• Please review our updated Terms and Rules here

Lazy 8" floppy disk question

The 765 has a read track operation. You might take a good disk and do a read track. Then take one that you tried to format and also do a read track. One can compare gaps and such that way. You might also take a look at the index signal from the drive. The Format instruction requires a clean index signal.
Dwight
 
The 765 "Read Track" operation looks for DAMs and just reads the data from index to index. So if you have a 16-sector track, you get "only" 16 sectors of data; no gap bytes, address headers, etc. As a matter of fact, the "Read Track" is useful for recovering data when the IDAMs are corrupted, because those are ignored.

You can "trick" the 765 into reading raw data after a fashion by giving the command a larger-than-actual sector size. Since the IDAMs are ignored, the sector size in the command overrides any recorded in the address headers. But you don't get any re-sync of the data separator on subsequent sectors after the first, so the remainder will probably be gibberish.

The WD 17xx/27xx is a true "read track" in that you get everything.
 
Chuck(G) said:
The 765 "Read Track" operation looks for DAMs and just reads the data from index to index. So if you have a 16-sector track, you get "only" 16 sectors of data; no gap bytes, address headers, etc. As a matter of fact, the "Read Track" is useful for recovering data when the IDAMs are corrupted, because those are ignored.

You can "trick" the 765 into reading raw data after a fashion by giving the command a larger-than-actual sector size. Since the IDAMs are ignored, the sector size in the command overrides any recorded in the address headers. But you don't get any re-sync of the data separator on subsequent sectors after the first, so the remainder will probably be gibberish.

The WD 17xx/27xx is a true "read track" in that you get everything.
Click to expand...

In other words useless. The NEC data sheet makes it look like it is reading all but I'll take your word for it.
Dwight
 
The Intel 8272 datasheet is essentially the same as the 765A. Note the command description on PDF page 9. There's all sorts of weird wording, but in essence, it's a continuous read starting at the index hole. Only the "N" (sector length) field and EOT (sector count) field really matter in the command. Sector data, if preceded by a correct DAM is read regardless and errors do not cause the command to terminate prematurely.

Yes, it's of marginal use. One of the gotchas is that it ignores physical interleave; it just reads the sectors as the occur, so that if you're looking to recover from a "sector not found" error, you have to match up the data from the sectors that you can read normally with the Read Track return and figure that the no-match(es) are the missing sector(s).
 
I hate to say it - most of what you are all discussing is way over my head.

'The Format instruction requires a clean index signal'

I gleaned from the above that the Format process needs a clean signal from the sector index sensor and associated logic? I made a start by cleaning the index opto sensors on both drives, primitive I know!

Dwight Elvey said:
The 765 has a read track operation. You might take a good disk and do a read track. Then take one that you tried to format and also do a read track. One can compare gaps and such that way. You might also take a look at the index signal from the drive. The Format instruction requires a clean index signal.
Dwight
Click to expand...
 
Do any of the following mean anything to any of you?

WP_20190319_22_06_55_Pro_LI.jpgWP_20190319_22_09_20_Pro_LI.jpgWP_20190319_22_12_28_Pro_LI.jpgWP_20190319_22_13_16_Pro_LI.jpg

If I try and format in single density, I get Read ID field Address Mark Error / Warm Boot Error - the drive (A: or B: ) seems to step to the first sector before displaying these errors.

If I try and format Double Density, the system locks up and needs a cold boot.

movcpm and sysgen results in the same error as well as Permanent Disk Error - possibly because I haven't managed to format a disk yet!

My drives work Ok with ImageDisk - I can read floppies to an image and write images to a floppy - resulting in working system disk copies. If I Format a disk in ImageDisk, the machine wont see the disk as formatted - I just get similar errors

I am willing to dig deeper with this - get to where I understand 'The 765 "Read Track" operation looks for DAMs and just reads the data from index to index' etc

Just thought i'd put everything on the table with shots of the errors I'm getting.

Thankyou All for your patience!

WP_20190319_22_13_46_Pro_LI.jpg
 
Chuck(G) said:
Also, make sure that the head-load mechanism is operating correctly. You should be able to hear the solenoid kick in when the drive is selected.
Click to expand...

Also make sure you have enough delay for track to track before you tell it to write. Reading is some what fault tolerant. It will usually wait until it gets a clean header an then read.
Step delay is usually something you have to set up.
Dwight
 
Dwight Elvey said:
Also make sure you have enough delay for track to track before you tell it to write. Reading is some what fault tolerant. It will usually wait until it gets a clean header an then read.
Step delay is usually something you have to set up.
Dwight
Click to expand...

Is step delay the same as write precomp? There are jumpers on the IMS 400 card that set a delay for write pre comp - it's set to 125 nanoseconds from the factory.

Hmmm, just read about write precompensation on Wikipedia - seems to be about the change in bit density the further towards the center of the disk you get - maybe something different to Step Delay. Ill have another read of the Shugart manual.
 
Last edited:
Chuck(G) said:
Also, make sure that the head-load mechanism is operating correctly. You should be able to hear the solenoid kick in when the drive is selected.
Click to expand...

The head load solenoids work on both drives, I can hear/see them in action.

I had to re solder the HL jumpers that where missing on the A: Drive logic board, now I've figured that out, I've got head load on both drives as of a few days ago.
 
No, it's not.

This is the mistake that I made with the first floppy driver I wrote a very long time ago. It would read just fine, but would corrupt the occasional write.

Here's the scoop--the head load/unload and the positioning mechanism are mechanical systems. As such, there are resonances that slowly decay with time. When the head is loaded or the head is moved, it doesn't settle down immediately and continues to vibrate a bit, jeopardizing contact with the medium. You have to build in delays in the area of 15-30 milliseconds for both.
 
Chuck(G) said:
No, it's not.

This is the mistake that I made with the first floppy driver I wrote a very long time ago. It would read just fine, but would corrupt the occasional write.

Here's the scoop--the head load/unload and the positioning mechanism are mechanical systems. As such, there are resonances that slowly decay with time. When the head is loaded or the head is moved, it doesn't settle down immediately and continues to vibrate a bit, jeopardizing contact with the medium. You have to build in delays in the area of 15-30 milliseconds for both.
Click to expand...

Some drives can settle the step in less than 5 miiliseconds. It is possible that your implementation has been set for a shorter delay. Delays are often done in software loops. Using faster processors without fixing delays can be an issue. You have to realize that with a software delay, the processor doesn't know it is running too fast. There is usually some information on your BIOS to tell you how to modify the delays. There is usually a delay for both head load and step, as Chuck mentioned.
I mentioned the index because when the LED interrupters get old, they can made some nasty flaky index signals.
Dwight
 
Fortunately, there was an 8253 PIT available, so I could precisely time my delays. I don't know if your system has a timer or not. Some old school stuff would incorporate one-shots for the delays, but if you've got a timer, so much the better.
 
The time delays and step time are set by the specify command.
This is the value 03h sent to the 765 controller. It would be followed by writes of 2 bytes :
1st byte:
bits D7 to D4 Step Rate in 1 ms increments 1 to 16
bits D3 to D0 Head Unload Time 16ms steps of 0 to 240 ms
2nd byte
bits D7 to D1 Head Load Time in 2 ms steps, 1 to 256 ms
bit D0 No-DMA

These are usually controlled by software in the boot BIOS EPROM.
There is a note that the specify command must be issued for each drive selected.
You need to look at the data in the EPROM and see where the specify command is written. It is likely that there is a table in the EPROM with all the time delays for the different drives selected. I would suggest that if you can find where in the code it writes the specify command that you modify both the set time and head load time to the maximum. You can then try to format again. If it works, you can try reducing it a little at a time. When it fails, add a couple counts and be happy.
It is possible that it has a table for each drive.
Dwight
 
You must log in or register to reply here.
Back
Top