DanBoris

Bad sound doesn't necessarily make a game harder to play, but it can make it less enjoyable. I guess if you didn't grow up in that period it might all sound like crap, but there was definitely a range of quality in game sound even in the 8-bit era. There were definitely some games that had really distinctive and enjoyable sound. Dan

If you are not using Basic you can safely use $80-$D3, and if you aren't using FP then $D4-$FF should also be safe. Dan

I think you can find them all here: http://www.programmerfish.com/source-code-of-several-7800-games-released/ That site has source for Robotron, Xevious, Dig Dug, Centipede, Joust, Ms Pac Man, Commando, Crossbow, Food Fight, Galaga, Hat Trick, Sphinx/Nile Flyer/Desert Falcon and Super Stunt Cycle/Motopsycho. Dan

If it does nothing then start with the obvious, there is probably a fuse somewhere in the machine I would check that first. Dan

Do 7800 cartridges work?

My father was actually a manager at the Franklin Mint around that time. A few years ago I asked him about the Swordquest prizes. He didn't have any memory of them, but indicated that since these were one off items it's likely that the mint didn't produce them directly but farmed the work out to one of the craftsmen they worked with in New York. Dan

Looking back at my notes from my 5200 emulator this looks correct. The only difference is that I map ANTIC from D400 - DFFF. As you point out Antic decodes it's own address, so I am not sure if I had a reason to believe it was accessible beyond D4FF. Dan

You guys rock! Thanks! Yes, "AAb = $1338" was a mistake, $0668 is the correct value. Dan

I need some help figuring out something, and thought some of the people here might spot whatever I am missing... I'm playing around with decoding the format of the MSDOS Adventure Construction Set game files. Some of it has been pretty easy to figure out but when I came to the object names I found out that they were compressing this text, but I can't quite figure out the logic. Here is what I know: - Each character can be one of 40 characters (26 letters, 10 digits, and 4 symbols) - Every three characters is encoded into 2 bytes - Here are some of the encodings I have seen, showing the character, hex values and binary values: 1 = C0 A8 11000000 10101000 A = 40 06 01000000 00000110 B = 80 0C 10000000 00001100 C = C0 12 11000000 00010010 D = 00 19 00000000 00011001 E = 40 1F 01000000 00011111 F = 80 25 10000000 00100101 A = 40 06 01000000 00000110 AA = 38 13 00111000 00010011 AAA = 69 06 01101001 00000110 ABC = 93 06 10010011 00000110 Anyone have any ideas on this?

You might be interested in checking out my blog http://www.atariage.com/forums/index.php?app=blog&module=display&section=blog&blogid=52&. I have done a bunch of posting that analyzes the machine code generated by various blocks of Action! code.

I just posed to my website schematics for the Voice that I put together a while back. According to these schematics the cartridge signals do pass directly through the module. http://www.atarihq.com/danb/o2.shtml I like the idea of building the voice directly into the base unit. Let us know if you get it working. Dan

The issue is copyrights. The copyright to every arcade game ROM is technically still owned by someone or some company. It doesn't make a difference whether the copyright holder is making any money off it they still own the copyright and thus have to give permission for the game to be distributed. Emulation itself is technically legal, it's the distribution of the copyrighted roms, whether you are making money off them or not, that is illegal. Dan

Ok, I'm just giving my opinion as the original creator of the header format. I am not going to try to stop anyone from doing this if they really want to. As for an emulator with a debugger, I have always wanted to take EMU7800 (http://emu7800.sourceforge.net/) and combine it with all the debugging capabilities of my 6502SIM simulator to make a really nice emulator for developers. Unfortunately it's one of those project I just never seem to get around to doing . Dan

I don't have an objection to including simple header features when a game is actually going to be released that needs it, but I don't like the idea of having "infinitely configurable" hardware defined in the headers. You are talking about adding bits for flexible memory, but what if I want the flexibility to put a POKEY anywhere in memory I want it, or maybe two POKEYS, etc, where would you draw the line. The header could end up getting very complex. I think the emulator authors can build that kind of flexibility into the emulator so developers can play with various configurations that a cart might support, and then add it to the header when they have settled on the scheme they want to use. Dan

I disagree with adding this to the header since all these different configurations won't necessarily show up in an actual game. Remember that the header is not just for the convenience of using images with an emulator they are also there as historical documentation. For that reason I don't like the idea of providing features that may never be used in a game. If we start down this road we could end up with all kinds of bits in the header for special hardware configuration that may never get used. If you want to have and emulator support this as a configuration option that is fine, but I don't like the idea of putting it into the header. Dan

Strange, never got the PM. Yes, this seems like a good idea to me. If you decide to go ahead with this let me know and I will "officially" document this on my web site. Dan

I have a lot of information on the 2600 and 7800 on my web site http://www.atarihq.com/danb/ along with links to a lot of other good pages on the 2600/7800 hardware. There are also good 2600 and 7800 message boards here at Atari Age frequented by a lot of knowledgeable people who can answer any specific questions you might have. Dan

I was just looking through some of the ANALOG magazines and noticed an article reviewing a couple game written by Marc Russell Benioff. I wonder if this is the same person who is now Chairman and CEO of Salesforce.com?

I had a situation like this once. Five or six years ago my local mall had a laser tag place which had been there a while but I never had any real interest in checking out. One day a friend of mine mentions that they have a small room in the back with a bunch of classic games. So I go back there and although I don't remember the titles, there were a bunch of good games. Within a week or two of me discovering this the place shuts down! Needless to say I was pissed! Dan

Here is one of the best sites I have found for Pinball machine repair and refurbishment information: http://www.marvin3m.com/fix.htm I have found this to be a good site for parts: http://www.marcospecialties.com/ Dan

Yes, there is a Racing Destruction Set. There also was an unofficial track editor for Pole Position. Adventure Creator was by Spinnaker and there was also Adventure Master by CBS. Someone earlier mention EA's Adventure Construction set, but this was never released for that Atari 8-bit. Dan

These articles by Chris Crawford eventually became the basis for the book De-Re Atari. Dan

Once you are in the debugger, just type HELP, it has extensive built in help. Dan

Yes MESS has a very nice debugger in it. You can single step, trace to a file, view/edit memory, set conditional breakpoints, etc. Dan

Let's take a break from looking at Action! math and take a look at procedure calls. We will start up with something that is trivially simple: Proc test() Return Proc main() Test() Return 0E61: 4C 64 0E JMP $0E64 0E64: 60 RTS 0E65: 4C 68 0E JMP $0E68 0E68: 20 61 0E JSR $0E61 0E6B: 60 RTS Our main procedure starts at 0E68 and it begins with a call to procedure Test using a JSR. The procedure Test starts at 0E61 which immediately jumps to the RTS since the procedure is empty. What I haven’t been able to figure out is why the JMP instruction is there since it doesn’t jump over anything. I have yet to find a case where it actually jumps over something. Next let’s look at how simple parameter passing is done: Proc test(byte I) Return Proc main() Test(1) Return 0E88: .BYTE #$00 0E89: 4C 8C 0E JMP $0E8C 0E8C: 8D 88 0E STA $0E88 0E8F: 60 RTS 0E90: 4C 93 0E JMP $0E93 0E93: A9 01 LDA #$01 0E95: 20 89 0E JSR $0E89 0E98: 60 RTS This is the same as the first example, but now we pass a single BYTE parameter to the procedure. Here is an area where Action! does a good job at optimizing. Since there is only a single BYTE being passed it uses the most efficient way possible, it just passes it in the accumulator. At 0E93 the value 1 is loaded into the accumulator then the procedure is called. At 0E8C that value passed is stored in the local variable I. You will notice that space for this variable is allocated before the start of the procedure code, so this doesn’t answer the mystery of the JMP instruction.