Timing weirdness in Battlezone radar

[Dan Piponi]

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

[Thomas Jentzsch]

Have you looked at the code using Stella's debugger? REFP0 is written at scanline cycle 50.

 

BTW: What are columns?

[DirtyHairy]

I have developed an emulator for 6502 based systems called 6502.ts that includes a VCS emulation (this being is the only full system emulated right now). Mine is written in Typescript (a statically typed flavor of Javascript) targets the web browser, and the VCS frontend happens to be called "stellerator" If you're curious, you can find the source on Github (https://github.com/6502ts/6502.ts) and a playable build here: https://6502ts.github.io/stellerator/ TIA emulation is pretty accurate at this point, and I have since been collaborating with Stephen Anthony (the Stella maintainer) on porting the core to Stella.

 

I remember having issues with Battlezone from time to time myself. Some things that I remember from the top of my head are:

• The top and bottom parts of the dial are P0 at double width
• The left and right parts are two close copies of P0, the right one being reflected
• Relative positioning between both "modes" is done via HMOVE
• There is no delay on RESPx, but there is a one clock delay in drawing wide players that you have to get correct for this trick to display correctly

If are unsure of the delays, you can take a peek at the 6502.ts source (or the new Github repo of Stella https://github.com/stella-emu/stella). The delays I ended up with are enumerated at the top of Tia.ts and Tia.cxx.

Edited January 1, 2017 by DirtyHairy

[Dan Piponi]

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 :-)

[eshu]

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 :-)

 

WSYNC and VSYNC work quite differently.

 

WSYNC waits for the horizontal blank/sync period so leaves you at cycle 0

VSYNC is used to set a signal, but doesn't wait for anything - so STA VSYNC is just a normal 3 cycle operation from that point of view

 

In an emulator I would expect that you would want to synchronize what you are displaying based on when bit one of VSYNC is set high

[Dan Piponi]

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?

[eshu]

If you tell me the address I'll have a quick look in stella debugger - but I would guess VSYNC just happens to be being set there, and most TV's are ok with that - does it also get turned off at cycle 15? - It probably should be set straight after WSYNC for three scanlines

 

i.e.

lda #%00000010

sta WSYNC

sta VSYNC

sta WSYNC

sta WSYNC

lda #0

sta WSYNC

sta VSYNC

[Dan Piponi]

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

[eshu]

Nice one

[DirtyHairy]

Sorry about accidentally stealing your name. I did some work related to nuclear fusion a while back and really got into stellarators :-)

No worries, I wouldn't consider it stealing, and in any case, we have the spelling to differentiate I have been working as a researcher on theoretical physics before leaving academia, so I have been playing the same pun.

 

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.

For ball and missile sprites, there is a delay of four color clocks between the decode of the "start drawing" signal and the first pixel on screen. For 8 pixel players, it is five clocks, and for wide players, it is six clocks. The four and five clock delays are documented in Andrew Tower's notes. The six clock delay isn't, but you can find references to it here and there over the forums. If you get this wrong, battlezone will look like this:

 

Edited January 2, 2017 by DirtyHairy

[Dan Piponi]

If you get this wrong, battlezone will look like this:

 

 

 

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

[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.)