alex_79

I think recent Atari Flashback models (those that have HDMI output) use Stella 3.9 which, while quite old, already supported DPC+.

Version 0.1 does not work on my two Harmony carts (black screen on both). Note that mine are standard (non Encore) versions.

I quickly tested and it seem to work for me on my Harmony cart, albeit the framerate isn't stable and the screen jitters sometimes. Javatari doesn't list DPC+ as a supported cart type in the project page, so that's probably why it doesn't work there. The only emulators supporting DPC+ that I know of are Stella, 6502.ts/Stellerator and Gopher2600.

I second @Al_Nafuur's suggestion: carefully clean and triple-check the board for shorts that might have been caused by the solder job. Check every solder joint with a magnifying glass to ensure that there's no small debris or solder drops that can potentially touch adjacent tracks or pads. Also check the power switch. Spray some contact cleaner and toggle it back and forth a few times to remove oxidation. If it feels "loose" when operating it, the contacts inside it might have lost tension. You can open it and re-tension the contacts. It's easier to do if you first desolder the switch from the board, but it can be done with some patience while leaving it installed. (You have to bend out the tabs that keep the metal cover of the switch attached). To rule out the switch you could just solder a jumper in parallel to it and plug/unplug the power adapter to turn the console on and off. If that solves the erratic behavior you know the culprit is indeed the switch and can proceed fixing or replacing it. Seems like the modifications to the board were made to adapt it to use a single rom chip, instead of the two it was originally designed for. That console has 128 games installed, instead of 192 advertised on the box.

If it's PAL, the colors will be wrong, and there are a few differences in the display too that you might be able to check even if the screen is rolling. Here is how it looks when running the PAL game on a NTSC console (note especially the green sky): Here is the NTSC game running on a NTSC console: In the NTSC version the score is right at the top of the display, while in the PAL one there's some space above it (because the "sky" area is taller). PAL also have a larger gap between the display and the fuel bar / lives indicators.

The screenshots in that auction show some graphics corruption. Possibly some bad ram in there that need to be replaced. I hope someday one of the owners of this device will take the time to disassemble it and trace the board. I'm fascinated by these kind of cartridges (like e.g. the Magicard for the Atari 2600) that turn the console into something similar to the early single board computer. I actually tried the hobby module on my Interton VC4000 using an home built cartridge, but it lacks the cassette interface so I'd really like to see a schematic of how it was implemented.

Are all the RIOT I/O registers (SWCHA,SWACNT,SWCHB,SWBCNT) ensured to be 0 before loading a 2600/7800 rom? Those are zeroed by the normal 6532 reset sequence (on a power cycle), but in case they're altered by the Concerto menu they could cause issues if a game rely on this and they're not restored to their initial state. I ask because in the past I experienced issues on the 2600 Pluscart until such initialization was added to the firmware: the "emulation-exit" feature allows to exit a game and go back to the menu without power-cycling, and if a game altered the I/O registers, the Pluscart menu or the games loaded after that sometimes misbehaved until the console was powered off and on again.

Stella autodetects that the game uses a genesis controller on left port, and an savekey on the right one and sets the inputs according to that. If you want to use the button on the second joystick, you must manually set the controller in the right port as joystick in "Game Properties". Selecting it on the game menu alone doesn't change the controller settings: Stella is still emulating a savekey in the second port, not a joystick, unless you manually change that. After you change the settings, Stella will remember them for that specific rom, so you only need to do it once.

The same code can be found in the PAL bios. Here's the original source code (used to be at "atarimuseum" website), which include comments:

I was reading through the thread, and noticed a few mentions of offset/shifted graphics in 2600 games (e.g. post #149 and #217) and how this is sometimes fixed by reloading the game. I also checked the "Smurfs" gameplay video posted on the previous page, and by comparing it to the emulated game in Stella, you can see that all the "player" objects are offset 1 pixel to the left in the video (look closely at the house, the fence and the spider web and compare their position with the playfield graphics). So, I wonder if maybe the TIA horizontal counter ends up being out of sync with the CPU when locking in 2600 mode (that is, the start of the scanline doesn't correspond to the start of a CPU cycle, but it's offset by 1 or 2 TIA cycles). This could explain the gfx glitches and also some games crashing altogether, as collision detection might be messed up and the TIA "WSYNC" function can misbehave in such condition, causing the CPU to skip a byte after it resumes execution.

Firmware updates for the Unocart using the same codebase as the Pluscart have been released here. You'll need an ST-link programmer to update the first time, though. Subsequent updates can be done through the SD card.

In those levels the game uses the same brightness for the two zones, which makes them difficult to distinguish. You might try increasing color saturation and brightness on your TV, but the real problem is the choice of color values in the game itself. Anyway, if you flip the TV TYPE switch in B&W position, the "un-dug" ground will change to a gray shade which should always be lighter than the "dug" area. Give it a try.

What about 6502.ts/Stellerator by @DirtyHairy? It's open source, supports ARM games and runs in a browser.

In order to communicate with an external device (e.g. a savekey), you need inputs and outputs that can be seen and controlled by the CPU. The program running on the 7800 must be able to read from an input pin and write to an output one. By looking at the schematic, the expansion port doesn't provide any of that. If bidirectional communication between the external device and the 7800 is required, it doesn't (it can't) happen through the expansion port. There needs to be some additional connection between the two, using the cart and/or controller port. By using the expansion port alone, the external device can only: - halt the cpu and disable Maria - highlighted in purple in the attached schematic. - provide the clock to the 7800 (as they must use the same clock to ensure synchronized video outputs that can be mixed together) - magenta in the schem. - see the A/V output from the Maria chip (including the separate digital luma, color and video sync signals) - green. All of this happens on the hardware level, and there's nothing else there. I don't see anything on the expansion port that can be controlled/seen by software running on the 7800.

The connectors are different (the one in the 2600 is smaller as it has less pins). It's the plastic cart guide, which is part of the top half of the case in the jr, that has the 7800 style larger slot and would work without modification with the 7800 cart connector installed inside the case.

Yes, according to the 7800 schematic, the expansion port doesn't have any I/O capabilities: it only provides audio, video and sync from Maria and a few control signals so that the an external device can: 1 - disable the internal 7800 clock and provide an external one 2 - halt/resume the cpu and Maria chip This allows to have the external and internal video generation to be synchronized, so that the two can be mixed together. Any data transmission in both direction has to happen using the cartridge or controller ports, the expansion port alone is of no use for that.

The voltage indicated in capacitors specs is the max rating, so, as long as it's not less than the actual voltage that will be applied to it in the circuit (5v in this case), it's fine.

Very nice repair job. Looks quite sturdy and should hold quite well IMO. BTW, did anyone notice that the cartridge guide on the junior (larger slot for the board, and thinner pegs) is actually identical to the 7800 one? Maybe Atari was planning a 7800 junior...

The FB2 uses an "Atari on a chip" recreation of the original hardware (not fully compatible, unfortunately), so it just reads the cart in real time like on a standard console.

It would be possible to store Supercharger loads on the Harmony/Melody eeprom, overcoming the 32k limit even on a standard (non Encore) Harmony. But, there are more powerful/flexible banking schemes available, so there's not been enough interest in the SC format to invest time in extending the current multiload limit.

$FFF9 should be avoided too: reading it won't cause a bankswitch, but the audio input is read at that location (on bit 0).

64 bytes, according to the manual.

"On par with nes games" might really mean anything. Some people around here might consider Atari 2600 games to be superior to nes ones!

What about sending some long enough speech data and check if the READY pin (pin 2 of the controller port, that is SWCHA bit 1/bit 5 for the right/left port respectively) ever reads as 0, indicating that the Speakerjet buffer is full? On a SaveKey that pin should be unused (floating) and always read as 1.

The game updates the players' graphics as they're drawn, so that each copy can be different. (if you step through the code in the debugger, you'll see several writes to the GRP0 and GRP1 registers during the scanline) In "Pepsi Invaders" (which is an hack of this game) the "aliens" are all different in each row, even when there's not an explosion.