Where is the PAL C64 memory map different than NTSC?

[Mr SQL]

Where is the PAL C64 memory map different than NTSC besides the frame rate?

I'm seeing programs freeze under PAL configuration on VICE but it's not clear why.

 

Does the PAL firmware use additional bytes on the zero page?

 

[DistantStar001]

As far as I understand it, they don't.  But the VIC II chips are different.  PAL and NTSC chips generate color differently.  Also, the VIC II is responsible for memory refresh in addition to video.  

 

Living in the U.S., I know there are a lot of programs that are incompatible with NTSC machines, so it's not unreasonable for some NTSC programs to be incompatible with PAL systems as well.  My guess is that they contain some incompatible graphics code that won't translate between standards.

 

This is why I imported a PAL system.  When I got it, it had a bad VIC, so I tried an NTSC chip to see if I could get it to work.  Spoiler: it did.  But at a 50Hz frame rate.  Fortunately, my TV was able to understand the signal.  When I got the replacement (PAL) VIC, I tried that in one of my NTSC machines and found that it worked as well. I was even able to run some PAL-only games at 60 Hz.  These games did not work on the PAL C64 when using the NTSC VIC.  

 

From this, I would assume that the compatibility issues your describing are due to color and video generation and not the memory allocation. 

[hofster]

I can't see that they use zero page differently. It's the same Kernal for both PAL and NTSC.

I did a quick search on NTSC and PAL keywords in the C64 Kernal source code to see what they do differently and the only differences seem to be the interrupt rate for the keyboard scanning and baud rates. I can't see that any zero page addresses are involved in those routines. 

The keyboard routines are probably using zero page addresses and are reading and writing them at a different rate but it should still be the same addresses.

That is on real hardware. I don't know how VICE is doing it.

Are you seeing the same freeze on real hardware?

[Mr SQL]

4 hours ago, hofster said:

I can't see that they use zero page differently. It's the same Kernal for both PAL and NTSC.

I did a quick search on NTSC and PAL keywords in the C64 Kernal source code to see what they do differently and the only differences seem to be the interrupt rate for the keyboard scanning and baud rates. I can't see that any zero page addresses are involved in those routines. 

The keyboard routines are probably using zero page addresses and are reading and writing them at a different rate but it should still be the same addresses.

That is on real hardware. I don't know how VICE is doing it.

Are you seeing the same freeze on real hardware?

 

I only have real NTSC Hardware so I am using VICE to test the PAL hardware.

Early builds ran fine on PAL in VICE, I used increasingly more of the zero page.

I did initially see freezing on NTSC on the real Hardware and in VICE and had to exclude certain zero page addresses and jump around memory to resolve/unfreeze.

The latest builds are stable on NTSC on the real hardware and VICE but freeze on PAL under VICE.

It's interesting there are multiple PAL models, I am relying on the VICE default as the most common/standard.

 

5 hours ago, DistantStar001 said:

As far as I understand it, they don't.  But the VIC II chips are different.  PAL and NTSC chips generate color differently.  Also, the VIC II is responsible for memory refresh in addition to video.  

 

Living in the U.S., I know there are a lot of programs that are incompatible with NTSC machines, so it's not unreasonable for some NTSC programs to be incompatible with PAL systems as well.  My guess is that they contain some incompatible graphics code that won't translate between standards.

 

This is why I imported a PAL system.  When I got it, it had a bad VIC, so I tried an NTSC chip to see if I could get it to work.  Spoiler: it did.  But at a 50Hz frame rate.  Fortunately, my TV was able to understand the signal.  When I got the replacement (PAL) VIC, I tried that in one of my NTSC machines and found that it worked as well. I was even able to run some PAL-only games at 60 Hz.  These games did not work on the PAL C64 when using the NTSC VIC.  

 

From this, I would assume that the compatibility issues your describing are due to color and video generation and not the memory allocation. 

 

That's an interesting point I makes me wonder what specifically is keeping them from running on NTSC machines. NTSC versions were produced of many of those programs so the programmers must have figured it out to do that, wonder if what had to be changed is documented anywhere.

 

Great idea I wish I had the PAL hardware too, I think the PAL system also needs European current standards or can run differently as well. 

 

Very intriguing that the PAL VIC-II can be dropped in in place of the NTSC chip to enable incompatible PAL games to run, that certainly points to the VIC-II.

 

[brain]

The KERNAL (OS) of the 64 is the same for all NTSC and PAL variants.  Thus, there is no difference in RAM and ROM usage. 

 

However, as others have noted, the difference is (indirectly) because of the video standards.  Strap in for a non trivial response.

 

Like many home computers that used (or had to support) a television for an output device, the main clock frequency of the design was tied to the frequencies needed for video generation. NTSC thus uses 14.31818 MHz as the master clock.  This frequency looks weird, but it's 4 times the NTSC color subcarrier frequency, which 3.5779545MHz (that should look familiar for NTSC folks).  There is then a "divider" IC in the design to divide this down to the VIC-II "dot clock" frequency, which is then used so that the internal timers output data at NTSC speeds.  FOr instance, if the goal is the have a full line of NTSC data (including non seen pixels) be 512, ~8MHz / 512 yields a line frequency of ~16kHz, and that divided by 262 lines yields 61Hz, both of which are "close enough" to feed into an NTSC TV.

 

So 14.31818 * 8/14 = 8.181818 MHz, and the VIC divides that down by 8 and then drives the CPU.  So, the CPU runs at 1.02MHz, trivially more than 1.0MHz

 

PAL is a different standard, so the goal is ~500 pixels per line and 50 frames per second.  If you work the calculations, you get a base frequency of 17.734475MHz, with a divisor of 8/18 to provide "dot clock" of 7.88 MHz.  VIC then divides that down by 8 to generate CPU clock of ~.985MHz.

 

OK, so PAL runs slower than NTSC?  Yep, it does, ever so slightly. 

 

So, there's less times to run code in a second on a PAL than on a NTSC, right?  I should get an NTSC machine and all PAL programs should run on an NTSC machine since it runs faster? Not so fast.

 

Again, life revolves around the video standard, and the key difference here is the screen refresh frequency. NTSC needs to refresh 60 times a sec, PAL only 50.

 

Games are written not with raw CPU speed in mind, but how many cycles are available per screen refresh.  So, while NTSC has more cycles in a second to do work, PAL actually has more per refresh (.985MHz/50 = 19700 cycle per refresh for PAL, compared to 17000 per refresh in NTSC).  So, a game running on a PAL system gets ~2700 more cycles to do CPU work per screen refresh.

 

How does that affect the game or code or cause a freeze?

 

Well, if the game author sets up a raster interrupt and tries to do more than 17000 cycles worth of code, on an NTSC system, a second IRQ will occur while the first IRQs code is still running. The game author probably did not write their code expecting to be interrupted while running it, so things might be in a bad state when the second IRQ comes in. 

 

Other times, the game will continue to play, but the bottom jitters or similar artifacts happen.  That is also due to not getting enough work done in a frame.

 

So, for the 64, PAL allows for better gameplay and graphics, because PAL only has to do stuff 50 times a second, while NTSC has to do things 60 times a second.

 

There's a bunch of additional detail you can read about (some PAL games expect there to be 312 lines on the screen, so they set an interrupt for line 311, and then the IRQ never fires on an NTSC machine, since the NTSC only has 262 lines.  IN those cases, the game appears frozen, but it's really just waiting for an IRQ that will never come.  Later PAL games took more of this into account.

 

So, blame the video standard for PAL games not working on NTSC.

 

And, yes, you can turn an NTSC 64 into a PAL with 3 changes.  Wap out the VIC-II (6567 for 6569), change the main crystal, and change a jumper on the IC that does the divisor (the divisor IC has both divisors coded in the IC, with a single pin to select with calculation is used).  Back in the 90's, many of us did exactly that, I have a PAL converted machine here.  Of course, the NTSC folks need a multi-sync monitor to then watch the video, but before VICE, that was the only way to play PAL games in the US...

[brain]

Posting this to enable following the topic if more questions are asked.  Note that I am not a VIC-II expert, bug a demo coder for the grittier details.

[Mr SQL]

2 hours ago, brain said:

Well, if the game author sets up a raster interrupt and tries to do more than 17000 cycles worth of code, on an NTSC system, a second IRQ will occur while the first IRQs code is still running. The game author probably did not write their code expecting to be interrupted while running it, so things might be in a bad state when the second IRQ comes in. 

 

Other times, the game will continue to play, but the bottom jitters or similar artifacts happen.  That is also due to not getting enough work done in a frame.

 

Great details and perspective! I think this may be what was happening and the NTSC systems ended up being in a good state, while the PAL hardware was still freezing from the timing differences/ending up in a different spot in the code. 

 

Here are two similar games that now run on PAL:

blitzii.prg    fluidcitybside.prg

Fluid City has no sparkles despite the higher frame rate. BlitzII sparkles only under NTSC but not PAL.

 

Fluid City is a demo scene release featuring artifact colors and graphics that vanish when you use the throttle.

 

Here is a thread with the NTSC only version locking on PAL.

 

[carlsson]

7 hours ago, Mr SQL said:

I think the PAL system also needs European current standards

The C64 always takes 5V DC + 9V AC. There has been debate on whether the AC must be 50 Hz or if 60 Hz works as well. As it turns out, the clock is generated internally so the only place where the line frequency matters is when it is exposed on the user port for e.g. modems. That means for the vast majority of applications, you should be able to run a PAL C64 on the same PSU as you already use.

 

The video output is a different matter as apparently very few TV's in the US ever have supported PAL, up to the point when composite and S-Video inputs completely vanished from the market. That is greatly different from Europe where NTSC support has been around for at least 20 years, perhaps 25 in some cases. I never understood if that is due to the TV models are cheaper in the US or just ignorance from the manufacturers' side.

[brain]

1 hour ago, Mr SQL said:

 

Great details and perspective! I think this may be what was happening and the NTSC systems ended up being in a good state, while the PAL hardware was still freezing from the timing differences/ending up in a different spot in the code. 

 

Here are two similar games that now run on PAL:

blitzii.prg 28.75 kB · 0 downloads      fluidcitybside.prg 29.41 kB · 0 downloads

Fluid City has no sparkles despite the higher frame rate. BlitzII sparkles only under NTSC but not PAL.

 

Fluid City is a demo scene release featuring artifact colors and graphics that vanish when you use the throttle.

 

Here is a thread with the NTSC only version locking on PAL.

 

I got so busy on the response I forgot to answer your specific question.  Though it's somewhat more common that PAL games misbehave on NTSC, the same applies in reverse.  One quick issue is an NTSC game author setting an IRQ not low enough to do "off screen" video updates.  Since off screen occurs later for PAL than for NTSC, updates can happen while the screen is still drawing (sprites can be messed up, or the timing for border removal can go south in these situation.  As well, if the game relies on having a certain number of cycles available per second to do work (some games update over multiple frames, but expect a minimum amount of code be run in that timeframe).  Those games will have issues on PAL if written fro NTSC.

 

One final issue is sound.  Audio and songs written for PAL land play faster on NTSC, and NTSC game audio plays slower when played on PAL.

 

Jim

[brain]

31 minutes ago, carlsson said:

The video output is a different matter as apparently very few TV's in the US ever have supported PAL, up to the point when composite and S-Video inputs completely vanished from the market. That is greatly different from Europe where NTSC support has been around for at least 20 years, perhaps 25 in some cases. I never understood if that is due to the TV models are cheaper in the US or just ignorance from the manufacturers' side.

No demand.  I think our video device export was significant (so Europe would have an interest in NTSC support), but we rarely imported anything that needed PAL.  Sony and some high end brands came out with multi-sync composite monitors, but that was niche.

 

The dramatic telling would have US shunning PAL devices with our "Not Invented Here" syndrome, but most people didn't even know about NTSC as a thing until ATSC came out and people had to learn they had been using a standard all this time.  Most people thought the standard was RF versus composite 🙂

 

I mean there was the whole "You mean there's another standard besides the US one?  No, there can't be.  Our standard is the only one!" 🙂 That's ignorance, no doubt.  But, I would counter that Europe's decision to use 50Hz was just them abusing the metric system.  Just to simplify calcs and make things fit in the decimal system, they gave up the better efficiency of 60Hz A/C over 50Hz AC, and they introduced more flicker in lighting.  And, they still had to support 60, as seconds still matter outside of US and NA.  And, they didn't do 100V or 200V, but kept the nonsensical 110/220 we started (and I don't know why Edison and Westinghouse decided on 110V in the first place, it might have been some easy calculations of rotor winding amounts).  PAL was arguably better than NTSC, because NTSC was designed for B&W, and then color was shoehorned in, whereas PAL I believe was designed from the beginning with color in mind.  But, 60Hz PAL would have been the best option (I think some countries do that).

 

And yes, I feel genuinely OK dissing Europe for 50Hz 🙂  The US tends to come out early and use weird things and half baked ideas, and then Europe gets it right by letting the US trip over their own mistakes while other countries learn from our mistakes (when we often don't... :-))  So, to see Europe choose poorly even with the evidence at hand sticks out.

 

Jim

[carlsson]

Brazil used PAL60. Not sure about Argentina, they may have been NTSC all through.

[+OLD CS1]

10 hours ago, carlsson said:

the only place where the line frequency matters is when it is exposed on the user port for e.g. modems.

The 6526 CIA TOD (Time-Of-Day) clock is also driven by one leg of the 9VAC line.  This is how I discovered a board of mine was PAL converted to NTSC: the clock on my BBS ran fast.  I fixed it in my BBS software by setting the TOD 60/50 flag as part of the initialization routine.  The Kernal apparently sets it during power-up.

[+OLD CS1]

1 hour ago, brain said:

The US tends to come out early and use weird things and half baked ideas

 

 

[oracle_jedi]

So explain this to me....

 

Ultimate II+ on an NTSC 64.  

 

PEEKing 65408 returns the value 3.

 

[hofster]

Looks like you are running a PAL Retro Replay image on an NTSC C64.  What was your question?

[oracle_jedi]

1 hour ago, hofster said:

Looks like you are running a PAL Retro Replay image on an NTSC C64.  What was your question?

 

I just plugged the Ultimate II+ in.  Nothing is running other than the default software in the unit.  Is this expected behaviour?

 

 

[potatohead]

Just saw this thread and wonder whether people have run NTSC machines at 50Hz.

 

The Color Computer 3 has literally a 50 / 60 Hz switch in a register.  When set to 50, the machine outputs a NTSC signal with the longer refresh time.  My TV sets all displayed it, though one performed poorly.

 

Has anyone changed the divisor to get essentially 50Hz NTSC on the C64?

 

If so, that should yield the extra cycles and could yield more scan lines.

 

Edited February 9, 2023 by potatohead

[Mr SQL]

1 hour ago, potatohead said:

Just saw this thread and wonder whether people have run NTSC machines at 50Hz.

 

The Color Computer 3 has literally a 50 / 60 Hz switch in a register.  When set to 50, the machine outputs a NTSC signal with the longer refresh time.  My TV sets all displayed it, though one performed poorly.

 

Has anyone changed the divisor to get essentially 50Hz NTSC on the C64?

 

If so, that should yield the extra cycles and could yield more scan lines.

 

That would be interesting I wonder if there is any way to get a PAL C64 to display 60 Hz/PAL 262 output to match NTSC timing.

 

This Arkanoid PETSCII demo runs on both NTSC and PAL C64's but more languidly under PAL.

 

Shift-lock speeds it up.

 

arkanoidairheadb.prg

 

[carlsson]

It appears that the emulated THEC64 can be set up as PAL 50 or 60 Hz, and NTSC 60 or 50 Hz. Games run the fastest at PAL 60 Hz, and slowest at NTSC 50 Hz.

 

However, I can't recall any techie discussion over the years e.g. on the cbm-hackers mailing list about changing the crystals to make a PAL unit run at 60 Hz. There may be additional limitations for this.

[+OLD CS1]

1 hour ago, carlsson said:

However, I can't recall any techie discussion over the years e.g. on the cbm-hackers mailing list about changing the crystals to make a PAL unit run at 60 Hz. There may be additional limitations for this.

Here is a good break-down of the 64 system and VIC-II timing.

https://codebase64.org/doku.php?id=base:cpu_clocking

 

 

Postulating out loud.  I assume changing the crystal will change Φ2 timing, as well, which will make the CPU run faster at 1.266748 MHz.

 

 

 

[brain]

The normal NTSC 64 runs at: 

14.31818 MHz * 8 / 14 = 8.181818 MHz / 8 = 1.02272725MHz

PAL is:

 

17.734475 MHz * 8 / 18 which = 7.881988 MHz / 8 = .985248.5MHz

If you just replace the Xal, then the calcs are:

 

17.734475 MHz * * / 14 = 10.1339857 MHz / 8 = 1.2667482142MHz, as you state

 

But, if you change the jumper, you would get back .985MHz, though the VICII would only get 7.8819MHz as the input, which means VICII is only running at 96% speed...  That's 57Hz  I assume newer NTSCs would sync, but you still don't get 50Hz.  You do get a small bump in cycles per scan:  .985MHz/57 = 17280cycles/scan.  Normal PAL is 19700 and normal NTSC is 17036cycles.  Not much, though.

 

If you left the NTSC divisor and just upped the Xtal, you'd get 123% speed, which is 74Hz, but you still get 17036 cycles per scan field.  And bad sync.

 

Sadly, since you cannot change the internal scan rate from 60 to 50, you really don't get anything of use from switching the Xtal.