• Please review our updated Terms and Rules here

Retry on Error routine

Well, I had a modicum of success this morning. I changed my error code and used my error disk that has no sector #1 on the directory track. My CBIOS error code reported 'Abnormal Termination', on B: "Sector not found'. CP/M reported BDOS ERR on B: BAD SECTOR. So this part seems to work. So now I have to think of how to make the next error test. Mike
 
The next test I did was to completely remove the 1st directory track. This time my CBIOS error code reported 'Abnormal Termination', on B: "Sector not found' and 'Cylinder Address Error'. CP/M reported BDOS ERR on B: BAD SECTOR. The CP/M error message is the same. Doesn't differentiate between the two. They are both non recoverable so maybe it doesn't make a difference. I'll probably keep the CBIOS error report that I made. Hopefully there will not be many errors so it should not mess with me to much. Mike
 
The next test I did was to remove the disk from B: and in a separate test remove power from B:. Both of these resulted in similar reports. CBIOS error code reported 'Abnormal Termination', on B:, and "NOT READY'. CP/M reported BDOS ERR on A: BAD SECTOR. The CBIOS error actually occurred during the cold start loader run. I'm a little confused by CP/M indicating the error occurred on A: rather than B:. Have to think about that one. Mike
 
This time I removed the write protect tape from a good blank CP/M disk. This time CP/M reported that same error, 'BDOS ERR on B: BAD SECTOR', but my CBIOS reported different things depending on what was done. At first I had thought that CP/M would have report 'READ ONLY', but after reading about this, this only occurred when a STAT command set the disk as R/O.

When I did a DIR B: my CBIOS reported no errors.

When I tried STAT B: I got ABNORMAL TERMINATION and two DATA ERRORS from ST1 and ST2.

When I tried STAT B:*.* my CBIOS reported no errors, just like DIR B:

When I tried just logging B: I got ABNORMAL TERMINATION and two DATA ERRORS from ST1 and ST2.

When I tried PIP B:ED.COM = A:ED.COM I got ABNORMAL TERMINATION and two DATA ERRORS from ST1 and ST2.

So apparently the DIR B: and the STAT B: must not access CBIOS to look at B:?

Mike
 
Well...... all this testing led to my finding another bug, this time in my CBIOS. It also got me to thinking about how the 8272 FDC acts when a non recoverable error occurs. Seems when an error like 'sector not found' occurs, the FDC doesn't forget it. I was wondering does a recalibration of the drive which had the error also act to 'reset' the FDC for that drive? My documentation doesn't talk about how the 8272 handles errors very much, other that you should try a few retries after an error. Mike
 
I think what I meant to say was that if an error occures and the FDC is unsure of what track it's on, does it giveup? Do I need to do a recal on an error like this? Mike
 
If there's a seek error, yes--you should recalibrate.

Here's a very common read recovery sequence.

1. Try the last operation 3 times
2. Recalibrate, seek to the desired track and perform step 1 three times.
3. If step 2 fails, quit with an error passed to the BDOS.

Clearly, there's no benefit in retrying with no user notification if there's a "drive not ready" error or "write protect error", so those should be filtered out and the user given an opportunity to correct the condition and continue--or abort (just do a cold-boot as an abort). If you do a warm boot as an abort, the poor user gets in the "BDOS err: R/O" miasma at the command prompt.
 
OK, here's what I getting at, exactly, When the system is first booted, the cold start loader will do a Specify and the a RECAL on both drives. Then load the system and the jump to BOOT (COLD). If something happens, error, system hang, etc. and a control C is needed, a warm boot occurs. Should a RECAL to both drives occur during the warm boot? I would think that a problem that needs a restart should include a RECAL to both drives. Am I thinking right here?

The not ready and write protect are filtered out and a notice is given. But after an error I have some code that describes the status registers to give a more detailed idea of the error and then just return with the error flag set. The user (me) then has to look at what happened and probably do a control C. Mike
 
There's certainly no harm in doing a recalibrate. You could alternatively, simply set a flag in your code saying "recalibrate needed"--or simply set the cells that you're using to keep track of cylinder positions to a nonsense value, such as 255, which indicates the need for a recalibrate.

There are more elaborate recovery schemes. One such is this:

1. Step in 1 cylinder, then step out; repeat the read.
2. Step out 1 cylinder then step in; repeat the read.

The idea there is that if there's any "slop" in the positioning mechanism, the operation would be retried at both extremes of the "slop".

Error recovery can be made as complex as your imagination wants it to be.
 
So the 8272/765 FDC controllers are on the dumb side? About the only items they remember are the SPECIFY settings and the Present Cylinder Number. The PCN is reset after a RECAL. Am I correct in saying that for a SEEK, READ or WRITE, should an error occur during the execution phase, the appropriate bits are set in the Status Registers and they are read out during the results phase. The FDC gets all the rest of it's information off the disk, ID fields tell it what track, sector, etc.

What happens should a seek fail, and the FDC can't find a track? What would the PCN be then? A RECAL should be done then for sure.

I'm looking to redo my error code. I have some that works pretty good, but some seems questionable. More putzing and testing. My system and I are getting smarter all the time, Mike
 
Last edited:
PCN is little more than a counter; it has little to do with the disk contents. It reflects the physical position of the head carriage, as the FDC understands it (zero when the track 0 sensor is active; +1 for each step in and -1 for each step out). Whether or not the carriage is actually at the position, depends on the drive electromechanics.

So if a seek fails, you'll get a "sector not found" error (D2 in SR1). Some of the description in the Intel 8272A datasheet is just plain wrong; a seek is basically a simple mechanical operation--you don't even need the head loaded to do it--the same as if you tried to access a non-existent sector.

Things have to work that way, if, for example, you're trying to read a 360K disk in a 1.2M drive. You seek to twice the cylinder desired, which means that the only place that the NCN will match the ID headers on the disk is track 0.

You'll get a seek error if the track 0 signal doesn't come at the expected place. In other words, if you're at cylinder 5 and you seek to cylinder 0 and don't get an active track 0 signal from the drive.

You have to recall the vintage of the 765/8272--it's basically a 1978-vintage device originally intended for 8" drives. It's smarter than its WD 17xx counterparts, but not by much. For example, it will track the carriage position of up to 4 drives and will automatically produce the correct data (according to the map and gap data submitted) for formatting.

It's better than the immediate predecessors; the NEC 372 and the Intel 8271, but it's not a computer giant intellect. Like the x86 PC platform, after the 5150, the architecture was pretty much frozen--it was embellished, but the basic operating mode didn't really change.
 
You must log in or register to reply here.
Back
Top