DanBoris

I just posted a disassembly of the 5200 BIOS I did. It's on my site. It's almost complete with the exception of the section that generates the Atari logo, not quite sure how that all work. Moderator Edit: Dan Boris pages are located here: http://www.atarihq.com/danb

Yes, both of these games used Graphics mode 8 which is the high resolution monochrome mode. I haven't tried them on an emulator that supports color artifacting yet (my VSS emulator doesn't) so they may actuall have some color to them due to the color artifacts. Dan

I did do a byte by byte compare of the two roms and there are a lot of differences at the byte level, but they don't seem to translate into noticible differences in the game. The speed problem in Asteroids really bugs me, both MESS and my original standalone 7800 emulator do this, can't figure out why. Dan

If you are a fan of APX check out this site: http://www.atariarchives.org/APX/ Dan

I think the reason for using mode E in Joust was for the eggs. All the players, and enemies are made of players and missiles, if they used mode 4 (the next logical choice) the eggs would have also had to be players which would have lead to a lot of flickering. In mode E the eggs are actually drawn as part of the background graphics. This technique is feasible in Joust for a few reasons: 1. The background is fairly static so it can be drawn once at the start of the game and doesn't have to be touched after that. 2. The background doesn't have to scroll. To do scrolling in mode E would require a lot of memory. 3. The eggs are fairly small so they can be erased and redrawn on the backgound quickly. 4. The eggs never have to pass over any of the other background graphics, thus making it much quicker to drawn them. Mode 4 actually has the same effective resolution as mode E. Mode 4 characters are 4 pixels wide X 40 chracters across = 160 pixels across. So mode 4 gives you the same resolution and colors as mode E, but since it's a character mode it's not quite as flexible in drawing graphics. Since most backgrounds can easily be reduced to a series of similar blocks (characters) mode 4 is a very good choice for most games. Dan [ 10-15-2001: Message edited by: Dan Boris ]

If I could choose just one game, it would be a sit down Star Wars, that was a great game, and you can't beat playing it in the sit down environment cabinet. Dan

You second question answers your first Any collisions that occur in a frame will set the appropriate collision bit which will stay set until you write to HITCLR. Since collisions can occur anywhere in the frame it's a good idea to check for them during VBLANK, then write HITCLR before the end of VBLANK. Dan

Ah, ok, I just changed how the color's where handled in mode F because Microgammon and Minature Golf (which both use mode F) displayed a blank screen. I took an educated guess at how the colors should work because I couldn't find it documented anywhere. How exactly is the color of the foreground determined in mode F? Dan

Display mode: I'll add back in the standard VGA mode in the next release. Mode F Color: I found the info I was looking for on this. The forground uses color register 1, but only takes the luminance not the color. I will also fix this in the next release. I also don't support the color artifacts at this point since it's a tricky thing to do. Might add this in the future Screen shots: VSS doesn't have a built in screen shot ability but if you run it from a DOS prompt under Windows you can use Print Screen. Dan

This one works better on VSS but it still isn't playable. I will have to look into it further. Dan

What mode are you using for your title screen? What part is the wrong color, the background or the image? Yes, it does uses a different mode. VSS .77 could run in standard 320x200 VGA mode or in 320x240 ModeX. VSS .80 drops support for the 320x200 mode (since a lot of games got chopped off in this mode) and just uses the 320x240 mode. Dan

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