GATES

[Mr SQL]

GATES is a colorful game with a tribal drums soundtrack

 

The objective is to pilot your craft through as many gates as you can (I made it through 14).

 

Waves: There are 7 gates per wave and each wave gets harder, you'll know because the gates initially dynamically appear in the moving barriers that ebb and flow with changing colors as you approach but change differently on subsequent waves requiring more strategy.

 

Strategy:

 

After the first wave it's better to be on the right side of the screen, because the barriers can change unpredictably in the second wave - larger gates may materialize or smaller gates harder to traverse.

 

Game physics include gravity and inertia.

Randomizer - Only the first game is the same, gameplay seeds the randomizer.

 

Best play options:

 

The algorithmic tribal drums soundtrack requires a real TIA to experience but the gameplay is just as fun on the Atari Flashback.

 

Here are versions for the SuperCharger and the AFP:

 

GATES_SuperChargerR2.bin GatesAFPr2.bin

 

Both versions run on the real hardware but Stella cannot currently play the Flashback version, use Javatari to play that one.

Note: You can also make Stella compatible with the Atari Flashback Portable Console by setting the option to clear the RAM in the debug menu.

 

EDIT: New version! GATES_R2A replaces the tribal drums sound track with an orchestral arrangement with different instruments that can be heard in emulation as well as a real TIA. There is also an option to change the background color with the button:

 

GATES_R2A_SuperCharger.binGATES_R2A_AFP.bin

 

SuperCharger wav files:

GATES_R2A_SuperCharger.wavGATES_SuperChargerR2.wav

 

 

Edited April 11, 2018 by Mr SQL

[Keatah]

So this needs real hardware? Stella 5.0.2 isn't accurate enough?

[alex_79]

So this needs real hardware? Stella 5.0.2 isn't accurate enough?

 

No, the game simply rely on a particular initial state of RAM, without any research being done to ensure that this behaviour is what happens consistently on real hardware.

In particular, the game doesn't initialize CBS RAM, and it fails in Stella (*) because RAM is random there at startup. The harmony implementation of CBS scheme and some emulators (including the one in Atgames Flashback portable) have the ram zeroed at startup, but of course none of them qualifies as "real hardware".

 

This fact has been pointed out before, but the author "decided" that CBS used dynamic RAM and that it should be zeroed at startup without providing any evidence to support this odd theory.

 

EDIT:

(*) actually, it depends on what you set on the Developer settings dialog in Stella, and in particular the option "Randomize zero page and extended ram"

Edited March 7, 2018 by alex_79

[DirtyHairy]

As Alex_79 said The AFP version is CBS and does not initialize RAM properly; that's why it doesn't run on Stella and 6502.ts. An interesting reference on the power-on state of SRAM (with a scientific paper linked) can be found here --- in general, SRAM does not power up in a defined state. The "tribal drum" soundtrack is accurately reproduced in Stellerator (and in my precise-audio development branch of Stella, if anyone likes to build from source ).

Edited March 7, 2018 by DirtyHairy

[Mr SQL]

So this needs real hardware? Stella 5.0.2 isn't accurate enough?

 

 

 

No, the game simply rely on a particular initial state of RAM, without any research being done to ensure that this behaviour is what happens consistently on real hardware.

In particular, the game doesn't initialize CBS RAM, and it fails in Stella because RAM is random there at startup. The harmony implementation of CBS scheme and some emulators (including the one in Atgames Flashback portable) have the ram zeroed at startup, but of course none of them qualifies as "real hardware".

 

This fact has been pointed out before, but the author "decided" that CBS used dynamic RAM and that it should be zeroed at startup without providing any evidence to support this odd theory.

 

 

Testing was done on an Atari Jr, Vader and Atari Flashback console as well as in Stella and Javatari making Stella the odd man out.

 

I provided evidence to illustrate Stella does not clear registers like the real hardware does right here using the SuperCharger; still haven't heard any argument to the contrary:

 

http://atariage.com/forums/topic/275869-problem-when-testing-on-real-hardware/?p=3973907

 

You have a point that the Harmony firmware could be incorrect along with the flashback portable and Javatari, but you haven't provided any evidence that CBS RAM acted like static RAM; you weren't there in that timeframe working with related technology like I was so I think your argument is less compelling - from my experience we generally kept the power off for a couple of seconds and RAM chips like that would clear - the onus is on you to prove it acted like you claim without power.

 

imo you should clear the RAM to fix this bug, and clear the registers to fix the supercharger bug.

[Mr SQL]

As Alex_79 said The AFP version is CBS and does not initialize RAM properly; that's why it doesn't run on Stella and 6502.ts. An interesting reference on the power-on state of SRAM (with a scientific paper linked) can be found here --- in general, SRAM does not power up in a defined state. The "tribal drum" soundtrack is accurately reproduced in Stellerator (and in my precise-audio development branch of Stella, if anyone likes to build from source ).

 

This is good research, but this is not the RAM from 1983 where waiting a couple of seconds would ensure it was clear - I'd like to see more specifics on 1983 CBS RAM, SARA and RIOT RAM where I would expect similar behavior; I think the RIOT RAM cleared unless you fried the system.

 

Very cool that Stellerator can do the soundtrack accurately, I will definitely check it out.

[Keatah]

Ok. For now I'll put it in the "does not work on Stella" folder.

[DirtyHairy]

Testing was done on an Atari Jr, Vader and Atari Flashback console as well as in Stella and Javatari making Stella the odd man out.

 

I provided evidence to illustrate Stella does not clear registers like the real hardware does right here using the SuperCharger; still haven't heard any argument to the contrary:

 

http://atariage.com/forums/topic/275869-problem-when-testing-on-real-hardware/?p=3973907

 

You have a point that the Harmony firmware could be incorrect along with the flashback portable and Javatari, but you haven't provided any evidence that CBS RAM acted like static RAM; you weren't there in that timeframe working with related technology like I was so I think your argument is less compelling - from my experience we generally kept the power off for a couple of seconds and RAM chips like that would clear - the onus is on you to prove it acted like you claim without power.

 

imo you should clear the RAM to fix this bug, and clear the registers to fix the supercharger bug.

 

• Unless you somehow managed to cram your code into a historic CBS cartridge, you used the harmony, which is a cartridge emulator and does not contain any SRAM at all. This does not offer any conclusions as to the initial state of historic CBS cartridges.
• The thread you mention has *nothing* to do with the Supercharger, but with the implementation of RESMPx in Stella and Stellerator, which is known to be flawed (as it is in all emulators I tested). I know what the issue is (I have even explained it at the circuit-level), and I will fix it when I find time.
• I don't care what you think SRAM within the CBS cartridge might possibly have acted like; the only real reference I have is existing SRAM. If you really want find out whether you're correct: write a test ROM that proceeds to run from RIOT RAM, then hot-swap the cartridge with a historic CBS cartridge and test. Until then, I won't change a single line in any emulator I am contributing to --- you can either use another emulator, write your own or just do proper initialization of the CBS ram on startup.

That's all I have to say here

Edited March 7, 2018 by DirtyHairy

[DirtyHairy]

 

This is good research, but this is not the RAM from 1983 where waiting a couple of seconds would ensure it was clear - I'd like to see more specifics on 1983 CBS RAM, SARA and RIOT RAM where I would expect similar behavior; I think the RIOT RAM cleared unless you fried the system.

 

Very cool that Stellerator can do the soundtrack accurately, I will definitely check it out.

 

 

Actually, there is a test ROM by Omegamatrix floating on the forum that dumps the initial state of RAM as hex: https://atariage.com/forums/topic/230219-startup-values-of-the-2600/. According to this thread, some consoles start up zeroed, others don't.

[Mr SQL]

 

• Unless you somehow managed to cram your code into a historic CBS cartridge, you used the harmony, which is a cartridge emulator and does not contain any SRAM at all. This does not offer any conclusions as to the initial state of historic CBS cartridges.
• The thread you mention has *nothing* to do with the Supercharger...

 

Unless you can get someone to burn a CBS RAM cart any cart created with that scheme will use Melody, which is the same as Harmony's scheme so that argument applies equally to both of us but I agree it would be the ideal way to verify how the real hardware acted.

 

The link to the binary on the thread I shared used real SuperCharger hardware to show the registers get cleared.

 

 

I don't care what you think SRAM within the CBS cartridge might possibly have acted like... the only real reference I have is existing SRAM.

 

Well that's the point, you have to care about your reference being accurate to the timeframe; SRAM today is different than RAM from 1983.

 

 

 

 

Actually, there is a test ROM by Omegamatrix floating on the forum that dumps the initial state of RAM as hex: https://atariage.com/forums/topic/230219-startup-values-of-the-2600/. According to this thread, some consoles start up zeroed, others don't.

 

Wow this is fascinating, I'm reading the thread now; it would be really interesting if the RAM initially worked like I remembered and during the long lifetime of the console it's characteristics more closely began to match modern RAM...

[alex_79]

Testing was done on an Atari Jr, Vader and Atari Flashback console as well as in Stella and Javatari making Stella the odd man out.

Since you didn't use a real CBS chip, that's the same as saying "No test was ever done"

 

I provided evidence to illustrate Stella does not clear registers like the real hardware does right here using the SuperCharger; still haven't heard any argument to the contrary:

You haven't.

 

As explained by Eckhard Stolberg in the thread you're referring to, the supercharger doesn't have access to the accumulator (or any other cpu register) and can't clear or set it. Your interpretation of the example code (lda #55; lda hotspot) is just wrong as the result is that accumulator is loaded with wathever the cpu reads from the data bus. The question in that case is what happens to the bus when you read from the hotspot and if the results can be replicated consistently on all hardware, and there's nothing conclusive and more research is needed as you can read from Eckhard's post:

 

[...]

... the SC will do a write to the RAM at address $fff8 too, even when writing is disabled. Therefore the the LDA will return the newly written value most of the time. Sometimes some bits are not set though. I haven't figured out why yet...

[...]

haven't provided any evidence that CBS RAM acted like static RAM

I don't have to. You're the one who claimed several times that is using dynamic ram, you have to provide evidence.

 

... you weren't there in that timeframe working with related technology like I was so I think your argument is less compelling ...

So, are you saying you have a superior authority that exempt you from providing evidence for your claims?

Sorry, I'm not used to believe things by faith. If you have more exeprience on the subject, that should make easier for you to demontrate your assumptions. If you can't demonstrate it, then your argument is worthless. If you think people have to believe unconditionally every thing you say, just because you're saying it, then you're a fool.

 

... from my experience we generally kept the power off for a couple of seconds and RAM chips like that would clear

"Chips like that"? What do you mean? The chips that "in your experience", would "generally" clear when powered off "a couple of seconds" were like the CBS RAMPLUS? In the sense that they both were little plastic square packages with a bunch of metallic pins?

Is this your demonstration?

 

Unless you can get someone to burn a CBS RAM cart any cart created with that scheme will use Melody, which is the same as Harmony's scheme...

You can build a cart using an original CBS chip for the ram portion only and eprom for the rom, by implementing address decoding and bankswitching functions with extra logic (with a PLD, for example).

Have you tried that?

 

... so that argument applies equally to both of us

Not at all. You're the one claiming that the CBS RAM acts consistently differently from the known behaviour of SRAM chips. The burden of proof is on you.

Moreover, even if you test your theory on a real CBS chip, that wouldn't be enough to prove that the behaviour is the same on every cart ever produced (e.g. the RIOT has static ram, but some consoles seem to start up with riot ram cleared, while other don't).

Unless you prove the contrary, the initial status of SRAM isn't something you can be certain of, so relying on one particular status in a game is a bug. (I believe that not initialize variables is bad programming practice anyway)

As discussed in the page linked by DirtyHairy, designing SRAM chips that consistently power up in a known state is possible, but it would have added cost with no advantage, considering that all the 4 known CBS RAMPLUS games (Omega Race, Tunnel Runner, Mountain King and Wings) have code to initialize the cartridge RAM when started.

 

 

 

but I agree it would be the ideal way to verify how the real hardware acted.

Not ideal. Mandatory.

 

SRAM today is different than RAM from 1983.

Evidence, please?

And by the way, you kept spamming threads in the past affirming that CBS was using dynamic RAM and that Stella was incorrectly emulating it. Now you're saying that it uses Static RAM, but that it was "different" back then. Which one is it?

Edited March 8, 2018 by alex_79

[Mr SQL]

Since you didn't use a real CBS chip, that's the same as saying "No test was ever done"

 

You haven't.

 

As explained by Eckhard Stolberg in the thread you're referring to, the supercharger doesn't have access to the accumulator (or any other cpu register) and can't clear or set it. Your interpretation of the example code (lda #55; lda hotspot) is just wrong as the result is that accumulator is loaded with wathever the cpu reads from the data bus. The question in that case is what happens to the bus when you read from the hotspot and if the results can be replicated consistently on all hardware, and there's nothing conclusive and more research is needed as you can read from Eckhard's post:

 

I don't have to. You're the one who claimed several times that is using dynamic ram, you have to provide evidence.

 

So, are you saying you have a superior authority that exempt you from providing evidence for your claims?

Sorry, I'm not used to believe things by faith. If you have more exeprience on the subject, that should make easier for you to demontrate your assumptions. If you can't demonstrate it, then your argument is worthless. If you think people have to believe unconditionally every thing you say, just because you're saying it, then you're a fool.

 

"Chips like that"? What do you mean? The chips that "in your experience", would "generally" clear when powered off "a couple of seconds" were like the CBS RAMPLUS? In the sense that they both were little plastic square packages with a bunch of metallic pins?

Is this your demonstration?

 

You can build a cart using an original CBS chip for the ram portion only and eprom for the rom, by implementing address decoding and bankswitching functions with extra logic (with a PLD, for example).

Have you tried that?

 

Not at all. You're the one claiming that the CBS RAM acts consistently differently from the known behaviour of SRAM chips. The burden of proof is on you.

Moreover, even if you test your theory on a real CBS chip, that wouldn't be enough to prove that the behaviour is the same on every cart ever produced (e.g. the RIOT has static ram, but some consoles seem to start up with riot ram cleared, while other don't).

Unless you prove the contrary, the initial status of SRAM isn't something you can be certain of, so relying on one particular status in a game is a bug. (I believe that not initialize variables is bad programming practice anyway)

As discussed in the page linked by DirtyHairy, designing SRAM chips that consistently power up in a known state is possible, but it would have added cost with no advantage, considering that all the 4 known CBS RAMPLUS games (Omega Race, Tunnel Runner, Mountain King and Wings) have code to initialize the cartridge RAM when started.

 

 

 

Not ideal. Mandatory.

 

Evidence, please?

And by the way, you kept spamming threads in the past affirming that CBS was using dynamic RAM and that Stella was incorrectly emulating it. Now you're saying that it uses Static RAM, but that it was "different" back then. Which one is it?

Alex,

you're quoting Eckhard but you only have half of the conversation; we continued it in a private chatroom with Fred:

 

Eckhard explained since it was unkown what value was in the hotspot the register contents were left intact (uncleared) and we discussed weather it might be a good idea to clear it. You can download that binary and actually see different performance on the real hardware (supercharger) vs Stella so you don't have an argument here; it's the real hardware.

 

You're right all we have for CBS RAM is emulation, but melody/harmony's interpretation, the official Atari emulators intepretation and Javatari all agree, leaving Stella alone in implementing a different idea of SARA and CBS RAM.

 

I think since Stella is in the minority the onus should be on the Stella team to dump SARA ram at least (if not CBS RAM, no one can make those carts) and see if it clears without power (what the rest of the development teams predict) or acts like static RAM.

[Keatah]

..and if there are different versions or behaviors of the external RAM due to process changes over the years, then that needs to be considered in emulation as well.

[alex_79]

Eckhard explained since it was unkown what value was in the hotspot the register contents were left intact (uncleared)

While I believe that you had a conversation on PM on this subject, I'm almost certain you didn't understand anything about it as it's evident from this sentence:

there's no way (in this universe at least) that the 6502 cpu would not perform a load operation into the accumulator (thus leaving it "intact" as you say) because it doesn't know the content of the address is reading from (?!?). It doesn't make sense on so many levels that I don't even know how to start to correct you.

 

You can download that binary and actually see different performance on the real hardware

Of course it's different, since the rom is relying on an undocumented behaviour. The key point here (that you keep not understanding) is that you have to document it first, and verify that it is determined and consistent across all hardware.

 

You're right all we have for CBS RAM is emulation, but melody/harmony's interpretation, the official Atari emulators intepretation and Javatari all agree, leaving Stella alone in implementing a different idea of SARA and CBS RAM.

Irrelevant. And actually since the initial state of SRAM is undetermined (unless someone prove the contrary) the other implementations are correct too, that is, it doesn't matter what's in ram at power on. A game that relies on a specific initial state is buggy on the other hand.

 

I think since Stella is in the minority the onus should be on the Stella team...

Nonsense.

 

... to dump SARA ram at least ... and see if it clears without power (what the rest of the development teams predict) or acts like static RAM.

Since I built a dumper years ago, and it only takes a few minutes to test this, I dumped the superchip ram inside an original "STARGATE" cartridge, power-cycling it after each dump:

 

dump1:
00000000 37 54 91 eb 33 8f da 5d 91 a2 0c c5 dd 4a 71 0a |7T..3..].....Jq.|
00000010 3f 6c 9a c8 e2 1f 1a ca a9 ea ca 51 10 db 84 e9 |?l.........Q....|
00000020 3a 60 f3 55 11 63 cb 4b f1 16 ee f1 d2 89 59 4c |:`.U.c.K......YL|
00000030 62 2b 35 9d b2 55 06 ca 73 af 0a 76 90 6d 74 7a |b+5..U..s..v.mtz|
00000040 92 1b 3f 0c c7 30 da 5c e2 8a fa 7a b2 ef f6 b9 |..?..0.\...z....|
00000050 5c b7 5c ed 52 cd 0a 8d 93 61 97 34 3d 50 a8 3a |\.\.R....a.4=P.
00000060 b1 34 2e a5 41 95 85 65 cb 21 5c 77 10 0b 67 d7 |.4..A..e.!\w..g.|
00000070 c2 b8 45 6c b8 34 fc 6d eb 24 a6 eb 0e 40 19 db |..El.4.m.$...@..|

dump2:
00000000 15 ef b0 e8 36 cd e2 5e c4 a6 4c be 19 6e 65 4a |....6..^..L..neJ|
00000010 3f 78 90 c9 4a 0b 9f ee 89 ae 7a 49 18 9e 84 6e |?x..J.....zI...n|
00000020 3b e0 c3 95 01 71 7b 48 f4 32 f6 31 fa 81 d9 5e |;....q{H.2.1...^|
00000030 6a 61 29 d5 bb 71 0a 4a 32 a5 08 70 a0 6d b4 1f |ja)..q.J2..p.m..|
00000040 da 79 6b 0d cf 7c 4f d8 22 8e fa 4a 73 cf be fd |.yk..|O."..Js...|
00000050 14 97 5c ed 7e c5 1a 88 17 6f 36 74 3d 74 84 1e |..\.~....o6t=t..|
00000060 31 7c 3e e2 41 11 9f e5 ca ff 1c 36 19 28 63 f7 |1|>.A......6.(c.|
00000070 e2 ba 45 e9 dd 34 fc 41 f9 74 6f ab 8c f9 5b 8b |..E..4.A.to...[.|

dump3:
00000000 27 fd d0 e3 71 8d fa df 91 a3 cc 75 d9 6a 71 ea |'...q......u.jq.|
00000010 1f 4c 9b c9 ca 0f 1c 82 3d a8 4b 71 10 1f 84 6d |.L......=.Kq...m|
00000020 7a e0 f3 55 11 61 9a 4e f0 92 f0 f1 72 88 d9 5c |z..U.a.N....r..\|
00000030 63 2f 3d ed 3b 75 0e 6a 7b af 0a 76 84 6f 37 fb |c/=.;u.j{..v.o7.|
00000040 fa fb 7b 6d ff fc db fe fb be fa fa fa ef fe fb |..{m............|
00000050 0c 97 0c ac 5a 85 03 0c 17 00 07 20 2d 50 84 18 |....Z...... -P..|
00000060 b1 74 fe a5 41 95 95 f5 ca f5 de 77 10 26 25 f5 |.t..A......w.&%.|
00000070 82 91 4d 25 1d 14 ec 0d cb 20 ae 8b 0e 48 1d 8b |..M%..... ...H..|

Note that if I don't power cycle, the content of the ram doesn't change, which means my dumper software isn't affecting the results.

BTW, there are a good reasons to doubt that someone ever put dynamic RAM in a 2600 cart, not only in this particular case.

 

...(if not CBS RAM, no one can make those carts) ...

This makes clear that you don't even bother to read my replies. Thanks a lot.

 

Anyway, as I said in my previous post, it's totally possible to build a cart using a real CBS chip scavenged from an original game, using only the ram in it while putting the rom in an eprom. I don't have the right equipment (nor a CBS cart), but I'm pretty sure I could do that (and I only have basic skills in electronics).

It isn't necessary if the goal is just to test the initial state of ram. Just dump it's content from an original cartridge exactly like I did for superchip.

Edited March 8, 2018 by alex_79

[Omegamatrix]

I don't have alot of carts anymore, but here's what I remember about Dig Dug. The Super Chip ram was dirty. If you have that cart please give it a dump to see. It was not all zeros, and very random.

 

CBS extra ram is also not zeros. Here's an old post I made 8 years ago which has interesting insights into CBS ram (FA bankswitching). Also this post I made in the same thread mentions other FA dumps on the net which had different values in the ram. I investigated old dumps from Rom Hunter's V1 collection (long, long ago). Some of the FA dumps had $FF and $7F in the ram locations. Others had $F0, $F4, and $FC. So it does not appear consistent or reliable, and certainly not all zero's.

 

IMHO ram should be cleared, or be feared...

[DirtyHairy]

..and if there are different versions or behaviors of the external RAM due to process changes over the years, then that needs to be considered in emulation as well.

 

 

Emulation always is just an approximation of the hardware, and it will never be an exact model. Furthermore, our time is limited, and we have to choose where to invest it. There are many aspects of emulation that I are much more important to me (and know to be incorrect) as the random distribution of uninitialized and undefined RAM contents and, you won't get me to invest any time in this --- my life has more important things to offer

Edited March 9, 2018 by DirtyHairy

[Mr SQL]

I don't have alot of carts anymore, but here's what I remember about Dig Dug. The Super Chip ram was dirty. If you have that cart please give it a dump to see. It was not all zeros, and very random.

 

CBS extra ram is also not zeros. Here's an old post I made 8 years ago which has interesting insights into CBS ram (FA bankswitching). Also this post I made in the same thread mentions other FA dumps on the net which had different values in the ram. I investigated old dumps from Rom Hunter's V1 collection (long, long ago). Some of the FA dumps had $FF and $7F in the ram locations. Others had $F0, $F4, and $FC. So it does not appear consistent or reliable, and certainly not all zero's.

 

IMHO ram should be cleared, or be feared...

 

I concur, my response is on the emulation thread here:

http://atariage.com/forums/topic/275179-stella-51-released/?p=3980974

 

 

 

 

Emulation always is just an approximation of the hardware, and it will never be an exact model. Furthermore, our time is limited, and we have to choose where to invest it. There are many aspects of emulation that I are much more important to me (and know to be incorrect) as the random distribution of uninitialized and undefined RAM contents and, you won't get me to invest any time in this --- my life has more important things to offer

 

As you can see from my response above I am supporting a number of Atari platforms with frameworks, languages and IDE's.

 

Consider that supporting Stella for 10 liners is going to come last; in the 80's I was in many of these 10 line BASIC game competitions and one liner contests too; it's a best practice to rely on ideosycracies of timing, artifacts, intial values and anything else you can identify

 

it's also a lot of fun! Try writing a BASIC 10 liner with Flashback BASIC, it won't take long and you can just use SuperCharger BASIC to cross compile your binary if it fails in Stella/Stellarator

 

http://relationalframework.com/Atari2600gamesonline.htm#GATES

 

btw, why did you change your opinion on the tribal drums? They sound much better on a real TIA than they do in emulation.

[alex_79]

I don't have alot of carts anymore, but here's what I remember about Dig Dug. The Super Chip ram was dirty. If you have that cart please give it a dump to see. It was not all zeros, and very random.

 

I have 2 of them actually. Both gray labels, one with a 1985 copyright, the other one with a 1987 one:

DIG DUG (PAL) 1985 copyright 

dump1:
00000000  03 f0 0f d0 61 90 03 e1  0c 88 4a 71 4c 98 03 e2  |....a.....JqL...|
00000010  7d 8f 75 0b ea ff e6 3f  dc 1f ec 9f be df ff 6d  |}.u....?.......m|
00000020  2b 50 38 32 84 da 05 f8  84 91 70 f0 28 82 03 90  |+P82......p.(...|
00000030  f9 cf f3 8f fc 3e 77 a7  5f df d7 3a f7 2d fa ea  |.....>w._..:.-..|
00000040  da d2 07 e2 2e b1 58 03  17 e0 06 53 32 d1 55 c0  |......X....S2.U.|
00000050  f3 bc 51 3a ba 0f f0 1f  fd 0f e3 4f df 3d fa 4f  |..Q:.......O.=.O|
00000060  8a 94 69 58 c7 c4 a8 90  d5 33 0d 71 a7 51 80 30  |..iX.....3.q.Q.0|
00000070  db 4f f9 2f bd 4d d3 2f  3c 8d d9 5e df de f5 5f  |.O./.M./<..^..._|

dump2:
00000000  07 40 0f c0 01 90 03 a9  0c 08 4a 69 4c 8e 03 23  |.@........JiL..#|
00000010  7d 8f 75 ab ea ff e6 7f  d8 5b ec 9f ba d7 ff 6d  |}.u......[.....m|
00000020  0b 58 18 22 05 4a 05 d8  04 91 74 d0 08 82 07 02  |.X.".J....t.....|
00000030  f9 d5 f3 8f fc 3a 73 a6  de df d7 3a f5 2c fa ea  |.....:s....:.,..|
00000040  4b d2 07 e6 0e 31 08 03  05 e2 06 53 02 81 15 00  |K....1.....S....|
00000050  f3 bc f9 38 f2 2f f0 3f  f8 cf f3 5f dd 7d fa 47  |...8./.?..._.}.G|
00000060  0e 94 69 58 c7 c4 28 90  95 13 0d 11 2f 41 80 00  |..iX..(...../A..|
00000070  f9 4f f8 6f f9 5d d3 7f  fc 89 d9 56 df de f5 df  |.O.o.].....V....|

DIG DUG (PAL) 1987 copyright

dump1:
00000000  bc 2c 57 eb 75 31 14 25  40 4f 83 45 e2 46 6e 0e  |.,W.u1.%@O.E.Fn.|
00000010  e9 fc 79 30 92 6d 90 65  b9 f8 f9 1b ca a3 2c c5  |..y0.m.e......,.|
00000020  ac 1c 13 45 66 61 43 49  81 ab 7a 0d 62 cb 4b 57  |...EfaCI..z.b.KW|
00000030  e9 99 3a f6 c8 9c c6 86  ee d4 67 0e b8 d4 3c a6  |..:.......g...<.|
00000040  ee bf 43 1d 97 98 5f 7d  b1 5b ee dd 61 5f 51 86  |..C..._}.[..a_Q.|
00000050  fa 80 c2 39 a2 8a d4 9e  83 51 8e 5c d1 08 a6 e1  |...9.....Q.\....|
00000060  af 9d 58 7f c3 c7 05 57  c8 70 39 e5 3f 20 27 d6  |..X....W.p9.? '.|
00000070  db 7f a2 ca e6 32 bb 13  e6 86 a1 07 ee e1 ad 1b  |.....2..........|

dump2:
00000000  bc 6e 55 e3 75 31 90 e5  51 08 81 45 e4 60 ec 06  |.nU.u1..Q..E.`..|
00000010  e9 fc 79 30 92 6d 90 45  99 78 3c 19 ce 2f 2c c5  |..y0.m.E.x<../,.|
00000020  ac 18 03 61 62 61 03 59  80 aa 78 09 72 89 4b 57  |...aba.Y..x.r.KW|
00000030  e9 9d 72 de c9 9d cd 86  ef f4 37 0f b9 d4 1e 86  |..r.......7.....|
00000040  e6 bf c7 55 97 98 7f fd  f1 db ec dd 61 7f 51 f7  |...U........a.Q.|
00000050  39 80 c2 01 a2 8a 10 1e  81 01 8e 4c 55 08 8e c1  |9..........LU...|
00000060  eb 9d 50 7d cb c5 15 73  c8 70 79 e5 3e 30 26 d6  |..P}...s.py.>0&.|
00000070  cb 1f a2 8a c6 22 8b 1b  e6 86 a8 07 cf e9 ad 0b  |....."..........|

[Omegamatrix]

Yeah, that is like the randomization I remembered when dumping Dig Dug. Certainly not all zero's, and changing.

[Mr SQL]

GATES is a 10 line Atari Flashback BASIC program compatible with the Starpath SuperCharger:

 

When running on the Atari Flashback it uses Atari's default memory scheme for the portable console but when running on the SuperCharger it uses the SuperCharger's memory scheme.

 

This is the magic of interoperable technology and it's a lot of fun! The same concept could be applied to dynamically translate Assembly SuperCharger games for the Portable, and I'm working on a cross compiler for the A8.

 

Here's some info about the design for anyone whose interested:

 

rem ** GATES, Atari 2600 10 line BASIC Game with an overview of the program architecture!
rem ** Detailed Explanation of the program, classic listing is readable with verbose BASIC commands and white space:
rem -----------------------------------------------------------------------------------------------------------------
rem -- GATES Design feature #1: Slow fall rate is sub Pixel; The slow falling rate in GATES is .5 pixels at a time:
rem -- Ever want to just add half a pixel or .5 in an 8-bit world? Line 0 uses the expression t=1-t to do that sparsely.
rem -- Ship controls, meteors AI and physics (gravity and inertia) lines 0 & 1; all driven by the flip-flop expression.
rem -- Initialization section - lines 3 & 4 only run once per game to draw the sprites and the board.
rem -- Frame delay throttle - line 5 allows soft blitter scrolling with additional game logic every 8th frame
rem -- incremental data pointer - line 6 increments the datapointer and loops it at the upper boundry
rem -- Randomizer - the incremental data pointer is also a gameplay driven randomizer for subsequent games.
rem -- line 6 sets constants and variables and gets the remainder of the scrolling X index for the virtualworld divided by 10.
rem -- (the remainder from division is stored in temp variable b [a,b,c,d are temp variables for this BASIC]).
rem -- line 7 if there's no remainder that's where a gate gets placed.
rem -- increasing difficulty - Two virtualworld pixels are flipped in a barrier by line 7, driven by the data pointer.
rem -- and after every 7th gate the flip can result in larger subsequent gates or smaller gates more difficult to cross.
rem -- Gate crasher? Meteor hit? Line 8 flashes the screen red, plays Fx and starts the game over with randomness.
rem -- Mood columns - Line 9 turns the moving barriers into mood columns flowing with ebbing hues as they traverse the screen.
rem -- Tribal Drums algorythm inspired by fun with BASIC Programming 2:05 https://www.youtube.com/watch?v=vhAj0XXuxVU
rem -- 120 character ruler:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0 if joy0up=1 then player0y=player0y+1:t=1-t:missile1y=missile1y+t else player0y=player0y-t:t=1-t:missile1y=missile1y+t
1 if joy0left=1 then player0x=player0x-1:missile0y=missile0y+1 else player0x=player0x+2:missile0y=missile0y+1
2 missile1x=missile1x+1:missile0x=missile0x+t:AUDV0=R(l):COLUBK=0
3 if g=0 then for j=0 to 3:player0(j)=pl(j):player0colors(j)=p2(j):next j else goto 5
4 for x=20 to 70 step 10:for y = 0 to 19:vwpixel(x,y,on):next y,x:player0y=50:player0x=52:BYTErowoffset=120:g=1
5 if e>7 then e=0:BITIndex=BITIndex+1:COLUP1=l*10 else e=e+1:return:data pl 240,255,127,240
6 if l<20 then l=l+1:x=BITIndex/10 else l=0:x=BITIndex/10:data p2 $36,$64,$76,$36:data R 3,8,2,0,3,8,8,5,3,0,3,5,8,8,5
7 if b=0 then x=BITIndex+10:vwpixel(x,R(l)+10,flip):vwpixel(x,R(l)+11,flip):data R2 5,8,5,3,0,2
8 if CXP0FB=130 or CXM1P>127 or CXM0P>127 then CXCLR=0:COLUBK=$34:AUDC0=4:AUDF0=l:AUDV0=31:g=0:BITIndex=0
9 if BITIndex>71 then BITIndex=0 else for j=0 to 9:rowcolors(j)=rowcolors(j)+2:next j:scrollvirtualworldtoggle=1

 

If you compile GATES for the handheld console you'll have to add some filler so it will recognize the ROM. Unused code or text in data statements works fine, I used the text from WARPDRIVE's cut scenes.

 

data textdata "PRGE 2016 ROCKS"
data textdata9 "practice this "
data textdata8 "game! take aim!"
data textdata7 "focus your mind"

 

 

 

[Mr SQL]

GATES Version R2A is in the first post.

 

R2A replaces the tribal drums sound track with an orchestral arrangement using the BASIC's built in sequencer/tracker.

 

Other features: The button will change the background color.

 

The game still fits in 10 lines and there's still some extra room, any ideas to add features?

 

Here's the updated Flashback BASIC listing with a description of how the program works:

 

GATES with paddingR2A.txt

 

Flashback BASIC is cross compatible with SuperCharger BASIC, download it here and here.

 

[Swami]

GATES Version R2A is in the first post.

 

R2A replaces the tribal drums sound track with an orchestral arrangement using the BASIC's built in sequencer/tracker.

 

Other features: The button will change the background color.

 

The game still fits in 10 lines and there's still some extra room, any ideas to add features?

 

Here's the updated Flashback BASIC listing with a description of how the program works:

 

GATES with paddingR2A.txt

 

Flashback BASIC is cross compatible with SuperCharger BASIC, download it here and here.

 

 

Hi, Sorry, I am confused by the supercharger reference (although I know all about the Supercharger, which uses an audio cassette player with the interface). How do you interface the game with the Supercharger on the 2600 or how do you make it work on the 2600? Thanks!

[Mr SQL]

 

Hi, Sorry, I am confused by the supercharger reference (although I know all about the Supercharger, which uses an audio cassette player with the interface). How do you interface the game with the Supercharger on the 2600 or how do you make it work on the 2600? Thanks!

 

Hi, I've added wav files for the SuperCharger to the first post.

 

You can also use the Harmony cart to play the binaries on the 2600.

[Swami]

 

Hi, I've added wav files for the SuperCharger to the first post.

 

You can also use the Harmony cart to play the binaries on the 2600.

 

Cool. Old School method. Thanks!

[Mr SQL]

New version released

 

GATECRASHER mellowmix is a relaxed version of GATECRASHER featuring an ambient synth soundtrack that blends with the gameplay and a motivational scoring system:

 

http://atariage.com/forums/topic/281793-gatecrasher-mellowmix/

 

Still working on cross compiling the SuperCharger version; Flashback BASIC has 5K like a VIC-20 instead of the 4K free to SuperCharger BASIC so I have to crunch it a bit to get it to fit..