How Galaxian hides enemies ?

[m.maccaf]

Hi,

 

I wrote an Atari 2600 emulator, while testing games, I noticed that Galaxian's enemies are not drawn correctly, in that specific case all rows are filled with enemies and also I can see a column of enemies on the left side of the screen that should not be there.

The emulator should work well, with positions, vertical delay and priorities, so I looked at the disassembly with Stella but I can't undestand what kind of "side effect" causes the enemies to hide, the sprite bitmap is set right after WSYNC and never changes on a scanline, there is a sequence of STA RESP0 / STA NUSIZ0 that, afaik, doesn't have any effect on the display, or better, it should display the player not hide. Maybe it is something related to the TIA delay queue, but I can't understand what, even running step-by-step with Stella I don't understand what happens.

 

Can someone explain how the enemies are hidden in that game ?

 

Thanks.

 

Edit: added screen capture for reference.

Edited April 29 by m.maccaf

[+SpiceWare]

There's some links that should be helpful at Minidig, which references a lot of useful information from the old Stella mailing list. 

 

Specifically check the Tricks page which has a link to this explanation of the RESPn trick used in Galaxian.

[m.maccaf]

Thank you for the links.

I've read it a bit and still doesn't make any sense to me. To hide the sprites, I mean, I understand that multiple RESPx hits may display more copies than expected, but why a 'STA Dummy' in between hides the sprite is beyond my comprehension.

I'll continue to read, and compare the source of other emulators (if someone has a pointer to the exact code portion that handles this trick is very welcome).

 

[JetSetIlly]

6 hours ago, m.maccaf said:

I'll continue to read, and compare the source of other emulators (if someone has a pointer to the exact code portion that handles this trick is very welcome).

Do you have a screenshot of the problem? I'm finding it difficult to picture what the side-effect looks like.

[Thomas Jentzsch]

6 hours ago, m.maccaf said:

Thank you for the links.

I've read it a bit and still doesn't make any sense to me. To hide the sprites, I mean, I understand that multiple RESPx hits may display more copies than expected, but why a 'STA Dummy' in between hides the sprite is beyond my comprehension.

It doesn't hide a copy, but it doesn't create a new one. 

 

BTW: If you want to test your emulator for correctness, try the attached SI-11 ROM. You can shot the invaders individually or use left difficulty = A which randomly removes and adds them.

SI-11 (230112)test.bin

Edited April 28 by Thomas Jentzsch

[+SpiceWare]

This topic might help, especially @SeaGtGruff's explanation on page 2 and the replies that follow.

 

 

 

[m.maccaf]

16 hours ago, JetSetIlly said:

Do you have a screenshot of the problem? I'm finding it difficult to picture what the side-effect looks like.

Added to the first post.

The top row should show two white enemiens instead of 5.

There is the leftmost column that should be completely hidden.

 

16 hours ago, Thomas Jentzsch said:

It doesn't hide a copy, but it doesn't create a new one. 

 

BTW: If you want to test your emulator for correctness, try the attached SI-11 ROM. You can shot the invaders individually or use left difficulty = A which randomly removes and adds them.

SI-11 (230112)test.bin 4 kB · 4 downloads

That's what puzzles me, how it doesn't create one when, AFAIK, the copy is already rendering ?

I tried to modify my code removing all the sprite optimizations and still it renders sprites where should be hidden, now some of them are displaying only the first n pixels (see screen capture).

 

I can't use your binary because it uses undocumented/illegal opcodes (0C NOP and C7 that I can't remember what it is... and maybe others, don't know).

The emulator runs on a microcontroller (no, not on a RPi Pico) and I had to remove all illegal opcode implementations to make room for the code (so far none of the games I have tested uses illegal opcodes).

 

[m.maccaf]

12 hours ago, SpiceWare said:

This topic might help, especially @SeaGtGruff's explanation on page 2 and the replies that follow.

Ah... yes, that's it (hope to understand correctly).

Now the problem is how to implement it in my code...

 

Thank you.

 

[JetSetIlly]

6 hours ago, m.maccaf said:

Added to the first post.

The top row should show two white enemiens instead of 5.

There is the leftmost column that should be completely hidden.

Thanks. I'm not sure there's an easy answer to this because there's a lots going on with the player objects, particular when you throw NUSIZ into the mix.

 

However, I can replicate your problem in Gopher2600 by forcing the player to begin drawing (ie. the scancounter starting) on the same colour clock as when the RESPx has completed. Screenshot below.

 

It's difficult to generalise what the exact problem is in your case but hopefully that's a clue as to what's happening.

 

Summary: Investigate the conditions under which the player object begins drawing. Players should not begin drawing on a player reset unless the scancounter was in the process of being latched

 

 

 

[m.maccaf]

17 hours ago, JetSetIlly said:

Summary: Investigate the conditions under which the player object begins drawing. Players should not begin drawing on a player reset unless the scancounter was in the process of being latched

Yes my current code begins drawing objects immediately at the calculated horizontal clock (that is +5 or +4 related to the RESPx clock hit, plus all the weird calculations related to when it is hit), because that's what I've read from every document and source code I've seen. This is the first time I read that there are delays on the first copy and I'm still struggling to understand how this delay is handled in existing emulators, my current reference is javatari.js, I'll look at your source even tough I don't know much about Go.

 

I fear that fixing this thing in my current implementation is nearly impossible, too much code to add (running out of code space).

I think that I need to take another approach to render the TIA graphics, I found this source https://github.com/jigo2600/jigo2600 that also have a very detailed description of the TIA internals, and being written in C++ maybe I can step though it more easily.

This will take a loooong time, this is the 4th or 5th time I rewrite the TIA code and I'm a bit tired... the games I'm more interested in are working, I can live without Galaxian for now...

 

Thank you all for the help.

 

[JetSetIlly]

22 minutes ago, m.maccaf said:

Yes my current code begins drawing objects immediately at the calculated horizontal clock (that is +5 or +4 related to the RESPx clock hit, plus all the weird calculations related to when it is hit), because that's what I've read from every document and source code I've seen. This is the first time I read that there are delays on the first copy and I'm still struggling to understand how this delay is handled in existing emulators, my current reference is javatari.js, I'll look at your source even tough I don't know much about Go.

There's no additional delay for drawing the first copy of the player object. But it does look to me like the player is drawn at the moment the RESPx resolves, which shouldn't happen - the first copy is not drawn until the following scanline (unless the position is reset again in the interim). But without knowing what the rest of the TIA implementation is doing it's hard to diagnose exactly.

 

22 minutes ago, m.maccaf said:

I fear that fixing this thing in my current implementation is nearly impossible, too much code to add (running out of code space).

I think that I need to take another approach to render the TIA graphics, I found this source https://github.com/jigo2600/jigo2600 that also have a very detailed description of the TIA internals, and being written in C++ maybe I can step though it more easily.

This will take a loooong time, this is the 4th or 5th time I rewrite the TIA code and I'm a bit tired... the games I'm more interested in are working, I can live without Galaxian for now...

I've not heard of Jigo2600. I'll take a look at that.

 

But good luck in your coding. It sounds like a fun project and an implementation targeting a microcontroller would be good.

Edited April 30 by JetSetIlly