pal/ntsc

[Oldmannewhobby]

I just had a thought. Are the games all compatible? Any other limitations?

[+intvsteve]

There are a few known problem games... Dreadnaught Factor doesn't work at all on PAL. Can't recall which others off the top of my head.

 

Many (most?) of the original 125 games will play faster on PAL.

 

The newer games *usually* (not always) will make efforts to play the same on either NTSC or PAL. Depends on the game and the person / people who wrote it.

 

The sounds will be a bit off on PAL games that don't adjust for the higher CPU frequency. And any code that tries to do 'wall clock' time by counting 'ticks' in the STIC will run too slow on PAL (i.e. it'll assume 1 sec == 60 ticks, but on PAL it's 50).

[Oldmannewhobby]

But is that a cart to consol issue or a console to tv issue?

[+intvsteve]

I'm not quite sure what you're asking. Whether a system will display on a particular TV is separate from whether a specific game will play on a given console.

 

The PAL consoles contain slightly different hardware to produce different video and sound output. The way it was done, not only did the changes to produce PAL vs. NTSC result in different video output, but also ran the CPU at a different speed. As a result, games that made assumptions about the timings of video interrupts, or just ignored them, might have problems on the 'other' type of console.

 

Now, video quality is a whole different thing. These old consoles produce RF output that may not look good on newer TVs for many reasons. There were some French systems that were made to have a SCART output, which, it's been said, are the best.

 

But, if a game won't work on PAL, it's a game <-> console thing, not a console <-> TV thing.

[IntellivisionDude]

Here is a good example for you. This is one of my friends who lives in Australia and has bought Intellivision games from me in the past.

 

Fast forward a 15:49 to the gameplay. Thunder Castle sounds and plays like it's in slow motion

 

 

Now here is a video of my playing it.

 

Edited October 21, 2014 by IntellivisionDude

[Utopia]

Here is my list of games that have issues on a Pal console that is by no means complete -

 

Motocross - Mattel version won't work but INTV version does.

Dreadnaught Factor wont work.

Star Wars - NTSC version plays start music but PAL version doesn't.

Stampede - Two versions (I have both) The NTSC version won't work or plays a bit and then hangs.PAL version is fine.

[Oldmannewhobby]

Hmmmmmm. and is it as simple as chancgin the stic to convert an ntsc concole to pal?

[Utopia]

Hmmmmmm. and is it as simple as chancgin the stic to convert an ntsc concole to pal?

I don't think a conversion is possible.

[Oldmannewhobby]

kk, cheers gents.

[stc2009]

Hmmmmmm. and is it as simple as chancgin the stic to convert an ntsc concole to pal?

No apart from the NTSC to PAL signal output the power input also will require the 60Hz 110V power for the NTSC consoles, rather than the 50Hz 240V power here in Australia. You might want to invest in a step-down transformer with a frequency changer (although a step-down transformer alone might work)

[Oldmannewhobby]

So are the power boards identical?

[HunterZero]

Power boards are the same, they have the same AC to DC rectifier, power caps and regulators, but the transformer blocks are different. Since the console logic board inputs are DC, I don't think input AC frequency matters.

 

I tried an NTSC STIC in my PAL Intellivision, but it garbles the display. The circuit that has the colour generator is replaced with a daughterboard on the PAL console, and the RF modulator is probably different too. The PAL colour generator oscillator and master clock runs at a different frequency to the NTSC one.

Edited October 21, 2014 by HunterZero

[Oldmannewhobby]

Ok I might test the powerboards in the incoming one to see if they work if that's the case I might just be able to change that and mine will tun fine.

[+intvsteve]

Here is a good example for you. This is one of my friends who lives in Australia and has bought Intellivision games from me in the past.

 

Fast forward a 15:49 to the gameplay. Thunder Castle sounds and plays like it's in slow motion

 

 

Now here is a video of my playing it.

 

Ah, here the speed of the game is governed by 'STIC ticks' -- which are 50Hz on PAL and 60Hz on NTSC.

[IntellivisionDude]

Ah, here the speed of the game is governed by 'STIC ticks' -- which are 50Hz on PAL and 60Hz on NTSC.

 

I wonder if something like that could give people advantages in high score competitions. hmmm

[+intvsteve]

 

I wonder if something like that could give people advantages in high score competitions. hmmm

My guess is that it would depend on the implementation of the game.

 

For example, if MOB locations and hit testing are updated at 'CPU speed' in RAM, not needing access to GRAM, you're going to run faster and be at a disadvantage.

 

I'll try to explain it... Your program is really just a big loop to update information. Let's say you have the position of the bad guy, and good guy, each as x and y.

 

If you update at 'CPU speed' then your function that, say, moves a few pixels every time it gets called would be something like:

UpdatePositions()
{
  bad_guy.X = bad_guy.X + 4;
  bad_guy.Y = bad_guy.Y + 4;
  good_guy.X = good_guy.X + 5;
  good_guy.Y = good_guy.Y + 5;
}

This is boring straight-line movement that won't last long, but you get the point. If that function gets called at 'CPU time' it'll be called as often as it can from the main loop. How long it takes the 'main loop' depends on how much code is in the loop, but it can be faster than how often the STIC interrupts the main loop. It could also be choppy, since other logic may result in some loop iterations executing more, or less, code.

 

The STIC interrupts either 60 times / sec (NTSC) or 50 types / sec (PAL). If you only call this function during that interrupt, then that's how often it'll run -- nice and consistent, but slower on PAL.

[+thegoldenband]

I find it so interesting that the pitch of the music is higher on PAL systems, even though the tempo is slower. Is it practical on the Intellivision to make music the same speed on PAL and NTSC, or does the architecture require that everything be frame-timed (i.e. sync'ed with 50Hz or 60Hz)?

 

I guess you could set the tempo of music based on 5 frames per tick on PAL vs. 6 frames per tick on NTSC, since both would equal 1/10 second. But that doesn't allow for fine-grained control of tempo and rhythm. Otherwise, I'd think you'd have to do mid-frame updates on PAL to duplicate NTSC playback speed, if that's even possible?

[HunterZero]

Ok I might test the powerboards in the incoming one to see if they work if that's the case I might just be able to change that and mine will tun fine.

Just to be safe, test the power output voltages before you reconnect the logic board ribbon and blue wire to make sure the board you are using is good. It's not hard to recondition a power board with new electrolytic caps and regulators.

[intvnut]

I find it so interesting that the pitch of the music is higher on PAL systems, even though the tempo is slower. Is it practical on the Intellivision to make music the same speed on PAL and NTSC, or does the architecture require that everything be frame-timed (i.e. sync'ed with 50Hz or 60Hz)?

 

I guess you could set the tempo of music based on 5 frames per tick on PAL vs. 6 frames per tick on NTSC, since both would equal 1/10 second. But that doesn't allow for fine-grained control of tempo and rhythm. Otherwise, I'd think you'd have to do mid-frame updates on PAL to duplicate NTSC playback speed, if that's even possible?

 

Arnauld and I have experimented with various ways to even out the PAL and NTSC experience.

 

 

The CPU clock is definitely faster on PAL systems (4MHz for PAL vs. 3.579545 on NTSC), and the PSG clock is tied to the CPU clock. But, the refresh interrupt comes less often (50Hz vs. 60Hz), which is why you end up with these weird differences. Retrace-timed events go slower, CPU-timed events go faster. And, the pitch on the PSG goes up since it's tied to CPU clock.

 

 

What Arnauld last mentioned to me was that he was planning just to run the timer-tick based tasks an extra time every 5th frame (to get 6 frames for every 5) on PAL machines. That works really well if your game speed is locked to vertical retrace. There's enough extra cycles on a PAL machine that it can absorb it, it appears. At least, in my few experiments, that seems to be the case. There are some things that won't work quite right if you do that, such as STIC based collision handling, since you'll end up skipping every 6th frame. But, if you do all your collision detection in software, you can still compute collisions for that 6th frame even if it isn't displayed. (Space Patrol is hybrid; most collision detection is in software, but a handful of collisions are detected by hardware. *sigh*)

 

As for pitch, the easiest thing to do is to just keep two pitch tables around and pick one based on detecting PAL/NTSC. That's what I did in my synth demo. (That's the ECS synthesizer keyboard demo I posted some time ago; I think it's under the "programming" tab.)

[HunterZero]

D2K is another game where on a PAL console the music runs slower at a higher pitch, and gameplay is slightly slower.

 

PAL:

 

- James

[+thegoldenband]

What Arnauld last mentioned to me was that he was planning just to run the timer-tick based tasks an extra time every 5th frame (to get 6 frames for every 5) on PAL machines. That works really well if your game speed is locked to vertical retrace.

 

Thanks very much for that detailed post (sincerely!), but I'm having a hard time wrapping my head around this as it applies to musical tempo and rhythm. Arnauld's tracker is locked to vertical retrace, isn't it? (Is it practical to write a music driver for Intellivision that isn't?) So wouldn't this just result in dropped frames from the music and, consequently, stuttering rhythms?

 

(I know you can often get away with stealing a frame for e.g. noise-channel sounds, but actual dropped frames would be very noticeable, I'd think.)

[intvnut]

 

Thanks very much for that detailed post (sincerely!), but I'm having a hard time wrapping my head around this as it applies to musical tempo and rhythm. Arnauld's tracker is locked to vertical retrace, isn't it? (Is it practical to write a music driver for Intellivision that isn't?) So wouldn't this just result in dropped frames from the music and, consequently, stuttering rhythms?

 

(I know you can often get away with stealing a frame for e.g. noise-channel sounds, but actual dropped frames would be very noticeable, I'd think.)

 

 

Yes, it's locked to the vertical retrace.

 

Playing an extra frame after every 5th frame actually shouldn't cause much issue at all. Consider a moderately high tempo song at 100bpm. 100 beats per minute. 1 minute has 3600 ticks at 60Hz. That means each beat (a quarter note) is 36 ticks long. So, by slicing out every 6th frame, it loses 6 ticks, evenly distributed throughout the beat.

 

It won't cause any rhythms to stutter noticeably at 100bpm, and I doubt the human ear could pick it out. An eight note loses 3 ticks (again, evenly distributed), shortening from 18 to 15 ticks. The first note that gets a little wobbly at that bpm is the 16^th note, with half of them shortening to 7 ticks (losing 2) and half shortening to 8 (losing 1). But, even then it's evenly distributed, so the overall beat remains stable. (I don't think the tracker goes below 16^th notes.)

 

There's no dropped sound, per se. Rather, the total duration of the tones, in terms of ticks, gets shortened. The wall clock time stays the same (or in the case of the 16^th note, it's on average the same).

 

Mostly, music consists of "tone start, wait a few tics, tone stop", with some volume shaping and maybe some frequency modulation to give a tremolo effect. The main impact is to the volume shaping and tremolo, not to the rhythm of the song. And because it's evenly spread out, it should be fairly minor.

[+DZ-Jay]

The way I overcome this difference in P-Machinery v2.0 is by using a system clock that keeps the pace of all temporal events in the game, including music, timed events, object movement, sprite animation, etc.

 

The system clock is updated on every vertical-retrace interrupt, and all temporal events are relative to it. PAL and NTSC consoles would update the system clock differently, but the game would still tick at its own pace.

 

In P-Machinery, the main game loop is tied to the system clock, and not to "CPU time," though kernel routines are executed on "CPU time" outside the critical path of the VBLANK ISR (interrupt service routine for vertical-retrace). This means that collisions and movements may be updated faster in one console than another, but they still occur at the same pace relative to the game itself, evening everything out.

 

The only exception, which I think is actually quite important, is the IO handler. The hand-controller is polled continuously for input on "CPU time," as close to "real time" as possible, after all kernel sub-systems have updated. This results in a higher degree of accuracy and responsiveness, which is one of the best features in Christmas Carol.

 

Obviously, this also means that the faster processor in PAL consoles may have a slight advantage by being potentially more responsive to user input. Though I'd expect this to be minimal in practice.

 

dZ.

 

 

P.S. Christmas Carol uses an older version of P-Machinery, relying on the vertical-retrace interrupt for timing. Therefore, it suffers from the same slow-down effect as the other games mentioned above.

[+thegoldenband]

Playing an extra frame after every 5th frame actually shouldn't cause much issue at all. Consider a moderately high tempo song at 100bpm. 100 beats per minute. 1 minute has 3600 ticks at 60Hz. That means each beat (a quarter note) is 36 ticks long. So, by slicing out every 6th frame, it loses 6 ticks, evenly distributed throughout the beat.

 

It won't cause any rhythms to stutter noticeably at 100bpm, and I doubt the human ear could pick it out. An eight note loses 3 ticks (again, evenly distributed), shortening from 18 to 15 ticks. The first note that gets a little wobbly at that bpm is the 16^th note, with half of them shortening to 7 ticks (losing 2) and half shortening to 8 (losing 1). But, even then it's evenly distributed, so the overall beat remains stable. (I don't think the tracker goes below 16^th notes.)

 

Well, it'd be an interesting experiment to find out! I think some musicians' ears would notice the irregularity in a run of notes that were tracked at 5 frames long (0.1 seconds each at 50 Hz), since you'd get a 20% variation in duration -- five out of every six notes would end up getting shortened to be 4 frames long (or 0.08 seconds), if my math is right..

 

That said, I just ran a test with running scales where every sixth note was 0.1 seconds long instead of 0.08, and it was smooth enough to "work" though I did notice a slight hesitation on the longer notes. Double that to two frames, though, and it's very noticeable. And of course, that's close to a worst-case scenario, given the 5/6 ratio.

 

I never thought about the tracker as having 16th-note resolution, though now that you point it out that's the paradigm, of course. I just use frame timing for the tunes I write, and try to use the smallest values possible that allow for the subdivisions I want -- that way, I have more tempo options with the SPEED multiplier. So if I'm programming a tune that uses triplets and "straight" eighths, I usually use a beat unit of 6.

 

BTW what's the 50 Hz mode flag for jzintv?

 

EDIT: Here's an MP3 of the file I used for testing, plus the same thing at 1/4 speed so the irregularity is easier to zero in on. (I used a sequencer program to produce it.)

Frame timing testing 25% speed.mp3

Frame timing testing full speed.mp3

[Oldmannewhobby]

Wow, this went into technical stuff i a- dont understand and -b never expected haha

 

had a thought earlier, aside from the space issue, would it be possible somehow to run 2 different logic boards in the one system with a switch to change them over?