Re: Jace: RamWorks III in the works

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

On Saturday, December 8, 2012 11:42:46 AM UTC-6, Michael J. Mahon wrote:
> BLuRry <brendan.robert@gmail.com> wrote:
> 
> > Doing this cleanly has taken a little more work than I anticipated, but
> 
> > mostly because I want to keep a memory management model that can be later
> 
> > adapted to implement a //gs one day -- not that I'm planning on it or anything.
> 
> > 
> 
> > The RamWorks card is easy enough to implement, but for some reason I have
> 
> > a really odd bug that the MMU is not mapping in the aux pages properly --
> 
> > all reads and writes are still going to the main memory instead of AUX. 
> 
> > I don't get why though because the memory mapping function that selects
> 
> > aux pages hasn't changed (and in fact, still works when ramworks is disabled.)
> 
> > 
> 
> > Eventually I'll find the culprit and get it working.  The old
> 
> > implementation has been refactored as an extended 80-column card and is
> 
> > still functional.  Self tests pass, etc.  Just not sure why things go
> 
> > bonkers with the RamWorks side of things.  Grrrrrr....
> 
> > 
> 
> > Once I get the bugs out I'll post a new build.  Seems I introduced two
> 
> > new bugs -- Joysticks disappeared from the config panel (??) and there is
> 
> > an odd race condition that the computer starts before the rom is loaded
> 
> > causing it to hang sometimes.
> 
> > 
> 
> > Fingers crossed, I hope to get this all resolved soon.
> 
> > 
> 
> > -B
> 
> 
> 
> Sleep on it. 
> 
> 
> 
> The problem will turn out to be both obvious and trivial, and you'll want
> 
> to slap your forehead. ;-)
> 
> 
> 
> -michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

Thanks!  Yes it was a facepalm moment -- I had copied the memory object reference as a static variable in a few unimportant places such as the CPU emulation.  So go figure it was hanging on to the wrong reference.  My final clue was that the 00 FF pattern was showing on the 80-col aux page but I wasn't initializing the aux page with that pattern in the new implementation -- so it was referencing the wrong object and so on.

Self-test passes and Airheart doesn't crash.  (Airheart uses Aux page LC1 and LC2 so it's a pretty good test)  I'm going to run AE's diagnostics next to see how it does with the memory detect.

One thing I have implemented but not hooked up is the bank order for AE cards since the banks are not exactly sequential.  It might not matter though and using a strictly linear bank order might work without issue.  Are there any programs that made assumptions about what banks are there or not?  Or did the programs all correctly scan for existing banks first?

-B