jaybird3rd

Yes, you should change both of these occurrences of $C000 to $E000, because MAME will disregard bank switching writes below $E000. Since your code resides in ROM, you don't have to worry about overwriting it.

Using a hex editor should work also (as long as you are editing the correct bytes!). While you're revisiting your code, however, you should also check to make sure that you are performing the bank switching by writing the bank number into a target address in the upper 8K bank, at $E000 or above. The original SuperCart permitted bank switching writes into either bank, but that range is restricted to the upper bank with the SuperCart II, which MAME emulates (because I wanted to make the lower bank available for writable storage). So, if you're writing to a target address in the lower bank, simply change the code to write to the upper bank instead; this should only require changing one byte for each occurrence of the target address.

Yes, that sounds like the correct ROM layout; in the 8K bank switching mode, the SuperCart always maps the last 8K bank of the ROM into the $E000-$FFFF range. (If it doesn't seem to work, check to make sure you are using the correct cartridge header in the last bank for 8K bank switching. On real hardware, it wouldn't make any difference as long as it's a valid header, since the jumper settings on the cartridge board determine the bank switching mode. The emulator must use the header to determine the mode, as documented here.)

The 5200 still got several 8K games, but I just took a quick look at my image collection in Altirra to compare the games that were released on the 400/800 and subsequently re-released in improved versions on the 5200. Each of the games I checked seems to have gotten a ROM size increase. For example, Centipede, Qix, Space Invaders, and Pac-Man were all 8K on the 400/800, and 16K on the 5200. Dig Dug on the 400/800 was 16K, and 32K on the 5200*. I can only imagine that the extra ROM space was one of the factors which made the improvements possible; as you say, I'm sure the added experience helped, too. Both the 400/800 and (prototype) 5200 versions of Asteroids are 8K, but as we know, little about Asteroids was changed in the conversion. * EDIT: 5200 Dig Dig is an interesting case. As you documented here, the 1983 version of Dig Dug was released for the 5200 and for the 400/800, replacing the 1982 original on the 400/800. The 400/800 versions were both 16K, yet the 5200 image that I have appears to be 32K. (It doesn't seem to be just an overdump, either; the two halves of the image are not identical.) I haven't looked at the image closely, so I'm not sure why the 5200 version would need to be so much larger.

I don't think I've ever tried ROMs of that size in MAME, so it might require the ROM images to be at least 16K (since that's the size of the cartridge window in the Aquarius memory map). You might try concatenating copies of the ROMs together to make a 16K image.

I'd love to see an improved Asteroids for the 5200. Something similar to the 7800 version, complete with support for four simultaneous players in cooperative and competitive modes, and with flexible control options (joystick, keypad, etc.). The "3D Asteroids" graphics demo that Tempest posted earlier seems to indicate that someone at Atari was thinking along similar lines. (It probably couldn't be quite as colorful as Asteroids on the 7800, but that might actually be a good thing. People who don't like the red and green asteroids in the 7800 version always say that they look like meatballs and Brussels sprouts floating in space.)

(I didn't want to sideline this thread any more, since it's supposed to be a thread about AquaLite and not MAME, so I moved the recent MAME-related posts into an existing thread about Aquarius emulation in MAME.)

I'm away from my development workstation, so at the moment I'm afraid I don't. What size are the ROM images you are trying?

^ Certainly. If anyone wants to update a previous post, just report the post in question to the moderators with a request to open it for editing. (If you want to edit multiple posts, include links to each post in your report; you don't have to file a separate report for each.)

You don't have to open the controllers. If there are any calibration issues with the console, they would need to be fixed inside the console, not the controllers. I maintain that the problems you're experiencing can be fixed with changes to the software. If some games work better than others with your controllers, it is because they are interpreting the controller input differently. (For example, some games may be more "forgiving" of minor miscalibrations or accidental changes of direction because they have more of a "dead zone" at the center of the stick's range of motion to mask these changes out, or they may be correcting for them in other ways.) These input handling routines are specific to each individual game; they are not built in to the console. A complete conversion of the 400/800 version of Asteroids would have included new routines and controller mappings that were more appropriate for the 5200, but of course, the version of 5200 Asteroids that we have is not a complete conversion—it is a prototype, and presumably somebody at Atari didn't think the inputs worked correctly either, because it was never released. Re-porting the 400/800 version "from scratch" would only get you another incomplete conversion, and then you'd have to tweak and fix the controls anyway, so one might as well fix the version of 5200 Asteroids that we already have. (Or, take full advantage of the larger cartridge capacity of the 5200, and put that effort into creating a better version of Asteroids instead. Remember, the 400/800 version was limited to an 8K cartridge—and within those limits, I always thought it was a decent enough approximation of Asteroids—but a version created specifically for the 5200 would not need to be constrained by those limits. One of the reasons that 5200 Centipede is so much better than 400/800 Centipede, even on equal hardware, is that the programmers of the 5200 version had more ROM space to work with.)

Do you mean cartridge binaries? You can attach them through the main menu. Press SCROLL LOCK to toggle the MAME UI, then press TAB to open the menu. I don't have a MAME machine within reach at the moment, but I believe that the cartridge port is configured as a slot device.

Well, I don't think we know for sure that Frye himself was involved in the conversion, but that aside ... perhaps it would be helpful if you made some more specific notes about what exactly you'd like to see changed. (Re-mapping the controls to the keypad, widening or tightening the "dead zone," etc.)

Why would it be necessary to "re-port" the entire game? It sounds as if your control issues could be fixed with a few tweaks to the 5200 version. (And yes, let's try to keep the conversion request threads under control.)

The label clearly seems to have been transplanted from an original Activision shell, after it had already taken some wear and tear, so it would not have been made this way by Activision. You can see the indentations left in the label from the two original screws; there are no screw posts at those locations in Atari's shells, which have only one screw in the center.

I hope to develop a lot more, but unfortunately, my plans are more abundant than my free time. I have some hardware projects in the works, and I hope to at least get a game under way before the year is over.

Yes, it was added only recently, with version 0.227. In case you need it, I posted an updated ROM set here.

I'm glad you've found it useful! Recently, support for SuperCart bankswitching was added to the MAME emulator. I haven't yet tried AquaLite, but I hear great things about it, and of course I'd love to see it support the SuperCart also!

Thank you! If you need more information about how the SuperCart bankswitching works, for 1MB ROMs and other sizes, see here. (It's nothing complicated; most of the work is done by a 74LS374 and a 74LS245.)

@Sugarland: I granted edit permission to your post in this thread (the second post), so if you wish to edit it, you should now be able to do so.

A few price-related notes from the ICWhen.com archives, including the original MSRP of the JagCD: "Tuesday, March 21, 1995, Atari announces a new low price for the 64-bit Jaguar game system of $159.99. The new price is on a system without the CYBERMORPH game cartridge which was packed in Jaguar systems selling between $189 and $249 previously." "April 1995: Atari Corporation announces hopes to have the CD-ROM peripheral for the 64-bit Jaguar to stores in June for $149." "May 1995: Atari Corporation reduces the price of the Jaguar core system to $149." "On the evening of Wednesday, December 13, 1995, a fax is sent to all Atari Rep Firms and Distributors announcing a new low price point of $99 for the Atari Jaguar." "On Monday, December 23, 1996, JTS of San Jose, a disk drive company, begins releasing pallets of Atari Jaguars to a liquidator (Tiger Software) for $20 each piece and software for $1 each piece. Expectations mount that the units will be bundled and sold at prices intended for expedient sale. Mr. Bob Gleadow, oversees the transaction from JTS’ European office (once known as Atari UK)." "January 1997: Tiger Software publishes and direct mails Volume VII, Issue 1 of their newest catalog called 1997 PC Yearbook. On the front page and on page 5, they offer an Atari Jaguar video game system at an exclusive price of $59.99 which includes ALIEN VS. PREDATOR, RAIDEN, NBA JAM and CYBERMORPH. Other games and accessories are offered at higher prices. According to some sources, Tiger paid $20 for the consoles and $1 to $5 for software as JTS is very anxious to rid themselves of Atari’s bulging warehouse of goods." [This sounds very similar to the catalog shown in Post #6.]

Nice! I'm reminded of one of my own early experiences with BASIC, when I was about six or seven years old. The TI 99/4A user's manual had a collection of type-in sample programs, one of which was an "inchworm" demo. It used character graphics to draw a blocky inchworm; it "crawled" across the screen with a simple animation effect, and when it reached the end, it beeped an "uh-oh!" noise and then "crawled" back the other way, repeating forever until the user entered a break. I spent a lot of time squinting at the fuzzy 13" black-and-white TV that I was using as a "monitor," debugging the program with my mother and rooting out my typos, and it felt like quite an accomplishment to finally get it working! Then of course, I got to work finding creative ways to modify it, which lead to hours of experimentation. A humble beginning, but it set me on my path. Now that I'm teaching classes in Computer Science, I'm always looking for ways to recreate that sense of discovery for my own students.

Yes, I remember QBasic. I started writing some simple games with it when I was in high school; this would have been around 1993-1994. I ran into a few snags that I could easily work through now with what I've learned since, so I've actually been thinking of digging one of them out again and finishing it! QBasic was a big step up for me from GW-BASIC, which I'd been using previously; it supported VGA graphics modes, and it didn't require line numbers! So far, so good! You're using Logo exactly as it was intended to be used: as a way to explore computers and programming.

Hmmm ... I'd check your procedures to make sure you're not making any infinitely recursive calls. If you're exhausting the available stack space, that could result in an error message like this.

Yes, that was a major omission in BASIC. Extended BASIC does add an EDIT command, but you can only edit one line at a time.