Dan Piponi

Just a small observation: I tried Battlezone on an Atari Flashback Portable and...guess what...it has the same misplaced pixels I was getting. (Mine are all fixed now BTW.)

Do you think it was a bug? Intended to be "SBC #$15" but it worked anyway so nobody noticed.

In Haunted House I see this bit of code being executed (in both Stella and my own emulator): F44E INY F44F SBC $0F F451 BCS F44E That SBC is reading from address $0F. This is in TIA, but there is no readable register there. So what does this read? My own emulator returns zero and so the code hangs. But Stella seems to not hang. When I read the Stella source it looks like this returns (depending on settings) something randomised or what was left on the data bus from before (though I don't fully understand how something can linger on the data bus). As the last thing on the bus was (I think) the $0F of the SBC instruction, it ends up subtracting $0F. That seems pretty weird. Anyone know what's going on here? Im the end I hard-coded a read from $0F to return $0F in my emulator and now I can play Haunted House in it. -- Dan

Hey! That's what mine looks like now :-)

eshu, Ah! I got it. The code in Battlezone looks like: F291 STY WSYNC F293 LDA #00 F295 STA VSYNC I made the mistake of thinking that VSYNC reset the pixel clock to zero as it starts a new frame. But it doesn't. And the LDA and STA here add up to 15 pixel clocks after the WSYNC. All makes sense now - and Battlezone is now running fine apart from two stray pixels that DirtyHairy's answer probably explains. -- Dan

Moonsweeper, Yes, I understand that WSYNC messes with the CPU clock and VSYNC doesn't. But why the 15 pixel clocks (5 CPU clocks) straight after STA VSYNC? That instruction takes 3 CPU clock cycles and performs the actual write on the third cycle. Where does 15 come from?

I was trying to avoid comparing to Stella as that's cheating :-) Anyway, using Stella revealed something I didn't know. I knew that immediately after a WSYNC the color clock is at 0. (I used the word 'columns' interchangeably with color clock as I'm thinking in terms of scanning across columns of pixels.) However, immediately after a VSYNC you're at color clock 15. As Battlezone sets RESP0 in the first row after a VSYNC I was off by 15 pixels. That explains explains (most of) the 130 to 146 discrepancy. Weird I hadn't noticed this in other games yet. I don't quite get what you mean by a one clock delay on wide players but maybe that explains the missing 1 from 145 to 146. (Though it might not really be missing, I wasn't counting exactly.) I'll have a peek at your code though. Thanks. Sorry about accidentally stealing your name. I did some work related to nuclear fusion a while back and really got into stellarators :-)

I'm working on a 2600 emulator. (Written in Haskell, a language for which large amounts of mutable state are the worst case scenario, but challenges are fun: https://github.com/dpiponi/Stellarator).At this point a lot of games seem to run reasonably well. But I'm having trouble understanding how the radar scope at the top of the Battlezone screen is rendered. It uses a nice trick where the two halves of the scope are a normal and reversed version of a doubled player 0 sprite giving a double width symmetric sprite. What I'm having trouble with is that in the real thing, the sprites start rendering at around column 146 even though RESP0 is written before column 130. Has anyone looked at this code and do they know what I'm missing? Is there some other delay in the system I should know about? I can get the scope to look better by putting a massive delay into the RESP0 register, but that messes up just about everything else. I can post disassemblies and traces if anyone might find them useful. Every time a weird quirk pops up in rendering there's always a neat story hidden in the disassembly. Yesterday I discovered the trick where Pole Position whacks three registers in three clock cycles using the BRK instruction. It revealed a bug in the timing of my BRK emulation. Thanks