Convert XEGS NTSC to PAL .. Is this normal?

[leonk]

In order to increase game compatibility, I've converted older consoles from NTSC to PAL with great success.  This is especially true for the C64 and Amiga line of computers.

 

My next retro computer of choice is the Atari XE .. in particular, I've purchased an Atari XE GS. I then installed a 40 pin socket where the ANTIC goes, and replaced the C021697-31 (NTSC) with a C021698-07 (PAL) which I purchased from Best Electronics. I have a PVM that can show PAL/NTSC as well as XRGB mini.

 

- When I turn the system on, before any modifications, I get Missile Command (XRGB reports 240p NTSC).

- When I swap ANTIC to PAL version, I still see Missile Command - but in Black and White on the composite out port! (XRGB reports 288p PAL)

 

So my questions are:

 

1) Is swapping ANTIC the only required procedure for XEGS? Or am I missing something (like crystal on C64 and Amiga)

2) Why would the picture be black and white on PAL and color on NTSC ANTIC?  Composite out from C64/Amiga in PAL mode show perfectly fine on my display devices.  I know they can handle it.

3) Am I doing the right thing by converting to PAL?  I recently purchased an AVG cart and my goal is to play as many Atari 8 bit games as possible on it.

 

 

[Roydea6]

I believe that you need a PAL GTIA also and a 14.187576  MHz crystal, besides the PAL ANTIC.

 

[leonk]

I just found an XEGS PAL picture online. Oh my. 

 

The PAL system has 2 crystal and resistors around it (ntsc has 1 resistor that connects the empty space to the existing crystal) 

 

And as far as chips are concerned. Yes. GTIA differs as well. hmmmm

 

So. a better question then is. Is it worth converting a system (XL or XE) to PAL vs NTSC for games?

[Swami]

1 hour ago, leonk said:

In order to increase game compatibility, I've converted older consoles from NTSC to PAL with great success.  This is especially true for the C64 and Amiga line of computers.

 

My next retro computer of choice is the Atari XE .. in particular, I've purchased an Atari XE GS. I then installed a 40 pin socket where the ANTIC goes, and replaced the C021697-31 (NTSC) with a C021698-07 (PAL) which I purchased from Best Electronics. I have a PVM that can show PAL/NTSC as well as XRGB mini.

 

- When I turn the system on, before any modifications, I get Missile Command (XRGB reports 240p NTSC).

- When I swap ANTIC to PAL version, I still see Missile Command - but in Black and White on the composite out port! (XRGB reports 288p PAL)

 

So my questions are:

 

1) Is swapping ANTIC the only required procedure for XEGS? Or am I missing something (like crystal on C64 and Amiga)

2) Why would the picture be black and white on PAL and color on NTSC ANTIC?  Composite out from C64/Amiga in PAL mode show perfectly fine on my display devices.  I know they can handle it.

3) Am I doing the right thing by converting to PAL?  I recently purchased an AVG cart and my goal is to play as many Atari 8 bit games as possible on it.

 

 

Good summary: Swapping the ANTIC takes care of everything except you may or may not have coloring off, depending on the game, since the PAL-M has a different color palette than NTSC - which cannot be fixed by the ANTIC or GTIA.

 

[ChildOfCv]

29 minutes ago, leonk said:

I just found an XEGS PAL picture online. Oh my. 

 

The PAL system has 2 crystal and resistors around it (ntsc has 1 resistor that connects the empty space to the existing crystal) 

 

And as far as chips are concerned. Yes. GTIA differs as well. hmmmm

 

So. a better question then is. Is it worth converting a system (XL or XE) to PAL vs NTSC for games?

Much of the circuit may already be present on the PCB, just with blank spaces where components go.  You'd have to cut a jumper that feeds the main clock into the color input pin, then provide the missing components which include a clock divider, a resonant tank circuit, and an output amplifier.  If you get a good Sam's Computerfacts copy for one of the XE or XL computers, you should see the PAL circuit option with all the required components and their values.

[leonk]

Interesting. So if I install the Sofia RGB mod. And the PAL ANTIC I should get video color back on the PVM and have Pseudo PAL / PAL60?? without changing the GTIA?

Edited September 18, 2019 by leonk

[Swami]

22 minutes ago, leonk said:

Interesting. So if I install the Sofia RGB mod. And the PAL ANTIC I should get video color back on the PVM and have Pseudo PAL / PAL60??

The PAL ANTIC in the NTSC console will give you NTSC50, something most multi-region TVs have never heard of. An automatic multi-region TV may get confounded and show something useless, but a standard PAL50 TV/monitor should work. Colors may be off a bit or a lot. Sofia RGB would improve colors with this setup.

 

In my case, I tried both a PAL 800XL stock and an NTSC with ANTIC swapped to PAL on an NTSC monitor with V-HOLD and multiregion TV. The PAL NTSC worked on the multi-region with correct color for PAL games. It worked on the NTSC after vertical hold adjustment, but the picture was black and white. The NTSC 800XL with ANTIC swap did not work on the multi-region, it gave a picture that flickered in and out every second, but your experience may differ. It worked well on the NTSC monitor after vertical hold adjust and had reasonable color. I've never tried NTSC games on either setup because I have another NTSC console and TV. I did not have RGB out on either 800XL. The one I use for NTSC has the UAV revD, but I've never compared color outputs to the PAL ANTIC swapped one.

[leonk]

13 hours ago, Swami said:

The PAL ANTIC in the NTSC console will give you NTSC50, something most multi-region TVs have never heard of. An automatic multi-region TV may get confounded and show something useless, but a standard PAL50 TV/monitor should work. Colors may be off a bit or a lot. Sofia RGB would improve colors with this setup

You're right.. which would be the worst of both worlds!!  The best of both would be PAL60.

 

If I understand this correctly, the system sets colors/encoding (PAL vs NTSC)

The ANTIC sets the frequency (50 vs 60hz)

 

So for best compatibility, you'd want a PAL60 which means NTSC ANTIC in a PAL system.  Sure, some things will still not work correctly, but it sounds like there is no "solution" that will work with every game and every demo, at correct speed, and full size screen.

[+Nezgar]

1 hour ago, leonk said:

You're right.. which would be the worst of both worlds!!  The best of both would be PAL60.

But with PAL60 you still lose half your vertical chroma resolution. (Red and Blue are sent on alternating even/odd lines)

[leonk]

But if I do RGB mod is this still an issue?

[tjlazer]

I put in a PAL ANTIC in my NTSC 800XL and I could not get a display on my NTSC TV (Which I assumed would happen).  I tried a Commodore 1084S-P1 monitor and it worked perfectly.  Showed a PAL color screen that was smaller on the screen with large bars at the top and bottom.  I was able to adjust the screen side and it looks good now.

[Rybags]

With RGB you don't have the colourburst issue where some monitors show only B&W.   But you do lose the PAL colour blending as well as not getting artifact colours in 320 modes (which can be  good or bad depending on the application).

[+mytek]

Parallel connected Antic chips: an experiment in isolation for the purpose of swapping between NTSC & PAL

 

I guess this as good a place as any to discuss Antic NTSC/PAL swap, since I don't want to disturb the AntiX topic.

 

Speaking of AntiX. Here's how the creator describes what is happening on his board...

Quote

How does AntiX work?
In simple terms there is a chip on AntiX that switches approximately 10 signals, and that chip is controlled by the included switch. To simplify this further, the AntiX is “remote controlling” a large number of switches at the same time, from ANTIC 1 to ANTIC 2 and back again.
There are also 2 extra switches in the chip which keep the non-active ANTIC asleep, and control the two LEDs on the PCB.

 

After looking at the description, I started wondering if there might be an even simpler way. So I made an Antic sandwich for research purposes. I must mention the fact that I have no idea what the AntiX board's logic really looks like. No schematic and no actual board to reverse engineer. I just wanted the challenge, and to see what minimally would be required. And I'm not looking to duplicate the AntiX, but I might build something like this into one of my other ongoing projects.

 

 

The image above was taken with the Antic sandwich mounted in my XEGS.

All the extra wires that are seen surrounding the Antic socket,

are from various upgrade experiments that I have used this system for in the past.

 

I started by paralleling everything between the NTSC Antic on the bottom and the PAL Antic on the top, with the exception of Reset and FΦ0 (Fast 3.57Mhz clock sourced from GTIA) on the PAL Antic. I then tied the PAL Antic's Reset to GND and FΦ0 to +5v. I got this idea from a post that Bryan made many years ago.

What I'm trying to do is figure out how to float the signals tied in parallel, or in other words make them look like there is no actual connection to the system.

 

Fired it up, and got a pretty messed up picture.

 

Next I started disconnecting things on the PAL Antic that I suspected would interfere with the NTSC one. That would be Φ0 (the 1.79Mhz clock for the CPU), and REF (refresh for the DRAM). Things started to work... well almost.

 

Next I disconnected R/W from the PAL Antic and initially tied it to +5v for Read (NOT!), and then to GND for Write (Bingo that worked!). And thus far after doing this last bit everything that I've thrown at the sandwich runs as if there is only an NTSC Antic connected, which was the whole point of these experiments (e.g., can I isolate the parallel connected Antic).

 

So here's where I'm currently at signal-wise...

 

There are a total of 5 signal lines for each Antic that need to be switched in some manner to deactivate a given parallel connected Antic.

 

The deactivated state is as follows:

 

Pin-8 (/REF) disconnect and float

Pin-14 (R/W) Tie to GND

Pin-34 (Φ0) disconnect and float

Pin-35 (FΦ0) Tie to +5v

Pin-36 (/RST) Tie to GND

 

The last two pin assignments (Pin-35 and 36) are what floats the Address bus and a few other associated signals. Then bringing the write line low, puts the data bus in input mode. Essentially all these things remove a good portion of the Antic pins from the system bus electrically speaking, so that they don't interfere with the other parallel Antic. This would have to be done for each Antic in the sandwich that you wish to deactivate.

 

I could see using a pair of 74HCT4053 chips to do all the switching, and just use a couple of pull-down and pull-up resistors to determine the logic state for Pins 14, 35, 36 when not actively switched in circuit.

 

Pair of 74HCT4053 Integrated Circuits

 

The control lines for 5 of the switches would all be connected together. Then dependent upon what state the control signal was (GND or +5v) the common side of the switch would be directed at either the PAL or NTSC Antic connections on the other side. Since there is one spare switch, that too can be connected to the common control signal, and the output side could select one of two LEDs to show the active Antic in a similar way to what the AntiX does.

 

Or there's something like this available from MAXIM MAX4948.

 

 

Now I wonder how close I am getting to the AntiX design?

 

[Fred_M]

On 9/18/2019 at 6:23 AM, Swami said:

Good summary: Swapping the ANTIC takes care of everything except you may or may not have coloring off, depending on the game, since the PAL-M has a different color palette than NTSC - which cannot be fixed by the ANTIC or GTIA.

As mentioned further in the Antix thread (it was not possible to edit the opening post), Antix creates a Pal-60 signal in a PAL machine with a NTSC Antic and a NTSC-50 signal (not Pal-M) when a PAL antic is put in a NTSC machine. Only a small number of displays can display a NTSC-50 signal. For a full PAL signal in an NTSC machine a PAL GTIA and crystals are needed. 

[flashjazzcat]

Here's a video documenting conversion of an NTSC 800XL to PAL:

 

 

The principle is the same on most other machines (except the 1200XL, which has no unpopulated PAL circuit on the board).

[Level42]

On 5/6/2020 at 4:08 AM, mytek said:

Parallel connected Antic chips: an experiment in isolation for the purpose of swapping between NTSC & PAL

 

I guess this as good a place as any to discuss Antic NTSC/PAL swap, since I don't want to disturb the AntiX topic.

 

Speaking of AntiX. Here's how the creator describes what is happening on his board...

 

After looking at the description, I started wondering if there might be an even simpler way. So I made an Antic sandwich for research purposes. I must mention the fact that I have no idea what the AntiX board's logic really looks like. No schematic and no actual board to reverse engineer. I just wanted the challenge, and to see what minimally would be required. And I'm not looking to duplicate the AntiX, but I might build something like this into one of my other ongoing projects.

 

 

The image above was taken with the Antic sandwich mounted in my XEGS.

All the extra wires that are seen surrounding the Antic socket,

are from various upgrade experiments that I have used this system for in the past.

 

I started by paralleling everything between the NTSC Antic on the bottom and the PAL Antic on the top, with the exception of Reset and FΦ0 (Fast 3.57Mhz clock sourced from GTIA) on the PAL Antic. I then tied the PAL Antic's Reset to GND and FΦ0 to +5v. I got this idea from a post that Bryan made many years ago.

What I'm trying to do is figure out how to float the signals tied in parallel, or in other words make them look like there is no actual connection to the system.

 

Fired it up, and got a pretty messed up picture.

 

Next I started disconnecting things on the PAL Antic that I suspected would interfere with the NTSC one. That would be Φ0 (the 1.79Mhz clock for the CPU), and REF (refresh for the DRAM). Things started to work... well almost.

 

Next I disconnected R/W from the PAL Antic and initially tied it to +5v for Read (NOT!), and then to GND for Write (Bingo that worked!). And thus far after doing this last bit everything that I've thrown at the sandwich runs as if there is only an NTSC Antic connected, which was the whole point of these experiments (e.g., can I isolate the parallel connected Antic).

 

So here's where I'm currently at signal-wise...

 

There are a total of 5 signal lines for each Antic that need to be switched in some manner to deactivate a given parallel connected Antic.

 

The deactivated state is as follows:

 

Pin-8 (/REF) disconnect and float

Pin-14 (R/W) Tie to GND

Pin-34 (Φ0) disconnect and float

Pin-35 (FΦ0) Tie to +5v

Pin-36 (/RST) Tie to GND

 

The last two pin assignments (Pin-35 and 36) are what floats the Address bus and a few other associated signals. Then bringing the write line low, puts the data bus in input mode. Essentially all these things remove a good portion of the Antic pins from the system bus electrically speaking, so that they don't interfere with the other parallel Antic. This would have to be done for each Antic in the sandwich that you wish to deactivate.

 

I could see using a pair of 74HCT4053 chips to do all the switching, and just use a couple of pull-down and pull-up resistors to determine the logic state for Pins 14, 35, 36 when not actively switched in circuit.

 

Pair of 74HCT4053 Integrated Circuits

 

The control lines for 5 of the switches would all be connected together. Then dependent upon what state the control signal was (GND or +5v) the common side of the switch would be directed at either the PAL or NTSC Antic connections on the other side. Since there is one spare switch, that too can be connected to the common control signal, and the output side could select one of two LEDs to show the active Antic in a similar way to what the AntiX does.

 

Or there's something like this available from MAXIM MAX4948.

 

 

Now I wonder how close I am getting to the AntiX design?

 

Yeah, without looking into the details that is very close to what I did.

 

I guess AntiX is history now.

[Level42]

By the way, the schematics and documents are available for all ABBUC members, but I don't have a problem uploading them here.

 

For now Fred and I have dropped the plans to have AntiX produced. There are in practice quite some issues to get the PCB produced.

[Level42]

Mytek, did you try moving a finger near the Antics while the machine was running ? I had issues with it freezing because apparently my finger induced a signal into one of the clock inputs. So I think I grounded both clock inputs  instead of just one.

 

There is also one signal that I switched......that isn't used in XLs and XE's but IS in 400/800.

[+mytek]

45 minutes ago, Level42 said:

By the way, the schematics and documents are available for all ABBUC members, but I don't have a problem uploading them here.

I don't have a membership to ABBUC. But this was really about challenging myself to figure it out in a day, how one could go about doing this.

 

45 minutes ago, Level42 said:

For now Fred and I have dropped the plans to have AntiX produced. There are in practice quite some issues to get the PCB produced.

Sorry to hear that. So what were the production issues exactly?

 

41 minutes ago, Level42 said:

Mytek, did you try moving a finger near the Antics while the machine was running ? I had issues with it freezing because apparently my finger induced a signal into one of the clock inputs. So I think I grounded both clock inputs  instead of just one.

I haven't been seeing that, although I'm not grounding the Fast CLK to disable the Antic. I found out that pulling it up to +5v worked better for me.

 

However having the 2 Antics stacked is not a good idea, since they both generate a good amount of heat, that after extended run would cause display errors to occur. Putting a very small 12v fan next to the stack and then running it from 5v (slow and quiet) was all that was needed to keep them cool, and no glitching.

 

41 minutes ago, Level42 said:

There is also one signal that I switched......that isn't used in XLs and XE's but IS in 400/800.

Which one was that?

 

----------

Actually I'm taking this much farther, and have been sketching out a plan to have dual Antics and GTIAs under electronic switched control. This way it would give you full compatibility with either video standard. Because just swapping Antic is a compromise that doesn't always work as expected on a given monitor. Although I do have one LCD that has no problem with using a PAL Antic in an NTSC system which is the worse combination. It's actually my favorite monitor, having excellent results from S-Video and Composite with our Atari's.

 

SHARP Model: LC-15B6U-SM

 

[+Stephen]

1 hour ago, mytek said:

Actually I'm taking this much farther, and have been sketching out a plan to have dual Antics and GTIAs under electronic switched control.

I like where this is going.

[Rybags]

Sounds good, but I wonder if you could do switching on the fly?  Or has that already been accomplished.

[+mytek]

4 hours ago, Rybags said:

Sounds good, but I wonder if you could do switching on the fly?  Or has that already been accomplished.

To answer your question, here's a preliminary look at where I'm going with this.

Yes this is a new project. I'm putting the iTari on hold for a while and pursuing this idea instead. /PAL is a connection that occurs in multiple places, but its source is an output on the TK-II utilizing new firmware. Its setting will be changed by an ALT+key press combination, and then stored in non-volatile memory to be restored upon power up. Essentially the idea is to be able to switch from one video mode to the other even while its running (PAL or NTSC), which might require the TK-II chip to issue a Reset simultaneous with the change. I'll start a new topic about this project when I get close to a completed PCB layout.

 

Because the color adjustment varies between GTIAs. Each one will get its own precision regulated color trimmer circuit.

 

Since this new project uses SRAM, the /REF output is not needed.

 

Just a warning... don't expect to see a working model for quite some time. Probably looking at end of the year or later. And this will definitely not get released to the public, so please don't ask. But anyone should feel free to utilize the schematics I will post to roll their own, or glean ideas for their own take on this.

 

[Rybags]

Looks like a lot of work going into this.   But it begs the question - why not do away with the shitty legacy video and go digital?

I don't know the innard of the likes of Sophia but isn't the new methodology to just sample the colour output of GTIA and calculate what's needed based on it's phase offset from the input clock, then do a calc or table lookup to determine what RGB or component values should be generated?

[+mytek]

14 hours ago, Rybags said:

Looks like a lot of work going into this.   But it begs the question - why not do away with the shitty legacy video and go digital?

I don't know the innard of the likes of Sophia but isn't the new methodology to just sample the colour output of GTIA and calculate what's needed based on it's phase offset from the input clock, then do a calc or table lookup to determine what RGB or component values should be generated?

The problem is that even with Sophia (either flavor) or VBXE, although you can get pseudo versions of PAL/NTSC by only changing the Antic chip, it's not truly the same as also swapping the GTIA along with it. And if your goal is to have HDMI output at the same time, this can be done externally for not much more money then the Sophia DVI (factoring in shipping) by going with a RetroTink Pro. Yes the RetroTink approach depends to a large degree on the quality and availability of the S-Video. Although what I've discovered with my motherboard redo projects, is that I can obtain the absolute best analog video from an A8 by using a power planed 4-layer PCB in conjunction with a UAV that looks pretty damn good after conversion to HDMI.

 

Other advantages to using something like the external RetroTink converter, is that it also supports audio pass-thru (audio embedded into the HDMI), which the Sophia DVI does not. So if that's what you need, there would be an extra cost and hassle to do so for the DVI option (by the time you factor in the DVI-to-HDMI cable and the audio injection box, you are well over any price advantage the Sophia brings). And one last thing, the RetroTink solution is much more universal when it comes to what HDTVs it will work with, whereas the Sophia DVI sometimes needs a core change in order to work with a particular TV. But in the end if what you want is the absolute best ever video clarity, the Sophia DVI would be the winner.

 

Any look at the pros and cons to what I propose in this personal project is really unimportant to the grand scheme of things, since it is purely a project of exploration. As in: "Can it be done?". Over the years there has been a lot of discussion of this very possibility, but it's never really gone past the discussion phase as far as I know. I'd like to see it actually happen and working in real hardware. Obviously it would be too complicated to make this as an upgrade kit for a stock A8, having problems isolating all the required signals due in large part to the locations of the Antic vs GTIA not being the same across the different models (no reliable way to piggyback to both chips from one add-on PCB). So to really see it in any practical way, it needs to be a new system design from the ground up.

 

Sometimes people like me just do things for the fun of it, with no commercial end product in mind.

 

[+tf_hh]

On 5/8/2020 at 8:24 AM, mytek said:

Yes this is a new project. I'm putting the iTari on hold for a while and pursuing this idea instead. /PAL is a connection that occurs in multiple places, but its source is an output on the TK-II utilizing new firmware. Its setting will be changed by an ALT+key press combination, and then stored in non-volatile memory to be restored upon power up. Essentially the idea is to be able to switch from one video mode to the other even while its running (PAL or NTSC), which might require the TK-II chip to issue a Reset simultaneous with the change. I'll start a new topic about this project when I get close to a completed PCB layout.

 

Interesting, I´ve done it nearly the same way on my upcoming (not yet published) SCCC V2.

 

Two things FYI: The /REF line must be used also to enable the CAS_Inhibit logic in the MMU or (!) U1MB. Without the usage of /REF you will get a lot of problems during PMG and some ANTIC modes, specially Hires. Sometimes the machine hang up. That´s my personal experience from several prototypes.

 

2nd: Some ANTIC I´ve in my drawer generates a spurious impulse on the /HALT signal even when the de-selected ANTIC has it´s RESET input grounded. I saw this 3 times using an "AMI" ANTIC with datecodes 83xx - PAL. If NTSC is affected I can´t check, I have only two NTSC ANTICs here.