Joystick/Sound in Supervisor mode?

[t0nyt]

The QL's RTC is only progressing in 1s intervals. You could use it, but it would make your program crawl The polling interrupt is really the only way you get a suitably fast tick rate.

If you pack your sources and put them here I could have a look at it.

Thanks, but I scrapped all my code and am starting from the ground up using your timer routine as the core

I know the timerTick is being called, because if I put, for example, a mode 8 screen trap in there then the screen constantly resets to mode 8

BUT when I try to increment a counter instead, the counter never increments (I can't use the example in your original timer code as none of the items are defined and I don't know what A3 is mean't to be set to either)

Am going to take a break from QL Assembler for now

Many thanks

[t0nyt]

This is the current iteration of my test timer code

Code: Select all

         SECTION  code

         lea.l    0(a6,a4.l),a6
         move.l   #0,MyTimer(a6)

         jsr      timerInit

loop:
         cmp.l    #300,MyTimer(a6)
         ble.s    loop

         moveq    #$10,d0
         moveq    #8,d1
         moveq    #-1,d2
         trap     #1

         rts


         OFFSET   0

MyTimer           ds.l     1

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    #1,MyTimer(a6)

         rts

         END

[tofro]

Inside of timerTick, you cannot use a6 to update your variable (it has another value in the polling interrupt routine than in your code and will actually point to the system variables).

Instead, you get a pointer in a3, not in a6, to 8 bytes before timerLinkage(a6) - That's because the polling routines are actually intended to work in device drivers, and you receive a pointer to a "device driver definition block" instead of to a "polling interrupt linkage" (which is contained in the above). Even if that might all sound like gobbledegook to you (it does make sense, I promise ), simply change your code from

Code: Select all

timerTick
         add.l    #1,MyTimer(a6)

to

Code: Select all

timerTick
        add.l #1,8+MyTimer(a3)        ; we're not a device driver, so look 8 bytes further on!

and it should just work.

[t0nyt]

Inside of timerTick, you cannot use a6 to update your variable (it has another value in the polling interrupt routine than in your code and will actually point to the system variables).

Instead, you get a pointer in a3, not in a6, to 8 bytes before timerLinkage(a6) - That's because the polling routines are actually intended to work in device drivers, and you receive a pointer to a "device driver definition block" instead of to a "polling interrupt linkage" (which is contained in the above). Even if that might all sound like gobbledegook to you (it does make sense, I promise ), simply change your code from

Code: Select all

timerTick
         add.l    #1,MyTimer(a6)

to

Code: Select all

timerTick
        add.l #1,8+MyTimer(a3)        ; we're not a device driver, so look 8 bytes further on!

and it should just work.

Thanks tofro!

I also had to relocate "MyTimer" to be after timer_plad and now it seems to be working, will try a few more tests just to check I have a good starting point

Many thanks

[t0nyt]

Something I'm still trying to get my head around is the reason behind why, if I compile as file type 2 so that I can use RESPR/Lbytes/Call the QL crashes but if I compile as file type 1 and EXEC or EXEC_w it works fine

Is there a particular reason for this please?

Many thanks

[tofro]

Something I'm still trying to get my head around is the reason behind why, if I compile as file type 2 so that I can use RESPR/Lbytes/Call the QL crashes but if I compile as file type 1 and EXEC or EXEC_w it works fine

Is there a particular reason for this please?

Many thanks

The reason is that when you RESPR a program, only the memory for your code is allocated and reserved. EXEC also allocates the memory for the data space. Even more, RESPR/CALL doesn't pre-set a6/a4 to "somewhere safe", but they may have aritrary values when your code is CALLed, so your program is writing to random places.

[t0nyt]

Something I'm still trying to get my head around is the reason behind why, if I compile as file type 2 so that I can use RESPR/Lbytes/Call the QL crashes but if I compile as file type 1 and EXEC or EXEC_w it works fine

Is there a particular reason for this please?

Many thanks

The reason is that when you RESPR a program, only the memory for your code is allocated and reserved. EXEC also allocates the memory for the data space. Even more, RESPR/CALL doesn't pre-set a6/a4 to "somewhere safe", but they may have aritrary values when your code is CALLed, so your program is writing to random places.

Many thanks tofro

Great info thanks