Joystick/Sound in Supervisor mode?

[XorA]

Code: Select all

label:
  clr.l d0

If you use a code section we can actually see the code properly!

[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

[tofro]

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.

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

[tofro]

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.

[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

[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

[tofro]

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.

[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

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

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