Mountain King for 2600 played in 7800 differs

[ttony_at]

At a flea market, I had a chance to try out for the first time the Atari 7800.

And I was curious as to what would happen when the Mountain King (CBS

Electronics) made for 2600, is played on a 7800.

 

Well, everything looks the same until you get up to the hidden world.

In the hidden world it seems impossible to create ladders like you do in the 2600

to climb higher. Both the paddles and Sega Genesis controllers don't add ladders

anywhere as they do when the game is played on the 2600. And the Atari Video

Touch Pad, Keyboard Controller and Colecovision don't remove ladders.

Why the difference I wonder.

 

Some extra ladders are created when taking up the Flame Spirit with you. But it's

still not possible to climb as far up as in the 2600.

 

What could be the reason for the difference?

[+-^CrossBow^-]

I could very well be way off base here. But the 7800 does use a slightly different processor than the 2600 does. They are virtually the same but the 7800's proc has the ability to halt.

 

Anyway, I am sure there are other differences as well, and so it could be possible that the hidden world on a 2600 is having its data sent to different registers or they come up differently than they do on the 7800's slightly different processor? I would think that since the 7800 proc has some differences, that it would also have more addresses for storing bits in than the 2600 did. Either that, or for some reason, the bits are simply stored differently on the 7800 than on the 2600.

 

Mind you, that since the normal game plays correctly anyway, the hidden world wasn't ever intended as a deliberate easter egg. It was simply a slip in coding that even allows you to get up there to explore the hidden world.

 

I am sure someone can give a much better explanation of what I am trying to say. Or tell me I am crazy and come up with the right reason. But I have always assumed these differences to be due to the slightly different Proc used on the 7800.

[ttony_at]

...the 7800 does use a slightly different processor than the 2600 does. They are virtually the same but the 7800's proc has the ability to halt.

I'm not sure what 'the ability to halt' means. Do you mean the 7800 clean up the code and doesn't let it get messed up like it does in the 2600?

 

Anyway, I am sure there are other differences as well, and so it could be possible that the hidden world on a 2600 is having its data sent to different registers or they come up differently than they do on the 7800's slightly different processor? I would think that since the 7800 proc has some differences, that it would also have more addresses for storing bits in than the 2600 did. Either that, or for some reason, the bits are simply stored differently on the 7800 than on the 2600. Mind you, that since the normal game plays correctly anyway, the hidden world wasn't ever intended as a deliberate easter egg. It was simply a slip in coding that even allows you to get up there to explore the hidden world.

I am sure someone can give a much better explanation of what I am trying to say. Or tell me I am crazy and come up with the right reason. But I have always assumed these differences to be due to the slightly different Proc used on the 7800.

Not at all crazy, this all sounds interesting.

[+batari]

Yesterday I read an interesting post about the efforts in getting z26 to emulate the hidden world correctly. The issue is that the hidden world is accessed by trying to read TIA registers as pointers to data.

 

The TIA read registers drive only the top two bits, and on the 2600, the other bits are floating, so you end up getting whatever was on the data bus last.

 

On the 7800, it's possible that the reason is that if any of these data pins are connected to anything else that drives it low or high, even weakly, the secret world will be different or even inaccessible.

[EricBall]

...the 7800 does use a slightly different processor than the 2600 does. They are virtually the same but the 7800's proc has the ability to halt.

I'm not sure what 'the ability to halt' means. Do you mean the 7800 clean up the code and doesn't let it get messed up like it does in the 2600? 

No, the HALT is used by the MARIA GPU in 7800 mode to stop the 6502 from executing so the MARIA GPU can fetch the display lists and graphics data. (aka DMA mode). I'm not sure if this is any different from the TIA halting the 6507 on a STA WSYNC (wait for end of line).

 

I suspect that batari is correct. If the hidden world is a result of the game using bits the TIA doesn't have output drivers for, it is certainly possible the 7800 could behave differently due to the data bus not floating in the same way.

 

I do believe this same quirk is used by some other 2600 games.

[supercat]

No, the HALT is used by the MARIA GPU in 7800 mode to stop the 6502 from executing so the MARIA GPU can fetch the display lists and graphics data.  (aka DMA mode).  I'm not sure if this is any different from the TIA halting the 6507 on a STA WSYNC (wait for end of line).

875484[/snapback]

 

The READY line on the 6507 freezes the processor in the middle of read cycles (only). For purposes of doing a STA WSYNC, this doesn't really matter since the next bus operation following the write to WSYNC is almost always going to be an instruction fetch (i.e. read). If one were to do something goofy like point the stack pointer at WSYNC and do a BRK, the three write cycles would happen immediately, regardless of the state of the horizontal sync, but unless one is trying to seriously torture-test an emulator I'd not consider that an issue.

 

For the MARIA chip, however, it's necessary to stop the processor BETWEEN bus cycles, and to delay both read and write cycles. Thus, it's necessary to have a HALT wire on the processor which behaves differently from the READY line.

[+batari]

The READY line on the 6507 freezes the processor in the middle of read cycles (only).  For purposes of doing a STA WSYNC, this doesn't really matter since the next bus operation following the write to WSYNC is almost always going to be an instruction fetch (i.e. read).  If one were to do something goofy like point the stack pointer at WSYNC and do a BRK, the three write cycles would happen immediately, regardless of the state of the horizontal sync, but unless one is trying to seriously torture-test an emulator I'd not consider that an issue.

877861[/snapback]

This is very interesting, and explains why my attempt to get two scanlines in two bytes by doing an INC WSYNC worked in an emulator but not in real hardware. (For those who don't know, read-modify-write instructions like INC do TWO writes to a register, one cycle apart.)

Edited June 21, 2005 by batari

[Bruce Tomlin]

Hmmmm... that might also mean that LDA WSYNC would take one more cycle than STA WSYNC.

[supercat]

Hmmmm... that might also mean that LDA WSYNC would take one more cycle than STA WSYNC.

881065[/snapback]

 

"LDA WSYNC" will take three cycles, regardless of when in the scan line it occurs. The MSB of the accumulator will indicate whether a collision occurred between player 0 and the playfield; bit 6 will indicate whether a collision occurred between player 0 and the ball. Bits 0-5 will most likely be "00 0010".

[Bruce Tomlin]

Oh, duh, a collision register. I forgot. LDA doesn't trip the write-only registers.