DanBoris

The next version of MESS should have the bug fix I sent in that gets Summer Games, Winter Games, and Impossible Mission working. This fix also improves Tower Toppler to the point where it's playable, but there are still some graphics issues with it. Dan

As an FYI, the dumps that where posted here (and other places) where dumped as 32K images, but the top 16K contained just $FF's. So the original carts must have only been 16K and that upper 16K of data was unncessary. Dan

Of some answers: - Dreadnaughtfactor looks the way I remeber it, I'll have to compare it against the real thing to be sure. - (Games to fast) I am still using the same speed limiter that I used in the previous version which didn't work right on some systems. I will have to try improving that. - Don't need to use -limit anymore, speed limiting is on by default (amazing how much difference there is in PC speeds in only 3 years) - (I do think it runs a hair slower the .77) - If you turn off the speed limiter on both .77 and .80, .80 should be considerably faster. Due to issues with the speed limiter though certains games might run a little two slow. - (development tools/debugger) VSS will now load 8K roms. I have never seen an actual 8K ROM image, so this feature is mainly for developers. The version that I just released does not have the debugger enabled, there will be a seperate version with debugging enabled. This should be released in the next few days. This version will include a slightly improved integrated debugger, and to help learn how existing games work, it will have the ability to press keys on the keyboard to disable each player and missile, so you can see where they are used in the game. - (Berzerk) Yes the voice in Berzerk does not work. This was done in the game by rapidly changing the values in the POKEY which the emulator can't handle properly. Dan

I love this game (thus my motivation for the painful process of writing the MAME driver for it), and my local arcade actually had an I-Robot machine back in the day. I think there were two things that hurt this game. First, it was probably two far ahead of it's time, it was just too different for people. The second reason is a technical one. The polygon generator circuit in the game is built around a custom IC chip. Supposidly Atari had a really hard time getting these chips produced reliably. In the end they had to actually plug the chips into the machines one at a time until they found one that worked with that specific machine. For this reason very few I-Robot machines where produced, the commonly accepted number was 1000, 500 domestic and 500 forigen (probably where the dumping 500 units overboard story came from. The hardware the machine runs on is quite amazing. Besides the 6809 microprocessor, which was quite powerful for it's day, the game had a custom build Floating Point Processor and a graphics processor that could draw points, lines, and filled polygons entirely in hardware. Some pretty cool stuff! Dan

Well, after a 3 1/2 year break I have finally updated and released a new version of my Atari 5200 emulator VSS. You can get it from my web page at http://atarihq.com/danb Dan

RAM runs from $0000-$3FFF. The cartridge ROM space runs from $4000-$BFFF. A 32K cartridge will take up the whole space. With 16K carts it depends on how the cart is constructed. If the cart uses a single 16K ROM chip, it will appear at locations $4000-$BFFF. If it uses two 8K ROM chips (which was very common in 5200 carts) the first 8K will appear at $4000-$5FFF and repeat at $6000-$7FFF, the second 8K will appear at $8000-$9FFF and repeat at $A000-$BFFF. Dan

This should work ok. There is only one reason I can think of that this might not work. On the 7800 Display Lists cannot be in ROM due to access time requirments. I don't know if this is the same on the 5200. Dan

I've never seen one of these with a switch. It's possible that the switch allows you to put in an 8K EPROM with two games burned on it, the switched would allow you to select one or the other. It's only a guess, but it's possible. The only way to know for sure is to open up the cart and see how it is wired. Dan

This is the easiest way to do it is like this: org 0 VAR1 DS.B 1 VAR2 DS.B 1 lda VAR1 sta VAR2 DS.B 1 allocates 1 byte of memory at he current position. VAR1 will point to this memory. So in this example VAR1 will point to memory address $0000 and VAR2 will point to $0001. You can allocate word (2 bytes) the same way by using DS.W 1 You can set ORG to whatever location in memory you want your variables, just remeber to do another ORG before you code starts so it starts at the right address. You can also allocate block of space this way. If you need a table of 16 bytes you would do: TABLE DS.B 16 Dan

Has anyone see Mr Do's Castle running on any 5200 emulator? It has never worked on my emulator (VSS) and I have recently been trying to figure out why. It really appears that the rom image is corrupt. I corrected one bad assembly instruction, and it works much better but still pretty messy. Dan

This was a nagging question for me also, I understood the hardware quite clearly, but I had no clue how you actually did anything useful with it. To learn a little more about his I decided to disassemble Robotron. I will post what I have done so far on my web site in a few days (www.atarihq.com/danb). Basically the way Robotron (and I am sure may others) work is by treating each object on the screen as an 8-pixel high sprite. There is a table in memory where all the infomation about each sprite is written (position, image to display, etc). This table is then read by a display engine that builds the display lists. In the display engine, the screen is divided into 8 line high regions each with it's own display list at a fixed memory location. The engine itterates through the sprite table and determines which region(s) the sprite appears in. If it wholly within a specific region, it gets written into the display list. If it cross over the boundry of a region, it's written into two consecutive display lists. In this case the memory pointers are adjusted above the start of the sprite for the first region (so the sprite is shifted down in the region), and for the second region the pointer is adjusted to the middle of the sprite (do the sprite is shifted up in the region). This may seem a little complex, but once you get into it, it's not to bad, and once the engine is written and working you don't have to worry about it anymore. The real beauty of the 7800 is that you aren't tied to one rendering engine, you can create different ones tailored to your needs. Hope this helps a bit. Dan

I was mistaken about the upper fire buttons, they are not read via the keypad scanning. These buttons behave like the Shift keys on the 8-bit keyboard. So the state of these button can be read from bit 6 of the KBCODE register, and according to the Analog article these button can also generate a Break key interrupt. I have to admit this was one of the hardest parts of the 5200 emulation to get working properly. Dan

The hardware manual probably details the chip from a hardware engineers persepctive as opposed to the programmers perspective in the Stella Guide. It probably contains detials on signal timing, pinouts, voltage specification, etc. Dan

Yeah, bad ROMS are very rare, but they do happen. I have about 1000 carts for different system and I can only remeber to bad ones, a 2600 Donkey Kong and a 2600 Spider Fighter. Dan

First question, are you putting the correct header information on the image once you have dumped it? The most important bytes are 53 and 54 which determine which type of cart it is. The looping of the Atari logo indicates that the cart isn't passing the validation test. If it was passing the validation, but crashing when the cart started you probably wouldn't get the looping. "Since I am getting the title screen and that beginning screen I feel the rom is probably okay but wanted " This is not necessarily true. The bad sections of the ROM may be in the gameplay area not in the section of the code that displays the title page, etc. Since the real cart is getting through the validation test, at least the first bank of the ROM must be ok, but the validation check doesn't check anything beyond the first bank. Dan

Mspacman definitly uses P/Ms for the player and ghosts. When you get 2 ghosts and a player in the same horizontal region you will notice the flicker start up. So they are basically doing sprite re-use when possible, then switching to page flipping of the PMs when necessary. Galaxian is pretty interesting. It uses mode E for the graphics, so all the invaders are drawn as bitmapped graphics. If you look at the display list, VSCROLL and HSCROLL are enabled on every line and are probably used to move the alien formation around without having to redraw the whole thing every frame. This should leave enough time to paint the attacking aliens in thier appropriate places. Dan

Ah, ok, I don't think that document has ever surfaced. Atari-History.com has managed to come up with Hardware Manuals for a couple other Atari chips, to may someday they will run across this one. Dan

Just goto the link above, scroll down to "Atari 2600 Technical Files" and click on "Stella Programmers Guide". Dan

You can get it from my page: http://atarihq.com/danb/a2600.html Dan

Ok, a few suggestions on this.. - You DO have to write the color values to the shadow registers. As Cafeman pointed out the hardware registers get overwritten by the shadows every v-blank. - Trig0 is not shadowed so you have to read the hardware registers. - Remeber the trig inputs only read the top triggers on the 5200 control. The bottom triggers are read via the keyboard scanning along with the rest of the keypad buttons. Other then this, the code should work as written. You might want to check to be sure the color register isn't getting reset elsewhere in the code. Dan

These are excellent steps to follow to fix most old computer or video game consoles. I have fixed 90% of non-working/twitchy systems using this procedure. Dan Boris

The limit on the length of variables and labels is determined by the specific assembler you are using. In most cases the limits are probably so large (128 character or more) it really would not become an issue. Dan

"Was this related to the fact that all of these games have onboard RAM?" Yeah, I was writing the cart RAM data to the wrong memory address. Really stupid bug, can't imagine how I missed it this long. Dan

I submitted a bug fix to MESS that actually gets a couple more games working. Winter/Summer games and Impossible Mission will be working now. Tower Toppler also works much better now, but it still has some graphics problems. This bug fix should be in the next MESS release. Dan

The .bin file needed it's .A78 header added to it, as well as the validation key to get it working in MESS. I have sent the modified ROM to AtariAge so it should appear here soon. I check the game out in MESS and it seems the same as normal Asteroids, but there are some differences in the rom image so there must be something different about it. Of course both this version and the normal version of Asteroids play almost twice as fast as they should in MESS, still haven't figured out why this happends. Dan