[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MiNT] Supexec taking one VBL?



Hi,

some days ago I decided to fix some issues in my Silkcut demo port, except the others also in one-frame transparent scroller. Since the whole port is done under FreeMiNT it's natural I test it here, too. I couldn't catch one remaining bug -- even when scroller took about 50% of VBL time, there were still some "jumps" with no obvious reason. Whole code was some rendering, then Vsync() and setting new video ram for double buffer (ok, not very needed in one frame scroller but whole demosystem works like that).

After numerous and numerous trial-error experiments I probably found the cause -- look at attached source code. It calls Vsync() (i.e. waits until we're in VBL), then change background to white (i.e. nothing since in VBL we're out of visible screen area), calls subroutine and then again change background to black.

In normal case (and under TOS), this routine should just loop and user shouldn't see anything since whole screen change ran in VBL as mentioned.

However, with Supexec subroutine ("mark") under FreeMiNT I see guess what? White screen, i.e. that call took whole next VBL to process! From FreeMiNT source I see there's some hacking with this system call so I just want to make sure this is normal and I didn't interpret something wrong..

Btw this makes clean coding a lot of harder since we can't use VsetMode() for video set/restore (XBIOS bug) and for setting video ram we have only one call -- VsetScreen() which is a little bit unpractical (it doesn't return old values and after every new value it reallocates / frees the previous buffer). Not to mention any clean way how to hook on user vbl (that one from 0x0456.w address) and the (non-)usability of XBIOS calls in such interrupt (i.e. for setting palette). Argh, I'm angry. After all that effort to make it as clean as possible (because I needed to give gdb as much control as possible) now I'm forced to use Super() in the demo init to make this one frame stuff work.

--
MiKRO / Mystic Bytes
http://mikro.atari.org

loop:		move.w	#$25,-(sp)
		trap	#14
		addq.l	#2,sp
		
		move.l	#-1,temp
		;bsr	mark
		bsr	xxx
		move.l	#0,temp
		
		bra	loop

mark:		pea	mark_super
		move.w	#$26,-(sp)
		trap	#14
		addq.l	#6,sp
		rts
	
mark_super:	move.l	temp,$ffff9800.w
		rts
		
xxx:		move.w	#-1,d7
.loop:		nop
		nop
		nop
		nop
		nop
		nop
		nop
		nop
		nop
		dbra	d7,.loop
		rts
		
temp:		ds.l	1