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?

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

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

Work would be needed to support homebrew mapper schemes with my dumper. Currently, my dumper in theory supports all the classic 2600 mappers (in practice it's only been tested with two, and there are probably bugs), but for any different mapper one would have to add code. (One could add code to auto-detect the new mapper, but I would be worried that this could break the auto-detection for one of the classic mappers, which are my priority. Probably a better solution would be to add code for the homebrew mappers that need to be manually set.)

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

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.

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.

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

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

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

Sorry for saying what may be obvious, but do you have a cartridge hooked up? The code scans the cartridge before creating the mass storage drive, so it can know how much space to allocate for each file, create the file names in the root directory, etc. If you want to try without a cartridge (and get an empty 2k file), you can comment out these lines in setup() and loop(): waitForCartridge(); ... if (crc != romCRC(0,romSize)) nvic_sys_reset(); // in case cartridge hasn't stabilized ... if (!detectCartridge()) nvic_sys_reset();

Can you try one of the USBComposite library examples, e.g., simplekeyboard? What OS are you using? There is also a known issue with some of the bluepills having a wrong resistor value. This never game me trouble, but it may give trouble to other people: https://sites.google.com/view/makeriot2020/home/tutorials/stm32-blue-pill/using-native-usb-port-on-stm32-blue-pill

Good point. Avoiding the USB pins, I found I couldn't put all the 13 address lines on one port. I had available 12 pins on GPIOA and 13 pins on GPIOB, but if I took all 13 pins from GPIOB for the address lines, I didn't have enough 5V-tolerant pins left-over on the board for the 8 data lines. So I ended up putting 12 address lines on GPIOA, A13 on GPIOC, and the data lines all on GPIOB. So I can't write the whole address at once, but I can do it in two steps (I didn't check what the assembly code looks like). I also made the cartridge removal detection code a bit more finicky, so it triggers a reboot more easily if you wobble the cartridge. I also do a second read of the whole cart during startup to make sure the cartridge is stably seated (if not, reboot). The downside of all this is that a wonky cartridge with bitrot that gives unrepeatable reads will get rejected entirely. Perhaps it would make sense to add a non-finicky mode which doesn't do cartridge stability or removal checks. Anyway, if you want to try out the revised code with some other nominally supported cartridges (right now all I have is one F8 and one DPC for testing), that would be great. I am particularly suspicious of my FE code.

Looking over my pin assignments, they are kind of random, arranged by physical proximity more than anything else. I think I'm going to resolder and move some of the pins so that all the address pins are on port A, and all the data pins are on port B, and then I can do atomic writing of the addresses, which I think is a good idea.

I've never used OpenOCD, and I've never used GDB for embedded projects. My usual way to debug for most platforms is to add print statements, or just put additional data in files on the emulated disc in this project.

Thank you for such a detailed writeup, and I'm sorry I was confusing... The right section of the boards is "STM32F1 boards". (I think you might be choosing the boards for the official STM32 Arduino core.) Then you choose "Generic STM32F103C series". Then in the Variant menu, choose the 128k version. Then choose the upload type to match your bootloader / upload method. Here's what it looks like for me: The version of USBComposite bundled with Roger's core is out of date, and I think he hasn't responded to my pull request to update it. Probably it doesn't matter for this project. But if you do want the latest, it's here: https://github.com/arpruss/USBComposite_stm32f1 I also now put a standalone firmware binary in the repo: https://github.com/arpruss/atari2600dumper/tree/main/binary (It may get out of date from time to time.) You can install in the same way that you would install a bootloader (I use a USB-to-serial link), and it overwrites the bootloader. But this way you don't need to build, or even have Arduino installed. I only own two carts; one is F8 and the other is DPC. Both now work. In theory, F4, F6, FA and FE should also auto-detect and work (and ditto Super Chip variants), but likely there are bugs since they are completely untested. (I emailed a local used game store asking if they might let me test with games in their collection.)

I just added a fun little thing. I auto-generate a LAUNCH.HTM file which launches the ROM using the javatari.js emulator.

Yeah, I should provide some instructions. I always use Roger's libmaple-based core rather than the official STM32 core, because USBComposite only works with libmaple, and libmaple is also less bloated. Here are two different sets of instructions (the second is mine) how to set up Arduino for this core: 1. https://www.instructables.com/Programming-STM32-Blue-Pill-Via-USB/ 2. https://www.instructables.com/Gamecube-Controller-USB-Adapter-and-Getting-Starte/ (see steps 1 and 2) I fear something may be out of date in these instructions, and a lot of developers have jumped ship from the libmaple core to the official one. People keep asking me to make USBComposite compatible with the official core, but I don't have the energy to figure out the details of how to do that.

I also added a second copy of the file, with the Stella type-identifying extension. After all, since it's a virtual drive, it doesn't cost anything (except a bit of RAM for the root directory entries) to have more copies.

Changes: 1. I used the @Windless pullup method to detect hotswapping (I also make sure that the reset vector is continuously readable for 2 seconds, in case the cartridge is being slowly inserted in a way that makes contact with some but not all data pins), but I do the dump without the pullup. 2. I use the retroarch rom database to detect rom names and I added LFN code so that the game gets a full name. 3. I detect 2K cartridges by checking if the second half equals the first half. 4. Now it needs to be compiled for 128k flash. If you have one of the rare blue pills with only 64k flash, you can remove some or all of the roms.h data. E.g.: C:\users\[deleted]\ARduino\atari2600dump>dir e: Volume in drive E has no label. Volume Serial Number is 0000-0000 Directory of E:\ 01/01/2023 12:00 PM 70 INDEX.HTM 01/01/2023 12:00 PM 89 INFO.TXT 01/01/2023 12:00 PM 8,192 E.T. - The Extra-Terrestrial (USA).a26 3 File(s) 8,351 bytes 0 Dir(s) 8,325,120 bytes free C:\users\[deleted]\ARduino\atari2600dump>type e:INFO.TXT Bank switching: F8 Size: 8192 CRC-32: 6d0a475f Game: E.T. - The Extra-Terrestrial (USA) C:\users\alexander_pruss\ARduino\atari2600dump>

I would worry about compatibility issues with such small drives. It wouldn't surprise me if either Windows or Linux dropped FAT12 support at some point.

Good idea. I earlier thought of using pullups, but I don't like the idea of the blue pill and the ROM chip fighting over the data. What if the ROM chip loses? Is that a possibility? I don't know how ROM (and EPROM) chips work on the hardware level. Is this an issue I should worry about? I did just check, and the CRC is still correct with pullups activated (ditto for pulldowns, btw), but I only have one cartridge to test with.

FAT16ReadOnly.cpp and FAT16ReadOnly.h are in the repo. I'm kind of proud of that code: it dynamically generates FAT-16 sectors as needed, so that although the computer sees an 8mb flash drive, the actual RAM usage is very small (we only have 20K RAM and 128K flash on the blue pill, and I currently use 7K RAM and 44K flash, so it should fit in an stm32f103c6t6 as well). Thanks for catching the unnecessary A12 write. Fixed. I could change the filename, but I don't really see why. I think GAME.A26 is more friendly than, say, GAME_F8.A26. Also, keeping the name the same makes it easier to set up an emulator to load directly from the fake flash drive (which is the purpose). Now, if I could set the filename using the CRC and a table of cartridges, that would be rather nice. I could, I guess, use the libretro database, which has 727 entries, and would fit into flash (though the list is missing one of my favorites: Foot Craz). But I'd also need to add support for long filenames to my FAT-16 code, since currently I only support 8+3. I'll think about it. Other changes: I fixed the bankedRead() routine to check whether we didn't inadvertently read a hotspot and switch banks. That would have affected cartridges where the last few bytes differ between banks--I don't know if there are any such cartridges. I added a CRC-32 to the INFO.TXT file (and checked that the one cartridge I have matches the CRC-32 for it on the web, as well as the one zlib reports for the GAME.A26 file). And I changed to DOS line endings for INFO.TXT.

I made a cart dumper for the stm32f103c8t6 blue pill boards using the libmaple-based Arduino core and my USBComposite library. The fun thing about this cart dumper is that it emulates a flash drive, so when you plug it into a USB port, you get a GAME.A26 file you can load into an emulator right from the dumper--you don't need to copy it or anything. Currently, it only supports 4K, F6, F8 and FA cartridges. One thing I haven't been able to figure out is how to recognize whether a cartridge has been pulled out and another inserted, so to switch cartridges you currently need to reset the device or pull it from USB. If you have any thoughts on how to detect a cartridge easily, it would be appreciated.

I made a USB spinner controller using an AS5601 magnetic rotary sensor and an stm32f103c8t6 blue pill. The spinner is ball-bearing mounted and super smooth, and the plastics are 3D printed. Parts cost is about $20. As is usual for USB spinners, the spinner is mapped to the horizontal axis of a mouse. It also has an optional port where you can plug a Wii Nunchuck for games that need a stick and a spinner (e.g., Mad Planets). There is also a mode (press button 3 while turning it on) where it emulates Stelladapted 2600 Driving Controller. Instructable: https://www.instructables.com/Magnetic-Sensor-Arcade-Spinner/ 3D files: https://www.thingiverse.com/thing:6043032 Arduino sketch: https://github.com/arpruss/usbspinner