ST536 STE EDITION

[exxos]

So it seems I have to use TEXT for the data stuff

I've also moved the print routine to the bottom of the file. I think it could have been calling the routine, and then running it a second time (without parameters) in the code flow.

No bombs and gets to desktop now

Capture.PNG (28.19 KiB) Viewed 427 times

Does anyone know if you can pause the emulation without using the F12 menu thing ?


So going by my debug outputs, its not entering supervisor mode.. i've had that issue before and never figured it out

Capture.PNG (26.77 KiB) Viewed 422 times

2.PNG (33.39 KiB) Viewed 422 times

EDIT:

Although it might be to many prints to screen screwing up the thing..

[exxos]

It gets as far as the SSP debug message, and seems to crash on where I have the blue dot a couple lines more down..

Capture.PNG (121.27 KiB) Viewed 417 times

[Cyprian]

Does anyone know if you can pause the emulation without using the F12 menu thing ?


So going by my debug outputs, its not entering supervisor mode.. i've had that issue before and never figured it out

You can define your own Pause shortcuts, "Hatari main menu" --> "Keyboard setup" --> "Shortcuts" --> "Pause emulation"

BTW Hatari debugger has a nice option:

Code: Select all

Xconout redirection [1] + Hatari command line help, hard-coded to "stdout"

https://www.hatari-emu.org/doc/debugger ... bugger_use

[agranlund]

Looks like you are overwriting a0 with a pointer to the debug message, while a0 was being used as storage for the old ssp (presumably so that it can restore it in the temporary bus-error handler)
This would for sure cause all kinds of havoc in the bus-error handler and a double bus fault seems likely.

Code: Select all

move.l d0,a0  /* save old ssp in a0 */
lea dbg_ssp(pc),a0   /* <---- trashing a0 above */
bsr print_string

Don't know how print_string looks but I'm assuming it saves and restores all the registers it modifies, if not then that can be an additional source of bugs unless you know exactly which registers it trashes and that those are "don't care" in all situations you are calling it.

[exxos]

Looks like you are overwriting a0 with a pointer to the debug message, while a0 was being used as storage for the old ssp (presumably so that it can restore it in the temporary bus-error handler)
This would for sure cause all kinds of havoc in the bus-error handler and a double bus fault seems likely.

Code: Select all

move.l d0,a0  /* save old ssp in a0 */
lea dbg_ssp(pc),a0   /* <---- trashing a0 above */
bsr print_string

Don't know how print_string looks but I'm assuming it saves and restores all the registers it modifies, if not then that can be an additional source of bugs unless you know exactly which registers it trashes and that those are "don't care" in all situations you are calling it.

Thanks.. I did start taking out the debug messages but didn't seem to help But I didn't remove that you you said.. so ill try that next..

My print routine...

Code: Select all

/* --- Print string in A0 ---*/
print_string:
movem.l d0-d2/a0-a2,-(sp)
move.l a0,-(sp)
move.w #9,-(sp)
trap #1
addq.l #6,sp
movem.l (sp)+,d0-d2/a0-a2
rts

[exxos]

I removed some prints..

The first breakpoint blue dot is "Super trap" message.. the second dot message is never reached..

Capture.PNG (96.95 KiB) Viewed 403 times

I will use A3 for the print messages, hopefully rule one thing out..

[exxos]

Using A3 now and same problem

Capture.PNG (86.44 KiB) Viewed 396 times

[exxos]

I asked GPT

2.PNG (32.73 KiB) Viewed 390 times

So now I get further it seems!

55.PNG (27.06 KiB) Viewed 390 times

Now GPT saying about wrong exception frames well GPT can fix it.. it knows more than me..

EDIT:

Now its broken todally.. Probably need someone to fix this code for me as I aint a clue what I am doing

All it should do is check a TTram address to see if it causes bus error or not... easier said than done!

[exxos]

I had a thought to jack into TOS's own TTram test. I should be able to run my TOS copy code if TTram is found. Not as good as checking stuff.. but this version of TOS shouldn't be run on anything but a STE with a STE536 anyway. So I am choosing not to care to check stuff properly

Hatari moans about ROM CRC error if I renamed 206 to 306. I have to untick the "patch system vars" thing to get the CRC message, otherwise it goes direct to desktop.. It doesn't even do STram test now. So no idea what's going on there.

I will just have to burn some ROMs tomorrow and test on real hardware and do it all "the slow way" again

[exxos]

While meddling in the TT ram code.. I have now worked out there is another problem (nothing to do with me)

I've known about this for a while, that if I actually issue BERR for TTram test (as it should be done) TTram ends up being found and then going nuts...

IMG_3372.JPG (49.94 KiB) Viewed 318 times

IMG_3375.JPG (57.89 KiB) Viewed 318 times

The ------------------ line actually appears instantly and it does not appear to be active checking the RAM at all...

Problem is again, there is PAK patches mixed in all that code if I take them all out then TTram isn't found at all then. So I'm asking GPT4 to figure that out now... As I aint a clue what the codes doing...

EDIT:

oh wow GPT4 fixed the problem!!

1.PNG (36.51 KiB) Viewed 317 times

Now I notice there's another mistake in the code.. its running "Ram OK" when its actually not because of the code execution order it seems