2600+ w/7800 support

[juansolo]

Actually a bug in the TIA, TailChao went into it in another thread. I've got the same problem with my 7800 and I implemented a bodge that adds a couple of resistors to port 2 when I've got my internal AtariVox enabled. When it's disabled and I have a second controller connected the bug does not occur. Alternatively you could drop in a different TIA and it would likely go away.

[TailChao]

On 11/19/2023 at 7:32 PM, Trebor said:

If the same consideration was provided to the 7800, drawing a parallel with the 2600 support and ARM, for the 7800, the outstanding item, what is not supported, is the BupChip; which is completely understandable.  I wouldn't realistically expect that to work with 2600+.

I'd argue the BupChip is even easier to support than ARM / Melody, as are most of the 7800 audio expansions. There's a dedicated pin for analog audio input right on the cartridge slot. Put a DAC on there, forward the emulated software's writes to the actual chip, capture the output and mix. Aside from fiddling with some timing here and there, it's a much less stressful job than accurately reimplementing a gajillion different audio chips.

 

 

3 hours ago, juansolo said:

Actually a bug in the TIA, TailChao went into it in another thread. I've got the same problem with my 7800 and I implemented a bodge that adds a couple of resistors to port 2 when I've got my internal AtariVox enabled. When it's disabled and I have a second controller connected the bug does not occur. Alternatively you could drop in a different TIA and it would likely go away.

While your workaround of adding pulldown resistors is correct, I wouldn't call it a bug in the TIA - rather, it's a quirk of how the paddle inputs are designed. You can also mitigate this in software by strategically dumping the inputs to ground. I didn't think any precautions were necessary at the time as none of the other "press button to play" games like Xenophobe or Rampage took them. Only after launch did the quirk show up in any sort of scale 😕 .

 

So don't blame the TIA, but rather my expectation that the ProLine's curse would be limited to some minor wrist damage.

[+batari]

On 11/19/2023 at 9:32 AM, Trebor said:

They did reach out about Stella - last year no less.

They were going to leverage a nearly as old version of Stella (2014) as ProSystem 1.3e (2013) for the 2600+; however, Thomas convinced them otherwise.  The lack of compatibility experienced now for 2600 titles (I.E. many of CHAMP GAMES) is due to not being able to emulate the ARM processor.  This is likely similar to the issue with not being able to leverage the A7800 emulator, the processor being used for 2600+ is not fast enough.  It cannot emulate the ARM adequately. 

I am pretty sure that the current problem with ARM games is a dumping issue, not an emulation issue. The ARM emulation in Stella is *very* fast and efficient. It was added way back in 2011 and it would run even on my old, slow 2004 laptop. I have little doubt that it will run on the 2600+ if the dumping issues are solved.

[+-^CrossBow^-]

5 hours ago, juansolo said:

Actually a bug in the TIA, TailChao went into it in another thread. I've got the same problem with my 7800 and I implemented a bodge that adds a couple of resistors to port 2 when I've got my internal AtariVox enabled. When it's disabled and I have a second controller connected the bug does not occur. Alternatively you could drop in a different TIA and it would likely go away.

As I stated above, I've had a few 7800s lately with ghost fire button pressese showing up without a controller. I corrected it by replacing the resistor at R35 with one closer to the 220Ω spec listed in the schemtics. The originals that were removed were reading around 217.5 which is still without the 5% they were spec'd for. But I'm guessing as the TIAs age, they become less tolerant and require more tighter values from those resistors.

 

 

[+-^CrossBow^-]

2 hours ago, TailChao said:

I'd argue the BupChip is even easier to support than ARM / Melody, as are most of the 7800 audio expansions. There's a dedicated pin for analog audio input right on the cartridge slot. Put a DAC on there, forward the emulated software's writes to the actual chip, capture the output and mix. Aside from fiddling with some timing here and there, it's a much less stressful job than accurately reimplementing a gajillion different audio chips.

 

 

While your workaround of adding pulldown resistors is correct, I wouldn't call it a bug in the TIA - rather, it's a quirk of how the paddle inputs are designed. You can also mitigate this in software by strategically dumping the inputs to ground. I didn't think any precautions were necessary at the time as none of the other "press button to play" games like Xenophobe or Rampage took them. Only after launch did the quirk show up in any sort of scale 😕 .

 

So don't blame the TIA, but rather my expectation that the ProLine's curse would be limited to some minor wrist damage.

Xenophobe and Rampage both suffer a similar issue in that on my main 7800 or rather..used to... the games player 2 would start up automatically after my console had been on for about 20min or so. Replacing the resistors as I've mentioned above has corrected this. Not saying it will fix it in every situation, but I've done about 4 7800s now where I replaced the original R34 and R35 resistors and it seems to have corrected the issue.

[TailChao]

1 hour ago, batari said:

I am pretty sure that the current problem with ARM games is a dumping issue, not an emulation issue. The ARM emulation in Stella is *very* fast and efficient. It was added way back in 2011 and it would run even on my old, slow 2004 laptop. I have little doubt that it will run on the 2600+ if the dumping issues are solved.

That was my understanding as well.

 

 

6 minutes ago, -^CrossBow^- said:

Xenophobe and Rampage both suffer a similar issue in that on my main 7800 or rather..used to... the games player 2 would start up automatically after my console had been on for about 20min or so. Replacing the resistors as I've mentioned above has corrected this. Not saying it will fix it in every situation, but I've done about 4 7800s now where I replaced the original R34 and R35 resistors and it seems to have corrected the issue.

These are just current limiting resistors, so while you're seeing the behavior go away it's likely more of a happy accident. Same as when swapping the TIA out for another one seems to fix it. Not that I'm doubting it's worked for you - but electrically you're not doing much other than changing the behavior of an antenna without attaching a ProLine or grounding both paddle inputs.

 

Mostly I want to dissuade from viewing this as a "bug in the TIA" since it's fair game for the paddle inputs to operate this way, based upon the TIA's internal schematics and how it was used in the 2600. If anything the "bug" would be in the 7800's original documentation for omitting it, or perhaps not realizing it'd be a problem.

 

Ah, but speaking of terminology misuses...

2 hours ago, TailChao said:

DAC

...should be ADC. May bad.

[zzip]

On 11/19/2023 at 7:32 PM, Trebor said:

That could have been the case, if the A7800 or JS7800 was the reference point and they "scrapped the set up [with original ProSystem] and instructed to rework it all [Utilizing either JS7800 or A7800 (sources)],

When I asked, they said the hardware was insufficient to run a7800.    JS7800 is a non-starter unless someone were to backport the changes to C/C++.  

[+-^CrossBow^-]

29 minutes ago, TailChao said:

That was my understanding as well.

 

 

These are just current limiting resistors, so while you're seeing the behavior go away it's likely more of a happy accident. Same as when swapping the TIA out for another one seems to fix it. Not that I'm doubting it's worked for you - but electrically you're not doing much other than changing the behavior of an antenna without attaching a ProLine or grounding both paddle inputs.

 

Mostly I want to dissuade from viewing this as a "bug in the TIA" since it's fair game for the paddle inputs to operate this way, based upon the TIA's internal schematics and how it was used in the 2600. If anything the "bug" would be in the 7800's original documentation for omitting it, or perhaps not realizing it'd be a problem.

 

Ah, but speaking of terminology misuses...

...should be ADC. May bad.

I'm just stating that the schematics call for 220Ω resistors off those trigger lines. Since they required for 2600 game use. Without the resistors in place, fire button functions stop working in 2600 mode. However, the ghost fire button presses in 7800 games will also go away if you remove those resistors while still allowing them to work in 7800 mode. So it does seem that those resistors play a pretty big part in the logic the 7800 is using to know if the fire buttons have been depressed or not.

 

I thought the issue was ghost fire button triggers in 7800 games causing the games to behave strangely or auto start a second player in a game without a controller attached? I know that in the above cases I was talking about, I was able to make the issue come and go simply by replacing the resistor or installing the original back in circuit. Yes having a second controller plugged in also made the issue go away, but in reality, the controller ports shouldn't detect any activity if there isn't anything plugged into them in the first place?Show Reply

 

[TailChao]

1 hour ago, -^CrossBow^- said:

I'm just stating that the schematics call for 220Ω resistors off those trigger lines. Since they required for 2600 game use. Without the resistors in place, fire button functions stop working in 2600 mode. However, the ghost fire button presses in 7800 games will also go away if you remove those resistors while still allowing them to work in 7800 mode. So it does seem that those resistors play a pretty big part in the logic the 7800 is using to know if the fire buttons have been depressed or not.

R34 and R35 are series resistors for the CX-40's trigger on Pin 6. Removing them will, of course, disable fire button functionality as you're also removing the connection from the CX-40's trigger to the TIA. However, they're also used by the ProLine to aggressively drive the paddle inputs high using the transistor network of Q5, Q6, and Q8.

 

 

1 hour ago, -^CrossBow^- said:

I thought the issue was ghost fire button triggers in 7800 games causing the games to behave strangely or auto start a second player in a game without a controller attached? I know that in the above cases I was talking about, I was able to make the issue come and go simply by replacing the resistor or installing the original back in circuit. Yes having a second controller plugged in also made the issue go away, but in reality, the controller ports shouldn't detect any activity if there isn't anything plugged into them in the first place?

Not exactly.

 

Pin 6 on either joystick port, which is used for the CX-40's trigger, is pulled high by R40 or R41. In single button mode (or for any 2600 game), this prevents the pin's state from changing and spuriously detecting a press. So in this case, it's difficult to get any surprises unless something has gone catastrophically wrong.

 

The paddle inputs on Pins 5 and 9, which are used by the ProLine controller for both of its triggers, have nothing to keep the pin's state from wandering. The two resistors inside the ProLine pull these low to indicate both buttons aren't being pressed. Pressing either button will short Pin 6 to its respective paddle input and force it high, using the aforementioned transistor network. The ghost button presses in Rikki & Vikki, Xenophobe, and Rampage are from the paddle inputs wandering high without a ProLine attached to hold them low. They're effectively an antenna.

 

If the ProLine is being used in single button mode (Q5 or Q6 are off), its pull downs are strong enough to overpower R40 or R41 and register a press on Pin 6. This is how its CX-40 compatibility works.

 

Refdes above are all for the NTSC schematic, of course.

[Trebor]

Below is a complete history of the ProSystem emulator for Windows, as it is not clear what sources are implemented under 2600+; hopefully, Atari will release the source code in time so the issues may be sorted out surrounding emulation and the root causes for them.

 

It has been stated version 1.3e is the source code utilized for 2600+; however, certain behaviors under 2600+, such as a ROM not being recognized at all, if not a part of the internal database (ProSystem.dat), was something addressed in Version 1.3a, but an issue with the original 1.3 and older source code.  There is further uncertainty when more recent pages listed the latest version as 1.3 and contain more recent dating than either the original 1.3 release, or version 1.3e.

 

Breakdown - Version x.x (mm/dd/yyyy):

Version 0.1 (02/14/2005)
Initial release by Greg Stanton (gdement)
SOURCE: http://home.comcast.net/~gscottstanton/  (Now defunct)

 

Version 1.1 (01/07/2007)
* Fixed Palette file not being used on reset
* Changed default palette to Nabuko78's palette
* Added joystick support
Updated by Brian Berlin (jberlin@cfl.rr.com)
SOURCE: http://home.comcast.net/~gscottstanton/  (Now defunct)

 

Version 1.2 (04/28/2007)
* Implemented INTFLG (Beef Drop now works)
* Added Command Line parameters
* Added mapping of Exit and Menu Enable keys
* Added storing of Menu Enable parameter
Updated by Brian Berlin (jberlin@cfl.rr.com)
SOURCE: http://home.comcast.net/~gscottstanton/  (Now defunct)
 
Version 1.3 (05/12/2008)
* Modified snapshot engine
* Take screenshots by press F12 without any prompt (in style MESS)
* Insignificant changes in main menu
* Moved all texts in resource (for future translations)
* Has put check on attempt to load CC2 hack's (in log file registers "ProSystem do not want to execute CC2 hacks.")
* The default palette is updated to Underball's latest palette. It is the best palette available with Hex values taken directly from a 7800.
* A little optimisation in logging messages
* Documentation updated
* "Unfortunately, everytime you exit and relaunch Prosystem it returns back to its default setting of 44100." - Fixed
* Command line "-SampleRate" - Fixed
* "If you launch a ROM from the command line the sound is a second or two behind the action, regardless of the sound latency setting." - Fixed
Updated by Leonis (tv-games@yandex.ru)
SOURCE: http://home.comcast.net/~gscottstanton/  (Now defunct)

 

Version 1.3a (12/24/2008)
* Now, emulator itself calculate MD5 checksum, and write it to "ProSystem.log"
* Modified snapshot engine - screenshots now save to directory "\snap"
Updated by Leonis (tv-games@yandex.ru)
SOURCE: https://forums.atariage.com/topic/124215-prosystem-emulator-update/?do=findComment&comment=1645790

 

Version 1.3b (03/20/2009)
Minor update:
Controller button 1 is now mapped as the left button, button 2 is the right. (Riot.cpp)
Default keyboard settings for buttons 1/2 edited to match this change. (Input.cpp)
FIXED: right button was not activating the legacy 2600 button signal (Riot.cpp)
added changelog.txt
Updated by Greg Stanton (gdement)
SOURCE: https://forums.atariage.com/topic/124215-prosystem-emulator-update/?do=findComment&comment=1707410

 

Version 1.3c (03/25/2009)
Minor update to handling of the emulator's window position:
- FIXED: emulator window now opens in previously saved position, not 0,0 (console.cpp)
- changed default window position to (120, 120) instead of upper left corner. (configuration.cpp)
This prevents menu and title bar from appearing underneath some taskbar setups.
Updated by Greg Stanton (gdement)
SOURCE: https://forums.atariage.com/topic/124215-prosystem-emulator-update/?do=findComment&comment=1710348

 

Version 1.3c *Updated* (03/25/2009)
Annoying mistake - I forgot to change the version number in the file I posted previously.
The files I posted above report the wrong version and should not exist.
This fixes that. No changes, just the correct version "1.3c" now shown in the "about" screen.
Updated by Greg Stanton (gdement)
SOURCE: https://forums.atariage.com/topic/124215-prosystem-emulator-update/?do=findComment&comment=1710748

 

Version 1.3d (04/09/2009)
2nd button now works correctly in Dark Chambers
Joystick button emulation is now much more accurate
- Distinct 1 button and 2 button joystick modes are now properly emulated (riot.cpp)
- SWCHB is now writable allowing games to toggle the button mode (memory.cpp)
- SWCHB default settings match testing on real console.
Updated by Greg Stanton (gdement)
SOURCE: https://forums.atariage.com/topic/124215-prosystem-emulator-update/?do=findComment&comment=1717822

 

Version 1.3d2 (04/16/2009)
This is a minor bugfix for 1.3d. It adds nothing, just fixes a stupid bug which caused the player 2 button to be permanently held. It was caused by me mixing up hex and decimal numbers.
This fixes the crashes that were happening with Jr Pacman - at least I haven't had that happen since this correction.
Updated by Greg Stanton (gdement)
SOURCE: https://forums.atariage.com/topic/124215-prosystem-emulator-update/?do=findComment&comment=1727901

 

Version 1.3e (06/05/2009)
Improved emulation of RIOT
-1/2 button modes are now toggled correctly.
    This fixes critical bugs in a few games (Fatal Run, Hat Trick, One on One, Water Ski)
-SWCHA now reflects the interactions of CTLSWA and the RIOT's DRA register. Ditto for SWCHB.
    This makes console switches more accurate, but it only affects odd scenarios.
Thanks to raz0red and groovybee for their help figuring these things out.
Updated by Greg Stanton (gdement)
SOURCE: https://forums.atariage.com/topic/124215-prosystem-emulator-update/?do=findComment&comment=1765438

 

Version 1.3e *Updated* (06/06/2009)
-Fixed Help-About still reports version 1.3d2
-Fixed bug discovered by raz0red which would mess up the controls in-between different games.
Updated by Greg Stanton (gdement)
SOURCE: https://forums.atariage.com/topic/124215-prosystem-emulator-update/?do=findComment&comment=1766481

 

Version 1.3f (09/06/2015)
Modified ProSystem for trying some of the enhancements made by raz0red in his Wii version:
Some games seem to work perfectly now : Kung Fu Master, Summer games.
Some others have less graphical glitches : Commando (title screen), Midnight Mutants (which still have sometimes, some red pixels in the text in the top banner).
Some others still have some graphical glitches : Ace of Aces (the blue horizontal line in title screen).
Not implemented:  high-scores cartridge support, lightgun support, better difficulty switches management.
Updated by JnO
SOURCE: https://forums.atariage.com/topic/124215-prosystem-emulator-update/?do=findComment&comment=3315897

 

Version 1.3g (10/29/2015)
Updates:
-Lightgun is supported! For the 5 games which support it and via the prosystem.dat file, it is now activated by default (you still can de-activate the lightgun through the "Emulation" menu).     Thanks to Raz0red for his lightgun related code in wii7800.
-Lightgun timing isn't accurate enough (it isn't in wii7800 either), so some offset has been added in the prosystem.dat for x and y coordinates (raz0red has made the same type of hack, too)
-Difficulty switches now are correctly managed. Their states are displayed in the menu bar, on the upper right
-Added some hblank values in prosystem.dat for a few games, in a hope to enhance the resulting emulation (graphical glitches) for these: for example, The "Commando" title screen is perfect now. Of course I know this isn't the definitive solution, but it's better than before though... (in the previous version, only BallBlazer had a hblank specific value).
Updated by JnO
SOURCE: https://forums.atariage.com/topic/124215-prosystem-emulator-update/?do=findComment&comment=3355788

 

What creates some additional confusion, is in more recent times, a GitHub page (https://github.com/gstanton/ProSystem1_3) has been setup by the original developer, and including the homepage (https://gstanton.github.io/ProSystem1_3/), shows only one release labeled Version 1.3 and dated March 17, 2015.  

 

It seems that version should be a "Version 1.3" release that takes place after version 1.3e was released on June 6, 2009, but before version 1.3f, which was released on September 6, 2015.

 

Spoiler

 

[RevEng]

On 11/21/2023 at 9:52 AM, TailChao said:

These are just current limiting resistors, so while you're seeing the behavior go away it's likely more of a happy accident. Same as when swapping the TIA out for another one seems to fix it. Not that I'm doubting it's worked for you - but electrically you're not doing much other than changing the behavior of an antenna without attaching a ProLine or grounding both paddle inputs.

Am I wrong in thinking that adding some high value pull-downs, say 10k+, at R34 and R35, would likely stop the wandering and allow for regular 2-button and paddle operation?

[TailChao]

On 11/22/2023 at 11:00 AM, RevEng said:

Am I wrong in thinking that adding some high value pull-downs, say 10k+, at R34 and R35, would likely stop the wandering and allow for regular 2-button and paddle operation?

R34 and R35 are both series resistors on the trigger inputs (J3-6 and J4-6 on the NTSC schematic, which go to the TIA's I4 and I5). So no, this wouldn't help with the paddle inputs drifting.

 

 

If you wanted to build a solution into the console, it'd resemble a mirror of the Q5, Q6, and Q8 transistor network which strongly pulls up the trigger inputs when ProLine mode is enabled through PB2 or PB4 on the RIOT. But instead of pulling up the trigger inputs when PB2 or PB4 and TIAEN are low, it'd pull down the paddles. Something like one NPN and a pulldown on each paddle line, fed by !(PB2 | TIAEN) or !(PB4 | TIAEN) through a few logic gates.

 

I'd honestly leave the wedge alone though. It's easier to take a female DE9 then short pins 5 and 9 (paddles) to pin 8 (ground) - now you've got a terminator. You can even 3D print a little shell for the solder side to make it look like a fancy port cover.

 

 

On 11/22/2023 at 10:11 AM, Trebor said:

Below is a complete history of the ProSystem emulator for Windows, as it is not clear what sources are implemented under 2600+; hopefully, Atari will release the source code in time so the issues may be sorted out surrounding emulation and the root causes for them.

Isn't ProSystem licensed under the GPL? You should just be able to ask Atari / PLAION to release the source for compliance if everyone is so eager to fix their product.

 

Or even better...

On 9/24/2023 at 7:02 PM, RevEng said:

How about the for-profit company do it for their product, instead?

[RevEng]

6 hours ago, TailChao said:

R34 and R35 are both series resistors on the trigger inputs (J3-6 and J4-6 on the NTSC schematic, which go to the TIA's I4 and I5). So no, this wouldn't help with the paddle inputs drifting.

Derp, you're right. I glanced casually at the schematic and mistook r34/35 as belonging to the pin 5/9 paddle inputs. So really I should have said R38/39. (and given those are 1.4k series resistors that will divide the voltage with the pull-down, I guess 20k+ would be more prudent than my original suggestion of 10k+)

[howerton]

I don't know if anybody tried this. But double dragon (7800) does not work on the 2600+, when Atari said it passed. Maybe they were using the PAL version because the NTSC version sure does not work.

[+-^CrossBow^-]

43 minutes ago, howerton said:

I don't know if anybody tried this. But double dragon (7800) does not work on the 2600+, when Atari said it passed. Maybe they were using the PAL version because the NTSC version sure does not work.

I can confirm this. My actual cartridge never even shows loading game on the 2600+. However, I'm able to load up the NTSC rom just fine from my DragonFly cartridge on the 2600+. So that tells me there must be at least two different revisions of the game that were released and the 2600+ is only able to know one of those versions.

 

Now, having said that, while it did load and play on the 2600+ from my DF cart, I did notice that the yellow color was missing on the title screen? It seemed to look okay in game though.

 

 

[gambler172]

On 9/25/2023 at 6:36 AM, Trebor said:

Here are many post original retail/homebrew release...

Test Results under ProSystem 1.3e Core via RetroArch:

 

7ix = Works without issue
1942 = Black screen
2048 = Graphic issue throughout
A.R.T.I. = Black screen
A Roach in Space - Part 2 = Works without issue
Ah Zombies = Graphic issue throughout
Alpha Race = Works without issue
Apple Snaffle = Some graphic corruption after screen scrolls
Arkanoid = Black screen
Armor Attack II = Works without issue
Asteroids Deluxe = Speed/Timing Issue present
Astro Blaster = Works without issue
Astro Fighter = Works without issue
Attack of the Petscii Robots = Black screen
Baby Pac-Man = Graphic issue pinball screen
Beef Drop = POKEY sound not present, enemies absent, player will not move
Bentley Bear's Crystal Quest = No POKEY music or TIA sound effects present
Bernie and the Cubic Conundrum = Graphic issue throughout
Bernie and the Tower of Doom = Black screen
BlocDrop = Works without issue
Block'em Sock'em = Black screen
BonQ = Works without issue
Cannon in D - D for Defense = Work without issue
Cartesian Chaos = Graphic issue throughout
Crazy Brix = Brix display incorrectly
Crazy Otto = Works without issue
Danger Zone = Graphic issue throughout
Death Merchant = Graphic issue throughout
Donkey Kong PK = No audio
DopeWars = Graphic issue throughout
Dragon's Cache = Works without issue
Dragon's Descent = Works without issue
Dragon's Havoc = Graphic issue throughout
Drelbs = Works without issue
Drone Patrol = Black Screen
Drunk Witch = Works without issue
Dungeon Stalker = Works with issue
E.X.O. = Black screen 
FailSafe = Works without issue
FlappyBird = Works without issue
Freeway = Graphic issue throughout
Frenzy (w-Berzerk) = Works without issue
Froggie = Some POKEY notes incorrect
Frogus = Black screen
Galaxian = Plays without issue
Game of the Bear - Polar Opposites = Works without issue
Get Lost = Works without issue
Ghosts'n Goblins = Graphic issue throughout
Graze Suit Alpha = Works without issue
Harpy's Curse = Black screen
Harry's Hen House = Works without issue
Heartlight = Works without issue
I.C.B.M. = Graphic issue throughout
Jacks or Better = Graphic issue throughout
Jr Pac-Man = Works without issue
K.C. Munchkin = Works without issue
Keystone Koppers = Black screen
Klax = Black screen
Knight Guy - Quest for Something = Works without issue
Knight Guy in Low Res World - Castle Days = Works without issue
Knight Guy on Board - 30 Squares of Fate = Works without issue
Legend of Silverpeak = Black screen
Lunar Patrol = Graphic corruption throughout

Meteor Shower = Works without issue
Millie & Molly = Black screen
Missing In Action = Graphic issue throughout
Moon Cresta = Works without issue
Ms. Pac-Man Twin = Works without issue
Ninjish Guy - Perilous Island = Works without issue
Oozy the Goo - Gaiden = Works without issue
Pac-Man - Energy Drink Edition = Graphic issue with sprite bottom of maze
Pac-Man Collection - 40th Anniversary Edition = Black screen
Pac-Man Collection - 40th Anniversary Edition (Short Mazes) = Black screen
PentaGo = No POKEY sound and graphic issue throughout
Pirate Cove = Works without issue
Plink = Graphic issue throughout
Plumb Luck DX = Works without issue
Plutos = Graphic issue throughout
Poetiru = Works without issue
Pong = Graphic issue throughout
Popeye = No POKEY sound and graphic issue throughout
RatTrap = No POKEY sound and graphic issue throughout
Rescue On Fractalus = Black screen after starting game
ReZolve = Works without issue
Rikki and Vikki (No Music) = Works without issue
Rip-Off = Works without issue
Robbo = No sound
Robots Rumble = Black screen
Santa Simon = Works without issue
Scramble = Sound issue
Sentinel = Needs light gun support
Serpentine = Black screen
Sick Pickles = Works without issue
Sirius = Works without issue
Slide Boy in Maze Land = Works without issue
Space Duel = Speed/Timing Issue
Space Invaders = Works without issue
Space Peril! = Graphic issue throughout
Space Race = Graphic issue throughout
Spire of the Ancients = Graphic issue throughout
Super Circus AtariAge = Works without issue
Super Pac-Man = Works without issue
T:ME Salvo = Works without issue
Touchdown Challenge = Graphic issue throughout
Tunnels of Hyperion = Works without issue
UniWarS = Works without issue
Wasp! = Works without issue
Wizard's Dungeon = No background sound and graphic issue throughout
Wordle = Graphic corruption - letter selection area
Worm! = Works without issue

 

Not even a good showing for the 7800 to state the least.  Hopefully, @TrogdarRobusto and @Ben from Plaion are able to take note and ensure this is communicated fully to the necessary parties to ensure a better product is delivered; or at least, a planned firmware upgrade accordingly.  Between this post and the one listing issues with the original Retail library since ProSystem 1.3e is being leveraged for the 2600+ system, there is still a lot to be desired concern 7800 compatibility and respectable playability.

Hi Robert

 

sure..these are the results on an emulator.

There is only one Homebrew, which works onthe 2600+ ....MS Pac fast...released by Bob in small

quantities....

All my other homebrews and hacks do not work.

 

Greetings Walter

[Trebor]

1 hour ago, gambler172 said:

Hi Robert

 

sure..these are the results on an emulator.

There is only one Homebrew, which works onthe 2600+ ....MS Pac fast...released by Bob in small

quantities....

All my other homebrews and hacks do not work.

 

Greetings Walter

Evidently, at best, the ProSystem.dat file being utilized under 2600+, is much older or/and missing many entries than the one utilized by RetroArch.

 

At worst, the above applies, in addition to 2600+ possibly utilizing source code from a ProSystem emulator version older than 1.3e.

 

Either case would result in the current 2600+ experience.

 

The testing I performed was with the understanding that version 1.3e of the ProSystem emulator was being utilized with the most commonly paired and utilized ProSystem.dat file (As leveraged with RetroArch).  Sadly, that is not the case, which made an already bad 7800 compatibility situation worse with the 2600+.

 

Hopefully, going forward, at least some of the issues can be sorted sooner than later.

[gambler172]

14 minutes ago, Trebor said:

Evidently, at best, the ProSystem.dat file being utilized under 2600+, is much older or/and missing many entries than the one utilized by RetroArch.

 

At worst, the above applies, in addition to 2600+ possibly utilizing source code from a ProSystem emulator version older than 1.3e.

 

Either case would result in the current 2600+ experience.

 

The testing I performed was with the understanding that version 1.3e of the ProSystem emulator was being utilized with the most commonly paired and utilized ProSystem.dat file (As leveraged with RetroArch).  Sadly, that is not the case, which made an already bad 7800 compatibility situation worse with the 2600+.

 

Hopefully, going forward, at least some of the issues can be sorted sooner than later.

Hi Robert

My homebrews do not work too. I would like to know, what I have to change....

BTW...my games work very well on e ery Prosystem emulator version

[Trebor]

33 minutes ago, gambler172 said:

Hi Robert

My homebrews do not work too. I would like to know, what I have to change....

BTW...my games work very well on e ery Prosystem emulator version

The ROM contained on the cartridge, at the very least, requires and entry inside the ProSystem.dat file that indicates the MD5 and a few other settings.

 

This is not something currently accessible to the public for the 2600+, AFAIK.

 

Here is an example:

 

The above is for the PAL version (region = 1) of Desert Falcon and the NTSC version (region = 0) of Dig Dug that are familiar to the emulator.

 

Bare in mind, having an entry does not mean it definitely will work, or will run the ROM accurately, only that the emulator will at least recognize the image and attempt to run it with the parameters that are in place.

[+mksmith]

This might have got lost in the sea of posts but this looks promising (from Ben @ Plaion):

 

BTW - very interesting read this topic! Some of the guys are now reading the dumping results from the 2600+ amongst their findings👌

 

[+Stephen]

3 hours ago, mksmith said:

This might have got lost in the sea of posts but this looks promising (from Ben @ Plaion):

 

BTW - very interesting read this topic! Some of the guys are now reading the dumping results from the 2600+ amongst their findings👌

 

Yes - it has been a fun read.  It's making me want one of these things!

[+mksmith]

Another update from Ben:

 

[+littaum]

One other thing to check (if it has not been posted already) - are the buttons on the Pro-Line controller reversed on the 2600+ when playing 7800 games as compared to a real life 7800?  I tested my retrogameboyz 7800 pad on a 2600+ at PRGE on 7800 games and confirmed that both buttons work, but it wasn't clear to me if the buttons were in the right order (who reads manuals? )  as I tend to just start pressing the other button if the first button doesn't do what I want.  On a twitter thread RetroGameBoyz confirmed both buttons work when tested on a 2600+ but they are currently reversed - and seemed to imply that was happening with Pro-Line controllers as well.

 

[John Stamos Mullet]

21 minutes ago, littaum said:

One other thing to check (if it has not been posted already) - are the buttons on the Pro-Line controller reversed on the 2600+ when playing 7800 games as compared to a real life 7800?  I tested my retrogameboyz 7800 pad on a 2600+ at PRGE on 7800 games and confirmed that both buttons work, but it wasn't clear to me if the buttons were in the right order (who reads manuals? )  as I tend to just start pressing the other button if the first button doesn't do what I want.  On a twitter thread RetroGameBoyz confirmed both buttons work when tested on a 2600+ but they are currently reversed - and seemed to imply that was happening with Pro-Line controllers as well.

 

They are. It was already discussed over in the 2600+ subforum.

[+Defender_2600]

"Apparently every single retail and homebrew 7800 game works with the update, including Rikki and Vikki.

 

I've got a revised build this morning and sent it on for checks.'