ROBOTRON X - new game & disassy

[Blue Azure]

BAM!BAM!BAM!

BAM!

BAM! BLUE AZURE MONDAY BAM!

BAM!

BAM!BAM!BAM!BAM!

 

(Now I release my games on Mondays, so I can fill your week with game-playing instead of on weekends).

 

Here it is, finally, the vaunted ROBOTRON X. There was a bit of a delay here, cuz we needed to verify some things, which it turns out still haven't been completely verified. The game is released (below), as the show must go on! But first, let's back up for a bit (or a byte). The source list, in simple turns, is a mess. The more I look at it, the more confused I get. So I don't want to look at it anymore. Frustrated, I gave up, thinking the source listing went encrypted over the decades to match the BIOS!!! And then a major thanks to Groovy Bee - he referred me to the 7800 Programmer's section I never looked at, and there was a major effort started by Dan Boris in 2006 and finished by Scott T. in 2012 to bring it together. Groovy. I converted it to .rtf so everyone can view it…

 

ROBOTRON DISASSEMBLY 2012, compliments of DB & ST...converted to .rtf so everyione can read it.

RobotronDisassy2012.rtf

 

It's a case of building blocks. It's clearly too big a job for one person to complete, so I'll be #3 to try it. We're still not where I want to be with this. I will be reviewing this and bringing it up to my unconventional format and post it when done. I use my format on my 10+ hour plane flights and for educational purposes for those who don't/can't/won't use DASM or other tools to be able to view and use C files.

 

As a side note I see Dan Boris also worked on FOOD FIGHT and I haven't searched 7800 Programmer's section yet for that. If anyone has a usable FOODFIGHT.asm or FOODF.asm that actually matches the released binary, please drop it here…

 

Now back to ROBOTRON (1984) vs. ROBOTRON X (19113, for those who know how the millennium bug works). Back in the Middle Ages, er, uh, Middle 1980s, as a kid I was playing 7800 Robotron. It was a riot of a game, always with the same result - I LOSE. Maybe I got to level 10, I can't remember. I was whooping it up - yelling and screaming and the neighbors were yelling and screaming as well…"Shuuuuut Uuuuup!". Frankly, the game was just plain too doggone hard to play. Who do you know who's playing Robotron these days? Nobody. Shelved decades ago, it's collecting about as much dust as Centipede was.

 

Something had to be done about it. Looking at the source list, it's a relatively easy read, so I went to the binary code to key in the change, and yikes, it doesn't match. Another victim of the grey area known as 1984-1986. I worked it, basically "guessing" what might work and on the second try I got it. I actually received a phone call while keying in the codes to "fix" Robotron, and yelled out "I CRACKED ROBOTRON!" And of course the other end of the line was saying, "Huh, what?" So they got the e-mail with ROBOTRON X attached, and I haven't heard from them since. Hope they didn't DIE in real life. Cuz this game is addictive and kills your hand after about an hour. Be sure to use a sacrificial Proline Joystick so when/if it breaks - you won't care!!! And a headache as well - turn down the audio!!! It's totally obnoxious on the TIA!!! Too bad not on Pokey.

 

At first we played it on ProSystem Emulator, and all was well. But you get tired around level 15 or 20, when things really start heating up every 5 levels with enemies and bullets (actually, "cruise missiles" according to the instruction manual) everywhere. The game starts to pixelate and actually even crash. I found if I started immediately shooting everything in sight this would defer or alleviate the emulator crashing. Now I was at first running XP on my Mac running as a Mac as just about everything I do is on a Mac. Eventually I did fire up my old 2004 PC and run ROBOTRON X on it as well. And even at level 5 you can enter level 5 and do nothing and eventually it crashes as well. So off to EPROM, program the 27256 and install on a real 7800 which never saw this version of the game before, and it PURRED. No errors, no crashing, NO DYING. This is sweet, for those who know how to program an EPROM and have a 32K+ board laying in wait.

 

Game play results… The game displays 7 digit scoring (millions of points displayed) so your High Score Card will be busy with this one. The game only displays up to 99 levels and then restarts at level 0. At about level 262 or so, you can achieve 10,000,000 points but the game will reset to zero points and start over. It takes about 100 minutes of non-stop gameplay, so get your comfy chair ready for this one... The object of the game is to save Humans - Mommy, Daddy, and Mikey (the owner of GoodDealGames.com, but don't tell him I said so), and shoot everything else in sight. Too bad your bullets don't pass through or kill the pesky & indestructible Hulk robotron, or the game would be even easier. The best fun is sitting in the middle of the screen and everything is swarming around you, in fact you purposely let them swarm. Then you press and hold the fire button and continuously swivel the joystick around and around and around firing in every direction. Eventually everything is dead and you move onto the next level. Hurrah. Forget 2-player mode unless you have a little brother or sister you don't prefer, and you sit them down as Player 2. "I'm almost done…" (after a day or two).

 

By the by, the ProSystem Emulator I am using is Version 1.3 © 2005 Greg Stanton, modified by Leonis, 2008. Not sure this is the latest and/or the one to use, or if this is 1.3e or not. Maybe other users can tell me this. Does your emulator version crash at Robotron levels 5, 10, 15, 20, etc.? What about SDL/MESS? I'm still not running that yet.

 

HOW IT WAS DONE...

 

THE CHANGE...

$D8B1 (EPROM $58B1) changes from $C9 $0D $D0 etc. to $4C $40 $D9, a jump to a magic invincible place. Just 3 bytes out of the 32768 in the entire code are changed and the game transforms into this raucous shooter for the ages…my bid for 7800 HACK OF THE YEAR - 2013. Unfortunately, looking at the disassembly provided by DB and ST it's not obvious why this works. Too bad.

 

NTSC ROBOTRON X

ROBOTRON_X_NTSC_BE52.bin

Robotron_X_NTSC_32K.a78

 

PAL ROBOTRON X

There was no Robotron originally produced/released for the PAL 7800. Can we make one?

 

ELECTRONIC HOBBYIST CHALLENGE...

 

Then the question is, how many lives would you actually lose playing this game up to 5, 10, 15, 20 levels (thousands of lives?)? There's a way to do this, with hardware. This is a electronic hobbyist's dream, to have another project to play with. You will need a solder iron and solder, wire, an electronic counter, an EPROM burner and these binary files, two 27256 EPROMs, and a 7800 EPROM board capable of handling a 27256. I created an EPROM, named DEATHCNT.bin (death counter), with all bytes $FF except the one byte at address $D8B1 (EPROM $58B1) is a $00. Program the ROBOTRON X chip and verify it's working. Then burn the DEATHCNT.bin on another 27256 EPROM and solder all pins to the original ROBOTRON X EPROM, EXCEPT the data bus pins 11(D0),12,13,15,16,17,18,19(D7) remain unsoldered and bent away from the ROBOTRON X EPROM. Any one of these pins 11,12,13,15,16,17,18,19 with pin 14 (ground) can be wired to an electronic counter and you should be able to count the deaths. EPROMs are noisy so you may need to add a 100pf (or higher?) capacitor across the electronic counter input to make it work right. Obviously, the counter shouldn't be registering deaths when you're not dying. Video this exercise and share it with us…

 

DEATH COUNTER (THIS IS NOT A VIDEO GAME)

DEATHCNT.bin

 

ENJOY THE GAME!!!

 

NEXT UP > GALAGA

[mimo]

Us PAL users have been asking for a PAL version for decades. Let's hope that it is now within reach

[Bakasama]

I've tried this on my macbook. I wasn't expecting a trainer but it is fun to see how fast the grunts go without dying.

[gambler172]

Hi BA

great work

greetings Walter

[gorfcadet]

Waitaminute! Bakasama, what are you running in mac to emulate? That would be a major help to me. I know there is something, but I haven't been able to find an actual link to a mac osx 7800 emu.

[Bakasama]

I use WinonX, it works with the prosystem with some weird sounds at time but at least I can play the 7800 homebrews. I just use it just because too much trouble just to use WINE for that.

 

You could try using SDLMESS but like it's name it is a mess from user standpoint.

 

Prosystem is suppose to be open source but I've haven't seen anyone attempt to port that Mac OSX

[NIKON]

After numerous plays....the game always crashes on me at level 50...I am using ProSystem 1.3 have no idea why ...but it is still fun to play this without dying....

[Blue Azure]

Yo NIKON, you're probaby getting tired by level 50. At level 49, simply press PAUSE (that's control/P or whatever the control key that works on your PC). Rest a few minutes and then jump into the game again. Press PAUSE again, and be sure to shoot everything in sight right away and you should be able to get through level 50. It's the emulator crashing trying to deal with too many sprites (objects on the screen). It works 100% in hardware, so keep that in mind - I got to level 262, no problems encountered. We should make carts some day, but too busy with other things right now.

[GroovyBee]

It's the emulator crashing trying to deal with too many sprites (objects on the screen).

 

Thats not true. ProSystem will process more Display List (DL) headers in a zone compared to the real hardware.

[Blue Azure]

Yo Groovy, I stand corrected and of course I wasn't trying to criticize the desgn of ProSys or design new games to break it down - ProSys is great and been my workhorse for the past months. Still wonder what's happening...it can handle more DL headers, but can't handle them fast enough? I could re-design my ROBOTRON so it would work on anything, but no time for that right now.

[GroovyBee]

Don't worry, no offence taken. ProSystem is good but its not cycle accurate at all.

[Blue Azure]

In case anyone is wondering...YES! I'm working on the ROBOTRON Disassembly right now. It's Priority #1 for me. It's a tough one, and as I'm finding out, the Dan Boris and Scotty versions are now somewhat usable, now that I've dug deeper into what they did. And they get full credit wherever possible. I can see it now, I'm re-tracing the same steps they took in prior years. The problem is the code was completely re-organized from the ca.1984 source list we have on file to the ca.1986 released binary. Game start was originally at $C000, now it's at $F31D of all places. There was never a PAL Robotron probably because the NTSC version received grave reviews for impossible game play instead of rave reviews. But there's ways to make it more playable, so we can now create the PAL version...(I hope).

 

THE GOAL:

(1) Create a disassembly to be a Pathfinder to the creation of PAL Robotron. I know nothing about NTSC-to-PAL conversion, but I'm hoping someone on here can help. It could take 5 minutes or 5 hours to convert to PAL - I have no idea. What a seasoned 7800 developer needs to do it, I have no idea either. All I know is PAL Robotron doesn't exist yet. If we had a fully-commented source I'm sure we could do it. However, I already know the likelihood of that is about 0%. But not to give up yet...

(2) Salvage as much is possible of the original source list comments on the new disassembly.

(3) All commented source code that doesn't directly port to this new disassembly will be bumped to the bottom of the disassembly for future legacy review purposes (for the next guy to figure out more). All bytes will be accounted for ($7000-$FFFF) on this 2013 version, just as the Dan Boris and Scotty versions. Too bad the game isn't 16K, there would be about 1/2 the work to do.

 

In case someone knows how to convert to PAL with less than a full disassembly I'll post some of the progress so far. Since the game was complete re-orged, the equates table is completely busted so I don't know where much of anything is yet. But piece-by-piece I'm finding things, like the scoring table and the game initialization at $F31D. There was also 4K of table data that I found last night that mostly matches the source list so that's a big score for the 32K project. I am still looking to capture everything to do with MPTR which is the missile pointer. A lot of this code is in $DCXX, but returns to an unknown location for processing, and that's what I need to find. Meanwhile, if anyone finds a complete ROBOTRON.asm that actually matches the released ca.1986 binary checksum=BFDC...please gimme!!!

 

Preliminary ROBOTRON Disassembly $F19A-$FFFF (this can be paired with the Dan Boris & Scotty Disasy2012 I posted above for further analysis)...

Robotron_FXXX_Disassy.rtf

[thegamezmaster]

Great work! Thanks!

[Blue Azure]

Long, but a good read. My effort to completely disassemble the ROBOTRON game is complete. Although there's more I could do, the clock ran out as I need to move onto other tasks. As it is, we know more now than ever before. This is BIG.

 

First off, why do it and how to do it? As the years click off, it becomes more and more difficult to do something "new" with the Atari 7800. Sure, new games are coming out, thanks to PMP and P13 and #392 and Gambler and Kevin and so on. They're all doing remarkable work. But for the average bloke like me, we're limited in our knowledge & resourcefulness, but certainly not limited in creativity. The released source lists provide us a chance to learn how it was done and the possibility to enhance it. Face it, we all love what was once Atari and want it to live-on forever. Being able to modify the original games is a dream come true. ROBOTRON presents itself with the added potential, as this was the one original title not ported to PAL. Why that was, I'm not sure we know. The game was very difficult to play, the result was always the same - I LOSE. The video game downturn and layoff turmoil at Atari didn't help either. Somehow a ROBOTRON source list leaked out but it was very preliminary (August, 1983). From it, we can tell a lot of the code hadn't even been designed yet. It also looks as if it was hacked just to get something to market, as the game start address is now $F31D, of all places. It was $C000 in 1983. We know not all of the code in the cartridge is being used either. In the hacking process, the GCC © 1984 was removed from the source and resulting binary - the only 7800 cartridge that was this way. The years clicked off, and then the decades. There has been interest in dissecting this code over the years, as evidenced by the efforts of Dan Boris (2006) and Scott T. (2012), whom I refer to as "Scotty." But still the disassembly lacked a lot of commentary essential to understanding the basic workings of the game. So I set out to work my magic on it. There are nine "S82" source files, whatever S82 is I don't know. Again this is the only original 7800 source list found this way. I can read them and that's all that matters. There's no linker so you don't know where anything is with respect to anything else. I imported them to my text editor and there it was, a pile of mush representing 32,768 bytes. Somehow. I know it's a mess because Dan wouldn't have taken on the project in the first place. Knowing me, I had to take the bull by the horns and directly started decoding the program code, because eventually I'd get frustrated and want to quit. Sure, I could start with the graphics data, and show pages of data that I may never know what it does, but that was to wait until later, when the program decoding bogged down. Then I hex-dumped the binary file, so I had three files on the screen, side-by-side: (1) the source code that was was being hand-disassembled, (2) the binary hex dump, and (3) Dan's and Scotty's disassembly (2012) which wasn't used much in the beginning. But later played an essential role in closing some holes. As the source code that could be decoded dwindled, the task quickly finished by patching the missing pieces with the work that Dan & Scotty did. In the end, I was comfortable I had preserved as much of the original comments as possible. Whatever I couldn't (or didn't) decode is retained at the bottom of the file as "Unclaimed Orphans" and highlighted in Cayenne color. The original prolog up front that shows page zero and all the equates was also retained but remains unchecked. Finally, cross-check was completed to make sure every byte on the disassembly matched the binary and all addresses are included. The 32,768 pieces to the puzzle are complete, at least for this version. And what a relief to get this off my plate. Now we can settle into re-designing an old game with a new personality. Thirty years later no one was playing it, now everyone will want to play...

 

I would like to thank Dan Boris (2006) and Scotty (2012) for their efforts which led us to where we are now. Not sure where they are now, but I see they were both here in 2012. Without their extensive efforts, I would not have had so much success. I hope they somehow find the result of my work. Cuz I know they could enhance it even more.

 

This game is amazing. It has EVERYTHING. If you want to program a new video game, check out ROBOTRON. It has game-programmability built-in. It was a climax of my effort when I found the WAVETBL Attributes Table at $EF1A. That was a cool-looking table in the original source, but I couldn't match the raw source code to the binary file, since the table hadn't been fully worked out and was mostly zeroed out. It took about 15 minutes to convert what-was to what-is, but now we have it. We can now create our own games to cater to our own personalities and likings. The options are endless, as we can specify what's going on in the first 40 levels and beyond.

 

ROBOTRON GAME LEVELS & LIVES SPEC

(Per the source list and some confirmed in gameplay testing)

 

* There is no Level 0, so the game starts at level 1.

* Level 1 - 40 play as specified in the WAVETBL starting @ address $EF1A, the numbers represent quantities of each Mommy, Daddy, and Mikey, Grunts, etc. All numbers are in hexadecimal, so "10" is actually "16" in decimal.

* Achieving level 41, the game begins to replay levels 21-40 and repeats this over and over, and then at level 256, something happens (the DeLorean lands in 1984 or something like that) and the game returns to level 1 to start all over. It takes about 100 minutes (unless you're in a hurry) to play 255 levels so this is OK.

* Level display is to "99" maximum and rolls over to "0".

* Initial Lives setting is 5 with 4 spare Lives displayed. But if we change $A5$75 at address $9044 to $A5$74 we start with 1 Life and no spares displayed. That was for Player 1 and for Player 2 we change $A5$75 at address $9061 to $A5$74. Perfect.

* Bonus Lives are at every 25,000 points.

* Maximum Lives achievable is 127 Lives. Why?

* Maximum Lives displayed on the screen is 7. But if we change $C0$07 at address $D358 to $C0$0E, now we can display up to 14 Lives. I like having more lives than cats. Purrfect, again.

* Maximum character sprites per type and per screen seems to be limited to 4D hex or 77 decimal. This means you can have up to 77 Mommies on the screen all at once. Alternatively you can have up to 26 hex Daddies and 26 hex Mommies for a total of 76 decimal. Or up to 19 hex Daddies, 19 hex Mommies and 19 hex Mikeys for a total of 75 decimal.

* The Score Table for non-Humans is at $F19A.

 

NOTE: There is a point where too much action can actually crash the emulator, as well as the 7800 hardware. The hardware can handle more, so this is where the emulator users start to be left behind. More testing is required to define these levels, particularly on the number of Brains. The Brains go berserk with no hulks or anything else getting in the way. Where invincibility made ROBOTRON too easy, now we look to make the game as difficult as possible without crashing the machines playing the game.

 

RobotronDisassy2013.rtf

(CAUTION, this is at least 161 pages)

 

MISSING PIECES

 

AUDIO TUNES

Still trying to get a full understanding of "TUNES". The original TUNES (TIA sounds) codes and lengths have been totally changed. I did find where they are approximately. There is a DOTUNE routine at $E395, which calls the data starting at $E67A, which is the MC/Player shooting sound. And several sounds were apparently added to the final released version. There is a lot of original support info included in the disassembly (which may or may not be correct) in this part of the code. Search for E67A in the text and you'l see it. I hope someone can complete this part of the task. The rack-end sound is particularly obnoxious after playing several hundred levels, and I'd like to change it.

 

CHANGE 2084

In Level 10 there's Electrode boxes labeled "2084". I'd like to be able to change that to "2013" or any other 4-digit number or word. Of course now we know that we can program the levels. To show "2084" in level 1, we can change Electrode Style from "0" to "7" by entering $07 @ address $EF28 and Electrode quantity, say $1D @ address $EF29. This way we can verify the "2084" change at level 1. At address $FCA1, changing $4A to $00 mops out the "2084" to make it a blank red box, but I can't find how to change the "2084" bit mapping. It may not be possible to do this easily.

 

Now I need to cross over the the other side to the Programmer's corner and see if we can wave a magic wand and create a PAL ROBOTRON.

 

Whew, that was a lot of work. Getting closer to vacation time for me...3 weeks in Bora Bora should do it.

[tep392]

If you want to figure out how the tune data is structured so you can change it, take a look at Pacmanplus's source code for PMC. The sound code is basically the same as the robotron code but has better comments. The structure of the tune/fx data is identical. Each sound effect data structure is comprised of a sequence of notes/durations, followed by control register values/durations then volume register values/durations. The tables at the start of the code have offsets for the control and volume data that's used to locate it and index through it as the sound is played. It's actually quite flexible. For example, you could have a sound that's comprised of 20 notes with a single control and volume or you can have the control and volume change with each note, or more often if you like. Your of course limited to one change per loop.

 

You'll also need to read some documentation for the TIA so you can make sense of the control values.

[Blue Azure]

Thanks Perry for your update. That should help me or someone else to complete that part of the project.

Right now I'm too busy to get to that. Appreciate your input though. Have a great weekend!

[robotrondev]

I'll take a look at the new source and if I have time, I'll add comments where applicable and post them back here for review. No promises though, you might have taken the disassembly further than I could hope

 

However, any progress is good progress and I'll do what I can.

 

Scott T.

[Blue Azure]

Great to hear from you "Scotty" and understand "no promises." I'm sure you got a kick out of my update to the ROBOTRON source. Not that every byte needs to be dissected, but I'm still hopeful we'll get a full handle on tunes some day. Don't know if you know Dan Boris, but sending a "howdy" to him as well. He did a lot of work on this and it looks like I missed him by about a year. I'm still on the other disassemblies, DigDug is done and I was able to port PAL Asteroids to NTSC Asteroids 3D so that's done. Of the originals I only have Xevious, Joust and FoodFight to go. I know Dan also worked on FoodFight. Did you update his work? Just asking. If you did, pleez dump it here. I did a work-up on it a couple of nights ago and Dan's is sparsely commented at best and it's gonna be another challenge for me some day. I have plans for another ROBOTRON version release, but no time for that right now. ROBOTRON on 7800 is BOSS, and it's about time in 2013 to unleash it!!! It could be up to 2 months before I get to it though. Blueman

[robotrondev]

Blueman

 

I only really looked at the Robotron 2084 assembly because I was trying to write my own version in C# and wanted info on how the Enforcers operated. I now know Eugene Jarvis got that weird behaviour via a bug, and so reproducing that behaviour would be practically impossible without disassembling the 6809 arcade roms.... bah.

 

I've not looked at the source for any other ROMs, but if there was one game I'd like to figure out the workings of, it'd be Xevious - but isn't that one fully commented anyway? I *loved* that game back in the day (I'm old enough to remember it when it was in the arcades first time round, and can still remember the intro music) .

 

If Xevious needs reverse engineered in general, I can take a look, but really it's Robotron I'm interested in.

[Blue Azure]

Yo Robodev, I agree ROBOTRON is BOSS. My fave to disassemble so far. It's got real potential and you'll love the new game I'll be working on in about a month or two. It shouldn't take more than a few days once I start on it. I already know what it is that I'm going to do, the name and etc.

 

Sure all the original games on the 78 have fully commented source lists. BUT they don't match the released binary. So if one wants to modify the released binary, which was the final working copy, then one must re-create the assembly source listing, like what I'm doing. I'm working on XEVIOUS right now and can give you a prelim look at it...No, the source doesn't match the released binary yet again, and since it doesn't appear to be linked, I have to manually piece it together. I wish I had a tool that disassembled the source list without stripping the comments.

 

XEVIOUS is a GREAT game, and seeing what I see so far in the disassembly, we're gonna have a lot of fun with this one!!! I have completed $8000, $9000, $E000 and layed out the rest so it looks like I've got my arms around it. If you want to help, do $D000, and/or at the bottom of the disassembly there's two blocks of DL code I can't find.

 

XEVIOUS NTSC disassembly, preliminary

XeviousDisassembly2.rtf

XEVIOUS NTSC DASM

XEVIOUS_NTSC_C0FD_DASM.rtf

 

BLUEman

[SoundGammon]

How about a "Walking Dead" hack?