Community-Built Unnamed 1970's Video Game Console-Compatible System (WIP)

[JetSetIlly]

3 minutes ago, Al_Nafuur said:

Do you have a link to your post there?

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

[+Al_Nafuur]

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.

[+MarcoJ]

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.

[+Al_Nafuur]

3 hours ago, MarcoJ said:

Wow, awesome! It's great that one side of the CPLD breakout could connect directly to the PI.

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.

[+MarcoJ]

12 minutes ago, Al_Nafuur said:

So for this "cartridge only" versions we just need a jumper wire for 3.3V and one for the 5V of the cartridge.

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

[+Al_Nafuur]

 

3 hours ago, MarcoJ said:

I will order a few and catch up.

They are not very expensive but I am still not sure that the Max-II satisfies all our requirements.

 

3 hours ago, MarcoJ said:

It does appear like there's less wiring involved from the get go.

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.

 

 

 

[+Al_Nafuur]

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.

[+Al_Nafuur]

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.

[+MarcoJ]

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. 

[+Al_Nafuur]

On 12/24/2023 at 3:50 PM, Al_Nafuur said:

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.

 

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)

 

[+Al_Nafuur]

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

 

[+MarcoJ]

22 hours ago, Al_Nafuur said:

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.

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?

 

1 hour ago, Al_Nafuur said:

Flashing seems to work but verifying fails at the first address:

Is there a program enable jumper or bit somewhere?

[+Al_Nafuur]

20 minutes ago, MarcoJ said:

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?

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. 🤷‍♂️

 

20 minutes ago, MarcoJ said:

Is there a program enable jumper or bit somewhere?

Haven't found any:

https://github.com/captain-amygdala/pistorm#cpld-bitstream-update-

 

But maybe I should try with the Pi3:

Quote

Raspberry Pi Zero2 and Raspberry Pi Model 3a+ work out of the box, the Raspberry Pi Zero and Model 2/4 cannot currently be used with the PiStorm. While support for other Raspberry Pi models is planned with an updated CPLD firmware, there is no ETA for this.

I don't know if this applies to the flashing of the CPLD too..

 

[+Al_Nafuur]

27 minutes ago, Al_Nafuur said:

But maybe I should try with the Pi3:

I don't know if this applies to the flashing of the CPLD 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?

[+Al_Nafuur]

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.

 

 

[Kroko]

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:

 

[+Al_Nafuur]

16 hours ago, Kroko said:

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.

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?

 

16 hours ago, Kroko said:

So however we finally do it... with MAX-2 or Pi-Pico ... locking the bus is the only missing piece for decathlon to run:

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.

 

 

[Kroko]

22 minutes ago, Al_Nafuur said:

Or can you share your Pico code so I can test myself?

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:

 

45 minutes ago, Al_Nafuur said:

Do you have other cartridges like a SuperCharger to test?

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

[+Al_Nafuur]

1 hour ago, Kroko said:

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

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:

 

[Kroko]

27 minutes ago, Al_Nafuur said:

It seems that except for the ADC (26-29) the GPIO of the Pico are 5V tolerant:

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 🤣
 

[+MarcoJ]

3 hours ago, Al_Nafuur said:

The Pico is cheap so we might use more of them,

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

[Kroko]

4 hours ago, Al_Nafuur said:

MAX-II and it's 80 GPIOs

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.
 

[killersquirel]

Is there any updates on this project?

[+Al_Nafuur]

Some things have to be fixed here, but this is basically how I would setup the system with a MAX-II as BIA (Bus Interface Adapter) and also for doing the IO part of RIOT and TIA.

 

The PiCLCK (GPIO4) is used as input clock for the MAX-II, so I had to move the data and address lines to GPIO5 to GPIO25. Unfortunately GPIO24 to 27 is used for flashing the MAX-II via the Pi, so I added jumpers to connect these double used lines during flashing (I hop this doesn't interfere with the other IO lines of the MAX-II)

 

[+Al_Nafuur]

 

Prototype Board V1:

 

Any suggestions or objections?