Lord Nightmare wrote:
The 2c33 can verify the CRC16, but you still read it off the disk like normal data. No weird tricks necessary (you can't seek backwards, btw).
So the crc16 is readable from the famicom/nes side? Interesting.
And by 'seek backward' I mean enable the motor right after it gets disabled and the head starts to swings back over the disk to the beginning, so the motor gets turned on and the gear re-engages before the head has fully retracted to the beginning, so you end up starting to read data somewhere random in the middle of the disk (I can't imagine this sort of shenanigans is good for the gears though, nor do I know if it will even work, there may be protections against the head re-engaging the motor unless it has fully retracted)
The CRC check is simple
Each bit read is passed into the CRC calculator of the 2C33.
When the 2C33 is instructed to seek the start of a new block, the CRC is reset to zero (0).
Once the CRC becomes non-zero the 2C33 will begin collecting data.
Normally the 2C33 is instructed to seek the next block within a gap between blocks.
While in the gap each bit read will be zero (0) and while the CRC is zero (0) it will have no effect on it.
The first non-zero bit in the stream will determine the start of a block.
A status flag ($4030.4) will also be set if the CRC is non-zero.
Data is read until the end of the block.
The block length in all cases is determined either by the block ID or by the previous block and two data bytes will follow.
The purpose of these two bytes are to bring the CRC back to zero.
If the status flag ($4030.4) is set after these two bytes are read, the CRC is non-zero and the read has failed (error 27)
Code: Select all
PROCEDURE update_crc(bit: Byte);
AND AX, 01H
XOR crc16, AX
SHR crc16, 1
SBB DX, DX
AND DX, 8408H
XOR crc16, DX
This is the correct
Since there is no standard block size, it is up to the software to determine if there has been a read error.