Chuck Guzis wrote: I'm sure a lot of us say that :-) I've got a few odds and ends here - Research Machines (CP/M and MP/M "natively"), Acorn (CP/M via Z80 coprocessor), Apple (CP/M via Z80 coprocessor), Torch (CP/N - sort of CP/M with various non-standard bits). I doubt there's any shortage of CP/M capable hardware owned by people on the list - there's just a shortage of CP/M "hardcore" knowledge, because the systems don't get used often enough for people to remember the real nuts and bolts.

Chuck Guzis wrote: I'd say no. It's real hardware. Peace... Sridhar

--- rachael at rachael.dyndns.org wrote: Particularly if it's a vanilla XT board, the answer is no reason you shouldn't. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Chuck Guzis wrote: Interesting; did CP/M ship with a range of UART and FDC drivers then, so you just tell it what particular ICs you're using and at what port addresses, and away it goes? Or was it more complex than that, and realistically you'd have to write your own comms / FDC driver which exposed some defined interface to CP/M itself? Hmm, one of my Research Machines (RML) systems has the networking add-ons; I think they called their implementation Z-net. Clients have enough ROM-resident code to invoke some form of network boot from the server - what I'm not sure is whether the OS image transfer is part of core "network aware CP/M" or whether that's a Research Machines extension (with the core stuff only really providing network-aware file services). The manuals are rather buried at the moment, but I seem to recall that they weren't exactly big on details anyway (RML were great at producing hardware documentation, but not so hot at writing down how the software side worked) cheers Jules

On Apr 18, 2007, at 4:43 PM, Jules Richardson wrote: The CP/M distribution, as shipped only boots & runs on one particular type of machine: an Intel MDS-800 development system. If you (or a computer manufacturer, say Kaypro for example) wanted your machine to run CP/M, and it wasn't exactly like the MDS-800 in terms of what I/O chips were used and at what addresses, you had to write the drivers to support your hardware. These drivers form the BIOS. CP/M was shipped with the intention that users would write their own BIOS code to support their own systems. In truth it is really not all that difficult. The BIOS interface is very simple and well-defined. Under the tutelage of an experienced mentor, I was writing BIOS code on my Imsai when I was about fourteen. It's nothing like the complexity of, say, a device driver system for an implementation of UNIX. -Dave -- Dave McGuire Port Charlotte, FL

On 19 Apr 2007 at 3:20, Sridhar Ayengar wrote: Well, CP/M 2.2 have no "open" and "close" function, just read and write--single character for character devices and a single 128 byte block for mass storage. The closest thing to ioctl is the "select unit", "set track" and "set sector" entry points. While BDOS supports open and close functions, it's entirely up to the user to track open files--the BDOS doesn't contain so much as a list of open files. Early MS-DOS operated the same way--using FCBs for file I/O like CP/M. Directories are, of course, flat, though you could qualify entries with a "User area" field that was not considered to be part of the filename. Allocation information is kept with each directory name entry; when a file got large enough, another directory "extent" was allocated. There was a very firm upper limit (implementation defined) on the number of files one could have on a volume. IIRC, the upper limit on disk storage was about 8 MB per volume. One needn't worry about reentrancy, multiple character/block requests or interrupts. Everything's done with a jump vector table; since CP/M is non-multitasking, management of driver data is simple. If you were dealing with disks with sector sizes larger than 128 bytes, some write-behind, read-ahead logic was unavoidable, but even there, the BDOS would help out by signifying if the read was for a directory block or the write was for a newly-allocated block. If you had sufficient RAM to do full track reads and writes, you could often improve the speed of CP/M I/O significantly. Disk volume tracking was done using a simple "checksum" on a installation-defined number of directory entries. If a disk was changed unexpectedly, the BDOS responded by setting its status to Read-Only and displaying an error. Later versions of CP/M supported multi-block I/O and file date and time stamps. Cheers, Chuck

You had to write something called a CBIOS (Customised Basic Input Output System IIRC). This was a set of routines to handle terminal I/O (and printer, paper tape I/O if you wanted that), disk block read/write, and so on. There's a manual giving the specs for these routines, how to get CP/M onto the target machine, and so on. The original CP/M distibution came with the source for a CBIOS for the Intel MDS800 (IIRC)m which you could use as a starting point I've never done it, but it ;ooks like quite a 'fun' thing to do for suitable values of 'fun'. Of course if you bought a packaged machine to run CP/M it came with a CBIOS written for that machine. And alas you rarely got the soruce of that :-( -tony

Hmmm, I have a Northstar Horizon and an IMSAI. I haven't used the N* recently but I think it's running 2.2. The IMSAI (with an iCom Frugal Floppy system -- the bank of my existence) runs CP/M 1.4. Then, of course, my Altair32 Emulator runs CP/M 2.2. On 4/18/07 12:24 PM, "Chuck Guzis" <cclist at sydex.com> wrote: Rich -- Rich Cini Collector of Classic Computers Build Master and lead engineer, Altair32 Emulator http://www.altair32.com http://highgate.comm.sfu.ca/~rcini/classiccmp