Joystick/Sound in Supervisor mode?

[tofro]

Don't use OFFSET.

Here's what I do:

• All of my program code goes into a SECTION code
• All of my data goes into a SECTION DATA

If you start a new section, the assembler re-sets all the addresses it generates to 0.
By setting a6 to the data space base adress at the beginning of the program and indexing by the labels in the data section, the assembler will manage the proper addresses:

Code: Select all

    SECTION data
a: DS.L    1
b: DS.L    1
c: DS.W   1
buffer:   ds.b 100

After this, the assembler will assign 0 to the a offset, 4 to b, 8 to c and 12 to buffer. In your code, do

Code: Select all

    SECTION code
    lea.l 0(a6,a4),a6     ; let a6 point to the bottom of the data space
    move.l #100,a(a6)    ; moves 100 to a6+a
    move.l #200,b(a6)   ;  same for b
    move.w #100-1,d0
loop:
    clr.b buffer(a6,d0.w)    ; clear the buffer
    dbra d0,loop
    

Thus, you don't really care where your variables are - they are always relative to a6, and where a6 points to was allocated by QDOS. You simply use the names.

If you write your code in multiple source files, the code that defines what's going on in your data space typically goes into an include file, that is INCLUDEd in all your code files.

[t0nyt]

Don't use OFFSET.

Here's what I do:

• All of my program code goes into a SECTION code
• All of my data goes into a SECTION DATA

If you start a new section, the assembler re-sets all the addresses it generates to 0.
By setting a6 to the data space base adress at the beginning of the program and indexing by the labels in the data section, the assembler will manage the proper addresses:

Code: Select all

    SECTION data
a: DS.L    1
b: DS.L    1
c: DS.W   1
buffer:   ds.b 100

After this, the assembler will assign 0 to the a offset, 4 to b, 8 to c and 12 to buffer. In your code, do

Code: Select all

    SECTION code
    lea.l 0(a6,a4),a6     ; let a6 point to the bottom of the data space
    move.l #100,a(a6)    ; moves 100 to a6+a
    move.l #200,b(a6)   ;  same for b
    move.w #100-1,d0
loop:
    clr.b buffer(a6,d0.w)    ; clear the buffer
    dbra d0,loop
    

Thus, you don't really care where your variables are - they are always relative to a6, and where a6 points to was allocated by QDOS. You simply use the names.

If you write your code in multiple source files, the code that defines what's going on in your data space typically goes into an include file, that is INCLUDEd in all your code files.

Thanks Tofro, but I still don't understand some of it - sorry

I don't get why a6+a4 now points to "section data", when previously if was pointing to the default 4kb data space (I think I'm misunderstanding a concept here)

And I don't get how the MT.LPOLL code fits into all this as it won't assemble in the code section

Sorry I'm being so thick, but I can't work out how everything hangs together

Many thanks

[janbredenbeek]

Thanks Tofro, so "OFFSET 0" puts the code at the start of the 4kb?
It still won't assemble code after an OFFSET though (the offset section is at the end of my source file)

You need to add a SECTION directive after the block defined after OFFSET 0. E.g.:

Code: Select all

OFFSET 0

label1	DS.L	1
label2	DS.L	1

SECTION CODE

(put your program code here)

END

[t0nyt]

Thanks Tofro, so "OFFSET 0" puts the code at the start of the 4kb?
It still won't assemble code after an OFFSET though (the offset section is at the end of my source file)

You need to add a SECTION directive after the block defined after OFFSET 0. E.g.:

Code: Select all

OFFSET 0

label1	DS.L	1
label2	DS.L	1

SECTION CODE

(put your program code here)

END

Thanks Jan, that let's it compile (apart from timertick's "add.l #MSPERTICK,ticksMillis+8(a6)" which I've commented out until I can work out what's missing)

Currently the emulator keeps crashing, I think each time the handler is called. Perhaps related to the above missing line?

My head's close to imploding right now, so will give it a rest until I can face it again

Many thanks

[janbredenbeek]

Interesting, you managed to jump to a system variable (SV.RAND) which contains a random number... And by chance it happened to have a value $Axxx which is always illegal to the 68000 (but often used by emulators).

[tofro]

And you managed to bring up a message window I've never seen before . (Didn't know Q-Emulator catches Line-A traps)

[t0nyt]

Well the error message has gone for now and I just get a corrupt screen

I've now stripped out all my code to just leave the timer routines which still give me a corrupt screen

Code: Select all

         section  code

         lea.l    0(a6,a4.l),a6
         jsr      timerInit
loop     jmp      loop

         offset   0

timerLinkage
timer_pllk        ds.l     1
timer_plad        ds.l     1

         section  timer

timerInit
         lea      timerTick,a0
         move.l   a0,timer_plad(a6)
         lea      timerLinkage(a6),a0
         moveq    #$1c,D0
         TRAP     #1
         rts

timerRemove
         lea      timerLinkage(a6),a0
         moveq    #$1d,D0
         TRAP     #1
         rts

timerTick
      ;   add.l    #MSPERTICK,ticksMillis+8(a3)
         rts

         END

I'm obviously missing something really simple here

[t0nyt]

Have tried tracing with C1Monitor and I can see that the data section is indeed located directly after the code ends and is in A6, so that all looks ok

But as I trace when it does the TRAP #1 it raises an illegal instruction

EDIT: After the illegal instruction the following rts is skipped, don't know if that's just a quirk of C1Monitor or if it's actually happening

[t0nyt]

Have tried tracing with C1Monitor and I can see that the data section is indeed located directly after the code ends and is in A6, so that all looks ok

But as I trace when it does the TRAP #1 it raises an illegal instruction

EDIT: After the illegal instruction the following rts is skipped, don't know if that's just a quirk of C1Monitor or if it's actually happening

Screenshot 2024-02-23 at 10.18.33.png

This is C1Monitor immediately before the TRAP 1 tries to execute

[t0nyt]

A dump of the storage and a disassembly of what it points to (rts)

I mean it all looks ok so I don't understand why it collapses in a heap