Re: Language card softswitches and the gospel of Sather

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

On Wednesday, December 5, 2012 8:05:53 PM UTC-6, BLuRry wrote:
> I'm trying to understand the explanation of the language card softswitches as described by Sather (5-27, 5-28).  How many flip flops is he talking about and exactly what all resets these flip flops?  I need to make sure I capture the complete state machine of these, because it seems I haven't gotten it quite right just yet.
> 
> 
> 
> I started finding Jace crash bugs in Airheart (ugh... again.  I know I had it working fine before!) and then I found the rom self-test died with an error indicating an MMU bug.  When I commented out the (likely incorrect) implementation of the dual-access nature of the flip-flops (meaning, I just changed them to work like single-access flip-flops), I found that the self-test passed.  It didn't fix problems in Airheart unfortunately, and really it might have just made things worse overall.
> 
> 
> 
> How does AppleWin handle these?  (you never hear about much software failing there. :-)
> 
> 
> 
> -B

Well, turns out that:

1) My softswitch implementation was fine.  The only thing I changed to make it pass self test is the write counter resets after two accesses so now it behaves like a flip-flop.  Write-enabling LC ram requires two accesses in Jace and this does pass the self-test just fine.  It's probably not a necessary feature.

2) I had a couple of LC-related softswitches incorrect in terms of what addresses read them.  I fixed that.  Odd that there's no way to read the state of the LCWRITE state (if you're writing to LC or not)

3) I found that I didn't implement the c07f read switch for dhires.  That's fixed.  Not sure if any software ever used it.

4) All of this and Airheart was still breaking. :-(  Turns out that the activation/deactivation of paddle buttons was causing some funked-up race condition in the emulator and it was totally screwing up the program counter (!)  I still don't know how that could possibly happen.  But what I do know is the recent synchronization methods I came up with (Computer.pause and Computer.resume) operate fast enough that I was able to fix the bug using these methods and not have to come up with anything more clever.  Gameplay is unaffected since the synchronization is on a millisecond level.

I suppose this fixes other crazy game-related crashes that were occurring in the source after my recent changes.  Once I do a little more validation, I'll post another build.  I'm just happy to have this cleared up since I didn't want to be heads down fixing bugs -- it's distracted me from much more entertaining goals to say the least of it.

-B