> I'm curious, how do you expect to test for this? Is it going old-school, with the oscilloscope and a voltammeter?
Nah. Just put up a stable pattern on the screen and then try long sequences of non-interruptible instructions and see if it jumps. :-) I don't really have a good oscilliscope for this at the time, nor do I have my Inty opened up.
We sell Spatulas, and that's all!http://spatula-city.org/%7Eim14u2c/http://sdk-1600.spatula-city.org/http://spacepatrol.info/
From: DZ-Jay <dz@...>
Sent: Tue, November 2, 2010 12:16:16 PM
Subject: Re: [intvprog] Pac-Man level speed fixed!
On Nov 02, 2010, at 13:02, Joe Zbiciak wrote:
> Ok, I just tried this version without any other patches, and it seems to
> eliminate the remaining "jump glitch." Bravo! I guess that other section I
> worried about wasn't a problem.
I'm thinking of patching the other block if anyway. My intention was to update the RAM position variables and the STIC shadow in one go to ensure their mutual consistency; but I guess the risk of disparity is minimal if I break up the critical section: since an IRQ at that point will just add the MOVE_PACMAN() task to the queue and not call it directly, the function won't be re-entered, so there is little chance (if any) that the position will be updated before the call to __UPDATE_PAC_POS ($599D).
> The section you show below shouldn't delay BUSAK by more than 56 cycles (6 SLRs
> followed by the ADDI). I'm starting to suspect that arithmetic instructions
> (ie. MVI@, ADD@) that update R7 might be non-interruptible. Time for an
> exploratory test, I guess.
I'm curious, how do you expect to test for this? Is it going old-school, with the oscilloscope and a voltammeter?