NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/211

Text File | 1996-08-05 | 3.3 KB | 65 lines

Newsgroups: comp.sys.amiga.programmer
Path: netnews.upenn.edu!dsinc!scala!darren
From: [e-mail] ("Darren M. Greenwald")
Subject: Re: QBlit() waits for blitter to finish... ??
Message-ID: <[e-mail]>
Date: Thu, 4 Jan 1996 16:27:04 GMT
References: <4cb2kv$[e-mail]> <[e-mail]> <4cet65$[e-mail]>
Organization: US Research and Development - Scala Inc.

In article <4cet65$[e-mail]> [e-mail] (Michael van Elst) writes:
>[e-mail] ("Darren M. Greenwald") writes:
>
>>or at least set a flag that the blit is done.  Note though that for
>>small to medium blits it could be that the everything is done fast
>>enough that QBlit() returns after the blit is done.
>
>Seems that AmigaOS2.0 has some problems though.
>
>With AmigaOS3.1 on A3000 the QBlit() function returns after about 120
>microseconds for the first QBlit() and after 60 microseconds for a
>QBlit() that just adds the node to the queue.
>
>With AmigaOS2.0 the first QBlit() returns when the blit is done (which
>in that case was after 4.5 milliseconds).
>

Well, I will let you in on an interesting story.  I ended up entirely
rewriting QBlit/QBSBlit and the blitter interrupt code near the very
end of the KS 3.x project.  This is not the kind of thing you normally
rewrite near the end of a project :)  The previous code, and what is
in KS 1.3 through 2.x was so convoluted, so strange, that it had long
since passed the point of anybody understanding what was suppose to
be going on in there.

The actual problem though was there was a race condition in the hardware
that would result in trashed blits, trashed sprites, blitter lockups,
and some other nasty problems in some of the new video modes that
3.x supported.  RoboCity (a long used demo) showed these problems,
but even prior to 3.x there where occasional problems with QBlit and
QBSBlit that resulted in RoboCity not undrawing parts of the animation
correctly.  The code was fixed multiple times prior to KS 3.x; supposedly
fixing the redraw bugs in RoboCity, but the problem was really never
fixed, just made slightly better (or worse maybe).

Now that I think about it you are correct.  This was just one of
many bugs I found in the QBlit subsystem prior to the rewrite.  In fact,
one of the tests I went through after fixing it is to prove that
trackdisk.device (one of the few pieces of code that does use
QBlit()) was not adversely affected by fixing this bug.  To this day
though, I expect there is at least one game out there that was
broken by fixing this behavior.  The most obvious problem is that
if a game unintentionally relied on synchronous behavior, asynchronous
behavior (even though that is the way the function is documented)
opens up a huge window for race conditions.  For programmers that
write their code correctly to use the cleanup routine, no problem,
other than the code may run more efficiently under 3.x than under
2.x.  For programmers that do not use the cleanup routine and rely
on timing and good luck... it comes down to timing and good luck :)

--
-----------------------------------------------------------
Darren M. Greenwald         | Scala Inc. R&D            /
Senior Systems Engineer     | [e-mail]         o
-----------------------------------------------------------