• Please review our updated Terms and Rules here

Dual (or more) booting a CP/M S-100 system

M

MykeLawson

Experienced Member
Joined
Mar 21, 2014
Messages
396
My development system is an STD/Z80/CPM system with 64K and uses a serial port for the console. As for storage, it has a CF to IDE adapter and uses address x8h to xFh. And since it does not decode the upper four bits of the port address, anything from 0xh to Fxh gets swallowed up. However, the software only uses the 08h to 0Fh values. So, if I add some additional decoding for the upper four bits in building out my S-100 system, things should work the same.

Now, if I added a second storage system, identical to the original, but, I added circuitry to switch between the two storage systems, I could effectively wind up with a dual boot system. I could flip bit 4 between the two and fool them into being the default.... Now, since the original is setup with a serial console and a 64K CP/M, I could take the second storage system and set it for a 62K CP/M system and put a 80x25 video card (Flashwriter II, hint, hint) in the very last 2K of the system.

When the primary storage system is active, then it disables the video card. When the secondary storage system is active, then the video card becomes active. In fact, by properly decoding the upper four bits of the I/O address, one could effectively fool the system into any number of boot configurations. And given the way my development system monitor ROM works, it could be done on the fly. Fip a switch to enable a different storage system, do a reset, and all is well. I attached the very simple schematic for the development disk system....
 

Attachments

  • DiskInterface.jpg
    DiskInterface.jpg
    51.2 KB · Views: 6
That would work, though in practice you could also just hot-swap software components in real time and move hardware in and out of memory space and do all of this without booting, or rather, via software rebooting since there's not much difference in CP/M, allowing you to reconfigure on the fly. Also, you can page video memory in and out as required from the BIOS also, or allow the TPA program to do the same.
As it's all CP/M, I'm not sure what benefit you gain from dual-booting from a fixed drive unless you're planning on running something like my OS as a second OS. My OS also dual boots, but that's mainly because I found there are times I just want to run a Vanilla CP/M from a testing POV and rather than booting a different disk, it hot-swaps the BDOS and CCP and moves them around in memory and uses a software initiated reset to restore the original, but that makes more sense because I'm not running CP/M. If you're already running CP/M, it makes more sense to hotswap components by just loading up a new BDOS/CCP via a reset function controlled by the BIOS, which knows what configuration you are expecting. A cold boot wouldn't be necessary. That also allows things like version upgrades and BIOS changes too, so you also might find it easier if using a fast system to boot into one preferred version of OS and then just reconfigure everything on the fly post-boot and call the initial OS a bootloader.

The easiest way to maximise the TPA is to use memory paging and hide it away from the system entirely where possible. You could just put all the jumps right at the top and keep the TPA to 64K - 512 bytes without too much difficulty. Once you've gone to that level of effort though, you might as well also just keep things they way they are outside of documenting what is happening since any memory mapped video is proprietary to CP/M.

Do you have a MMU methodology in mind? Since it sounds like you're looking at a defacto memory paging system more than a disk changing system, you could extend that and add some more memory and switch things around to really push the 64K limit. Then you can do stuff like add in graphics modes as well and give your CP/M high resolution graphics as a second video mode like the Matrox did :)
 
For right now, I'm just gonna keep it simple. One of my S-100 boards will have a bunch of SRAM that intend for now to be a RAMdisk. But one of the benefits of having a wire-wrapped system is that it can be modified rather quickly. So changing it to paged memory could be easy enough. But since this is just an exercise in keeping my brain working, who knows. :)
 
pbirkel@gmail.com said:
Interesting. What exactly did Matrox do, and how? Does any code/documentation still exist for that capability?
Click to expand...

Matrox pretty much invented the current generation high resolution graphics card for the PCs of the era...

Anyway, they had a 256 pixel and a 512 pixel ( 256 pixel/interleaved/four shades ) model, so could do 256x256 graphics. It was a 1 bit card - and you gave it an "X" coordinate and a "Y" coordinate via I/O ports and then it plotted a pixel there. It could also be genlocked.

I built a very similar card using old chips, and turns out I was pretty close to what Matrox did, but didn't know at the time.

There's articles on it here;

I've recently built a circuit that did almost exactly this - it latches an X and Y coordinate ( though I use a microcontroller as the source ) and can plot or read the pixel there. I used a 64k x 1 bit 70ns RAM for the video memory.

I didn't go as far as making it Matrox compatible but when I get some time I will.
 
You must log in or register to reply here.
Back
Top