HDMI connector wired interface version

[ryanschlegl]

Hi all, first @darthcloud thanks for your awesome work.

I'm interested in building a RJ45 multi-console version of the BlueRetro to support a smaller form factor and the old MC-Cthulu style adapters as described here. Of course this would reduce the amount of consoles supported (bye bye megadrive/genesis) however I think it would still be a great option.

Here to ask Jacques and others about ideas around the feasibility of keeping changes contained in wired, and if the pin definitions should be abstracted out of each controller or duplicated in different folders. Particularly if there's any perceived show stoppers getting console detection to work with 8pin RJ45 without major changes.

Further, if the wired interface can be made modular I'd like to investigate a HDMI interface similar to a reverse of the Blissbox adapters to reduce the form factor and potentially add back all the awesome console support BlueRetro has.

Any feedback would be awesome, thanks.

[darthcloud]

You'll loose Saturn too as BlueRetro only support the TWH protocol (need all 9 pins for that).

My original plan was to use RJ-50 (10c10c) but this made auto detection too complex.

Current auto detect code will not work on split up connector for various reason.

[darthcloud]

The level shifter you use are bi-directional and this simply doesn't work in real life.

You need level shifter were you explicitly control the direction via a pin for each gate individually.

Current design put them in cable for good reason. There is not enough IO to control them with esp32 and using io expander would add too much delay in the toggle.

Also n64, gc and dreamcast are bidirectional and current code do not (nor need) control any level shifter direction as signal are passthrough.

[ryanschlegl]

The level shifter you use are bi-directional and this simply doesn't work in real life.

@darthcloud just an update, I have prototyped and had success using the "auto direction sensing" level shifters in line with the PS2 and N64. Waiting on extension cables for my Saturn and SFC/SNES to test further.

[darthcloud]

I wouldn't trust this at scale ;)

[kaduleite]

The level shifter you use are bi-directional and this simply doesn't work in real life.

@darthcloud just an update, I have prototyped and had success using the "auto direction sensing" level shifters in line with the PS2 and N64. Waiting on extension cables for my Saturn and SFC/SNES to test further.

First thank you for contributing with the best ESP32 project at all by @darthcloud.
Did you make the @darthcloud suggested git for the schematics using bidirectional level shifter? Or did you post it somewhere?

[ryanschlegl]

Hi @kaduleite, I have now posted the schematic and gerber files for JLCPCB manufacturing into this url here https://github.com/ryanschlegl/brminishield FYI @darthcloud . Hope someone finds it useful. I also have a couple already assembled that I would be happy to send for cost + postage.

[ryanschlegl]

Update, can confirm auto detect working reliably with the Saturn (5v) , PS2 (9v power 3.3v Signal) and N64 (3.3v),
Haven't tried with the SFC yet as I use MiSTer but I have the cables if someone is interested. Also planning to make a 4 player DC cable but I only ordered 2 DC extension cables by mistake :( .

Cables are dumb wires only and made using extension cables and the below:

Smarts are all in the shield PCB that the ESP32 plugs into (black box with lid off in the picture)

[darthcloud]

Congrats on figuring out how to use the bidirectional shifter. Once you are ready consider making a git repo for your design. I'll add it to the community section.

[DerfJagged]

Awesome stuff! I had considered doing the same with USB-C since - apparently - USB-C doesn't have to be rotationally symmetrical. But HDMI would probably offer a much stronger physical connection.

Can this design be made safe to be plugged into a TV? I would worry about someone accidentally sticking it into a TV and frying either device. Obviously, it'd have no functionality, but just thinking safety-wise.

[ryanschlegl]

Can this design be made safe to be plugged into a TV?

As for plugging consoles from the controller ports into a TVs HDMI, I don't think it's possible to make that electrically safe, except possibly hardware keying on custom plug housing.

For the BlueRetro, plugging a HDMI lead from a TV into it there may be an issue that PIN 17 which is normally ground is used as VREF (each level shifter chip's VCCB supply). The data sheet for one of the compatible level shifters is here: https://www.ti.com/product/TXS0108E, but my reading and googling hasn't made me confident without testing it. Any insight would be welcome.

Otherwise if the current wiring isn't safe we would need to look at the software to reduce the amount of pins needed for universal auto detection to make pin 17 ground as all 19 pins + the connector housing for ground are currently used.

[ryanschlegl]

Otherwise if the current wiring isn't safe we would need to look at the software to reduce the amount of pins needed for universal auto detection to make pin 17 ground as all 19 pins + the connector housing for ground are currently used.
Thinking on it a bit it might also be okay to swap pin 17 and 19 to make it more safe as 19 is I39 used just for autodetect and can be expected to be grounded. No real reason for 19 being I39, other than HDMI 19 being hotplug detect and the function sort of matching. Would probably also neaten PCB layout.

[ryanschlegl]

Once you are ready consider making a git repo for your design. I'll add it to the community section.

Thanks! I will look into uploading the devkit c shield version, however a new revision would probably be good as the BOM is a bit expensive due to the power supply IC being in short supply.. and I can cut down on one of the bi directional level shifters as it only services one pin where I think a simpler part is all that's needed for I39.

What I'd like to do is an all in one board version in the same footprint, but will have to work in USB. Shouldn't be much more in BOM cost than buying a non-clone devkit-c though.