Page 75 of 97
Re: ST536 STE EDITION
Posted: 10 Jun 2025 13:07
by exxos
The past two errors seem to be because the labels were used elsewhere in TOS :roll:
Now that's fixed, Hatari says my TOS is not valid ?! I've only compiled the TOSCOPY module, its not even called yet :shrug:
I wonder if my new module pushed it over the size limit, its still showing 250KB though in size. TOSCOPY.PRG only takes up 731 bytes. So wouldn't seem so..
I moved the include statement for my new code and now get a sh*t load of errors :shrug:
Capture.PNG
It seems I have to put TEXT at the end of my include file, but no other includes to that :shrug:
BUT then it crashes :(
Capture.PNG
ahhh I think its actually running the code directly on include instead of it acting as a subroutine :roll:
Might be simpler just to get the include and just copy the code into the main startup script instead..
Its not helping either as Hatari doesn't seem to enable TTram with TOS206 :cry: It keeps forcing 24bit addresses which is why I assume its not letting me have TTram..
The workaround is to try and allocate a bit of TTram to see if it exists or not before trying to do the copy...
Re: ST536 STE EDITION
Posted: 10 Jun 2025 15:42
by exxos
Anyone know why this code is causing the three bombs in Hatari ?
Code: Select all
exxos_check_ttram_available:
movem.l d0-d2/a0-a1,-(sp) /* Save registers */
/* Align stack to word boundary */
move.l sp,d2
andi.l #$FFFFFFFE,d2
move.l d2,sp
/* Enter supervisor mode to access exception vectors */
clr.l -(sp) /* Super(0) to get current SSP */
move.w #$20,-(sp) /* Super call (opcode 32) */
trap #1
addq.l #6,sp
move.l d0,a0 /* Save old SSP in a0 */
/* Save original bus error vector */
move.l $8.w,a1 /* Get bus error vector ($8) */
move.l a1,-(sp) /* Save it on stack */
/* Install temporary bus error handler */
move.l #bus_error_handler,$8.w
/* Attempt to write to TT-RAM ($01000000) */
move.l #$01000000,a1 /* TT-RAM base address */
moveq #0,d0 /* Clear bus error flag */
move.l #$12345678,d1 /* Test value to write */
move.l d1,(a1) /* Write to TT-RAM address */
/* Check if bus error occurred */
tst.l d0
bne fail_tt /* Bus error: TT-RAM not accessible */
/* Success: TT-RAM is accessible */
moveq #1,d0
bra restore_state
bus_error_handler:
moveq #1,d0 /* Set bus error flag */
move.l 10(sp),2(sp) /* Copy PC to return address for RTE */
addq.l #8,2(sp) /* Skip faulting instruction */
rte /* Return from exception */
fail_tt:
moveq #0,d0 /* Failure: TT-RAM not accessible */
restore_state:
/* Restore original bus error vector */
move.l (sp)+,$8.w /* Restore saved vector */
/* Return to user mode */
move.l a0,-(sp) /* Push old SSP */
move.w #$20,-(sp) /* Super call */
trap #1
addq.l #6,sp
done_tt:
movem.l (sp)+,d0-d2/a0-a1 /* Restore registers */
rts
no_tt_ram:
lea ttram_error_msg(pc),a0
bsr print_string
moveq #4,d0 /* Custom error code for TT-RAM unavailable */
bra done
Calling function:
Code: Select all
bsr exxos_check_ttram_available
tst.l d0
beq no_tt_ram
Its supposed to check if there is any TTram. Sets up a BERR handler, as I assume Hatari will issue BERR because TTram isn't there.
Re: ST536 STE EDITION
Posted: 10 Jun 2025 18:43
by Cyprian
Are you sure that Hatari CPU is not in 24bit mode?
Re: ST536 STE EDITION
Posted: 10 Jun 2025 18:47
by exxos
Cyprian wrote: 10 Jun 2025 18:43
Are you sure that Hatari CPU is not in 24bit mode?
I mentioned this a few times before, its stuck in 24bit mode, it seems to assume TOS206 needs 24bit even if I set TTram to 64MB. Its a limit in Hatari.
I can't even get a print message line to work in my code, it worked as a standalone PRG. So I am trying to figure that out now.
Re: ST536 STE EDITION
Posted: 10 Jun 2025 19:21
by exxos
I'm giving up for tonight. Maybe
@dml can see something obvious ?
I can do this
Code: Select all
/*exxos end of crc patch text (done!) */
move.l #ROMDONETEXT,-(sp)
move.w #9,-(sp)
trap #1 /* Cconws()*/
addq.w #6,sp
Works fine.
But when I just try and do a more complex print routine, it either prints garage and/or 3 bombs.
Code: Select all
TEXT
lea dbg_bg(pc),a0
bsr print_string
data
/* Debug messages for exxos_check_ttram_available */
dbg_bg: dc.b "DEBUG: Return",13,10,0
TEXT
/* --- 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 19:22
by stephen_usher
Change the version code to 3.06 instead, as you did once for me. Most programs work better on an 030 if they think that they're running on a TT anyway. :-)
Re: ST536 STE EDITION
Posted: 10 Jun 2025 19:23
by exxos
stephen_usher wrote: 10 Jun 2025 19:22
Change the version code to 3.06 instead, as you did once for me. Most programs work better on an 030 if they think that they're running on a TT anyway. :-)
I did try that right at the beginning, didn't work, can't remember why.
Re: ST536 STE EDITION
Posted: 10 Jun 2025 20:08
by exxos
It seems to work better without DATA in the code :shrug: I had to print several times because I couldn' t see the text because the Hatari crash box and bombs was in the way..
But still no idea why its crashing.
Capture.PNG
Re: ST536 STE EDITION
Posted: 10 Jun 2025 20:14
by Cyprian
exxos wrote: 10 Jun 2025 18:47
Cyprian wrote: 10 Jun 2025 18:43
Are you sure that Hatari CPU is not in 24bit mode?
I mentioned this a few times before, its stuck in 24bit mode, it seems to assume TOS206 needs 24bit even if I set TTram to 64MB. Its a limit in Hatari.
I wanted to make sure.
In Hatari 24bit CPU mode, writing to $01000000 means writing to address $000000, which if I remember is hardware protected by the GLUE.
The question for Hatari Team is why they don't allow 030 with 32bit addressing mode for ST/STe machines.
Re: ST536 STE EDITION
Posted: 10 Jun 2025 20:19
by exxos
Cyprian wrote: 10 Jun 2025 20:14
In Hatari 24bit CPU mode, writing to $01000000 means writing to address $000000, which if I remember is hardware protected by the GLUE.
The question for Hatari Team is why they don't allow 030 with 32bit addressing mode for ST/STe machines.
Yeah, its a bit of a annoyance for debugging stuff :(