REU/MOS 8726 DMA controller emulation?

[raszpl]

https://www.c64-wiki.com/wiki/Expansion_Port https://rr.pokefinder.org/rrwiki/images/9/90/1750_1764_Service_Schematics.pdf

Afaik _ROML/_ROMH are just address decode helpers to ease cartridge development, and can be swapped for A14/A15.

For complete emulation we will need D0-7, A0-15, R/_W, PHI2, BA, _DMA. 28 IOs. Then we need two more for Data and Address bus level translator (SN74LVC8T245/SN74LVC16T245) direction control.

PICO has 26 IO on edge connector, but you could potentially steal GPIO29/GPIO25 https://peppe8o.com/raspberry-pi-pico-pinout/, still two short :( Chip itself https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf has 30. https://proto-pic.co.uk/wp-content/uploads/2021/03/RPI-PICO-R3-PUBLIC-SCHEMATIC.pdf I dont know how viable is stealing GPIO24/GPIO23, but if its possible then we would have all the IO needed for full REU emulation.

[cknave]

Yeah ROML/ROMH were convenient for this project so I didn't have to monitor R/W, PHI2, and BA.

Are there designs you know of where the Pico's internal GPIOs are used? It looks like GPIO25 couldn't be used as an input for example, since there's an LED on it.

It might be possible to make a design based on the RP2040 only, but that's a lot more complicated. I like the Pico because it already has a bunch of useful parts built in!

I've found that some shift registers (74LVC8T595, 74LV165AD) could be fast enough: 62.5 MHz is as fast as the PIO can generate a clock at the Pico's default clock speed, which is enough to get data in or out in a PHI2 clock pulse. I've only used those for debugging this device though, no idea if they'd be suitable to put on a C64 bus. And bidirectional IO means even more parts and complexity.

Last challenge I can think of is the PIO instruction memory. I'm not familiar with REU capabilities, but you'd probably need to use both PIO units to get everything to fit.

This seems like it's maybe just within the Pico's limits, I'd be very impressed to see it.

[raszpl]

GPIO25 will be usable after desoldering R3, same with GPIO24 and R1 R10, GPIO29 removing Q1, GPIO23 will require two small trace cuts next to TP4 pad on the underside. After that you will have full hardware control over 30 GPIOs, I presume some pico code will also have to be commented out to not interfere. No need for shift registers.

REU capabilities

Would be cool to at least get the bare minimum required to get the Sonic C64 REU port running. This requires 256KB of ram, leaving RP2040 XIP and 8KB sram left for firmware (potentially 4kB more if USB is disabled) https://www.lemon64.com/forum/viewtopic.php?t=78945

I have no experience with RP2040 yet, and would love to learn more about PIO ability to handle those kinds of tasks. Im eyeing it as a potential hardware platform for IDE emulation. This requires 120 - 600 ns timings (PIO 4 - PIO 0).

[fanoush]

hi just a comment regarding gpios mentioned already in closed issue 3 - there is board https://www.aliexpress.com/item/1005003708090298.html which also has GPIOs 24 and 29 available (and extra button on 23) the board is discussed also here https://forums.raspberrypi.com/viewtopic.php?p=1955110#p1955110

Also this board has SPI flash in soic-8 format so it is easier to solder to so it can be also used to steal some more gpios - once bootloader loads code into RAM the QSPI could be disabled and pins reused as long as CS pin of the flash is kept high.

BTW for bidirectional 5v I/O there is slightly related discussion here https://github.com/q3k/chubby75/issues/37#issuecomment-698011549 the SN74CBT3245APW can be one option

[oemsysadm]

I would also be interested in this, and have been looking at the Pico for emulating a 1764 REU. It would be ideal if a user building this wouldn't need to source a lot of extra components, and if the PCB would be relatively simple.

If the REU really requires 30 gpio pins, how feasible would it be to put two Picos on the board, have one handle read and the other write, and connect them to each other via SPI? Maybe we could even get it to then emulate a 1750 REU or a Super CPU with ramcard. It would still be a really cheap device (and readily available, unlike alternate MCU boards).

[raszpl]

Eben recently confirmed pico is 5V tolerant https://hackaday.com/2022/09/25/pi-pico-w-does-pcmcia-gets-this-ibm-pc110-online/#comment-6516402

Note: the pads themselves are 5V tolerant for input, just not 5V5 tolerant, which is what we’d need them to be to put “5V tolerant” in the data sheet. (Hypothetical) future designs will fix this.

Note also: they’re not (and will never be) 5V failsafe, so don’t subject them to 5V without first powering VDDIO.

This is good news as the design could drop level translators as long as user has C64 5v Overvoltage Saver. It would make the whole thing just a cheap $1 jlcpcb interposer for $5 pico. This also lowers IO pressure from 30 to 28 pins. reclaiming couple IOs is relatively easy and involves desoldering 3 SMD resistors https://www.reddit.com/r/raspberry_pi/comments/w37gx2/i_freed_up_two_gpios_on_the_raspberry_pi_pico/

as for speed PIO turns out to be much faster than required for RUE emulation. https://github.com/polpo/picogus directly handling 8MHz ISA https://github.com/rhulme/picoROM_pio 215nS with no overclocking

[cknave]

The "2 Picos duct taped together" idea tumbled around in my brain this week. With one Pico for the control signals and the data bus, and another for the address bus, it's not really that unwieldy. And you get another 256K of RAM to use. And without the GPIO pressure, there's room to assert IRQ as well.

It was an interesting enough idea to make a schematic for this weekend. First draft, and these may not be the best chips for the job, just what's in stock today.

c64-pico-reu.pdf

[oemsysadm]

Looking at the pico pinouts, it seems like you could basically stick 2 picos back to back and have spi0 and spi1 more or less lined up. Does the above hackaday link mean the voltage translators won't even be necessary?

Having a device thats basically 2x picos sandwiched with a pcb between them, and which fits in a std cart enclosure, that can do a 512k REU and maybe a super CPU w. ramcard.. That would be amazing.

Add either a pass through port or the ability to also be a gmod2 or ef3 compatible cartridge, and I think this would be a must have device.

[LukaszDziwosz]

The schematics looks great. I was personally toying with idea of REU emulation with ESP32 and external RAM but Pico is actually more suitable. I'm very excited that you working on it. This would ignite C64 scene.

[raszpl]

https://github.com/rumbledethumps/rp6502 pico fast enough for 8MHz 6502 direct buss interfacing https://www.youtube.com/playlist?list=PLvCRDUYedILfHDoD57Yj8BAXNmNJLVM2r

[LukaszDziwosz]

Guys since Commodore REU was pretty slow what about using 16MB flash on RP2040 USB-C pico clone as RAM? If that's possible then single pico would be sufficient.

[frntc]

Hi there,

I'm using latches and multiplexers together with an RPi 3A+/B+ or Zero2 to emulate a REU: https://github.com/frntc/RAD

[LukaszDziwosz]

Hi frntc. Given the problems with RPI supply, do you think ESP32 S3 could handle what you did with Zero2?

[frntc]

I don't have experience with the ESP32s -- in the specs I read about PSRAM with configurable caching behavior, which sounds scary (getting the caching right was already difficult enough on the RPi). How fast is a PSRAM access? The 512k built-in RAM does not sound interesting, you already need the complete 512k for some demos, and you would not be able to watch NUVIEs or BluREU.

My take on this is: RPis will become available (in the past days I've seen RPis 3A+ available in different places). And you can still share the RPi with your Sidekick64 ;-)

[LukaszDziwosz]

Agreed not worth a hustle