the odd thing is that only acts up in STOS. So there's something naughty going on in STOS.. But where... If AI can't trace through the entire STOS code base and find it, then no hope of me figuring it out !The issue is that your TOS patches shifted the BSS by $B32 bytes, placing _curkeytbl at $10EE. On the original TOS, _curkeytbl was at a different address. STOS writes to $10EE through some indirect path that we haven't been able to trace, but it only causes a problem because _curkeytbl now sits at that address.
Code: Select all
START → start
Cmdline → CMDLINE
exit → EXIT
Copy_Path → Copy_path
adapt+2 → Adapt+2
Extend → extend
name → NAME
I basically turned off the verify timing and started to get drive clunks which are not expected like it is having difficulty reading the track. So I have put the verify back in the floppy routines. Strictly speaking it should not be really needed but maybe the ageing drives even though "new", may need a little bit of extra time and help correctly read the floppy contents.The WD1772 seek command has two modes:
Without verify ($10) — the chip just counts step pulses to reach the target track and assumes it arrived correctly. Fast but purely mechanical — it trusts the stepper motor.
With verify ($14) — after stepping, the WD1772 waits for the disk to rotate and reads an ID address mark from the track to confirm it actually arrived at the correct track. Slower (up to one full rotation ~200ms) but guaranteed correct.
On vintage drives with well-worn mechanics and consistent step timing, no-verify works reliably because the stepper motor is predictable.
On new drives the step timing, head settle time, and track-to-track spacing may differ slightly from what the original hardware expected. Without verify the WD1772 has no way to know the head didn't quite land on the right track, so it starts reading and gets garbage data from the adjacent track — hence the clunk (retry seek) and "data may be damaged" error.
The irony is that the original TOS restore command ($00) does verify track 0, but regular seeks don't. Adding verify to regular seeks would fix the new drive issue at the cost of being slower — which is probably the right trade-off for reliability.
Trust me @exxos, the AI (which I assume wrote that content) has no idea what's talking about. For starters it is not exact that command $00 verify the track, it "only" verifies that the track zero sensor is activated.exxos wrote: Thu Apr 09, 2026 7:11 pm The WD1772 seek command has two modes:
Without verify ($10) — the chip just counts step pulses to reach the target track and assumes it arrived correctly. Fast but purely mechanical — it trusts the stepper motor.
With verify ($14) — after stepping, the WD1772 waits for the disk to rotate and reads an ID address mark from the track to confirm it actually arrived at the correct track. Slower (up to one full rotation ~200ms) but guaranteed correct.
On vintage drives with well-worn mechanics and consistent step timing, no-verify works reliably because the stepper motor is predictable.
On new drives the step timing, head settle time, and track-to-track spacing may differ slightly from what the original hardware expected. Without verify the WD1772 has no way to know the head didn't quite land on the right track, so it starts reading and gets garbage data from the adjacent track — hence the clunk (retry seek) and "data may be damaged" error.
The irony is that the original TOS restore command ($00) does verify track 0, but regular seeks don't. Adding verify to regular seeks would fix the new drive issue at the cost of being slower — which is probably the right trade-off for reliability.
You like to defend AI
I don't think that's what the AI was talking about that. Or at least, not only about that. AI was claiming that the track to track radial distance might have changed in newer drives, that's something completely different than the step rate. And that doesn't makes any sense whatsoever.I understand that TOS 2.06 uses 6ms step rate setting for HD drives, because it assumes the clock would be doubled when it steps, and then it would really step at 3ms. At least that's the idea, I believe.TOS206 defaults to 6ms for some odd reason. TOS104 defaults to 3ms.
It doesn't work that way. Drives don't exactly support a specific set of step rates. Drives require a minimum delay between individual step pulses. That means that any drive that supports 3ms step rate (as most "standard" 3.5 ones do), it automatically also supports any step rate higher (slower, like 6ms, or 12ms) than 3ms.As to what drives support what rates, I don't really care about TBH. Sony drives support both, but I use 3ms anway.
That, yes, but that was not what AI was claiming in the quote above.With my HD controller I set it on the fly depending on DD or HD. Its all really well known stuff and makes perfect sense to me. Its all really well known stuff and makes perfect sense to me.
I'm not sure how the verify step could help with the settling time. Settling time is usually not a problem. And if it is, then either the FDC will not find the sector header at all in the first revolution, but it will find it in the next one. Or if it finds the header but it provokes a reading error, TOS will retry once (or twice, don't remember for sure if this depends on the TOS version) before reseeking. Either way this would give plenty of time for the head to settle.I suspect the extra verify steps just give the heads more settling time which is why it works better rather than reseaking and verifying the actual track itself.
I never even read that part of what AI said to be honest.ijor wrote: Fri Apr 10, 2026 3:33 am You like to defend AI
I’m not disputing the specific technical corrections ijor made . Some details in the original AI quote were imprecise and got clarified, that’s fair.stephen_usher wrote: Fri Apr 10, 2026 10:32 am The issue is that if there are things that the AI is saying which are obviously wrong to those who are well versed in the subject how much can you trust the rest of the "information" it's giving you?
I think this is the point that Ijor is trying to make.