Jump to content
IGNORED

Where is the PAL C64 memory map different than NTSC?


Recommended Posts

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. 

  • Like 1
Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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...

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...