Boarding pass: a work in progress.

["BLuRry" <brendan.robert@gmail.com>]

Funny things happen when you consume too many free drinks on an
airplane.  And several times in the past six months, I have been
upgraded not only to the first class cabin, but to seat 2E.  So, as
part of this ritual, I would start working on something //e-related.  I
decided in one of these buzzed sessions of coding that it might be fun
to try my hand at an emulator.

And now it's the middle of January and I got the CPU and memory cores
to start behaving themselves.  It will be cycle-accurate, or at least
it should be in theory.  Or the whole thing will be too slow to emulate
a real-time apple.  Haven't figured out if that's the case yet.  ;-)
If there are any pain points, I can use the wonderful profiler in
Netbeans 5.5 to track down the culprits pretty easily, I think.
"Boarding Pass" is a tentative name.  I'll probably change it
eventually once this thing actually works.

Thanks to the applewin debugger, I was able to trace my cpu's first
hundred or so cycles and verified that, in fact, the 65c02 emulation
core is working at least in some basic level.  I haven't verified all
the opcodes are perfect yet, but it shows a lot of promise -- and does
what it's supposed to do.  It gets to the point where the slot rom is
supposed to enable, but I haven't fixed it yet.  Once I fix the CXXX
rom logic bugs it should get closer to working.

The memory core is an interesting beast.  There are two main banks
called activeRead and activeWrite, which are reconfigured whenever you
mess with a softswitch that affects readable/writable memory.  The
memory is really divided into chunks named like main, aux,
languageCard1, etc.  The memory also allows registration of various
listeners (think Mame cheats, which inspired the idea), which the soft
switches use to register themselves.  So even though the target is a
//e, making it work like another machine is pretty simple because you
don't have to tack in a bunch of conditional logic, just register
different listeners.

The video emulation will be basic mono/rgb -- no fancy ntsc-looking
stuff at the moment.  Before i get too crazy with the video bit, I at
least have to get it to work.  In theory it should be working, but I
haven't figured out why it's displaying the wrong stuff (bit vertical
white bar on the left side).  It should be cycle-accurate once it's
done, but currently it's done in a buffer so you won't see the frame
until it hits the VBL period.  So, it should look much like a
cycle-accurate machine but will always visibly lag behind 1/60th of a
second.  I'm hoping this won't make a big difference.

Like the CPU, the video core is a timer-based object that works at a
pre-determined interval (1.023mhz).  Every million cycles, a
timer-based object evaluates how fast/slow it was operating based on
how it should have performed, and its delay-per-cycle time is adjusted
accordingly.  Each timer runs in its own thread, processes a single
"tick" (diplay one byte, process one opcode, wait, etc), and in some
cases there is a wait timer (in cycles) set that makes the whole thread
sleep until the wait is over.  This helps video accurately reflect an
HBL or VBL period, and the CPU opcodes take the appropriate amount of
cycles.

Anyway, it's in progress.  There's not even so much as an "Apple //e"
in the top-middle of a window.  But hopefully soon I'll make progress.
Got upgraded to seat "2B" -- which will have to do.  ;-)  I'll probably
give the guy in "2E" a very evil eye for raining on my parade.