Yet another cartridge dumper

[Windless]

3 hours ago, arpruss said:

Sorry for saying what may be obvious

Thanks you saying what may be avious

 

Checking the code for that was definitively in my todolist (I wanted to see the MSD detected on windows before I spent time connecting all those cables). I'm so used to seeing USB enumeration failing that I start telling my backup solution before I even read the code ^^ It's working now. Next step : think of a good way to connect all the cables !

[arpruss]

11 hours ago, Windless said:

Next step : think of a good way to connect all the cables !

I just soldered. It took a while and was a mess. 3D printable case is here.

 

 

 

 

[Windless]

It seems you have the same connector as mine. I could design a PCB for it and the bluepill (4€ for 5 pieces at jlcpcb), but with two problems :

- not all bluepill have the same pinout, e.g. some Vss pins on some bluepills are Vdd on others. I could at least make a PCB that work for all the one I have

- the edge connector (you seem to have the same as mine) will only allow to insert the carte for 4-5mm if you solder it on a CB. That might work for most cartridge, but maybe not all ?

 

Tell me if someone is interested

[arpruss]

I just realized a nasty thing; internal pullups, and maybe pulldowns too, are not 5v tolerant. Maybe it's ok for brief intermittent use?

[Windless]

The short answer is I don't think using them for short period of time (nor even long) will cause problems, but this is there because things like rising time of the signal might be slightly different depending on the source and specifying the behaviour with tight tolerances would require more precision on the pull up resistor.

 

---

 

(now  the long one )

 

The reference manual of the stm32f103c8 has this diagram :

you can see on the right part the clamping diodes which became busy when tension on the I/O pin is greater than Vdd_ft (which value is not in the reference manual, datasheet nor specification sheet but is probably around 5V)

 

top right from that, you see the possible pull-up and pull-down with their interruptors (probably an unspecified transistor). You see that if the pull-down ties to Vss, the pull-up ties to Vdd not Vdd_ft. If you activate the pull-up and then apply 5V on the I/O pin, with Vdd at (max) 3.3V the resitor will have a drop of (min) 1.7V, and with its 20 to 50kR value that will be a current of max 0,085mA. Probably not enough to overeat nor damage anything (we know the resistor can wistand a continous 3.3V).

 

on the schmitt trigger entry, what will it change ? it depends on how well the tension source can deal with that resistor. I guess that this is the reason why they say not to use pull-ups, they could also have specified the behaviour (but the resistor being very approximatively specified, they probably just don't want to build on it).

 

you can see that on the pull-down side we don't have any difference between the 5V tolerant and non 5V tolerant pins (the schema is just before the one I pasted, but basically Vss stays Vss, you don't have Vss_ft), and indeed the datasheet says :

...

so pull-downs are also not sustainable. The reason is the same : instead of being used at 0 or 3.3V difference, they would be used with a 0 or 5V difference.

 

though you might be out of specification, if the fall time of the signal stays fast enough for your use, even if you have 32 pull ups on 5V tolerant pins (total 2.72mA and 13,6mW) and continous use (e.g. while debugging) I can see any other possible damage than the pull up/down stopping working.

 

[arpruss]

15 hours ago, Windless said:

- the edge connector (you seem to have the same as mine) will only allow to insert the carte for 4-5mm if you solder it on a CB. That might work for most cartridge, but maybe not all ?

Yeah, I ran into the same issue when I was thinking about a PCB. My edge connector is no longer easily accessible, but I wonder if the pins on it are thin enough that it could plug into a 24 pin header, making it stick out higher? (One might want to use some glue to join the plastics more rigidly then.)

 

Thanks for the explanation of the 5V tolerance issue. I am uncomfortable with going out of spec. I managed to change the program logic to avoid all the problematic pullups and pulldowns (I do pullups in a few cases, but only after checking that the bit in question is zero), but there are two cases where my code will fail:

 1. If the reset vector is FFFF, then the cartridge won't be detected at all by the current code. But why would you have the reset vector be FFFF, given that it's outside the standard address space?

 2. If you have an F4, F6 or F8 SuperChip cartridge, in very rare circumstancs if all the RAM write port reads (0x1000-0x107F) float up to FF (despite the fact that I try to prevent that by pulling down before the reads and then releasing the pulldown), then it will be detected as a plain F4, F6 or F8.  The dump should still work, but it will include RAM data, and hence won't match CRC data in the database. (I could just make the assumption that no ROM is going to start with a string of 128 FFs, and detect all cartridges with 0x1000-0x107F being FF as SuperChip instead.)

[arpruss]

In theory, the code now supports all of the classic cart types: 2K, 4K, 3F, CV, E0, E7, F4, F6, F8, FA, FE, UA, DPC, plus Super Chip variants of F4-F8.

Alas, all I have for testing are F8 and DPC.

[Windless]

On 9/17/2023 at 5:15 PM, arpruss said:

Yeah, I ran into the same issue when I was thinking about a PCB. My edge connector is no longer easily accessible, but I wonder if the pins on it are thin enough that it could plug into a 24 pin header, making it stick out higher? (One might want to use some glue to join the plastics more rigidly then.)

You might want to check this :

I frist intendent to fill the gap with some cyanoacrylate or epoxy glue, but it's really strong enough as this. What I may try (purely for aesthetic) would be to cut the pin so they are just a bit shorter than the plastic things in the corner. Also with a jig it could be possible to drill holes in the corner and join the two parts with four bearing needles.

[Windless]

I'm still trying to get it to work. Finding very weird values with my oscilloscop (I definitively was shortcutting something or having not 5V tolerant pins getting 5V - or both), I started GDB and... the state of BSSR register did not make sense.

 

So I looked at the code, and this comment seems to be right for the data pins :

  // pins: 3,4,10,11,12,13,14,15 -> bits 0-7

which means the diagram at the begining of the code is right.

 

Then I tried to decipher the address pins :

    uint32_t mainAddressPortValue = (address & 0x7ff) | ( (address & 0x800) << (15-11));

we apprently take 11 bits of the address, then move the 12th bit by 4. So address 000DCBA987654321 becomes C0000BA987654321 (Dth bit disappeared, but the cartridge space only has 12 bits and the 13rd one is a chip select always equal to 1, so this is probably normal)

 

then with :

const uint32_t mainAddressPortMask = 0b1000011111111111;

we set and reset the bits on port A and C :

    register uint32_t bsrr = (mainAddressPortValue) | ( ((~mainAddressPortValue) & mainAddressPortMask) << 16);
    uint32_t bit12AddressPortValue = (address & 0x1000) << (15-12);
    register uint32_t bsrr12 = (bit12AddressPortValue) | ( ((~bit12AddressPortValue) & bit12AddressPortMask) << 16);

    // *nearly* atomic address write; the order does matter in practice
    mainAddressRegs->BSRR = bsrr;
    bit12AddressRegs->BSRR = bsrr12;

Apparently what we want is to set the 11 low bits of port A as the 11 low address bytes. But then why is mainAddressPortMask 0b1000011111111111 and not 0b0000011111111111 ?

Then IIUC, we read bit12AddressPortValue as bit 13 of address (the 'Dth' bit that disappeared earlyer), and roll it as bit PC15. Are there cases where we wante something else than a 1 here ? (if yes, having "chipSelect()" and "chipUnselecte()" functions would be more readable, or am I missing something ?)

 

so it seems that A0..A11 is mapped to PA0..11 and CS is mapped to PC15. Is that right ? I sent a pullrequest on the github poject to update the comment in the code which was giving really different values.

[Windless]

Ok, I think I understood the the thing about the mask in previous post. the bit that get shifter to PA15 is not A12 but A11, my previous schema is wrong about that.

 

-- analysis kept for record
 

Spoiler

Ok, I still can't get this to work, but there is a probleme in my previous message for which I need help :

 

if we have an adresse with bits 0bCBA9876543210, we do :

    uint32_t mainAddressPortValue = (address & 0x7ff) | ( (address & 0x800) << (15-11));
 
    register uint32_t bsrr = (mainAddressPortValue) | ( ((~mainAddressPortValue) & mainAddressPortMask) << 16);
    uint32_t bit12AddressPortValue = (address & 0x1000) << (15-12);
    register uint32_t bsrr12 = (bit12AddressPortValue) | ( ((~bit12AddressPortValue) & bit12AddressPortMask) << 16);

we have a mix of hardcoded values and constatified masks.

 

first mask the address 0x7ff = 0000 0111 1111 1111, we are left with 0b.... .A98 7654 3210 ('.' are zeros, '0' is bit 0 of the address)

we then mask it with mainAddressPortMask = 0b0000 1000 0000 0000 (getting 0b.... B... .... ....), and move the result 15-11=4 bits right

then we or the two and get 0bB... .A98 7654 3210, and save the result in mainAddressPortValue.

this value is used to drive all pins on mainAdressReg = (GPIOA).

 

so this explains why the mask is 0b1000 0111 1111 1111, but :

- why is not PA11 used for bit 12 ? According to the datasheet, it's 5V tolerant

 

[Windless]

Ok, still trying to make it work. The good new is that with what I understood in last post, the bluepill now enumerated as an MSD when I have a cartridge in !

 

The sad new is that I can't use the file. The two cartridges I tested, that work on the 2600, give invali instructions on Stella. The downloaded content does not match the roms I DLed from the internet :

 

- Ms. Pac-man (pal) is seen as a 2K cartridge

- Here is a comparison of Off The Wall (pal) first 0x200 bytes - dumped on the left, downloaded on the right :

Spoiler

b8 72 f8 84 d6 b4 f0 b0 d4 84 d4 d0 06 d6 f0 88	| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0 d4 84 d4 4a 4a 4a 4a 94 ea a4 d4 28 0e 94 18	| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
bc e8 f0 b8 84 f8 84 d4 b8 96 f8 84 d6 b4 ee b0	| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d4 30 02 f6 ee 28 0e 94 14 4c b0 f6 00 0a 0e 14	| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
fa fa fa fa 28 32 32 34 34 36 36 38 38 3a 3a 3c	| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40 40 42 4c 52 62 fa fa fa fa fa fa fa fa fa fa	| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
fa fa fa fa fa fa fa fa 0a 00 00 0e 04 0a 04 0a	| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
08 0a 04 0c 0c 04 00 08 0e 0e 00 00 00 00 00 00	| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00	| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00	| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00	| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00	| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 02 02 02 04 06 04 04 06 10 fe 08 08 08 fe 0e	| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
06 18 14 12 fe 12 fe 12 12 14 10 14 10 16 0e 16	| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0e 18 0c 18 0c 1a 0a 1a 0a fe 12 12 12 10 12 10	| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
10 0e 10 0e 0e 0c 0e 0c 0c 0a 0c 0a fe 02 02 04	| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
04 06 06 08 0a 0c 0e 10 12 16 1a 1c fe 0a 0a 0a	| a9 fd 85 08 a9 00 85 e5 a9 f1 85 e6 4c de 9f a9
0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a fe 1c 1a	| 0c 85 e5 a9 b9 85 e6 4c ea 9f a9 00 85 2c a2 d6
1a 18 18 16 16 14 12 10 0e 0c 0a 08 06 fe 02 08	| ad f2 f0 f0 02 d0 02 a2 68 8e 75 f0 ad a0 f0 d0
00 12 06 0a 06 00 0e 10 0a 14 12 18 18 10 14 1e	| 05 ad 9e f0 f0 05 a2 70 4c 3e 91 ae 99 f0 ad 84
16 1a 14 1e 0a 1e 1a 08 fe 00 00 02 00 00 00 02	| 02 d0 fb 85 02 85 2b 85 01 a0 12 88 85 02 d0 fb
00 00 00 02 00 02 fe 02 1c 1e 00 1c 02 1c 1a 04	| a0 00 84 1d bd c0 9d 85 1b bd 28 9e 85 1c bd 00
06 1c 06 1a 08 08 0a 18 0a 0c 0c 18 14 0e 12 0e	| 9f 85 06 bd 60 9f 85 07 ca c8 c0 04 f0 05 84 02
12 12 10 12 10 12 12 12 0e 12 14 0c 14 16 0a 16	| 4c 54 91 84 02 ad f5 f0 85 08 ad 95 f0 85 0e ad
08 16 08 16 06 18 04 1a 18 02 1a 1c 00 1e fe 08	| 96 f0 85 0f bd c0 9d 85 1b bd 28 9e 85 1c bd 00
0c 12 0a 14 08 16 04 18 fe 04 00 00 0e 00 00 fe	| 9f 85 06 a9 00 85 0e bd 60 9f 85 07 a9 00 85 0f
06 00 02 02 04 04 06 08 0c 0a fe 0a 06 0a 00 10	| ca c8 84 02 bd c0 9d 85 1b bd 28 9e 85 1c bd 00
00 16 fe 00 00 00 00 00 00 00 00 00 00 00 00 00	| 9f 85 06 bd 60 9f 85 07 ca c8 a9 4a 85 08 ad a6
00 02 00 00 10 00 00 00 c9 2a 00 00 00 10 10 00	| f0 85 0e ad a7 f0 85 0f c0 0c f0 03 4c 73 91 84
06 00 00 00 00 00 00 00 a0 05 00 20 00 00 00 00	| 02 a9 00 85 0e 85 0f bd c0 9d 85 1b bd 28 9e 85
a1 fe 00 00 00 00 01 00 08 c0 01 00 00 00 00 00	| 1c bd 00 9f 85 06 bd 60 9f 85 07 c8 ca c0 10 f0
00 00 01 00 40 00 00 00 59 28 00 08 ec 05 00 20	| 05 84 02 4c d7 91 85 02 85 10 85 11 a9 00 85 1b

 

 

I dumped the game three times, and values at offset 0x01C8 and 0x01C9 varies on each read, others are the same (I only chacked the 0x270 first bytes)

 

If I try using gdb to step the code, in the cartridge detection function when the dumper tries to read the value at 0xFF1C-0xFF1D (the only read I checked), and I use a DMM to read the bus :

- first address bus turns 0b1111111111100 (0x1FFC, correct), and the data bus reads 0b11011000 (0xD8). Decoding the gpio port works (uint8_t resetLow = read(0x1FFC); is set to 0xD8). My downloaded dump contains 0xD8 at this address (correct) but the value in the my dumps contains 0xEC.

- second address bus turns 0b1111111111101 (0x1FFD, correct), and the data bus reads 0b11011110 (0xDE) (D1 still 3.5V). Decoding the gpio port works (uint8_t resetHigh = read(0x1FFD); is set to 0xDE). My downloaded dump contains 0xBF at this address (different) and the value in the my dumps contains 0x05.

 

There is definitively something weird. Any idea ?

of the wall pall - not working dump.a26

[arpruss]

1. Have you double checked the continuity of all the connections between the blue pill and the edge connector, and also checked if any two neighboring pins (either on the edge connector or the blue pill) got shorted? One of my initial problems was some bad connections and a short due to a strand of wire not having gone through the hole on the blue pill. 

 

2. It's clearly not correctly detecting the cartridge types. What cart type is it detecting Off The Wall as? (See the extension, or look at the info.txt file.)

 

3. Can you force the cart type in Ms PacMan to f8 (which is what I think it should be), and see if the dump is correct then? You do this by writing a one-line text file to the drive that says at the beginning command:force:f8 (followed by CR or LF or CRLF). It doesn't matter what the name of the file is. On Windows, you would do something like this:

 

echo command:force:f8 > e:z.txt

(where e is the drive letter of the device).

 

You can also force f8 detection by changing detectF8() to always return true. 🙂

 

And then in Off The Wall, force the detection to f6s (which is what I think it's supposed to be), and if that doesn't work, f6.

 

4. Do you have E.T. or Pitfall II? That's what I've been testing with, as that's all I have.

[arpruss]

By the way, the reason I don't use PA11 is that it's also USB Data Minus.

[Windless]

On 9/29/2023 at 12:14 AM, arpruss said:

1. Have you double checked the continuity of all the connections between the blue pill and the edge connector, and also checked if any two neighboring pins (either on the edge connector or the blue pill) got shorted?

Yes, twice. I'll try once more

 

On 9/29/2023 at 12:14 AM, arpruss said:

It's clearly not correctly detecting the cartridge types. What cart type is it detecting Off The Wall as? (See the extension, or look at the info.txt file.)

Only the .A26 file appears. Off the wall, RealSports Soccer and Ms.Pacman (all PAL) all shows the same info.txt file. Pole Postion doe not eumerate (though the game work on the console)

Spoiler

Persistent:
 hotplug
 no file with Stella extension


Non-percommand:hotplug
 command:nohotplug
 command:force:XXX
   XXX = 2k, 4k, 3f, cv, e0, e7_8k, e7_12k, e7_16k, f4, f4s, f6, f6s, f8, f8s, fa, fe, ua, dpc
 command:noforce
 command:stellaext
 command:nostellaext

 

On 9/29/2023 at 12:14 AM, arpruss said:

Can you force the cart type in Ms PacMan to f8

No ^^ I tried the command you gave, and also with `command:stellaext`, but that does not change anything. There is still only one 2ko file and the `info.txt` file shows the same persistent state.

 

On 9/29/2023 at 12:14 AM, arpruss said:

Do you have E.T. or Pitfall II? That's what I've been testing with, as that's all I have.

No. I could try emulating theme with a plucart, but that would probably change a lot of contexte.

 

On 9/29/2023 at 12:17 AM, arpruss said:

By the way, the reason I don't use PA11 is that it's also USB Data Minus.

Yes, became abvious once I spotted it ^^

[arpruss]

This is all very strange. What you are listing as the contents of INFO.TXT looks like what is supposed to go in OPTIONS.TXT!

 

Are you using the latest version of the code? Do you have some local modifications? And are you using the USBComposite library bundled with the libmaple core, or the latest version from https://github.com/arpruss/USBComposite_stm32f1/ (if you do use that one, you should delete the copy bundled with the libmaple core)? How are you uploading the code to the blue pill?

 

For testing, you might want to comment out:

  EEPROM8_init(128);
  hotplug = !EEPROM8_getValue(NO_HOTPLUG);
  stellaExt = !EEPROM8_getValue(NO_STELLAEXT);

and replace with:

  hotplug = true;
  stellaExt = true;

You can manually force a mapper by putting in the same place in the code something like:

force = 0xF8; // Ms Pacman, RealSports Soccer, Pole Position

or

force = 0xF6 | SUPERCHIP; // Off the Wall

 

Edited September 30, 2023 by arpruss

[arpruss]

I just added a simple serial mode for checking connections. It should dump the first 4K bank to the serial console. Just #define SERIAL_TEST to use it, and have the cartridge plugged into the blue pill when you plug the blue pill into the computer. Then you can compare that to the first 4K on the good copies.

 

(I also fixed a stellaExt bug.)

[arpruss]

Looking at your Off The Wall dump, it looks like a part of the problem has to do with the cart's A11 connection. (The dump repeats every 0x0800 bytes, which suggests that the cartridge's A11 pin is always getting the same data.) 

 

And I just noticed that the connection diagram in the comment at the beginning of my code listed cart A11 connected to PA11, instead of to PA15 as it should be (and as it is in the code itself). I just fixed that comment. Sorry! Did you follow the comment, or did you connect cart A11 to blue pill PA15?