Re: Boarding pass: a work in progress.

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

Michael J. Mahon wrote:
> Linards Ticmanis wrote:
> > BLuRry wrote:
> >
> >>Like the CPU, the video core is a timer-based object that works at a
> >>pre-determined interval (1.023mhz).
> >
> >
> > Why 1.023? The real Apple runs at 1.020484-ish
>
> Thank you, Linards!  The erroneous "urban mythic" clock speed of
> 1.023MHz or 1.024MHz for the Apple II has always bothered me.
>
> But it's clearly a case of cognitive dissonance--2^10-1 or 2^10
> are common numbers.

Actually, it's reinforced by the //c documentation oddly enough.  But,
anyway, the clock speed is something you can set per component.   So
you can clock the video at a different speed of the CPU thread.  :-)

Why is a great question, really, and Nick hit it on the head.  Because
I wanted to see what kind of punishment I could do with Java using new
Java 5 language syntax and thread semantics.  The Applelet project is
awesome, and there's a lot to learn from it.  But what I wanted to
design something modular enough to add new hardware support, and
mame-sytle cheats, without a large overhaul.  The cycle-accurate
conversation last fall was where I decided it would have to be done
from-scratch to be efficient enough to work in Java, thus I started
writing my own instead of adapting one that already existed.

Another big driver of this is that my day job deals primarily with web
programming and very dead-simple java, string processing mostly.  What
I get out of this sort of project is I actually get to use my comp sci
education for something -- analyzing code, looking for performance
bottlenecks, and writing a multi-threaded application that can really
push the JVM to its limit. :-D

Anyway, my progress for now is that I did some more reading about how
the rom in the //e works.  Wow. Very odd, especially the C3xx and
C8xx-CFxx page behavior.  Thank goodness for the "Understanding the
//e" book.  Demystifies it pretty darn well -- so I should have that
fixed up soon.  ;-)

-B