Prototype Problems on Different 2600 Models

[Tempest]

Has anyone noticed that certain prototypes act strangely on certain systems? For instance I had tested my Save Mary prototype out on my Atari 7800 and found that Mary was invincible to falling block and rising water. I assumed this was because my prototype was a work in progress. On Saturday I was playing it on a 5200 with a 2600 adapter and discovered that Mary was quite mortal and died in the normal way. Is this because prototypes are more sensitive to the slight differences in the system hardware than regular carts?

 

What system is best to test them on? I have a heavy-sixer 2600 which I've had prototype problems with (Saboteur refuses to play on it), a 5200 with a 2600 adapter (this may be the way to go), and a '84 7800 (which I just noticed some proto problems on). I'd hate to have to test them on all the systems, but that may be the only way to know.

 

Any other proto collectors have these problems? I've noted a few:

 

Ms. Pac-Man - This proto goes nuts on my heavy sixer. Ms. Pac-Man will immediately go left and shoot right through the wall!

 

Saboteur - Once again this proto is incompatible with my heavy sixer. Pushing the fire button eventually resets the game, although you can occasionally get to the next level.

 

Krull - Scott Stilphen noted that his Krull proto had no sound on the spider web level on his 4 switch 2600.

 

Save Mary - Mary is invincible on the 7800. This led to interesting situations where she could be trapped in blocks. A bug that cause bricks to sometimes drop prematurely may also be caused by this incompatibility.

 

Jr. Pac-Man - The prizes did not destroy the power pellets on my 7800. Worked jsut fine on a 2600 Jr. though.

 

 

I've also had commercial game problems with my 7800. Wall Ball goes nuts on my Heavy Sixer and will only let you move down and left. The game also starts automatically.

 

Tempest

 

[ 01-07-2002: Message edited by: Tempest ]

[Lemmi]

heh just think of the 5200 as a computer in a big black case, and since the games were programed on computers maybe this is why it plays correctly on it

 

[ 01-07-2002: Message edited by: Lemmi ]

[Eckhard Stolberg]

Save Mary uses the superchip RAM. I think problems with this chip led to the change in the 7800 design that made later consoles incompatible with Decathlon etc. At least some people who did Chad Schell's fix to get Decathlon working on the 7800 reported occasional problems with other superchip games.

 

Also there seem to be differences among the different VCS consoles when it comes to certain TIA graphics tricks. For example the score in Kool Aide Man. It gets positioned in a rather strange way. On one of my 'big rainbow' Jrs. and on all of my PAL 7800s the score numbers get positioned partly on top of each other, which triggers a constant collision, which makes the game unplayable.

 

Also on my 7800 based cartridge reader there were some bankswitched games that couldn't be read at 7800 speed. I had to write a special reading routine that forces the 7800 to 2600 speed. The games you mentioned also all use that same bankswitching method, so timing differences might be part of the problem with your prototypes.

 

 

Ciao, Eckhard Stolberg

[Tempest]

Hmmm... Interesting. I guess I'll have to test my protos on all my 2600 compatible systems to see if the differences I discover are actually the prototype or the hardware.

 

Tempest

[MattyXB]

Not by a Prototype. But I have get for weeks the game Open Sesam - Sesam öffne dich (Puzzy).

On my Atari 2600 Jr. I walk, die die die and then I am dead. I can do nothing then walk a bit. Sometimes I reach a rope but I die and die again. And there was no enemy that has touch me. The screen flicker a bit and the score has some errors.

 

First I have think that the game is defect, but then I have try it on the Atari 7800, and there was no problems. I am not die by nothing and can play normale. The screen flicker not and the score is normale too. I have it try again on the Atari 2600 Jr. Maybe it was not correct in the console, but again. Die die die and dead.

 

For month I have an other game (don't know in the moment wich one). In the middle screen was my ship invisible. I can't see it there, but right and left I see it. Maybe it work better on the Atari 7800 console too. But I test it later when I find it again.

[Scott Stilphen]

It would be interesting to know how many different versions of the TIA (?) are out there, and how they differ, especially considering how many versions of the console were made (Atari alone had at least 6 different 'dedicated' consoles, plus the 7800 versions and the 5200 adapter). I noted a few compatibility problems with the original (heavy) 6-switch model, and the later 6 and 4-switch ones.

 

If it is indeed a software problem (like the two 5200 OS versions), then simply changing the TIA with one from a different console would prove it. Does Best Electronics still sell these. Can you tell by looking at the chip what version it is?

 

If it's a hardware problem, then perhaps a mod can be designed (much like the one for the later 7800s).

[MattyXB]

I have found now the other game. It was Galactic from Goliath Video System.

But the game has the same errors on the 7800 like on the 2600. In the middle is a black field, that I can't see my ship. The enemys can I see there. And if I shot I see the ship for a time.

 

Maybe an error in the game, my other Galactic (Funvision) work fine.

[Eckhard Stolberg]

The Goliath version of Galactic was hacked to display the company name at the bottom of the screen. Unfortunately the person who did this didn't quite know what he was doing, and therefore broke the game display in the way you described it. The Funvision version used the unmodified ROM image, so it play normally.

 

 

Ciao, Eckhard Stolberg

[MattyXB]

The Funvision games has to a Goliath Logo in the screen, but it looks a bit diffrent.

[Ze_ro]

A number of people (including me) have had problems getting Ghost Manor to work properly on older Heavy Sixer's. When I try to play it on my Heavy Sixer, I can never get to the second level. When I do, the game instantly resets back to the title screen. However, everything seems to work fine on my other Atari's (I haven't tried it on a 7800 though).

 

I also have a copy of Space Invaders (text label) that only works on my Heavy Sixer. It's not a prototype, but it's definitely unusual.

 

--Zero

[MattyXB]

That remember me to an other thing that I tried.

 

I have make more game to wav, to play them on the SuperCharger. But some games reset after a level or after a time. By Crazy Valet have I finish the first level, then it reset, and I have the titlescreen from my SuperCharger.

 

But I have no Heavy Sixer where I can try it, this is one from 2 Atari PAL consoles that I miss. The second is the Atari Jr with short Rainbow.

[cschell]

My guess would be that many of these problems are caused by timing errors, caused by various differences in the chips in each Atari. Not necessarily a design difference, but even just simple variations in the performance of each individual chip.

 

All of this stems from the fact that Atari did not bring the clk2 signal out to the cartridge port. This means that the carts are responding to things even as the address/data bus is in an unknown/unstable configuration. Yet bankswitching, or putting RAM in a 2600 cart, requires that the cartridge respond to certain key addresses or address and data combinations. These combinations might appear on the bus during times of transition, when the clock line would indicate that address/data is invalid. Without the clock though, the carts have to use some form of timing of their own to determine when an address/data set is actually valid.

 

For bankswitching addresses, one typically wants to delay the response to the presence of the address, to make sure that the address is valid and not just a transient. There are various ways to do this, the most simple of which is passing the bankswitch detected response through a low pass filter. (Which I believe is how Chris Wilkson's F8/F6 boards function.)

 

However, for extra RAM this is more complicated. If you delay the signal indicating the presence of a write address, this will work fine for beginning the write, but might cause the write to fail at the end, because by the time the write enable line of the RAM is switched off, the inputs at the address or data lines may have already changed, causing invalid data to be written, or data to be written to the wrong address. It's an annoying balancing act.

 

This means that all bankswitching and extra RAM hardware in carts must make assumptions on how the timing will actually happen and try to set up accordingly. If you change the specs that are assumed, things break. With 7800s, the newer 6502 used is actually much faster than the older 6507 used in the 2600. Not so much in terms of processor clock speed (even in 7800 mode it's still under 2 MHz), but in terms of setup and hold times on the address and data buses.

 

I believe the reason that Superchip games fail on the 7800 is because the data from the 6502 is invalid by the time the Superchip has detected the address is no longer a write address and ended the RAM write command. Installing the "compatibility" circuit forces A12 low at the start of every new cycle using the clk2 line to gate the A12 signal. This ensures that the Superchip will see an address that is not a write address very shortly after the clk2 line indicates address/data is invalid (74LS series parts have fast propogation times relatives to the 6502's hold times.) This causes the Superchip to end it's write closer to the correct time, which is apparently just enough to get the job done. (I say just enough because some 7800's without the compatibility mod will work with some Superchip games, so it's apparently a marginal race condition in terms of the Superchip successfully writing data before it is invalid without the compatibility fix.)

 

Now we move onto the Supercharger, which is broken by the above "compatibility" fix. This happens because the Supercharger does not look for just key address, but also counts every change in the address bus. In order to do this, it generates a timing pulse that is triggered by a change in the address bus. However, this pulse cannot be triggered again while it is active. The pulse is timed such that it stays active during the time the 2600 address bus is unstable, this way the Supercharger only counts true changes in the address bus, ignoring all the intermediate changes that occur as the address actually transistions from one correct value to the next. Ideally, this pulse would be timed to be 1/2 clock cycle long, as the address is valid only in the second half of the clock cycle. Unfortunately, if that timing is used, it does not leave sufficient time (just the second half of the cycle) for the Supercharger chip to actually decode what to do based on the new address and have it's slow RAM and ROM actually have their signals ready in time for the 2600 to read them. (Not to mention enough time to write data into the Supercharger's RAM.) So it cheats, and waits approximately 1/4 of the cycle before responding to the address. This is ok because the 6507's setup is time is smaller than this, so the address is indeed valid by that point. Now with the 7800's compatibility circuit in place though, the address is definitely invalid during the entire first half of the clock cycle because A12 on the cart is forced low. Thus when the Supercharger samples the address it won't see the correct value and can't respond to it's key addresses correctly (it never sees them) and it fails to work.

 

This is even more complicated because the Supercharger must also generate an appropriate delay pulse to write data into it's own RAM, and that pulse must be long enough to write into the RAM, but short enough to stay within the confines of the remainder of the cycle. The Supercharger write pulse delay is actually variable and is determined at run time each time you power up the Supercharger.

 

FE games (decathlon, some copies of robot tank) also rely on a state machine to implement their bankswitching, so they are probably doing something similar timing wise to the that done by the Supercharger. So again, the 7800 compatibility fix prevents them from seeing their key addresses, and the bankswitches never occur, thus the games fail to run. FE games also need an appropriate data delay because they use not only key addresses, but also data. The data lines of the 6507 are not stable until around the last 1/3 of the cycle.

 

On the Cuttle Cart, getting the timing correct to work with all of the bankswitching modes was a real headache. Setting everything up to run on a state machine like the Supercharger (which I had to do to emulate the Supercharger) causes problems with other bankswitching modes. The delayed response of the Supercharger state machine is directly counter to the quick end of cycle detection and response required by the Superchip games. Also, it turns out that leaving data on for too long, as is done by the Supercharger and it's state machine, causes some odd error in collision detection in some games, like air-sea battle. (Load it on your Supercharger sometime, you can't shoot anything.) This required the use of additional standard non-latched combinatorial logic in additional to the state machine to get all the timing to work, so that Superchip games and game like air-sea battle would all run correctly. (Not to mention for Superchip games the speed of the SRAM is very important, modern high speed SRAM responds to changes in the the address and data bus so quickly that it's essentially impossible to use in the 2600 as a Superchip because by the time your logic figures out the address is no longer a write address and ends the write signal, the SRAM has already detected and responded to the same address bus changes that your write address logic is responding too, and you write data to the wrong address.)

 

Ok, if you're still with me, I'll get back to the individual differences between equivalent chips. I found this out because of a timing problem in the first production run of Cuttle Carts that forced me to recall them. It turns out that many 2600's do not have a stable clock signal, or at least not as determined by viewing changes in the address bus. Some of them have a jitter of around 100-150 ns, which is quite high given the ~800ns cycle time of the 2600. This jitter was large enough that it was pushing my data strobe timing out close or slightly beyond the end of the cycle on certain 2600s, which caused the Cuttle Cart to fail to load games correctly (and thus they played incorrectly, or not at all.) One part on the first production run of Cuttle Carts was at the limit of it's tolerance, which pushed the timing slightly beyond the timing I used in the prototypes. In stable 2600's this was fine, but in unstables ones it was just enough to cause the problem. I missed this because the prototypes, being able to deal with this problem, worked fine in all the various 2600's and equivalents they got used in during the months of testing. (I don't know for certain how many, if any, of those 2600's had the unstable clock problem.) However, none of the 2600's I used to test the production run had the unstable timing, so they all worked fine for me. Then I started getting a few reports of people having problems. Someone brought one back to me at CGE (they were released very shortly before CGE) and I tested it in Chris Wilkson's 2600 and it worked fine, so we figured it was the customer's 2600 that was at fault (which, in a way, it was), but I gave him a new Cuttle Cart in the hopes it would work better in his particular 2600. Curious as to why this was happening, I grabbed every 2600 I could find after getting home and started testing the questionable Cuttle Cart in them. I finally found one in which it failed and determined that all the production carts also failed in that 2600 but the prototypes worked fine. With a test case to work with, I was able to find the actual cause (the unstable clock of the 2600, coupled with the now too long timing of the production carts) of the problem. (I then decided that I couldn't live with a silent recall fixing only the Cuttle Carts of people who happened to have a 2600 with unstable timing, so I recalled all of them, adding new features at the same time.) This problem was of course fixed on the second production run.

 

Anyway, I believe this unstable clock could cause other carts to fail as well, especially prototypes which never got the widespread testing of production carts. I also doubt that this unstable clock was present to this extent when the units were manfuactured, but rather believe it is a side effect of the units aging. (I'm not certain of that.) I've now seen the problem on both six and four switch 2600's, but mostly on the older six switch models. It's not consistently present in any particular model though. I've yet to see or hear of the problem in a jr. (This pattern is why I think it is the aging of the components - not consistent in any model, more common in older ones.) I'm sure that other slight timing, power, or various problems might creep into the consoles with time. It doesn't take much to break the somewhat fragile nature of the hacks that are bankswitching and extra RAM in 2600 carts.

 

So my advice to you, Tempest, is to find a 2600 that seems to run everything, and do most of your testing with that, most likely a jr. That will probably give you the best results of the how the prototype software is actually is supposed to work. (Or dump it and load it into a Cuttle Cart.)

 

Chad

--Now you know part of the reason why I'm growing increasingly annoyed with the lack of signals brought to cartridge ports on classic game consoles.

[cschell]

quote:

---

Originally posted by MattyXB:

[QBI have make more game to wav, to play them on the SuperCharger. But some games reset after a level or after a time. By Crazy Valet have I finish the first level, then it reset, and I have the titlescreen from my SuperCharger.

QB]

---

 

Have you modified your Supercharger? Many 2K and 4K games will not work in an unmodified Supercharger because they access it's bankswitching hotspot, causing it to switch modes, swapping in a different block of RAM or the SC ROM.

 

Since you're getting the SC ROM, I would say this is what is happening.

 

Chad

[MattyXB]

No, I think about it, when I get back my second SuperCharger. But I have fear to broke it or do some mistake. I don't know if I do it or not.