Your controller replacement options for a displaywriter beamspring are:
- xwhatsit's displaywriter controller
- a TH controller, with the displaywriter plugboard attached, you can reuse the OEM controller's connector, or you can use a 'new' connector, but depending on the type of new connector it may or may not allow you to use the mounting tab to secure the controller to the keyboard on at least one side. If you reuse the original connector, then that definitely has the correct depth, to screw the controller to the keyboard
- a TH controller with no attached plugboard, but with a connector manually wired point-to-point directly to the TH motherboard. Must be wired the same as the plugboard would make the connections.
- Any Model F controller (including xwhatsit, wcass, TH, or my SMD model F) can be modified to make it work with a Displaywriter. See an example of someone doing that here to an original xwhatsit model F controller: viewtopic.php?t=16469. If you plan to use original xwhatsit firmware then all you have to pay attention to is that rows go to rows and columns go to columns. If you use my firmware and don't want to custom edit code to make it work, then there is only one correct pin mapping you can use, and it depends on the controller you're using. (I can elaborate if you want to go down this route)
- DMA's Common Sense
The first two are the cleanest solutions.
If you want to build a TH, I've put a lot of effort into documenting important details, like
BOM,
Bare PCB Ordering Instructions,
Errata, etc... Just make sure you use the
gerbers from the repository, not older outdated gerbers you might find in the forums or elsewhere. Hopefully the links in the BOM are not outdated, but there is enough detail there that you should still be able to easily find replacement parts if the links don't work anymore.
The reason plain beamspring controllers will not work (including xwhatsit's beamspring controller, and my compact beamspring controller), even with modification, is that plain beamsprings only have 4 rows, which can be handled by a single quad-comparator chip. There's one less comparator chip on plain beamspring controllers. (and one extra shift register, because there's also more columns). So it's not possible to adapt it by just wiring to the right pins.
Credit/History
I most certainly don't want to take credit for other peoples work, so let me clarify things:
1) First there was xwhatsits original work, which includes:
- theory of operation
- schematic
- pcb layout
- firmware
- software
All credit here goes to xwhatsit.
All of xwhatsit's boards use the atmega32u2 chip.
2) wcass
wcass has drawn up a smaller controller that Ellipse uses in his keyboards. The
PCB layout was redrawn by wcass, but everything else is the same as original xwhatsit.
viewtopic.php?f=7&t=13479
3) my firmware, aka the qmk firmware
My firmware is an alternative firmware which was first only implemented for original xwhatsit boards, and also the wcass redraw. My firmware still supports all original xwhatsit and wcass boards too.
I implemented it myself from scratch, and it drives the hardware fairly differently than the original firmware does.
Credit goes to
tentator for testing. That may sound too small to mention, until you realize that the firmware was first written without me owning any xwhatsit hardware, so we had to
test it to life, and
we worked very closely together to get it ticking.
4) TH
The TH, or the "$10 DIY Through Hole Universal Model F and Beamspring Controller" was initially begun by
listofoptions & kmnov2017.
It is based on
xwhatsit's original work, but it uses atmega32u4, which is a newer version of the chip, mainly because the intent was to rely on the Pro Micro development boards to keep things through-hole-solderable, which was also a great decision, because somehow pro micros are easier to find than the chip that's on them. And it also uses a different DAC, because it was easier to source.
For these reasons the original xwhatsit firmware is not compatible with the TH. (it can be made compatible though).
I offered however to port my firmware to these boards, and at the moment my firmware is the only one that works on these boards.
The TH still uses the exact
same theory of operation as original xwhatsit, so all credit still goes to xwhatsit for that. The schematic
was redrawn, but it's pretty much just a copy of xwhatsit's work with different components.
However
listofoptions and kmnov2017 receive the credits for: PCB layout, replacement parts choice, and in general making it easy for anyone to build these, even if they don't have the ability to do SMD soldering.
I have also contributed a little bit later on to newer versions of the TH, to polish up things. Please don't use my fork of the TH, it's only there to allow me to push branches, please use the head of the
listofoptions repository whenever ordering TH PCBs.
5) My compact beamspring controllers, and SMD Model F controllers
These are all based on the TH controller.
Initially listofoptions started out by switching the TH components to SMD, trying to make another modular design that would support all beamspring/model F keyboards like the TH does, and I also tried contributing to that. In parallel I also started the compact beamspring controller design mainly because I didn't really feel like the modularity was an all-that-important requirement for an SMD design, and there were just so many constraints in trying to support every keyboard, it would make things too hard and slow, while not really offering a size-optimized solution for any particular keyboard. Eventually the modular SMD controller based on the TH didn't get anywhere, but my Compact beamspring design was quickly ready.
While I did all the CAD work on the Compact Beamspring Controller PCB design myself,
I cannot overstate the importance of the contributions of listofoptions, kmnov2016, tentator when it came to discussions, and trying out designing the various other designs even if those prototype designs didn't see the light of day in the end.
Since these controllers are are based on the TH, with virtually almost the same schematic, only my firmware supports these for now, hence they're being called the 'qmk' controllers by many, although I think it's not necessarily a good name, cause they can in the future potentially support xwhatsit's original software as well when someone, maybe even me, implements the necessary changes.
I try to give credit everywhere I can, we're all standing on the shoulders of giants, there's mentions of all of these amazing people who contributed on the PCB silkscreens, in the software USB strings, etc... If anyone thinks I could do a better job properly giving credit, please message me, so I can improve on this.
Chips
Original xwhatsit used
atmega32u2.
Why was the only-slightly-better
atmega32u4 used for the TH? I don't know I wasn't there when the decision was made, but I speculate it was because the pro micro is one of the most widespread and easy to get small devboards. RPI pico didn't exist yet. And porting the firmware was easier when choosing a chip from the same family.
Why my SMD designs use atmega32u4? Simply because they're basicly an SMD-ified version of the TH. I didn't want to do any porting of firmware, and the same .hex file supports both the TH and my SMD controllers, which is good!
Overall using atmega32u4 in a pro micro _is_ a great choice, cause you can still get them easily on ebay, and other places. Using say an STM32 might have sounded reasonable in the past but the supply problems affected STM32s more than pro micros. I'm glad the TH didn't go that way.
