Mr.Boehm Raspberry Pi Classic Controller Hat for the 2600/5200/7800

[flickertail]

I'm not sure how well this thread is going to go, but the purpose of this thread is to get feedback from the community on the design of the MrBoehm PCB before we get our first prototype set created so I can finish writing the Python controller code.

 

Long term goals:

1) Power a RPi Zero W from the 2600/5200/7800 joystick ports. (Have run successful tests with my 7800).

2) Develop a version of Linux that boots within a few seconds that allows for cart changes

3) Implement a variety of Classic Controller controller configurations in software for modern Bluetooth and USB controllers.

-- This includes:

-- -- Support for my 2600 Hypothetical Controller design (which others may have proposed in the past)

-- -- Support for the modern controllers of the pending modern Atari VCS console release. - I have no illusions about the quality/success of the VCS, I'll just leave it at that.

 

The Mr. Boehm is designed to support a 4-port Atari 5200, though it will require a 15 pin DSUB extension cable for each port in use.

 

The left two ports of the Mr. Boehm are designed to support the two ports of the 2600/7800 using a 2600 to 5200 converter with classic controllers implemented in software.

 

I've done a bunch of tests with my breadboard prototype, which if you haven't seen them already, you can view these tests on my blog: Flickertail's Blog

 

I will be posting schematics here to explain the attached PCB design, assuming that this thread doesn't go off the rails due to just too much info.

 

I don't know, it may be that a console-powered PI is not possible. It maybe a reasonably fast boot headless Linux OS for cart switching is not possible... But stuck at home due to COVID, this is the project I've decided to work on to get my mind off work.

 

I am not the only person working on this project, my friend David is doing the PCB layout, and he provides me with electronics guidance. In another life, he was an electronics specialist for the AF.

 

This PCB is ready to be sent to the manufacturer, for a test run of 5, but before it goes, I'd like to get feedback from the community. Even those who are purists who think this project is pointless are welcome to comment.

 

Oops... almost forgot to post the 9pin to 15pin mappings:

2600/7800 ------ 5200

Pin 1 ------------- Pin 7

Pin 2 ------------- Pin 6

Pin 3 ------------- Pin 5

Pin 4 ------------- Pin 8/13

Pin 5 ------------- Pin 3/10

Pin 6 ------------- Pin 1/14

Pin 7 ------------- Pin 9/12

Pin 8 ------------- Pin 4/15

Pin 9 ------------- Pin 2/11

 

PCB_PCB_2020-06-06_23-48-09_2020-07-04_09-07-59.pdf

Schematic_Atari_MrBoehm_Wiring_2020-07-04_09-02-06.pdf

[flickertail]

I'll try to go over how the GPIO pins of the PI control the MrBoehm and provide feedback to the user.

 

Would very much appreciate any feedback people might have on the I/O capabilities of the controller ports for the 5200, as I haven't looked into supporting controller port output for the 5200.

 

I2C provides the primary communication of the Pi with the MrBoehm over the SDA and SCL pins of the GPIO header (SDA - Pin 3, SCL - Pin 5). The two items directly connected to SDA and SCL are a TCA9548A I2C multiplexer and a 2-row 16 character LCD screen controlled by a PCF8574T Chip

 

The TCA9548A has 8 x I2C channels, of which only the first four (SD0/SC0 - SD3/SC3) are used - one for each console controller port of the MrBoehm. Each channel has 1 x AD5242 potentiometer chip ( 2 x pots per chip) and 4 x ADG715 digital switch chips (8 x switches per chip).

 

Software-defined controller selection and Bluetooth syncing will be done through 5 x Push Buttons tied to 5 x GPIO pins set to Input (Pins 16,18,22,32,36) with status feedback to the user provided though updates to the LCD. The push buttons are not integrated directly on the MrBoehm so that they could potentially be customized for a 3D printed MrBoehm case in the future. Instead, screw port connectors are provided for push buttons.

 

2600/7800 controller port "data out" is provided by mapping the 2600/7800 pins 1-4 (as mapped to 5200 pins 7,6,5,8 via the 2600to5200 port converter) on MrBoehm controller port 1 to 4 x GPIO pins set to Input (Pins 7,11,13,15). The same pins on MrBoehm port 2 are connected to 4 x GPIO pins set to Input (Pins 29,31,33,37).

 

The primary purpose for enabling port output on the MrBoehm is to provide support for rumble support for Bluetooth/USB controllers that have a vibrate feature. This would only work for Homebrew games that programmed their IO to support this, so it is not useful for era games. Though I could be convinced to use "data out" for other features if requested by enough people.

 

Output is also not provided for 5200 control ports. My guess is that any controller port data output features supported by the 5200 don't operate on the same pins as the 2600/7800. Any feedback on "data out" support for the 5200 would be greatly appreciated.

 

The Hypothetical 2600 Controller

Attached is an image of the Hypothetical Controller that I have prototyped on a breadboard. I think others have proposed something similar in the past, so I don't claim originality. The controller has the following features.

1) Pot directional hat

--- Pot 0 controls horizontal direction (or more accurately - pin 5) where "no resistance" is "right" and "500K" is "left". Anything between 0-500K resistance is considered "centered"

--- Pot 1 controls vertical direction (aka pin 9) where "0K" is "down" and "500K" is "up". Again, anything in between is considered "centered"

--- For this to work, pot values need to be measured on scanlines 0 and 190, and I guess the relevant capacitors on the console would need to be functioning properly. I suppose it could be implemented in straight Assembly programmed Homebrews, but I only plan to use it with my CDFJ version of Quidditch that I have been working on for years and years.

2) 4 x Fire Buttons

--- Fire 1 - standard 2600 joystick fire button

--- Fire 2-4 - standard 2600 joystick up/right/down postions/buttons

3) Rumble Support

--- D6 and D2 of the SWCHA set to output, which means that a 3v mini rumble motor is connected to pin 4 and pin 8 of each 2600 port

 

The directional pot requires a 500K Ohm resistor between the "left" contact and pin 5, and another 500K resistor between the "Up" contact and pin 9. In my prototype, I use the same push buttons that I use for the fire buttons. The disk for the directional hat seen in the photo is the sticky back to a broken Pop Socket sitting on top of four push buttons.

 

This prototype will be implemented in the MrBoehm through software.

 

[EPIK]

Hello, here's a 3D rendering of the board and also a mock-up of the 9 to 15 pin dsub adapter.  This is my first time routing a PCB, if someone has experience routing PCBs please let us know if you have any suggestions or feedback.  More specifically, should certain circuits (power, ground, Atari I/O, I2C, GPIO) have more direct routes than others, greater clearances, not use vias, etc?

Schematic_Atari Adapter_2020-07-11_09-08-46.pdf

[RevEng]

Some commentary on the project... first off, neat! I think a general purpose bluetooth to multi system adapter is super useful and interesting. Kudos on the progress you've made so far.

 

I think there would be more interest in the project if people could easily understand what it is, and for you to think about your posts more in marketing terms. When I read "Mr.Boehm Raspberry Pi Classic Controller Hat for the 2600/5200/7800" I think "what the heck is a Mr.Boehm, and why would I want that?" and I'm a Linux geek who already understands what a Raspberry Pi and hat is. Being a geek I dived deeper and saw what you were doing. Perhaps the technical emphasis is intentional, with this project mostly being kept to the hardware forum and blog posts, but I think you'd generate more interest and support by making things understandable for the normies. With them, other technical folks will come too. 

 

So from a planned UI perspective, would one interact with the controller config via an http page, SD card, or what? Along the same lines, I think there's a lot of added value to be had in "adapting" some standard stuff to rarer controls, like mouse->paddle, mouse->driving, thumbstick->paddle, mouse->st-mouse, mouse->amiga mouse, mouse->trakball, etc. I'd say there's even a good chance of getting savekey emulation working here.

 

Rumble is neat, but if you're getting into console to boehm specific communication, you might leave the door open to the program signalling what controller type should be used. E.g. a pulse of certain joystick pins on game startup might signify that the standard "boehm paddle config" should be used.

 

I'm a longtime Linux user and admin. (I had my own x86 appliance dists back in the day, way before LFS was a thing. Was an early adopter of Linux appliances like Sheevaplug. I published a root exploit for a closed Linux NAS appliance.). I think boot times can be shaved down to the upper ranges of what you're thinking (I believe you mentioned 2-8 seconds) but to get close to that you're looking at something less standard and less user-modifiable (e.g. no standard distribution repos and packages), with a custom init and likely busybox binaries. If the end goal is an appliance, which I believe it is, then that's not a big deal. Just figured I'd make the observation.

 

[edit - one more observation in this vein... graceful shutdown is only needed if you have r/w filesystems open. I'd recommend just leaving everything read-only, and if you need to update a config from the UI, do a quick r/w remount, update the config, and then remount r/o.]

 

Anyway, my post here is a bit scattershot. Overall I just wanted to de-cloak and say "good job", and to encourage you to keep on keeping on! ?

 

[flickertail]

4 hours ago, RevEng said:

Some commentary on the project... first off, neat! I think a general purpose bluetooth to multi system adapter is super useful and interesting. Kudos on the progress you've made so far.

 

I think there would be more interest in the project if people could easily understand what it is, and for you to think about your posts more in marketing terms. When I read "Mr.Boehm Raspberry Pi Classic Controller Hat for the 2600/5200/7800" I think "what the heck is a Mr.Boehm, and why would I want that?" and I'm a Linux geek who already understands what a Raspberry Pi and hat is. Being a geek I dived deeper and saw what you were doing. Perhaps the technical emphasis is intentional, with this project mostly being kept to the hardware forum and blog posts, but I think you'd generate more interest and support by making things understandable for the normies. With them, other technical folks will come too. 

@RevEng - I very much appreciate this post. I feel you are correct on all of your points.

 

David and I have been disappointed in the lack of response, I just figured that the community might think that I am a wanna-be windbag pushing vaporware, so I kept getting more technical and more technical, thinking that the technical details would overcome it.

 

Especially since I have been a developer poking around on AA on and off over the past 12 years, but I have never really come close to finishing anything until now. I thought maybe that was contributing to people's lack of enthusiasm. You know, kind of a... "talk to us when you have something to show us" kind a thing.

 

As fare as the end result of the project, we plan it to be an appliance type of device with a static file system. Otherwise, it's just a modern computer talking to the console, and if that's the case, why not just play games with an emulator? Which is a valid question.

 

I agree, "Mr. Boehm Raspberry Pi Classic Controller Hat" is a bit... confusing.

 

Maybe I should call it something else, and say that "MrBoehm" is its development "code name" - like, Stella, Pam, or Maria. LOL. Essentially, the device is meant to be a Bluetooth/USB hub for classic Atari systems.

[flickertail]

As far as UI goes. We plan to have 5 push buttons on the device and a 2 row, 16 char LCD screen. If a keyboard (BT or USB) is connected, the user will be able to use some keyboard shortcuts to interact with it more quickly.

 

This has just been a discussion between David and I, so we are open to ideas.

 

Originally, it was just a series of LEDs and push buttons. I suppose there could be an app at some point as well, maybe through BTL or something. However, I have found iPhone communication with the Pi over BT to be a bit problematic. To the point where I gave up on it.

 

I suppose it could be done over WiFi too, but I hesitate to turn on the WiFi because of hacking.

[RevEng]

For sure a little of the lack of response is the "we'll see", but I think a larger part is the location (hardware forum, and blogs) and the marketing. IMO you've already shown a proof of concept working, which will get most people over the "we'll see" hump. When you first started blogging about it, I was in the sceptical "we'll see" camp too, until you started showing off your progress.

 

I think "MrBoehm" is fine if you're attached to it for personal reasons (it certainly is unique) but it should be paired with a rough description of what it is for the end-user, even if it's approximate or imperfect. e.g.  "MrBoehm Bluetooth Controller Adaptor" . In your first paragraph of a new topic on this project, provide some detail of exactly what it is, in terms of what the end-user gets out of the device, rather than how it's implemented. Later as more people get more familiar with the project you can just have a link to a description for new folks, and then eventually drop it altogether when the project is critical mass.

 

As far as the location, IMO I'd hit up the 2600 forum with a general recap of the idea, and cross post some links in the other supported platforms to that thread, since the 2600 scene is likely your biggest target audience. The blogs are a bit of a viewing wasteland, and the hardware forum is limited in scope.

 

To me wifi and an http interface would be preferable to the screen and buttons. It would allow for more nuanced configuration, which could be pulled off from your couch. e.g. the kind of device emulation that I was talking about in my previous post would be a nightmare with buttons and lcd screen. I don't personally care if the box is easily exploitable or even wide open... if it's behind my router and it doesn't reach out to the internet (it doesn't even need to be routable to the internet), it's miles ahead of the Windows PCs and download games that my kids are using at home.

 

But it might be good to put this same question to the audience of that marketing-focused post.

 

[edit] if it doesn't add too much to the cost or footprint, it might be very good if we had a few spare gpio+level-shifters on board, so if one was inclined, they could mod their console with a harness that provided control over the console switches. Or perhaps the 4 port version might be able to have an option to configure a spare port for this, for 2 port consoles.

[flickertail]

1 hour ago, RevEng said:

But it might be good to put this same question to the audience of that marketing-focused post.

 

[edit] if it doesn't add too much to the cost or footprint, it might be very good if we had a few spare gpio+level-shifters on board, so if one was inclined, they could mod their console with a harness that provided control over the console switches. Or perhaps the 4 port version might be able to have an option to configure a spare port for this, for 2 port consoles.

 

@RevEng - Not sure what you mean by "GPIO level shifters". Is there a way to use a GPIO pins through some sort of shifter?

 

Gain access to the console switches would require that a user probably hack their console.

 

That said, there are four open I2C on the multiplexer. I have contemplated making the device modular. Where based device has two ports, and then additional ports could be added in two's up to eight ports. Not sure exactly how that would work, as that's not currently in the design.

 

And only the first two adapter ports have Atari controller port I/O capabilities as that is all the GPIO pins we current have available.

 

If we go with a HTML/App UI for setup and controller selection, that would free up at four of the five UI GPIO pins for other things. I'm still not certain it would be a good idea to remove the 5th UI GPIO pin because that's the Bluetooth pairing button. The actual use of the other four have yet to be defined.

 

If you hacked your console to expose the console switches, there's no reason why you couldn't control console switches through one of the ports. You wouldn't even need to touch the GPIO pins for that purpose. Aside from the pots, everything else is just an I2C controlled switch. I'd have to write the python code for it, and the mechanism could be defined in the controller map JSON file. But it's not an unreasonable request.

 

I suppose could create a 3D printed case, put your 2600 board and the adpater (including the pi) in the case and have a system that would be completely controlled from a bluetooth controller. You'd only have to get off the couch to change games and turn it on/off.

 

Ok, I've posted a poll to the 2600 Forum. Hopefully, it will drive interest.

 

 

[RevEng]

Oh, I see. I hadn't looked at your hardware implementation details before. I had assumed you were using GPIOs with level shifters attached, to connect to the control port logic. I now see from what you're saying that you're using an i2c controlled switch. Either way, my point was just to have some spare connectivity for the console switches, which you've confirmed, so all good.

 

Good stuff on the post. I'm sure it will drum up interest - it's an interesting project.

[flickertail]

See attached for an example of the "settings.json" file.

 

It contains information for:

• Default Controller Template to be used.
• Supported BT/USB Controller Maps (Could also contain maps for keyboards, mice, etc...)
• Classic Console Controller Templates List by Console Type (aka port maps)
• MrBoehm port-level I2C memory map for generic switch and pot settings (aka "addresses").

I coded this all by hand, however eventually, I plan to make a tool that generates this JSON file automatically.

 

settings.json

[+fdr4prez]

I read the first three posts and was quite confused by it all.

 

9 hours ago, flickertail said:

Essentially, the device is meant to be a Bluetooth/USB hub for classic Atari systems.

That one line said it all for me.  Now I know what the project is suppose to do.

 

That should have been the first line of the first post and then start with all the technobabble  

 

Granted this is the Hardware subforum, so all the techie talk is welcomed here.  I just needed a little bust to get up to speed on what the plan is.

 

6 hours ago, RevEng said:

Good stuff on the post. I'm sure it will drum up interest - it's an interesting project.

I agree