Jump to content
IGNORED

Atari cartridges differences


Martin72

Recommended Posts

I have a question about Atari XL cartridges: i have an old brown cartridge for example of the game Donkey Kong Junior. That cartridge works fine in my Atari 600XL with 64k Ram . When i use the same game but in a grey cartridge then the game doesn't work fine in the Atari 600XL. In a 65XE or a 130XE the problem doesn't occur, so the grey cartridge seems to be ok. The same problem occurs at the game RealSports football. Do someone know the difference between a brown and a grey cartridge internally (maybe another layout?)

Edited by Martin72
Link to comment
Share on other sites

What exactly happens with the grey cart in the 600XL? Black screen, or the game plays with garbage on the screen, or what?

 

I've got a 64K upgraded 600XL and a grey Millipede cart... the cart works fine on my XEGS and 800, but not on the 64K 600XL. I get extra pixels on the screen, the same color as the mushrooms. The game is actually playable (the extra pixels don't seem to trigger collision detection). All my other carts work fine on the 600XL... and Millipede plays fine when loaded from disk. So, like you, I think something weird is going on inside the cartridge.

Link to comment
Share on other sites

I have a question about Atari XL cartridges: i have an old brown cartridge for example of the game Donkey Kong Junior. That cartridge works fine in my Atari 600XL with 64k Ram . When i use the same game but in a grey cartridge then the game doesn't work fine in the Atari 600XL. In a 65XE or a 130XE the problem doesn't occur, so the grey cartridge seems to be ok. The same problem occurs at the game RealSports football. Do someone know the difference between a brown and a grey cartridge internally (maybe another layout?)

Most (or maybe all) brown game carts will probably work with 16K of RAM.

Most XEGS grey carts require 48K or more of RAM (some 64K). There are some re-releases of old carts in grey that should work with 16K of RAM.

 

600XLs have 16K ram by default and can be updated internally or externally to have more.

 

--Ken

Link to comment
Share on other sites

In the Atari 600XL (internally updated to 64k) the beginscreen of the "Donkey Kong Junior" game starts up normally but when i start the game the screen seems to be freezed and nothing happens anymore.

The same happens at both of cartridges, but in the 65XE or 130XE they work fine. So i think there is a small difference in the layout of the pcb of the grey cartridges with grey label or something else (or there's a little difference in the 600XL).

But i understand you have a comparable problem with the grey Millipede cartridge.

By the way it is not at all grey cartridges: my grey moonpatrol cartridge works fine in the 600XL also the XE-blue-label grey 64 k cartridges (like Mario Bros).

Edited by Martin72
Link to comment
Share on other sites

600XLs have 16K ram by default and can be updated internally or externally to have more.

 

We both have internal 64K upgrades... I did mine with a pair of 64Kx4 RAM chips from an old ISA video card.

 

In the Atari 600XL (internally updated to 64k) the beginscreen of the "Donkey Kong Junior" game starts up normally but when i start the game the screen seems to be freezed and nothing happens anymore.

The same happens at both of cartridges, but in the 65XE or 130XE they work fine. So i think there is a small difference in the layout of the pcb of the grey cartridges with grey label or something else (or there's a little difference in the 600XL).

But i understand you have a comparable problem with the grey Millipede cartridge.

By the way it is not at all grey cartridges: my grey moonpatrol cartridge works fine in the 600XL also the XE-blue-label grey 64 k cartridges (like Mario Bros).

 

Wait, the same thing happens with both carts (brown and grey Donkey Kong Jr), or just the grey one?

 

When the problem with the Millipede cart first came up, someone suggested it might be a bad capacitor inside the cart... and someone else suggested it might be that the replacement RAM chips have different timing than the originals (too bad I never tried Millipede on the 600XL before upgrading it). I packed up everything I own and moved not long after that, and the 600XL was in storage until 2 weeks ago... and now I can't find the Millipede cart. When/if I do find it again, I was going to see if I could either replace the cap inside the cart, or swap ROMs with a working cart (assuming the ROMs are socketed in the grey carts like they were in the brown ones).

 

Also I've got 6 more 64Kx4 RAMs if I can find them, was going to try swapping those into the 600XL... though I doubt it'll change anything: all 8 chips came from the same ISA super VGA card, they should be identical. Also everything else I've tried works great on that 600XL, including a BASIC XL cart (if something were wrong with the cart port, I'd expect a bankswitching cart to fail).

 

Another thing I might try: burn an EPROM of the Millipede code and see if that works in the cart.

 

Do you (or anyone) know whether the grey Atari carts are socketed?

Link to comment
Share on other sites

I must agree that this sounds like a RAM problem. Selective cartridge failure can be attributed to how that cart program operates when there is an absence of RAM after $3FFF.

 

My first Atari was a 600XL with the memory expander module (back in 1985). After a number of years of use and transporting I would occasionally encounter a bad connection between the computer and module. This resulted in the absence of the extra RAM.

Regardless of the type of memory upgrade you have, suggest using the in-built self test function (hold down option at powerup, no cartridges) and select the memory test. This will let you know if your memory upgrade is letting you down. Note that if you enter the self test mode from basic by typing 'BYE' you will never see 48k of ram since the basic rom is occupying the last 8 kilobytes.

 

 

As an aside, there is a disk that PAGE 6 magazine used to sell containing some digitized music demos. This disk did not work on my XEGS. At first I suspected the XEGS and examined the circuitry intently but subsequently could not fault. It then occurred to me that the XEGS was not necessarily 100% hardware compatible with an XL. I tried the disk with my XL and it worked fine. After examining the machine code I discovered that the author had skipped convention when using register $D301 for bank switching. Instead of loading the register and then manipulating the appropriate bit(s), the author loaded the accumulator with a specific byte and stored it into $D301. From memory there was one or two bits set to zero that should have been set to on. Moral of the story is to question the premise of your conclusions! I was so close to dismantling my XEGS.

Link to comment
Share on other sites

I must agree that this sounds like a RAM problem. Selective cartridge failure can be attributed to how that cart program operates when there is an absence of RAM after $3FFF.

 

You mean Martin72's problem, not mine? 'Cause in my case, if the game's using the extra RAM, it wouldn't keep playing (with minor graphics glitches), it would die...

 

My first Atari was a 600XL with the memory expander module (back in 1985). After a number of years of use and transporting I would occasionally encounter a bad connection between the computer and module. This resulted in the absence of the extra RAM.

Regardless of the type of memory upgrade you have, suggest using the in-built self test function

 

With the internal memory upgrade, you actually remove the original pair of 16Kx4 chips and replace them with 64Kx4s. So they're "all or nothing", you won't encounter a failure condition where the new/extra RAM disappears but the old remains... I suppose a cold solder joint could intermittently cause part of the address space to not be decoded correctly, but I've left it in self-test before and let it run for a couple of hours, never saw a red block appear. Also, disk software that requires 48K or 64K never fails... for that matter, I've done a bit of tinkering with BASIC on this machine. If the upper RAM disappeared while in standard GR.0, the display would go haywire (since the display list and screen RAM are located just below $A000). This hasn't ever happened... I'd assume a bad solder joint wouldn't only cause problems with one cart, and in fact the same version of Millipede plays fine when loaded from disk. (Actually it's not *exactly* the same: it needed 3 or 4 STA's that write to the cart address space switched to LDA's, to keep it from self-destructing when loaded into RAM. I doubt these are the source of my problem, though: Pac-Man contains similar self-destruct code, but my Pac-Man cart works fine).

 

Instead of loading the register and then manipulating the appropriate bit(s), the author loaded the accumulator with a specific byte and stored it into $D301. From memory there was one or two bits set to zero that should have been set to on.

 

Ouch! So it did something like enable the Missile Command ROM? I'd never even thought of that as a source of incompatibility for the XEGS, it'd probably drive me insane too...

Link to comment
Share on other sites

the same version of Millipede plays fine when loaded from disk.

 

It does sound more like a hardware (cartridge) fault in your case. Be aware that PROMS are more than just a collection of stored data. There are input address address lines which select the approprate position in the "array" of data. There are also data lines which produce the data to the CPU/ANTIC chips. These data lines are controlled by an "enable chip" pin on the PROM. When the PROM is not being accessed these same data lines go high impedance to allow other devices to use the data lines.

 

It is feasible that the PROM access management circuitry is damaged (not necessarily complete failure) but the data remains intact. I know this does not explain why the cartridge worked on other model Atari's.

 

Without delving into the enormous topic of semiconductors, perhaps the 600XL with your "ISA" memory chips in combination with a PROM/cartridge are affecting the voltage levels on the bus. Or on a simpler level, is the 5 volt supply line being loaded down when a problem cartridge is inserted? There are so many variables.

 

This weirdo problem you are having may be beyond the scope of advice by remote. A visit to your local electronics tech' may be useful!?

 

So it did something like enable the Missile Command ROM?

It in fact crashed the XEGS when executing the code. I did not investigate exactly what was going on in the XEGS. My theory is based on the assumption that the custom MMU is the same as in the 130XE. RAM at $4000 to $5FFF was being switched out and due to absence of expanded memory there was a void left.

Link to comment
Share on other sites

I have a similar problem with my (provisionally) upgraded 600XL (64K) and the "Flight Simulator II" cart that I got at the same time as my XEGS. Right now I have the SRAM mounted on an external breadboard with some jumpers and so forth to bring the signals out. I've removed the old 16k chips and some of the DRAM support logic as well.

 

Everything else works fine, but FS II won't start in my 600XL (fine in the XEGS). Three out of four times, the instrument panel will appear, and the screen will flicker. One out of four times it's just a black screen. I wonder if there's just something funky about the 600xl... a slightly different OS maybe?

Link to comment
Share on other sites

My 600XL - not sure if all of them are like it - had the early XL OS.

 

You can tell the difference by behaviour if changing cartridge without powering down.

The older OS version does a coldstart immediately. The newer version does a "soft lock" of the machine, and coldstarts when you press Reset.

 

No idea though if the older OS had any bugs which caused erratic cart operation.

 

But, I think both utlitised code in the VBlank routine which constantly compared a stored checksum of a small area of the cart's address space.

 

ed - scratch that last bit. The checksum was on warmstart, to check if a cart had been "swapped". The VB only checked TRIG3 to see if the cart was inserted or removed.

Edited by Rybags
Link to comment
Share on other sites

It is feasible that the PROM access management circuitry is damaged (not necessarily complete failure) but the data remains intact. I know this does not explain why the cartridge worked on other model Atari's.

 

Without delving into the enormous topic of semiconductors, perhaps the 600XL with your "ISA" memory chips in combination with a PROM/cartridge are affecting the voltage levels on the bus. Or on a simpler level, is the 5 volt supply line being loaded down when a problem cartridge is inserted? There are so many variables.

 

Yah, I know just enough to know there are lots of things that can go wrong. Nonstandard cart works in standard machines, standard carts work in nonstandard machines... but the weirdness in the cart and the weirdness in the 600XL happen to interact in a way that's noticeable.

 

This weirdo problem you are having may be beyond the scope of advice by remote. A visit to your local electronics tech' may be useful!?

 

Sadly, I am my own local tech. I can just about follow a set of directions... I can troubleshoot simple things, but I don't even know where to start with this.

 

Well, I do know where to start with the cart (replace the ROM with an EPROM, and/or get another Millipede cart, see what it does), but not the 600XL. I can usually fix the ones that don't work at all, but this is much more subtle.

Link to comment
Share on other sites

One thought I had was that the MMU might be different on the 600XL. Apart from the OS, this is the only other "black box" in the decoding of addresses within the 600XL - maybe the RAM is still present when the cart switches in. Perhaps the self-destruct code might cause a conflict that is resolved elecrically - or not. For example, a 1 in RAM and a 1 in ROM is probably fine, as is a 0 in RAM and ROM. But maybe a 1 in RAM beats a 0 in ROM (or vice-versa), for example.

 

Granted this is pure speculation. But now I have some ideas to test:

 

1) Try limiting my external RAM to 32k

2) Try swapping out the MMU with the one from my 800XL (if I can find it)

3) Try swapping out the OS with one from the 800XL

4) Take out the MMU, put it in the breadboard, and break out some DIP switches and the logic probe

Link to comment
Share on other sites

Today, i found the solution for my problem:

In my Atari 600XL there was placed a processor with text: UM6502I from UMC. I have replaced this by a processor of an old 600XL board: CO14806-12. The problem is gone and the grey XE cartridges works also in my 600XL! So i think there's a difference in the processors. The UM6502I is a type used in a XE computer and seems to work in a 600XL but not for 100%.

 

Thank you all for the responses!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...