A sickly beeb and a cunning plan

Post date: 21-Jan-2010 18:15:06

We've got 4 Beebs between us - 3 model Bs (one a loaner) and a Master. We also have an Electron, but that's a bit special - the CPU is socketed, and the video/CPU memory sharing is more involved.

Ed's beeb had a RAM extension - Solidisk sideways RAM - which was becoming unreliable. So he removed it (several flying leads had to be removed too: this was quite an invasive upgrade.)

But from that point on, the machine has become unreliable. It will usually boot, but stray characters start appearing on screen, and the rate of stray writes starts to rise. This makes it an increasingly marginal platform for testing.

So Ed took the path of least resistance and switched to the loaner machine for a few months.

Our cunning plan is to map some or all of the host RAM into our fast RAM on the Level1b board. Mapping RAM is attractive for other reasons: if we can access the memory at full speed instead of host speed, we get faster access to the stack and zero page, also to the OS and language variables in low memory, and to any user program which is located in the mapped area. (Unfortunately, as it makes no sense to speed up for single accesses, there isn't actually any speed gain unless the code and data are both in fast memory. It would be very nice to be mapping the ROM space too, but that's for another day.)

Back to the flaky machine...

If the stray writes are confined to RAM, the machine become usable again! We've got 128k on board (512k also supported) so mapping 32k isn't a big deal. If we map video memory onto the board - the Beeb uses from 1k to 20k of the 32k for video - then we won't see anything on screen. Unless, in an extra level of cunningness, we mirror writes for some or all of the mapped RAM back to host memory. The CPU will have to slow for some proportion of writes, but we'll get to see graphics and the stray writes will only disturb the view, not the machine.

The first effort is likely to be: 16k mapped, writes not mirrored back to host.