Atari 2600 Jr (PAL) compability issues, please advise.

[Mef]

Hello Atarians,

I've recently got a simple (no bankswitching, only 2/4k ROMs) multicart for my Junior and finally got to try a couple titles I've never owned, and also some 4k Demos.

To my surprise, 3 of those are more or less messed up:

In Warlords, the right side of the playfield isn't mirrored, but the numbers in top right corner are! This was the most surprising of the 3 glitches, as I have never seen any compatibility problems with Warlords ever mentioned with PAL Juniors or any of the corresponding TIA revisions.

In Gehirn, the first letter in "Wamma" is misplaced to the left and the "antenna mast grid" is not centered, but also moved to the left.

Tom/Jones by Trilobit is just complete shit...

My Jr is a late (1991) PAL version. After carefully scanning thru various sources on TIA compability issues, I've found nothing that could explain the problem with Warlords. All the ROMs used on the cart were earlier tested in Stella set to PAL mode. Only thing I've found that might shed some light on the issues I'm experiencing, is this piece at 2600connection:

Version 10 is found in 2600 "JR" consoles (both NTSC and PAL) that are made in China after late 1989. The signal timing in the TIA for the shifting pulses for the movable objects seems to be a little off from older versions of the TIA. Therefore when a game starts the shifting process in such a way that some of the shifting pulses happen during the visible part of the screen, the movable objects might be positioned slightly differently. This affects all PAL 7800 consoles, too.

Sounds like what's happening with the Gehirm demo, but doesn't help on messed up mirroring in Warlords.

To make things even more interesting, I've also got a clone system built on UMC AoaC from 1992 and it's showing exactly the same issues.

Please have a look at this short video showing my problems:

https://www.youtube.com/watch?v=WnQeawkHyzg

Could any of the hardware/software masters here confirm that this is just an incompatible TIA/timings for certain operations and I can just forget the whole thing? Or maybe this makes you suspicious of some component failure/deficency, or badly designed multi-cartridge (flash too fast/slow to Read)? I don't really care about the demos, as these are bound to be tricky, but while there are repeated mentions of other titles having trouble with compability, it's never Warlords! And being such a common game, this is driving me insane that noone has documented it yet.

Edited October 4, 2014 by Mef

[Thomas Jentzsch]

Warlord can probably explained. Instead of:

  lda #$11 ; load $11
  sta CTRLPF

it does:

  lda $11 ; load content of $11, which is a collision register. The bits 0 to 5 are unused and usually still contains the value of the address just read.
  sta CTRLPF

This is a common programmer error. Due to the hardware quirk described above it still works on most consoles. Your consoles seems to mask (setting them to 0) those unused bits.

 

I would expect that the ball size is also smaller.

 

[Mef]

Thank you Thomas. Your input is much apprecieated, but unfortunately, also very cryptic to me.

 

Are you saying that the way Warlords is coded, it relies on the first 6 bits of collision register containing the value of previously read address, using it as kind of a temporary "storage"?

Was there any version of this game that wouldn't use that particular technique? Like a " fix for some TIAs" version or something? I know that some games were revised during their lifetime, to remove dependencies on code that might have different outcome depending on the console used, was Wardlords among those as well?

 

Or maybe it's something that can be fixed on the console side? Say, the values of these registers are set on power-on and the switches aren't debounced properly, or need to hold the reset line a bit longer upon start? (I'm just making this up, am I?)

 

P.S. I remember once seing a scan of internal Atari document describing all the incompatibilities they've found between older 2600 and Jr, but can't find it anymore. Does it ring a bell for anyone?

[Thomas Jentzsch]

Are you saying that the way Warlords is coded, it relies on the first 6 bits of collision register containing the value of previously read address, using it as kind of a temporary "storage"?

Yes, exactly. I am pretty sure the developer just forgot the '#' and was just lucky the code still worked.

 

Was there any version of this game that wouldn't use that particular technique? Like a " fix for some TIAs" version or something? I know that some games were revised during their lifetime, to remove dependencies on code that might have different outcome depending on the console used, was Wardlords among those as well?

Not that I am aware about. But try the attached file.

Warlords (fixed).bin

[Mef]

Thanks again Thomas!

 

I won't be able to test it for the time being, as I don't have the equipement to flash the cart (I've ordered it with the ROMs I have sent to the maker), but will try it whenever I have the opportunity to do so.

 

Does anyone have any idea about the document I've mentioned at the end of my previous post?

[Mef]

Hi all, I think the multicartridge is to blame for these glitches, and not the console(s) after all.

I've got my second Junior arrive today, a 84/85 short rainbow one with Synertec/Rockwell chips (looks like the TIA is the same as in PAL Vaders) and it exhibits the same behaviour with Warlords and the Demoes mentioned earlier. Might be that the eprom isn't fast enough, or there is some other quirk in the multicart I'm using.

 

Anyone had bad experences with AMIC A29040B 70?

I'll try to get the schematics for this cartridge I'm using, in case anyone might spot something odd.

[Mef]

Sorry for bumping my own old thread, but I got it all confirmed thanks to Harmony cart.

 

It's the Flash ROM used on the multicart. Same games and demos (using the very same binaries) work flawlessly on Harmony on all of my systems, including the clone one.

I've tried swapping OE/CE and other funny stuff with that Flash-based multicart and the issue persisted. Guess it was all down to Flash acccess time not being up to specs.

Edited June 23, 2015 by Mef