Interrupt vector and Minerva

[spkr]

Hi there guys,

I found that my most recent demo release is not Minerva-ROM compatible. Because I have no intention to willingly deny Minerva users to run my demos, Im interested in looking into what causes the incompatibility. Luckily for me, the issue can be reproduced using Qemulator!

However, I lack the knowledge about how the QL OS (Minerva) runs. So far, I have `winged' it in JSROM, to put my own VBLANK vector in the designated spot; like this (Warning code follows:)

This is the way I install my own demosystem handler; by overwriting the user programmable auto vector for vblank

Code: Select all

initInterrupt
	move.w	#$4e71,initInterrupt				; make this run once, so the next time we run this it does rts
	move.w	#$2700,sr						; stop interrupts
	move.l	#vblRoutList,$2803c				; write our own vblank vector list in the designated user programmable auto vector
	move.w	#$2100,sr						; enable interrupts
	rts	

However, when using hte Minerva rom, as soon as I enable interrupts again. The system triggers an interrupt, from which it no longer recovers (using Minerva ROM, using JSRom it just ends up execting code properly).

The interrupt thats being fired drops the PC to $6BC. Some research seems to lead to that this is cased by a level 2 interrupt being triggered (vectors defined at $68 ?).

It seems the Minerva code is less selfcontained than the JSROM....

If anyone has a quick fix, please chip in. Otherwise I'll just have to delve into the rabbit hole a bit further.

Kind regards,
Wietze

[Silvester]

Try POKE!!53,128

[spkr]

What does that do?

[M68008]

Perhaps you could leave interrupts disabled and poll the vblank register.

[spkr]

Perhaps you could leave interrupts disabled and poll the vblank register.

No thats not an option.

[Silvester]

What does that do?

Disables the interface interrupt (IPC activity). Value gets copied to ZX8302 interrupt mask register. QDOS never used it but Minerva introduced it to respond to IPC (Hermes). But it causes slow down on non-Gold systems (FLP activity, POKE!!53,128 restores performance). Don't know if emulator replicates it, but I thought it might worth a try since QDOS (JS et al) appeared to work.

[janbredenbeek]

Hi there guys,

I found that my most recent demo release is not Minerva-ROM compatible. Because I have no intention to willingly deny Minerva users to run my demos, Im interested in looking into what causes the incompatibility. Luckily for me, the issue can be reproduced using Qemulator!

However, I lack the knowledge about how the QL OS (Minerva) runs. So far, I have `winged' it in JSROM, to put my own VBLANK vector in the designated spot; like this (Warning code follows:)

This is the way I install my own demosystem handler; by overwriting the user programmable auto vector for vblank

Code: Select all

initInterrupt
	move.w	#$4e71,initInterrupt				; make this run once, so the next time we run this it does rts
	move.w	#$2700,sr						; stop interrupts
	move.l	#vblRoutList,$2803c				; write our own vblank vector list in the designated user programmable auto vector
	move.w	#$2100,sr						; enable interrupts
	rts	

I don't get the $4e71; this is the opcode for NOP, not RTS. The next time this runs it will execute NOP followed by whatever two words follow, depending on the location. It might as well crash because it executes an illegal instruction (which usually causes a lock-up if you don't have redirected the illegal instruction vector). Besides, self-modifying code is generally considered not-done. It would be better to test the system variable for the value you've written and return if it's already done.
But if you want to do it this way, the correct opcode for RTS is $4e75.

However, when using hte Minerva rom, as soon as I enable interrupts again. The system triggers an interrupt, from which it no longer recovers (using Minerva ROM, using JSRom it just ends up execting code properly).

The interrupt thats being fired drops the PC to $6BC. Some research seems to lead to that this is cased by a level 2 interrupt being triggered (vectors defined at $68 ?).

It seems the Minerva code is less selfcontained than the JSROM....

There is not much difference in the way Minerva handles frame interrupts compared to JS. In Minerva, the linked list for the inbuilt polled task starts in RAM (unlike in JS, where it is in ROM) but that shouldn't make a difference since you write your entry directly into the system variable instead of using the proper system TRAP (thereby disabling the inbuilt routine which scans the keyboard). I assume your vector list is a proper linked list with the first long word being 0 (or next entry) and the second long word a pointer to the handling routine?

[janbredenbeek]

What does that do?

Disables the interface interrupt (IPC activity). Value gets copied to ZX8302 interrupt mask register. QDOS never used it but Minerva introduced it to respond to IPC (Hermes). But it causes slow down on non-Gold systems (FLP activity, POKE!!53,128 restores performance). Don't know if emulator replicates it, but I thought it might worth a try since QDOS (JS et al) appeared to work.

Well, it's actually the other way round. The JS ROM has a provision for the interface interrupt but the original 8049 never used it, unlike Hermes. Older Minerva versions used to ignore it but when Hermes appeared it was reinstated.

[spkr]

Hi Jan,

thanks for your comment, nice to see another Dutchie here .
Regarding the nop; yes, geez, is my face red. That is supposed to me ending in 5....

Correct:

Code: Select all

vblRoutList		dc.l	0
				dc.l	demoScriptHandler

Where demoScriptHandler is part of the little kernel of my demosystem.

I will try and cobble up a minimal example, and see how that behaves.

Kind regards,
Wietze

[janbredenbeek]

Hi Jan,

thanks for your comment, nice to see another Dutchie here .
Regarding the nop; yes, geez, is my face red. That is supposed to me ending in 5....

Correct:

Code: Select all

vblRoutList		dc.l	0
				dc.l	demoScriptHandler

Where demoScriptHandler is part of the little kernel of my demosystem.

That looks OK, though it will be position-dependent because of the absolute pointer. Usually, machine code on the QL will be loaded using EXEC or LRESPR and you don't know beforehand where your program will go in memory. The usual way to set this up will be something like this:

Code: Select all

lea vblRoutList(pc),a0
lea demoscripthandler(pc),a1 
move.l a1,4(a0)

(even this is a bit dirty since the link is in the code itself, it should really be in a data area e.g. the common heap)

Best Regards,
Jan