DanBoris

Looking at the release history there were four releases last year and five the previous year which isn't very much for a community project like this. Back in their heyday MAME and MESS would often do a release every month. Looking at the release notes I see numerous fixes in each release. For example version .145 fixed issues with the C64, Lynx and N64 among others. As to why it is based on MAME, they are both multi-system emulators, MAME does arcade games, and MESS does consoles and computers. There is a lot of functionality that is common between emulating arcade games and emulator consoles/computers so MESS and MAME share a lot of the same code. A big benefit of this is that if something is fixed in one, it can benefit both. For example if someone on the MAME team fixes an issue with the 68000 CPU emulation code, the consoles and computers in MESS that use the 68000 also get the benefit. As for the 5200 button emulation, the code that makes the second button work is in the driver but is commented out. Based on the notes in the driver it appears that fixing the 5200 button broke something in the Atari 8-bit computer emulation (the 5200 hardware is almost the same as the computer so they are part of the same driver.) I need to study this code a little more to figure out how to properly fix this issue.

I just looked at the MESS code and it appears to support both fire buttons. What 5200 games use the buttons for separate functions?

The issue was that he was doing a LDA $04,X instead of a LDA #$04. The LDA $04,X was reading from location $04 which is the TIA collision register. It just happened that the value it got on the real hardware and on most emulators worked in this case, but MESS on the other hand was returning a value that didn't work. To be provide truely accurate emulation MESS should return the same value as the real hardware, but I am not sure what that should be.

There are also some things that are only emulated in MESS. For example the Entex Adventurcision can only be found in MESS. I am also guessing some of the more obscure computers are only emulated in MESS.,

I know Any chance, if not under the MESS code, you would revisit 7800 emulation perhaps in an update to V7800? Seriously though...Thank you Dan, I've said it through the years, but still have to continue to mention it. If it weren't for you and your V7800 emulator, MESS would likely contain little to no 7800 emulation. Your contributions - including areas outside of the 7800 are greatly appreciated. If I were to continue work on 7800 emulation I would do it in MESS. My v7800 emulator has just fallen to far behind.

Even though there are a lot of people on the MESS team, each system drivers tends to be "owned" by a single person who works on it. If they loose interest in it someone else may or may not pick it up. I am personally guilty of this, I haven't toched the 7800 driver in ages.

Hmm... I think ERROR 5 is an emoticon math error. Actually, it looks like it's going beyond the dimensioned length of S$.I am going to take a wild guess and say that in line 290 I am betting that the "1-" in line 290 is wrong.

If you are looking for a Infocom game interpreter to play games you can check out Frotz which is available for many different platforms.

Did you use the installer or just the update? and which windows OS? Jay I found the problem, I needed to run it as administrator. I noticed you create the atari.fon file in the program directory. Under Vista, and I think Windows 7, programs can't write to the Program Files directory without permission. That's what was causing the rror.

When I run it I get a Path/File Access Error.

Here's a few more: C# C64: http://sourceforge.net/projects/sharp-c64/ C# Spectrum: http://sourceforge.net/projects/cse/ C# Gameboy: http://code.google.com/p/crystalboy/

I did some Action! programming "back in the day" and I think it's a really nice language. The development environment is very easy to use and the code compiles quickly. It produces some pretty efficient 6502 code, although not as tight as hand coded assembly. You can also easily make calls to machine code from Action! if you want to.

I am not entirely clear what your question is, and for a proper answer I would need to know what Basic you are using on what kind of system. If you are asking about collision detection, then the simplest way is to determine the coordinates of a sqaure that encloses your "thing" and compare this to the coordinates of a square that encloses your dot to see if the two squares interesect. If they do, then increment your score. Dan

The MESS emulator has a very nice debugger, but it's not included in the standard build, you would need to download the MESS source and build the debug version. I've always wanted to graft my 6502SIM debugging GUI on EMU7800 but it's just one of those project I have never gotten around to doing. Dan

You are correct, the GTIA an POKEY chips are at different addresses in the 5200. The sticks would be tricky since they appear to the system as analog paddles, instead of the normal digital joystick on the 400. The other thing that the 5200 is missing is the PIA chip which is involved in the control of the SIO port on the 400. Finally you would need two different BIOS roms since the 400 has a much significant BIOS then the 5200. Dan

It's the right gender to attach Apple IIc/IIe sticks though. Check out the connector on these Apple paddles. Not sure about the other one. Maybe it connects to a PC game port? Ah, ok. Yes, the top one might be a for a PC game port, it's the right type of connector. I am guessing the bottom one is for connecting the Apple IIc style controllers to the older Apple II controller port. Dan

The top one has the wrong type of connector for connecting a 2600 joystick, it would need to be a 9-pin male instead of a 9-pin female. In theory this could be used to connect a 5200 controller to a 2600 console, but I am not sure why anyone would want to do that. The connector on the bottom one is right for an Apple II controller, but again the other connector is the wrong polarity for connecting a 2600 stick.

Yes, very likely he transposed the numbers, v1.18 is the latest I know of.

The 2600 driving controllers are digital, they output a 2 but grey code as you rotate them. The 5200 trackball is digital internally, but the signals are converted to analog so they can interface to the 5200's analog controller port. The speed of rotation of the ball is converted to voltage output, so the speed of the ball would correspond to how far you are pushing the normal joystick. The Tempest arcade controller is digital and is read with a pair of opto-interrupters similar to the way a mechanical mouse works. Dan

It's a Unimex duplicator. You can find some information about it here. Dan

but what exactly ramps up in advanced? I took a quick look at the source code and only saw two things that the difficulty effects. The first appears to be how fast the food that the chefs throw moves. The second appears to be that in the beginner mode the chefs will not sit on a pile of food and keep throwing it. Dan

I have this issue. I'll PM you where you can get the scans. Dan

The game Shamus actually does this with mode 4. Here is a dump of the video ram during the game play. The game dynamically alters the character set to achieve horizontal movement, and it appears to re-use the same set of characters for each sprite that is moving. It does not handle vertical movement dynamically, so it has a different set of characters for each step of vertical movement. Animation appears to be handled by redrawing the characters. This of course imposes a bunch of limitations that you can see if you watch Shaums closely. Sprites need to move a full 4 pixels horizontally or 8 pixels vertically before they can change direction, so you can't do smooth diagonal movement. Sprite also can't always be right next to each other. For example if I have two sprites one above the other both fully within their character cells and the bottom one moves down, you have to wait for it to move all 8 pixels before you can start moving the top sprite down. 0/0/0/0/$#######################$/ ‘.$ $0 ¦¥$ $/ /0/0/0/0$DE DE $0/0/0/0 ..$FG FG $/0/0/0/ &%$ $0/0/0/0 0/0/0/0/$ ËÌÍ $/0/0/0/ ########$ $#######$ $####### $ ÄÅ $ $ . $ ÆÇ $ $ . $ @A $ $ . $ BC $ $ . $ $ ÄÅ $ . $ $ ÆÇ $ . ################$ $ $####### 0/0/0/0/$ ËÌÍËÌÍ $/0/0/0/ /0/0/0/0$ $0/0/0/0 0/0/0/0/$ @A $/0/0/0/ /0/0/0/0$ BC $0/0/0/0 0/0/0/0/$ $/0/0/0/ /0/0/0/0$ $0/0/0/0 0/0/0/0/$#######################$/0/0/0/

No. No way possible, or no because it wouldn't have been the same 7800 (and different to develop for?). I realize you have done some pretty impressive things with the 7800, which indicate that the weak game play in some early games could have been programming issues. However, with stronger hardware backing Maria up, one wouldn't have as much to overcome. Someone with your talent could have come up with tempest 2000 on it (since somebody's already done a decent job of doing that on the regular 8-bit). Would more memory allow better use of the 320 modes? The 5200 cartridge port doesn't have the necessary signals coming out to it to allow this sort of addon. Dan

Looks like you are off to a good start. Emulating the 2600 is really tricky because you have to be so precise with your timing. One thing to remember about the RIOT timers is that they count down based on the interval, but when it reaches the end of the count and rolls over, it starts counting down again at an interval of 1.