C68 & detecting vsync

[Silvester]

I wrote my solution back in 2002 after studying how Tebby dealt with it. If a job is set up with an associated poll task and the job is forcibly removed then it requires a scheduler task to immediately clean up. TBH I haven't looked at your movie code (yet).

[mk79]

I wrote my solution back in 2002 after studying how Tebby dealt with it. If a job is set up with an associated poll task and the job is forcibly removed then it requires a scheduler task to immediately clean up. TBH I haven't looked at your movie code (yet).

Where did Tony do it this way? Because I stole my solution from Tony, too Hotkey System to be exact.

His solution there is to employ the same mechanism that closes the channels of a job on its removal. Basically when the common heap allocations of a job are freed any blocks belonging to a driver (think channel definition block) trigger a call to the driver's cleanup function. With a bit of trickery this mechanism can be employed even without a driver. It's a really clever and neat solution.

[megatron-uk]

I've definitely lost my keyboard input though as the debug box on the next page cannot be cleared (it responds to any key press), so I'clearly need to set something back again.

Why not do it right in the first place? I even provided the code

But it should be possible to disable and re-enable interrupts with a single instruction, right?

Something like:

Code: Select all

	.text
	.even
	.extern	_WAITVBLANK
_WAITVBLANK:
	or.w		#0x0700,sr		;Disable interrupts, except NMI
	move.b	#255,$18021    		;Clear any current interrupt bits
_WAITVBLANKAGAIN:
	move.b	$18021,d1			;Read in vblank state
	tst.b		d1				;Wait for an interrupt
	beq		_WAITVBLANKAGAIN	;Vblank hasn't occurred yet
	and.w	#0xF8FF,sr			;Enable interrupts again
	rts						;Return to caller

I'm only disabling them for the duration of that _WAITVBLANKAGAIN loop - it's not as if I'm then jumping back out without turning them back on again (the 0xf8ff mask should set the three interrupt level bits back to level 0, from what I understand). Yet keyboard input (I'm using io_fbyte() to get keypresses) definitely stops working after this code returns.

[pjw]

<>

Code: Select all

        move.w    sr,d0
        trap      #0                  freeze Qdos
        move.w    d0,-(a7)
        
        la di da..
        
        move.w    (a7)+,sr            unfreeze!

[megatron-uk]

No difference I'm afraid, the vblank wait routine works fine, and the display animates as expected, but keyboard io stops being received afterwards.

I attach the current build of the game engine and the sample game data files as a 1.44mb QL formatted floppy. Just "exec_w flp1_game" to run.

Excuse the slowness of the text printing routine at the moment.

Hit enter at the splash screen, press 'm' to move, then choose 'n' for north (the only option from the initial game location). The menu selection should flash several times, then the screen repaint for the new map location. A debug box pops up, and it should be possible to cancel it by pressing escape... but no further keypresses are detected. If I comment out the vblank wait and interrupt disable code, then it works as intended.

This is targetted at a base QL machine at present - 128kb and QDOS (and a floppy), so I don't expect it to work with SMSQ/E, pointer environment, fancy hardware like the Q68, etc.

[mk79]

I'm only disabling them for the duration of that _WAITVBLANKAGAIN loop - it's not as if I'm then jumping back out without turning them back on again (the 0xf8ff mask should set the three interrupt level bits back to level 0, from what I understand). Yet keyboard input (I'm using io_fbyte() to get keypresses) definitely stops working after this code returns.

I see a lot of things that are wrong with the code, the least of which is acknowledging all interrupts whether you handle them or not... this style of coding was commonplace in the early 80s and is the main reason old games don't work anymore or only on specific platforms when the moon is in the right phase. But as you seem to be set on your path, good luck.

[megatron-uk]

I'm only disabling them for the duration of that _WAITVBLANKAGAIN loop - it's not as if I'm then jumping back out without turning them back on again (the 0xf8ff mask should set the three interrupt level bits back to level 0, from what I understand). Yet keyboard input (I'm using io_fbyte() to get keypresses) definitely stops working after this code returns.

I see a lot of things that are wrong with the code, the least of which is acknowledging all interrupts whether you handle them or not... this style of coding was commonplace in the early 80s and is the main reason old games don't work anymore or only on specific platforms when the moon is in the right phase. But as you seem to be set on your path, good luck.

Okay, thanks - it may have been useful to point that out; I can see from here that only bit 3 of 0x18021 should be set and tested, so I have now made that change.

Even with that change, and supervisor mode entered and exited immediately prior and after the call to waitvblank, I still lose keyboard input. Rather than insisting that I am doing something wrong, when the documentation appears to state otherwise, could anyone explain why keyboard io does not return after re-enabling interrupts and re-entering user mode?

[mk79]

Even with that change, and supervisor mode entered and exited immediately prior and after the call to waitvblank, I still lose keyboard input. Rather than insisting that I am doing something wrong, when the documentation appears to state otherwise, could anyone explain why keyboard io does not return after re-enabling interrupts and re-entering user mode?

WHAT documentation states what you're doing is right? This obscure web-site you've found? I'm one of the main operating system developers for the platform and I gave you working example code (specifically developed for you just this evening) that does what you want for all platforms in a clean way, yet you insist on this outdated and error-prone register hacking. I really don't get it.

[mk79]

Ah, what the hell... my guess would be that you never acknowledge the interrupt in the end, so no more are issued, so the operating system is dead.

[megatron-uk]

Ah, what the hell... my guess would be that you never acknowledge the interrupt in the end, so no more are issued, so the operating system is dead.

Okay, thank you for the explanation

I've added in your poll.s implementation - I get approximately the same effect as the vblank method (animation flashes repeatedly but keyboard continues to function) but the wait duration is obviously different; what is the approximate duration for each counter increment?