<If you're writing your own, it might be well to keep in mind that the BIOS <used in several late-generation CP/M systems used device drivers which coul It was late generation in 1981! I started doing it then. CPM had a formal product called CP/M+ (CP/M3.0) to extend that idea. <California Computer Systems (CCS) had a pretty nice boot process in which <they loaded a skeletal BIOS in a 32K CP/M, since 32K was the smallest memor <in which they claimed they could run. It wrote that to the boot blocks, Actualy it was 20k for cpm2.2, as it was distributed as a 20k system that you would run movcpm on to get the xxK version you wanted. <then, under the control of that skeletal system, they loaded a "full-size" <(you get to define that!) CP/M and transfer control to it. It's pretty <solid and makes the preparation of a bootable disk a straightforward if no <a quick process. Yes and they were doing it a long time back, Compupro too. Kaypro was one of the few "boxed" system that had the rom mapped to get a large TPA. <IIRC, the XEROX 820 used a swapped-in BIOS which lived in PROM and was <mapped into the TPA during file transfers, or something on that order. If Classic. <your machine can handle that, it saves on BIOS size, especially tables, etc <and, generally speaking, if the READ operations from the TPA are from <temprorarily mapped-in PROMs, you can overwrite the TPA in the event you'r <loading overlays, with complete impunity. That way your blocking/deblockin <buffer space can still reside in high memory. An IMSAI can neither handle that nor not handle that. The basic design had no rom! To do that you need a prom card with a little bit of hardware to map it with an IO port. The key here is to get a working system in whatever space... Why, it's the development platfrom for itself. Once you have it running and can poke and understand it the improvements will come. Allison