OSI Floppy Test Program

You should know your computer memory is good before running this program. Available from osi.marks-lab.com tools. See TestMem.zip. Also Osiweb.org has a memory test for video-based computers.

The code V1.04 is on github here and as a zip file here. Mark made some improvement which I haven't had time to test but should be the best version to use. They are on his site and I have a local copy here. Floppy test 1.04u.zip

Load files for the OSI are provided. If you wish to reassemble use the A65 assembler from Mark's OSI software archive. The make_test file builds it for me under Linux. I have a script convser I used to make the serial load file. You can also use OSIALod from the above page.

This program is intended to work with an Ohio Scientific computer with either serial console or video board and at least 16k memory. If used the video board must support at least 64 characters wide. It has been tested on a C2 with 505 CPU, 540B video and serial console with SYNMONV1 ROM. If you run into problems and want to help debug it on other machines contact me at the link at the bottom of the page.

Loading the program

This program is intended to be run standalone. It uses zero page locations that will conflict with OSI operating systems. I have not looked at if it can be loaded by the operating system then run standalone.

For serial at the H/D/M prompt hit M and then upload the program over the serial port. Since the OSI echos each character you will need an upload program that waits for the character sent to be received or that can add delay between characters to prevent data overrun. Lowering the baud rate won't help since the sending slows down also. Sending with two stop bits may help. After loading is done type G to start the program running.

For video at the H/D/M prompt have caps lock on then hit M then L then upload the program over the serial port. I've been using a 505 processor card and the serial port on it. For other machines you will need to figure out how to upload the program. I think with video it's fast enough that it will keep up with the serial data. The program autostarts when loaded through the video monitor.

Running the program

If you ever need to stop the program just hit the reset button. You can restart by using the monitor to start execution at 0300. For video type M 0300 G. For serial type M G.

After it's started the program will then print HIT ANY KEY TO SELECT CONSOLE DEVICE. Hit a key and then you should get the main menu.

 OSI DESTRUCTIVE Disk Test
--------------------------
1. Test Disk
2. Test Track
3. Select Drive
4. Set Drive Type
5. Set Pattern and passes
6. Toggle read only
7. RPM Test
8. Status screen
9. Exit

Drv=A/8 Pattern $18  Passes 1 Normal test R/W > 

Note the 'DESTRUCTIVE' - do not feed it data you're fond of.

First verify the setting are correct. The last line says we are testing drive A which is 8" with pattern hex 18 and doing one pass with normal test in read write mode. Options 3-6 allow changing the settings.

Since I just finished this program and haven't done that much fault finding with OSI floppies some of the suggestions for problem causes may be wrong. Some is based on faults I have seen on other machines.

RPM Test

Probably the first test to try is 7 RPM test. It will print the minimum, maximum, and average RPM with the head loaded and unloaded. The SA800 OEM manual says that the index pulse should be 166.67 +- 3.33 ms. That is a 2% speed variation so RPM should be between 367.2 and 352.8. My drive reported the values below on the last test. For the average it hasn't varied more than .5 RPM. Head loaded is normally slightly less. If loaded is significantly less, likely either the floppy is going bad with the surface getting sticky or the drive belt is getting loose. I have had the drive belt start slipping in DEC RX02 drives. If the values vary significantly check the index sensor. If the 8/5.25 drive type is wrong the values will also be way off.
Head unloaded RPM: AVG   360.40  MIN  360.05  MAX  360.57
Head loaded   RPM: AVG   360.31  MIN  359.97  MAX  360.57

Status Test

This test allows you to see the drive status lines and set the drive control lines. It is useful for troubleshooting when things aren't functional enough to allow the other tests to run.

When first entered all bits should be zero. The track number printed is not accurate until you hit Z with the drive selected. Below is after hitting S to select the drive. The bits are the logic level of the signal. The actual signals are active low so low level = 1. The drive you have chosen should have RDY 1. If the heads are at track TRK0 should be 1. Hitting Z should move the heads to track 0. U should move the head to track 1 and TRK0 should go 0. D to move it back should set TRK0 back to 1. The program doesn't prevent you from stepping below track 0 or above the maximum track. I've heard that on some drives, this can affect the alignment so best not to do that. Index will go 1 occasionally. W will write all ones to the entire track until W is hit again to stop it. Both write enable and erase enable will be active. You can use test equipment to check the various signal lines.

CMDS:(S)el (H)ead (W)rite Step:(U)p (D)own (Z)ero (E)xit

R T F S R W S I
D R A E D R e N
Y K U C Y I l D
1 0 L T 2 T 1 E
    T     P   X
1 1 0 0 0 0 0 0  TRK  0  

Test Disk: Normal version

Select between scope and normal version with menu choice 5.

The main test is 1 test disk. This will first write all tracks with the specified test pattern then read all the tracks and print out if any errors are detected. It will repeat for the specified number of times. You can also select to only do the read test with 6 toggle read only. The disk for the read only test must have been written by this program.

For track without any error it will print.

RTRK ##     0
The last digit is the difference between the expected number of bytes and the actual number read. Missing bytes is negative. Reading more bytes than needed is not considered an error. Up to one junk byte found before the start of track byte will be silently discarded. If errors occur they will look like these:
RTRK 26 ----6 2618 18 0CP 2619 18 86P 2620 18 D5  2621 18 EDP 2622 18 FE   476
RTRK 61     0 2645 18 18P    1
The first line says we read 6 bytes less that we wrote. The first byte in error was byte 2618 and the expected value was $18 and the value read was $0C and it had a parity error. The error data will repeat for the number of errors that will fit on a line. Last value says 476 total errors were found on the track. The second line is an error in only one byte.

Seeing if the errors are mostly repeatable vs random and if they change each time the disk is rewritten may give clues to the error cause. Errors that repeat at the same location are likely media defects.

Test disk: Scope test version

Select between scope and normal version with menu choice 5.

The scope test version is intended to trigger a scope when an error is detected. The trigger will be a negative pulse on the fault reset line. The start bit of the word in error is around 76 to 86 microseconds before fault reset falling edge for my 1 MHz 505 processor. Faster processors will reduce the delay but not the 44 microseconds to shift in the serial byte.

The error printout in this mode is like this:

RTRK 26 2619 GOOD 18 BAD 58
Hit space to reread E to exit or other key to continue > 
This says that byte 2619 was bad with the expected value 18 and the value read 58. It also checks for parity errors but doesn't currently print if it got one so it's possible for good and bad to be the same if the error was in the parity bit. Only the first error is reported. My format is about .8 us delay from index rising edge to first byte written then 3600 bytes of data for 8" or 2167 bytes of data for 5.25. The first byte is always $5A and the second byte the track number starting at zero. The rest of the bytes are the specified pattern.

OSI uses a non standard disk format with the data read and written with a UART and the drive having an on board data separator. My test uses 8 bits even parity 1 stop bit. If you want to know detailed information on the OS-65D format see the Compute's Gazette 20 and 21

Serial data idle level is a 1/high with the start bit 0, the least significant bit sent first and parity after the 8 data bits. The last bit is a stop bit which is a 1.

First find the start bit. Picking a visually distinctive test data pattern helps. I find what I think is the start bit for the error then back up and verify the previous byte is the expected test value. The data value reported by the OSI should match the output of U4-12 clocked by U4-13 unless there is a hardware problem. Interpreting the U4 signals is shown in the second picture below. The output of U4 may not match the clock and data from the drive in the top traces. If they don't match the one shot timing should be checked. The U numbers will vary based on the board but the circuity is similar for all OSI disk interfaces I have seen.

This shows the data value $f3 as read from disk. $f3 is 11110011 binary. Since the value is read least significant bit first from left to right on the scope it will be seen as 11001111. The serial data always starts with a 0 bit. After the 8 data bits will be a zero if there were an even number of ones in the data. In this case there are 6 ones so the parity is zero. The last bit is the stop bit and it's always a 1. U4-13 is the clock bit to the UART and U4-12 the data bit. The state of U4-12 when U4-13 goes high is the value the UART will see. It can be different than the bits you see from the drive clock and data bits due to the OSI using one shots to generate the UART clock and data. If the zero is too far from the clock the one shot will time out and the data bit will be received as a one. The second zero in the data is close to this condition. Click on picture for full size.

This picture shows a couple errors. The data reported by the OSI was $fb which is 11111011. You can see the two zero data bits were received ok from the drive same as the previous capture. I have marked the data bits generated by the one shot feeding the UART. You can see the second zero bit is now a one matching what the OSI reported. The parity is a zero since it is correct for the 6 ones written. With the 7 ones received it would generate a parity error. Where I marked clk you can see we are missing the clock for the one stop bit. It got converted to a zero data bit by the data separator in the drive. This would generate a framing error in the UART. My code doesn't check for that error.

In the above capture it is hard to see that the data changed before the clock. This is zoomed in to show this. The slowest speed of the MC6850 UART datasheet specifies 250 nanosecond (ns) setup and hold time so if the clock transitions within 250 ns of the data transition it is not guaranteed if it will read the old or the new data value.

More examples of read data errors and some troubleshooting information

Test track

Same as test disk but only tests the selected track.

Amplitude check

I wrote a script to use my scope to measure the read amplitude on each track. This is more of a proof of concept than finished code at this point. It uses the status screen to control the reading. It uses the write function to write the entire track with zeros. I ran it on a disk that had one track that was known to be marginal. This graph shows two test passes graphing the maximum and minimum voltage on the track. It uses a 25 sample sliding window for the minimum and maximum values. The bad track was picked up on the two reads with amplitude of 0.26 and 0.30 volts. There are larger variations between the two reads on other tracks than I was expecting so this may need more work or the drive/disk has noticable variation. The next lowest amplitude was 0.44 on the one read and 0.52 on the next. You can also see the amplitude drops as you go towards the inner tracks where the radial velocity is lower. X is track and Y is voltage.

The code is here



Feel free to contact me, David Gesswein djg@pdp8online.com with any questions, comments on the web site, or if you have related equipment, documentation, software etc. you are willing to part with.  I am interested in anything PDP-8 related, computers, peripherals used with them, DEC or third party, or documentation. 

PDP-8 Home Page   PDP-8 Site Map   PDP-8 Site Search