Cannot enter setup utility/boot issues

[bleggett]

I've tried with both stable and 3.1 branch.

I cannot get the setup tool to show up reliably (basically, the device to correctly boot) no matter what acsi2stm.h setting I tweak.

ACSI_ACK_FILTER, ACSI_CS_FILTER, ACSI_FAST_DMA 0 or 1

The odd thing is that sometimes (thus far, 2-3 times) I can get the ACSI2STM to boot into the setup util successfully. However, even if I change nothing, and simply rebuild and reflash the device, it stops booting into the setup util.

Usually what I'll see over serial is the normal device boot logs, then some attempt at DMA transfer, then an immediate Quick Reset, eg

20:32:15.683 -> DMA send (512 bytes): 10 7 41 FA 0 C6 EA 8 D1 10 48 7A 0 4C 3F 3C 0 9 4E 41 5C 8F 2F 3 26 38 [...]
20:32:15.730 -> 
20:32:15.730 ->  -- Quick reset --
20:32:15.730 -> 
20:32:15.730 -> Waiting for the ACSI bus ...

I see more extensive transfers when the setup util boot actually works.

Not sure why I keep seeing Quick Reset after initial DMA transfers.

[bleggett]

I'm going to try and get serial log dumps from both the success and fail runs.

[retro16]

Hi, Thanks for the feedback.

If recompiling changes behavior more or less randomly, it looks like the hardware bug of the STM32 I'm currently fighting in 4.0 development. Can you try 4.0c ? 4.0 doesn't have the setup anymore and GemDrive isn't ready, so you have to use a SD card or an image with an Atari driver already installed (such as ICD or PP).

[bleggett]

Trying with an image on the SD card and the latest 4.0d release.

19:24:20.232 -> ACSI2STM SD bridge v4.0d
19:24:20.232 -> 
19:24:20.232 -> SD0 36MHz 62685184 blocks rw
19:24:20.309 -> Waiting for the ACSI bus ...
19:24:20.435 -> --- Ready to go ---
19:24:21.667 -> 
19:24:21.667 -> 
19:24:21.667 ->  -- Quick reset --
19:24:21.667 -> 
19:24:21.667 -> SD0 36MHz 62685184 blocks rw
19:24:21.667 -> Waiting for the ACSI bus ...
19:24:22.151 -> --- Ready to go ---
19:24:27.202 -> [0:8][<0][<0][<0][<1][<0](6 bytes)
19:24:27.202 -> Read 1 blocks from 0 on SD0
19:24:27.202 -> DMA send (512 bytes): EB 58 90 4D 53 44 4F 53 35 2E 30 0 2 20 7E 8 2 0 0 0 0 F8 0 0 3F 0 FF 0 0 0 0 0 0 80 BC 3 C1 3B 0 0 0 0 0 0 2 0 0 0 [...] OK
19:24:27.202 -> Success
19:24:27.202 -> [>0]
19:24:27.202 -> [1:8] - Not for us
19:24:27.278 -> [2:8] - Not for us
19:24:27.325 -> [3:8] - Not for us
19:24:27.371 -> [4:8] - Not for us
19:24:27.418 -> [5:8] - Not for us
19:24:27.464 -> [6:8] - Not for us
19:24:27.511 -> [7:8] - Not for us

this is the log I get.

Image doesn't boot or show up, I've tried various delays and settings as before.

Wonder if I just have a crappy DMA chip or something.

[retro16]

Aha ! 4.0d has a trick up its sleeve: do you have a way to transfer ACSITEST.TOS found in the release package onto a floppy (or any other working drive) and run it from the ST's desktop ? The tool will ask for the ACSI ID (usually 0) and runs a few tests. I will need the log output of the ACSI2STM during the test, as well as the amount of tests that were successful/failed. If all tests work okay, please do a buffer test ('B' key after the normal tests finished) for a few minutes (don't need the log for this one), and a surface test with an unimportant SD card ('S' key, this may corrupt the SD card's data in some rare cases).

Also, can you tell me what driver/image you are using ? If you used a publicly available ready-made image, can I have a download link (or search terms for Google if the image isn't 100% legally clean) ?

Given the results, I may ask a few more things to have a precise idea of what's happening.

Thanks a lot for your help, quality feedback like this really supports the project.

[bleggett]

Aha ! 4.0d has a trick up its sleeve: do you have a way to transfer ACSITEST.TOS found in the release package onto a floppy (or any other working drive) and run it from the ST's desktop ? The tool will ask for the ACSI ID (usually 0) and runs a few tests. I will need the log output of the ACSI2STM during the test, as well as the amount of tests that were successful/failed. If all tests work okay, please do a buffer test ('B' key after the normal tests finished) for a few minutes (don't need the log for this one), and a surface test with an unimportant SD card ('S' key, this may corrupt the SD card's data in some rare cases).

Sadly, I do not (yet) - it's a 1040 STF (originally shipped with 6-chip TOS 1.0, I upgraded to TOS 1.04) and the floppy drive as is common is DOA with a (physically busted) head. I have another 1040 arriving soonish I can cross-test with, and I plan to eventually replace the floppy drive in this one with a Gotek or similar, since it is unfortunately beyond fixing.

Either way, will update you when I can try with ACSITEST.TOS, one way or the other.

Also, can you tell me what driver/image you are using ? If you used a publicly available ready-made image, can I have a download link (or search terms for Google if the image isn't 100% legally clean) ?

Using the 1GB image mentioned in the first post here, which AFAIK should work just fine? https://www.atari-forum.com/viewtopic.php?t=41008

Given the results, I may ask a few more things to have a precise idea of what's happening. Thanks a lot for your help, quality feedback like this really supports the project.

Sure thing. Like I said, only I have one (relatively early model) 1040 with a busted FD ATM, but I'm interested in helping where I can, I know this stuff can be pretty trial and error (and Atari ST DMA seems to be historically problematic)

[retro16]

Oh no, that dreaded free PP driver. It does something wrong with the A1 line at boot, so it doesn't work as-is with 3.X nor 4.X.

4.0e will have a workaround, I had one a long time ago in 2.x firmwares, but it was hit or miss. Now that the ACSI implementation layer is much cleaner than it was back then, it should be possible to implement the workaround correctly.

A workaround is needed anyway, because TOS 1.00 also exhibits the same bug, and you swapped yourt ROM chips, but not everyone can/wants to do that to their ST.

[bleggett]

Oh no, that dreaded free PP driver. It does something wrong with the A1 line at boot, so it doesn't work as-is with 3.X nor 4.X.

4.0e will have a workaround, I had one a long time ago in 2.x firmwares, but it was hit or miss. Now that the ACSI implementation layer is much cleaner than it was back then, it should be possible to implement the workaround correctly.

A workaround is needed anyway, because TOS 1.00 also exhibits the same bug, and you swapped yourt ROM chips, but not everyone can/wants to do that to their ST.

I will try a few more images/drivers later and report back if that changes anything, thanks!

[bleggett]

I was able to get some activity via GEMDRIVE mode, weirdly enough.

It's very intermittent though - on some boots, it hangs on the ACSI2STM splash screen:

On others, it gets to desktop but seems to randomly freeze on file access.

I did manage to launch ACSITEST a few times - it failed every time.

[bleggett]

I'm wondering if maybe I have a bad RAM chip or something and it's not related.

[retro16]

GemDrive disables ACSI to avoid conflicts with other drivers, so it's expected that ACSITEST doesn't work in this mode. The last screenshot is correct.

However, the unstability you get is not normal. GemDrive is still alpha at this point, but it's only filesystem operations doing wrong things: During my tests it proved to be very stable in the sense that it always behaves the same (wrong) way. Starting simple programs at the root of the SD card should work 100% of the time.

This indeed looks like hardware issues, whether it's the blue pill, the ST, bad RAM, bad capacitors, bad connections, ... it's virtually impossible to debug this kind of issue remotely (or at least it's something I'm unable to do).

[retro16]

FYI, I just pushed a pre-version of 4.0e with the workaround for ACSI mode in the master branch. ACSI mode is probably final in the master branch, remaining work is only for GemDrive but I won't release 4.0e as a beta as long as there are important issues / missing features in GemDrive.

[bleggett]

This indeed looks like hardware issues, whether it's the blue pill, the ST, bad RAM, bad capacitors, bad connections, ... it's virtually impossible to debug this kind of issue remotely (or at least it's something I'm unable to do).

Yep makes sense.

I'm gonna get a diagnostic cart and run some tests, and will try this on an STE when I can.

Thanks for the help!

[bleggett]

Well good news - I flashed 4.0e and it works!

(I did enable ACSI_STRICT in acsi2stm.h but otherwise changed no other consts)

SD card insertion detection seems a bit fiddly which could be my solder joints, but I can boot images!

Works in the 1040 ST/1.04 TOS and seems to work in the 1040 STE / 1.06 TOS as well.

Successfully booted both ICD and PPD images as well.

[bleggett]

FWIW GemDrive so far also seems to work reasonably well. There is at least one HDD conversion game (Total Eclipse) that crashes on load with both the GemDrive and ACSI driver, but not the PP driver, which is curious/could have to do with free RAM (though I would expect GemDrive to occupy even less RAM than PP driver) - but pretty much everything seems to work.

Good to close this unless you need me to try more things, thank you!

[retro16]

I'll have a look at Total Eclipse when I'll have time to work again on the project, it's worth investigating. GemDrive consumes the least amount of RAM (by far ! because it actually uses the STM32 RAM to store things), but I think the PP driver allocates top RAM which increases compatibility a lot.

4.00 brought some improvements since 4.0e. I'll close this ticket for now, feel free to reopen if 4.00 brings regressions.