Bob's Blog

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.

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.

 

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!

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.

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.

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)?

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.

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.

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

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

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

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

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.

   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.

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

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.

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

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

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.

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.

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.

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

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.

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

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.

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