Jump to content
  • entries
    106
  • comments
    796
  • views
    139,735

Reindeer Rescue Bug

Sign in to follow this  
Guest

2,892 views

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:blog-6060-1134888067_thumb.png

Sign in to follow this  


73 Comments


Recommended Comments



Results of my testing:

 

rr_batari1.bin - fails

rr_batari2.bin - fails

rr_batari3.bin - worked - played into level 2, no problems

rr_batari4.bin - fails

rr_batari5.bin - fails

rr_supercatwildnwacky.bin - fails

Interesting... this means my theory is wrong. As to why #3 would work and not the others, I haven't a clue.

 

But the score display thing reveals that the problem is with the EPROM mucking up the data bus. But this shouldn't happen...should it?

 

Anyway, I'd look into a hardware hack, as this doesn't appear to be software problem.

 

Try clipping a resistor (say 20-50k ohms) from D7 to Vcc (that's pin 19 to pin 28 on the EPROM.) Maybe this will give D7 enough boost to read the collisions properly.

Share this comment


Link to comment

A quick note:

 

Thanks Al, for doing all this testing. :)

 

Second, I have played around more with forcing different values into SantaTemp in order to reproduce the weird behavior Al has seen. Short version: There is no way to reproduce any of the really weird behavior he has seen by putting different values into SantaTemp.

 

I tried this code:

   lda Counter     ;<--variable that is decremented once per frame
  and #$7F
  sta Temp
  lda CXP0FB
  and #$80
  ora Temp
  sta SantaTemp
  sta Score                 ;<---high two digits of score

I could see by looking at the score that the contents of SantaTemp were cycling rapidly through every possible value (0-127 when not hitting PF, 128-255 when hitting PF), but other than that the game played exactly as it should. I'm taking this as absolute confirmation that the code nowhere depends on any of the bits in CXP0FB/SantaTemp except bit 7.

 

I also tried this version:

   lda Counter
  and #$7F
  sta SantaTemp
  sta Score

I could see in the score that SantaTemp was holding all values between 0 and 127 in rapid succession, and (since I forced bit 7 to zero at all times) no collisions with the playfield were ever registered - but otherwise, the game played completely normally.

 

Also tried this version:

   lda Counter
  sta SantaTemp
  sta Score

So here every value was forced into SantaTemp in numerical order.

This behaved predictably - when bit 7 was zero, the game behaved as if Santa was not hitting the playfield; when the top bit was 1, Santa behaved as if he was hitting the playfield. Otherwise everything was completely normal. This version was not playable since when Santa "hits the playfield" for 127 consecutive frames he is rapidly pushed off the screen to the left. And since this happens every 4 seconds or so in this version, games end rather quickly. :D

 

But again, I have not been able to reproduce ANY of the weird behavior just by forcing different values into SantaTemp.

 

I stand by my conclusion that the CMOS EPROMs are somehow corrupting the address and/or opcode of the 'sta SantaTemp' instruction!

Share this comment


Link to comment
I stand by my conclusion that the CMOS EPROMs are somehow corrupting the address and/or opcode of the 'sta SantaTemp' instruction!

I agree with you. The EPROM is supposed to float the data bus when reading/writing TIA regs or RAM. During this time, either /CE or /OE or both is supposed to go high.

 

Apparently it is not fully floating the bus - it must be weakly pulling data lines up or down, possibly depending on what data is located at the address on its address lines. I looked at the TIA schematics, and it only drives values low - high values are caused by pullup resistors.

 

It seems that loading from CXP0FB causes an incorrect value to be placed in the accumulator, but a correct value is placed in processor flags. Maybe a different mechanism is used in the 6507 for each - and the flaky value on D7 goes one way or the other.

 

I have two more suggestions, one hardware, one software. One is the pullup resistor on D7. If I am correct about this, all versions will work if this resistor is in place.

 

Another suggestion is to change the STA $1FF6's at the beginning of the banks to STA $FFF6. If this works, I'll explain my theory.

Share this comment


Link to comment
Another suggestion is to change the STA $1FF6's at the beginning of the banks to STA $FFF6.  If this works, I'll explain my theory.

PMed a binary with this change to Al. We'll see.

 

EDIT: Here's a recap of where we're at right now:

 

The problem: on TI EPROMs, the game exhibits very strange behavior that has not been reproduced in emulation. This behavior includes what appears to be unintended writes to TIA registers and/or RAM locations, unintended changes in the PC and/or SP, and unintended bankswitches. Specifically, the music cuts out for no apparent reason, sprite-to-sprite collisions are inconsistently detected, sprite-to-playfield collisions are only detected once, initially, and then ignored thereafter, and the game resets to the title screen (as if the code executed a BRK) or freezes (as if the code executed a HLT opcode, e.g., $02). Most of this behavior is consistent, though unexplainable.

 

The issue perhaps lies with the sprite-to-playfield collision-reading code, which originally was this:

   lda CXP0FB
  sta SantaTemp

By changing this code (but only in certain ways!) we have gotten the game to run apparently correctly on the TI EPROMs - though no one is really sure why.

Here are the modifications that have worked:

 ;--batari solution that worked
 and #0
 clc
 adc CXP0FB
 STA SantaTemp

;--supercat solution that worked
 lda CXP0FB
 and #$C0
 ora #2
 jmp ImHere
ImHere
 sta SantaTemp

;--Manuel solution that worked
 lda CXP0FB
 bpl NoCollision
 lda #$FF
 .byte $2C
NoCollision
 lda #0
 sta SantaTemp

;--my solution that worked
 bit CXP0FB
 bpl NoCollision
 lda #$FF
 .byte $2C
NoCollision
 lda #0
 sta SantaTemp

All other suggested changes have not worked, including changing the TIA_BASE_READ_ADDRESS to $30.

Share this comment


Link to comment
Apparently it is not fully floating the bus - it must be weakly pulling data lines up or down, possibly depending on what data is located at the address on its address lines.  I looked at the TIA schematics, and it only drives values low - high values are caused by pullup resistors.

 

Always-on pullup resistors? Hmm... I wonder how my 4A50 cart works then, since it relies upon the data bus to be floating when the processor isn't doing anything to it.

 

It seems that loading from CXP0FB causes an incorrect value to be placed in the accumulator, but a correct value is placed in processor flags.  Maybe a different mechanism is used in the 6507 for each - and the flaky value on D7 goes one way or the other.

 

How does the "Supercat" solution work, then (LDA, followed by masking)?

Share this comment


Link to comment
It seems that loading from CXP0FB causes an incorrect value to be placed in the accumulator, but a correct value is placed in processor flags.  Maybe a different mechanism is used in the 6507 for each - and the flaky value on D7 goes one way or the other.

 

How does the "Supercat" solution work, then (LDA, followed by masking)?

I think that batari's diagnosis is a little off.

I think it is possible to get the correct value in the accumulator, but for whatever reason it needs a little help (i.e., supercat's AND/ORA/JMP combination) and, if it doesn't get that help, not only is an incorrect value stored in the accumulator but the following instruction(s) are corrupted in some way.

 

At least, that's my tentative theory, though I'm not sure how batari's working solution fits in. :)

Share this comment


Link to comment
Apparently it is not fully floating the bus - it must be weakly pulling data lines up or down, possibly depending on what data is located at the address on its address lines.  I looked at the TIA schematics, and it only drives values low - high values are caused by pullup resistors.

 

Always-on pullup resistors? Hmm... I wonder how my 4A50 cart works then, since it relies upon the data bus to be floating when the processor isn't doing anything to it.

The pullups seem to only be on bits 6 and 7. They might not be always-on either. Look at the TIA schematics to see what I am referring to (in the collision registers, to the right there are two resistors tied to what looks like a circle with a plus in it (I assume this means +5v.) The rest of the bits are always floating.

 

It seems that loading from CXP0FB causes an incorrect value to be placed in the accumulator, but a correct value is placed in processor flags.  Maybe a different mechanism is used in the 6507 for each - and the flaky value on D7 goes one way or the other.

 

How does the "Supercat" solution work, then (LDA, followed by masking)?

Ok, so this guess is wrong. I was just speculating.

Share this comment


Link to comment
Another suggestion is to change the STA $1FF6's at the beginning of the banks to STA $FFF6.  If this works, I'll explain my theory.

Al tested this; he said it did not work:

I see "33" when Santa is gleefully running along, and then a "stuck" digit (between 2 and 4 or something like that) and 3 when Santa is wedged in the poor playfield.

So there you go. Incidentally, I think by "stuck" digit between 2 and 4 he means this:

 

...

 

 

Oh yeah, can't attach things to comments. Well, I'll attach it to the original blog post at the top, you can see it there. In any case, my point was that this corresponds to: $B

 

So the value it is reporting is $33 when no collision between player 0 and the playfield and a $B3 when there is a collision...which makes sense. But notice the code that binary is using:

   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

That SantaTemp would have the correct value stored, so the playfield-to-sprite collisions would be handled eventually, but we would still see weird behavior. Or...:)

 

BTW: I was able to check and SantaTemp is $DF

Share this comment


Link to comment
Another suggestion is to change the STA $1FF6's at the beginning of the banks to STA $FFF6.  If this works, I'll explain my theory.

Al tested this; he said it did not work:

 

...

 

BTW: I was able to check and SantaTemp is $DF

$DF should properly register a collision but it doesn't? Why? :)

 

But as for additional suggestions, I have none except "use different EPROMS" or "send me a cart and I will hook it up to a logic analyzer" but there's not enough time for this...

Share this comment


Link to comment
BTW: I was able to check and SantaTemp is $DF

$DF should properly register a collision but it doesn't? Why? :D

Um, maybe I wasn't clear. I meant that the address of SantaTemp is $DF. So sta SantaTemp is equivalent to sta $DF.

But as for additional suggestions, I have none except "use different EPROMS" or "send me a cart and I will hook it up to a logic analyzer" but there's not enough time for this...

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. :)

Share this comment


Link to comment
   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.

Share this comment


Link to comment
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

Share this comment


Link to comment

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.

Share this comment


Link to comment
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).

Share this comment


Link to comment
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

Share this comment


Link to comment
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.

Share this comment


Link to comment
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.

Share this comment


Link to comment

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.

Share this comment


Link to comment
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

Share this comment


Link to comment
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.

Share this comment


Link to comment
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

Share this comment


Link to comment

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.

Share this comment


Link to comment
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

Share this comment


Link to comment

Guest
Add a comment...

×   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...