Mega STe differences ?

[christos]

It's probably the hddriver cache size. Try lowering it.

[npomarede]

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.

Hi
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")
Nicolas

[ijor]

Hi Nicolas,

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")

Hmm, is he using STEP with verify? Troed? I thought we were talking about Seek with verify, not Step. Step with verify would be very slow.

Anyway, something is wrong. Step rate should be the same as the one used by TOS and by any other program. There is no reason why your drive would fail only in this case, not for this reason. Either the step rate bits get corrupted and then the program attempts to seek at 2ms step rate, or probably the issue is something else.

[npomarede]

Sorry, this was not detailled enough. This is what happen when 2nd part of the demo is loaded using direct FDC accesses (1st part is loaded using TOS calls) :

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
...

On my STF, this will fail after a few tries (giving a red screen + crash)

The fixed version does this (ie : same but with verify bit set) :

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


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.
Note that the timings are those from Hatari, on my real HW they might be different to make the loader fail.

Nicolas

[ijor]

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.

Unlikely. The Restore command will keep stepping out until sensing the track 0. That's before any verification. So even if some step pulses are missed or are too fast, it still should reach track 0. And the verify bit won't change anything. If for some reason it didn't reach track 0, then the verify bit won't help unless you manually retry if verify fails.

Code: Select all

fdc type II read sector sector=0x1 multi=off spinup=on settle=off

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]

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.

That's interesting, as the disk is already spinning due to the restore/steps, then the next read sector with spinup=on will skip the spin up phase and I thought the sector would be read correctly.
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" ? (under emulation, settle will add a delay or not, but it won't do anything more)

Nicolas

[ijor]

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" ?

Yes, more or less. It isn't exactly that it needs finer adjustment, it's that the head might be vibrating and swinging right after stepping. Hence the term "settle".

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.

This is, of course, assuming that the problem is indeed settle time, which I can't be 100% sure.

[troed]

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.

Nicolas got one of the 10 physical discs uniquely written one by one by my deployment system, which is how Closure was distributed The layout should be Fastcopy "interleaved" 80/9.

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?

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 ...

[npomarede]

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.

As troed wrote, I had the problem with the floppy he duplicated himself and sent me by postal mail.
But I also tried to format a standard floppy on my PC and then to write the .ST images on this disk to be sure it was not the floppy itself (similar to "dd" command under linux)
It fails in both case, but of course it might be because when formatting on my PC I had a gap layout similar to the one Troed got with fastcopy on his ST.

[ijor]

Nicholas got one of the 10 physical discs uniquely written one by one by my deployment system, which is how Closure was distributed The layout should be Fastcopy "interleaved" 80/9.

I see. So may be it is his drive after all, although no necessarily a slower settle time. Note that distributing physical disks, all with the same layout might hide some problems that could appear only when somebody else make his own disk with a different layout. You should perform some tests with a different one, just to be sure.

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 ...

Then you might try v1.2 with the fixed retry logic but without the verify flag Anyway, if you insist on using the verify flag, it should be better to use Seek and not Step. The effect of using Step with verify is increasing the step rate unnecessarily.

Just out of curiosity, any other fix/enhancement in v1.1?

[troed]

Just out of curiosity, any other fix/enhancement in v1.1?

512KB check in boot sector
Mega STE compatibility
8.05MHz compatibility
Nicolas' floppy drive not loading (rewrote FDC code)
Fix writer-blanking lines glitch

... the reason it wasn't released is that I had one final thing I wanted to do as well and failed Then I started doing other stuff.

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.

[troed]

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. And since Closure sync locks to HBL (thanks for that ) it was quite critical.

[ijor]

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.

Strange. How are you retrying? Are you just issuing another read sector command, or are you reseeking to the correct track? You should do both in sequence. If you don't reseek then this obviously won't solve a failed seek. But reseeking immediately on every failure isn't correct either. Because then, if you have a timing problem (as not enough settle delay), then you will repeat the same timing and it might never work. So you should first just reissue the FDC command, once or how many times you want. And if that also fails, only then restore and seek again.

Can you please PM me version 1.1?

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.

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.

[czietz]

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.

This is because in the MegaSTE the interrupt handling has been significantly changed to allow for the VME bus. It reuses the SCU from the TT to allow (among other things) VME cards to also raise interrupts of all priority levels. Interrupts from the VME bus and from the Atari itself can be separately masked by the SCU.

EDIT: I find this schematic better readable than the version on dev-docs.org: http://gossuin.be/images/schemasatari/MEGA%20STE.pdf