Windless

Yes, twice. I'll try once more 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) 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. No. I could try emulating theme with a plucart, but that would probably change a lot of contexte. Yes, became abvious once I spotted it ^^

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

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

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.

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.

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.

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

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 !

To me, It would make more sens and beauty to code games for the $3 raspberry pico.

Do you have a multimeter to test continuity between the bottom-left pin of the IC and the corresponding pin ? Maybe it just need a jump wire to run again on the retron ?

for now I have a probleme where the usb enumeration fails. I've tested on 3 different (one real stm32, oe fake stm32, on "real" cs32) bluepills and they all get the same result. I don't know why but bluepills / blackpills usb enumeration (even in DFU mode) seldom work on my two computers, but using the code provided with STM32 seems to work fine (I made a mass storage device that is detected perfectly on each try using this). My plan was to try reusing you dumping code with my mass storage device code tomorrow. I don't have much cartridges here, will need to check if any of them uses bankswitching

Today I (finally) received one of the boards from Canada... felt like christmas when I was 6 years old I also received some "Edge Card Connector Slot 2.54 mm Pitch" in 2x12pin from aliex. I ordered 5 because I was not sure how rigid the pins would be and I was afraid I would have to try several ways of using them, but the pins are rather strong and the plastic is not as cheap as I thought it would be. So the first try was the good one and I did not have to bend any pin or to have the cartrigine hanging horizontally. I paid 4€ for 5 pieces and needed only 2. Soldering is easy : tin 2 opposite pins, held the two connectors in place with one hand, re-melt the solder with the other. Then you put a small amount of solder on the iron, touch one side of a pair of pins, touch the other side with the solder wire, and repeat 23 more times. Merci @rbairos !

Yes Also a good idea is to keep free then pins that could better be used for something else (e.g. : usb pins, SWD pins, the buttons on the board, ...)

I finally managed to build just an hour ago (removing the "additionnal board management url", then it found the one I installed in "hardware"). My problem is now that GDB refuses to connect OpenOCD ^^ I'm starting to wonder if it would not be time for me to try something else than this programming thing I'm still so bad at after nearly 40 years

I've still not managed to build it. I took notess of everything I did at last attempt : This part is optionnal, use it to upload code from arduino IDE, but you can also just use arduino IDE to compile the code then flash the .bin with your usual method Download the HID bootloader ( stm32_binaries.zip ) from https://github.com/Serasidis/STM32_HID_Bootloader/releases Install it like you would usually flash a firmware on your board (e.g. using STLink V2) or use the hid_flash util you can find on previous link Thi spart is reuqired : Download and install the version 1.8.19 of the Arduino IDE from http://arduino.cc/en/Main/Software. Run the IDE, in file -> preferences, change laguage from "os default" to "english" if you want In Tools -> Board : ... -> Boards manager, and search "Arduino SAM boards (Cortex-M3)" and install it (you won't use it, but this will install a working arm-none-eabi-g++ toolchain to compile the code for the bluepill) Download zip file containing the STM32 files from https://github.com/rogerclarkmelbourne/Arduino_STM32/archive/refs/heads/master.zip. Unzip it "my document\Arduino". You should have a directory named "C:\Users\<your user name>\Documents\Arduino\Arduino_STM32-master" Rename it to remove the "-master" part In this folder, you will find a /drivers/win/install_drivers.bat file : run it as administrator Restart arduino ide Open the atari2600 dumper project In Tools -> Board: ... -> Stm32 boards group choose "Generic STM32F1 series" In Tools -> Board part number:... choose the proper bluepill In File -> Preferences, make sure "Sketchbook location" is the path to the parent folder of your "Arduino_STM32" directory (so it should be "C:\Users\<your user name>\Documents\Arduino\" if you have a default windows install) At this point, compiling gives and error : atari2600dump:17:10: fatal error: USBComposite.h: No such file or directory 17 | #include <USBComposite.h> | ^~~~~~~~~~~~~~~~ and USBComposite is not found in the library manager. I tries moving the "USBCompostite" folder in "ARDUINO_STM32..." to the "libraries" folder of my sketchbook directory, but then it can't find "Boards.h". There is a "boards.h" file but if I try using this one it misse "maple/maplelib.h"... I give up untill I find some help

I did not try runing it on my 2600 (I only have the SECAM one here ^^), was a bit puzzle about what I saw... then tried the `_pal_2k` file instead of the `_ntsc_2k` and it might be the case that there is something wrong with stella interpretation of the ntsc version you provided ^^ (stella 6.7 here) really clean interpretation. Makes me need to improve my own plasma-ish effect before I dare releasing it

If you have some spare time, it would be great to include some building instruction For now I guessed that the .ino file means you build with the arduino IDE, So I tried to, I think I managed to find how to build for a bluepill. It could not build because USBComposite.h was not found, so I cloned this library in the "library" directory of the arduino ide but then it complains about not finding "boards.h", and there are to many of the on github for me to find the right one. This is where I gave up

FAT16 is basically an extension of FAT12, there are probably around 100 lines of code you would drop by reomving support of FAT12, and that would prevent anybody from reading a floppydisk. I don't expect that soon.

pullups on the stm32f103 are (IIRC) 14KR. They are just pull ups, not drivers. Basically, pullups exist for the sole purpose of not letting undriven lines read random values while letting other drive them when they are connected. Stella uses (de facto standard) file extensions that helps the emulator (and dev carts) know which scheme is used. It would be an easy way for user to know which format was detected without even needing to open the .txt file you create : https://stella-emu.github.io/docs/index.html#PropertiesCartType d I went the opposit direction for my dev cartridge : I declare a FAT12 SMD with only 64 sectors (32kB) plus the two required one for FAT and file name. Also the cluster is 32kB, this way you can not write a new file, only replace the existing one. (Ok, since the OS caches the access, there is no way to prevent file deletion so in the end you alway can delete a file - in cache only - and write one with a different name)

I tried to read the code, but I could not find where the FAT16FileReader is defined. Are you missing some files or is 7am too early for me to try reading C code (I am really not an expert in C ^^) Also there is this I'm not sure I understand : digitalWrite(addressPins[12], 0); for (unsigned i = 0 ; i < 13 ; i++, address >>= 1) { digitalWrite(addressPins[i], address & 1); } Is the 13 supposed to be a 12 ? IIRC the code works because you always %4096 the address before calling read(), so when i=12 pin 12 is set to 0 again, but that make the first line useless ? I like the automatic hotspot detection. Since you are detecting the bankswitching scheme before initialise the MSD anyway, probably you could use this information to change the filename. Thank you for sharing this !

I am currently trying to make a devboard and I have plenty of bluepills... this will be a handy test tool I would activate the pullups and continously read the reset vector. If it's $FFF then you know the cartridge is removed. You probably want to programmacticaly disconnect the mass storage device from the OS then, so when a new cartridge is inserted it can be discovered again, else you will most probably have issues with the OS caching the whole 4K file (and probably the file allocation table also)

Nw temporary lab is installed. It's a bit tiny and that don't make things easy but I managed to get some data using a cheap saleae clone. The clone does not use a real bufer, but 100.1kR in serie and then the (apprently 2.4V) clamping diodes of the mcu. I don't know if the explains what I see. Now, what I see. First with a real cartridge, while the game is running : everything seems to work except for channel 3. Channel 0 should be A12, 1, 2 and 3 A2, A1 and A0, and channel 4, 5, 6, 7 D1, D2, D3, and D4. With the cartridge removed, I get this : The capture begins when I switched the VCS on. Channels 3 may react to other channel changing, or I may have a short (but I doubt it since the game on the cartridge was running fine). The result is what I expected : Channels 4, 5 and 6 are pulled up most of the time since there is no cartridge to pull them down. Now with the notworking scamcart proto : I just don't undertand what I see : There are two time where the data and address lines changes after the power on. They seems to match the timing when seemilar changes occure with no cartridge. but when there is activity on the address lines between those with no cartridge, there is nothing with my cartridge. Then after the second period of activity, the adresse bus never changes, like if I where pulling them high even when the 6507 tries to pull them. Could it be possible that I start writing on the databus too early and mess with the setup of the VCS/6507 ? Any idea to explain what I see ? things seems ok when using a bluepill to inject address and the oscilloscop to read data... Thanks, W. Note : I have not checked everything twice. I don't have a proper breakout board yet so I use chip hooks on the 6507, and they might be badly positionned, have shortcuts, ... Edit : the recording is 4 seconds long, and nothing appears later on the 3rd one, the problem does not seem to be tied to the boot time of my code

I still need to reinstall my lab (probably this week-end), but I have some spare rpy picos, a ds1054Z with three probes and two 50hz (secam) 2600 here is you need a few recordings.

I have an unfinished article about using bankswitching on the VCS here. The first part (which is not specific about any bank switching scheme) might be interesting if you have no previous experience, and since my current project is stalled I could write the part about bank E7 if it could help.

The code is available on gitlab : https://gitlab.com/FTregan/scamcart2600 I think I did all you suggest, except for copying the code into ram but test on the oscilloscope did not show any out of time, and non initialising large datastructures but I should have none. I wanted to rewrite all the init phase in assembly though, I currently use the stm32cubemx generated one.