This sounds wild! What's the hardware that supports all this?
At the moment the hardware is just emulated while I write the OS ( CP/M clone OS ) and finish converting the BASIC, but it's pretty simple in terms of hardware decoding. I'll make some physical hardware once I've finished all that - it's a long terms project for me, and without the software/OS/BASIC etc, there didn't seem a lot of point to build hardware that can't be tested - also, as I've written the OS and tested it in the emulated environment, I've learned where I need to change things to improve - and it's still not fully debugged, but works for the most part. Currently a functional version is on GIThub - so it's possible to try out, though the mechanisms for getting CP/M software into it are a bit clunky so once I've finished converting Sinclair ZX Spectrum BASIC to run under CP/M, I have to modify the environment so .COM files can simply be put into a directory under Windows 11 and when the emulator is run, it will convert them to/from CP/M format and then write files back to the directory when it's finished.
The emulator also covers the graphics hardware now - I wasn't fully confident in the graphics hardware so I did actually build that to the 90% level as a proof of concept - and it worked and produced video with very tight timing specs - It can do 512x192 graphics at 16 colours using just two GALs as raster-address and timing generators running from a 7 MHz clock. I wanted to see how far I could push 1985 technology based on designs that were touted and never built - The Loki was Sinclair's proposed "Super Spectrum" that was supposed to be impossible to build, so his investors pulled the plug, but if you follow the path left behind by the clues, it looks like there are certain specifications that require very low chip counts. For example, the proposed hardware vector graphics should be able to draw lines at 7 pixels per microsecond, yet works without any comparitors and requires just a single TTL adder and a counter - given they would have converted these to ULAs back in the day, it's an extremely low chip and gate count. I can't get ULAs so I just use PAL/GAL chips when I do test something.
The architecture itself follows this. It's from my earlier notes but mostly reflects the current state.
It uses two 22V10 PAL/GAL to drive the lower bus address lines, and a fast SRAM to drive the upper address lines MA12 to BA19. It swaps some Memory and I/O addresses to ensure that 128 bytes of RAM are mapped to the upper I/O address that z80 in/out commands use access individual RAM addresses, so the below assumes some additional decoding logic to tell it whether it's an I/O or a Memory access cycle, and of course, one decoded I/O address will appear to be a memory access cycle so that I/O to that port ( lower 8 address lines ) will swap the addressing via multiplexing in the PAL/GAL chips, and the latched MA7 to MA11 will be pushed out onto the bus rather than CPU addresses A7 to A11, and the latched "track" outputs show up from BA12 to BA19.... It's incredibly simple in design.
Also, the use of a SRAM for most memory decoding could be replaced by a single memory management chip in TTL ( they did exist in 1985 and worked with the same 4K blocks also ) but by using a RAM, I can create "processes" allowing me to switch which memory banks are paged in with a single out command - so drivers can have their own process, and when something like the video driver is accessed, so there's no need for the software to care about what is happening - it's automatic.
I could go further and hardware map the actual directory itself to the MMU, and slave them off of RSTs and Interrupts, which would hardware switch paging automatically to support multitasking environments ( ie, when an interrupt occurs, it automatically changes the paging model ) but I decided that's a "later" enhancement I can chase after I build the base hardware.
If you follow some of the videos I post, you can see how this actually looks in practice.
The first few bits show the L: drive ( ROM Boot drive ) and the M: drive ( Memory Management show up when I do a "DIR" - Each file is a reserved memory map. )
Interestingly, because CP/M supports cross-linked allocations without any issues, I use that also - for example, the directory structure shares common allocations for Page0 and Page 14 and 15 between the RST allocations so that if a RST is called or activated by an interrupt, it can change the Process ID and page in it's own memory - The video driver does this, but I've left the RSTs alone so anyone can use them for their own purposes.
And of course, the Spectrum ROM BASIC you see running later simply redefines these anyway, as Spectrum ROM calls the RST for internal functions to save memory.
It's a fun architecture to play with. It links a file name to each process ID and allows for up to 256 process IDs ( though I'll only include about 32 in the first hardware version ) and you can use standard 3rd party CP/M DISK tools to see how memory is both allocated and being used, as well as telling you how much unused memory you have. Also also allow the creation of "unused" files so that if you don't have 1Mb of RAM, you simply allocate the unused memory to a file that tracks them and then the system won't try to reuse that memory. Even the TPA doesn't require contiguous RAM for this reason.
Finally, the upper 8 drives are permanently mapped to the MEMORY by the BIOS - But all in different locations. This means that all I need to do to support an option ROM is to look for a file that is supposed to exist on the drive letter assigned to that option ROM and if it's there, execute it. This performs the checking of the drive, makes sure the file is valid and in the right spot and then runs it -
The advantage of this? You can also store utilities in the ROM - for example, imagine if you install Floppy Drive Option ROM in Drive P: - Not only does it self-install a driver, but you can add critical routines such as "Format" - so you can add commands to CP/M that are hardware specific, and if you wanted to format the disk, you'd just type "P:FORMAT D:" or something like that. You can already reload the video driver which is on J: drive by typing "J:VIDEO" and it reboots the video driver and reloads itself into memory.
Why? Because if you're running video through a terminal, you can also do something like "ERA M:VIDEO.DRV" and "ERA M:VIDEOMEM.IMG" which would return 2 extra pages from the driver, and allow 64K (16 pages) of video memory to be used as system memory since the video output is no longer in use... Or if the NVM drive ( planned for 256K of static battery backed RAM) isn't wanted, you can "ERA NVMEMORY.DSK" and suddenly 256K of RAM becomes system memory and now the system has 917K of system memory available.
And, if you want to turn the NVM back on, a utility can determine which processes have to be killed or have their memory allocations copied and changed to release that memory! Which is pretty neat. It's a very flexible architecture.
I haven't written it as a multitasking OS, but given at least one RST (38) is going to be attached to an interrupt generator, and the same with the NMI, it wouldn't take much to write a preemptive kernal even in 1Mb. It's a shame I can't hardware switch all the z80 registers too!
