PALNTSC upgrade Question

[puppetmark]

I would like to install a PAL Antic Chip in a 130Xe via the attached upgrade instructions. I have the PAL antic chip already. I dont know how to patch the OS. I have the 130xe rom file and I know how to disassemble it but the instructions explain the required change as part of the source code, so how do I figure out where to patch the disassembled code? Even if someone has the patched OS I would still like to learn how to do this. I know the basics of machine language coding. Here is what i used to dissasemble the rom:

 

http://www.atarimax.com/dis6502/

 

Here are the instructions:

PALNTSC.TXT

 

Thanks in advance!

[Urchlay]

I would like to install a PAL Antic Chip in a 130Xe via the attached upgrade instructions. I have the PAL antic chip already. I dont know how to patch the OS. I have the 130xe rom file and I know how to disassemble it but the instructions explain the required change as part of the source code, so how do I figure out where to patch the disassembled code? Even if someone has the patched OS I would still like to learn how to do this. I know the basics of machine language coding. Here is what i used to dissasemble the rom:

 

You don't really need to disassemble and reassemble the ROM. From the instructions:

 

The required modification was very simple: I just changed address $C386 to be "1" instead of "0".

 

I'd probably do this by editing the OS image file (usually "atarixl.rom") in a hex editor. The ROM starts at $C000 in the Atari, but the hex editor doesn't know that (it just works on raw images), so you'll want to find offset $0386, which should contain a 0, and change it to a 1. Save the edited file and burn to an EPROM, you're done (if you're paranoid, you could test the modified image in an emulator before burning it).

[Rybags]

I don't get it.

 

Why would you want to patch the OS, just so the shadow PALNTS flag is set correctly?

 

Only XL/XE uses that flag, so anyone writing a game/demo which needs to know whether a system is PAL or NTSC would check the ANTIC register anyway.

 

And, since the system clock is still at the NTSC rate, setting that flag to PAL would cause the PAL tables to be used for SIO instead of the NTSC ones.

 

That patch also retains the NTSC key repeat rate (which you would probably not want as they'd be painfully slow on a PAL VBlank rate).

 

If I was going to the trouble of making a patched OS ROM, I'd add some enhancements like no attract mode and faster key rates.

 

C383   A9 06		 LDA #$03   ;NTSC detected  * key repeat rate
C385   A2 01		 LDX #$01   ;(used to be LDX #$00)
C387   A0 30		 LDY #$14   ; * key repeat delay
C389   8D DA 02			 STA $02DA  ;KEYREP - Rate or key repeat
C38C   86 62		 STX $62	;PALNTSC
C38E   8C D9 02			 STY $02D9  ;KRPDEL - Auto delay rate

 

Changes "*". That will change the key rates. Probably best to work out your own preferences in the emulator. POKE 729/730 with the delay/rate. Smaller values = faster.

[ijor]

Only XL/XE uses that flag, so anyone writing a game/demo which needs to know whether a system is PAL or NTSC would check the ANTIC register anyway.

 

And, since the system clock is still at the NTSC rate, setting that flag to PAL would cause the PAL tables to be used for SIO instead of the NTSC ones.

 

It's the other way around, Rybags. The PAL hardware register is in GTIA, not in ANTIC (some newer demos might measure ANTIC refresh rate, but older software probably does not).

 

Indeed, changing ANTIC won't change the crystal, but will change the refresh rate. So this is actually a "mixed" setup. But the most relevant timings are refresh rate (and not crystal) related, so it probably does make sense to patch the ROM.

 

Edit: I think I misunderstood your post. ANTIC/GTIA was probably just a typo. You mean OS patch won't help for games, they will go to the hardware directly. I agree. Still, it might be better to patch the OS.

Edited July 26, 2007 by ijor

[Rybags]

My mistake there - for some reason I was thinking ANTIC had the register but it is on GTIA.

 

But my thoughts are "why?", especially since that patch didn't even bother to change the key-rate. I guess that the OS does need to convince itself it's PAL though, since cassette I/O depends on the timing of reading the block headers (which relies on VCount and the passing of VBIs). Also, I believe it uses slightly different POKEY divisors to establish the baud rate.

[ijor]

My mistake there - for some reason I was thinking ANTIC had the register but it is on GTIA.

 

Probably because it would make more sense in ANTIC After all you are usually interested in the refresh rate (ANTIC) and not on the color system (GTIA). It is true that Antic refresh rate can be measured, but I don't think anybody did that in the old days.

 

But my thoughts are "why?", especially since that patch didn't even bother to change the key-rate. I guess that the OS does need to convince itself it's PAL though, since cassette I/O depends on the timing of reading the block headers (which relies on VCount and the passing of VBIs). Also, I believe it uses slightly different POKEY divisors to establish the baud rate.

 

I didn't check what that patch actually does. So possibly it is not the right patch. But yes, you need to patch it for tape handling. I don't think it changes the pokey divisors for compensating the difference in the crystal, the difference is too small. That difference is relevant for very high SIO rates only (as used in some drive mods).

[puppetmark]

Wow, this turned out more informative than I thought! Thanks for the great input. I used a hex editor and made the appropriate change with the help you gave me Urchlay. Fun Stuff! I am looking forward to enjoying PAL software with out the jumping and overscaning.

[Shawn Jefferson]

I've done this on one of my machines, but not the ROM patch. Is there any need to do this, by that I mean, does any software look at it and refuse to run if it finds a NTSC machine?

[Rybags]

Not that I know of.

 

Like I've said before, it would make sense to check the hardware register since the shadow is only specific to XL and later machines.

 

If it were the case that you found some objectionable software, someone could easily enough just patch it so it works anyway.

 

Or, we could make a special boot disk that plugs in the value to the shadow register then prompts to insert a normal boot disk.

[puppetmark]

Not that I know of.

 

Like I've said before, it would make sense to check the hardware register since the shadow is only specific to XL and later machines.

 

If it were the case that you found some objectionable software, someone could easily enough just patch it so it works anyway.

 

Or, we could make a special boot disk that plugs in the value to the shadow register then prompts to insert a normal boot disk.

 

That's very true. I think its nice to have the patched ROM just in case. I enjoyed figuring out how to patch it. I have been wanting to learn how to do this for a while and I figured this was a good way to get started. I learned how to dissasemble the rom, and then use a hex editor to change the values. Now, I can make more changes to the OS. Does anyone know where I can get the source code for the atari XL /XE OS?