Atari ST sometimes bombing out on reboot with AUTOBOOT.hfe

[simonsunnyboy]

Reported by Keith Beesting on Facebook:

"When using Flashfloppy on my Atari ST Gotek sometimes when I boot I get these symbols on the screen and no keys respond if I unplug the USB stick and reboot it works fine again, could anyone explain why this hapoens. Many thanks."

[simonsunnyboy]

Maybe it is a corrupted RAM issue.

TOS has system variables that indicate if RAM has been tested at boot time.
This may be exploited by the image selector software. The vectors are cleared in the reset routine and the ST should perform a cold boot.

This might render any "run AUTOBOOT on coldstart" feature inoperable so the fix might need further work.

I have patched the reboot() function but didn't test this yet.
force_coldboot_st.patch.txt

[keirf]

Thanks! Let's see if we can get the OP to test it and see if it helps.

[simonsunnyboy]

I just rethought the thing and realized my fix won't work. It would only affect a program run AFTER the floppy image selector but not the selector itself.

The bombs (crash) happen during the runtime of the selector software itself.
As the selector is bootsector loaded through TOS routines, I would assume the hardware is correctly initialized. I am unsure if the selector software properly clears its BSS segment on startup.
Maybe some corupted RAM variables lead to the crash.

I will try to enable the RS232 debug way to find out more on my actual setup, presuming the selector still works with the HxC firmware.

[keirf]

When I originally got my build of the selector working I managed to debug it on an ST emulator I think. Perhaps because it crashed so early, so the lack of an actual Gotek to talk to didn't matter :) I do remember doing lots of builds changing screen colours at different points as that's all I could work out how to do, haha! It was painful...

[simonsunnyboy]

I managed to get some debug output with Hatari working by replacing the serial debug with the NATFEATS.

Although main part of the manager is not working, I could debug the program startup.
With running the game Rodland from the Pompey Pirates crack beforehand, I could make the selector crash directly before attempting to access media.

That should be similar to the screenshot above.

After a bit of experimenting I decided to simply add a distinct cleanup of the BSS RAM segment to the startup code. See attached patch

With that in place, I do not get bombs anymore on the selector when doing a warm reset from Rodland. I get as far as the floppy media access which fails under emulation as no FF is present.

I still have to check with real hardware, I remember encountering similar bombs on warm reset on my real STE aswell.
clear_bss.patch.txt

[simonsunnyboy]

HFE image file for testing on hardware attached
AUTOBOOT_bss_clear.zip

[keirf]

This is great work thank you!

[simonsunnyboy]

I found time to give this a test run myself today.
I noticed I made a mistake in my patch, it clears 4 times the size of the BSS. The count is in bytes and not longs. I corrected this and got bombs again.

It turns out the stack allocated by the startup code behind the BSS segment is what causes the crash.

If I now clear the stack aswell as the BSS, things work fine.

I tested this on my STE (4MB, TOS 2.06DE) with genuine HxC firmware on the Gotek but it should work.
Running Rodland and then an older selector version with a warm reset brings bombs the same way as with Hatari. Running Rodland and then my updated version, I get no bombs anymore.

I tested the new selector by running a couple of demos which normally leave the RAM pretty messy aswell. The patched selector always recovered well and allowed changing of slots without issues.

The new BSS clear routine looks like this:

;## clear BSS segment

	add.l #STACK_SIZE, d7
	lsr.l   #2, d7                    ; convert BSS length in bytes to number of longs
	addq.l  #1, d7                    ; one long to spare to make sure

clear_bss:
clr.l (a4)+
dbra d7, clear_bss

That should do it.
AUTOBOOT_SSB_2019-11-14.hfe.zip

Again patched HFE for confirmation by other users attached.

[keirf]

Thanks. Strictly speaking requiring zeroed stack is poor as C does not guarantee initialised stack vars. But a fix is a fix and this seems a good robust thing to do.

[simonsunnyboy]

I agree however I think this is linked with 2 properties.

a) The selector is loaded through a special bootsector and not through official TOS routines. This affects how RAM is allocated and cleared before any fresh process/program is loaded.
b) The selector itself uses a stripped down C runtime environment to reduce compile size, as the m68k-atari-mint toolchain official C runtime ("Mintlib") uses much more RAM for the compiled program. This stripped down environment is obviously not 100% according to standards.

I would really like to see any more clean patch to prevent system crashes on warm reboot with undefined RAM contents.

[simonsunnyboy]

For providing a pull request I must be able to provide a branch. Could you please add me as a contributor? I can then provide a pull request for this feature.

[keirf]

That's definitely not needed. Anyhow as an alternative please just attach the final patch to a reply on this ticket.

…

On Fri, 29 Nov 2019, 07:48 Matthias Arndt, ***@***.***> wrote: For providing a pull request I must be able to provide a branch. Could you please add me as a contributor? I can then provide a pull request for this feature. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGWZFR66OZJSDJJ57DXBC3QWDCNZANCNFSM4JLZXHUA> .

[simonsunnyboy]

Yes I had already forked the SW by acident, i just synced it and added abranch for the pull request.