From mint-bounce@lists.fishpool.fi Sun Sep 7 15:52:22 2008 Message-ID: <48C415D6.605@gmail.com> Date: Sun, 07 Sep 2008 19:56:38 +0200 From: Miro Kropacek Organization: Mystic Bytes User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: mint Subject: [MiNT] Supexec taking one VBL? Content-Type: multipart/mixed; boundary="------------040207080709050301050604" X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: miro.kropacek@gmail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: This is a multi-part message in MIME format. --------------040207080709050301050604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------040207080709050301050604 Content-Type: text/plain; name="vsync.s" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="vsync.s" bG9vcDoJCW1vdmUudwkjJDI1LC0oc3ApDQoJCXRyYXAJIzE0DQoJCWFkZHEubAkjMixzcA0K CQkNCgkJbW92ZS5sCSMtMSx0ZW1wDQoJCTtic3IJbWFyaw0KCQlic3IJeHh4DQoJCW1vdmUu bAkjMCx0ZW1wDQoJCQ0KCQlicmEJbG9vcA0KDQptYXJrOgkJcGVhCW1hcmtfc3VwZXINCgkJ bW92ZS53CSMkMjYsLShzcCkNCgkJdHJhcAkjMTQNCgkJYWRkcS5sCSM2LHNwDQoJCXJ0cw0K CQ0KbWFya19zdXBlcjoJbW92ZS5sCXRlbXAsJGZmZmY5ODAwLncNCgkJcnRzDQoJCQ0KeHh4 OgkJbW92ZS53CSMtMSxkNw0KLmxvb3A6CQlub3ANCgkJbm9wDQoJCW5vcA0KCQlub3ANCgkJ bm9wDQoJCW5vcA0KCQlub3ANCgkJbm9wDQoJCW5vcA0KCQlkYnJhCWQ3LC5sb29wDQoJCXJ0 cw0KCQkNCnRlbXA6CQlkcy5sCTE= --------------040207080709050301050604--