Re: Need a really good ram unit test program

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

Not a lot of update on this one.  The frustrating thing is that POP crashes randomly, so there's no easy way to reproduce the issue.  I've been able to play POP for 15 minutes, all the way up through level 3, without having a crash.  And then sometimes it crashes when I walk into the first room with a guard in it.

I've been doing various tweaks but nothing seems to have helped much.  Airheart seems to play for a few minutes without crashing, so maybe there is some improvement?  Anyway, I decided to log the bankswitches to see if I could find a pattern and all I can see so far is that POP does a LOT of bankswitches, most of which result with no issue that I can discern, and this includes many combinations of AUXZP, RAMWRT, RAMRD, 80Store, Page2, and the three LC switches.  The only thing that stands out is that when POP and Airheart both crash, it seems to correspond in some cases with the CPU encountering a BRK command.  Are there some cases where toggling different switches disables others?  I've re-read Sather and haven't found any gap in my MMU implementation so far.

I've seen BRK used to make software interrupts, but it wasn't until I read the POP source code that I found Prince of Persia only uses BRK in a few sparse pieces of code, but none of those treat BRK as a 2-byte opcode instruction.  This leads me to consider the BRK opcode in POP might not be happening for a legitimate reason, and is certainly not for a branching-style software interrupt.  If I'm lucky, I can use this to trace back to the cause of a crash.

The only other thing that comes to mind is that there could be some random case where I didn't implement an opcode correctly.  At this stage I find it almost hard to believe, but I'm willing to entertain any notion that could lead to a bullet-proof //e emulation.

-B

On Friday, April 20, 2012 9:20:35 AM UTC-5, BLuRry wrote:
> This is AWESOME feedback David, thank you!  I love any excuse to play Ultima IV, especially when I can say I'm playing Ultima IV... For science!
> 
> To your point, I recently (back in Feb) found that my interrupts were incorrectly implemented when I was adding mouse support.  I believe my current implementation is correct, provided that the IRQ does not alter the MMU switches.  I think that the interrupts work, because various mouse-based programs are working that do not use polling.  Among things I've tested: Dazzle Draw, Apple // Desktop, GEOS, Chipwits.
> 
> I saw a great conversation involving Mr. Mahon and Oliver Schmidt a long time ago discussing the MMU and the reset vector, but I implemented that behavior (well, I tied the softswitch resets to the reset vector more directly).  If I can't get Ultima IV to crash repeatedly, then I might have to suck it up and write some actual assembler code.
> 
> -B
> 
> 
> On Friday, April 20, 2012 8:25:10 AM UTC-5, David Schmenk wrote:
> > On Thursday, April 19, 2012 9:32:34 PM UTC-7, BLuRry wrote:
> > > Not to test memory, but really what I need is the ability to test the behavior of the MMU and all the softswitches related to it.  I keep getting random crashes in JACE in games that use AUX memory, and sometimes Prodos as well.  Though it's speculative, I think the most prudent thing to do is assert what is proper MMU behavior with a software-based test and compare results to a running physical machine.  Since there are some switches (for LC) that require being accessed TWICE before they allow writes, these are the sorts of things that should be tested in all, or at least most, possible combination.
> > > 
> > > Specifically, I get the impression that aux ram is being switched back to main ram and the program counter is not picking up the right opcode at the right time, or from the right place.  But its only a hunch.  It could be a similar issue but with language card banks.
> > > 
> > > Before undertaking such a labor of pain.. er... love, I wanted to see if anyone knew of any good diagnostic programs that tested language card ram and aux ram -- I might get what I need from something off the shelf.  
> > > 
> > > Any advice or tips greatly appreciated!
> > > 
> > > -Brendan
> > 
> > Hi Brendan-
> > 
> > Can you isolate the failure to ether AUX RAM of LC RAM access?  The soft switches for AUX RAM are pretty straight forward.  When writing Appalm, Ultima IV gave me fits with its LC access (more from a performance standpoint than functionality).  It keeps its graphics assets in the second bank of the LC and ping-pongs constantly between the two banks.  I would think if you can run Ultima IV, your LC code should be pretty solid.
> > 
> > Sometimes writing a simple test to try out the combinations one at a time is useful.  I had to do this for the LC mode where LC RAM is write enabled, but reads from ROM.  ProDOS does some clever tricks to figure out how the LC is currently configured (no softswitches to read) before calling into the guts of ProDOS in the LC.
> > 
> > My second thought involves interrupts.  Is JACE emulating interrupts?  I have run into issues with the unenhanced IIe and interrupt interaction with AUX memory usage.
> > 
> > Sorry I don't have anything more formal.
> > 
> > Dave...