Re: JACE: Finally usable for a change

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

On Jan 27, 4:59 pm, mmphosis <mmpho...@yahoo.com> wrote:
> On Jan 26, 11:13 pm, BLuRry <brendan.rob...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 26, 11:13 pm, mmphosis <mmpho...@yahoo.com> wrote:
>
> > > Awesome!
>
> > > I am running jace on Mac OS X 10.6.6 (Snow Leopard.)
>
> > > $ java -version
> > > java version "1.6.0_22"
> > > Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
> > > Java HotSpot(TM) Client VM (build 17.1-b03-307, mixed mode)
>
> > > "It is a faithful cycle-accurate emulation of an apple //e computer."
>
> > >http://hoop-la.ca/apple2/2011/images/screenshot2011-01-26at8.45pm.png
>
> > Well, the video is only accurate within 4 cycles for efficiency but I
> > can improve on that. ;-)
>
> > I just posted an updated build that fixes some configuration UI bugs
> > (you can now set numerical values without errors) and also fixes an
> > odd bug where you might BLOAD an image into memory from a hard drive
> > and it doesn't show up on the screen (because it wasn't triggering
> > memory listeners and therefore not dirtying the scanline bits...)
>
> > -B
>
> "The video is only accurate within 4 cycles" explains why the video
> switches at different byte boundaries than what I remember on real
> hardware.
> The current version of jace displays 5 bytes of graphics and 8 bytes
> of text whereas this code alternates between 6 bytes of graphics and 7
> bytes of text...
>
> ORG $0300:
>     LDA $C050 ; 4 cycles
>     NOP ; 2 cycles
>     LDA $C051 ; 4 cycles
>     JMP $0300 ; 3 cycles
>
> Note that 13 cycles is what makes the video "lock in" work.  I ran
> "Gorgon" because I remember Gorgon mixing hi-res and lo-res that would
> move (no "lock in"), but it doesn't seem to work in jace, or the
> Gorgon I downloaded doesn't do that.  Here is what the screen looks
> like without "lock in" ...
>
> http://hoop-la.ca/apple2/2011/images/screenshot2011-01-27at2.43pm.png
>
> Another difference on real hardware is that when transitioning between
> graphics modes, the real Apple II fetches the byte of data from the
> previous graphics mode to display in the graphics mode it is switching
> to.  This is a timing thing within one clock cycle.  It can make for
> some strange effects in the transition.
>
> I think that the "top" command indicates that the java process is
> making one of the cores 65.7% busy on my Mac which has a 2 GHz Intel
> Core Duo.  The fan is running.

That's an interesting thing about the video scanner I didn't know.  As
for getting full cycle-accurate emulation, it's on my to-do list to
convert the video scanner to capture the bits during the horizontal
scan period and then actually draw the line during the horizontal
blanking period.  That will help speed things up considerably I
think.  It will be a very time-consuming rewrite of the video logic,
which is why I keep putting it off. ;-)

When you're flipping video modes, it is most likely forcing the
emulator to re-render the whole screen in full.  If sound is running
as well, that could account for why it's eating up so much CPU.  If it
was equally busy sitting idle at the basic prompt, I'd be heavily
disappointed.  Of course, I'm overdue for another optimization round
of the code to squeeze out some more performance but for now I'm just
happy it's working.

-B