Jump to content
IGNORED

Need help building a list of what does NOT run on the 2600+! Games -and- Hardware


Recommended Posts

1 hour ago, Giles N said:

Could it be R&V is not region-specific or - playable both on PAL and NTSC?

I have played it on 7800 PAL only. But I assume that it works on NTSC also.

10 hours ago, karri said:

I have played it on 7800 PAL only. But I assume that it works on NTSC also.

@RevEng

 

- have you tried several 2600+ dumpers (just to ruke out its not the one you use who is ‘picky’?)

 

- does it happen, have it happened, to other known carts (during the firmware-upgrade process), that the dumper doesn’t even ‘want to’ ‘consider it’, but just goes into no cart detected?

   If so, what caused the rejection?

 

- on how many categories can the R & V carts pins/contacts possible present itself as (so different) than other 7800 carts as be not detected

 

- what are the most fundamental things the dumper would loon for in a 7800 cart in order to begin load it, not load? Does it try to load anything that has right type of pins, and fits into it?

   Does it have a system of priorities to sort carts, functional from non-functional (would it have tried to load a physically new and funtional cart with gibberish code on it?). 
What are the core things it wants’ for detecting ‘something to try to load’?

14 hours ago, karri said:

I had a lot of these failed starts on real 7800 with my Pico based carts. But the 2600+ reads the cart over and over again. So this makes no sense. The 2600+ reads a Pico cart several times until the Pico has booted and can deliver correct data.

 

Perhaps the dumper needs to behave like a real 7800 and not start dumping in random order?

I'm not sure what you mean when you say it's dumping in random order.

 

If your pico just presented 0 to the data lines all the time, I'm pretty sure you'd see the same symptoms with it. R+V isn't booting like your pico or harmony. Maybe it just doesn't like the way the 2600+ is bitbanging the cart port, so it's not presenting any data. Maybe there's something else that's causing the bank logic to freak out. The only other similar "all zero" failure we see is with one of the rom chips in some Crossbow carts.

 

4 hours ago, Giles N said:

@RevEng

 

- have you tried several 2600+ dumpers (just to ruke out its not the one you use who is ‘picky’?)

 

- does it happen, have it happened, to other known carts (during the firmware-upgrade process), that the dumper doesn’t even ‘want to’ ‘consider it’, but just goes into no cart detected?

   If so, what caused the rejection?

 

- on how many categories can the R & V carts pins/contacts possible present itself as (so different) than other 7800 carts as be not detected

 

- what are the most fundamental things the dumper would loon for in a 7800 cart in order to begin load it, not load? Does it try to load anything that has right type of pins, and fits into it?

   Does it have a system of priorities to sort carts, functional from non-functional (would it have tried to load a physically new and funtional cart with gibberish code on it?). 
What are the core things it wants’ for detecting ‘something to try to load’?

The cart isn't dumping at all, otherwise Kari would have seen the dump, so switching or sorting dumpers wouldn't help.

The cart has to present consistent non-zero data for it to run through the dumper code. It's possible that a valid 7800 cart might eventually have the dump aborted due to failing heuristics that are also present in the 7800 bios (valid start address, 7800 cart type value, etc) but that would take longer than what Kari is reporting.

On 9/10/2024 at 7:42 AM, karri said:

Yep. I meant that it does not appear to like bit banging the cart. The dumper just reports 0xEA once every 4 seconds.


Ok, can you (re-)program

the dumper to be less picky, or actually get to like some seconds of bit banging?

Of is it all set in stone & hardwired once and for all?

 

If the dumper can be programmed to rather do some double-checking, rather than not load something that appears ‘strange’, perhaps it would discover what starts R & V on original hardware.

 

 

On 9/10/2024 at 4:35 AM, RevEng said:

The cart has to present consistent non-zero data for it to run through the dumper code.

Like the entirety of the games’ ROM, or just a segment which starts the game in the first place?

 

If all the 2600+ dumper needs is to not be alienated by some lack of meaningful start-up ‘code-phrase’, perhaps the ‘code-phrase’ that starts  R & V  can be extracted from looking at what happens in original hardware.

Then, perhaps the 2600+ dumper could be instructed to look for the  

R & V  start-up phrase, which have been given the dumper in advance?

 

Edited by Giles N
On 9/10/2024 at 4:35 AM, RevEng said:

The cart isn't dumping at all, otherwise Kari would have seen the dump, so switching or sorting dumpers wouldn't help.

Do you have alternative or other types of hardware(-set ups) using dumpers, that can provide alternative information to whats going on…?

 

For example, a dumper connected to a PC, which shows what sort of start-up-line/info is acceptable for a real 7800?

 

Or, for that matter, just some very direct means of ‘seeing’ what makes the difference between what really happens when a real 7800 reads a R&V cart, and compare it to some process/program revealing exactly how the 2600+ tries to do it?


If the 2600+ now just quits looking after 1 second, I would just think that the first info it finds concerning compatibility is very ‘off’ or ‘alien’ as to what it usually finds acceptable? 
 

Is the info coming out of full image, full line of data from the pins (which then seems to be taken as gibberish), or only from a little segment, like beginning to read a sentence, but breaking off thinking its not actual information in here…?

 

Could the R&V start-up data be extracted from another hardware-setup, and just be imported into the 2600+ dumper-software to ‘look for’ (contra reject)?

The guys working on the dumper have also created Souper support for emulators @raz0red. So the skill to make the dumper to work is there.


But it won't fetch the music.

 

You can get the full experience with the music from Steam to your PC.

 

So I am not so sure that it is worth the effort to get just the game without the music to the 2600+.

  • Like 1

Anyone having trouble with Fishing Derby?

I cleaned my contacts really good and it takes about 5 or 6 attempts for it to work right. 

All other games are just about fine. 

 

I'm on Firmware V5 and the dumper update 01.

 

 

Edited by DhaemonX
5 minutes ago, DhaemonX said:

Anyone having trouble with Fishing Derby?

I cleaned my contacts really good and it takes about 5 or 6 attempts for it to work right. 

All other games are just about fine. 

 

I'm on Firmware V5 and the updated dumper.

 

 

I have no problems with my PAL-version. But it is an Activision cartridge..... These are known to be a bit difficult. Like others already have mentioned, puling Activision cartridges just slightly out (just 1 millimeter or so) often helps.

  • Thanks 1
On 8/25/2024 at 2:31 PM, Ben from Plaion said:

Is this the game that needs the HALT line connected @RevEng?

Rikki & Vikki needs HALT connected in a genuine 7800 to perform graphics paging, but if you're just reading the cartridge's data off it can be held HIGH.

 

On 9/8/2024 at 2:13 AM, Giles N said:

They contact TailChao and asks for permission to import the R & V music onto the 2600+ Firmware on the next update, and when the R & V cart is detected physically, the FW uses the preloaded music file, now in the 2600+ FW code, as the tracker.

This is the easiest solution for many of the games which have nonextractable data, yes.

 

On 9/9/2024 at 10:35 PM, RevEng said:

If your pico just presented 0 to the data lines all the time, I'm pretty sure you'd see the same symptoms with it. R+V isn't booting like your pico or harmony. Maybe it just doesn't like the way the 2600+ is bitbanging the cart port, so it's not presenting any data. Maybe there's something else that's causing the bank logic to freak out. The only other similar "all zero" failure we see is with one of the rom chips in some Crossbow carts.

This sounds like PHI2 isn't toggling. Is the 2600+ / 7800+ performing a fully compliant 6502 bus cycle for every read or write?

What I mean is...

 

  1. Start with PHI2 low.
  2. Set the address and R/W.
  3. Drive the data bus (if writing).
  4. Wait a bit...
  5. Set PHI2 high.
  6. Wait a bit...
  7. Read the data bus (if reading).
  8. Set PHI2 low.
  9. Wait a bit...
  10. Release the data bus (if writing).
  11. goto 1.
     

My offer to send in a cartridge still stands, if compatibility is actually desired.

  • Like 2
  • Thanks 3
12 hours ago, TailChao said:

This is the easiest solution for many of the games which have nonextractable data, yes.

Theoretically, this has been talked about and agreed workable in principle for CDFJ.

 

Implementation is another thing.

Edited by Ben from Plaion
2 hours ago, Ben from Plaion said:

Theoretically, this has been talked about and agreed workable in principle for CDFJ.

 

Implementation is another thing.

I presume because the majority of Champ Games are potentially IP copyright infractions?

3 hours ago, John Stamos Mullet said:

I presume because the majority of Champ Games are potentially IP copyright infractions?

In the software engineering world (and speaking as a Java/Swift/Objective-C/C engineer), the solution doesn't scale.    Sure you can maybe do that for some of the games, but now you have to update the firmware *** every time *** there's a new release where there's some data hidden in an area where the dumper can't see.

 

Only way I see that they will ever solve the home-brew thing in a way that scales are ways that I don't see happening:
 

- Atari starts using real-time interpretation of what's coming off the cartridge line much like the real hardware would have instead of "dump and run" (I know there's an effort here, but likely scope is enormous and would take years, if it ever made it in)

- FPGA (non-starter)

- Run Flashback 2 style original hardware that can read carts in real time (likely non-starter)

- CDFJ authors re-write their games (likely non-starter for the authors involved)

Edited by ForceInfinity
8 hours ago, ForceInfinity said:

In the software engineering world (and speaking as a Java/Swift/Objective-C/C engineer), the solution doesn't scale.    Sure you can maybe do that for some of the games, but now you have to update the firmware *** every time *** there's a new release where there's some data hidden in an area where the dumper can't see.

 

Only way I see that they will ever solve the home-brew thing in a way that scales are ways that I don't see happening:
 

- Atari starts using real-time interpretation of what's coming off the cartridge line much like the real hardware would have instead of "dump and run" (I know there's an effort here, but likely scope is enormous and would take years, if it ever made it in)

- FPGA (non-starter)

- Run Flashback 2 style original hardware that can read carts in real time (likely non-starter)

- CDFJ authors re-write their games (likely non-starter for the authors involved)

 

Yes, but in this case we are talking about one of the best games for the 7800 (Rikki & Vikki), what is called a killer application. That is why people talk about it so much, so not exactly the "every time" circumstance.

 

Also, we currently only have two non-compatible 7800 games and we will not have an FPGA solution from Atari for many years.

Edited by Defender_2600
4 hours ago, Defender_2600 said:

 

Yes, but in this case we are talking about one of the best games for the 7800 (Rikki & Vikki), what is called a killer application. That is why people talk about it so much, so not exactly the "every time" circumstance.

 

Also, we currently only have two non-compatible 7800 games and we will not have an FPGA solution from Atari for many years.


And that is fair.  
 

I was just responding the back-and-forth about why there would be deliberation on including code bits in the firmware.   
 

If we’re talking the one game, then fair point.   But then we start getting into ‘what about x and what about t’ and the Pandora’s box gets thrown open and now you got the scope creep.  I see these kinds of discussions pop up all the time in my day to day work between PM’s and SDE’s

 

With that, I’ll shut my mouth and go find a YT video to see what R & V is all about because I missed out on that one

I just got Pitfall II in the mail that eBay said was tested and working.

It won't run. I cleaned the contacts, it attempts to load but it either says loading game and I get no game found or I get this horrible sound and a bunch of lines with colors on the screen. 

 

I am using updated firmware version 5 and dumper version 1.

If I take out the game with the line and strange sound it will continue to play. 

I paid a good bit of $$$ for this game. Feeling a bit defeated at the moment.

 

 

PXL_20240916_211049288.jpg

PXL_20240916_211048597.jpg

PXL_20240916_211815572.PORTRAIT.ORIGINAL.jpg

Edited by DhaemonX
1 hour ago, DhaemonX said:

I just got Pitfall II in the mail that eBay said was tested and working.

It won't run. I cleaned the contacts, it attempts to load but it either says loading game and I get no game found or I get this horrible sound and a bunch of lines with colors on the screen.

Zoom in on those cartridge contacts...

image.thumb.png.91f3179195e6f20eb53f802ce2eeec60.png

 

They are dirty.  The side shown and perhaps/probably the other side need to be cleaned more thoroughly.   

 

Instead of a back and forth sweeping motion.  Scrub up and down.  Try a Q-Tip and 91% Isopropyl Alcohol.

  • Thanks 1
8 minutes ago, Trebor said:

Zoom in on those cartridge contacts...

image.thumb.png.91f3179195e6f20eb53f802ce2eeec60.png

 

They are dirty.  The side shown and perhaps/probably the other side need to be cleaned more thoroughly.   

 

Instead of a back and forth sweeping motion.  Scrub up and down.  Try a Q-Tip and 91% Isopropyl Alcohol.

I'm using 99% and a QTip. I'll try the scrub up and down. Thank you.

So I cleaned more of it off, but the situation has not changed. Also if I take out the cartridge it's still gives me the weird screen and or sounds until I power of the Atari.

 

Here is the cleaner contacts and the video of how it acts now.

 

PXL_20240916_232900617.PORTRAIT.jpg

It may be beyond recovery. 

If possible, you may want to try it on an original 2600 or 7800 console to see if it even would work there. 

The last couple of pins, especially on the far right, has some significant corrosion.

image.thumb.png.7ae713cca513f29e5e95ce570a04d942.png

Pitfall II definitely works with the 2600+, has been the case since version 1.1x-r3 of the firmware. 

 

EDIT: Another thread is discussing this particular cartridge too. 

Probably best to keep this thread from being bogged down with the same cartridge being cross posted. ;)

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...