When I read this, I think "Supercharger". Scan and decode 2D barcode (QR, DataMatrix, what have you) Encode as audio (FSK?) compatible with supercharger. Stream decoded audio out through a Supercharger compatible phone plug. Supercharger allowed for multi-tape game loads, so the scanning of multiple 2D barcodes should be workable. Superchargers seem to be fairly rare so probably not an ideal solution. I don't know the architecture well enough to answer myself, but I wonder if an alternate firmware for a multicart (e.g. Harmony) could make it receive a digital stream via the USB port and load the stream contents to RAM like it would otherwise do with a file from an SD card. I know this is kind of circumventing/bypassing/ignoring the StellaRT as real hardware angle, but I thought I'd ramble it out here anyway.

I had once thought of this long ago too before I heard of papercart, but what I imagined was an image of pixels - 128x128 with 16 available colours for each pixel. This would provide 8kb of space.. if my math is correct. 2 pixels would be one byte. Just need to figure out a way to scan all the pixels and interpret the colours. Easiest method is with a camera. It is a really cool idea. It would be the neatest thing to have an entire game on a paper card.

I also like the idea of using MAX-II for RIOT/TIA. It is a better solution for any complex time critical logic. Of course also a bit harder to handle, development wise. The implementation of this "Transceiver with Lock" fills up 29 command of the 32 that are available per PIO. So first PIO is already full with only this little function. Also PIO is not super well documented. I had difficuties to connect the same GPIOs to two different PIOs ... so it may get ugly soon, when we need to do more complex things.

Hey this is a good idea. These boards are cheap and plentiful, I like this direction.

There has been a lot of discussion about this ... not only in this thread. This is what I found on RaspberryPi Forums: GPIO pins that aren't shared with the ADC can accept a maximum of 3.6v without IOVDD being powered. GPIO pins that aren't shared with the ADC and have IOVDD at 3.3v can accept a maximum of 5v ( not 5v tolerant as this typically means up to 5.5v) Remember during powerup in typical designs 3.3v usually comes up after a 5v rail so applying 5v to a GPIO will end up over stressing the RP2040 during powerup. If you exceed the one of the specifications the internals may not fail immediately, but over time if the silicon is stressed it may fail. Remember noise and overshoots can all add to stressing the silicon. I would recommend designing to the datasheet as this is what is what the parts are tested to. Or as someone else stated: everything is 5V tolerant for a while 🤣

It seems that except for the ADC (26-29) the GPIO of the Pico are 5V tolerant: The 2600PicoCart is not using level shifter too:

I attached the code that I build and download to the Pico. What is necessary as input is the DIR line from the Pi 4B and also a new line that I called ADR_CHANGED. Maybe we can replace the dedicated ADR_CHANGED line by the LE for the address latches... However it needs to be set to "1" together with the address lines and LE (not before and not after, in the same command) Then it needs to be kept on "1" until the Pico had the time to detect it, I think I have it on "1" roughly 200ns now. Then it must go down to 0. Every address change needs to trigger one puls on the ADR_CHANGED line. Next rising edge of the ADR_CHANGED is also reseting the LOCK of the databus. This is how I connected the BUS: ; Pico GPIO16 = DIR (Input : from PI-4B) ; Pico GPIO17 = ADR_CHANGED (Input : from PI-4B) ; Pico GPIO18 = LOCK (Output: just for DEBUG to watch when the transceiver is LOCKED) ; Pico GPIO0-GPIO7 = DS (Databus connected to Stella ) (DIR=0: Output DIR=1: Input ) ; Pico GPIO8-GPIO15 = DC (Databus connected to Cartridge) (DIR=0: Input DIR=1: Output) It is important to note that I have resistors on all GPIO both (PI4B and also for Pico) for protection. The Pico is not 5V tolerant and it can also not be made 5V tolerant by resistors. But its probably giving me more time before the setup fails. In the final design we will need level shifters so no 5V is seen on Pico GPIO. This is how this looks like in the logic analyzer: I don't have a SuperCharger ... I also am still having trouble with extra RAM cartridges ... but I did not look into this lately. Something still does not work for these, because for example my copy of BoulderDash is unable to enter the game screen. Also I am having trouble with the Stella Emulator code. I only partly understand which place in the code corresponds to which time in the time slice. Need to look more into it to find out where the problem might be ... PicoLockableTransceiver.rar

This is (somehow expected, but still) awesome! Do you have other cartridges like a SuperCharger to test? Or can you share your Pico code so I can test myself? Pico would be fine if we keep the joystick/console ports via USB. But if we want to emulate the IO part of RIOT and TIA we need 22 more GPIOs plus the address lines they use (~7) for the IO. The Pico is cheap so we might use more of them, but I doubt a single Pico has enough IO to emulate a RIOT. The IO part of TIA and RIOT is only needed to be compatible with all old input devices and things like the CompuMate: So we might split up the development here and have a USB variant and then we see if we can get a joystick/console port variant with the (more expensive) MAX-II and it's 80 GPIOs.

Meanwhile I replaced the 245 Bus transceiver with a Raspberry Pi Pico and implemented the databus handling as PIO state machine. Freezing the data that the cartridge is sending some time after the address bus changed is enough to get the real decathlon cartridge running. So however we finally do it... with MAX-2 or Pi-Pico ... locking the bus is the only missing piece for decathlon to run: 2024-01-13.mp4

After correcting the "bcm2835gpio peripheral_base" to "0xFE000000" and the "bcm2835gpio speed_coeffs" to "236181 60" in the detect and flash config script it is now flashing on the Pi4 too.

Flashing with my Pi3B (my Pi3B+ has defect GPIOs) worked. The PiStorm config scripts for openocd (https://github.com/captain-amygdala/pistorm/blob/main/nprog/detect.cfg) have a "bcm2835gpio_peripheral_base" constant which is set to the base address of the Pi3. Now I wounder why the Pi4 detected the EPM240 with this base address?

It looks like the latches (SN74LVC16373) are used for level shifting (even though they aren't fully 5V tolerant?). The two SN54CBTD3384 are only connected to the other control lines of the 68K. I think the CPLD on the PiStorm only controls the "bitstream" aka the latches, because the 68K emulation on the Pi is done with the normal PiOS and not a RTOS. So they are facing the same issues like we are. It is even "worse" for the PiStorm, because their peripherals (RAM, graphic IC, Floppy controller,..) have a own clock and are expecting the 68K to have this clock too. 🤷‍♂️ Haven't found any: https://github.com/captain-amygdala/pistorm#cpld-bitstream-update- But maybe I should try with the Pi3: I don't know if this applies to the flashing of the CPLD too..

I don't get it. Why would the PiStorm design go to the length of using a CPLD, only to using external glue logic. Is there a level shift? Is there a program enable jumper or bit somewhere?

Tried to flash with Pi4 and openocd and the PiStorm flash script: Flashing seems to work but verifying fails at the first address: $ ./flash.sh Detecting CPLD... EPM240 detected! Flashing... Flashing failed, please see nprog_log.txt for details $ cat nprog_log.txt Open On-Chip Debugger 0.12.0 Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html DEPRECATED! use 'bcm2835gpio peripheral_base' not 'bcm2835gpio_peripheral_base' DEPRECATED! use 'bcm2835gpio speed_coeffs' not 'bcm2835gpio_speed_coeffs' DEPRECATED! use 'adapter gpio tck; adapter gpio tms; adapter gpio tdi; adapter gpio tdo' not 'bcm2835gpio_jtag_nums' DEPRECATED! use 'adapter gpio srst' not 'bcm2835gpio_srst_num' Info : BCM2835 GPIO JTAG/SWD bitbang driver Info : clock speed 100 kHz Info : JTAG tap: max2.tap tap/device found: 0x020a10dd (mfg: 0x06e (Altera), part: 0x20a1, ver: 0x0) Warn : gdb services need one or more targets defined svf processing file: "./rtl/EPM240_bitstream.svf" adapter speed: 100 kHz Error: tdo check error at line 7789 Error: READ = 0xffff Error: WANT = 0x7fff Error: MASK = 0xffff Error: fail to run command at line 8014 Error: tdo check error at line 7789 Error: READ = 0xffff Error: WANT = 0x7fff Error: MASK = 0xffff Time used: 0m0s943ms svf file programmed failed

After digging a little deeper into the PiStorm project, I found the following interesting findings: Only 16 GPIOs of the Pi for the data and address bus are used, so for the 24bit address two writes from the Pi are necessary. 4x 16bit latches (SN74LVC16373) are used for the address and data bus. One for 16bit data in and one for data out and two for the 24bit address bus. The 16 Pi GPIOs are connected to the latches and the MAX-II (I don't know why the MAX-II needs this information, it should be enough if the Pi tells it which latch to use in this cycle?) The SN74LVC16373 are not 5V tolerant (only 4.6V according to the datasheet) but they are directly connected to the 5V data bus of the 68K connector. For the other control lines of the 68K (RW, RST, HLT,.. ) two 10bit high-speed bus switches/level shifter (SN54CBTD3384) are used. (We might use these for the TIA and RIOT I/Os) GPIO4 of the Pi (PICLK_OUT 200Mhz) is used to clock the MAX-II (IO12 / GCLK0) GPIO24-27 of the Pi are used to program the MAX-II (TMD, TDO, TCK, TDI)

My MAX-II's just arrived. I'll get setup with Quartus. I got it working to upgrade my Dragonfly some time ago. I recall it taking forever to install. I recall some jiggery pokery was needed to get my blaster working though.

I am trying to flash the MAX-II with the USB-Blaster for several days (weeks) now, but with no success! On my Win10 installation the Blaster is not appearing in the device list of the Programmer, even though the driver has been installed successfully. Quartus doesn't want to install on my old Linux laptop, because the CPU there is not supported. Quartus also doesn't want to install on an alternative Laptop with win10 (32bit), because 32bit is not supported. Also not supported is MacOS, so my MacBook cannot be used too. I reactivated my Linux partition on my Win10 machine, but 20GB is not enough for Ubuntu and the Quartus IDE (minimal installation for only MAX-II support!) After adding a new SSD with 180Gb for Ubuntu I was able to install Quartus for linux and the Blaster even shows up in the device list of the Programmer, but still no connection to the MAX-II I've looked into the PiStorm project and I think we should borrow a few ideas for a custom board. They are using the Pi 200Mhz core clock for the MAX-II, so we would save an extra crystal (the MAX-II boards I have here have a extra 50Mhz one) They are flashing the MAX-II from the Pi with openOCD, so no extra jtag header but 4 GPIOs of the Pi are needed.

During my research I realised that the PiStorm project initially also used the MAX-II for the 68k emulation: They have the same problem that the 29 GPIOs of the Pi are not enough for all address and data pins of the 68k.

They are not very expensive but I am still not sure that the Max-II satisfies all our requirements. I am not finished with soldering. The address and data wires for the cartridge and level shifter are still missing.. Unfortunately the I/Os of the Max-II are not 5V tolerant (only 4.6V !!) so we will still need the SN74LVC245AN.

Are you putting in a 74HCT245 for the data bus? I heard this CPLD is not 5V tolerant.

Not exactly. The MAX-II board has 44 pins on each side and the 40 middle pins are I/O, the pins on the side are VCC or GND. The 40 PIN in the middle align with the 40 pin (29 GPIOs) connector of the Pi except for the 3.3V and 5V pins. The additional GND Pins of the Pi connector are not a big issue because the unused I/O pins of the Max-II can be used as GND supply. So for this "cartridge only" versions we just need a jumper wire for 3.3V and one for the 5V of the cartridge. If we want to add the 16 I/Os of the RIOT and the 6 of the TIA, we will not have enough I/Os on the right side of the MAX-II board.

Wow, awesome! It's great that one side of the CPLD breakout could connect directly to the PI. I will order a few and catch up. It does appear like there's less wiring involved from the get go.

Started soldering the new breakout board(s) today: The USB Blaster for flashing arrived this week, but I still have issues getting it to work with Quartus on Windows 10.

https://woodgrain.taswegian.com/index.php?topic=44.0

🤷‍♂️ We still would have the issue that some of the cycles are far longer than on a real 6502@1.19Mhz. In my theory, however, this does not play a major role, as most (all) cartridges response to the address bus changes and don't have a own clock/crystal (the only one I know of is the GameLine modem). Do you have a link to your post there? The MAX-II boards arrived today. I am still waiting for the programmer (USB-Blaster), which should arrive next week. Then it's "only" programming and wiring the stuff and we should be done