Modifying NTSC machines to run PAL software

[adam242]

Okay, I'm starting to go off-topic in a couple of threads (including one of my own) with this idea, so I'm moving the discussion here.

 

I have an NTSC 800 that has the ANTIC chip swapped out for a PAL version with the intention of being able to run Euro games and demos correctly. This chip swap gives my machine a 50hz frame rate for proper speed, and the longer VBLANK needed for intricate interrupt routines. It works perfectly nearly all the time.

 

Software that checks the GTIA PAL register $D014 will usually cause problems, as my machine still 'looks like' an NTSC box. Games that self-adjust for the timing difference (Yoomp, Pac-Man Arcade and IK Enhanced, to name a few) now run too slowly - my 800 is already at 50hz.

 

Even worse are the games and demos that check $D014, see its set for NTSC, and then abort with some "This game requires PAL!" message.

 

I've been told it would be "relatively simple" do improve this modification by changing the GTIA register to read as PAL - WITHOUT swapping the GTIA chip itself - using a GAL. I don't know how to do this, but if someone could push me in the right direction I would love to learn.

 

Of course, native NTSC software now run incorrectly as well. US games that I grew up playing on a stock American Atari feel all kinds of wrong at the slower speed. The Holy Grail mod for me would be to have both ANTICs installed with the ability to switch between them. I've found a few threads here and here but no one seems to have a definitive answer how to make this work. I'd like to continue research on this, and if anyone can contribute the help would be appreciated.

 

 

[Rybags]

Yep, a middleman hack would be desirable - the problem with putting the foreign GTIA in is that you then cop colour encoding issues which can be an entire PITA in it's own right.

 

The elegant solution would be have GTIA sit on a board, in events where any read occurs to $14, have the logic device return a selectable value - if this thing was manufactured then equally PAL machine owners would like to be able to masquerade as well.

 

Whether a simpler/cheaper method could be done, not sure. To act as Pal, we need reads to Register $14 to return $01 instead of $0F so maybe it could be hacked together using 7400 series chips.

[Bryan]

The best way to test for PAL is to count the scan lines rather than use the PAL register for this very reason. If it's only a few pieces of software, it might be easier to hack them by looking for the PAL read in the code.

 

Since GTIA pulls down stronger than up, A single PAL/GAL (the other PAL - programmable logic) chip could test for a read of $14 and overdrive D1-3 low without much risk to the chip (how often is PAL read anyway?). This is what the new 2600 carts are doing as well for faster writes: The CPU keeps hitting the registers with $FF and the cart overloads with the actual data.

[Rybags]

Yep, that's the other thing. There's probably less than 2 dozen games ever created that bother checking Pal/NTSC for the purpose of adjusting speed of the game itself, fair enough there's probably a good number in the modern day that do so to keep the music tempo the same.

 

It probably would be easier to just do hacks for the ones that don't behave like you want.

[Xuel]

This doesn't help with existing games but for anyone writing new games check out Mapa's routine in this thread for a short and sweet implementation of PAL/NTSC detection based on counting scan lines.

This is what I used in X:8 but forgot to use in Ransack:

    ; Carry set = PAL

    ; Carry clear = NTSC

detect_pal_or_ntsc

    sei

detect_loop

    lda vcount

    cmp:req vcount

    bcc detect_loop

    cmp #132

    rts

Edited January 2, 2015 by Xuel

[Bryan]

Another way:

 

loop1
   lda VCOUNT   ;We must start on a non-zero VCOUNT.
   beq loop1
loop2
   tay
   lda VCOUNT   ;Save VCOUNT in Y until it wraps.
   bne loop2
 
;Y now equals the maximum VCOUNT found.

[Tezz]

It's good that you've brought up this point with regard to hybrid systems, I'll certainly stop using the $D014 check for PAL/NTSC from now on and change to checking vcount instead. I'm in the process of wrapping up one of my projects so that'll be avoided now.

[_The Doctor__]

most games can be converted to ntsc with care, or can detect pal/ntsc via the scanline method and load a properly coded version based on the detection. It's up to the programmer if he wants to take the time to do any of this however... I prefer that they did... Roklan titles had both 50hz and a 60hz versions made for titles that required it.

[pps]

Hardest thing is testing your code on real machine, if you don't have a NTSC machine. You know, even the best emu is just an emulator.

[flashjazzcat]

Fortunately you're among the biggest congregation of Atari 8-bit users on the globe here, so once the thing works in emulation, surely it's worth running it by someone who owns an NTSC machine. Shouldn't be too hard to get hold of someone.

[pps]

Fortunately you're among the biggest congregation of Atari 8-bit users on the globe here, so once the thing works in emulation, surely it's worth running it by someone who owns an NTSC machine. Shouldn't be too hard to get hold of someone.

yes that's right, but sometimes a coder needs to see it all, what happens with his code...

[flashjazzcat]

Sure - but I mean in a "needs must" situation when you've already tested it in emulation and need to know if there are real-hardware nasties prior to proudly announcing the release. Certainly an NTSC machine is a must-have for a serious developer, though - I agree with that. Meanwhile, not having one isn't necessarily a valid reason not to even attempt to support American machines, given the quality of modern emulation.

Edited January 5, 2015 by flashjazzcat

[phaeron]

For most, it's just not practical to do hands-on testing of both NTSC and PAL. I have three NTSC machines here and zero PAL machines, and even if I had a PAL machine, I'm not sure any of the monitors or capture devices I have would work with it.

 

It's rare that a program fails on an NTSC vs. PAL issue that doesn't reproduce in emulation since frame timing is a rather blatant requirement for an Atari emulator to, well, work. A lot of the issues that people think are emulation vs. real hardware are actually configuration differences in memory, disk drive, etc. The issues that I've helped people lately that actually turned out to be emulation issues were much more subtle, like uninitialized reads from extended memory and HSCROL timing problems.

 

That having been said, the NTSC50 case is bad news on both the real machine and emulation fronts. The only emulator I know of that can currently run in that configuration is Atari++, and almost no one has a hybrid machine with PAL ANTIC and NTSC GTIA. Need to fix that.

[flashjazzcat]

We're lucky in Europe: most compatible LCD monitors will handle NTSC output.

[phoenixdownita]

I use my PAL consoles via http://www.amazon.com/ViewHD-Universal-Multi-system-Three-Input/dp/B00AE0DMD8

and it's an acceptable compromise.

 

I can play comfortably a GX4000 [via composite ... little blurry] and Amiga CD32 PAL [sVideo a little too bright], I also play with my NTSC A7800 via SVideo mod (as my LCD does not like the direct feed somehow).

 

My LCD TV can render 720p at 60Hz as well as 1080p at both 50 or 60Hz so I set the converter to 1080p50 for PAL machines and whatever at 60Hz for NTSC console when the TV refuses the direct feed (rare, only 7800 and sometimes NeoGeo AES show the issue)

 

It's not perfect but it works well enough [some cropping of PAL signal, sometimes interlace latches on the wrong semipicture etc ..] .... and it is not too expensive either.

Edited January 6, 2015 by phoenixdownita

[Tezz]

Fortunately you're among the biggest congregation of Atari 8-bit users on the globe here, so once the thing works in emulation, surely it's worth running it by someone who owns an NTSC machine. Shouldn't be too hard to get hold of someone.

We're certainly blessed with Altirra for development nowadays. I'd like to have the games play tested on the real hardware in NTSC land before release to make sure there are no unforseen issues and also for feedback though A bit more work needed before then.

[+SpiceWare]

This is what the new 2600 carts are doing as well for faster writes: The CPU keeps hitting the registers with $FF and the cart overloads with the actual data.

 

What carts are using bus stuffing? I know some tests have been done, but wasn't aware of anything beyond that.

[flashjazzcat]

We're certainly blessed with Altirra for development nowadays. I'd like to have the games play tested on the real hardware in NTSC land before release to make sure there are no unforseen issues and also for feedback though

I completely agree - there's no substitute for a real hardware test. The point I was making is that there have to be plenty of discreet people here with the necessary hardware who'd be more than happy to provide detailed pre-release private testing feedback on new software. God knows, I've been helped in this precise way in the past by the good members of this community.

[Bryan]

 

What carts are using bus stuffing? I know some tests have been done, but wasn't aware of anything beyond that.

Sorry, I had read about it and thought it was a feature of the CPU based carts.

[+SpiceWare]

Sorry, I had read about it and thought it was a feature of the CPU based carts.

 

No problem, just thought I'd missed something. The CPU carts can do it, that's what the testing was, we just haven't gone any further down that path yet.

Edited January 7, 2015 by SpiceWare