View Full Version : CP/M2.2 Source Code II

March 8th, 2015, 07:10 AM
The first thread was getting rather long, so I thought of starting another. While I'm waiting for some new 8 inch disk to show up, I thought I'd try some testing of the internal commands. The DIR command seems to work, just fine. I tried all the wildcard marks. I found a different disk that has some good low tracks for this testing. In fact the Siemens drive works just fine with this different disk. So, I moved on to tried the ERASE command and it didn't work. I tried to erase the ED.COM file. The disk was not write protected. I'd type in ERA ED.COM, the program would take some time access the drive, then do a CRLF and redisplay the A> prompt. A DIR revealed that the file was not erased. So I figured that maybe the transient commands are read only files. I read that the file user number on the directory is also used to mark the file as deleted and the 7th bit of byte 9 shows read only status. Is there a way to look at and maybe change these bits/btyes using 22DISK or IMD or some other program?

Then I tried some other ways of erasing files with wildcards and got two different results. When the file name contained a wildcard, the response was the same as above

A>ERA E?.COM (user input) or A>ERA ED.COM

A> (computer response)

BUT, with a wild card in the extension, I'd get an error message.

A>ERA ED.?OM (user input) or A>ERA ED.*

Bdos Err on A:File R/O (a crtl c would re boot and display the A>)

Indicating that the file is read only, but why should this report the error only when a wildcard is used? Is this normal? I'm going to look through the CP/M code and see if I can determine why. Mike

March 8th, 2015, 08:32 AM
This seems a little odd. I removed the cover from the write protect slot on my system disk and then booted the system. I stopped the system and looked at the WRTPRT words at 111 255 & 111 256. All the bits are set to zero. So the boot does not check for write protect at the start? I then did a DIR and checked again for write protect and still the same, all zero's. I can't seem to get anything to change in WRTPRT. Is a zero write protect or a one? Seems it is a one. Mike

March 8th, 2015, 09:14 AM
Am I thinking about this correctly? How does the WRTPRT bits relate to the physical disk write protect slot? The WRTPRT bit could be set or not regardless of whether or not the slot is covered or not. How are these sync'ed or is it not required? Mike

March 8th, 2015, 09:19 AM
The message does not necessarily mean that you have an actual write-protect error. If the BDOS detects that you have changed the disk, it will label the drive as protected. What this implies is that the directory as read does not match what was expected. In other words, have you actually written to the disk?

March 8th, 2015, 09:44 AM
I had to retry to be sure. When the Bdos Err on A:File R/O was displayed the head was not loaded. But when the error message was not displayed, the head was loaded, so I believe that the disk was read. Mike

March 8th, 2015, 10:27 AM
The procedure for an ERA, if memory serves, is that the directory with the updated information is written, then read back, a new checksum is computed and compared with what it should be. If there's a mismatch, the RO bit is set. What this means is that you're not reading back what was written. At that point, any attempt to write to the disk will be failed by the BDOS.
Mike, I think you're probably taking the long way around the barn here. Back in the 70s, there was no source code available for CP/M to vendors. You took the alteration guide and programmed your CBIOS according to it and CP/M just worked. By digging around inside, you get distracted with CP/M BDOS internals and don't see your really basic problems in your CBIOS--which is really where you need to start. Myself and others (e.g. Epson) have written CP/M clones--it's not rocket science.

The only way for a CBIOS to notify the BDOS that write-protect is active on a floppy is to fail a write operation. The actual reason that a write fails (e.g. write-protected disk, bad address mark, drive not ready...etc.) is immaterial to the BDOS.

Your bible should and must be the "CP/M 2.2 Alteration Guide" and really nothing else. If your CBIOS works and conforms to what's specified, you'll have no problems. Otherwise, you'll go bonkers with the distractions.

March 8th, 2015, 11:31 AM
You may be right, I've been doing a lot of walking, but I've also learned a bit about the code. I do look at the Alternation Guide and I believe that my code works. Yet you are probably right in that the CP/M should work and the real variable is my code. I'm hoping some of the trouble is the old media. I hope that all this 'walking around the barn' doesn't bug people too much. In order for me to trouble shoot, I need all the clues I can get. To that end,

I've looked at the directory buffer located at 114 360, 4C F0h, excepting to see the extents. The first byte is the user number, the next 8 are the filename followed by the extension. I had thought that the filename would be ASCII characters, but I can not recognize them as so. The DIR command of CP/M works everytime. I have added and removed files with 22DISK and each time DIR has correctly reported the files. Yet when I look at what I think is the directory buffer, I don't see ASCII. Thanks, Mike

March 8th, 2015, 03:09 PM
As a start, ensure that your CBIOS disk routines are always returning 0. Any other status will surely mess up CP/M. Secondly, make sure that your routines always detect errors when they occur. Saying that a read is good when it isn't, for example, will really mess things up. In other words, your disk I/O should be bulletproof.

March 9th, 2015, 12:12 AM
Myself and others (e.g. Epson) have written CP/M clones--it's not rocket science.

Interesting. Is there some alternative to CCP for 8080 CPU? I know there is ZSDOS but that's for Z80 CPU.

March 9th, 2015, 04:59 PM
Well..... I think I have found some of my trouble. Seems that the directory extents are being corrupted. I found the listings for some files that I had copied to disk, STAT and ED. They were on track 2 sector 1, Yet there was stuff (not 345, E5h) in other directory allocation blocks. It looks like code and it was in separate sectors. For example 4 10 12. So, I figured that my CBIOS was some how writing back to the disk. I reformatted the disk and installed the system. I then checked the disk with IMD to make sure that the directory allocation blocks were full of 345's and it was. In my CBIOS I added a beep routine to sound if a WRITE was called. I fired up the 8080 and loaded CPM, got the A> prompt, did a DIR, no beep. So, back to IMD to do another disk read to check the directory allocation blocks, they were empty, all 345's. OK, so then I fired up 22DISK to copy STAT.COM to the disk and try CP/M again. Copied the file, checked the directory and there is was. But just for grins, I fired up IMD again and checked the directory allocation blocks and there was the same code fragments. Somehow 22DISK is writing the corrupted directory sectors. So, I'm doing something wrong with 22DISK. Here's what I did. Start 22DISK, at the menu I press 1 for disk type. I select generic A1. Then I press 2 for disk name, A:. Then I pressed 4 to copy dos file STAT.CPM to A:STAT.COM. I then checked the directory by pressing 6 and there it is. Yet IMD shows that STAT.COM is all over the place. Seems that there is a problem with the interleave. In IMD, I format my disk, 26 sectors, starting with sector 1, 500K FM, 128 bytes per sector and 6:1 interleave. I then copy my system onto the disk. This disk works fine on my 8080 machine. I think I'm doing something wrong with the 22DISK program, but it is not obvious to me right now. Mike

March 9th, 2015, 05:30 PM
It's not obvious to me either; what version do you have?

For what it's worth, you can bypass the menu using the command line syntax; e.g.,

dtoc /A1 FOOF.CPM A:

(Assuming that you're transferring the DOS file FOOF.CPM to drive A:. Also, you do need to run 22DISK from hard disk using DOS or the Command Prompt mode of Windows 9X.

You can also format your disk using 22DISK from the command line. e.g.

cfmt /A1 A:

Will format disk A: with the A1 format. (It does verify as it formats).

You can get a directory with:

cdir /A1 a:

and copy from CP/M to DOS with:

ctod /A1: A: C: (if C: is your hard drive)

March 9th, 2015, 05:55 PM
I have 22DISK version 1.4. I'm running it on an old HP 8560 that only has DOS 6.22 on it. I have not formatted any disk with the 22DISK yet, I've always used IMD to format. I was wondering, I copied the CP/M utilities from my original CPM disk using the 22DISK. Could the original CPM disk be 1:1 interleave? But shouldn't coping back just look for the sector ID's and not just physical sectors? Is there a way to copy the files using IMD instead of 22DISK? Just trying to think of another way. Mike

March 9th, 2015, 08:55 PM
22Disk's format A1 is the same format as described in the Alteration Guide for the Intel MDS. 26 sectors of 128 bytes, physically 1:1 interleave, but logically (translation table) interleaved 6:1.

Here's the 22DISK definition for it;

BEGIN A1 Generic CP/M - SSSD 8"
SIDE1 0 1,7,13,19,25,5,11,17,23,3,9,15,21,2,8,14,20,26,6,1 2,18,24,4,10,16,22
BSH 3 BLM 7 EXM 0 DSM 242 DRM 63 AL0 0C0H AL1 0 OFS 2

Note that the SIDE1 line defines the "skew vector" and that unless specified by an INTERLEAVE statement, the physical interleave is assumed to be unity. The A1 definition hasn't changed since 1987.

March 10th, 2015, 06:28 AM
This morning, I tried to format one of my disks with 22DISK. This disk has been formatted with IMD many times and has had my CPM system on it and has worked fine in the 8080 machine. BUT 22DISK would not format the disk. I would get Hard error on track 0, then the same error on each track there after. So, I figured maybe I have a bad copy of 22DISK. I found a newer version 1.44 and copied that on to my DOS machine. Got it installed and tried to format the same disk. The new version gave me the same error Hard Error on track 0 but then gave up and returned to the menu. The disk would format fine on IMD. Mike

March 10th, 2015, 09:17 AM
So, what your DISKETTE.CFG file look like?

March 10th, 2015, 09:19 AM
Well, for whatever reason, 22DISK version 1.44 will not do anything with my drives. I found a version 1.42 and this works the same way as the 1.4 did. I tried a copy of ANADISK and this will format my disks, but I have not figured out how to copy from the 8" drive to C:\ and then back to different 8" disk. Mike

March 10th, 2015, 09:26 AM
Chuck, I have version 1.42 of 22DISK running right now. There is no file called 'DISKETTE.CFG'. I have


March 10th, 2015, 09:27 AM
1.44/1.45 is the latest working version and has been so for a couple of years.

Exactly how is your PC set up? Several hundred people have no problem with 22DISK. Something is definitely wrong with your copy.

The definition file should be "CPMDISKS.DEF", not CPMDISK.DEF. "STRIPID.EXE" is not one of our files, so I wonder if you have a hacked copy.

Contact me off-line. Let's see if we can get you set up with something working.

March 11th, 2015, 05:44 PM
Well.... today was a good day. With the help of Chuck(G), my 8080 and I made a couple more forward steps. I have the CP/M system up and running. I've learned a couple things about STAT and DIR (and 22DISK). I tried a number of options with them and have changed R/O and R/W on files. I've used ED to create a text file and saved it. Although, I'm having a little trouble with ERA. I had expected it to be an easy command, but it doesn't work as expected. I'm not sure whether or not the file has been erased. When I do a STAT *.* it lists the files and the last one is just a period, which I think the remainder of the disk, because it is big. At first it was marked R/0 and this kept me from making the text file, until I changed it with STAT and $R/W. But the ERA still puzzles me. I tried to erase my text file, with questionable results. Sometimes the command will just be taken as if it works, but a DIR will reveal that the file is still there. Yet when I try to open it with ED I get a BDOS error. Well, tomorrow is another day to putz with it. I'm at least 8 steps farther ahead than yesterday. Thanks Mike.

March 11th, 2015, 07:00 PM
If it helps, here's how ERA works.

It searches the directory for all files (and extents) matching the search pattern and rewrites them with E5h as the frist byte. Nothing more. This makes a CP/M unerase operation very simple--just change those E5s back to 00 or whatever user number they used. Reset the drive system so that the allocation information is re-read.