<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
Received on Thu May 27 1999 - 21:54:11 BST