At one point during the port I had to disable (skip) the demo mode because bugs at the time would cause it to crash which of course hampered debugging of the splash animations for one, and also the game play indirectly. Being so focused on completing the game play, I'd completely forgotten about this and when I re-enabled it today, I was reminded of the bug where the player base just moves to the right side of the screen and sits there.
Fortunately it took about 2 minutes to find and fix; yet another endianity bug in a small block of data that is copied to RAM on start-up, that had slipped under the radar, it not being commented in the disassembly. So bug #13 done and dusted.
Rather than pursue the elusive 2-player issue right now, I decided to get the disk version working and add appropriate splash screen and README.TXT content. So the minute I fix what I firmly believe is the final bug, and test on real hardware, I can release an Alpha for general consumption.
Stay tuned, we'll be back shortly.
UPDATE: My daughter wanted to play horse Duplo with my wife, so I snuck away and managed to find the last bug - a register value that was being overwritten by 6809-specific implementation. That register contained the delta-x value for moving the invaders, which should have been either +/-2, but was overwritten with -4 every time (I didn't notice). Hence the invaders not wiping properly. Bug #14 squashed.
Now to fire up my brand new, as-yet unused EPROM eraser and see if it runs on real hardware!
UPDATE #2: I actually found a blank EPROM so no waiting for the eraser, but an unexpected result. The game runs, but the invaders aren't firing back at all, and it seems the player's shot is too fast. Reminds me of an earlier observation during the porting process. Interesting... without looking into it, I do have one guess.
UPDATE #3: Well my theory on why it's not running on real hardware didn't pan out, so right now I'm stumped. Mind you, I've spent about 2 minutes looking at it, so I likely haven't exhausted all avenues just yet. I'll need to spend at least another 2 minutes before I get to that point...
Hmm... A bit of code accessing ROM or something in $FE00 or above? Interrupts not firing at the expected time? DP being changed in an interrupt? Stack area not big enough?
ReplyDeleteCan it run in CoCo 2 mode on Xroar? That's more accurate than most emulators.
At this stage, while I can't be 100% positive, I don't think it's any of the above. My first guess was the timer interrupt not firing, but emulating that in MESS produced completely different results. DP is very carefully managed, and the stack is an order of magnitude larger than the original, so I'm ruling those out.
ReplyDeleteNext suspect was unintialised RAM, but then I remembered that I'm zeroing RAM to circumvent a 'feature' in the original code.
Won't run in Coco 2 mode as-is; not being intimately familiar with the Coco2 I'm not sure if it can be made to do so. Atm runs in 256x225 (1BPP) mode, and requires both VBORD and TIMER interrupts.
I see. I misread an earlier post and thought you were implementing the second interrupt as an offshoot of the first, rather than as a proper interrupt. The CoCo 2 can't use the timer interrupt (it can do HIRQ, but you can't specify the line, so it triggers at every single one which is nearly useless!) It can't do anything more than 256x192, although would having 33 pixels chopped off the bottom prevent the debugging of this issue?
ReplyDeleteThis comment has been removed by the author.
ReplyDelete