Want to get my IMSAI running CP/M

[smp]

Hello all,

For the very first time in my life, I am looking to get an S-100 system up and running with CP/M from scratch.

My system is:

IMSAI (with front panel)
Compupro CPU-Z
Compupro RAM-17
SD Systems Versafloppy II
www.s100computers.com SIO

I have a system monitor program that I cobbled together from the TDL Zap monitor and another Intel hex file loader that I acquired out on the Internet. This system monitor fits within a 2K EPROM that I have installed on the RAM-17 board at F000H.

Most recently, I spent some time chasing some memory problems that I thought I had. Then once I was certain that I have good memory in my system, I added in the Versafloppy II interface and attached a 5.25 inch floppy drive. I downloaded the Versafloppy diagnostic program available on www.s100computers.com (thanks a million John Monahan!) and patched it to run with my system monitor I/O routines. I have the Versafloppy diagnostic running (it's a lot of code - something like 14K) and it is exercising my disk drive quite nicely.

I have the hardware foundation for moving ahead and trying to get CP/M up and running.

I can use the diagnostic code to format the floppy disk in a variety of different DSDD formats.

What is my next step? Do I buy a copy of CP/M on a disk from eBay and then use the instructions originally provided by Digital Research to write a minimal boot loader and attempt to read CP/M into my system, and then patch it to communicate through my system monitor I/O routines? Are there copies of original CP/M out there that I can actually try this with, or is it best to get a disk image from Dave Duffield and start from there?

I have used CP/M machines before, but all have come with their own specific boot disks. I've never tried to do this from absolute scratch before. Any advice or pointers that you may offer will be greatly appreciated!

smp

 

[pcjunky]

I would be very interested as I have a very similar machine I would like to get going.

 

[Mike_Z]

I've been working on a homebrew 8080. The project was to get CPM 2.2 to function on it. I got a copy of CPM20.com from Chuck(G). I'd post it here but I can't figure out how to post a file on this website. I'm using 8" drives and used IMD and 22DISK to place CPM onto large drives. I wrote a CBIOS and a cold start loader, which seem to work pretty well. Yet I'm still improving them. My latest project is to add a retry on drive error routine. Once the CBIOS is proven, I want to incorporate it into my monitor program and expand the CPM 20K system to the max memory. I'm a slow worker, but seem to be making progress. I've tested the CPM 2.2 and found it work well, I also found some interesting twists, but that's part of the learning curve. Mike

 

[TX_Dj]

There is actually a pretty good video series on youtube on doing precisely this - now, ever disk controller works differently, so the specific code he used won't necessarily help you bootstrap from the front panel, but it sounds like you're well on your way in that regard, since you're already talking to the controller. You'll need to adapt his code to work with your controller, and then the steps should be pretty similar, and you can follow along with the cbios and such for your card to make your own CP/M image. Here's the first vid in his series, you can follow from there:

https://www.youtube.com/watch?v=sAHIR2OYNVU

 

[smp]

I am very frustrated at this point.

I have a good, working IMSAI system (as I described in the first post above), and I have the ability to load code into this system by sending Intel hex format files from my terminal (a laptop PC running Windows XP and Tera Term). In this system is a good, working SD Systems Versafloppy II floppy disk controller board. I have successfully acquired a Versafloppy II diagnostic program from the www.s100computers.com web site, and assembled it with a Z80 assembler I have on my laptop PC that I use as my terminal (thanks a million to John Monahan!). With this diagnostic program running in my system, I can exercise my two Tandon TM65-2L 5.25" floppy drives. I can format floppy disks, I can perform a random sector write, read & verify, I can copy disks from A to B or B to A and verify.

One thing that I found is that my floppy disk drives have a problem formatting at 128 bytes per sector. The single and double sided formats that try to format 128 bytes per sector in either single or double density do not work for me. The format is carried out, but when I try to exercise the disk afterwards with a random sector write, read & verify, I get errors sometimes. If I format the floppy disk as double sided, double density with 512 bytes per sector, everything works great. The disks get formatted, and I can let the diagnostic program perform the write, read & verify all day with no errors reported.

So, here I am with what appears to be a good working system, with a good working floppy disk controller, and two good working floppy disk drives.

I have been trying to figure out how to get CP/M into my system and onto a floppy disk.

An online friend of mine who I assisted in the past, was kind enough to provide me with some files to assist me. (He has an IMSAI with a Versafloppy II floppy disk controller and the same SIO board as me!) He sent me a hex file of 20K CP/M 2.2, as well as the source and hex files for a small CP/M BIOS set up for the Versafloppy II board. He also included the source and hex files for a putsys program, to put CP/M and BIOS onto a floppy disk once I get CP/M and BIOS running.

One would think that I am golden at this point, right? Well, no. My friend had 8" floppy drives, so he was able to format them as 128 bytes per sector and 26 sectors per track (or whatever the original single density IBM 3740 format was). All of the code he sent me is for 128 bytes per sector. 128 is 80H and it fits in one byte in the code. I am stuck at 512 bytes per sector in my system. 512 is 200H and needs two bytes in code. As well, all the code counts the number of sectors to read or write as 128 bytes per sector, etc.

I have tried the code anyway, and yes, it chokes because I cannot find a way to jump into CP/M without having it try to access the disk, and as soon as it tries to access the disk, it gets confused because it cannot read the disk.

I have looked and looked around, but I cannot find any code for a BIOS or a putsys that is set up for anything else except 128 bytes per sector, and that is a format that my hardware has trouble with. Am I doomed to have to go out and buy 5.25" floppy disk drives that are capable of formatting 128 bytes per sector? Am I doomed to have to somehow acquire 8" floppy disk drives?

Has anyone brought up a CP/M system from scratch with code that used any other size besides 128 bytes per sector?

Thanks very much, in advance, for any thoughts or advice you may have!

smp

 

[Chuck(G)]

Has anyone brought up a CP/M system from scratch with code that used any other size besides 128 bytes per sector?

Several. You have to write your own sector blocking/deblocking routines--the interface to BDOS still must be done in terms of 128-byte sectors--your CBIOS does the heavy lifiting. CP/M 2.0+ passes a value that actually helps you to optimize the write routines.

 

[DDS]

I haven't played with CP/M for ages but one thing that stuck with me is that the base system only does one disk sector size. The custom code that was required for anything other than a basic IBM 3740 style drive had to handle the blocking/deblocking of any other sector size before handing the data off to or after receiving data from the base system. That code was usually written by a vendor when they customized CP/M for their particular hardware.

 

[1944GPW]

I had a Versafloppy II in my Applied Technology S100 box 35 years ago, so I started writing a simple operating system for it (more like a loader and saver). I recall the VFII's EPROM had calls that saved a chunk of memory to diskette, given the track, starting sector and number of sectors (I think), and a complement for loading from diskette. There was an interesting article in BYTE (or it might have been Kilobaud) called 'Roll your own Disk Operating System' which covered the FAT and data block layout which I used as the basis for the OS.
The Versafloppy II was a great board so if you can hook up those routines and your keyboard routine to CP/M BIOS then you ought to be good to go.

 

[smp]

I recall the VFII's EPROM had calls that saved a chunk of memory to diskette, given the track, starting sector and number of sectors (I think), and a complement for loading from diskette.

My Versafloppy II does not have any EPROM on it. Could it be possible that you had another SD Systems board along with your Versafloppy II?

Here's a reference for you: http://www.s100computers.com/Hardware Folder/SD Systems/VersaFloppy/SD Systems Versafloppy.htm

I have a Rev P Versafloppy II.

Too bad for me. I would love to have some EPROM support like that!

smp

 

[Chuck(G)]

Here's an outline of what a CP/M blocking/de-blocking routine should look like.

First of all, you'll need a buffer in BIOS RAM or somewhere outside regular CP/M BDOS/user program memory space. In other words, don't get the idea that you can put the buffer in the TPA. This buffer should be the size of a physical disk sector, which will be a multiple of 128 bytes. You'll also need to keep two more pieces of information around: What disk sector (C H R) is stored in the buffer (or if the buffer contains nothing meaningful) and whether or not the buffer contains information not yet written to disk (the "dirty" flag).

You'll need a routine that can move 128 bytes to or from the disk buffer.

Finally, you'll need disk routines that can read or write a sector to or from the buffer.

So, this is the basic strategy:

1. If you're reading a CP/M 128-byte sector, you first need to check if that lies within a physical sector currently within your buffer. If so, you simply need to calculate the starting address of the CP/M sector within the buffer and move 128 bytes to the CP/M-specified DMA address.

If the physical sector containing the desired CP/M sector is not in the buffer, you first need to check to see if the buffer contains data that hasn't been yet written to disk. If so, write it and clear the "dirty" flag. Next, read in the appropriate physical sector that contains the desired 128-byte CP/M sector, update the buffer status and go to (1). Easy, right?

Disk writes are a little more complicated, but somewhat similar. You're helped by the value passed in (C) by the CBIOS "Write Sector" call.

1. First of all, see if you've already got a buffer with the "dirty" flag set that contains the 128 byte sector that you're writing. If so, then just move the data into the buffer and you're done. Some BIOS code assumes that files will largely be written in consecutive ascending sectors, so when the last sector in the buffer has been written, the buffer is written to the corresponding physical disk sector and the "dirty" flag is cleared. Other BIOSes don't make this assumption, so you'd do nothing.

2. If the physical sector that you're after isn't currently in the buffer, you need to check the "dirty" flag and write what's in the buffer to disk ("flush" the buffer). As a matter of implementation, it's useful to have a "flush to disk" routine that inspects the flag and writes if necessary. That way, you can call it from several places in your code (which can be useful).

In any case, you're now with a clean buffer and you need to figure out how to "insert" the new 128 byte block (from the SETDMA routine) into the correct place in a physical disk sector. Usually, this is just a matter of masking off the low bits of the CP/M sector address, so that, for example, if you have 512 byte physical sectors, CP/M 128-byte sectors (0, 1, 2, 3) are in the first 512-byte sector on the track, (4,5,6,7) on the second, and so forth. Take these masked off bits and shift them by 7 bits and you have the appropriate offset into the 512-byte buffer.

Now, this is where the value passed in the (C) register by the BDOS for the WRITE routine comes in. If the value is 0 or 1, you'll have to first read the corresponding physical sector from disk, then insert the 128-byte CP/M sector data (again, from the SETDMA call) into the buffer in the correct place. Mark the buffer "dirty".

If the value passed in the (C) register is 1, signifying a directory write, you'll want to flush the buffer immediately to disk to avoid later corrupted directory issues. Mark the buffer "clean".

If the value passed in the (C) register is 2, the BDOS is telling you that this is the first write to a previously unallocated block, so you can skip reading the block before you move data into the buffer. So do that, and mark the buffer "dirty".

If the BIOS is entered as the result of a re-boot, you'll want to flush the "dirty" buffer.

All of this is detailed in Appendix G of the "CP/M 2.2 System Alteration Guide".

Some CP/M systems with memory to burn will track-buffer data from the floppy. This is very effective if you're using a controller that can do multi-sector I/O and the disk is interleaved at 1:1.

Beyond this, your only big decision is whether or not to use a memory buffer for each drive or to use a common buffer for all drives.

 

[1944GPW]

Chuck has pretty much covered it above - reading and writing sectors to and from memory.

My Versafloppy II does not have any EPROM on it. Could it be possible that you had another SD Systems board along with your Versafloppy II? . . .
smp

Looking at your link, I haven't seen that VFII manual in three decades, brings back some dim memories.
To my amazement I have just found an old folder with amongst other Z80 code projects, my original notes circa 1982/83(?) for my simple 'operating system', and it was definately a Versafloppy II I had - it's written at the top, including something about its I/O ports being from 60H to 64H. I ran the VFII with a TEAC FD-50A 5-1/4" floppy drive. The info and flowchart for section 3-2 SECTOR READ SEQUENCE that sounds familiar, where a specified 128 byte 3741 sector is loaded into memory, and the following bit on writing a 128 byte block out. This may have been using the 1791 FDC controller directly or perhaps it was the DDBIOS. One of the code fragments with a label named GETASEC has HL being loaded with the destination address for the sector coming from disk, which ties in with the 3-2 flowchart.
It mentions a 2716 EPROM with their DDBIOS/SDOS track read/write routines that sort-of sounds familiar. Now I did have a 2716 eprom board in my AT S-100 system, so maybe that's what I used. I know I sound pretty vague but it was a long time ago :sleepy:
My dad designed and built a 2716 EPROM burner on an S100 card (I have some pages of notes and Z80 code for that too!) so we either had that rom or burned it ourselves. We did not have CP/M until much later - my brother and I preferred to spend our pocket money on hardware rather than software (Z80 games on cassette tapes excluded!) so attempting to write an OS was not only fun, but a necessity. Later on we acquired a Micropolis II floppy and S100 card, the only thing I recall about that was that it hard-sectored floppies (but it did have CP/M). If anyone's interested I can scan my old scribbled notes that were spread across 13 foolscap pages, written in my high school days.

Steve.

EDIT: I just found the magazine articles I mentioned, there were actually two I had looked at (I had thought it was one). They are: 'Software for the Economy Floppy Disk' BYTE June 1977 page 88, and 'The Hobbyists Operating System' in Kilobaud January 1977 (in a few parts). Both these are available on the web.

 

[Chuck(G)]

I'll add that using larger sector sizes can result in substantial performance improvements over using 128-byte physical sectors--and you get more storage on the same media.

To address the last first, consider a single-density 8" disk. You can comfortably fit 26 128-byte sectors (normal CP/M type "A1"). However, if you double the sector size to 256 bytes, you can fit 16 256-byte sectors on the same disk (HP 125 format). That's 768 bytes more per track, or 59K on a single-sided floppy. You get the added benefit that the result won't cross a cylinder boundary for the last allocation block on the track.

Now, consider reading or writing the same disk using 256 byte sectors. To read a track, you're only doing half the number of reads and thus, the interleave can probably be lower than the normal 6:1.

So, at the expense of a bit of memory and a little extra code, things can really speed up.

 

[smp]

Here's an outline of what a CP/M blocking/de-blocking routine should look like.

Hi Chuck,

Thanks a million for all your attention and advice. I studied what you wrote, and I understand most of it. I believe this level of programming effort is a bit too much for me. I certainly understand what you describe. In order to us a disk that has sectors larger than 128 bytes, then I will have to handle all the disk I/O to read in or write out a sector (like 512 bytes) but then handle it internally as the several 128 byte sectors it represents, down to the 128 byte sector that the BIOS thinks it is asking for, or providing. Low level disk I/O handling is just more than I can attempt for myself.

I am happy that I've brought my system up to the point that it is stable and running well with a variety of boards, and I am especially happy to have acquired the Versafloppy diagnostic program, and adjusted it to operate in my system.

I will probably move on to dig out my Northstar floppy disk interface again, and give that one another try. Now that I have a good handle on my system, maybe that will get me up to the point of running a primitive disk operating system on this old iron.

smp

 

[smp]

Hi Steve,

It mentions a 2716 EPROM with their DDBIOS/SDOS track read/write routines that sort-of sounds familiar. Now I did have a 2716 eprom board in my AT S-100 system, so maybe that's what I used.

Yes, I bet that's it. I've seen a lot of stuff on the Internet indicating that SD Systems provided a bunch of stuff along with the Versafloppy interface, and a BIOS in EPROM is prominent in there.

I just found the magazine articles I mentioned, there were actually two I had looked at (I had thought it was one). They are: 'Software for the Economy Floppy Disk' BYTE June 1977 page 88, and 'The Hobbyists Operating System' in Kilobaud January 1977 (in a few parts). Both these are available on the web.

Thank very much for the pointers. I look up those articles, and there's a lot go guidance there. I'm just not up to that level of intensity in my hobby programming at this point. Like I said in my response to Chuck above, I'll probably put the Versafloppy board aside and give my Northstar floppy disk interface another try, now that I know for sure that I have a good stable working system.

smp