ST536 STE EDITION

[exxos]

The past two errors seem to be because the labels were used elsewhere in TOS

Now that's fixed, Hatari says my TOS is not valid ?! I've only compiled the TOSCOPY module, its not even called yet

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

Capture.PNG (28.94 KiB) Viewed 424 times

It seems I have to put TEXT at the end of my include file, but no other includes to that

BUT then it crashes

Capture.PNG (17.09 KiB) Viewed 421 times

ahhh I think its actually running the code directly on include instead of it acting as a subroutine

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 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...

[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.

[Cyprian]

Are you sure that Hatari CPU is not in 24bit mode?

[exxos]

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.

[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

[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.

[exxos]

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.

[exxos]

It seems to work better without DATA in the code 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 (17.86 KiB) Viewed 367 times

[Cyprian]

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.

[exxos]

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