procyon

Beautiful work, thank you so much for pouring your time and energy into this. I searched through the topic thread before writing this, but I didn't see anything about this, so I thought I'd mention it here. Most of the RCs don't seem to be very happy when run in MAME in conjunction with the XM cart. Doing so results in a yellow screen displaying: 36.02.40.00.00.00.00.00.00.00. I doubted this was intentional, so I just wanted to share this discovery. I found this out because my default method of loading any 7800 game in MAME is: mame a7800 -cart xm -cart2 popeye.zip Couldn't get passed that until I ditched the xm portion. Apologies if this was already known.

I have one of these (got a second one on the way.) I can only recommend it after having ditched the stock firmware for a custom firmware that people are developing over at the dingoonity forums. The custom firmware gives a much better experience, adds a few system emulators (although it currently takes one away, Genesis, but that's being worked on) and allows zipped roms which the stock firmware doesn't. It's not great, and it's not nearly as powerful as a GPD XD, but it's a fun little toy for the $70~$90 that it can be found and had for.

Omg, cool! I've never met a fellow StrategyWiki editor on here before. That's awesome

Lol, you could have just linked to where all of that Ms. Pac-Man information came from: https://strategywiki.org/wiki/Ms._Pac-Man/Home_version_comparisons I'm the guy who put most of that page together

Nothing is wrong. It's using the Japanese version of the ROM. Those were Namco's official names for the monsters in Japan.

I don't have time to properly respond to everything that's been said here, but I think Kurt's approach is WAY too complex for what the 7800 is capable of, and too complex for what can realistically be achieved. There are a few things that Bob needs to put in place in order to reduce the amount of work the system needs to do in order to pull this off, and some "realistic physics" is going to have to be sacrificed. The screen needs to be broken up into grids. Collision should only be checked against something that occupies the grid that the ball is currently in. Depending on how granular you make that grid, and how much processing time you need, you can check four grids: the one the ball is in, as well as the three grids in the approximate direction of the ball. e.g. If the ball happens to be travelling up and to the right, the grids you would check are the ball's current grid, the one above, the one to the right, and the one above and to the right. That significantly cuts down on the number of collision checks you need to make. Any area that's enclosed, like the FRUITS and TUNNEL portions, that should put the ball on rails. Don't bother processing collision for the ball at that point, just take the current speed that the ball has and run it through a predetermined, precalculated vector. That will definitely keep the ball from getting stuck, and cut down on the amount of work you need to do. Trying to send the ball through those rails with realistic collision and physics is going to drive you nuts, especially when you start debugging it. If you want to cut down further processing at the expense of memory, you can have a second representation of the playfield, strictly for collision, with everything expanded outward by the radius of the ball. That way you're only processing collision at the point of the very center of the ball. You don't want to have to extend a collision vector in a variety of directions to see if the ball happened to bump into something, especially in a direction other than the one it was travelling. Your representation of the collidable playfield should allow you to treat the ball as a single pixel in size. Obviously this needs to be achievable first, and then improved upon in later iterations. Don't go for perfect on the first pass. Go for feasible. I'm speaking with experience.

PMP, are you still looking for any kind of assistance with the pinball physics? I only have a little experience in assembly, but I've done a variety of collision physics systems for games in C++, so I can at least explain what you're shooting for in an algorithmic, potentially object oriented way. Please let me know if I can lend a hand in any way.

Hi Bob, been following the thread with great interest. I understand your desire to implement the pinball controls based on Video Pinball, but please allow me to provide some arguments for at least giving players another option. One problem with the Video Pinball setup is that it makes it rather difficult to flip one flipper, and then another start the other flipper going up before the first flipper finishes going down, and that becomes integral to some pinball strategies. To do this with the Video Pinball controls, you have to quickly rock the joystick from one direction to the other. It's possible, but it doesn't feel nearly as natural as tapping one button, and quickly tapping the other button in rapid succession. One reason Video Pinball has the controls that it has is because the Atari 2600 only had one button. The 7800 has two. It would be unfortunate not to leverage that fact. Additionally, some players like to play with a Genesis controller, or they emulate the 7800 where a traditional gamepad is an option. That gives you the possibility of using the NES Pinball control scheme, where any direction on the d-pad flips the left flipper, and any button flips the right flipper. This scheme also allows for easier "multi-flipping" where both flippers are going, but slightly off-timed from one another. I'm not saying I couldn't play the game with the Video Pinball scheme. I would just enjoy it much more if I had the option to use either 7800 button, or something akin to the NES Pinball controls. Ultimately, either way, I will be grateful for your efforts. Thanks for listening.

No! I have not. What's the source for all this? Thanks.

I bought the My Arcade Pac-Man Micro Arcade machine today (along with 3 others). Just a fun fact worth pointing out: they used the Japanese version of the ROM. The ghost names in the attract mode are not the American versions.

I was trying to capture the artwork of the rounded ground on the bottom. Natually I don't expect to be able to reproduce the curvature of the surface, but the artwork clearly puts the cannon and the shields below the horizon. Here is another screenshot, this time of the SNES version which is recreating the arcade backdrop artwork. What's interesting about this depiction, is that it similarly uses bands of gradiants to darken the sky as it goes higher.

Hi all. I had an idea that's been stuck in my head for a week now, so I thought I would share it. "Space Invaders Arcade" is one of my all-time favorite hacks, but I was thinking about the version of the arcade game that projects the image onto a backdrop artwork. I was wondering if it were possible to marry the SI Arcade hack with the kind of background present in Air Sea Battle, in an attempt to recreate the backdrop version of the arcade. Since a picture is worth a thousand words, I'll just describe what I was thinking in pictures: => + = Would something like this be possible? As a bonus, the Color/B&W switch could be used to toggle between the backdrop version and the "vanilla" black space version. I lack the skills to develop something like this. Would anyone be interested in taking up the challenge?

I'm very grateful for all your effort to fix the issue. I pulled down the deb and installed it. Both the delay and the seg fault are gone. I did have one issue with this build, and one wish list item. The issue I had was that the video on this build was extremely washed out. Like someone poured bleach on my screen. I don't have that with my normal 3.1.0 build, but I build it from source, so maybe that's the difference? My wish list item, if anyone would like to tackle it, would be the have the ability to map Start, Select, Option and Reset to my joystick. I know I can get around it with a joystick to keyboard mapper, but if that functionality could be supported internally by the software, that would be awesome. I would especially love that in Colleen for Android, in order to avoid needing to tap on the screen to bring the buttons up. Again, just a wish list, I know it's a big request. Thanks so much again!

Oh awesome, thanks for the reply. Here are my answers: 1) procyon@MSI-GS60-6QE:~$ atari800 --version Atari 800 Emulator, Version 3.1.0 2) F4/F3/F2 are all unaffected. F1, F5 and F9 are. 3) So unfortunately, the only other USB joystick that I had available to test besides a Dualshock 4, was a Dualshock 3, and yes, it exhibited the same behavior, but that's probably not surprising. I'll see if I can find a different type of controller to test with. 4 & 5) To my surprise, using -nojoystick caused a Segmentation fault: procyon@MSI-GS60-6QE:~$ atari800 -nojoystick Using Atari800 config file: /home/procyon/.atari800.cfg Created by Atari 800 Emulator, Version 3.1.0 no joystick Video Mode: 1920x1080x32 fullscreen, pixel format: BGR16 OpenGL initialized successfully. Version: 4.5.0 NVIDIA 361.42 OpenGL Pixel Buffer Objects available. Segmentation fault (core dumped) Please let me know what other information I can provide.

Hello. I'm having a weird problem with the atari800 emulator, and I don't know where else to turn. This problem has more to do with the environment that I'm running the emulator in than anything Atari specific. To begin with, I'm running atari800 in Ubuntu. When I'm in the emulation, I use the number pad and right Ctrl as the joystick, and this works perfectly well. The input is responsive and near-immediate. However, all other keyboard input is incredibly slow and delayed. It's as though it's going through a buffered delay. I can type really quickly, and the letters won't appear until 3 seconds later, but as fast as I originally typed it. This problem extends to the configuration menu. Even pressing F1 to enter the menu goes through this delay. Then I can, for example, tap down, down, down in rapid succession. The program will wait three seconds, and then just as quickly move the menu selection down three times. I don't really understand what could be causing this problem, as I don't have a similar issue in any other emulator. It's also odd that joystick input is not affected by this problem. Can anyone shed any light on this problem? Or point me somehwere for assistance? Thanks very much. UPDATE: Just discovered that it has everything to do with the fact that I have a Dualshock 4 plugged into my laptop. When I remove the joystick and restart the program, the delay disappears. So my problem is semi-solved, but it's still perplexing. Does the emulator author read this forum, or respond to bug reports? Thanks.

I was the author who contributed that picture to StrategyWiki (and basically wrote most of that Galaxian guide). If you want that version, make sure you download KevinMos3's most updated version on his hacks thread: http://atariage.com/forums/topic/154984-hack-project-thread-galaxian-arcade-double-dragon-xenophobe-etc/

OK, I got exactly what you printed, and -cart2 is working as expected. Originally, I did not have xm.zip in the right location. However, that being said, when I execute the command: mess64 a7800 -cart1 xm -cart2 dkxm_final_demo_ntsc.a78, I still do not get proper sound, but rather feint crackling. Trebor, I assume you _do_ get proper sound when playing this ROM through MESS? What bit/OS version are you running? Based on RevEng's analysis, is there any hex editing magic I can do to the header to fix things? Thanks for your assistance.

When I try this, I get what frogstar_robot initially got: Error: unknown option: -cart2 Like I said, this is with the latest MESS source from GitHub, although I doubt the command line syntax has changed recently. Any suggestions?

I would love some help with this. I'm having the same problem that frogstar_robot had. I run Ubuntu, and I built the latest version of MESS from the GitHub. I have all the files in the right place, but no matter what I do, I can't get the POKEY sound to work when I try to run DKXM. I always get: POKEY + Bank 0 of 144K ROM at $4000 (Header 0x09) Disabling POKEY By contrast, if I try to run the Pac-Man Collection with POKEY sound, it works fine. I'm using the bioses contained in Trebor's original post. Any suggestions? Edit: More info. What I notice is that if I run: mess64 a7800 -cart xm then POKEY is listed as part of the system's sound components. But if I then choose the dkxm_final_demo_ntsc.a78 file, or if I run: mess64 a7800 -cart xm -cart dkxm_final_demo_ntsc.a78 then POKEY is removed from the sound components, and only TIA is listed. I tried both dkxm_final_demo_ntsc.a78 and dkxm_final_demo_ntsc_htc.a78 with the same results.

RT: That's okay, it's just as well. This clearly was not the best approach that I could have taken, and I wish I could retract my second post. For what it's worth, while we are asking for "free" content, and make no attempt to hide that fact, we also take no ownership of the content either. If you look at the licensing on the site, we operate under CC BY-SA 3.0, so all contributed content becomes part of the public domain. That even means, if AA became so inclined, they could import the content from SW directly on to this site, provided they followed the attribution rules specified by the license. There are other sites out there who do claim ownership of your contributions, but we are not one of them.

RT: Point well taken, I see what you mean. I meant in the general sense that someone who knows anything about Atari 2600 games is an expert compared to the general population. I don't suppose it's possible to alter the title of the thread? Trent: We're aware of the pop-up ad situation and trying to work with our advertisement agency to remove them. That actually only started recently and we weren't told about it in advance (naturally).

OK... these responses took me a bit by surprise, but I'm taking them at face value. StanJr, I had no intention of making any kind of backhanded slap to any member of this community. I was genuinely unsure if I had posted my request in the correct place based on the lack of response I initially received. I apologize if my second post insulted anyone. Trent, we're clearly not AtariAge, and we don't have a store to support the site. The ads help keep the site running. Without them, there'd be no StrategyWiki. Most importantly, StrategyWiki is in no way trying to compete with this site, Digital Press, or AtariProtos. Not even remotely. Our competition is sites like GameFAQs.com. We're trying to record and preserve actual game play information, everything and anything there is to know about how the games were played, strategies to get the best scores, easter eggs, etc. I have always seen sites like Atari Age more about preserving the history of the physical media (who created what, when and how many). While we may incorporate information like that wherever it's practical and relevant, it's not our core focus. That's the huge distinction between AA and SW. Anyway, I apologize if I sounded pushy, I was very eager for feedback, and hopeful that some members of this community would let us know how well game play information is presented, and how to improve that presentation. It never occured to me that anyone would think that AA and SW were trying to occupy the same space on the internet. Thanks anyway,

I'm only going to bump this topic just this once, because I was really hoping for some kind of feedback. I assumed this would be a good place to find people who genuinely enjoy Atari 2600 games, and who could provide expert opinions on how we're doing at presenting information. If there is a better forum for fans of Atari 2600 games, could someone please direct me to it? If not, I would greatly appreciate any thoughts that you could share with me about what we do well, and where we could improve. Thanks very much for your time.

Part of what you have to do to understand Tod's thinking is put yourself back in 1982, and remember how Time Warner was running Atari around that time. Atari wasn't a place where programmers strived to create the highest quality programs ever created. If you wanted to do that, you went to Activision or Imagic. Programmers were cogs, not people, part of a machine that was designed to pump out widgets that made execs and investors a lot of money. Tod was the first to receive royalties, but until you get a check for a million dollars, it's kind of hard to imagine how that's going to feel. When the execs told him to polish up the game and make it sellable, he probably just shrugged and followed the order, regardless of how idiotic it sounded to him. It's very easy for enthusiasts like us to think that if we were in Tod's position, we would have tried harder, and fought against stupid business executives who didn't know a joystick from a door knob. I didn't get to know Tod for very long (about a year or so), but he was who he was. He was a brilliant guy who just wanted to solve difficult problems. He didn't care what you thought of him, or what you thought of Pac-Man or Swordquest or anything else he did. He knew what he was capable of, and he knew what he was paid to do, and he didn't equate the two. In a way, I kind of admire him for that.

I may have mentioned this once or twice in the past, but I had the luxury of working with Tod Frye at 3DO just before the company vanished. He told me quite a bit about developing Pac-Man, and why certain decisions were made. It largely came down to the fact that his manager was a prick. He actually had a version where the ghosts didn't flicker, but his manager was so patronizing that Tod didn't bother submitting the flickerless version. At first, he developed his version as a proof-of-concept prototype to show that something like Pac-Man could be done. He never intended for the prototype to be the foundation for the actual game, but when the execs saw what he had done, they told him to polish it up for sale. And the rest was history. It's been several years since I spoke with him, but as I recall, he wasn't the least bit upset about how it came out. He made his millions There's also the story, which Tod tells himself on HSW's excellent "Once Upon Atari" DVD, where someone grafittied the Pac-Man machine in the Atari break room by writing "Why Frye?" on the machine, lamenting how much money he made on that port. So Frye took a pen and drew a line over "Why" which mathematically means "not" so that the quote read "why not Frye?" That ranks up there for me with Frye's fire sprinkler induced head gash emergency room story.