BigEd wrote: ↑Sun Mar 19, 2023 8:45 pm
You're picking B for Apple, but I'd pick A for beeb! To cook up a reason, a system designed to run at 2MHz has a chance of later expanding the RAM, but a system with 48K RAM running at 1MHz is more difficult to upgrade to 2MHz. ...
But the beebs interleaved video access meant 2mhz mpu needed 4mhz ram bandwidth to cover graphics leading to a long wilderness period where its 1mhz equivalent competitors had more ram more affordably and the beeb b had no software backed way to catch up..
Perhaps a compromise could be 2mhz mpu Rom at 2mhz, zero page and stack at 2mhz by using a small 512byte-ish static ram, other ram at 1Mhz that might have encouraged a max 48k linear ram even if not populated at first.
Adding 16k of sideways ram to a 32k bbc b is ok for games but doesn't help high level programmers or applications (unless you fits lots and officially take the Bas128 approach of language/app in main ram using multiple 16 sideways ram pages for data(ie basic code)) , but that would have needed encouragement from Acorn by supplying such language/application versions. It might have allowed of official Acorn opcode originating address controlled shadow ram to be skipped, thus avoiding a damaging
court case hiatus/disagreement/other better description with Aries over the patent/patent application.
Otherwise A linear 48k max beeb b would just have seemed to have a longer useful life without needing the complex patent-defendable shadow ram imo
EDIT I would include Rich Talbot-Watkins idea of keeping the bbcs 4 16k chunks architecture but allowing the maxing out of linear ram to 48k to move the vdu memory beside the basic/sideways rom area where it would paged by usual software method by MOS vdu drivers , adding some 16k vdu modes, and just leaving any extra space for machine code or workspace for language.. Actually, I think Rich Talbot-Watkins idea is a much better basis for the B+ and should avoid the 20k shadow ram court case.
EDIT Interestingly? The originally 48k linear max ram Apple II, despite its (charming?) idiosyncrasy, its successor II models seemed to facilitate the increasing need/desire for more memory better than the ( more seemingly elegantly designed) beeb at least from an application user/high level language programmer pov ...?
EDIT as paulb as mentioned elsewhere, the original Bbc computer could have satisfied the Bbc studio need for proper broadcast quality teletext output with an external addon teletext box, so if the Bbc could have been persuaded to drop the mode 7 requirement, the money saved on the mallard 5050 and support circuitry could have been used to make 32k dram go further:
..............a serious computer needs an 80 column mode, so instead of teletext mode, instead supply a conventional ROM fed text only 80x25 character mode (and 40x25), needing only 2k(and 1k), so 26k free for serious apps. (Or would 80column teletext be cheaper
if possible on the beeb) An E00 dfs would mean shadow ram provided little extra for serious 80 col text apps. An 80 column text mode would also mean perhaps bitmapped modes 0 and 3 could be dropped reducing the required video memory bandwidth if desired ;*.
Perhaps the character Rom could hold the appropriate teletext chars, allowing a monochrome mode 7 simulation.
More memory for machine code games could be provided by sideways ram, so if Bbc b+ had been shadow free just with 2 sideways ram banks, a plain bbc model b could be easily upgraded to match it compatibly, and no Shadow ram
court case trouble...
*
(in that case presumablyreducing colour bitmapped modes bandwidth would also be desired: perhaps by OS support for redefining pallette in different screen areas, a 160x128 resolution mode2 etc)