Page 76 of 97
Re: ST536 STE EDITION
Posted: 10 Jun 2025 20:22
by exxos
So it seems I have to use TEXT for the data stuff :shrug:
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
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
2.PNG
EDIT:
Although it might be to many prints to screen screwing up the thing..
Re: ST536 STE EDITION
Posted: 10 Jun 2025 20:44
by 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.. :shrug:
Capture.PNG
Re: ST536 STE EDITION
Posted: 10 Jun 2025 20:47
by Cyprian
exxos wrote: 10 Jun 2025 20:22
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"
Re: ST536 STE EDITION
Posted: 10 Jun 2025 21:14
by 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.
Re: ST536 STE EDITION
Posted: 10 Jun 2025 21:17
by exxos
agranlund wrote: 10 Jun 2025 21:14
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
Re: ST536 STE EDITION
Posted: 10 Jun 2025 21:26
by exxos
I removed some prints..
The first breakpoint blue dot is "Super trap" message.. the second dot message is never reached..
Capture.PNG
I will use A3 for the print messages, hopefully rule one thing out..
Re: ST536 STE EDITION
Posted: 10 Jun 2025 21:51
by exxos
Using A3 now and same problem :(
Capture.PNG
Re: ST536 STE EDITION
Posted: 10 Jun 2025 22:15
by exxos
I asked GPT :lol:
2.PNG
So now I get further it seems!
55.PNG
Now GPT saying about wrong exception frames :hide: well GPT can fix it.. it knows more than me.. :lol:
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!
Re: ST536 STE EDITION
Posted: 11 Jun 2025 21:49
by 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 :(
Re: ST536 STE EDITION
Posted: 12 Jun 2025 19:50
by 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
IMG_3375.JPG
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 :roll: 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
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 :roll: