Little home project: ROM dumper

[Thomas Jentzsch]

5 hours ago, SvOlli said:

... I can tell which bytes differ between download and cartridge.

Signs of watermarking? Or just a few bytes?

[Dionoid]

11 hours ago, Thomas Jentzsch said:

Signs of watermarking? Or just a few bytes?

I guess to find watermarking, you'll need the ROMs for two different serial numbers?

[Thomas Jentzsch]

Watermarking should have bits and bytes changed all over the ROM.

[Dionoid]

Hi @SvOlli, I can’t seem to find a place to order a 24-pin cartridge slot in Europe. Where did you buy yours?

The best I could find is this on eBay, shipping from Taiwan:

https://www.ebay.nl/itm/133593578172

[SvOlli]

4 minutes ago, Dionoid said:

Hi @SvOlli, I can’t seem to find a place to order a 24-pin cartridge slot in Europe. Where did you buy yours?

The best I could find is this on eBay, shipping from Taiwan:

https://www.ebay.nl/itm/133593578172

Since it's been quite some time, I can't remember for sure. But I think I found some German reseller on eBay who charged for a single one about as much as your find wants to have for a pack of 10.

[Dionoid]

For whoever is interested: I found another 24-pin cartridge connector on AliExpress, which has additional screw-holes on the side:

https://nl.aliexpress.com/item/4000169102431.html

 

[OriginalJohn]

What about this one??

https://www.digikey.com/en/products/detail/te-connectivity-amp-connectors/5530843-1/2310824

[Dionoid]

On 4/29/2021 at 11:02 PM, Dionoid said:

I just ordered a Teensy++ 2.0 from eBay to be able to build your dumper. Looking forward to it!

The Teensy that I bought from eBay turned out the be a counterfeit, and has issues with serial communication - each time I dump a rom, approx. 5% of the bytes are random. ?

I asked for a refund, and ordered a new Teensy from an official PJRC reseller...

[SvOlli]

Well you can try to set the baud rate down. With 9600 baud, the transfer might become more stable, even though a dump will take significantly more time. But since you only need to dump once...

 

Edit: you need to change this in the source code and compile both sides, host and Arduino.

Edited May 26, 2021 by SvOlli

[Dionoid]

14 hours ago, SvOlli said:

Well you can try to set the baud rate down. With 9600 baud, the transfer might become more stable, even though a dump will take significantly more time. But since you only need to dump once...

 

Edit: you need to change this in the source code and compile both sides, host and Arduino.

Yes, I thought about using a lower baud rate, but I rather use a genuine Teensy instead of the counterfeit.

Eventually I want to use this setup to do a PoC where the Stella emulator is reading bytes directly from the cartridge, instead of a rom file. I'm aware it will probably run only at 10% speed, but it's just a PoC.

 

[Dionoid]

Now using a genuine Teensy++ 2.0, the dumper works flawlessly!

 

[Yoruk]

Great news !

 

How many time does it take for a standard dumping at full speed ?

[Dionoid]

7 hours ago, Yoruk said:

Great news !

 

How many time does it take for a standard dumping at full speed ?

It takes around 3-4 seconds for a 4K cartridge dump, IIRC.

Edited May 28, 2021 by Dionoid

[Dionoid]

Hi @SvOlli, I'm working on support for the Arduino Nano, and I have the sketch working.

• when I open the Serial Monitor in the Arduino IDE and send the command 'rF000', it returns the first ROM byte correctly
• when I send the command 'dF000 1000', it returns all the hexadecimal values of a 4k cart as a long string.

However... I cannot get the dump2600.exe working with the sketch on the Arduino Nano. It looks like the dump-tool is waiting on something. This is what is shows:

 

C:\git\retrocartdumper>dump_2600.exe COM4 4k test.bin
0000

Then after a minute of nothing happening, I just kill the process with Ctrl-C.

 

I've tried to lower the baudrate to 9600 (both in dump2600 and in the sketch), but that didn't help. Note that the dump2600 works fine when I run it on the Teensy.

 

Do you have any suggestions on what might be the problem?

 

Edited May 28, 2021 by Dionoid

[SvOlli]

I've used the Teensy, because a Nano does not have enough GPIOs.

We need as a bare minimum:

• 13 for address lines (bidirectional)
• 8 for data lines (also bidirectional, required for 3F bankswitching for example)
• 2 for UART (1 input, 1 output)

An Arduino Nano has:

• 2 for UART (D0, D1)
• 11 digital (D2-D13)
• 6 analog/digital (A0-A5)
• 2 pure analog (A6, A7), which won't work

So that's 23 required vs 19 available, and I have no idea how this could be made working without some additional hardware.

[SvOlli]

7 hours ago, Yoruk said:

How many time does it take for a standard dumping at full speed ?

I've never optimized it for speed, I just wanted to dump some ROMs for running in an emulator and Uno Cart 2600. The transfer protocol is also intentionally kept simple, so there's less chance for errors: all data transfer is encoded in hex instead of binary. This divides the transfer time by two. Also the Baud rate is selected very conservative with 38400, more on the stability side, since I had problems running on 115200.

[Dionoid]

For the Nano, I've wired the cartridge's A12 signal to +5V, as I had no more free IO pins. This means that on the Nano, only bankswitching schemes are supported which use hotspots within the cartridge ROM address space (i.e. f8, f6, f4, parker, CBS, M-Network), so not for example TigerVision's $3f.

That is indeed a limitation, but IMO still acceptable for people that want to tinker around with a cheap Arduino Nano clone - I recently bought one for 5 euro on Amazon.

 

So in total, I'm using 20 GPIO pins on the Nano (D2-D13 + A0-A7). This is the bare minimum to dump cartridges which use bankswitch hotspots within the ROM address space. And of course for cartridges that don't use bankswitching at all ?

A6 and A7 are indeed analog-in only ports, but converted to digital like this:

static inline uint8_t peek( uint16_t addr )
{
  setaddr( addr );

  uint8_t data = PINC;
  if (analogRead(A6) > 512) data |= B01000000;
  if (analogRead(A7) > 512) data |= B10000000;
  
  return data;
}

I've got the Nano already dumping the correct HEX data in the Serial Monitor, only the dump2600.exe tool isn't working (yet) with the Nano. Maybe the Teensy serial libraries add some magic, which isn't in the default Arduino libs.

Edited May 31, 2021 by Dionoid

[SvOlli]

Is the Nano based upon the 328P or the 168P? From my different projects I noticed that the 168P gets programmed using something like 19200 instead of 57600 or 115200 like the 328P. I'm pretty sure that this was for a reason...

[Dionoid]

58 minutes ago, SvOlli said:

Is the Nano based upon the 328P or the 168P? From my different projects I noticed that the 168P gets programmed using something like 19200 instead of 57600 or 115200 like the 328P. I'm pretty sure that this was for a reason...

It's an 328P with a CH340 USB to Serial chip (instead of an FT232 chip)

[Dionoid]

7 hours ago, Dionoid said:

However... I cannot get the dump2600.exe working with the sketch on the Arduino Nano. It looks like the dump-tool is waiting on something. This is what is shows:

C:\git\retrocartdumper>dump2600.exe COM4 4k test.bin
0000

Then after a minute of nothing happening, I just kill the process with Ctrl-C.

 

I've tried to lower the baudrate to 9600 (both in dump2600 and in the sketch), but that didn't help. Note that the dump2600 works fine when I run it on the Teensy.

 

Do you have any suggestions on what might be the problem?

 

I was able to get dump2600.exe working with the Nano at 38400 baud, by disabling some lines in windows/serial.c. I basically removed most of the DCB settings and only kept BaudRate, Parity, StopBits and ByteSize. So apparently one of the other settings was conflicting with the Arduino/CH340 driver.

 

@SvOlli Could you please test if dump2600.exe still works for you, if  you only keep these settings in windows/serial.c?

   memset( &dcb, 0, sizeof( dcb ) );

   dcb.DCBlength       = sizeof(dcb);      

   dcb.BaudRate        = baud;
   dcb.Parity          = NOPARITY;
   dcb.StopBits        = ONESTOPBIT;
   dcb.ByteSize        = 8;

 

Edited May 29, 2021 by Dionoid

[SvOlli]

On 5/28/2021 at 11:17 AM, Yoruk said:

How many time does it take for a standard dumping at full speed ?

Now that I needed to dig out my dumper for a test run I've got some more reliable numbers: the Teensy++ 2.0 it takes about 1.1s for dumping 1k of data.

 

These also have been some code changes to the Teensy++ 2.0 firmware. But these are purely cosmetic. The intention is to make maintaining more that one board at bit easier.

[Dionoid]

Here are some pictures of my breadboard-setup of @SvOlli's Rom Dumper, but this time using an Arduino Nano, for which I added the code to his retrocartdumper project on GitHub.

 

Note that the Nano has the bare minimum of the required 20 GPIO pins for dumping of Atari 2600 cartridges. I had to connect the cartridge's address A12 signal to +5V, which basically works as the chip-select for the ROM. This means that only bankswitching schemes are supported which use hotspots within the cartridge ROM address space.

For most cartridges brands (e.g. Atari, Activision, Imagic, CBS, M-Network and Parker Brothers) this is sufficient. If you need support for dumping TigerVision's 3F or Superbanking cartridges, please use the Teensy++ 2.0 microcontroller instead.

Also, since the A6 and A7 pins on the Nano are analog-in only, writing to the the data bus is not supported on the Nano, but only on the Teensy.

 

Picture of dumping a PAL Fatal Run cartridge (which has F4 bankswitching + SuperChip) using a cheap €5 Arduino Nano clone:

 

Note that I had to lift the 24-pin cartridge connector on its legs as high as possible, because the connector wasn't tall enough to give the cartridges enough clearance when inserting them.

 

[Dionoid]

Hi @SvOlli, I was comparing some F8 cartridge roms which were dumped with dump2600.exe to external roms which I downloaded before.

I noticed that, for the same games, some F8 rom dumps have different bytes in the hotspot locations xFF8 and xFF9. Some use $00, others use $FF and others seem to contain a byte-value which was actually read from the cartridge in that hotspot location.

 

For a correct working of the rom it probably doesn't matter what byte-value is in the bankswitch hotspot location, as the byte probably isn't used. But theoretically it could be used, right?
Anyway, it seems there is no convention for dumpers. I prefer the way you are doing it in the dump2600 utility, which for F8 hotspots is doing:

• read byte from hotspot location $FFF8 and store in ROM-buffer locations $0FF8 and $1FF8
• read byte from hotspot location $FFF9 and store in ROM-buffer locations $0FF9 and $1FF9

Question: do you know if F8 carts always return the same byte when reading the hotspot location, or maybe it just returns the byte which was set on the bus by the previous read?

 

 

Edited August 10, 2022 by Dionoid

[SvOlli]

Here we are leaving the digital area and go into analogue. Or to put it another way: I don't think there's a "correct" way to solve this problem, as I can think of ways to implement the bank switch before and after the triggering read. As it's by definition a strobe register, the value read doesn't matter.

 

And the most important point: to have the dumper correctly mimicking a 2600 there, you need the correct "CPU" frequency to access the ROM, as well as "matching" pull-up resistors.

 

And since the dumper is much slower because of getting all data through the UART, I never bothered, knowing the data I read will always be "too late", but never "too early".

[Mr SQL]

3 hours ago, Dionoid said:

Question: do you know if F8 carts always return the same byte when reading the hotspot location, or maybe it just returns the byte which was set on the bus by the previous read?

 

3 hours ago, SvOlli said:

And the most important point: to have the dumper correctly mimicking a 2600 there, you need the correct "CPU" frequency to access the ROM, as well as "matching" pull-up resistors.

 

I'm curious what values you retrieve for CBS RAM if you try a Tunnel Runner cart.  Answer may be related to the F8 Superchip question. Currently there are three ways to define it, low high or random.