Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team
ijor wrote:troed wrote:Orion_ wrote:where mine was $13, missing the "verify" bit, I guess that might be an important bit I was missing
Yeah that's the one I had to add to get Closure to load on Nicolas' drive.
Seek with verify it's usually not needed. It might suggest some kind of timing problem. May be you were not waiting for settle time? Also the FDC spin-up logic is a bit tricky and ill designed. It is not that difficult to get into a situation that you are trying to read a sector when the drive still didn't spin up and you don't know.
Was that on Nicolas's DRIVE, or on Nicola's computer? Yeah, I know it probably was both. But the question is if you could isolate the problem was on the drive and not on the computer.
npomarede wrote:Can't tell the difference, because this STF only has 1 drive, so it's hard to check if it's the drive or the STF ; maybe with a standalone loader program that tries to load the demo from drive B I could try the same floppy on an external drive on the same STF.
Depending on the result, it would tell if it's the STF itself or the drive (my guess could be that some "step" are too slow to be executed on the drive (or the loader program is sending them too fast) and one of them get lost when verify bit is not set, so in the end the physical head is not on the expected track when doing "read sector")
Code: Select all
fdc type I seek dest_track=0x2 spinup=on verify=off steprate_ms=3 drive=0 tr=0x2 head_track=0x2 VBL=209 video_cyc=7492 324@14 pc=fc160a
...
fdc type I restore spinup=on verify=off steprate_ms=3 drive=0 tr=0x2 head_track=0x2 VBL=1188 video_cyc=3268 196@6 pc=676
fdc type I step in spinup=on verify=off steprate_ms=3 drive=0 tr=0x0 head_track=0x0 VBL=1239 video_cyc=11736 472@22 pc=6d2
fdc type I step in spinup=on verify=off steprate_ms=3 drive=0 tr=0x1 head_track=0x1 VBL=1239 video_cyc=36756 404@71 pc=6d2
fdc type I step in spinup=on verify=off steprate_ms=3 drive=0 tr=0x2 head_track=0x2 VBL=1239 video_cyc=61776 336@120 pc=6d2
fdc type II read sector sector=0x1 multi=off spinup=on settle=off tr=0x3 head_track=0x3 side=0 drive=0 dmasector=1 addr=0x10000 VBL=1239 video_cyc=87476 436@170 pc=85c
...
Code: Select all
fdc type I seek dest_track=0x2 spinup=on verify=off steprate_ms=3 drive=0 tr=0x2 head_track=0x2 VBL=215 video_cyc=107256 248@209 pc=fc160a
...
fdc type I restore spinup=on verify=on steprate_ms=3 drive=0 tr=0x2 head_track=0x2 VBL=502 video_cyc=3196 124@6 pc=9e8
fdc type I step in spinup=on verify=on steprate_ms=3 drive=0 tr=0x0 head_track=0x0 VBL=553 video_cyc=70652 508@137 pc=a44
fdc type I step in spinup=on verify=on steprate_ms=3 drive=0 tr=0x1 head_track=0x1 VBL=554 video_cyc=67456 384@131 pc=a44
fdc type I step in spinup=on verify=on steprate_ms=3 drive=0 tr=0x2 head_track=0x2 VBL=555 video_cyc=64512 0@126 pc=a44
fdc type II read sector sector=0x1 multi=off spinup=on settle=off tr=0x3 head_track=0x3 side=0 drive=0 dmasector=1 addr=0x10000 VBL=556 video_cyc=62008 56@121 pc=c2c
npomarede wrote:The 1st seek is made by TOS at the end of loading 1st part, then custom loader does a restore+steps.
Maybe the restore without verify doesn't properly go to track 0, then following "steps" will be on the wrong track too.
Code: Select all
fdc type II read sector sector=0x1 multi=off spinup=on settle=off
ijor wrote:That might be part of the problem. Settle delay is not enabled and the sector might not read correctly. It shouldn't be fatal if retry would be performed properly, but forcing read errors under emulation it seems there is some kind of bug at the retry logic. Troed?
If step with verify is enabled, then that would compensate for the settle delay being disabled.
npomarede wrote:Do you mean that if settle is off then even if the WD1772 encouter the index for sector 1 then the index CRC or the data CRC could be wrong and an extra revolution (or more) could be needed to read the sector correctly ?
Physically, does it mean that the head is not correctly positioned after 'step' and settle is needed to adjust it "finely" ?
ijor wrote:Note that it doesn't necessarily means that your drive has a slower settle time. This might depend, among other things, on the utility you used to write the ST/MSA image and how the sectors are physically laid out on the track.
ijor wrote:That might be part of the problem. Settle delay is not enabled and the sector might not read correctly. It shouldn't be fatal if retry would be performed properly, but forcing read errors under emulation it seems there is some kind of bug at the retry logic. Troed?
ijor wrote:Note that it doesn't necessarily means that your drive has a slower settle time. This might depend, among other things, on the utility you used to write the ST/MSA image and how the sectors are physically laid out on the track.
troed wrote:Nicholas got one of the 10 physical discs uniquely written one by one by my deployment system, which is how Closure was distributedThe layout should be Fastcopy "interleaved" 80/9.
ijor wrote:There is retry logic, but it might be that it was buggy in v1.0 and corrected in v1.1 (which additionally has the verify flag on). Of course, while v1.1 has been implemented for almost a year I haven't released it yet ...
ijor wrote:Just out of curiosity, any other fix/enhancement in v1.1?
troed wrote:I just diffed the DMA floppy code between v1.1 and v1.0 and indeed I had rewritten quite a lot it seems. But your info here has made things quite a lot clearer so I'll revisit it. edit: Only the fixed retry code didn't solve it, it really was the verify flag that got it working. However, I never looked at settle.
Btw, the Mega STE incompatibility was caused by behaviour I haven't seen anyone describe before. Autovector interrupt timing (HBL) is different on Mega STE compared to STE ... 8 cycles difference I believe it was.
ijor wrote:Interesting. I don't know much about the MSTE. But looking at the schematics it seems (some pages are barely readable) that VPA and the IPL signals are not handled by GLUE anymore. Possibly ACIA access timing is affected as well, not only autovector interrupt timing.
Users browsing this forum: No registered users and 2 guests