At 10:40 AM -0500 1/7/00, Allen Briggs wrote:
> One of the issues was dedicated to 6502/8502 assembly/machine
>code and had an article or two on the undocumented instructions (mostly
>formed by figuring out which bits drove which functions and finding
>"unused" combinations).

Ah, the days before "illegal instruction trap" :-)

>Do you have code that can be integrated so that other people might be
>able to pound on it some and help out?  Is it basically functional for
>some models?

Unfortunately, everything is in sort of a "pile". I have a thousand
snippets of code, test programs, annoted ROM disassemblies, and a huge
folder full of information, specs, notes, and little tiny slips of paper
with offsets, bitfield guesses, etc. This is really nothing anybody else
could digest. Which is why I really must drag myself to write a concise
piece of code :-)

The guts of the drivers tend to conern me less. These are trivial pieces of
code if I'm just doing monitor probing and DAC support. What I find myself
doing when I get time is trying to hack a better framework to put the
drivers in. My earlier attempts at Vidtest were to complete the whole
project in one fell swoop so I was wrestling with some gaping holes in our
graphics framework and API that I now realize are just taking too much time
to solve and are reinventions of the wheel when compared to things like the
linux-fb (which, BTW, is the most complete solution to the framebuffer
problem I've seen so far).

The more I work with the Apple-like API the less I like it. I made a device
independant grf layer for it and am not entirely happy with the results.
This is why I'm glad we now have wscons since I believe it takes us a step
closer to a better API and internal framework for graphics.

The most machines I've had working in one piece of code were the IIsi/IIci,
IIvx, and Quadra. However, the Quadra support was incomplete because I was
naive about the way depth switching worked on those machines. I am also
attemping to fix the problem of "sparkling" during DAC loading on the
IIsi/IIci and IIvx. The effect is supremely obnoxious under X with such
small screens. I know I have to sync with the vertical retrace but I've
been having trouble since the interrupt handler needs to write a location
and then the driver needs to poll that location and I'm not sure that's
something that's germain to the NetBSD device model. There is also a
problem with palette loading during the switch from and to 16 bit mode on
the IIvx. Not exactly code that's ready for prime time :-)

This is why I'd like to go "back to basics" and just write the smallest set
of stuff I can write for all machines and submit that. That gives me a
springboard to work off of. When I come back at the code for a second pass
I can concentrate on less mundane problems.

Stay tuned. I've been feeling lucky since I got linux back up on my
PowerMac again :-)

____________________________________________________________________
 Michael Zucca - mrz5149@acm.org - http://www.mdc.net/~mrz5149/
 "I will choose a path that's clear. I will choose Freewill. "
  --Rush, Freewill
____________________________________________________________________