Extra Terrestrials ROM released, loose carts, follow up story and more

[+stephena]

I'm ok with patching the ROM - as long as it we keep the naming etc. distinctly different. The game, as it is, DOES play properly on real hardware. Now that we *think* we know what the issue is, if this spurs on the fixing of Stella by making it technically more complete that's great! On the other hand, I understand it could be a lot of work to address only 2 or 3 ROM's. Is it possible to "fake" Stella into returning the RSYNC values Extra Terrestrials is looking for? (what am I saying, emulation is really a big fake lol).

 

It may be possible to add a special case for this ROM, once we conclusively determine exactly what the issue is. Older version of Stella worked that way, but it was a fragile area of the code since new ROMs popped up that broke the assumptions. I wouldn't necessarily mind doing it as long as (a) it is a temporary fix and more importantly (b) it doesn't break any other ROM. IMHO, these types of ROM tweaks aren't proper emulation, but kludges to get things working. And eventually the emulation must be extended to take care of the issues natively.

[Eckhard Stolberg]

EDIT: Scratch that last comment. There's no literal access to RSYNC/$03, but it does happen just as you say. And in Stella, it shows a zero being poked in RSYNC. However, it does that for many other ROMs I've tested too. I guess in most of the other ROMs, the lack of RSYNC functionality doesn't affect the emulation.

The difference is that the other games all do a WSYNC again before positioning the players. Therefore Stella knows where in the line it is supposed to be when RESPx gets triggered. I think RSYNC is the same as WSYNC except that the CPU isn't halted, because the new scanline starts immediately.

 

When you look at the loop at L13AF you'll notice that it triggers RSYNC 10 cycles or 30 pixels (I miscounted the loop in the last post) after it triggers WSYNC. This effectively starts a new scanline, which Stella doesn't notice, because it doesn't handle accesses to RSYNC. The emulator still counts it's current position in the line from the WSYNC not from the RSYNC. Therefore it positions the players 30 pixels too far to the right.

 

To fix the problem in Stella you could execute the same routine for RSYNC as you do for WSYNC. But since you don't have to halt the CPU emulation, you only need to render the current scanline to the position where the RSYNC happens and fill the rest with black pixels before resetting the TIA emulation for the next scanline.

 

I'm sure there are plenty of sideeffects when triggering RSYNC in the middle of the scanline, but since almost all current games only trigger RSYNC during their initialization loop, I guess Fatal Run would be the only one that might have problems with changing Stella this way.

[+stephena]

EDIT: Scratch that last comment. There's no literal access to RSYNC/$03, but it does happen just as you say. And in Stella, it shows a zero being poked in RSYNC. However, it does that for many other ROMs I've tested too. I guess in most of the other ROMs, the lack of RSYNC functionality doesn't affect the emulation.

The difference is that the other games all do a WSYNC again before positioning the players. Therefore Stella knows where in the line it is supposed to be when RESPx gets triggered. I think RSYNC is the same as WSYNC except that the CPU isn't halted, because the new scanline starts immediately.

 

When you look at the loop at L13AF you'll notice that it triggers RSYNC 10 cycles or 30 pixels (I miscounted the loop in the last post) after it triggers WSYNC. This effectively starts a new scanline, which Stella doesn't notice, because it doesn't handle accesses to RSYNC. The emulator still counts it's current position in the line from the WSYNC not from the RSYNC. Therefore it positions the players 30 pixels too far to the right.

 

To fix the problem in Stella you could execute the same routine for RSYNC as you do for WSYNC. But since you don't have to halt the CPU emulation, you only need to render the current scanline to the position where the RSYNC happens and fill the rest with black pixels before resetting the TIA emulation for the next scanline.

 

I'm sure there are plenty of sideeffects when triggering RSYNC in the middle of the scanline, but since almost all current games only trigger RSYNC during their initialization loop, I guess Fatal Run would be the only one that might have problems with changing Stella this way.

 

Sounds like a reasonable explanation. I'm too late in the release cycle for 3.7 to address this, but I'll try to find time after the next release (mid May or so) to look into this in more detail.

[Omegamatrix]

I wrote a test rom to help determine how Stella should handle RSYNC. It can be found here, so as not to derail this thread:

 

http://www.atariage....-and-emulation/

 

One of the other unusual things Extra Terrestrials does is update HMP0 too early after HMOVE.

 

L1366 SUBROUTINE
lda	#$03	  ; 2  same as #$00 for HMPx, was #$30 (LEFT 3) meant to be used?
sta	HMP0	  ; 3
sta	HMP1	  ; 3
sta	RESP0	 ; 3  strobe
sta	RESP1	 ; 3  strobe
sta	WSYNC	 ; 3
;---------------------------------------
sta	HMOVE	 ; 3
lda	#$00	  ; 2
sta	HMP0	  ; 3  too early after HMOVE!
lda	#$0F	  ; 2
sta	alienHpos ; 3

[Eckhard Stolberg]

One of the other unusual things Extra Terrestrials does is update HMP0 too early after HMOVE.

That's true, but as you pointed out, writing $03 into the HMPx registers is the same as writing $00. Therefore writing $00 into HMP0 later doesn't change anything. Even though the write occurs during the time where the HMOVE updates are still in progress, it has no effect, since no HMOVE pulses are fed into the position counter for player 0.

[+stephena]

The next release of Stella includes a fix for this ROM, as well as basic RSYNC write functionality. It works on most test ROMs we've tried, but not on all. I'm hesitant to add any more to this area, since the TIA code is being reworked (again), and we'll probably come up with more accurate emulation when that happens.

[awhite2600]

Great news. Looking forward to Stella users being able to try out Extra Terrestrials.

[+stephena]

To anyone reading this and responsible for the ROM: I'd like to get the ROM info added to Stella properties database. The info I need is as follows:

Cartridge_Manufacturer

Cartridge_ModelNo

Cartridge_Name

Cartridge_Note

Cartridge_Rarity

 

I've also sent this request to the maintainers of the museum webpage mentioned in the first post in this thread.

[+stephena]

Stella 3.8.1 is now released, which includes a fix for this ROM.

[kevtris]

Are there instructions for this game? I poked around the two websites linked in this thread and in the other bigger thread, but I could only find a zip of the ROM and pictures of an owners manual, but no actual instructions for playing the game. I got it working on my FPGA 2600 so I was wondering if a few things I saw were legit or not. I think it's right but would be nice to know for sure.

[awhite2600]

Are there instructions for this game? I poked around the two websites linked in this thread and in the other bigger thread, but I could only find a zip of the ROM and pictures of an owners manual, but no actual instructions for playing the game. I got it working on my FPGA 2600 so I was wondering if a few things I saw were legit or not. I think it's right but would be nice to know for sure.

We don't have any instructions. The Personal Computer Museum has so far only obtained three loose carts - two release versions and an unfinished version. The original programmer and owners of the company that made the game don't have any of the instructions or boxes.

 

Trial and error gameplay suggests that the Extra Terrestrial's goal is to eat eat the "candy" and avoid the "ranger" Player 2 controls the "ranger" who's goal is to capture the ET. The game is two players only. Game Select allows you to choose from different alien images. That's about all we know.

[kevtris]

We don't have any instructions. The Personal Computer Museum has so far only obtained three loose carts - two release versions and an unfinished version. The original programmer and owners of the company that made the game don't have any of the instructions or boxes.

 

Trial and error gameplay suggests that the Extra Terrestrial's goal is to eat eat the "candy" and avoid the "ranger" Player 2 controls the "ranger" who's goal is to capture the ET. The game is two players only. Game Select allows you to choose from different alien images. That's about all we know.

 

Thanks, yeah that's what I gathered. The part I was unsure about was there seems to be invisible walls in several places that the ET hits and it causes the screen to flash pink. They seem to stay in the same places game to game and are more or less randomly scattered around the screen. I didn't see the ET hit them in the youtube video but that might be because if you know where they are, they are easy to avoid.

[+stephena]

Thanks, yeah that's what I gathered. The part I was unsure about was there seems to be invisible walls in several places that the ET hits and it causes the screen to flash pink. They seem to stay in the same places game to game and are more or less randomly scattered around the screen. I didn't see the ET hit them in the youtube video but that might be because if you know where they are, they are easy to avoid.

 

The same thing happens for me in Stella, and on a Harmony cart.

[awhite2600]

Thanks, yeah that's what I gathered. The part I was unsure about was there seems to be invisible walls in several places that the ET hits and it causes the screen to flash pink. They seem to stay in the same places game to game and are more or less randomly scattered around the screen. I didn't see the ET hit them in the youtube video but that might be because if you know where they are, they are easy to avoid.

The same thing happens for me in Stella, and on a Harmony cart.

I forgot about the invisible walls. When I spoke to the programmer he couldn't remember if they were there by design or the result of a programming bug.

[RevEng]

On 5/2/2012 at 9:31 PM, HammR25 said:

I get weird collision detection errors on my CC2 as well. I assume I'm not suppose to hit invisible walls in the middle of the play field unless I'm just using the wrong bankswitch file.

Hopefully this necropost can be forgiven, for providing new information.

 

It was recently pointed out to me by @Kitrinx that the 7800 has phi0 being generated by Maria instead of TIA *and* this would impact correct RSYNC behaviour. So I gave this ROM a try via Harmony Concerto. I have the same result as you, which matches the rsync-not-properly-emulated result described earlier in the thread. (the alien is displayed quite a bit to the right of the dots eaten, walls are similarly offset from the actual player display) So I believe this result is a general 7800 thing.

 

Homebrewers experimenting with or otherwise relying on RSYNC should be aware of this potential issue on 7800s.

 

[Omegamatrix]

4 hours ago, RevEng said:

Hopefully this necropost can be forgiven, for providing new information.

 

It was recently pointed out to me by @Kitrinx that the 7800 has phi0 being generated by Maria instead of TIA *and* this would impact correct RSYNC behaviour. So I gave this ROM a try via Harmony Concerto. I have the same result as you, which matches the rsync-not-properly-emulated result described earlier in the thread. (the alien is displayed quite a bit to the right of the dots eaten, walls are similarly offset from the actual player display) So I believe this result is a general 7800 thing.

 

Homebrewers experimenting with or otherwise relying on RSYNC should be aware of this potential issue on 7800s.

 

Now that is important and good info. Thank you!