PAL vs. NTSC issue on original hardware only

[erichenneke]

Here in the USA my actual machines are all NTSC of course ( I have several stock 800XL's and a few stock 130xe's... all are NTSC, none of them have been modified in any way ).

 

I have run into an issue where my program works fine on all my NTSC hardware, and also works fine on both NTSC and PAL emulation ( both in A800win and Altirra, in 800XL and 130XE settings ), but now when somebody else is trying to run the program on actual PAL hardware they are seeing some PM graphics as garbage on the screen.

 

I have never seen this garbage issue with the program in all the modes I tested above, but of course I do not have an actual PAL system to test on. So my testing has all be actual NTSC machines and emulation(both PAL and NTSC).

 

Do any of you have any ideas as to why an actual PAL system (which I am told is fully stock PAL 800XL) would be having garbage on the screen when it works fine when I test it on actual NTSC hardware and in PAL emulation?

 

Really appreciate your help!

Thanks,

Eric

[phaeron]

Uninitialized memory access is a possible culprit. The OS clears most main memory on startup, but the EXE loader will leave behind nonzero memory that your program may pick up. Also, the OS does not clear memory location 0, so make sure you don't have an LDA 0 when you mean LDA #0. Extended memory and memory under the OS ROM are not cleared at all by the OS and should especially be cleared manually.

[sanny]

I'm living in a "PAL country" (Germany), but I've bought a NTSC machine (in fact, in the meanwhile two: a 130XE and a 1200XL). The reason was to test my programs on NTSC and compare the NTSC emulation of the Dreamcast version of the Atari800 emulator to the "real thing".

I've also bought a "multi-system" TV set on Ebay for €3 (ok, I had to drive a few 100 kms to pick it up, so with the gasoline the actual costs were higher).

 

So I'm now set up to be able to run a program both on PAL and NTSC hardware.

 

If you send me your program I can check on hardware and the Atari800 emulator. If it behaves differently on hardware and emulation it would indicate a problem in the emulation. I could take a look at that.

[Rybags]

Strange sounding problem. The suggestion of uninitialized memory is good but would equally apply to NTSC and PAL.

 

My suspicion is that possibly your program also has garbage in NTSC but it's just not visible. PAL CRTs will usually show the entire 240 scanlines of normal Atari video, plus a few more. NTSC CRTs will usually show less than 240. There's also overscan area in the horizintal plane that might be visible or not.

 

Suggestion - try your program under same circumstances in Altirra with the video options set to show the entire display, and see if it still happens. The emulation is sufficiently good that any anomolies that occur on real machines should also occur there.

[erichenneke]

I'm living in a "PAL country" (Germany), but I've bought a NTSC machine (in fact, in the meanwhile two: a 130XE and a 1200XL). The reason was to test my programs on NTSC and compare the NTSC emulation of the Dreamcast version of the Atari800 emulator to the "real thing".

I've also bought a "multi-system" TV set on Ebay for €3 (ok, I had to drive a few 100 kms to pick it up, so with the gasoline the actual costs were higher).

 

So I'm now set up to be able to run a program both on PAL and NTSC hardware.

 

If you send me your program I can check on hardware and the Atari800 emulator. If it behaves differently on hardware and emulation it would indicate a problem in the emulation. I could take a look at that.

Thanks!!! I just sent you a copy as a private message. Take a look and let me know what you see and think could be going on.

 

-Eric

[erichenneke]

Strange sounding problem. The suggestion of uninitialized memory is good but would equally apply to NTSC and PAL.

 

My suspicion is that possibly your program also has garbage in NTSC but it's just not visible. PAL CRTs will usually show the entire 240 scanlines of normal Atari video, plus a few more. NTSC CRTs will usually show less than 240. There's also overscan area in the horizintal plane that might be visible or not.

 

Suggestion - try your program under same circumstances in Altirra with the video options set to show the entire display, and see if it still happens. The emulation is sufficiently good that any anomolies that occur on real machines should also occur there.

thanks Rybags. Yes, the program is using some of the tops and bottoms of the player area memory locations to store some data where it shouldn't be visible. However, when running in Altirra PAL with all the entire screen/overscan visible there doesn't seem to be any visible garbage on the screen, so I don't think that's the problem.

 

I am still trying to get a snapshot or video of the issue being experienced on the actual PAL hardware, so I do not yet know exactly what the "garbage" looks like.

[erichenneke]

Uninitialized memory access is a possible culprit. The OS clears most main memory on startup, but the EXE loader will leave behind nonzero memory that your program may pick up. Also, the OS does not clear memory location 0, so make sure you don't have an LDA 0 when you mean LDA #0. Extended memory and memory under the OS ROM are not cleared at all by the OS and should especially be cleared manually.

reviewed all the code for any LDA 0 LDX 0 LDY 0 and not seeing any unintentional use of locations zero (good suggestion though!)

 

Also, I just created a new build that loads up zeros into all the memory locations used by the program before it loads to make sure there isn't any uninitialized memory causing the issue. I sent this to the person experiencing the garbage on actual PAL system and I am awaiting their test and feedback.

[phaeron]

The thing about NTSC vs. PAL is the person testing on the PAL machine is almost certainly not using exactly the same setup as the NTSC machine. The differences between NTSC vs. PAL are minimal and very well known, but there are going to be lots of other differences just by virtue of it being a different machine run by a different computer, such as:

• EXE loader. The computer doesn't have a built-in EXE loader, so one has to be supplied, and there are many different ones with different RAM usage. Are they using Atari DOS, SpartaDOS X, MyPicoDOS, AspeQT/RespeQT loader, SIDE loader, AtariMax cartridge, etc.?
• BASIC or SpartaDOS X. Do you need BASIC disabled? Emulators will do this for you, real computer not so much. When run from SDX, do you need the SDX cart disabled (X.COM)?
• Computer type. Is it an 800XL or a 130XE? It's difficult to make a program that will only run correctly on one or the other for a reason besides extended RAM, but it has happened. The main mechanism: reading unassigned hardware addresses.
• RAM type. If you do happen to be reading uninitialized memory under the OS ROM, you can end up being sensitive to the brand of RAM chips in the system. One demo ended up crashing on certain systems as a result....
• Disk type. Certain disk types can result in near-deterministic or fully deterministic frame timing. SIO timeouts are VBI-based, so issuing a command that times out results in execution being locked to the VBI.

Also, check your initialization code. If you have a dirty display switch at startup, the extra VBL time in PAL could make a difference as to when your display switch occurs since it would be more likely to happen in VBLANK. One way you can get P/M garbage on screen is turning off P/M graphics DMA without either shutting off GRACTL or clearing the graphics latches. The former will give you bus noise on screen while the latter will create solid ribbons. Altirra emulates both, but whether it occurs at all could be timing related.

[+CharlieChaplin]

Okay,

 

it is me who is testing the program on two PAL Atari 800XL with 64k RAM, standard XL-OS (Rev. 2) and errmm, 512k extended RAM (no switch installed, thus 576k RAM is always there)... the 512k SRAM was made by mega-hz, it is the same upgrade that tfhh sells and more or less the same upgrade as HiasSoft`s 512k SRAM upgrade... and also one PAL 800XL with standard XL-OS and just 64k RAM (no memory extention).

 

[stereo was always switched off, Basic was always switched off; no other upgrades in the machines, meaning no 65816, no VBXE, no audi-board, no SDX, no My-IDE, no SIDE, nothing hanging on the PBI, nothing in the cart slot, just 576k RAM or 64k RAM and XL-OS active]

 

 

- the program comes as a CTB program with Runtime, linked into one *.XEX file with CTB-linker

(it uses RAM under the OS and works only on 64k or bigger machines)

- since the CTB-Runtime does not switch off Atari Basic automatically, I added (appended/merged/linked) a Basic-off switch in front of it (uses $0400-042C, Init $0400; page 4 is fully available again, after Basic has been switched off - the routine is from Bill Wilkinson, released as a type-in in Compute! magazine, nowadays spread all over the world)

 

- the program is unpacked (so a packer is not the source of the problem!) and it loads normally without any bugs, it displays a Gr. 2 text "Loading...", then the title screen appears;

 

- when I start the program with paddle fire-button (or joystick movement to the left which matches paddle fire button), the game screen appears normally without bugs (your gun/cannon is there, mountains are there, etc.); a scroller can be seen on the top of the screen which says "Mission x:..." (e.g. Mission 1: Kill ten chutes... or something like that) and all is fine up to here...

 

- right after this scroller the game should begin and players/missiles (planes, parachuters) should appear on the screen which you can shoot down with your gun; but instead of the pm, there is only garbage in form of vertical stripes - every pm is garbage / a vertical stripe... except your gun/cannon (when you shoot, you get endless points, but it is no fun getting endless points for shooting garbage...)

 

The strange thing is, the garbage does not happen all the time. For my tests I did several coldboots by powering on my 800XL again and again (not good for a machine from 1983, but anyways). I always waited the 10-30 seconds for the RAM to lose contents. And I loaded the program with DOS 2.5, Nano-DOS (a gamedos), two bootloaders and MyPicoDOS (another gamedos) five times each. The result: With DOS 2.5, Nano DOS and the bootloaders I always got the garbage, with MyPicoDOS I sometimes did get garbage and sometimes not... so I am out of clues what is wrong here. Maybe it is just my 800XL computer that is faulty - but I tested the program on three different machines (two 800XL with 576k RAM and one 800XL with 64k RAM), all with the same results... and I do not believe all these machines are faulty...

 

Alas, I cannot do screenshots from my 800XL and tv screen showing the garbage-bug tonight. This will have to wait until tomorrow. And errm, the (buggy?) program is an entry for the Abbuc Software Contest, so that is why we need a solution fast... (and we are, alas, not allowed to upload the program here).

 

-Andreas.

 

P.S.: Besides using real 800XL computers, I also use 1050 drives with Speedy enhancement...

 

 

BASOFF.XEX

Edited September 5, 2016 by CharlieChaplin

[phaeron]

Sounds like either the P/M bits are not getting set in DMACTL or the P/M bits in GRACTL are getting reset.

 

If the author's willing to send me the build over PM, I can try to reproduce in emulation.

[Rybags]

Does the program use it's own VBlank routines to the point where the OS isn't any longer handling shadow registers?

 

That could be a possible cause. Intermittent problems mean that some value is getting initialized but occasionally the OS VBl executes that one more time before you disable it.

[+CharlieChaplin]

Errrm, found out something today...

 

When I booted the game at first it did run fine to my surprise. Tested it again and again, but it always did run fine (even if I loaded other programs before). But after the Atari was powered on for approx. 3 hours, the garbage-bug (or better the vertical stripes) were suddenly there again. Since this did not happen in all the tests I did before, it looks like this bug has something to do with heat. Either Antic or GTIA or both produce that bug when they are powered on for some hours (when they are hot)...

 

So, the bug has nothing to do with the game (software) it seems, but with my hardware... (Antic or GTIA chip)... have to ask Juergen if this is normal or if I should replace one or both chips.

[erichenneke]

Does the program use it's own VBlank routines to the point where the OS isn't any longer handling shadow registers?

 

That could be a possible cause. Intermittent problems mean that some value is getting initialized but occasionally the OS VBl executes that one more time before you disable it.

No. Using a deferred VBI and exiting with a JMP 58466. Using all the standard OS routines.