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 could be swapped in and out of PROM. This seems like a decent idea in view of the way in which some compilers handled their TPA usage. You could end up with a pretty big BIOS if you make it any sort of fancy at all , and that could mean you can't run some compiled programs. 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 memory in which they claimed they could run. It wrote that to the boot blocks, 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 not a quick process. 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 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're loading overlays, with complete impunity. That way your blocking/deblocking buffer space can still reside in high memory. Just a thought . . . Dick -----Original Message----- From: Dwight Elvey <elvey(a)hal.com> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Thursday, May 27, 1999 3:25 PM Subject: Re[4]: Bringing up a CPM