RevEng

Speaking to the 7800 side of things, @raz0red and I have been compiling a list of issues reported here, and actively investigating+addressing them. That list is private, because we're dealing with old carts, dirty carts, varying boards for different releases, etc - and getting multiple reports on the same games lets us cut through some of that noise.

The worldwide view at your link is skewed by the massive number of Android users in India and China. Correct me if I'm mistaken, but I don't think Atari is targeting those markets with the 2600+. At the bottom of your linked page you can check by region. Which OS is top when you click on the largest regions the 2600+ is selling in? It seems to be Windows in almost all cases. The only counterexample I see is Europe, where Android only slightly eeks out Windows.

He says the game loads anyway, despite the failed message. If you stick in Deadly Duck and wait, and the game never loads, then it's another issue.

There's a UI issue... when the state of that switch changes, we need to generate a timed virtual pause-button press in software, or else pausing in some games doesn't work. e.g. try holding down the pause button in Galaga on a real 7800, to see what I mean. We'll revisit it and see if there's anything we can kludge in.

I've had other 7800 emulator authors reach out, unsure if their emulator is broken or not, when they try out Karateka. It's always Karateka that's the problem.

Perhaps Atari should consider compiling a nice looking book with *all* of the Atari produced 2600 instruction manuals, for those that want paper references. Add a page of preamble for each - excerpts from interviews with the programmers and artists, media or historic events that happened at the game's launch, etc - and you have a nice piece of memorabilia.

Thanks for the confirmation. The original klax proto had a race condition that caused it to crash on some 7800s. I'm thinking it's related to that. [edit - this is the issue I'm talking about, though likely it can be worked around in the emulation]

swlovinst (John Hancock) reported his Klax cart was working. Any chance yours needs a cleaning?

I think it would be useful to have a "2600+ compatible" category in the store too. @Albert surely doesn't have enough to do, these days!

Hey John, for this one... ...Crazy Brix swaps controls via the difficulty switches. Can you please try again with joystick plugged in, and switching the first-player difficulty switch if it doesn't work? Nope, there's no unusual tech in Popeye. With some more bug reports for other homebrew carts, we will hopefully see a pattern and narrow it down. There's also the possibility that Popeye might work for someone else, if it's a dirty cart, fitment issue, edge-case timing, etc., so more reports for reported-failed carts is helpful too.

Are you sure this one just doesn't need a clean? It's working on my 2600+

Just so people are buying with eyes open... @raz0red and I were brought in after the console hardware was finalized, to improve the 7800 experience. I worked on a generic 7800 dumper module (which probes the cart, and supports dumping of linear and various sizes and flavours of supergame) and raz0red worked on that absolutely massive list of emulation improvements. But the console won't be supporting banksets (no halt line) and doesn't have a connected audio line from the cart. More exotic peripherals like atarivox, savekey, and keypads likely can't be supported. The dumper+emulator architecture means that it can only run "in-cart" hardware that the emulator has code to detect and handle. There's a lot of good things to say about the console. It's a cool piece of hardware for playing old (and many new) 7800 games on your modern TV, without the need for a scandoubler, and it has the iconic Atari feel and brand. If you do the serial port mod, it's also a nifty cart-dumper. Just spend your cash knowing what you're buying.

You may find the lfsr6502 project of interest - it's a C based implementation of some notable LFSRs from the 6502. It's meant to document and conveniently test the output of the included LFSRs. The LFSR you linked to above is equivalent to the "reversed" batari basic 8-bit LFSR. lfsr6502 also allows you to create bitmaps from the LFSR output, to see patterns. I posted some bitmaps generated from it in this thread

Correction... Altirra is licensed under the GNU General Public License (GPL), version 2.

Have a look at the fonts that @SpiceWare and some others came up with. Some of the resolutions use a line or two for descenders, but the smaller ones like 3x5 use raised descenders, and it looks fine to me.

Atari emulators often block "impossible" direction combinations from input when joysticks are selected for input, because it's really easy to press impossible directions when using a pc keyboard. The 2600 driving control generates impossible directions in some positions. Fixing driving controls might just be a matter of overriding that behaviour, since it's not needed here.

But Orson may sample the "update" a bit before the public does...

Awesome - thanks for the bug report, testing, and kind words!

I think I see the reason for the dual-snes2atari mix-up, and possibly the mixed device hang. I don't have my 7800 handy right now, so... if you copy this updated snes2atari.asm to your project directory, does it fix either bug? snes2atari.asm

You can check if hsdevice=2. (see the "high score support" section of the manual) If high score support is enabled, and a avox/savekey device is detected, the multi-button code doesn't probe that port for a multibutton controller.

Yep

Assuming this is a retail mega7800, what color is the LED on the mega7800 showing when your pad is plugged in? It should show green for a 6-button controller, whether or not the console has negotiated to use the extended button mode.

Sure does... (see below for spoiler)

I checked my conversations with Rafal just now, and yes, DragonFly only supports the "2x128k+RAM+Pokey" banksets mapper.

Not originally addressed to me, but I have 2 cents. Programming on old consoles, and the 2600 in specific, is a sort of extreme situation where you can't apply very many general rules. Your specific game design may be ram hungry, and thus call for trading off rom and cpu for ram. Someone else's design may be rom or cpu hungry. You likely won't understand which constraints you'll be bumping up against until you eventually become an expert in implementing your specific kind of game on the 2600. Rewrites are a normal and natural part of the process, and shouldn't be thought of as wasted time. While I said "there aren't very many general rules", I do strongly believe Knuth's thoughts on premature optimization apply to the 2600. As meagre as the 2600 resources are, they're actually pretty well balanced - don't assume you'll be short on one resource vs another until you have evidence for it. Write code and figure it out. Nobody ever finished coding a 2600 game that was exactly implemented as it was planned up front. In terms of your specific questions about sprite animation... Animation doesn't use much cpu time. With bB animation amounts to changing a single pointer value. My own preference for animation is to use a single frame counter variable and animate all of the sprites using a mask, but that approach requires your animation frame counts to be based on powers-of-two (i.e. 2, 4, 8, 16) which i don't personally find constraining. Others really want more flexible animation counts, or don't understand bitwise operations, and wind up using separate variables. Sometimes you just want the animation to change with screen position, in which case you can use the position variables to drive that. None of this is make or break, nor is it a big cost to change your mind later and take a different approach.