Jump to content
SvOlli

Little home project: ROM dumper

Recommended Posts

5 hours ago, SvOlli said:

... I can tell which bytes differ between download and cartridge. ;-)

Signs of watermarking? Or just a few bytes?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

  • Thanks 1

Share this post


Link to post
Share on other sites
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...

  • Sad 1

Share this post


Link to post
Share on other sites
Posted (edited)

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 by SvOlli
  • Thanks 1

Share this post


Link to post
Share on other sites
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.

 

  • Like 1

Share this post


Link to post
Share on other sites

Great news !

 

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

Share this post


Link to post
Share on other sites
Posted (edited)
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 by Dionoid

Share this post


Link to post
Share on other sites
Posted (edited)

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 by Dionoid

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Posted (edited)

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 by Dionoid

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
Posted (edited)
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 by Dionoid

Share this post


Link to post
Share on other sites
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.

  • Like 2

Share this post


Link to post
Share on other sites

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:

IMG_6130.thumb.JPG.8f3068b46db82cd05aeb84ff3eb32827.JPG

 

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.

 

IMG_6125.thumb.JPG.8361572492c993b3616512aa6343b0ff.JPGIMG_6126.thumb.JPG.59f4f4f7e8d38fc4b77e90c1261526c3.JPG

  • Like 1

Share this post


Link to post
Share on other sites

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...