No, with a 32K Beeb the VDU drivers would "see" memory at &7000-&BFFF, with &4000-&7FFF reflected at &0000-&3FFF, so the user memory would be &0000-&2FFF. The user would have the usual choice of using memory for programs up to &7BFF in MODE 7 or for screens down to &3000 in MODE 0, just as our world's Model B.It could probably have used a little of the low RAM for higher resolution modes if necessary, similar to what the actual system does. A bigger problem with this idea though is that at a time when RAM is significantly expensive, you'd be constraining the user's choice of what that resource is used for. Imagine a 32K beeb with 16K of low RAM and 16K of screen memory overlaid on the ROM area - now for applications that don't require graphics, you no longer have the option of using that high RAM for general puprose storage.
With the 48K option there would be no reflections, the VDU drivers would still write to memory at &7000-&BFFF, but with a full 48K of memory MEMTOP would never need to drop below &7000. You'd get:
MODE 0 HIMEM=7000 VDU writes to 7000-BFFF
MODE 1 HIMEM=7000 VDU writes to 7000-BFFF
MODE 2 HIMEM=7000 VDU writes to 7000-BFFF
MODE 3 HIMEM=8000 VDU writes to 8000-BFFF
MODE 4 HIMEM=8000 VDU writes to 9800-BFFF
MODE 5 HIMEM=8000 VDU writes to 9800-BFFF
MODE 6 HIMEM=8000 VDU writes to A000-BFFF
MODE 7 HIMEM=8000 VDU writes to BC00-BFFF
Like this. (It makes more sense in my head):
Code:
16K Model AC000 +------+ |screen|RAM1 |\/\/\/| | |8000 +------+ |screen|RAM1 |\/\/\/| | |4000 +------+ |screen|RAM1 |\/\/\/| | |0000 +------+32K Model AC000 +------+ |screen|RAM1 | | | |8000 +------+ |screen|RAM1 | | | |4000 +------+ |\/\/\/|RAM2 | | | |0000 +------+48K Model AC000 +------+ |screen|RAM1 | | | |8000 +------+ |\/\/\/|RAM2 | | | |4000 +------+ | |RAM3 | | | |0000 +------+Statistics: Posted by jgharston — Thu Sep 11, 2025 8:37 pm