• Please review our updated Terms and Rules here

How does the TRS-80's floppy controller distinguish ID fields from user data?

B

bradr

Member
Joined
Feb 7, 2020
Messages
15
Location
Sydney, Australia
Hey All,

I'm looking into adding support for floppy disk support for my FPGA TRS80 project and as such have been reading over the docs for the WD1771 disk controller and have a question.

At the end of page 3 of the data sheet it says this:

"When a Seek, Step or Restore command is executed an optional verification of Read-Write head position can be performed by setting bit 2 in the command word to a logic 1. The verification operation begins at the end of the 10 millisecond settling time after the head is loaded against the media. The track number from the first encountered ID Field is compared against the contents of the Track..."​

What exactly is the "first encountered ID Field"? I'm wondering how the controller locates/recognises the ID field and what would prevent a similar pattern of bytes in the user sector data from tripping up the controller and getting an invalid field?

I can understand how this could work if the controller waited for the index hole, then decoded the track from the start, but this sounds like the head is simply moved to the new track and reading could start anywhere in the middle of the track. How does it know it's really a ID Field?

Any help appreciated :)

Brad
 
The data actually written to the floppy contains both clock and data information. "Regular" data bytes are written with a clock pattern of all 1's, while Address Mark bytes are written with 'missing' clock bits. The data separator (internal to the WD1771 - if you're using a standard expansion interface) is responsible for extracting the clock vs data bits from the signal coming from the disk read head. This is somewhat described deeper in the datasheet. For example, see page 13.

Short story is that the controller can identify ID and Data Address Marks in the data stream (vs user plain old user data bytes). So it doesn't have to wait for the index hole to come back around.
 
Ah ok, I think I get it... so when the track is written, those special byte marks (index, id, data marks) are recognized and certain clock bits dropped so they can be distinguished when read back. Clever.

The "formatting the disk" section of the data sheet makes a lot more sense now.

Thank you!
 
You must log in or register to reply here.
Back
Top