Tips & Tricks PAL-50 conversions

[Thomas Jentzsch]

While Atari's Stella Programmer's Guide urges to use "2 byte fractional addition techniques", many developers back then and even today choose to base their updates (movement, animation etc.) on a counter which is updated every frame. It is easier to handle and saves RAM and ROM space. But a NTSC to PAL-50 conversion based on a frame counter will slow down by ~17%. No good!

A simple solution is converting to PAL-60. This works with almost all modern TVs. However back then, this was no option. Also the extra scan lines of PAL-50 allow for extra content. And for a vice versa, PAL-50 to NTSC conversion, we have to adjust the frame rate, even today.

While creating my Pitfall!x16 hack, I came up with the idea to accelerate the frame counter. Every 5th frame the counter has to be increased twice. But these updates cannot be done in any frame, e.g. in Pitfall! (like in most other cases I have seen so far), the updates happen in frames 2^n (here every 2nd, 4th, 8th and 128th frame). So when increasing the frame counter a 2nd time, we must not skip these frames! Also the additional counter updates should not be noticeable, so they must be (more or less) evenly distributed.

I save you the rather complicated math and simply show you my code:

.doInc  
  inc frameCounter
  lda frameCounter
  cmp #%01010011     ; 83 (1x)  
  beq .doInc
  and #%1111111
  cmp #%0010011      ; 19, 147 (2x) 
  beq .doInc
  and #%11111
  cmp #%00011        ; 3, 35, 67... (8x)
  beq .doInc
  and #%111
  cmp #%111          ; 7, 15, 23... (32x)
  beq .doInc 

This code uses no extra RAM and 24 bytes ROM. For 10 seconds (500 frames) the counter is off by just 2 (= 0.4% here, 0.33...% on average)

However, there are some cases this code doesn't catch:

• updates which happen every frame - here you have to find individual solutions
• updates which don't happen at frame 2^n (e.g. every other odd frame) - maybe you can move them to frame 2^n

For solving 1., one could e.g. call the same code twice (like the frame counter updates) or switch to fractional math here.
For problem 2. a simple fix may do, e.g.:

  lda frameCounter
  lsr 
  bcs .doUpdate     ; replace with bcc

Attached you find a speed compensated PAL-50 version of my hack. Except for minor exceptions (e.g. Harry falling and sound speed), it plays 99.66...% identical with the NTSC version.

Pitfall!x16 (2017) (Activision, Thomas Jentzsch) (PAL-50).bin

[Dionoid]

More than six years later, this frame counter accelerator code helped me to create a PAL50 version of my homebrew game Tower of Rubble, running at (almost) the same speed as the NTSC and PAL60 versions. Thanks for sharing, @Thomas Jentzsch !!!

[Omegamatrix]

@Thomas Jentzsch just wanted to mention you could save a byte in your code by using an ASL on the first AND, and adjusting the AND and CMP operands that follow. That will reduce it to 25 bytes same cycles.

 

.doInc  
  inc frameCounter
  lda frameCounter
  cmp #%01010011     ; 83 (1x)  
  beq .doInc
  asl
  cmp #%0100110      ; 19, 147 (2x) 
  beq .doInc
  and #%111110
  cmp #%000110       ; 3, 35, 67... (8x)
  beq .doInc
  and #%1110
  cmp #%1110         ; 7, 15, 23... (32x)
  beq .doInc 

 

For the updates that happen every frame I don't imagine you would need to check the framecounter at all unless I am missing something.

[Thomas Jentzsch]

4 hours ago, Omegamatrix said:

@Thomas Jentzsch just wanted to mention you could save a byte in your code by using an ASL on the first AND, and adjusting the AND and CMP operands that follow. That will reduce it to 25 bytes same cycles.

Good catch, saves one byte. 👍

4 hours ago, Omegamatrix said:

For the updates that happen every frame I don't imagine you would need to check the framecounter at all unless I am missing something.

Right. And these cannot be accelerated that way.