DanBoris

One of the downsides to doing this in character mode is the problem of vertical movement. Since each character is 8 pixels high, you can only easily move the enemies 8 pixels at a time and this would look pretty clunky. To get around this you would have to define extra characters with the image half way into the character. This would run you into the problem of not having enough characters. To get an 8x8 enemy your would need two characters side by side. To support the 4 pixel vertical move, you would need 4 more characters, so thats 6 characters for each type of enemy. This only gives you movement in one direction. To have a enemy that can face four directions would require 24 characters. As you can see you could very quickly start running out of characters. On the plus side you can easily achieve animation with character by defining two or more character sets, one for each animation frame, then flipping between them. Not saying that the character mode is a bad idea, but you have to weight the downsides. Dan

Just checked out the 8-bit version and I have to say it's pretty impressive considering the limitations of the 8-bit hardware. Using the monitor in Atari800Win it's pretty easy to figure out how some of it works. As has been said, it uses Antic mode E which is the highest resolution 4 color bitmapped mode. Hscroll is set on each display list line, so it uses this to do fine horizontal scrolling, but since the is no LMS on each dlist the course scrolling must be done by a redraw. The player seems to be made up of Players 0 and 1 and Missiles 0 an 1. This would leave Players 2 and 3 and Missiles 2 and 3 for the second player. The enemies must be drawn as bitmaps. The move horizontally in 4 pixel increments because each byte of memory can hold 4 pixels this makes the drawing process much easier. They almost move vertially in 4 pixel increments. There's not good technical reason for this, but it probably makes the motion more consistend and saves processing time. Dan

First a question, was there an Atari 8-bit version of Gauntlet? I did a web search and the only thing I could come up with from Mindscape was an Atari-ST version along with a few other platforms, but not the 8-Bit Atari. As for how to get multiple moving objects on the screen at the same time, there are a few techniques, each with it's own pros and cons. 1. Sprite re-use. Since 8-bit sprites are the full hight of the screen it's an easy matter to change the horizontal position of the sprite between scan lines which would allow you to use the same sprite multiple times on the screen. Still can't do more the 4 sprites on a line. 2. Sprite multiplexing. Instead of displaying all the sprites at the same time, display 4 during one video frame, then another 4 during the next. Leads to some flicker but gives you 8 sprites on a line. This can also be combined with technique 1. 3. Draw the sprites in bit-mapped mode. This gives you an unlimited number of 4-color sprites but is very processor intensive. Atari 5200 Galaxian uses this teqnique for the enemies in formation. The movement of the formation is done with using fine scrolling so the enemies don't have to be re-draw until they break formation at which point I think they become player sprites. 4. Character mode graphics. This is similar to 3 but doesn't take up as much processing power. The downside is that it's hard to get total freedom of movement and sprites cannot overlap each other. Also, multi-colored sprites can be achieved without having to use multiple sprites. If you don't need multiple colors on the same line of a sprite, you can change the sprite color on different scanlines so the same sprite shows up in multiple colors. Dan

Probably not of the above! Looking at the technical specification of the Gauntlet hardware, it has very powerful sprite hardware. According to the specs it could display up to 56 motion objects (sprites) per scanline. Dan

It sounds like you are just double clicking a DASM icon to run it in, this will not work. DASM is a command line program and should be run from a DOS command prompt. Another option is to the command line with all it's options into a batch (.BAT) file which you can then double click to run. Dan

It would probably require a couple chips to achieve so you would be easier to build it on a seperate board that would still fix inside the cart. Yes, it probably would be that simple. You would turn on the LED when the collision happens, but the tricky part would be controlling how long the LED stays on so it's visible. You would have to leave it on for a few video frame or it would flash so fast you probably wouldn't see it. Dan

This should be doable but it would take some work. First you would have to modify the cart to add some logic to control the LEDs. The simplest way would probably be to take a set of unused addresses and create a circuit to recognize an access to those address and to turn each LED on or off. You could have one address for on and one for off, or maybe each access to an address toggles the LED. Since Combat is 2K you should have 2K worth of free addresses to use. Second you would have to modify the software to add the LED control to the part of the program that checks for obstacle collision. Since Combat has been disassembled this shouldn't be too difficult. Dan

Sounds like a problem in the video hardware. First thing I would try is to remove each socketed chip on the board (ROMS, RAMS, etc) and re-seat them back into thier sockets. If that doesn't do it you probably have a bad chip somewhere. Dan

Happ is a very reputiable company, you shouldn't have any problem with them. It's been a long time since I have ordered from them, but I would image it would give you a chance to confirm the final price with shipping before you submit the order. Dan

What kinds of problems are you running into? I don't see this as being to complicated. If the scanline where the DLI is needed doesn't change from frame to frame then you can just leave the DLI's set on those lines and the scrolling shouldn't effect it. If the DLI scanlines have to change between frames then is should just be a matter of going through each display list intruction during Vblank, and setting the DLI bit on the appropriate lines. Dan

I have just posted the first release of my latest project, SIM6502.NET. It is a generic 6502 system simulator/development environment for Windows. With is you can load 6502 code into the simulated systems memory, run the code, single step through it, view memory, disassembly, etc. It also has a simple built in line assembler. SIM6502.NET is based on Mike Murphys 6502 core from emu7800 and has also been released as open source. You can download it from here: http://sourceforge.net/projects/sim6502net/ I would like to add a lot more features to it in the future, just a matter of finding the time! If anyone tries it out, please let me know what you think. Dan

Both the NES and the 5200 only had a 32K window into the ROM cartridge, to make bigger games both systems had to resort to bankswitching. There is no technical reason why 5200 games could not have been as big as NES games. Also there is no actual upper limit to how big a cartridge can be using banks switching. Theoretically you could make a 32MB cartridge for the 5200. You would actually run into problems of physical size and power consumption before you ran into addressing issues. Dan

Check out an amusement auctions sometime. I went to an auction by this company, http://www.superauctions.com/, last week in my area and things where going for ridiculously low prices. I saw working arcade games go for $30.00, and non-working machines go for a $1.00! Last year I picked up 3 non-working cocktail table machines for a total of $25.00. Got two of them working with little trouble. As one of the other posters said, be careful what you are getting into with Pinball machines, there are a lot of things that can go wrong with them. I just finished restoring a 1974 Williams electro-mechanical pinball (and am now starting on another). It's very rewarding, but it's a LOT of work. Dan

The machine language itself is the same on both systems (6502), but it would be easier to get the C64 to do something meaningful, like displaying graphics, then it would be on the 2600. Learning to program the 2600 graphics hardware can be very tricky. Dan

On some games you can display the actual graphics sets. Just press F4 and then use the left and right arrow keys to change from the palette display to the graphics display. Use the up and down arrows to change the color plane. Dan

I didn't get to deep into commentin the display engine in Robotorn, but it does appear that it uses method 2, fixed display list regions. Each display list can be up to 128 bytes long. This method is effcient, but as Bruce pointed out, a big memory waster. Since each region would have to be worst case size, I would be you would end up with at least 75% of the memory not used at any given time. Dan

Could also be a RAM problem since the system doesn't use the RAM when it's in 2600 mode. Dan

Swordquest Water World: $1 Crazy Climber: $1 Dan

This may not work because the game can detect if a trackball or a normal controller is hooked up. Unless the game is constantly checking for this, which I think it unlikey, it's won't see the change and will probably not work properly. Dan

The BIOS wouldn't be a big problem since it doesn't do a whole lot in the 7800. The main thing it does (besides the Atari logo) is the cartridge validation check which wouldn't be needed if this was a 7800 only system. Another IP issue would be the 6502. Western Design Center owns the rights to the 6502 intellectual property so if you wanted to clone it and sell it you would probably have to pay them royalties also. Dan

Just when I am about to give up on my local flea market, it seems I always find something that makes the weeks of finding nothing worth while... Today as I was going through and I spotted a box with a 4-port 5200 sitting on top of it. I started digging in the box, which contained a bunch of common 5200 carts, badly broken 5200 controllers, a couple of TI computer cables, etc, and. . . ., a 5200 Joust Prototype Loner Cartridge! I really did want any of the other stuff since I have a ton of 5200 stuff, so I said to the woman at the table that I was only interested in one item in the box, which she wasn't to happy about since she wanted to unload the whole thing. So I asked how much she wanted for the whole box and she said $5.00! Needless to say I paid the 5$ and ran! Does anyone else feel bad about taking advantage of people's ignorance? Dan

Here is my calculation based on information in the 7800 programming guide: 456 Maria cycles per line -7 Start of DMA -9 DMA Startup (worst case) -13 DMA shutdown (worst case) ---- 427 Total left Lets assume 8 pixel wide, 4 color sprites: 8 Header 6 2 direct graphic reads --- 14 Cycles per sprite 427/14 = ~30 sprites per line If you did an 8 pixel, 2 color sprite: 8 Header 3 1 direct graphics read ---- 11 427/11 = ~38 sprites per line This is my interpretation of what is in the 7800 Software Guide and are highly open to debate! Dan

As someone who has written numerous emulators, here's what I suggest: 1. Good programming skills (as you said). Emulators are tricky to write so I don't recommend learning to program a new language and learning to write an emulator at the same time. 2. Technical information on the system you want to emulate. The more the better. You need to know the CPU it uses, how the IO functions work (video, audio, controllers etc) where everything is in memory, etc. 3. Software to run on the system. It's almost impossible to write an emulator without software to run on it, this includes "external" software from a cartridge or disk and internal BIOS software. 4. A strong desire and determination to do this. Emulator programming can be very frustrating at times, if you are a person who gives up on things easily, don't bother with trying to write an emulator. 5. A system (to emulate) that you enjoy. If you hate NES games, don't try writing an NES emulator, because you are going to be playing them a lot. 6. Time! 7. Time! 8. More time! 9. Even more time! Once you have decided to actually go ahead with a specific system you will also need to decide how much you will write youself and how much pre-exsting code you will use. For example there are open source CPU cores avaialble for most major processors, you may want to use one of these instead of writing your own from scratch. Hope this helps.

No, there is currently no way to bypass the enter key. It's a resonable request so I will add a command line option to do that on the next release. Dan