Windless

While on can't code / scope, I started overthinking again : the STM32L412K8U6 is a rather cheap (currently 4€ for one piece on mouser) Cortex M4 with 64kB of flash and 32+8kB of SRAM. It has an internal oscillator. If I ever manage to make my code run, it might be possible to have a bank switched cartridge for 5€ in small batches (4€ for MCU, 1€ for PCB, 1€ for LDO + a few capacitors) Of course, data retention of the flash is only guaranteed to be 30 years, lot less than PROMs, but that is for 85°C.

I'd be really happy to have one (I was going to order 5 pieces on jlcpcb, but if you have some spares... That would avoid some non recyclable FR4 material !) Do you have some link ? I bought a 8bit saleae clone a few years ago, paid 4€ including shipping, never used it. All 16 bits I now find on aliex are 60€+ 😕 Great idea I'll could monitor the +5V rail and still have... 1 bit left to monitor data bus (ok, ok, I need 16) W. PS : I unfortunately I no longer have a place to spread all my equipment for now, I may not be able to really work on this project for 3-4 weeks Edit : I also wanted to try using a raspberry pico clone. They apparently can be used as logic analyzer with 21 pins ans 120Mhz capture speed... but sigrok seems to be stalled or abandonned, so only a fork supports the rp2040 (+ rp2040 is officially 3.6V tolerant, it may draw more current than wanted on the bus even if it works)

(previous message contains an error : test uses A12 not A9)

I triggered the oscilloscop on A9 rising, to get only changes on the data bus driven by the cartridge : The signal changes before the white vertical line are not the ROM answering the processor but the data bus being release by previous driver. if we take a single snashot, we sometimes see the signal falling before the white bar then rising again when the cartridge answer. So all cartridge answer are between the two vertical lines. So it seems we: - have 160ns (13 stm cycles) after we a change on address bus to release the data bus - need to wait at least 14 cycle after the change before we take control of the data bus (to avoid collision) - should put data on bus about 250ns after the change if we wan to do as the cartridge does. But we should not need since the 6507 datasheet tells us we have more than 500ns and it seems the RIOT takes 550ns So... interesting, but nothing helping me to debug the cartridge. Side note : if using another cartridge (Off the Wall instead of Centipede), the data line are pulled way earlier, even before the data bus seems to be released by previous user and we no longer can see the two groups :

Another measurement : This ones shows one pin of the address bus (yellow) and one pin of the data bus, with an original cartridge. We see a first group of change on the databus which happen very soon after address rises (on the right you also see when they occure after an address fall, which is faster / earlier than rise). Since the address is not stabilised yet, we can guess that's the processor writing data. Then we see lot of data changes 150 to 300ms after address rises. I guess that's the rom and some peripherals answering. Lastely, very close to to the allowed time (400 to 550ns after address rise, between the cursors in white), we see some other exchanges. Maybe that's the TIA answering out using its out of phase clock ? I would have to study the clocks of the VCS a bit to answer the question, feel free to enlighten me. Anyway, it seems that answering on the databus 550ms after an address bus changes is still fast enough for the 6507. Again, this is not the thing preventing my cartridge emulator from working... See you soon for other too long posts about me learning to use an oscilloscope and hoping not to fry a 2600 PS : you might also notice in the top left corner, behind the cursor values, that there are two slightly different high levels on the data line but there is only one after A9 line rises. Does the RIOT speak louder than his teammates ? ^^

I measured the rising time of the signal on one of the address pins of the 6507 using an original cartridge. The duration between the moment when the stm32f401 is no longer guaranteed to read a 0, and the one when it is guaranteed to read a 1 is 9.2ns, which is less than a cycle at 84MHz (11.9ns). So it might seem legit to just re-read the bus after we detected it has change (which is at least 5 stm32 cycles later). Of course there are still possibilities that the different lines of the bus don't rise at the same time, or that having the stm32 and all the too long dupont wires on the bus modifies the shape of the signal. Lets first check the first hypothesis. I am not super well equiped to probe several pins at once, but I manage to get some data : This time we see something else: the fall time of the signal is faster than the rise time. There is also some difference between pins (A5 in blue is always rising later than A9 in blue). I would have to take timings on all pins, but with those two pins 80ns already is a minimum margin - less than 7 cycles. I could replace the stabilisation waiting loop with a few nops, but I'll keep it for now and take measurments once 4K is working and I need to save cycles for bank switching. So in the end : these tests don't change anything. I need more diagnostics.

Irq are disabled (the timing is stable, see previous oscilloscope screenshot), and I checked the continuity twice (one from the breakboard's fingers to the blackpill pins, then later directly from 6507's pins to blackpill's one)

Yes, I switched from bluepill (stm32f103) to blackpill (stm32f401) for the reason. Anyway, I'll try capture some levels on the address and the databus, good idea. I do not have thelogic analyzer to monitor the 13 + 8 lines to check if the level is due to the stm32 or another component though.

Week-end... time for diagnostic. List of thing that can go wrong and I will try to check : ✔️Continuity tested from 6507 pins to Blackpill pins ❔Time between address stabilisation and data stabilisation with current version of the code (and compare with an original catridge*) ❔ Time before power on and data on address bus VS time before power on and data on data bus (compare with an original cartridge*) ❔ Scanning all adresses on the address bus with a blue pill and check data returned by the blackpill (bluepill emulates the VCS, blackpill emulates the cartridge) If you see anything else I should check, just tell * : @rbairos I guess you already conducted some of the tests ? Do you have the timings somewhere in a file ?

Hi, I am currently trying to make an atari 2600 development cartridge and am looking for a ROM that I could legally use in my test code so I can distrbute the unfinished firmware with the test data included. This would be a temporary use before I replace the code with a demo of my own, but all the code I have ready is uses E7 abnkswtiching and I have no implemented it yet. Any 4K 50Hz rom you know I can use ? Thanks, w.

I tried flashing the firmware again with data from a PAL rom, and ... black screen. So I flashed back with the previous rom and... blackscreen again, could not get back what I showed in previous photo. I guess there is either something about precise timings (phase problem ?), or my dupont wire make unreliable connections... That's won't be the fun part of the debugging process ^^

On wednesday morning I dared to plus the board in the console and... did not work Nothing burnt but the screen was the same as when you don't initialise the registers properly on stella... On Thursday morning I re-checked a few things and recompiled the code to remove the pullups I put on the databus just (I needed them to check things on the oscilloscop without plugin the cart in), and... just a black screen. Same as thing as when I start the VCS with no cartridge in This morning I tried to plug the oscilloscope on the VCS to see how fast the signals on the databus we rising / lowering because my code made this assumption that, once you have waited for the databus to start changing, you could just execture a few instruction and then read read the bus the bus that now should be stabilised, but I failed to check that. So this afternoon I rewrote the super-safe double loop code (one which wait for the address bus to change to go tristate, then one which wait until it reads twice the same value on the bus). The last version of the code is fast enough to do that until I try implementing bank-switching. So I tried the again and... still black screen. So I rechecked everything I could in order to put a report of what I'm shure of hoping some people on this forum will help me and... hooooooo... five wires for the address bus were in wrong position (I coded the version that preserve on pin because it has a button, and wired everything as if I have coded the version which saves a cycle by sacrifying the button) And now : Isn't this exactly what a TV that does not support 60Hz would show if you run some code designed for a 60Hz VCS on a 50Hz Secam VCS on a perfectly working development cartridge ? I'm not 100% (the colors seems weird), but next post will tell us

Thanks This means something to me ! (I am an unwitting procrastinator, and sharing projects is one of the few things that helps me actually doing things instead of just imagining / overthinking them. Always great to know someone follows one and I not really alone ^^) The board is far from being ready for production. For now I have a (still unused) breakout board and will make a first version of my own pcb when the code runs and I could test the fastest working pinout (probably in a month or two). The idea in the end is not to sell them, but to let people directly order the PCB and parts from china, solder 46 pins and flash the firmware. Maybe make a 30° chamfer on one side for pro looking (but useless) finish. For 4€ thought you would get 5 Hot Air Surface Leveled PCBs, that is the unimpressiv silver solder protection of the pads. I may make a one shot grouped order of shiny gold plated (ENIG) PCBs with pro made 30° chamfer because I want one for myself and cost starts at 20€ (still for 5 pieces, or 3 pieces from OshPark).

Code on github : https://gitlab.com/FTregan/scamcart2600 (very early code, nearly no documentation, the part described in previous post is in Src/loop.s, everything else is basically stm32cube scafolding)

(Nothing constructiv to say, but just wanted to say it's amazing... when I'm done with my hardware projects and get back to my 2600 demo, I really want to have a deeper look at it )

Ok, the pattern was shown by the oscilloscope was a bit weird, I was not sure I understood all I saw, so I rewrote everything step by step, making sure I understodd everything with the oscilloscope before going to next one. The result is indeed different (I also learnt to better use the oscilloscope ^^) : What we see : - 150ns after start of screen, the address changes on the bus (either from low to high or from high to low, the screenshot summs thousand of samples) - about 70ns later, the adress change is detected and the data bus is freed (set to high impedance). For the test I use the MCU inner pullup, so if the data (in blue) was high, it stays high but if it was low it starts to (slowly) rise. - I then re-read the address (being able to detect the change on adresse bus earlyer does not mean the adresse was stable. There the code from the unocart reads in a loop until the address read is twice the same, but since I took time too exit the "wait address change" loop and to change the databus to tristate, I assume the address bus is now stable, that's a bit faster and time is really more stable this way. I have to check the rise speed on a real 2600 to be sure, here the address is injected with an stm32f103 on a bluepill) - I check if adress bit 12 is 1, else I go back to waiting for a new adress on bus - I transform the value read from port B to a usable address in the rom (from 0ABC0DEFGHIJK0LM to BCDEFGHIJKLM, dropping bit 12) - I read the copy of the game rom in the stm32f401 flash at the offset correpsonding to this address - I put the data byte on the port A (offset by 1 bit because B<0> has a switch on the board) - I switch the pins of the address bus from high impedance (input) to output and the this data soon becames available. This, depending mainly on "where in the address change wait loop" did the address bu change, takes at max 320ns (white line) So, I'm pretty sure I can emulate a 2K or 4K cartridge and answer in 320ns. I think I have about 200 more nanoseconds to deal with bank switching (easy) and maybe emulat RAM (My target would be to fully emulate E7 because it's beautiful). So, next step would be to connect the bluepill to an actual 2600. For this, I still need to : - check everything again and again (I'm very paranoïd about risking to hurt a 2600) - understand how much time I have to answer the 2600. I guess the stm32 will start booting before the 6507 (because it requires lower voltage and the oscillator would start to oscillate sooner ?), and then IIRC I still have 7 6507 cycles (that's 494 stm32f401 cycles, and even more on stm32f411) to set the ports and start waiting for change on the address bus. But all my initialisation if written in C, so probably slower than needed. Plus there is some bootstrap generated code to copy some segments from flash to ram and initialise lot of ram to 0 that I really don't need. - maybe do other things I still have not thought about. Help and advice welcome

I *think* (still all buggy) I managed to read the address spread in 3 bits blocks and write the output in 2 blocks on another ports just fast enough on an stm32f401. The rpi pico is 133MHz and, thought I think M0 cores don't have the handy BFI instruction, it seems the "Programmable IO" thing is dedicaded to this kind of translations, it might be able to treat the fifo in a few cycles while the cores can do other things. (the "datasheet" is something inbetween a tutorial and a medium post, I still have a hard time understanding it ^^)

I *may* be able to use consecutiv address lines (or at least B<0..12> then B<15> for 13rd bit that would be remove for free using the barrel shifter when reading data) but that would require using B<2> which has a pulldown (or up) so I need to check that the timing is not too different from others. Also, the reason B<2> is pulled is that it's used for BOOT1 so you would need to switch of the VCS off to use the internal bootloader... which probably is a good idea anyway. Plus you would ever use the bootloader I guess. For the data bus in this configuration (since I'd use the barrel shifter to left shift the address to remove the 13rd bit for free, the adresse would be multiplied by two. I could store the data as precalculated half-word "port values" instead of byte rom values. Anyway trying to understand where I could get a few more cycle (using the barrel shifter), I read all the instruction of the armv-7m in the datasheet and learnt about this interesting BFI instruction, rewrote everything to assembly and I'm just a bit slow : - channel 2 in blue is the bit toggling on the databus - channel 1 in yellow show when the bus toggled relativ to the reponse - adress is injected with an stm32f103 in push-pull mode so signal rise might be faster than on a 6507 - data bit toggle triggered approximatively 10.000 times so I guess this can be considered stable According to the 6502 datasheet, Tacc (max delay between stable 2.0V+ or more values on the address bus and stable answer on the data bus) is 575ns at 1MHz and 300ns at 2MHz. So probably 520ns at 1,19MHz. I probably can still win 10% cycles in the code and overclock a bit and stay under 10€ for the PCB, the components and shipping. not sure there is time left for bank switching ^^. Edit : just looked at the clock configuration to check if overclocking by 10% would indeed reduce the delay by 0,91% and... it turn out the clock was running at 72MHz insteand of the nominal 84. At 84MHz, the max delay is 520ns using the same setup !

I'd be happy to discuss this subject if you open another thread, but basically from the read command to the answer, the slowest mode of the physical layer specification lets you 18 cycles at 12.5MHz (1.44µs). The usb Mass Storage Class ("usb key") have not been design for this. Even USB has not been (IIRC, usb 2 is polled every 125µs, usb 3 is a bit better but usb has lot of things to do before starting to get the data you want). With todays cheap and slow 128Go usb key, caching would be very expensive *and* take 20 minutes. So unless there is a possibility to declare the SD card busy after the command is received and before you answer, the timing will be an issue. And I don't think there is (SD Cards are not meant to be shared between hosts, so the host probably checks for business before sending commands.) Edit : could this sub-discussion be moved to another thread by our ❤️ admins ?)

@Andrew Davie said :

Some updates on the project : - rom upload via usb, using Mass Storage Class (just copy file to an "usb key") works, I hade to dive into the FAT format but can now detect when a file is done writting and have the filename - emulating the cartridge is currently a dead end : the response time is at min around 450ns, when the 6502 let you ony 290. I may be able speed things up a little more and maybe the 6502 is a bit more tolerant than the datasheet says, but I definitively won't have time to add bank switching and read/write even if I can emulate 4k. Maybe if I can find a bit faster card and/or one which has 12 consecutiv pins I can use instead of having to pack the address bits, things would be easyer but I could not find one in the STM32 family. The abvious choice nowadays woul be RP2040 but I'm not a big fan of the documentation, and @electrotrains is already working on the 2600picocart.

BTW, it would be really interesting to have a 2600 crack scene in 2023 :D

the idea is indeed to make a very cheap test for a (stupid ?). If it works, I'll look for cleaner solutions

Not having the crystal drift with temperature is a very hard topic and the crystla alone would not by a stable / precise enough information. But maybe you could combine a lot of innacurate measurement, and if they all change decide that the console must be different. Among them, you could monitor : -frame duration (crystal frequency) -voltage on each of the cartrdige pin -timing of the stabilisation of the pins -spectrum of the 5V (come to my place when some industrial motors are runing nearby, you definitively would see the effect on the 5V pin with an oscilloscop !) -surrounding WIFI SSIDs Of course, all of this would change if you use another PSU... Reminds us of the copy protection systems in the early 90's on PC that marked a sector of the harddrive as bad, but used it to store things like checksum of the BIOS, ... Nightmare for users AND computer repairers.

I looked at the output of the 3.5mm jack output of my phone, using normal music and 2 100R resitors as a load : - at normal listening level, I get too much noise (which may be filterable, I really don't hear it) - at max listening level the noise is very low, peak to peak level is 2x330mV. The standard should be 1mW under 600R load, and that would give +-110mV (peak to peak). I need to find 600R resistor to see if I ca reach this, but I don't thing that would work using a real tape deck.