Jump to content





Reindeer Rescue Bug

Posted by , 15 December 2005 · 1,998 views

2600 Game Development Reindeer Rescue
JUST WHEN I THOUGHT I WAS DONE it turns out I'm not. :|

Anyway, I'll just reproduce what Al wrote to me and ask: anybody have any explanations or a fix?

Hi Bob,When playing the game (NTSC) on a real 2600, I ran into an interesting bug. When starting the game, if you don't do anything, Santa ends up running right through the playfield, and the game shortly resets back to the title screen after that. I burned two games to boards to test, and only discovered this after I played int the third level. It was a fluke that I noticed this at all, but it's a pretty serious problem so I'm going to start erasing the 100 (well, uhhr, 98) EPROMs I burned.This does not happen in Stella, which is probably why nobody saw it. before. Do any of the other testers have Krokodile Carts or Cuttle Carts they can use to test this on a real 2600?

Message Two:

I did some more digging-- it seems that the game only fails on one type of EPROM, the Texas Instruments 27C128. This is strange, as I use these all the time for Thrust+ Platinum. The game does seem to work fine with all the other types of EPROMs I programmed (five other types). Unfortunately, the TI 27C128s are the ones I have the most of, and comprise probably 60 of the EPROMs I programmed. Really strange that this problem only occurs with this one part. I assume it's some kind of weird timing issue. I'm hoping that you might be able to come up with some theories as to why this might be happening and maybe a fix? I'm a bit nervous about soldering more boards until I hear back from you.

If anybody has a Kroc cart or a CC and want to test Reindeer Runner for me? Manuel, I'm assuming that you have already, since you ran this on a real TV to test the PAL colors.This has me baffled; it is beyond my "expertise."The only weird thing that the game does is hit HMOVE at an odd time and, as mentioned in Eric B's weblog, it outputs 270 scanlines (NTSC); I do store the value of CXP0FB in RAM halfway down the screen (right before drawing the string of Christmas lights) and then use that stored value to process collisions between Santa and the playfield; so I suppose that maybe that value is being corrupted or lost somehow...? I dunno.Help?
(Note: I'm going to post this same thing on the [stella] list...)

EDIT: This is the pic referred to in comment #58:Attached Image




  lda CXP0FB
   sta SantaTemp
   sta Score
I bet all the weird stuff is happening during the 'sta SantaTemp' instruction and that everything is back to normal at the 'sta Score' instruction.  So if you switched the code to this:
  lda CXP0FB
   sta Score
   sta SantaTemp

Could be. I'd try the above to see if different values get put in the score.

But I might suggest the following, if the problem is with STA SantaTemp. Try STA.w SantaTemp.

Maybe there is.  I think Al has enough non-TI EPROMs for a little while.  I don't want to volunteer anybody or anything, but if you can do something with the actual cart that would tell us what is going on, you might ask Al to send you a cart. :)

I wouldn't need a whole cart, just a board with TI EPROM containing the original code. And the source and a binary so I know what address to set the trigger point at for the logic analyzer.

I can't guarantee that a logic analyzer will tell us what's happening, but if Al sends me a board and EPROM, I'd be happy to hook it up and report the results, but I'm not sure I'd be able to do it before Xmas.
  • Report

I wouldn't need a whole cart, just a board with TI EPROM containing the original code.  And the source and a binary so I know what address to set the trigger point at for the logic analyzer.

I can't guarantee that a logic analyzer will tell us what's happening, but if Al sends me a board and EPROM, I'd be happy to hook it up and report the results, but I'm not sure I'd be able to do it before Xmas.

I will send you a socketed 16K board with a TI EPROM with the original code, as well as a GI 27C128 (which works, but behaves differently than a 27128 part) as well as a non-CMOS part for comparison. I don't actually have enough non-CMOS parts for all the Reindeer Rescues I need to build, so I am trying to source more at the moment. :) I'll get the board and EPROMs out to you on Monday, as I'd really like to know what's going on here.

..Al
  • Report
I am more and more convinced that there is a little flaw in the cart board design. Maybe whoever designed the board layout might be able to identify the problem.
  • Report

I will send you a socketed 16K board with a TI EPROM with the original code, as well as a GI 27C128 (which works, but behaves differently than a 27128 part) as well as a non-CMOS part for comparison.  I don't actually have enough non-CMOS parts for all the Reindeer Rescues I need to build, so I am trying to source more at the moment.  :)  I'll get the board and EPROMs out to you on Monday, as I'd really like to know what's going on here.


Could you try using 27256 or 27C256's? I don't think I have any TI 27C128's but I might have some TI 27C256's in the office, so if those exhibit the same problem I could experiment with those and a scope (might be better than a logic analyzer).
  • Report

Could you try using 27256 or 27C256's?  I don't think I have any TI 27C128's but I might have some TI 27C256's in the office, so if those exhibit the same problem I could experiment with those and a scope (might be better than a logic analyzer).

I cannot use 27256/27C256 EPROMs without a 32K binary (in other words, I can't just drop-in a 27256 with the 16K PLD code). Having said that, I pretty much use CMOS parts for all 32K games (2600, CV, and 5200) without any problems. However, I'm not sure I've used any TI 27C256 parts. Joe Grand did look at the data sheets for the 27C128 and the ATMEL PAL we're using, and did not see any problems. It's possible there's a problem with the PLD code that only affects these 16K CMOS parts.

..Al
  • Report

Could you try using 27256 or 27C256's?  I don't think I have any TI 27C128's but I might have some TI 27C256's in the office, so if those exhibit the same problem I could experiment with those and a scope (might be better than a logic analyzer).

I cannot use 27256/27C256 EPROMs without a 32K binary (in other words, I can't just drop-in a 27256 with the 16K PLD code). Having said that, I pretty much use CMOS parts for all 32K games (2600, CV, and 5200) without any problems. However, I'm not sure I've used any TI 27C256 parts. Joe Grand did look at the data sheets for the 27C128 and the ATMEL PAL we're using, and did not see any problems. It's possible there's a problem with the PLD code that only affects these 16K CMOS parts.

..Al

If you doubled up the binary it might work. Though you might need to bend out A14 and tie it high or low.

Regardless, I would send some parts to Supercat too, since if the problem is due to marginal logic levels, a logic analyzer might not pick this up but a scope will.
  • Report

I cannot use 27256/27C256 EPROMs without a 32K binary (in other words, I can't just drop-in a 27256 with the 16K PLD code).  Having said that, I pretty much use CMOS parts for all 32K games (2600, CV, and 5200) without any problems.  However, I'm not sure I've used any TI 27C256 parts.  Joe Grand did look at the data sheets for the 27C128 and the ATMEL PAL we're using, and did not see any problems.  It's possible there's a problem with the PLD code that only affects these 16K CMOS parts. 


I use 27C256's in 8K/16K carts with no problem. Indeed, I never use anything else.

From the DOS prompt:
COPY /b 16Kfile.bin + 16Kfile.bin 32Kfile.bin
or
COPY /b 8Kfile.bin + 8Kfile.bin + 8Kfile.bin + 8Kfile.bin 32Kfile.bin

This works just fine with the 8K and 16K PLD's. I don't know whether A14 is high or low, but since the same code is selected regardless it doesn't matter.
  • Report
A minor correction here: It turned out that the binary I sent Al that wrote the contents of CXP0FB to the score wasn't completely helpful, since the hex digits $C through $F were not unique (specifically, they looked like either 0 or 3).

So I rewrote that binary a little (as it turned out, there was room for bitmaps for $A -$F - to my surprise), and the actual result from the TI EPROMs were that CXP0FB returned $3F when not hitting the playfield and $BF when hitting the playfield (before it appeared as if it was reading $33 and $B3.

Sorry if that causes any confusion.
  • Report

I am more and more convinced that there is a little flaw in the cart board design. Maybe whoever designed the board layout might be able to identify the problem.


Could it be that the rom is not being written correctly to start with? Has anyone tried dumping one of the bad roms to check that the contents do actually match the original?

Chris
  • Report

Could it be that the rom is not being written correctly to start with?  Has anyone tried dumping one of the bad roms to check that the contents do actually match the original?

I already asked Al that; he wrote that the ROMs are verified immediately after they are burned.
  • Report

A minor correction here:  It turned out that the binary I sent Al that wrote the contents of CXP0FB to the score wasn't completely helpful, since the hex digits $C through $F were not unique (specifically, they looked like either 0 or 3). 

So I rewrote that binary a little (as it turned out, there was room for bitmaps for $A -$F - to my surprise), and the actual result from the TI EPROMs were that CXP0FB returned $3F when not hitting the playfield and $BF when hitting the playfield (before it appeared as if it was reading $33 and $B3.

Sorry if that causes any confusion.


Are you done testing?

If not, how about the following.

To get a better look at SantaTemp...
   lda CXP0FB
   sta SantaTemp
   lda SantaTemp
   sta Score

To simulate what you've seen of SantaTemp so far...
   bit CXP0FB
  bpl NoCollision
  lda #$BF
  .byte $2C
NoCollision
  lda #$3F
  sta SantaTemp

edited to add the close code command
  • Report
More testing...I dunno. I think Al is pretty busy, and it is a big pain to create and send all these binaries over dialup. I'm kind of waiting until I hear from batari's tests with the logic analyzer whatsit.

But if Al is willing, I'll throw together some more binaries for him to test.
  • Report

I am more and more convinced that there is a little flaw in the cart board design. Maybe whoever designed the board layout might be able to identify the problem.


Could it be that the rom is not being written correctly to start with? Has anyone tried dumping one of the bad roms to check that the contents do actually match the original?

Chris

The device programmer does a read of the EPROM after writing ot it and verify that its contents match that of the buffer. If the contents do not match, it prints a nice, red message that I would see. This happens sometimes with various EPROMs, but not terribly often. I have used these TI 27C128 EPROMs without problems for other games, such as Thrust+, Berzerk Voice Enhanced, and Pick 'n' Pile NTSC.

..Al
  • Report