RevEng

Just out of curiosity, does anybody have load-corruption issues with the latest firmware *and* a non-socketed Sally in their 7800? (no need to answer if you're not sure about the latter)

The warning dates back to the bB codebase, but I understand why it's showing. You're multiplying a value by a constant, and the interpreter doesn't know if it's a multiply by a power-of-two or not, so it's missing the ability to optimise the multiply. For sure, just using "8" works. "def" should work too. It looks like I missed adding def to the 7800basic manual, so you can learn about it via the bB entry for it, for now.

I think it probably uses Maria sprites, mostly because a full-screen graphic buffer like the A8 or Apple II versions would be too costly in terms of ram. But I think the sprites are ram backed and it's copying the sprites over. Maybe. If not, all of that copying doesn't make a lot of sense to me otherwise. The wooden court is indeed a nice touch indeed. 👍

You're welcome. One of the files is an A78 file, which has a header that describes the hardware the game requires, and can be used with emulators and some flash carts. The other one is a BIN file, which is just a headerless ROM file, which you'd use either for burning an EPROMs with real cart hardware, or with an older flash cart like the CC2. Otherwise, both files are identical. Thanks. I think there's some good ones, and some stinkers. The stinkers hurt more on the 7800 than they do on other consoles, because the commercial library was so limited. But there are very good ones; IMO it's the go-to console for Joust or Food Fight. One On One is actually a pretty faithful port, in spite of the bug. I think it's fair to say the trade-offs the game design makes - large soft sprites, at the cost of less than fluid action - have made it age less well. I ran the 7800 version of the game through the 7800heat profiler, and it spends a ghastly amount of time just copying bytes around. I don't know for sure, but that makes me think they just overlaid the soft-sprite code on top of the 7800 architecture, which is a shame. Given how few things actually move in this game, it should really fly on this hardware.

Yes, it's easiest to launch the debugger via cli. An example command-line to launch in debugger mode is at the wiki, but I'll repeat it here... mame64 a7800 -cart1 xm -cart2 digdug.a78 -debug ...or if you're using a7800 proper, then you can use... a7800 a7800 -cart1 xm -cart2 digdug.a78 -debug If you just want to look at the Maria registers, you can view the memory locations in question as the game runs. You're right that there's no 6502 code examples. The guide assumes that you know 6502 assembly and that you know what registers or memory you're interested in. There are plenty of tutorials on 6502 assembly on the internet, and it's just a generic intro to the debugger for coders, not really how-to for hacking roms.

I don't have a pat answer here... analyse the joust source code and see what it does, and copy what that code is doing into your code, is the short answer. The longer answer is for me to do it for you, which isn't what you asked. I don't see any helpful answer between those two. I'd personally just implement the same gravity+flap idea without trying to copy it, as there's nothing particularly special about it. Assuming you want to do a physics sim, you need to have fixed point variables for the object's x and y position and velocity. Each frame the object's velocity variable, whatever the value is, gets added to it's position. If you want to implement gravity, then you add some constant value to the y velocity variable. If you want to implement a flap, then you subtract some larger value from the y velocity variable, whenever the fire button is pressed. There's a bit more code you'll want to likely add, because you'll probably want to nullify or negate the velocity values depending on certain object state. (e.g when the object is standing on a platform, or if you want the object to bounce) but those are the basics. The spacephysics sample program may give you some ideas about how to deal with velocity and position in this kind of sim, though it's not directly applicable to your gravity+flap request.

Concerto 2600 support is in WIP status, and doesn't support any of the ARM based games presently. It will support them eventually, given it's batari's baby, but there are bigger fish to fry at the moment.

You can in fact use ™ without registration, and that's actually what it means - an unregistered trademark. For registered marks you would use the ® symbol instead.

It's a very counter-intuitive result, but indeed I perceive the flicker getting worse for each square that's lower on the screen. (save the first, of course) Tested on real hardware with a CRT. Nice discovery! 👍

Yeah, those source files under Commando appear to just be a bunch of program skeletons, and randomish data, without any actual game logic or anything like that. Even if I take the mostly sensibly named data files and search our roms for binary strings within, nothing turns up. I did enjoy this little passive-aggressive tidbit from the included README2.DOC...

A full-blown disassembly isn't required for color hacks, but you do need a beginners grasp of 6502 assembly. The way I'd personally approach this task... 1. load up the game in the a7800/mame debugger 2. trap any writes to the Maria color registers, and run the game 3. look what values are being written to the registers, and figure out which ones you want to change. take note of the displayed disassembly and hex code for the load and store of the color you're interested in modifying. (t's possible the load will be from a table. if that's the case, note the table location and modify the desired table bytes instead, in the next step) 4. Open the rom in a hex editor and search for the hex code in question. If it occurs in several places, you likely want to change each one. It's probably duplicated due to the same color being used in different banks or different levels. 5. sign the changed rom using 7800sign. 6. run the modified rom to test it out If anyone (who has basic 6502 assembly knowledge) wants to learn the debugger, taking on this project would be a nice way to start. I'd be willing to mentor.

Somehow Atari managed to consistently bungle every controller design after the cx40. IMO either the Seagull 78 and a Genesis controller is the way to go, or just modify a genesis controller with the connections and resistors required for 7800 two-button operation. Sometimes people modify an NES pad, but that's a bit more work since you can't reuse the cable. The 7800 Europad is probably a distant option to any of those, but still better than the proline controller.

It's not possible to enable double-lines purely through software, but you can double up lines using what I refer to as "mirror ram". The Rescue On Fractalus proto uses this. Basically it's on-cart RAM with one of the address lines permanently set low (or skipped) with the effect that each even numbered RAM page is identical to it's neighbouring odd numbered RAM page. When you store graphics in this mirror ram area, when Maria pulls the graphical data it will cause duplicate lines (cutting the Y resolution in half) due to the fact that each line of graphics is stored on consecutive pages.

Poor Larry. Doomed by the bug to an eternity of free throws, and never once sinking it. 😆

Yeah, this was part of the talk. Gumby was supposed to be integrated into Maria initially, and then scrapped when other Maria functionality needed the die space. (yes, there is no sound related functionality in Maria now.) It seems from the presentation and the slide I quoted earlier, full blown Gumby would have 8 voices and 2 channels, though it's not clear if that's supposed to be 4+4 voices, or 8+8. The latter seems a bit excessive, unless those voices were also to be combined for timbre purposes in some fashion. We don't have any other information or insights on the design, which is why I reached out to Steve. (no reply yet) I'm not entirely sure if Gumby itself was part of the initial 3600 Maria TTL breadboard proto or not, but Steve's slides do mention that a Minnie (mini-gumby) TTL breadboard was completed, so there definitely are design details that can hopefully be illuminated by Steve. I think it's safe to infer that Minnie would have been mono, since there's only one audio line from the cart. One might also infer that naming it Gumby means GCC thought it would be at least as capable for sound as Pokey is (likely more) but it's less safe to carry that reasoning over to Minnie. Last inference to be made is it would have certainly been much more capable than TIA (or at least complementary to TIA) or else they wouldn't have bothered. Going into sheer speculation territory, my guess is that any difference from Pokey to Gumby would be evolutionary, rather than revolutionary. By the time Gumby was on the table, GCC programmers had developed 2 Pokey based arcade games (maybe 3. anybody know if Nightmare is pokey based?) and bunch of 5200 games. I think those programmers would have been looking for more+better, rather than an entirely new paradigm... but you never know.

As part of some troubleshooting, I happened to run One On One in a7800 without a bios, and noticed that the title screen was different. Usually the game starts with Larry Bird shooting a free throw, shortly after which the options screen appears. But if the bios is skipped and the cart is executed immediately, the title screen instead features a continuous gameplay attract mode, which gives you time to read the scrolling message at the bottom and to hear the entirety of the title music, until you press the fire button to get to the game menu. I also noticed that the A8 version is identical in behaviour to the 7800 bios-skip behaviour. I have little doubt that the 7800 version free-throw beginning was a bug that either nobody noticed until the carts were made, or that nobody cared enough about to track down. I added a memory cleanup routine to the beginning of the rom, which fixes the bug. I also added a proper 2-button setup, since the game does a half-assed one. One-on-One Basketball - Title Fix (NTSC).a78 One-on-One Basketball - Title Fix (NTSC).bin Enjoy!

The "plotmap" command in your example doesn't just use "currentscreen". It creates a ton of character display objects, each of them pointing to some offset of "currentscreen". So each of these display objects would need to be recalculated and modified under-the-hood, which is a lot more work than just changing one pointer. It could be done if it was really required, but most game designs would be better served by one of the more common screen change models... 1. use plotmap with a ram buffer of characters, and change the ram buffer contents whenever required. (it sounds like this is what you settled on) 2. use clearscreen and use plotmap to point to some other rom. (with the understanding this may take a few frames to happen, and you likely want to black the screen while it happens)

Ok, thanks for confirming. The AtariVox bug I was talking about is definitely related to AV+, so that's definitely not the problem here. 👍

Just wondering... does your vox sound fine with Dungeon Stalker and T:ME Salvo? Some percentage of consoles were found to have an AtariVox voice problem with these games, similar to what you describe, and the issue was eventually traced back to a problem with the design of the Vox units themselves.

7800basic uses the self-serve area of the AtariVox/SaveKey memory, so Albert doesn't need to reserve anything for your game. The $1970 value you reserved here isn't a location; it's a lookup key for any save data stored on either the HSC device *or* the AtariVox/SaveKey self-serve area.

With 7800basic? no. The last 4k of the rom is reserved for 7800basic functions, and there's no way to import graphics there. 16k is the smallest officially supported size. With the 7800 Assembly Dev Kit? yes. Just set your ROM ORG to $f000 in your source code. I did this just the other day in fact.

If it's not showing up in Device Manager when you plug it in, in any form, then the Harmony Programming Tool will never find it. No point in uninstalling or reinstalling the software, until Concerto shows up as a device to the OS. As Karl is suggesting, ensure you're using a cable that is know to work for data with another device. There are "power only" usb cables, and it's easy to get fooled by them. Also check using another port/computer, with the known good cable. If all of the above has been vetted, then it could be that there's some lower level problem with your Concerto's serial bridge.

And you're not powering Concerto in the console while you try to connect over USB, are you? Assuming not, does it show up in the Windows Device Manager tree as an unknown device, or is it recognized?

You understand correctly, but I think the language that it switches to 1.19 MHz (which has been used since the gcc docs) is a bit vague. What exactly happens is that when Maria (which generates Sally's PHI0) detects access in the TIA or RIOT address ranges, it will lengthen only the 6502 read/write cycle to 1.5 the usual length. So we get an effective 0.5 6502 cycle slowdown per TIA/RIOT access. It's not a real matter of flipping clocks, but rather just Maria logic, so I don't think there's much chance of it being messy. But it's entirely possible that some Sally's may not be happy with the long cycle.

Interesting that the CPU was running fine in the 800xl, which runs at the same base frequency at the 7800. Do you have a way to run the acid800 tests on your 800xl with this CPU? While the test is mainly for punishing emulators, the CPU specific tests could turn up something interesting. (though I'm leaning toward this being some kind of timing based difference.)