The test program (listing no. 1) is not an exhaustive test but it does
verify that the mapping works. In it all the forty eight 4k blocks from
addresses 10000H to 3FFFFH are mapped into the 4k block starting at 1000H and
the block number is written into the first byte of the block. The process is
then repeated mapping the blocks beck and checking that the first byte is still
what had been written. It outputs ‘Success’ or ‘Failed’ depending on the
result. I didn’t have any problems so I haven’t bothered to extend the program
to explore which blocks failed.
Having all this additional memory, what did I do with it and was it worth
it?) The first thing I discovered was that it was no use for programs as there
is no way of linking sections of code or data at a particular address.
Therefore the first thing I did with the extra RAM was to use it as a 192k byte
RAM disk (see listing no. 2). The sector size was made 128 bytes to avoid the
need for deblocking and the track size was made 4k bytes so that the track
number for a read or write gave me the 4k block number to map.
To make full use of it I changed SUBMIT and the CCP to use the RAM disk for
the “$$$.SUB” file. Then I reduced the disk size by 4k and reloaded the CCP and
BDOS from it at each warm boot. Finally I patched Wordstar to look on drive M:
for its overlay files. What an improvement (provided I remembered to copy then
across first), particularly the speed up in editing. But I do regret that the
disk will never be big enough to use as a source disk.
For some time I considered the possibility of writing disk cache software
to use the memory more efficiently, but eventually opted to try a banked version
of CP/M Plus which already includes all the disk cache software. This meant
that I had to allocate 4k blocks of memory to banks, a 4k block to common memory
and then write my own bank switching routine (listing no. 3).