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

[+Al_Nafuur]

11 hours ago, Al_Nafuur said:

So we either need a port expander like the MCP27S17 or one of the Raspberry Pi Compute Modules (which seem to have more GPIOs on the edge connector)

2 hours ago, MarcoJ said:

I looked into this last month. The I/O expander chips run at max 10Mhz clock, when the bit bang is executed it would be sub 1 MHz, our target to work. Also, the SPI and I2C ports are not available as the cartridge bus uses parts of them. 

We would have to move the GPIOs for the bus to use a I/O expander. Most likely the SPI version in 8bit mode at 10Mhz (~1.25Mhz per "byte"). This would give us a little bit more speed than the 6502 at 1.19Mhz, but not much and it would be one more component for the hobbyist to obtain. I like the MCP27X17 expanders, they are 5V tolerant and match exact the I/O part of the RIOT.

 

2 hours ago, MarcoJ said:

Hmm, this is a good idea! It should work well to bit bang the ports in parallel, perfectly in sync with the execution. Such a design would need at the very least a breakout board of some type. Such as this:

https://www.raspberrypi.com/products/compute-module-io-board-v3/ This would have enough I/O to interface to bidirectional joystick ports. This does give some hope to extend and expand the project. Also, it gives the hobbyist options to build the basic cartport driver or the full emulated ports.

The Compute Module 4S and 3+ have 46 GPIOs on the edge connector. As far as I understand the specs GPIO0-27 are on port 0 and GPIO28-45 are port 1. So we would have enough I/O's for the RIOT emulation on one Pi GPIO port, but we would need two more 74LVC245Ns. I would prefer the 4S, but it looks like they are difficult to obtain. The "new" Compute Module 4 variants are easier to obtain (and cheaper?), but it looks like they only have the same 28 GPIOs connected than the normal PI has.

 

2 hours ago, MarcoJ said:

In other news, I've had the "Back to the future" demo rom on Harmony I posted before running for about a week without crashing. The CartridgePort driver is very stable.

👍

 

2 hours ago, MarcoJ said:

OK, Are you hoping to have have a direct cart connector to your PCB, or wires? If the latter, this design could be used:

I thought of a direct cart connector and a manufactured PCB from JLCPCB or PCBWay. I would like to save myself the extra work and the soldering...

 

[+Al_Nafuur]

2 hours ago, MarcoJ said:

Hey, excellent. Have you noticed if the emulation is lasting longer without glitches as compared to your Pi3 setup? I am guessing you're using the same breadboard setup. 

I am using the same breadboard setup, but I have reconnected all cables from the Pi3 to the Pi4. My Pi3 was in a "unusable" state when I disconnected the cables. The flaky behavior of the breadboard is the main reason why I want to switch to a PCB.

 

2 hours ago, MarcoJ said:

I have tried this out, I could only ever get it working for a few hundred milliseconds on PlusCart. A real cart didn't work. How long did it run on your rig?

In emulation mode Stella is switching really fast to the debug window with an illegal instruction message, but on the debugger you can continue the emulation by constantly pressing "Frame +1". Then it runs in the debug window with glitches. Maybe this is only working on my setup, because I made some changes to the CartPort driver code (only cleanup).

 

[+MarcoJ]

29 minutes ago, Al_Nafuur said:

I would prefer the 4S, but it looks like they are difficult to obtain

Looks like they only make them for customers who used the older Compute Module 3. Both look difficult and expensive to obtain. It's a shame really, all that lovely GPIO.

 

33 minutes ago, Al_Nafuur said:

I thought of a direct cart connector and a manufactured PCB from JLCPCB or PCBWay

With a common cart connector chosen, it should be quite simple to produce and design. It would optimise the lead lengths. The PI does have some mounting holes for standoffs which could help support the cart during insertion and removal from the connector.

30 minutes ago, Al_Nafuur said:

The "new" Compute Module 4 variants are easier to obtain (and cheaper?), but it looks like they only have the same 28 GPIOs connected than the normal PI has.

I see. Yes, they only have 28 GPIOs. Odd choice, with those micro connectors being able to support dense arrays of I/O. This would probably be a better choice for the basic project if it was PCB based, as it's cheaper and smaller. The standard pi4 is more commonly available

 

 

 

 

 

[+Al_Nafuur]

59 minutes ago, MarcoJ said:

Looks like they only make them for customers who used the older Compute Module 3. Both look difficult and expensive to obtain. It's a shame really, all that lovely GPIO.

 

I see. Yes, they only have 28 GPIOs. Odd choice, with those micro connectors being able to support dense arrays of I/O. This would probably be a better choice for the basic project if it was PCB based, as it's cheaper and smaller. The standard pi4 is more commonly available

There are not much projects with custom boards for the Pi CPUs. They are somewhat "close source" and cannot be obtain separately. Building a custom board requires desoldering a CPU from an Pi board.

 

https://www.arducam.com/shrink-your-raspberry-pi-into-a-40x25mm-somsystem-on-module/

 

So designing a custom board with these CPUs is off the table.

😠

[+Al_Nafuur]

21 hours ago, Al_Nafuur said:

We would have to move the GPIOs for the bus to use a I/O expander. Most likely the SPI version in 8bit mode at 10Mhz (~1.25Mhz per "byte"). This would give us a little bit more speed than the 6502 at 1.19Mhz, but not much and it would be one more component for the hobbyist to obtain. I like the MCP27X17 expanders, they are 5V tolerant and match exact the I/O part of the RIOT.

10MHz SPI is not enough! Depending on the device we need min. 8bit for the command and (min.) 8bit for the response. There are 26Mhz IO expander (but not in DIP/DIL package) e.g.:

https://www.mouser.de/datasheet/2/146/XRA1403_100_092011-1889074.pdf

 

 

[+MarcoJ]

1 hour ago, Al_Nafuur said:

10MHz SPI is not enough! Depending on the device we need min. 8bit for the command and (min.) 8bit for the response. There are 26Mhz IO expander (but not in DIP/DIL package) e.g.:

https://www.mouser.de/datasheet/2/146/XRA1403_100_092011-1889074.pdf

Can the Pi4 write that many times within a 6502 cycle? I.e. could it actually bit bang the IO expander at 26MHz, roughly 26 times per 6502 cycle? 

 

[+Al_Nafuur]

1 hour ago, MarcoJ said:

Can the Pi4 write that many times within a 6502 cycle? I.e. could it actually bit bang the IO expander at 26MHz, roughly 26 times per 6502 cycle?

The Raspberry Pi can (theoretically) run its hardware SPI bus at core_clock/2 (125Mhz). How it is doing this, 🤷‍♂️

 

23 hours ago, MarcoJ said:

I see. Yes, they only have 28 GPIOs. Odd choice, with those micro connectors being able to support dense arrays of I/O. This would probably be a better choice for the basic project if it was PCB based, as it's cheaper and smaller. The standard pi4 is more commonly available

Looks like some of the GPIOs > 28 are on the CM4 connectors. They are just not labeled in the docs, and might be wired on the CM4 board (eg. Internal 1.8kΩ
pull up to CM4_3.3V)

https://docs.google.com/spreadsheets/d/1m27caMlk2gofswU9ZlBD_y3y81Y_0ARSmmQgm0i1AdQ/edit?pli=1#gid=0

https://github.com/raspberrypi/documentation/issues/1570

[+Al_Nafuur]

While looking at the 2600 schematics:

https://www.atariage.com/2600/archives/schematics_pal/Schematic_2600_Junior_PAL.html

I realized that we would (of course!) need the 6 lines from the TIA to the joystick-ports (for paddles and buttons) too!

[+MarcoJ]

5 hours ago, Al_Nafuur said:

I realized that we would (of course!) need the 6 lines from the TIA to the joystick-ports (for paddles and buttons) too!

Yes, there's quite a few, probably a 16 bit I/O expander could do it. Some bits would need to be able to output too with the DDRD register. The 4 paddle inputs are analog to digital type too, haven't looked if the GPIO can do that.

[+Al_Nafuur]

21 minutes ago, MarcoJ said:

Yes, there's quite a few, probably a 16 bit I/O expander could do it.

The RIOT alone has 16 (3 of them not connected), so we would need 22 for RIOT and TIA or 19 if we use RAM for the 3 not connected one.

 

27 minutes ago, MarcoJ said:

Some bits would need to be able to output too with the DDRD register.

🤔 The direction for the expander or the Pi GPIO can be set similar to the RIOT. AFAIK the direction of the TIA pins can't be changed.

 

33 minutes ago, MarcoJ said:

The 4 paddle inputs are analog to digital type too, haven't looked if the GPIO can do that.

are you sure these TIA pins are A/D ports?

[+MarcoJ]

5 hours ago, Al_Nafuur said:

are you sure these TIA pins are A/D ports?

They are some kind of sensing pin rather than digital . For the purposes of us, it would need to be an analog to digital converter. 

 

5 hours ago, Al_Nafuur said:

he RIOT alone has 16 (3 of them not connected), so we would need 22 for RIOT and TIA or 19 if we use RAM for the 3 not connected one.

I guess it depends how far one wants to go. Being able to facilitate i/o to an external plugin device is the most important, whereas reset/select etc can be done with a keyboard in USB. 

[+Al_Nafuur]

7 hours ago, MarcoJ said:

They are some kind of sensing pin rather than digital . For the purposes of us, it would need to be an analog to digital converter. 

As far as I understand the schematics and the explanations on how to "read" the 4 paddles, it is all about the time it takes to load an external capacitor (C5, C6, C13 or C14) to switch the input of the TIA (P0-P3) high again, after it has been set to low by VBLANK.

 

 

 

7 hours ago, MarcoJ said:

I guess it depends how far one wants to go. Being able to facilitate i/o to an external plugin device is the most important, whereas reset/select etc can be done with a keyboard in USB. 

Yes, I thought about USB for the consoles switches too. It would be possible, but the (small) down side is it would add "lag" for a few games (Space Shuttle?) that are using the switches.

[+MarcoJ]

3 hours ago, Al_Nafuur said:

As far as I understand the schematics and the explanations on how to "read" the 4 paddles, it is all about the time it takes to load an external capacitor (C5, C6, C13 or C14) to switch the input of the TIA (P0-P3) high again, after it has been set to low by VBLANK.

Oh wow, is that how they work. Apologies, I haven't used them before. In that case, a replication of the levels, thresholds, resistances and capacitances of the TIA circuit should be all that's needed. The Vblank handle in the TIA emulation would need its own dedicated driver to control the inputs, and reset them when in read mode. I recall the Quadtari using this same system to switch which controller is being read. 

 

The minutia of this interfacing does sound like fun to do. Although at this time I'm more inclined to focus on being able to support the full 6507 cycle length and sustaining real time emulation. To start a thread that  updates the emulation whilst gathering/actioning the next CPU instruction might need a frozen set of state variables while this is occurring. Or not, possibly, since on a real 2600 the TIA is updating in real time alongside the CPU in parallel. Have you had further thoughts on how this will be possible?

 

 

[+Al_Nafuur]

I am still a bit "disappointed" that there is no current Raspberry Pi board with more than 28 GPIOs exposed. And since the Pi CPUs are not openly available there will never be a chance for a custom board along this road.

Even if we use USB for the RIOT console switches we would need 14 additional GPIO to the 22 we are already using. So we would need a 26Mhz I/O expander for the PI

 

I did some research the last two days for an alternative board/CPU.

 

The specs we need are:

• CPU openly available
• good documentation
• not too expensive
• a performant CPU ( > 1Ghz)
• multiple cores
• hdmi out
• min. 40 GPIOs (ideally 5V tolerant)

[+MarcoJ]

2 hours ago, Al_Nafuur said:

I am still a bit "disappointed" that there is no current Raspberry Pi board with more than 28 GPIOs exposed. And since the Pi CPUs are not openly available there will never be a chance for a custom board along this road.

Even if we use USB for the RIOT console switches we would need 14 additional GPIO to the 22 we are already using. So we would need a 26Mhz I/O expander for the PI

Agreed, expandability is quite poor. The beaglebone black seems to have plentiful I/O and can potentially signal at 2.9MHz. It's quad core 1GHz.

https://codeandlife.com/2016/04/18/beaglebone-black-gpio-benchmark/

 

 

However, I do feel optimistic the pi project could be completed with just the Cartridgeport being stable. The codebase could be shared between projects too.

 

 

[+Al_Nafuur]

4 minutes ago, MarcoJ said:

Agreed, expandability is quite poor. The beaglebone black seems to have plentiful I/O and can potentially signal at 2.9MHz. It's quad core 1GHz.

https://codeandlife.com/2016/04/18/beaglebone-black-gpio-benchmark/

I had an eye on the beaglebone boards today too. They only have 1Ghz and only one core. But the CPU has two inbuild MCUs with 200MHz they are independent from the Linux scheduler and can be used for fast GPIO access. But the beaglebone boards are a bit pricey..

 

 

4 minutes ago, MarcoJ said:

 

However, I do feel optimistic the pi project could be completed with just the Cartridgeport being stable. The codebase could be shared between projects too.

I hope so too.

[+MarcoJ]

4 minutes ago, Al_Nafuur said:

I had an eye on the beaglebone boards today too

There is also the Dual core Beaglebone AI. It has the same form factor.

https://www.beagleboard.org/boards/beaglebone-ai

[+Al_Nafuur]

5 minutes ago, MarcoJ said:

There is also the Dual core Beaglebone AI. It has the same form factor.

https://www.beagleboard.org/boards/beaglebone-ai

Dual core yes, but triple price 😞

 

[+MarcoJ]

https://wiki.pine64.org/wiki/PINE_A64-LTS

 

- Quad Core

- 42 IO pins

- $39

[+MarcoJ]

Looks like Pine make compute modules too. Much smaller than the A64

 

https://pine64.com/product/soquartz-2gb-compute-module-w/

 

Supposedly 100 pin expansion

[+Al_Nafuur]

7 hours ago, MarcoJ said:

Looks like Pine make compute modules too. Much smaller than the A64

 

https://pine64.com/product/soquartz-2gb-compute-module-w/

 

Supposedly 100 pin expansion

The SOQuartz modules have only 28 GPIOs on these connectors. Just like the Pi CM4 module. The PIN doc of the Pine is even comparing to the CM4:

https://files.pine64.org/doc/quartz64/SOQuartz Connector Pin Assignments ver 1.0.ods

 

This is the issues with these boards. They are trying to be "compatible" with the Raspberry Pi boards without using the unavailable CPU. But this doesn't work well and in the end they have a incompatible product with the same restrictions, so no real benefit for the makers.

[+Al_Nafuur]

Just as a crazy idea: why don't we put a real 6532 RIOT chip on our board or a chip that is compatible with the IO part of the RIOT? It wouldn't need any additional GPIOs. The chip is still available (unfortunately only old stock?). We only would need (and have) the 6 additional TIA I/Os as PI GPIOs.

 

[+MarcoJ]

2 hours ago, Al_Nafuur said:

Just as a crazy idea: why don't we put a real 6532 RIOT chip on our board or a chip that is compatible with the IO part of the RIOT?

That is thinking outside the box. (pun intended)  That would also save on poking the emulated RIOT chip. As long as Stella is disciplined with its approach on emulating the RIOT chip, it should work. It's an optional accessory too, not everyone has fit a RIOT chip. I have bought them too from China on Ehay before so they are out there. Stella might lose the ability to manage RIOT RAM in house though.  Could also try make a substitute TIA chip interface for the specific inputs address range that related to paddle controllers, and let the emulated TIA do the rest of the address range. Probably just need a few GPIO read/write,chip select lines to complete the interface. And for users who want the minimal cartridgeport interface, there is that too. 

[+MarcoJ]

31 minutes ago, MarcoJ said:

Probably just need a few GPIO read/write,chip select lines to complete the interface

Looks like only 3 outputs needed from the PI to support both the RIOT and TIA . 

 

6507 R/W pin (GPIO output, direct to chip(s)). Read write strobe.

6507 O (GPIO output, direct to chip(s)). Emulated clock signal.

6507 O2 (GPIO output, direct to chip(s)). Emulated clock signal.

 

The rest of chip select lines are actually address pins, so we get them for free.

 

The RDY signal is probably not needed - it is used to stop the microprocessor executing for STA WSTNC - that function is done internally between the emulated 6507 and emulated TIA. 

The RST signal is only for reset purposes, not connected to either TIA or RIOT. Not needed.

 

[+Al_Nafuur]

New parallel interface expansion I/O chips seem to be rare.

 

The 82C55A is cheap and seems to be available, but the IO direction can only be set for the whole port not a single pin.

 

The CH351DS3 has 4x 8bit GPIOs (each GPIO pin has a direction control bit like the RIOT)

https://www.wch-ic.com/products/CH351DS3.html

🤔 But the docs are only available in Chinese. Price and where to obtain is also unknown.

 

Alternatively we could use a MCU like the ATmega1284P with 4x 8 Bit GPIOs to emulate the IO parts of TIA and RIOT on the bus. But i am not sure if it is fast enough (20Mhz)