The core of the disk emulator logic is a process that will start up with the first sector marker it sees while the disk is loaded and not currently seeking. This will generate the data and clock signals for every sector as it rotates past the virtual head, also keeping track of whether we are starting the header, label or data record of the sector.
Those data and clock signals will not be delivered over the interface unless the computer raised ReadGate. With ReadGate true, we pass along the signals to the computer as ReadClock and ReadData.
Thus, if the computer decides it is reading a given sector, it will turn on ReadGate and see the appropriate bits stream in. If it is an update operation, it sees the first record(s) using ReadGate and then starts writing by raising WriteGate.
When we see WriteGate go true, the separator watches for alternations of the WriteClockandData line, each such reversal is seen as a clock or a data bit, depending on the timing from when we see the very first transition.
A transition that occurs less than 500 ns after the prior clock transition is read as a 1 bit. This will be followed by another transition in much less than 600ns to represent the clock pulse ending the bit cell. If the transition occurs after a 500ns delay from the prior clock, it is the succeeding clock bit and there was a 0 data value in the bit cell.
Each bit cell injects the 0 or 1 bit value into the deserializer, shifting in to form 16 bit words. The deserializer signals when a word has been accumulated, so that it can be sampled by other processes.
When the disk is selected, loaded and WriteGate turns on, it begins a process to write one or more records in the sector. The continual read process tells us whether this is going to be the header, label or data record we are writing. We begin tracking the incoming words that the computer writes to us, looking for the words that will be stored into RAM at appropriate locations.
The write process drops zero bits, looking for a 1 bit that represents the sync word which begins a record. This is what actually syncs up the deserializer to begin informing us as words are ready for sampling.
After sync is achieved, we extract 2, 8 or 256 words, storing each in the RAM slot assigned to it for this sector. Meanwhile, we calculate a running checksum using bitwise XOR and a seed value of 0x0151.
Following the last data word of the record, we extract a checksum and verify that it matches the checksum we calculated. There is no way to reflect the error back to the processor, but we can flag it for our awareness.
After a checksum word, there is a stream of up to 4 words of zeroes, which tells us to drop sync and prepare to write the next record of the sector (unless we just finished the data sector). The deserializer drops the sync condition, ignores zero bits and waits for the first 1 bit to act as the sync word.
If WriteGate is dropped, we stop and go back to idle state. The read process continues to run at all times the disk is loaded, fetching the newly written words once the virtual platter rotates the sector back under the virtual head.
We always address RAM with the current sector number and the current value of the Head signal coming from the computer. The cylinder value that addresses RAM is initially zero and is updated by any seek process.
The seek process sits at idle until the disk is selected, loaded and the Strobe signal is activated. ReadytoSeekReadWrite goes false in 2.5 us and we wait another 27.5us before signalling either AddressAcknowledge (or LogicalAddressInterlock if the cylinder requested is >202).
The process calculates the movement distance based on the prior cylinder address and the value presented by the computer when Strobe is activated. We wait 600 us per cylinder plus 14400 us settle time, to model the physical seek duration on a readl drive. The process will then respond by returning ReadytoSeekReadWrite to true which signals completion of the seek.
There needs to be a mechanism to load or unload the virtual drive. When loaded, FileReady as well as ReadytoSeekReadWrite are turned on. Unloading waits until all in-flight actions such as seek or write are idle, then resets those two signals.
It is up to the user to load or fetch RAM contents to the PC while the drive is unloaded. The emulator will serve up whatever is in RAM as data or replace selected words during writes.
No comments:
Post a Comment