REX2 Memory, CP/M Usage, and Startup of CP/M from REX Manager
REX2 Memory and CPM
V1.0 Steve Adolph
These are my notes and comments regarding the hardware provided by REX2, and how it should be used by CP/M. These comments are for M100/T102 and will be similar for T200 should we ever get to that.
REX2 provides selectable 32k blocks of memory that are visible in the OPTROM memory space. There are 32 blocks of FLASH and 4 blocks of SRAM. Blocks are numbered 0-35. 0-31 and FLASH, 32-35 are SRAM.
In a REX system, block 0 through 5 are reserved for REX system usage. Blocks 6-31 are flash blocks that are filled with user data, rom images and possibly a CP/M trampoline for example. The REX Manager software does not access blocks 32-35 - the SRAM is reserved for CP/M usage.
Selecting a block for access involves sending a command unlock sequence to REX, and then sending commands to switch access to a specific block number, and then locking REX again. I can provide all those details when needed.
REX2 SRAM is battery backed and survives power toggling. The Memory power switch will wipe it out just lik the regular system SRAM.
CP/M Usage of REX2 SRAM
CP/M needs all RAM mode, so one of the 4 SRAM blocks should be nominated for use as the default lower memory bank. I propose block 32 be reserved as SRAM for CP/M operation.
The remaining 3 blocks, 33-35, can and should be used as an internal RAMdisk for booting up CP/M. TPDD could be a secondary device.
I propose that we use a specific utility to load/save 96k images from the RAMdisk to and external system. We can build a disk image as the default image, and used Laddie or similar to transfer into the internal RAMdisk. I could write that utility.
RAMdisk Access by CP/M, and Interrupts
It is probably clear to everyone by now, but when accessing the RAMdisk, it will have to be bankswitched into the lower memory to access it. Interrupts will have to be disabled clearly, since the ramdisk won't have vectors. A TRAP occuring when the RAMdisk is being accessed, would be fatal.
This could be an argument for interrupt vectors being included into each 32k block of the ramdisk.
All routines that handle interrupts should probably be in upper memory - that is probably the case by default.
Startup Sequence for CP/M
Since CP/M will wipe out the main system RAM of the M100, we should use REX to preserve the state of the M100 whenever we start CP/M. Also, on exit, we could restore the state of the M100. This takes about 4 seconds each way.
There is a thing in REX called the ACTIVE RAM block. This is the block that the current main system RAM is backed up into.
Upon starting CP/M, we should go through the process to "REFRESH to the ACTIVE RAM BLOCK". Upon exiting from CP/M back to M100 OS, we should "RESTORE from the ACTIVE RAM BLOCK". I can provide all the code for doing this.
This implies that there needs to be some access to the REX Management software in block 0 of REX. So, all of this stuff should be callable from CP/M to the REXROM.
Anyhow, back to the subject of CP/M startup. There is only one situation I think - a complete restart of CP/M. We should store a block in REX with a CP/M trampoline. The trampoline could consist of
1) code that excutes the steps needed to start up CP/M (code designed to run in ALTLCD) 2) a default image for lower SRAM 3) a default image for upper SRAM
Why use code to run in ALTLCD? Because, just like for REX, we need to operate safely in upper RAM while we bank switch the lower RAM, to access what we need to access.
Proposal for startup of CP/M:
- refresh to the ACTIVE RAM BLOCK to save the M100 OS state
- wipe the upper RAM and lower RAM
- copy the default images to upper and lower RAM
- RST 0 - start CP/M
I think there are some gymnastics to manage around the ALTLCD space, since for at least part of these steps, we have to operate in there.
We could leave the storing of the M100 state to the user. Should be discussed.
It might actually make sense to maintain ALTLCD in CP/M (maybe even the primary LCD memory).