It has become apparent that although the video controller design makes
all sorts of things possible, it also makes some things rather
inconvenient.

Example:  double buffering

For this, you have to update the viewport pointer every frame (or
every time you want to switch views).  The problem is that the pointer
is not stored in a fixed location in the video program, and it's split
across two instructions.  As a result, it's not advisable to simply
hard code something in a driver to make this change.

Example:  knowing when you're in vertical blank

Windows drivers want to know when you're in vertical blank and when
you're not.  A common way to figure this out is to read a scanline
number from the VC.  We don't have any such concept.  Our INT flag
allows us to interrupt as many times as we like, so hypothetically, we
could put an interrupt in at the end of the last active scanline and
another one just before the first active scanline.  But then you're
faced with the challenge of determining which interrupt your ISR was
triggered by.  (Store the system timer of the last interrupt and see
if the time period was short or long?)


For the first problem, I have a tentative suggestion.  Rather than
adding more hardware (given that the hardware is capable of doing what
we need to do, however inconveniently), perhaps we could have the vc
compiler function (progressive, interlaced, etc.) fill out a struct
with some key information, such as the addresses of the ADDR and INC
instructions that contain the pointer.  So when you call progressive,
pass it a pointer to the struct, and then store that away.  When it's
time to flip views, you can look in that struct for offsets to where
the instructions are.  This way, when we update progressive.asm in a
way that moves the ADDR and INC instructions, no other code has to
change.

Discussion?

--
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to