I had to do some deep thinking about exactly how to handle the case where I am updating an existing sector, which means that the header and optionally the label records are read, then the controller has to switch over to writing to write out the data (and optionally the label) record on the remainder of the sector.
This has two complications. First, the timing of the clock transitions when we begin writing are extraordinarily unlikely to match seamlessly with the clock transitions that were previously written on the disk. Second, the write pole is forward of the erase pole on the disk head, thus when we begin writing the space where we first write transitions has not been erased.
If the new clock transitions begin right after the previously recorded transitions of the postamble of the prior record, then will appear to be a 1 bit value and not a clock transition. Thus, if this happens at any time while the controller is trying to read, incoming data is corrupt. If it happens when the controller should be seeing a preamble of zeroes before the sync word, we get a false start to the record.
It takes about 2 microseconds for the erase pole to get to the point on the disk where the write pole had been when switched on. There will be remnants of the transitions written prior to this pass, until the erase pole reaches them. For that 2 us interval we may get false transitions.
There is no way to smoothly switch from reading old transitions at the end of one record and start writing the preamble of zeroes for a new record. If one were to look at a sector at the gap between one record and the next, when the latter record was written as an update, we would see:
- an interval of transitions every 600 ns, representing the postamble words of zeroes for the first sector
- an interval of 2000 ns when the erase and write gates are turned on
- the new clock transitions every 600 ns but not on the same schedule as the old transitions
- a few words of zero
- a sync word of 0000000000000001 to start the next record
One could just start new clock transitions right when the write and erase gates are switched on. If so, there is a 2 us interval where there may be confusing overlap of transitions. Alternatively, one could wait the 2us before issuing any transitions, so there is a gap with no clock transitions.
The Alto always works on word boundaries, so the way it handles this cutover is the first case, producing some overlapping but not synchronous clock transitions. When the sector is first written, there are five words of zeros after a record, called the postamble, then three words of zeroes as a preamble before the sync word that starts the next record.
To handle a switch from reading to writing between records, the alto switches off reading but counts three word times (still in the postamble) before turning on the write and erase gates. The next word, word four of the postamble, has its first 4 bits corrupted by the distance between the poles on the head, but is more or less where the original postamble word was placed.
The controller continues writing the last postamble word and the three preamble words, then the content words of the record. When reading the sector in the future, the read gate is turned off after reading each sector, then delayed 4 word times to make sure the head is well past the corrupted section before it begins reading preamble words looking for the sync word.
I will change my write logic to begin with clock transitions immediately after turning on the write and erase gates, since this is how the Alto handles the disk. The remnant transitions only occur during the first word of switch on, but all the reading logic ignores data for quite a bit of time past that point.
When writing the first record of a sector, the write and erase turns on and 34 words of zeroes are emitted before the sync word. When reading the first record, the controller waits for the equivalent of 21 word times before it starts reading the transitions - far far past the corrupted first preamble word.
Similarly, when writing a new record after reading a prior record, there are three postamble words from the original version of the record, one corrupted word and a final good postamble word. The preamble of three words is written too.
Thus, when reading a record that was 'updated', the delay of four word times puts the head past the corruption point and lets it see about four words of newly recorded clock transitions before the sync word.
I will make the change to how I start up writing a field, to create clock transitions immediately after turning on the write and erase gates. That will let me build the Update Sector FSM properly, according to the scheme described above.
No comments:
Post a Comment