Joystick/Sound in Supervisor mode?

Anything QL Software or Programming Related.
User avatar
XorA
Site Admin
Posts: 1365
Joined: Thu Jun 02, 2011 11:31 am
Location: Shotts, North Lanarkshire, Scotland, UK

Re: Joystick/Sound in Supervisor mode?

Post by XorA »

Code: Select all

label:
  clr.l d0
If you use a code section we can actually see the code properly!


User avatar
t0nyt
Gold Card
Posts: 370
Joined: Wed Nov 22, 2023 6:46 pm
Location: UK

Re: Joystick/Sound in Supervisor mode?

Post by t0nyt »

I've been testing animating a character and using vsync waits to slow it down (else what should be a walking pace turns into Usain Bolt)

In the emulator (Q-emuLator both Mac/Windows) if I wait for 5 vsyncs to happen before each animation update I get the kind of animation speed I'm looking for

But when I then run the same binary on a BBQL the animation goes like the clappers

Is this expected behaviour with an Emulator vs Real Iron please?

Many thanks


User avatar
tofro
Font of All Knowledge
Posts: 2699
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Joystick/Sound in Supervisor mode?

Post by tofro »

t0nyt wrote: Thu Feb 22, 2024 11:17 am I've been testing animating a character and using vsync waits to slow it down (else what should be a walking pace turns into Usain Bolt)

In the emulator (Q-emuLator both Mac/Windows) if I wait for 5 vsyncs to happen before each animation update I get the kind of animation speed I'm looking for

But when I then run the same binary on a BBQL the animation goes like the clappers

Is this expected behaviour with an Emulator vs Real Iron please?

Many thanks
Well, the question would be "how exactly do you wait for vsyncs?". I guess if you use the "proper" method to do that (a polling task), it should behave identical on Q-Emulator and the real box.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Derek_Stewart
Font of All Knowledge
Posts: 3953
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Joystick/Sound in Supervisor mode?

Post by Derek_Stewart »

HI,

I am sure there is a System Variable to detect when the display raster scan has passed the display file and is lopping back to the top of the display memory.
I will have a look at some books I have, maybe the Advanced QL User Guide, QL Technical Manual, QDOS Companion.


Regards,

Derek
User avatar
tofro
Font of All Knowledge
Posts: 2699
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Joystick/Sound in Supervisor mode?

Post by tofro »

Derek_Stewart wrote: Thu Feb 22, 2024 12:03 pm HI,

I am sure there is a System Variable to detect when the display raster scan has passed the display file and is lopping back to the top of the display memory.
I will have a look at some books I have, maybe the Advanced QL User Guide, QL Technical Manual, QDOS Companion.
No, unfortunately not. You need to link in a polling task, which will then be called from the systems internal interrupt service routine. MT.LPOLL is the trap to look for. Some people on the internet seem to be recommending other methods (like fiddling with the polling task list directly, starting from SV_PLIST, or even more obscure methods...), but that's definitely not the proper way to do it.

Linking in a poll task gives me the identical results on QPC (I'm rarely using Q-Emulator) and the real thing.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
t0nyt
Gold Card
Posts: 370
Joined: Wed Nov 22, 2023 6:46 pm
Location: UK

Re: Joystick/Sound in Supervisor mode?

Post by t0nyt »

Ok, thanks. Will look at that option

I was using this and calling it 5 times

Code: Select all

WAITVSYNC:
         move.b   #%11111111,$18021
WAITVSYNC2:
         move.b   $18021,d4
         tst.b    d4
         beq.s    WAITVSYNC2
         rts


User avatar
t0nyt
Gold Card
Posts: 370
Joined: Wed Nov 22, 2023 6:46 pm
Location: UK

Re: Joystick/Sound in Supervisor mode?

Post by t0nyt »

A quick question though, does MT.LPOLL work in supervisor mode please?

I'm not using Supervisor mode yet, and maybe won't, but it's why I've been avoiding Traps etc.

Many thanks


User avatar
tofro
Font of All Knowledge
Posts: 2699
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Joystick/Sound in Supervisor mode?

Post by tofro »

t0nyt wrote: Thu Feb 22, 2024 12:22 pm A quick question though, does MT.LPOLL work in supervisor mode please?

I'm not using Supervisor mode yet, and maybe won't, but it's why I've been avoiding Traps etc.

Many thanks
Yes, it does. All manager traps (MT.xxxx) with the exception of $4, $5, $8, $9, $a, $b (these call back into the scheduler) are guaranteed to work in SV mode. But as you only have to call MT.LPOLL once you can very well do this before you enter SV mode, so it's a bit irrelevant.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
t0nyt
Gold Card
Posts: 370
Joined: Wed Nov 22, 2023 6:46 pm
Location: UK

Re: Joystick/Sound in Supervisor mode?

Post by t0nyt »

tofro wrote: Thu Feb 22, 2024 12:32 pm
t0nyt wrote: Thu Feb 22, 2024 12:22 pm A quick question though, does MT.LPOLL work in supervisor mode please?

I'm not using Supervisor mode yet, and maybe won't, but it's why I've been avoiding Traps etc.

Many thanks
Yes, it does. All manager traps (MT.xxxx) with the exception of $4, $5, $8, $9, $a, $b (these call back into the scheduler) are guaranteed to work in SV mode. But as you only have to call MT.LPOLL once you can very well do this before you enter SV mode, so it's a bit irrelevant.
Ok, many thanks


User avatar
tofro
Font of All Knowledge
Posts: 2699
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Joystick/Sound in Supervisor mode?

Post by tofro »

Just a short explanation on why you shouldn't be fiddling with PC_INTR ($18021) directly:

If you write directly to that address (a hardware register), you're confusing the system that normally maintains a copy on what was last written there. Next, you seem to be writing $ff there, which re-arms all interrupts, not just the vsync. When you read that address, you're not checking the vsync bit only (which is in fact the frame interrupt), but rather check for non-zero, which basically triggers on any interrupts the QL has. So, in case people have special hardware that uses the external interrupt or you have microdrives running or network or serial traffic incoming, your routine will also assume 0.02s have passed... If you want exactly that, a simple HALT would do he same (It just waits for the next interrupt which is effectively what your loop does).

That "improper" method will probably work on a "naked", unexpanded QL, but the more stuff people might plug in, the less it might probably be accurate. You're unlikely to break anything but your own program, though.

The "improper" method (changed to be a bit more specific what interrupt to arm and which to wait for by looking at specific bits) is only really needed when you run your code with interrupts disabled. But these are very rare cases.
Last edited by tofro on Thu Feb 22, 2024 1:03 pm, edited 2 times in total.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Post Reply