Software incompatibility between Xl and XE?

[Gatherer of Data]

I know that some pre-Xl stuff can cause problems on newer models, but is there anything that will run on a XL, but not on a XE, or is compatibility 100%?

[mimo]

100% I believe. I have never had any problems.

[candle]

never heard about single case when software compatibilty issues would arrise after changing the enclosure

but who knows, maybe repainting might bring yet another software compatibility issues

 

ok, smartass mode off

[Sikor]

100% without software wrote for 1200XL especially (more function key, older basic - on cartridge, no build-in).

[Gatherer of Data]

Hmm, the consensus seems clear so far. What prompted this quesiton in part is this from Atarimania - Andreas Koch wrote the following, under the FAQ's 8.4 part:

Also note, that some software will not work correct (or not at all) on

newer XE/XEGS versions (which have a new OS with a new version number,

a new selftest/memory-test/keyboard-test, larger RAM chips, etc. etc.);

 

What could this be refering to?

Edited February 7, 2013 by Gatherer of Data

[www.atarimania.com]

IIRC, some versions of Blue Max don't work on the 130XE.

 

--

Atari Frog

http://www.atarimania.com

[Xuel]

Programs that write bad values to PORTB could fail on 130XE if they swap out banks of RAM they were relying on.

[drac030]

Hmm, the consensus seems clear so far. What prompted this quesiton in part is this from Atarimania - Andreas Koch wrote the following, under the FAQ's 8.4 part:

Also note, that some software will not work correct (or not at all) on

newer XE/XEGS versions (which have a new OS with a new version number,

a new selftest/memory-test/keyboard-test, larger RAM chips, etc. etc.);

 

What could this be refering to?

 

This refers to programs written by idiots, who "encode" the contents of their programs by EORing it with ROM. The differences between the "old" OS (v. 1.02) and the "new" one (v. 1.03) are pretty much limited to the version number itself, the release date and the control checksum value. The only major difference are changes in SelfTest which should not matter anyway, as it is swapped out ofthe memory space when a program is running.

[+CharlieChaplin]

Well,

 

first of all, I do not know the OS version number of the newer XE`s, but you can see it e.g. in the Selftest: a) the 1200XL function keys are gone in the keyboard test (note, they are only visually gone in the Selftest, they are still there in the OS), b) if the RAM has been upgraded to 128k then the memory test will also test the extra RAM - shown as 4 long bars (which represent the four extra banks, 16k each), etc. etc. Most of these XE`s were made in China and do have the faulty GTIA. Afair, there is a picture here on AA showing the Selftest / memory test with these 4 long bars, aka extra RAM...

 

Now, regarding incompatibilities - I found out that some A8 programs do not work correct or not at all on these XE`s with this kind of OS. Since I have long sold all these XE`s (I once had four of them, one belongs to Marius right now, who is very active in this forum) and only kept XL computers (currently I have eight of them), I do not remember anymore all the programs that did not work correct or not at all. All I do remember atm are four programs:

 

1) Muad Dib Demo by Hurek: The demo starts with a b/w text and while loading it continues to show more b+w text on the screen. On my 800XL computers (and most likely on XE computers that still have the same OS as the 800XL) the program runs fine, after the b+w text you can see the main parts of the demo.

Not so on the XE`s with the newer OS, here the demo crashes shortly after showing the b+w text...

http://atari.fandal....hp?files_id=654

 

2) Fpack 3.3 by SR-U: On the 800XL computer this program works fine, I can pack almost any program with it without problems (the packer uses page 4 for depacking, so programs that also use page 4 will not work of course). On the XE computers with the newer OS this program completely crashes, you just see a blank screen. Not much nicer on the XEGS: Here you see a garbled screen, filled partially with the program gfx and err, either Selftest or Missile Command gfx (it was one of them, do not remember anymore, if it was the Selftest or Missile Command)...

ftp://ftp.pigwa.net/stuff/collections/holmes%20cd/Holmes%201/ATR%20Programs/Applications%20A-Z/Flash%20Pack%203.3.atr

 

3) Ms. Pacman by Namco/Atari (cart.): Works fine on the 800XL computers (and XE computers with the same OS), had either gfx bugs or did not work at all on the XE computers with newer OS...

 

4) Encounter by Novagen: the original (copy-protected) version checks for the OS revision number, since it does not recognize the newer OS and its revision number, it does not work on XE machines with the newer OS...

 

Think in the end I noticed more than 20 programs that did not work correct or not at all on the XE`s with the newer OS. I solved the problem(s) easily, by selling all these XE`s and the XEGS. So nowadays I cannot test anymore which programs are incompatible, since I only have XL computers left...

 

-Andreas Koch.

Edited February 7, 2013 by CharlieChaplin

[Sikor]

1) Muad Dib Demo by Hurek: The demo starts with a b/w text and while loading it continues to show more b+w text on the screen. On my 800XL computers (and most likely on XE computers that still have the same OS as the 800XL) the program runs fine, after the b+w text you can see the main parts of the demo.

Not so on the XE`s with the newer OS, here the demo crashes shortly after showing the b+w text...

http://atari.fandal....hp?files_id=654

http://www.atari.org...pic.php?id=3664 - demo XOR data with OS ROM (only on loading).

 

Hmm, but I thing, that many of them check only OS revision, so it is only programmers bug.

I find backdays other thing: on "Garfield" demo by Jakub Husak sometimes (old OS revision, Atari 65XE, PAL) was lost some letters (demo written in pure Action!). When I restart demo by Reset key - all was O.K.. There are few more programs with "erroirl" like this. What is problem? OS revision? No - Freddie and No Freddie computer versions. Sometimes - RAM version (1bit - all XL's and first XE's, 4-bits - newest) - are incompatible sometimes...

So, I think - all XL/XE are compatible (in 99% - without 1200's of coz), sometimes bugs are only protect method problem / os revision "read" / minor changes in chips.

================

One more about Muad Dib:

http://www.atari.org.pl/forum/viewtopic.php?id=4120

"Muad Dib" by Hurek ("Hurek proudly presents" na początku). Demo jest "zaszyfrowane" przy użyciu klucza' date=' którym jest zawartość ROMu z 1983, więc zawiesza się na XE z ROMem z 1985 i na emulatorach z włączonymi patchami.[/quote']

Sorry for my english, Fox wrote somethink like this:

"Muad dib by Hurek ("Hurek proudly presents" on beginning). Demo are "encrypted" by key, wchich is ROM content from 1983, so - are break on XE ROM from 1985 and on emulators with patches on"

Edited February 7, 2013 by Sikor

[phaeron]

There are three differences in hardware behavior that manifest at least between my 800XL and 130XE and can cause incompatibilities:

• IRQ timing. The minimum IRQ delay time is two cycles on my 130XE and three cycles on my 800XL. This can cause IRQs to execute at slightly different times.
  
• Floating/non-floating data bus. On my 800XL, unassigned addresses like $D600 always return $FF. On the 130XE, they return whatever was last on the bus. I have seen programs do crazy things that can be affected by this -- one had a bug where it would jump to an address in the $D5xx range and happened to work on XL systems because it would execute $FF opcodes until it hit the math pack, after which it would run some random code and then RTS. It looked like it had been generated by some cartridge-based freezer.
  
• GTIA timing. XL and XE systems often have slight timing/behavior variations when PRIOR is changed on the fly. This has caused problems where people have written demos with tricky mid-screen mode switching and ended up with artifacts on the other system type.
  

[Rybags]

Another PortB difference is that bit 6 controls the Missile Command Rom on XEGS and could inadvertantly get switched in by incorrect programming.

 

Relying on specific data in the OS Rom - really, that lesson should have been learned early on in the XL days, any software that either relies on specific data or does illegal calls should never have been released after then but of course previous mistakes do get repeated.

 

TRIG function of GTIA used for keyboard detection on XEGS but I doubt it gets anything into trouble.

[Creature XL]

There are three differences in hardware behavior that manifest at least between my 800XL and 130XE and can cause incompatibilities:

• IRQ timing. The minimum IRQ delay time is two cycles on my 130XE and three cycles on my 800XL. This can cause IRQs to execute at slightly different times.
  
• Floating/non-floating data bus. On my 800XL, unassigned addresses like $D600 always return $FF. On the 130XE, they return whatever was last on the bus. I have seen programs do crazy things that can be affected by this -- one had a bug where it would jump to an address in the $D5xx range and happened to work on XL systems because it would execute $FF opcodes until it hit the math pack, after which it would run some random code and then RTS. It looked like it had been generated by some cartridge-based freezer.
  
• GTIA timing. XL and XE systems often have slight timing/behavior variations when PRIOR is changed on the fly. This has caused problems where people have written demos with tricky mid-screen mode switching and ended up with artifacts on the other system type.
  

The smart asses should read this post

 

 

Can someone tell me was this "XOR with ROM" is all about?

Except for character bitmaps from the charset-ROM I can't think of any case where I want to fetch data from the OS.

Is it about saving some bytes as opposed to defining my own constants?

[phaeron]

Copy protection. You try running with a custom OS, the game inexplicably crashes on load in garbage code. Nowadays, between emulation and hardware freezers, it's not nearly so difficult to figure out what happened....

[+therealbountybob]

100% I believe. I have never had any problems.

Make that 99.9%

"Pole Position X" used to run on the XL but not the XE but I had Fandal patch it a while ago

[+tf_hh]

Hi,

 

IRQ timing. The minimum IRQ delay time is two cycles on my 130XE and three cycles on my 800XL. This can cause IRQs to execute at slightly different times.

 

Floating/non-floating data bus. On my 800XL, unassigned addresses like $D600 always return $FF. On the 130XE, they return whatever was last on the bus. I have seen programs do crazy things that can be affected by this -- one had a bug where it would jump to an address in the $D5xx range and happened to work on XL systems because it would execute $FF opcodes until it hit the math pack, after which it would run some random code and then RTS. It looked like it had been generated by some cartridge-based freezer.

 

The reason for floating data bus on the XE series is the "Tramiel Save-Mania". On all XL PCBs there are pull-up resistors of 10 kOhm for the datalines D0...D7. So when no RAM or no ROM/IO-block is selected, the CPU reads always $FF back. Some monitor programs, the Speedy 1050 sector-copy-program and others expecting $FF in non-used areas, so some strange issues can be happen.

 

When using the Speedy 1050 sectorcopy, sometimes formatting a disk on non-Atari-Diskdrives or non-stock Atari-Diskdrives will fail, because the software uses $D500-$D5FF as "format buffer" and assumes, that there are only $FF. When the diskdrive on the other hand really inspects the 130 bytes sent with the format commando and gets garbled data, it hangs up or sent a NAK.

 

A harmless issue is a nice floating line of garbled dots in monitorprograms like in submon. The author wants to save 40 bytes of valued RAM and let point a line for visual "windowing" to $D500. On the XL (without SDX enabled or any cart inserted) it looks normal, on every XE it looks like this:

 

 

Here´s the reason, a look to the actual DL (Display List) when Submon is loaded:

 

 

Simple solution: Solder a 8-times 10K resistor array to D0...D7, common to +5 Volts. That´s all.

 

For the IRQ handling... do you have more informations? I can´t imagine why this difference may happen unless all main ICs are the same - and freddie has no effect on IRQ.

 

Jurgen

[phaeron]

For the IRQ handling... do you have more informations? I can´t imagine why this difference may happen unless all main ICs are the same - and freddie has no effect on IRQ.

 

Not sure, but it does seem to be a combination timing and temperature sensitivity issue. If I let the 130XE warm up on a warm day, it will gradually change its behavior (I forget which way... it's currently winter here). For the GTIA issue, I can actually see the boundary case get sparkly while this happens, and then revert it with canned air.

[HiassofT]

For the IRQ handling... do you have more informations? I can´t imagine why this difference may happen unless all main ICs are the same - and freddie has no effect on IRQ.

This has to do with POKEY and seems to affect all systems.

 

POKEY asserts IRQ very late during PHI2, and the CPU samples IRQ on the falling edge of PHI2.

 

If POKEY gets warmer, IRQ is asserted slightly later and the setup time of the IRQ input on the CPU isn't met - and the CPU "sees" the IRQ one cycle later.

 

So you have to be prepared that POKEY (timer) IRQs aren't absolutely cycle exact, they could "occur" (be seen by the CPU) one cycle later than you'd expect.

 

I also observed this behaviour when doing research on POKEY and SIO timing and wrote quite a bit about it in this thread:

http://www.atariage....s/#entry2081463

 

so long,

 

Hias

[atari8warez]

I solved the problem(s) easily, by selling all these XE`s and the XEGS. So nowadays I cannot test anymore which programs are incompatible, since I only have XL computers left...

 

-Andreas Koch.

 

Hmm, I would have solved the problem the other way around, by dumping those incompatible programs, but I guess you like XLs more anyway....

[thorfdbg]

1) Muad Dib Demo by Hurek: The demo starts with a b/w text and while loading it continues to show more b+w text on the screen. On my 800XL computers (and most likely on XE computers that still have the same OS as the 800XL) the program runs fine, after the b+w text you can see the main parts of the demo.

Not so on the XE`s with the newer OS, here the demo crashes shortly after showing the b+w text...

But this is not the fault of the Os. It is the fault of the crappy program... It expects exact byte sequences in the ROM which are used to decode its code, and it also jumps directly into the Os. So what do you expect to happen?

[+CharlieChaplin]

But this is not the fault of the Os. It is the fault of the crappy program... It expects exact byte sequences in the ROM which are used to decode its code, and it also jumps directly into the Os. So what do you expect to happen?

 

Yes,

 

and the same is true for all 400/800 only programs that only run under OS A or OS B. Atari already changed the OS various times and we had incompatibility problems in the past. They came with the Translator disk therefore. Its true, that this is not the fault of the OS, its the fault of the programmers...

 

However, in the late 80s (1989 onwards) the Tramiels were not really interested in the 8Bits anymore, why they still changed the OS in some of the (later) XE computers (while they used the same OS as in the 800XL in all XE`s released in 1985-1988/1989) is a mystery... and in my eyes this wasn`t a good choice nor a good decision. [irony on] Maybe they should have released a translator XL disk then, one that installs the 800XL OS into these later XE computers with the new OS, ha ha ha... [irony off]

 

Besides, if anyone with a newer XE (and newer OS) wants an 800XL OS ROM for better compatibility, I do have three or four of them left... -Andreas Koch.

 

P.S.: The XEGS has a 32k ROM (16k OS, 8k MC, 8k AB), would it be possible to install a switchable 32k eprom that has a) 800XL OS (16k length) and b) OS A (padded for 16k length) on it ?!? Or would there occur problems with the detachable keyboard or the bigger sized and faster RAM-chips or the (then) missing Atari Basic or any other things ?!?

[thorfdbg]

and the same is true for all 400/800 only programs that only run under OS A or OS B.

Things aren't quite as simple. Actually, only a minority of programs fail under the XL Os because they jump directly and intentionally into the operating system. The only exception I know are programs written under some dialect of Forth - I forgot which.

 

I remember a couple of issues old programs have: The most popular is because programs accidentally overwrite the newly introduced shadow copy of TRIG3 in page 3, and the VBI of the XL Os then intentionally locks up (probably as part of a copy protection for cartridges). A couple of older synapse games fail due to a programming error where timer 1 is ended incorrectly by RTI instead RTS.

 

Atari already changed the OS various times and we had incompatibility problems in the past. They came with the Translator disk therefore. Its true, that this is not the fault of the OS, its the fault of the programmers...

 

However, in the late 80s (1989 onwards) the Tramiels were not really interested in the 8Bits anymore, why they still changed the OS in some of the (later) XE computers (while they used the same OS as in the 800XL in all XE`s released in 1985-1988/1989) is a mystery... and in my eyes this wasn`t a good choice nor a good decision.

This is hard to say - first of all, I don't think such decisions are really made at the highest level of the management. Second, I'm not even clear what was changed, and why. It was at least a valid decision to change something, probably to fix bugs, as the Os interface remained stable. Even more so, every programmer should have understood by then that depending on specific ROM addresses is doing something seriously wrong.

 

P.S.: The XEGS has a 32k ROM (16k OS, 8k MC, 8k AB), would it be possible to install a switchable 32k eprom that has a) 800XL OS (16k length) and b) OS A (padded for 16k length) on it ?!? Or would there occur problems with the detachable keyboard or the bigger sized and faster RAM-chips or the (then) missing Atari Basic or any other things ?!?

 

I don't think the keyboard is causing a problem, neither the lack of Atari basic (the XL rom works fine even if no Basic ROM is found). It is just that the addressing of the ROM chip in the XEGS does not support such switching - some soldering would need to be done, probably even more than on an XL where the additional pin would be either grounded or connected to VCC,

 

Greetings,

 

Thomas