Theminbios.z80 code used so far only has the minimal functionality needed to get CP/M off the ground. Well… slightly more, to be precise: it can see 256 KB of RAM as virtual disk A: and 256 KB of flash memory as (read-only) virtual disk B:.
There is no persistence. There are no applications to run at all, in fact - not even the standard CP/M utilities such as STAT and PIP, for example.
We can take this a little bit further by copying more files to the virtual disk image that gets uploaded to flash. Here is a slightly larger disk image, with at least a minimal set of utilities:
A>dir b:
B: HEXSAVE COM : GETFLASH COM : PUTFLASH COM : XMODEM COM
B: MAPDRIVE COM : DDTZ COM : DUMP COM : LOAD COM
B: LS COM : PIP COM : STAT COM : SUBMIT COM
B: XSUB COM : XMODEM CFG
A>b:stat
A: R/W, Space: 247k
B: R/W, Space: 208kBut it’s still not very practical: the flash memory is read-only, and everything stored on A: is lost on power down. We can push some more utilities over the serial port, using a save-in-memory-then-dump-to-file utility such ashexdump.z80, but it’s still very limited, error prone, and insufficient to get data back out again. A more advanced utility such as “XMODEM.COM” can send and receive files reliably, but let’s not forget that we have less than 250 KB of storage on A:, so even this approach will quickly run out of steam… or rather: disk space.
The solution is to hook up an SD card. Then, storage-wise at least, all our worries will be over.
There are two ways to do this: on the eZ80 side or on the Blue Pill side. The benefit of putting it on the Blue Pill side, is that we can play tricks with the disk image virtualisation, while the eZ80 sees disks with 128-byte sectors. And Forth is a lot more fun to write than Z80 assembly!
The drawback of this approach, is that we need to invent some sort of simple way to pass disk sector R/W requests from the eZ80 to the Blue Pill. This will be addressed in the next article.
For now, let’s focus on the design choices for an improved BIOS, calledmaxbios.z80 !
Each disk needs space in the BIOS to manage block allocation and larger disks need more space, so if we want to stick to the default 1.5 KB BIOS size, we have to make careful choices.
It might be tempting to define one or two 8 MB hard disks, the maximum size supported by CP/M 2.2, but since there’s no support for sub-directories, they are not really that convenient. In the era of floppy disks, organising data was a matter of swapping various disks around!
Here’s the disk structure chosen for this EZ-Retro project:
| Drive | Type | Size | System | Max files | Notes |
|---|---|---|---|---|---|
| A: | RAM disk | 360K | 6.5K | 64 | uses 512K SRAM |
| B: | ROM disk, R/O | 256K | 6.5K | 64 | internal eZ80 flash |
| C: | RAM disk | 1440K | 0K | 256 | uses 2048K SRAM |
| D: | Virtual disk | 1440K | 18K | 256 | mapped to SD card |
| E: | Virtual disk, R/O | 1440K | 18K | 256 | mapped to SD card |
| F: | Virtual disk, R/O | 1440K | 18K | 256 | mapped to SD card |
The C: drive is only available in systems with 2048K RAM installed.
The disk format used for the D:, E:, and F: drives is the same as in thep112 project.
In terms of speed, A:, B:, and C: will be fastest, since these are all stored in local memory, with disk access being nothing more than a bulk memory copy. The D:, E:, and F: drives are virtual and sent off to the Blue Pill, so there will be a slight lag - but nowhere near the lags of real hard disks, since this data still resides on µSD cards without any seek time or rotational latency.
Drive A: starts off as an empty and fairly small 360K disk, but it can also contain a copy of the B: flash drive, in which case the disk geometry changes accordingly, turning A: into a 256K drive. The reason for this is that A: can then be used as alternate boot / startup disk and that its contents can be transferred to the B: drive, erasing and overwriting the flash memory. This is intended to be used for system modifications: try new code out on A:, then (once verified to work as expected) freeze it as permanent back onto B:. Seegetflash.z80 andputflash.z80.
Drive B: is intended as system disk, containing the essentials needed to boot and use CP/M. The system tracks on B: (tracks 0 and 1) determine what EZ-Retro does on power-up.
Drive C: (if available, else the smaller drive A:) is intended for all non-critical information, build results, temporary files, etc. Its contents is lost when the EZ-Retro is powered down.
Drive D: is the main persistent disk, and 1.44 MB should be plenty for running applications and performing tasks as in the ol’ days of CP/M. Back then, most floppies were a lot smaller.
Drives E: and F: are similar, but always read-only, so thatonly drive D: needs to be tracked, backed up, and cared for - E: and F: are intended for bringing new files into the system.
As implemented so far,maxbios.z80 fits comfortably in the allocated 1.5 KB of upper RAM, with over 100 bytes left for future extensions. Half the space is used for buffers and maps.