Re: JACE crashes fixed!!!

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

Java UI has its own thread(s), and so as a person interacts with the UI (keypresses, mouse movement, joystick, config changes), that fires off various things that operate outside of the main JACE loop.  This was the source of the race condition I mentioned.  There is a thread for CPU/Video rendering (interleaved just like the real thing).  The video is scaled and drawn in a separate thread to avoid slowing down CPU, and this thread is restarted any time the video renderer is switched out.  The main CPU thread queues sound into a buffer, but sound playback is in its own separate thread as well.  Most other behaviors are event-driven so they usually fire off in the CPU thread, so for example disk reads are processed as the disk i/o ports are accessed.  For dual or quad core machines, the Java VM scales this out rather nicely.  

I'm still trying to find ways to optimize the behavior to reduce the CPU footprint, as it's not nearly as efficient as AppleWin or Apple2PC.  It is, however, a price to pay for the additional flexibility of the code framework and high-level abstraction.  I remember this started off as a scrap of code meant to actually be used as a mockingboard sound tracker.  Then I started Apple game server and decided if I added a few more things I could use it to test Apple game server.  Once Nick and MDJ helped get a few critical pieces working, it started to look like the real deal and now it has a life of its own -- several years later.

Now if I can just get the mockingboard routines running.  :-D

-B

On Thursday, April 26, 2012 11:22:39 AM UTC-5, Marc S Ressl wrote:
> BLuRry wrote:
> > The culprit this whole time was the evil nature of multithreaded code.  It
> > is possible for events to trigger various soft switches, namely a few the
> > might also cause the emulator to reconfigure the MMU memory map.
> > 
> > The toxic part about this is that there was no mutex around memory
> > configuration, and because MMU has a lot of rules, the memory
> configuration
> > starts off with a base layer (aux or main mem) and then layers on the
> > correct pages of Zero-page, language card, rom, etc.  This was implemented
> > perfectly as far as I could tell.  And I was under the impression this was
> > the problem, but I was only kind of right.
> > 
> > The real problem was that memory reconfiguration was occurring while the
> > CPU thread was still running!  Because of this, there was a horrible race
> > condition that was only manifesting in airheart when I was holding down
> the
> > closed-apple to go fast.  And apparently, in some cases when I was
> pressing
> > closed-apple in prince of persia to grab a ledge (I usually hold
> open-apple
> > a lot when playing POP).  All this combined: Race condition.  Solved.
> > 
> > I won't hold my breath and assume this fixed the random prodos desktop
> > crashes, it could just be a buggy program in and of itself (I don't know
> it
> > very well).  However, I did tweak the language card write switch behavior
> > to work a tiny bit more correctly, so it could fix other problems.
> > 
> > Anyway, JACE is working well enough to play two of the games that push the
> > //e to the max and much help to all who helped keep me going with ideas. 
> I
> > swear I almost gave up a couple of times on this.
> > 
> > A build will be release again soon, I have a mockingboard routine to debug
> > now.
> > 
> > -B
> >
> 
> Brendan, I'm glad you fixed it :-). yeah those are hard!
> 
> How are you using multithreading? In OE I'm using four threads, a GUI
> thread, a sound thread, a video thread and an emulation thread. I thought
> about using even more threads (one for each emulation), but I found no way
> to make the plumbing simple and effective :-(.
> 
> With the best wishes,
> 
> Marc.-