Mark,
I'm impressed with how you found that 34 bytes were truncated from the 8th sectors. But I'm wondering: can a sector continue past the index hole into the start of the "next revolution" of the disk? 34 bytes would take 34 * 88 = 2,992 microseconds, which is more than the 1 millisecond delay there supposedly is between the index hole and the track header. But I'm not sure how long the index hole itself lasts for (I haven't been able to find anywhere what the angular size of the index hole is supposed to be), nor if that 1 msec delay is the right figure for 5.25" diskettes.
If there were a few bytes going past the index hole, I presume the .65D format would simply include them without any indication of that. Still, I'm wondering how WinOSI handles requests to read bytes from a track after the designated end of data on the track has been reached. Not because of things like these FORTH tracks, but for things like some versions of the DI (sector directory) command. Will it start from the beginning of the track again? I think it doesn't and (correct me if I'm wrong) will hang waiting forever for the RDRF bit to go high. If that's the case, can that be changed?
Compute's Gazette #20 Jan 1982 p136 &
Part 2 #21 have a very detailed description of actual OSI disk timing. It varies greatly from what OSI states. I believe it shows that 8 single-page 65D sectors on a 1MHz will not fit on 5.25" track with actual timing.
As you state - the disk rotates, the index hole comes into view & index goes active, then as it passes goes inactive again. This is the edge that all later OSI code use to start the sector timing. Supposedly delaying at least 1ms before starting writes. But how long is the index active? 5ms? SA800 says 1.7ms +/-5ms, SA801 says 0.4ms +/- .2ms. I can't find Ed's original RawDump code, but all the ones since 2004 stop reading a track when the index is active.
As a test I modified the disk dump read code to include the area "under" the index hole for the FigForth disk I have, but was unable to retrieve any more valid data. I just got a series of $01s, which in itself was unexpected (perhaps leftover MFM data from PC formatted blank?).
I'm not sure how FlashFloppy handles the index signal at all! The virtual disk creates the index signal, but it's unclear if anything in the track image starts the index or if it just starts before the track data is clocked out, or if it's just a fixed duration at the start of data(my assumption).
I recall some OSI disk write code checking for reassertion of the index signal during write and exiting the write code, but the code in the disassembly of OS65DV3.2 shows it only waits until the next byte is accepted and does no other checking. It will try to verify what it wrote though. (Perhaps I saw that in one of the other OSes?) Anyway it seems possible that OS65D writes "under" the index hole. Perhaps the disk dumper needs to read through index activation?
So for "RawRead" it fills the buffer with zeros, then starts saving all the data from the time the index ends until it is active again. Depending on the disk this could be 0 or up to 2.2K of data. One change I made was to include a "high water" mark at the end of the track buffer to indicate the last byte read. This value is used in WinOSI to stop clocking out bytes on virtual tracks, otherwise all the extra zeros in the disk padding would keep streaming out.
So eventually the index comes around on the virtual track in WinOSI, it passes, and then data becomes available again and the track is replayed. At least that is how it should work. There have been a few bugs when the high water mark was added that broke things for a while. DI should work in the current version, or at least in the version I'm working on
So on OS65D, during boot there is code at $2E84 that gets called which measures the 60Hz clock from the OSI540 board by testing the high bit of $DE00 & counting loops. For 1Mhz or no detection you get a value of $31, for 2Mhz ~$62 and so on. This "NMHZ" value @ $267B changes some of the time delay values used on OS65D. So does the C1P use 1Mhz timing for any CPU frequency? I don't think it has the equivalent clock. Also is there any programmatic way to detect a series II 600D vs original 600?
You can detect the amount of CPU clocks needed to clock out bytes of the disk ACIA & determine CPU speed, but an 8" disk on a 2MHz machine looks a lot like a 5.25" on a 1Mhz machine ACIA-wise. Further testing drive characteristics could identify machine configurations programmatically.
The other unique clock is the 400ms 5.25" or 1sec 8" clock connected to CB1 on the disk PIA. But do all disk controllers have this strapped?
davisgw,
You should be able to successfully dump any disk image that works on your C1P without errors using disktool or the older OSIDump even if you are having write problems with the disk image in disktool. (Unless data is being written to the hidden area under the index hole)...
Please "ZIP" up posted images to ensure data integrity. It will be interesting to see what you've made!