It seems I have been giving the writers of DDOS too much credit. The long seek was being caused by DDOS issuing a seek command having not loaded the data register with anything. B-Em's 1770 emulation would attempt to do the seek but DDOS seems to rely on these seek commands doing nothing.
One case I was able to resolve by correctly implementing that the restore command (seek track 0) sets the data register to zero but there were others where the spurious value was coming from a previous read or write sector with no intervening seek to track zero. DDOS does issue a force interrupt after the seek so there seem to be two possibilities:
1. The 1770 is clever enough not to attempt the seek if it has not been told where to seek to. I suspect it does track whether the data register has been loaded with anything since the value was last used for something. This is not visible in the status register on type 1 command (seeks and steps), but I wonder if the status register is just exposing different parts of the internal state which remain, whether visible or not.
2. The force interrupt command is always issued fast enough that the head has not actually been stepped.
The other possibility is that it doesn't work correctly even on real hardware or a more accurate emulation, though I have not tested that. The problem only seems to appear if doing sustained disk access that moves the head around; I found it with my filing system tester, in particular a part that writes a file sequentially then reads it randomly and vice versa, comparing to make sure the data is correct. If the disc is allowed to spin down between operations then it wouldn’t appear as the seek back to track zero to re-read the catalogue would set the data register to zero.
One case I was able to resolve by correctly implementing that the restore command (seek track 0) sets the data register to zero but there were others where the spurious value was coming from a previous read or write sector with no intervening seek to track zero. DDOS does issue a force interrupt after the seek so there seem to be two possibilities:
1. The 1770 is clever enough not to attempt the seek if it has not been told where to seek to. I suspect it does track whether the data register has been loaded with anything since the value was last used for something. This is not visible in the status register on type 1 command (seeks and steps), but I wonder if the status register is just exposing different parts of the internal state which remain, whether visible or not.
2. The force interrupt command is always issued fast enough that the head has not actually been stepped.
The other possibility is that it doesn't work correctly even on real hardware or a more accurate emulation, though I have not tested that. The problem only seems to appear if doing sustained disk access that moves the head around; I found it with my filing system tester, in particular a part that writes a file sequentially then reads it randomly and vice versa, comparing to make sure the data is correct. If the disc is allowed to spin down between operations then it wouldn’t appear as the seek back to track zero to re-read the catalogue would set the data register to zero.
Statistics: Posted by Coeus — Fri May 23, 2025 12:31 am