Pitfall 2 Question

[OscarGungan]

I had heard emulating Pitfall 2 had always been a challenge because of some technical issues that I'm not sure I totally understand. Is it fair to speculate its something that may not ever be compatible on the 2600+ or would it just be a matter of time?

[Thomas Jentzsch]

Seems fair.

[CapitanClassic]

Anytime additional hardware is used in a game, creating an emulator for a game system requires also emulating the additional hardware as well. You might have noticed this with early releases of other emulators like NES that don’t support certain cart mappers, or SNES emulators that don’t support additional chips like SuperFX (Starfox) or Cx4 (MegaMan X).
 

David Crane explains how the chip inside the Pitfall II cart works here.

 

[Laner]

Pitfall II is supported through Stella on other platforms. I'm not sure what would prevent it from working on the 2600+

[Thomas Jentzsch]

13 minutes ago, Laner said:

I'm not sure what would prevent it from working on the 2600+

Because it cannot be dumped completely. The dumper can only dump what is visible at the cart port. But carts with extra chips (Pitfall II, Melody enhanced homebrews, Harmony, PlusCart...) have data which is only used internally. Yet, Stella needs it to emulate the internals too.

[John Stamos Mullet]

11 hours ago, Thomas Jentzsch said:

Because it cannot be dumped completely. The dumper can only dump what is visible at the cart port. But carts with extra chips (Pitfall II, Melody enhanced homebrews, Harmony, PlusCart...) have data which is only used internally. Yet, Stella needs it to emulate the internals too.

but it could be re-written to recognize the cart type and pull a working rom from memory instead of dumping the cart in that particular case. Not unlike Prosystem, match the MD5 of the file to Pitfall II and then run the rom stored from the internal storage (instead of the cart).

Edited December 1, 2023 by John Stamos Mullet

[Thomas Jentzsch]

1 hour ago, John Stamos Mullet said:

but it could be re-written to recognize the cart type and pull a working rom from memory instead of dumping the cart in that particular case. Not unlike Prosystem, match the MD5 of the file to Pitfall II and then run the rom stored from the internal storage (instead of the cart).

Legal problems, especially for Pitfall II. 

[John Stamos Mullet]

1 hour ago, Thomas Jentzsch said:

Legal problems, especially for Pitfall II. 

Yeah, I realize it's probably likely, but it *could* be done. Not saying it will.

[Eckhard Stolberg]

14 hours ago, Thomas Jentzsch said:

Because it cannot be dumped completely. The dumper can only dump what is visible at the cart port. But carts with extra chips (Pitfall II, Melody enhanced homebrews, Harmony, PlusCart...) have data which is only used internally. Yet, Stella needs it to emulate the internals too.

I don't know about all the modern ARM based cartridges, but all the data in the Pitfall II ROM image that Stella can play is available through the cartridge port. The 7800 DevOS cartride dumper can read the Pitfall II ROM just fine. I'd have to dig out the source code to see how exactly to access the graphics ROM and the random number generator, but I don't remember it being that complicated. If the cartridge dumper in the 2600+ is able to write data to the cartridge, it should be able to read the Pitdfall II ROM as well.

[+Mitch]

1 hour ago, Eckhard Stolberg said:

I don't know about all the modern ARM based cartridges, but all the data in the Pitfall II ROM image that Stella can play is available through the cartridge port. The 7800 DevOS cartridge dumper can read the Pitfall II ROM just fine. I'd have to dig out the source code to see how exactly to access the graphics ROM and the random number generator, but I don't remember it being that complicated. If the cartridge dumper in the 2600+ is able to write data to the cartridge, it should be able to read the Pitfall II ROM as well.

If you are digging through the DevOS source any chance for a x64 exe?

 

And welcome back.

 

Mitch

[Thomas Jentzsch]

8 hours ago, Eckhard Stolberg said:

I don't know about all the modern ARM based cartridges, but all the data in the Pitfall II ROM image that Stella can play is available through the cartridge port. The 7800 DevOS cartride dumper can read the Pitfall II ROM just fine. I'd have to dig out the source code to see how exactly to access the graphics ROM and the random number generator, but I don't remember it being that complicated. If the cartridge dumper in the 2600+ is able to write data to the cartridge, it should be able to read the Pitdfall II ROM as well.

Sounds cool. I am more than interested to find out.

 

Is the source code available somewhere? I found this in archiv.org, it that containing the latest code?

void dump_P2BS(void)
{
unsigned int z;
   for(z=0; z<2; z++)
   {
      write_byte(0xfff8+z, z);
      dump_noBS(15, 0xf0);
      read_buffer(0xff00, 0xf8);
      bufcount=bufcount+2;
      read_buffer(0xfffa, 6);
      printf("%3u\r",bufcount>>8);
   }
   write_byte(0xf050, 0xff);	/*counter for extra ROM low byte value*/
   write_byte(0xf058, 0x07);	/*counter for extra ROM high byte value*/
   for(z=0; z<8; z++)
   {
      read_onespot(0xf008, 256);
      printf("%3u\r",bufcount>>8);
   }
   write_byte(0xf070, 0x00);	/* reset random number generator */
   read_onespot(0xf000, 255);
   printf("\nadding 255 bytes of random number generator data");
}

 

The 1st half of the code seems to dump the first 8K (just like F8). And the 2nd half looks like you can make the extra data visible at 0xf000 and 0xf008. Correct?

 

@Eckhard Stolberg Can you explain the detection code? testtype.das is not commented.

 

@Ben from Plaion I stay corrected, Pitfall II can be dumped. And it doesn't seem too difficult. Maybe your developers should analyze the 7800 DevOS dumper code.

 

@batari Does something similar work for the ARM carts?

Edited December 2, 2023 by Thomas Jentzsch

[Eckhard Stolberg]

15 hours ago, Mitch said:

If you are digging through the DevOS source any chance for a x64 exe?

 

And welcome back.

 

Mitch

Hey Mitch, thanks for the welcome. Nice to see you are still around. 🙂 Unfortunately I don't  have any of the nessessary tools installed on my computer anymore, and my Atari stuff is packed away, so a x64 exe is probably not going to happen anytime soon. Sorry.

[Eckhard Stolberg]

9 hours ago, Thomas Jentzsch said:

Sounds cool. I am more than interested to find out.

 

Is the source code available somewhere? I found this in archiv.org, it that containing the latest code?

void dump_P2BS(void)
{
unsigned int z;
   for(z=0; z<2; z++)
   {
      write_byte(0xfff8+z, z);
      dump_noBS(15, 0xf0);
      read_buffer(0xff00, 0xf8);
      bufcount=bufcount+2;
      read_buffer(0xfffa, 6);
      printf("%3u\r",bufcount>>8);
   }
   write_byte(0xf050, 0xff);	/*counter for extra ROM low byte value*/
   write_byte(0xf058, 0x07);	/*counter for extra ROM high byte value*/
   for(z=0; z<8; z++)
   {
      read_onespot(0xf008, 256);
      printf("%3u\r",bufcount>>8);
   }
   write_byte(0xf070, 0x00);	/* reset random number generator */
   read_onespot(0xf000, 255);
   printf("\nadding 255 bytes of random number generator data");
}

 

The 1st half of the code seems to dump the first 8K (just like F8). And the 2nd half looks like you can make the extra data visible at 0xf000 and 0xf008. Correct?

 

@Eckhard Stolberg Can you explain the detection code? testtype.das is not commented.

 

@Ben from Plaion I stay corrected, Pitfall II can be dumped. And it doesn't seem too difficult. Maybe your developers should analyze the 7800 DevOS dumper code.

 

@batari Does something similar work for the ARM carts?

I think that's the only version of the source code that I published. I changed the connection to an FTDI cable and added some more bankswitching types when needed later, but I think I only posted the binaries for those versions.

 

You read the code correctly. First, two 4K banks get read, like for normal F8 bankswitched games. Note that I'm skipping the bankswitching hotspots in both banks to avoid having to reset the bank and to deal with possible random values for these addresses. I do that for all bankswitching types and RAM setups. I simple fill the ROM image with 0xff for all those addresses, since that is what ROM chips usually have for unused bytes. I don't think that ever caused a problem with any game.

 

Then 0xff gets written to 0xf050 and 0x07 gets written to 0xf058. That sets to first data fetcher in the DPC to the highest address in the graphics ROM (0x07ff). That way we can read the full 2K of graphics ROM data from the first data fetcher at 0xf008.

 

Finally we write 0x00 to 0xf070. That resets the pseudo random number generator, so that we can read the full 256 byte sequence from 0xf000. We probably could have added the algorthithm for that to the emulator instead, but it was easier this way, and I'm lazy. 😉

 

Yes, I guess I should have commented testtype.das a lot more. 🤔 IIRC, when we have established that we have F8 bankswitching without SuperChip RAM, the test for Pitfall II simply is to reset the random number generator and read several values from 0xf000 in a row. If they change, we assume it's Pitfall II.

[Thomas Jentzsch]

Thanks for the info.

43 minutes ago, Eckhard Stolberg said:

I think that's the only version of the source code that I published. I changed the connection to an FTDI cable and added some more bankswitching types when needed later, but I think I only posted the binaries for those versions.

Do you still have the latest code somewhere?

43 minutes ago, Eckhard Stolberg said:

Yes, I guess I should have commented testtype.das a lot more. 🤔

It is never tool late.  

 

BTW: Could one detect hotspots by simply peeking them multiple times? Are the returned values really random?

Edited December 2, 2023 by Thomas Jentzsch

[Ben from Plaion]

12 hours ago, Thomas Jentzsch said:

Sounds cool. I am more than interested to find out.

 

Is the source code available somewhere? I found this in archiv.org, it that containing the latest code?

void dump_P2BS(void)
{
unsigned int z;
   for(z=0; z<2; z++)
   {
      write_byte(0xfff8+z, z);
      dump_noBS(15, 0xf0);
      read_buffer(0xff00, 0xf8);
      bufcount=bufcount+2;
      read_buffer(0xfffa, 6);
      printf("%3u\r",bufcount>>8);
   }
   write_byte(0xf050, 0xff);	/*counter for extra ROM low byte value*/
   write_byte(0xf058, 0x07);	/*counter for extra ROM high byte value*/
   for(z=0; z<8; z++)
   {
      read_onespot(0xf008, 256);
      printf("%3u\r",bufcount>>8);
   }
   write_byte(0xf070, 0x00);	/* reset random number generator */
   read_onespot(0xf000, 255);
   printf("\nadding 255 bytes of random number generator data");
}

 

The 1st half of the code seems to dump the first 8K (just like F8). And the 2nd half looks like you can make the extra data visible at 0xf000 and 0xf008. Correct?

 

@Eckhard Stolberg Can you explain the detection code? testtype.das is not commented.

 

@Ben from Plaion I stay corrected, Pitfall II can be dumped. And it doesn't seem too difficult. Maybe your developers should analyze the 7800 DevOS dumper code.

 

@batari Does something similar work for the ARM carts?

Well that's a turn up for the books. Nice.

[Eckhard Stolberg]

2 hours ago, Thomas Jentzsch said:

Thanks for the info.

Do you still have the latest code somewhere?

It is never tool late.  

 

BTW: Could one detect hotspots by simply peeking them multiple times? Are the returned values really random?

Yes, I still have all my old code. But the latest version contains code to read Boulder Dash, so I have to be very carefull with whom I can share it. 😉

 

I don't think bankswitching hotspots are random enough to be detected that way. Even if the switch would happen in the middle of the data transfer, the value in both banks usually would be the same anyway. You'd probably get 0xff in most of the reads.

[Thomas Jentzsch]

20 minutes ago, Eckhard Stolberg said:

Yes, I still have all my old code. But the latest version contains code to read Boulder Dash, so I have to be very carefull with whom I can share it. 😉

I know someone.  

20 minutes ago, Eckhard Stolberg said:

I don't think bankswitching hotspots are random enough to be detected that way. Even if the switch would happen in the middle of the data transfer, the value in both banks usually would be the same anyway. You'd probably get 0xff in most of the reads.

Would have been too easy that way. Thanks for confirming.

Edited December 2, 2023 by Thomas Jentzsch

[chad5200]

On 12/1/2023 at 5:57 PM, Eckhard Stolberg said:

I don't know about all the modern ARM based cartridges, but all the data in the Pitfall II ROM image that Stella can play is available through the cartridge port.

This would be a huge win for the 2600+ if they got Pitfall 2 working!

[+batari]

21 hours ago, Thomas Jentzsch said:

@batari Does something similar work for the ARM carts?

Using the fetchers gets us part of the way there on DPC+. I don't think fetchers would be useful for CDFJ. DPC+ additionally has the note table for music, which isn't directly accessible, and ARM carts also have the ARM code, some of which isn't visible through simpler means.

 

While it is possible to fully dump ARM carts, it is definitely not a simple matter and will require some ingenuity.

[Thomas Jentzsch]

2 hours ago, batari said:

While it is possible to fully dump ARM carts, it is definitely not a simple matter and will require some ingenuity.

So, DPC+ might be first? Or is that still a complex task?

[tradyblix]

One thing I noticed today is that the amount of "play" in the cart dumper slot is such that, you often get bad "reads" by whatever reads the rom to send to the emulator, and this problem is exacerbated if you are above the console and hold the cart at a high angle when approaching the slot. (forgive me if this sounds too sexual)

 

When you insert with the bottom of the cart lying flat along the floor of the insertion slot (ie, a 10 degree lower angle) it connects better. I think this is due to the additional space on the 2600+ cart slot. 

Edited December 4, 2023 by tradyblix

[DEANJIMMY]

2 hours ago, tradyblix said:

One thing I noticed today is that the amount of "play" in the cart dumper slot is such that, you often get bad "reads" by whatever reads the rom to send to the emulator, and this problem is exacerbated if you are above the console and hold the cart at a high angle when approaching the slot. (forgive me if this sounds too sexual)

 

When you insert with the bottom of the cart lying flat along the floor of the insertion slot (ie, a 10 degree lower angle) it connects better. I think this is due to the additional space on the 2600+ cart slot. 

That makes sense to me, as I experience the same.

As you can move the 2600 carts inside of the slot, they sometimes fail to load and then I insert them again with two hands, sensing how thy slide in and they work.

 

How ever some cards, some people never get them working, even they run on real HW and got cleaned. 

In my case Juno First and others reported same thing about Stargate or Enduro (in my case it needs more than one try and it loads).

 

The 7800 carts fit like a glove and therefore usually work or fail, not matter how often you try.

 

But to be fair, some 2600 carts have mechanical issus on the real 7800 too and fail therefore to start (like Juno First in my case).

[tradyblix]

12 minutes ago, DEANJIMMY said:

That makes sense to me, as I experience the same.

As you can move the 2600 carts inside of the slot, they sometimes fail to load and then I insert them again with two hands, sensing how thy slide in and they work.

 

How ever some cards, some people never get them working, even they run on real HW and got cleaned. 

In my case Juno First and others reported same thing about Stargate or Enduro (in my case it needs more than one try and it loads).

 

The 7800 carts fit like a glove and therefore usually work or fail, not matter how often you try.

 

But to be fair, some 2600 carts have mechanical issus on the real 7800 too and fail therefore to start (like Juno First in my case).

Yeah. I have Beamrider, which uses a non-standard Activision cart and it's a bit finicky, but if I do it carefully with a couple attempts I can get it to read. 

 

Some carts are fine right away. My copy of Juno First works, thankfully, sorry to hear about yours. It's up there with Beamrider for one of my top 2600 games. 

 

I have some coleco (white) ones that don't work at all. It's Venture tho, so ... no big loss lol. Plus I have an Atari "Red Label" Venture that works. 

 

There's a lot of variables there but hopefully people get used to re-inserting a few times on some of these. 

Edited December 4, 2023 by tradyblix

[DEANJIMMY]

1 minute ago, tradyblix said:

Yeah. I have Beamrider, which uses a non-standard Activision cart and it's a bit finicky, but if I do it carefully with a couple attempts I can get it to read. 

 

Some carts are fine right away. My copy of Juno First works, thankfully, sorry to hear about yours. It's up there with Beamrider for one of my top 2600 games. 

 

I have some coleco (white) ones that don't work at all. 

 

There's a lot of variables there but hopefully people get used to re-inserting a few times on some of these. 

Beamrider works in my case but also needs to be inserted by a gentle slide (this sounds really odd 😉)

Some white Coleco have issues with the dumper (like Time Pilot, Donkey Kong) and others need some care or some people fail to run their copy (like Front Line).

 

And yes, Juno First hurts. I would buy an NTSC cart if possible.

@Ben from Plaion

Hopefully Atari gets the licence to put Juno First on Atariage Store again or release it via Plaion like Berzerk.

But in that case, the Atarivox should work on the 2600+ as well! This game benefits so much from the speech and of cause saving your high score🤙

[JetSetIlly]

On 12/3/2023 at 6:46 AM, batari said:

Using the fetchers gets us part of the way there on DPC+. I don't think fetchers would be useful for CDFJ. DPC+ additionally has the note table for music, which isn't directly accessible, and ARM carts also have the ARM code, some of which isn't visible through simpler means.

 

While it is possible to fully dump ARM carts, it is definitely not a simple matter and will require some ingenuity.

I must confess that the only way I can imagine it working is for the cartridge to cooperate with it's own dumping.

 

One possibility would be for the console to initiate the dumping with a port-knocking sequence. In other words, there is an agreed protocol that when a cartridge sees a particular (relatively long and unlikely) sequence of bytes on the bus it goes into "dumping mode". Once in dumping mode the cartridge can return the CDFJ (etc.) binary as a stream of bytes. Part of the protocol would be for the console to revert to the regular dumping method if it doesn't receive an initial agreed response from the cartridge.

 

As I say, the problem with this is that it requires cooperation from the cartridge. Harmony and PlusCart could be updated with new firmware to allow this but preexisting standalone ARM cartridges would be left in the cold. Going forward however, I see potential for newer ARM cartridges to indicate that they are 2600+ compatible on the cartridge livery.

 

Edited December 4, 2023 by JetSetIlly