Reserve List for Jr. Pac-Man

[+Propane13]

It's not an issue with the maze drawing routine, but it is with the dot placement routine. The dots are placed in groups of 8 (1 byte for 8 dots) and an ASL is done to get the bit out to tell if a dot is to be placed or not. There is one variable that holds this value as it's being shifted. That's the variable that for some reason is being thwarted, only on the newer 7800s. For instance, the right side where the outer wall is has the last two positions of the dots and 6 'spaces' (value $C0). In the places where the dots are placed through the wall, this $CO value either isn't getting shifted correctly, or the memory position holding that value is changed to something else (again, only in the later model 7800s). I've tried moving it to a different location (maybe something was being overwritten), but that didn't help. One thing I am going to try when I get home, is changing the 'ASL TEMPDOT' to 'LDA TEMPDOT, ASL, STA TEMPDOT' just to see if that makes a difference.

 

How did that test work?

 

I have some other ideas (as this is a non-standard situation), if it does come down to timing:

 

1) Add a NOP to the ASL loop:

 

TempdotLoop:

ASL TEMPDOT

NOP // added to "Waste time" so that the previous command can finish its cycles.

Branch TempDotLoop

 

Perhaps the issue is that the ASL does not complete before the next occurs.

If this is the case, adding a NOP will let the pipeline clear before the next one.

 

2) Move your ASL TEMPDOT code somewhere else in the program.

Maybe there's a weird situation where DMA is being enabled right as this step is being hit.

If that's the case, maybe there's a timing issue between the processor being halted and when it returns, such that it's garbled.

Theoretically, this shouldn't happen, but that's a possibility I would not rule out.

 

Not sure how useful they are, but they seem like worthwhile ideas given the situation.

 

-John

[GroovyBee]

Instead of speculation, how about somebody with a logic analyser looks at the offending system/cart combination? I've got one, but I'm on the other side of the pond, so that doesn't help .

[PacManPlus]

I feel like such an idiot. I completely forgot about NOP

 

Thanks for the suggestions, John. I'll give that a shot.

 

 

 

 

EDIT - Missed Groovy Bee's post. Thanks! Are those things expensive and / or difficult to read?

Edited May 12, 2009 by PacManPlus

[GroovyBee]

EDIT - Missed Groovy Bee's post. Thanks! Are those things expensive and / or difficult to read?

Ebay is your friend . Something like a HP16500A, HP16500B or HP16500C would be good for the job. They are quite old, but very usable (very heavy, so costly on postage ). You'll also need a HP16541 or HP16550/554/555/556/557 synchronous state & timing analysis module to look at the cart's address, data and control lines.

 

There aren't many HP16500x models on EBay at the moment. If you want a modern USB one, have a look at the ANT. I've never used one of those, so can't recommend it from personal experience.

[legeek]

Hi Bob,

 

Please add me to the waiting list

 

Cheers,

Ben

[atarian63]

Finally had time to play mine, so far after level 1 it's fine! Great piece of work! A really nice version.

 

Thanks Bob!

[+remowilliams]

Got my cart today. It is yet another entry in a line of fantastic achievements - Bob you simply rock!

[PacManPlus]

Thanks for the compliments, guys It actually makes me want to do more

 

Update:

I no longer think it's a timing issue. I tried a few NOPs, but it still happens (sometimes) in the *same spot*.

 

Here is what I am able to conclude:

 

1) It's always the same three rows affected (at least on the first maze): (Top row of dots, row of dots the player starts in, and bottom row of dots). It's always the same columns that get affected as well. The only thing in common these lines have, is that they contain $FF (all 8 dots enabled) somewhere in the line.

2) The bad value always gets turned to $FF (again, all 8 dots on).

3) Like I said earlier, I have a work around for the outside of the maze, but when it happens toward the center of the maze, it's still annoying.

4) It seems to only happen in two areas: The center of the maze and the right-most side of the maze.

 

I'm getting closer...

 

I think a complete work around would be to check for a maze section underneath before I place a dot down.

Thanks!

Bob

Edited May 13, 2009 by PacManPlus

[+Propane13]

Hi Bob,

 

I've still got a funny feeling about DMA.

And, I have a small test I'd like to recommend that you try.

 

So, is this drawing routine only happening after reset is hit (i.e. to copy of the dot buffer into RAM initially)?

If so, do you wait for VBlank before drawing? Additionally, on setup of the grid, are you burning lots of cycles (likely)?

 

I have a strange suspicion that some 7800's may not "gracefully" handle the situation where the DMA starts drawing and certain computations are still going in the VBlank.

What would happen if you had too many cycles for the initial startup, and said interrupt happened, and when it returned, the carry bit itself was incorrect on return from the DMA code? That *shouldn't* happen, according to the design specs, but it's a possibility worth trying to rule out, since you're seeing odd behavior.

 

Here's some code I stole from the 7800 Diagnostic cart:

 

	;************************
;* Subroutine:		*
;*     WaitVBlank:      *
;************************
LE710: JSR    LE71E   ;6
      JSR    LE723   ;6
      RTS            ;6


;************************
;* Subroutine:		*
;*    WaitNotVBlank:    *
;************************
LE717: JSR    LE723   ;6
      JSR    LE71E   ;6
      RTS            ;6


;************************
;* Subroutine:		*
;*     WaitVBOff:       *
;************************
LE71E: BIT    MSTAT   ;3
      BMI    LE71E   ;2
      RTS            ;6


;************************
;* Subroutine:		*
;*     WaitVBOn:        *
;************************
LE723: BIT    MSTAT   ;3
      BPL    LE723   ;2 
      RTS            ;6 

 

 

I'd recommend as an experiment calling JSR LE710 (WaitVBlank) before your dot-drawing routine.

The consequence is that it may slow down your game, BUT, for debugging, this might tell you if DMA is the issue or not.

 

What do you think? Worth a try?

 

-John

[PacManPlus]

Hey John:

 

Thanks for the info!

I should have stated that I am waiting for VBlank before starting the Dot section. I also tried waiting for VBlank before each byte to be processed (took almost two seconds to draw the screen). Nothing changed.

 

The drawing routine happens at the beginning of every round. The issue happens as soon as you boot the game, and start it right away by pressing the button. It seems that any time you start it after that, it's ok - although jwierer had it happen once on a later board.

 

Thanks,

Bob

[jwierer]

Hey John:

 

Thanks for the info!

I should have stated that I am waiting for VBlank before starting the Dot section. I also tried waiting for VBlank before each byte to be processed (took almost two seconds to draw the screen). Nothing changed.

 

The drawing routine happens at the beginning of every round. The issue happens as soon as you boot the game, and start it right away by pressing the button. It seems that any time you start it after that, it's ok - although jwierer had it happen once on a later board.

 

Thanks,

Bob

I'll see if I can create a cart that does it again so I can repeat that error this weekend.

 

-Jeff

[+Propane13]

Ok, let's try something else.

 

I'm assuming you tried this, and it didn't work (since you said you were thinking to try it):

'ASL TEMPDOT' to 'LDA TEMPDOT, ASL, STA TEMPDOT'

 

Here's another theory then. Maybe the ASL command itself for some reason doesn't get processed well on some new 7800's.

If that's the case, I say let's try a few things:

 

; Test 1- this dumb little test could figure out if some junk is getting back into your asl (if it's acting like a ROL). So, clearing the carry.

; Of course, I don't think this will help much.

CLC

ASL TEMPDOT

 

; Test 2-- forget ASL, and let's try a... different way to ASL, using ROL

CLC

ROL TEMPDOT

 

 

; Test 3-- An ASL essentially "doubles" the value, right? So, let's do an addition of itself instead

; store the leftmost bit in a variable called BITSET (instead of carry), then mask it out, and add to itself.

; If I remember my Comp-Sci theory correctly, this code box below is essentially an ASL, but expanded out.

   LDA #0
   STA BITSET ; bit we're shifting not set initially
   LDA TEMPDOT
   BPL LeftMostBitClear
   LDA #1
   STA BITSET
   LDA TEMPDOT
   ORA #%01111111 ; clear the leftmost bit before addition, so no overflow
   STA TEMPDOT
LeftMostBitClear
   LDA TEMPDOT
   CLC
   ADC TEMPDOT
   STA TEMPDOT
UpdateCarry
   CLC
   LDA BITSET
   BEQ Done
   SEC
Done

 

These may be desperate and weird solutions, but hey, we're looking at a weird situation!

 

-John

Edited May 13, 2009 by Propane13

[VectorGamer]

Sorry folks - maybe this was already posted but is there a timetable for release and if so how many carts will be produced?

[Dauber]

A lot of the carts already went out. (I got mine last week. )

[Zoyx]

Summary of thread...

 

a) List of people started who want Jr. Pac-man cart.

b) List is filled.

c) First batch is made/shipped.

d) Flaw found, only happens on certain consoles.

e) Trying to discover/fix flaw before next batch is shipped.

 

That's where we are.

Edited May 13, 2009 by Zoyx

[PacManPlus]

Thanks for taking that one, Zoyx

 

 

Hey John et al:

 

Ok, I know now it's not the routine I thought it was. I put a display in the program and when it goes to *read* the value to convert into dots it's getting $FF instead of $C0 (for example). This means the error is happening not when it's writing the dots to the screen, but when it's storing the dots in memory (it then reads them from memory to convert to screen dots)

 

I'm now in a different subroutine. I tried moving the DOTARRAY to a different RAM location, double-initializing that area of memory, forcing a WAITVBLANK prior, and I got no change. I plan on trying using different variables to get the memory location.

 

The thing that sucks is that every time I try something, I ruin an OTP Prom. I've burned through about 30 of them already, and tossed them all. It seems to happen more often with these than with normal eproms. So I have to use them.

 

Bob

Edited May 14, 2009 by PacManPlus

[+Propane13]

Maybe it has to do with the RAM needing to warm up before being used?

i.e. the ram doesn't have enough power before the game starts?

 

You mentioned these symptoms:

- it only happens the first time around

- values are FF, which is typcally what happens when RAM is uninitialized

 

Seems valid in my mind. Maybe you need to have it burn 60 frames at power up (i.e. 1 second) in order to warm up the ram before trying anything.

 

That would explain also why

- it only works with some 7800's (possibly slightly lower power on later models, so may be slower to warm up ram),

- it happens only with some ram (some slower to warm up than others)

 

What do you think?

 

-John

[AdeptRapier]

Maybe it has to do with the RAM needing to warm up before being used?

i.e. the ram doesn't have enough power before the game starts?

 

You mentioned these symptoms:

- it only happens the first time around

- values are FF, which is typcally what happens when RAM is uninitialized

 

Seems valid in my mind. Maybe you need to have it burn 60 frames at power up (i.e. 1 second) in order to warm up the ram before trying anything.

 

That would explain also why

- it only works with some 7800's (possibly slightly lower power on later models, so may be slower to warm up ram),

- it happens only with some ram (some slower to warm up than others)

 

What do you think?

 

-John

 

Do the affected 7800's have the updated ROM that don't show the Atari Logo? If so, maybe the lack of this extra "start up" time is the problem?

 

AdeptRapier

 

[VectorGamer]

Summary of thread...

 

a) List of people started who want Jr. Pac-man cart.

b) List is filled.

c) First batch is made/shipped.

d) Flaw found, only happens on certain consoles.

e) Trying to discover/fix flaw before next batch is shipped.

 

That's where we are.

 

Q: Is there a reason why after a "first batch is made/shipped" that subsequent carts cannot be turned over to AtariAge for sale?

[Underball]

Summary of thread...

 

a) List of people started who want Jr. Pac-man cart.

b) List is filled.

c) First batch is made/shipped.

d) Flaw found, only happens on certain consoles.

e) Trying to discover/fix flaw before next batch is shipped.

 

That's where we are.

 

Q: Is there a reason why after a "first batch is made/shipped" that subsequent carts cannot be turned over to AtariAge for sale?

Second batch and pretty much any that would be given up is already taken and accounted for by previous requests.

[the.golden.ax]

So, the solution is... talk to your 7800... make sure it is in the mood before you begin. Start by caressing it gently, but take your time. Don't go too fast. Turn it on first, then only once it's hot, insert your joystick slowly. Toggle the little difficulty switch near where you just inserted your joystick to assure maximum enjoyment. Then you can get down to business. Continue to play until you are both finished. Remember, the more effort you put into this relationship, the more you will get out of it.

 

AX

Edited May 14, 2009 by the.golden.ax

[Underball]

So, the solution is... talk to your 7800... make sure it is in the mood before you begin. Start by caressing it gently, but take your time. Don't go too fast. Turn it on first, then only once it's hot, insert your joystick slowly. Toggle the little difficulty switch near where you just inserted your joystick to assure maximum enjoyment. Then you can get down to business. Continue to play until you are both finished. Remember, the more effort you put into this relationship, the more you will get out of it.

 

AX

This is why I like the 7800 ovr the NES.

 

With the NES, you constantly had to give it a douche/internal cleaning just to make it work properly. And then with all the flickering and tons of shovelware. It was like trying to have sex with a fat girl with bad hygiene.

[GroovyBee]

I've never heard of RAM needing to "warm up" before use .

 

I strongly suspect its a PHI2 and/or R/W# marginal timing problem. Do you have a schematic of the modified cart and part numbers for the RAM and OTP?

[Tempest]

I've never heard of RAM needing to "warm up" before use .

Sort of reminds me of Bubble Memory. Remember that little technology fiasco?

 

Tempest

[GroovyBee]

One of my engineer friends remembers keeping his lunch warm in the RAM pack for a machine they had when he was starting out in his career. The joys of iron core memory!