New Apple 2 Keyboard replacement

I've been making progress -- just not posting it, so here is a series of updates.

The earlier post of the aligner was the aluminum version.  Here is the PCB version, with Gateron switches installed.

IMG_20240511_214154010.jpg

When you have dozens of diodes to bend and stuff, what do you do?

Well, you print a bending form.

IMG_20240512_164918814.jpg

The divots are appropriately sized for the diods and the width is correct for the PCB holes.  Allows me to bend 10 at a time.

IMG_20240512_164932865_HDR.jpg

The form is two parts that are identical.  Once the diodes are in place, the top part is put in place to sandwich the diodes in place.

IMG_20240512_164954537_HDR.jpg

The result is a strip of diodes with nicely bent leads, ready to be clipped and stuffed.

IMG_20240512_165212751.jpg

After a bunch of bending, stuffing, and soldering, the board is ready to mate with keys.

IMG_20240523_230504236.jpg

IMG_20240523_230451987.jpg

Can you spot the mistake?

Time to tackle the controller board.  Not my best soldering job ever, but its sufficient.  For those wondering, it took two tries.  First one I tried with my hot air gun.  I have an tip appropriate for the package.  Would probably have done well if I had ordered a stencil for the board.  Too hard to get even solder paste spread across the pads from a syringe.  Ended up pulling it off, cleaning it up and doing it a second time with a regular iron and the "drag method".  Came out decent.  Ended up with only one pin that I had to go back and touch up because it wasn't connected.

IMG_20240522_092100220.jpg

With that, I added the crystal and its caps, the bypass caps, and programming headers so I could program the chip.  That turned into an escapade in its own right.  Note that the fuse values in the CMakefile comments DO NOT agree with the actual values set by the CMakefile.  Ended up using a Bus Pirate to program the chip.

With the chip programmed and verification that it was at least scanning the key matrix, I put everything else needed, for an Apple II keyboard, on the board.

IMG_20240601_164929676.jpg

With the controller complete, it's time for testing. 

IMG_20240601_180031285.jpg

I actually found the badly soldered pin during testing.  Data bit #1 was stuck low.  Tracing it back was when I found the not connected pin.  With that fixed, all data lines toggled and all keys responded as expected.

IMG_20240601_180037510.jpg

Now, for the real test!

IMG_20240601_180352624_HDR.jpg

It's alive and appears to be fully functional. 

Oh yeah, did you find the mistake I made earlier?  It's a painful one.  I forgot to install the space bar stabilizer before I mated the keys+aligner to the PCB.  Unfortunately, there will be a bunch of de-soldering in my future to get them installed.

In post #54, 'wpmcamara' wrote:

"Too hard to get even solder paste spread across the pads from a syringe. "

Uncle Bernie comments:

the ladies who do the SMD soldering by hand in the company I worked for before retirement used a small brush (and a loupe) to apply solder paste to the solder side of the pins, while holding the SMD with a "suction cup" type tool. Then they positioned the SMD on the PCB, hand soldered and adjusted two diagonal pins, and the rest was done by a  combination of pre-heat and hot air. This technique even works with BGAs. The trick is to get the right amount of solder paste on each pin. I tried to replicate their technique myself but failed. It's not easy. But these ladies had the skill.

- Uncle Bernie

UncleBernie wrote:

 

the ladies who do the SMD soldering by hand in the company I worked for before retirement used a small brush (and a loupe) to apply solder paste to the solder side of the pins, while holding the SMD w

That sounds like a neat trick, thanks for sharing! I've got some test boards I'm gonna try this on!

The brush method certainly sounds very difficult.

What works for many is to automate the paste application as much as possible. The goal is to apply the same size dot to all 88 pads (e.g.) of a QFP: so use a device+technique that can repeat the same size dot 88 times. Now the only manual aspect is positioning the syringe and activating the pump.

Got back from vacation and decided to tackle my mistake and get the spacebar stabilizer installed.

Made me an 8u stabilizer bar.  Since someone will ask, I have a DU-BRO E/Z Bender Wire Forming Tool.  Makes forming the bar much easier.

IMG_20240620_143821890.jpg

Installed.

IMG_20240620_144323801_HDR.jpg

All put back together.  Added a warm white power LED as well.

IMG_20240620_151554319.jpg

Met up with @dnfr2 this weekend to get a set of key caps and got them installed.

IMG_20240622_221028617.jpg

Mounting it was another story.  My Apple II+ has a rev 2 keyboard and mounting the replacement requires removing the controller board to be able to get to the screws.  And the screws are at an angle.  And, when directly mounted, the top lit bumps into the top of the keyboard and can't slide into place.  Still, I got it temporarily mounted and am quite happy.

IMG_20240623_211151213.jpg

IMG_20240623_211157526.jpg

IMG_20240623_211202504_HDR.jpg

IMG_20240623_211957133.jpg

IMG_20240623_212840695.jpg

I've got some longer 6-32 screws arriving tomorrow and I'll 3d print a space to allow enough room for the lid to slide into place.  Otherwise, its getting close to being called "complete".

I printed a set of spacers and palte to better mount the keyboard.

Both sides have a backing plate to better spread the force of the screws, and accounts for the angle of the screws.

IMG_20240626_172655902.jpg

Each side also has a spacer.  On one side, it's just a solid block.

IMG_20240626_172716560.jpg

On the other side, its a bit more complex because the aligner plate comes all the way over and has cutouts for the screws.

IMG_20240626_172730723.jpg

With the backing plates and the spacers, I can properly tighten the screws down, without bending or damaging the PCB.  The case lid now clears the aligner board.

IMG_20240626_172811302.jpg

With that, I'm considering this build done, at least as far as my Apple II is concerned.

Wahoo very impressive,

i need a set of keycaps for apple II+ do you know where I can find them ? vincebt

VIBR wrote:

Wahoo very impressive,

i need a set of keycaps for apple II+ do you know where I can find them ? vincebt

If you are looking for originals, then good luck.  Single keycaps show up on Ebay, as well as complete keyboards, but they aren't cheap.  The ones dnfr has will only fit Cherry MX style switches.

I can't believe I didn't see this before.  I just got done watching Chris' build video.  Awesome work, just awesome.

Can someone bring me up to date as to where this project is right now and if there is a way I can get/build one of these?

Thanks! :-)

Subject says it all.  I'm going to reduce your inventory... ;-) This is a great project.

Hello guys,

this is some really impressive work!

I've been desperately (and long) waiting for Apple ][+ replacement keyboards to show up on Reactivemicro, before I stumbled upon this thread. I'm good at soldering, but my technical skills are not at a level that'd allow me to produce or instruct a third party on how to build the PCBs for me.

Is it possible to sign up for a replacement keyboard kit here (keyboard + encoder)? I'm interested in buying 1-2 of these. Is there something like a wait list? 

I have original sets of keycaps. I am reading that these fit the Futaba MD switches in the comments below this video:

https://www.youtube.com/watch?v=LShPrPoK4dI&list=WL&index=62&t=2123s

I have a couple of superencoders from Reactivemicro, as well as full sets of original keycaps. I'm ready to buy the other components or trade mine for the components I'm missing. Can you please help me find the missing components so I can bring back to life my two Apple ][ Europluses? I'm based in Germany.

In post #67, 'shortydos633' wrote:

" I've been desperately (and long) waiting for Apple ][+ replacement keyboards to show up on Reactivemicro, before I stumbled upon this thread. "

Uncle Bernie comments:

Don't be desperate, just try to contact 'dfnr2' by using the "send PM" button and ask him if he has some PCBs left over.

Also note that a few days ago I have revived my own keyboard project, but it has slightly different mission objectives, as it primarily is meant for the Apple-1 builder scene. Recent trouble with original Apple II keyboards I have used so far (and converted for Apple-1) nudged me into  taking my project from the back burner and finishing it, and as I have some original Apple II keyboard encoder cards around, I added the 25 pin connector to make it able to accept such an encoder. The open question still is if the result fits mechanically in the Apple II shell.

Here is my thread:

https://www.applefritter.com/content/does-anyone-know-source-25-pin-apple-ii-keyboard-connector

The title shows why I just had to do it. I have two original Apple II keyboards which I have restored in many hours of work, but one of them has a flaky Molex connector and as the thread found out, these are out of stock everywhere. So I had to make a new layout supporting the Hirose connector which still is in stock at several distributors.

If 'dfnr2' is sold out, I have ordered a few PCBs more of my own design than I need, and my part with the excess at my own costs.

BUT . . . here is advice for readers who have followed this thread here (not the mine):

Some commenters have expressed concerns about ordering keyboard PCBs by themselves, from the github files. IMHO these concerns are justified.

Once you have mechanical specs to be observed for the mounting of the key switches, it may get tricky to get what you want (the jury is still out on my own attempt to make a keyboard PCB). Too many things can go wrong even when the Gerbers are the same and once yielded working PCBs. This is because every PCB manufacturer has their own internal processes, CAD/CAM tools and interfaces and they need to convert your Gerbers back to their in-house tools. Occasionally, something can go wrong in that process. Frankly, Gerbers are NOT the best way to specify PCBs, because of these possible ambiguities and pitfalls. But Gerbers happen to be the old-time industry standard and every PCB manufacturer supports them. Despite of the risks.

Yet another issue is NRE costs which can't be spread out over many PCBs, so small quantities of PCBs typically needed by an individual may have prohibitive costs per unit.

So my advice is, don't attempt to order these 'dfnr' PCBs by yourself, but ask 'dfnr' if he has some left for you. This will take the PCB manufacturing pitfalls away from you and he will be happy to sell off his excess parts inventory.

- Uncle Bernie   

Thanks for your extensive reply. I will definitely follow your advice about the PCBs! It seems that getting new keyboards will be an ongoing topic, so I will surely check out this and your thread regurarly. Any other suggestions on from where to get replacement parts / kits / complete keyboards would be much appreciated! Thanks again!

Hello everyone,

I'd like to give you an update on my progress with Dave's Unified keyboard kit. Long story short: the mechanical assembly was successfull and the keyboard looks and feels amazing! However, after several programming attempts, the Apple II does not react to keystrokes nor RESET. Any hints or advice on programming the Atmega328P would be greatly appreciated as I already ran out of ideas!

Several months ago, I posted here and asked Dave to send me a Unified keyboard kit, as I was intending to build a new keyboard replacement for my Apple II+.  After he sourced new PCBs, he was so kind to send me the kit, as shown below on photo 1 (keyboard, aligner and encoder PCB, keycaps, misc connectors). As a disclaimer, before starting, I read all possible threads on forums and the internet on the project and how to put together a working keyboard, based on this kit.

I opted for the Cherry aligner since I'm based in Germany and I could find Cherry key switches of various types cheaply. I went for Cherry MX black switches from here, which cost me about 0.50€ per piece:

https://www.reichelt.de/de/de/shop/suche/cherry%20mx%20switches?GROUPINDEX=0&search=cherry+mx+switches

Next, I needed to source a stabilizer rod and the spacebar side supports, since these were not included. I found something on Aliexpress that matched what I was seeing on Github and forum photos and bought it:

https://de.aliexpress.com/item/1005009539466906.html?spm=a2g0o.productlist.main.1.528c5ab1RIjRM4&algo_pvid=ab1642e4-534c-4103-9a85-ca573915c7e2&pdp_ext_f=%7B%22order%22%3A%221%22%2C%22eval%22%3A%221%22%2C%22fromPage%22%3A%22search%22%7D&utparam-url=scene%3Asearch%7Cquery_from%3A%7Cx_object_id%3A1005009539466906%7C_p_origin_prod%3A

The supports are a perfect fit to the PCB. However, the stabilizer is a 6.25U length, which is too short. The correct length of 8U simply does not excist anymore, so I needed to bend a stabilizer myself. In the process, I found that the correct spacebar installation was the most difficult part of the assembly. While I was waiting on the supports, I bought a 1.60 mm wire, as I read on the internet that the original rod was made from 1/16" (1.59 mm) thick wire. As someone mentioned on the forum, you need to be very precise to get the correct length. The supports are spaced 133,5 mm axis to axis and this is what you should aim for after bending. However, it is also important to get a smooth 90° bend with the smallest radius possible (see photo 2). Otherwise, the rod will not snap under the clip of the support or you risk breaking the retaining clip. I bent 5-6 rods until I got a rod that will work. However, the rod still snapped only with a lot of force and the mechanism was prone to slight jamming when the spacebar was pressed. When the aliexpress supports arrived, I found that the supplied 6.25U rod was 1.50 mm in diameter, so I decided to give a thinner wire a try. I ordered 1.50 mm thick, 30 cm long straight pieces of wire from here:

https://www.ebay.de/itm/175584943363?var=475856438007

This wire was perfect, as it did not come rolled and did not need to be straightened. After couple of attempts, I manage to produce a stabilizer that snapped perfectly into the supports (photo 3) and without too much pressing force. It's not а loose fit either, so the stabilizer cannot fall off with the keyboard moved around. The ends that go into the supports need to be cut to 10-11 mm, as indicated by Dave. Now the spacebar actuation works and feels perfectly.

I also found out that the spacebar supports' lateral position does not match the PCB supports spacing. The former are spaced at 101.5 mm, while the latter are 133.5 mm apart (this may be something Dave could address before he orders the next batch of keycaps). I designed retainers for this spacebar that can be 3D-printed (photo 4). They snap between the small ribs at the correct lateral position in the spacebar perfectly. It is a tight fit and they do not even need to be glued. See the links for the STL and STEP files if you are interested to 3D-print the adapters yourself. Please note that if you do, you should know that the "+" cutout is too tight. I 3D printed my retainers at 80% fill density, so I recommed you going for 60% or 40% for more loose fit. Otherwise, the spacebar can be installed, but you'll need to press it hard to snap into place. 

Spacebar support adapter STL file (you need 2x)

https://limewire.com/d/FT3Mf#1EP8iEwmeb

Same adapter in STEP format (you need 2x):

https://limewire.com/d/NIoIX#7I9XPjhfpC1

After all this, I was ready to assembly the keyboard completely. One thing I did was to wait with the aligner installation until I got all required parts. And I recommend you installing and testing your spacebar, LED, resistors, etc. before you do too. Otherwise you may find out that you need to unsolder dozens of switches for access and fixing stuff.

I went with the 3-post Cherry MX swiches, although the single-post would work too. I found out that they sit very solid on the main PCB, even without the aligner. However, I decided to install the aligner, as I already had it.

I wouldn't put all switches on the aligner and then try to snap everything into the main PCB, as suggested. I found that some swiches come with slightly misaligned pins, which will bent in the process and won't make electrical contact. Instead, I went for installing four swiches just in the corners of the aligner (photo 5). (Just make sure you place the four switches and the correct locations. Placing the aligner over my old Apple II keyboard worked best). Then I soldered the four switches to prevent the aligner snap out from the PCB. After that, I added all swiches one by one, while I as watching the PCB from behind and making sure the switch pins were straight and could be see coming out of the holes before pressing them into place.

One pleasant suprpise was how well the POWER LED fit into the keyboard (photo 6). Each Cherry MX switch has a cutout for individual LED (remember to use 3 mm LED). The PCB has two pairs of through-holes for the LED and one sits directly beneath the switch (both pair are electrically connected). The LED can be installed easily, as also seen from the back of the PCB (photo 7). The POWER button can be used freely as such, as indicated by Dave. I also can't help but notice that the main PCB can be designed for individual LEDs for every switch, the same way it is for the POWER button. Combined with some modified keycaps with translucent bottom half or third, this may produce an interesting product for the Apple II and others in a later revision. Just an idea ;)

One little modification I did was to install the LED resistor on the underside of the PCB (photo 7). This way I can easiliy replace it and adjust the supplied voltage to the LED. I installed a 3V LED (that does not work for some reason, although it is connected to the power rail). I went for 330 Ohm resistor and I'm measuring 2.5V voltage drop between the terminals.

Photos 8 and 9 show the assembled keyboard. And yes, It looks and feels amazing. And now the bad news: it does not work.

I'm not including photos from the Encoder PCB assembly, as it was pretty straight-forward. I sourced the required chips, sockets, caps, etc. locally and from new parts and assembled them according to the instructions on githib.

I bought a Arduino Uno clone board with another Atmega328p on it as a programmer device. A quick disclaimer: I've never used an Arduino, but I do have programming experience.

It a first attempt to program the Encoder, I followed some instructions I found on the internet ( https://www.youtube.com/watch?v=TtC6crf_EP4 ). You can see the wiring and the programming setup on photo 10. I downloaded the Arduino IDE from the official Arduino page, as well as the proper keymap file from here:

https://osiweb.github.io/unified_retro_keyboard/index.html

(I went for the asdf-v1.6.5-atmega328p.hex file)

Arduino IDE recognizes the programmer and does not complain that it is not a genuine Uno. After wiring up and connecting the Uno and the Encoder, I selected in the IDE the proper device (Arduino UNO) and corresponding COM port. Then, I loaded ArduinoISP from the examples library, which opened a new window with the code. From Tools, I chose Programmer: Arduino as ISP and I uploaded the code.

After some Google search, I found that a hex file can be uploaded to the Encoder easily with avrdude by using a command prompt command. I came up with a command to match the file name paths, COM and Baud settings (the Baud matches the baud in the ISP code) and executed it. Avrdude started to spit out output, including "Writing..." progress bar, which took about 7 s seconds to fill and complete. I was amazed that it all went through from the first try! The output is shown on photo 11.

Photo 12 shows the final result. I had the feeling that the programming went too smoothly and was way too easy, and unfortunately, I was right. The Apple II does not react to key strokes at all, even not reset. I troubleshooted whatever I could. I used my multimeter to check for voltages and continuity. I measure contiuity between GND terminals as expected, the LED (which, by the way, does not work either, for a yet unknown reason), the encoder to keyboard header, and the chips all get 4.99V, as expected. The Atmega chip is getting correct 5V at the appropiate pin and it's GND pin seems to be connected the GND pins on all headers. When I short RESET with GND on header J4 on the Encoder, that triggers reset on the Apple II, but this is the only sign of life I get.

I'm confident that my assembly and solder work are fine and that the most probable cause is inproper programming. I tried to set the Enocoder jumpers to 0010 (all caps Apple II setting) prior to programming and to reprogram. This, as all other attempts, yielded the same result.

One thing I noticed is that the fuses are reported in the output as follows: Fuses OK (E:FF, H:D9, L:62). Dave's saying the correct configuration is Extended: 0xFF High: 0xD9 Low: 0xD2, i.e. low fuse should be D2 instead of 62. I did not find a way to modify these and I'm not sure if this what is causing the programming failure.

If you have any hints or even some instructions on how to program the Encoder for this particular use case, I would be endlessly grateful. The setup cost me money and a lot of time, but more importantly, the keyboard looks and feels great and I really want to get it working. Any help will be much appreciated!

Regards,

Martin

P. S. I'm sorry for my chaotic text in English. It is not my native language and I'm writing this already frustrated and in a beginning state of desperation :D

IMG_4137.JPG

2

IMG_5067.JPG

3

IMG_5157.JPG

4

IMG_5226.JPG

5

IMG_5231.JPG

6

IMG_5232.JPG

7

IMG_5233.JPG

8

IMG_5239.JPG

9

IMG_5241.JPG

10

IMG_5062.JPG

11

Output_Arduino_Programming.jpg

12

IMG_5238.JPG

shortydos622 wrote:

One thing I noticed is that the fuses are reported in the output as follows: Fuses OK (E:FF, H:D9, L:62). Dave's saying the correct configuration is Extended: 0xFF High: 0xD9 Low: 0xD2, i.e. low fuse should be D2 instead of 62. I did not find a way to modify these and I'm not sure if this what is causing the programming failure.

This would most certainly cause problems.  The low fuse byte being 0x62 is the default setting.

ATmega 328/328P chips have a built in RC oscillator which has a 8.0MHz frequency. New chips are shipped with this set as the clock source and the CKDIV8 fuse active, resulting in a 1.0MHz system clock.

Settubg the low byte to 0xD2 disables CKDIV8, among other things, resulting in an 8MHz processor clock.  So, it's likely that your MEGA328 is running 8x slower that it should be.   The avrdude command to program the lower flash by to 0xD2 would be:

-U lfuse:w:0xD2:m

Word of caution -- be careful programming the fuses, especially the clock fuses.  If you get it wrong, you may well stop yourself from being able to program the chip.  For example, if you accidentally programmed the fuse to 0xD0, instead of 0xD2, you have now set it to use and external clock signal, rather than the internal RC oscillator.  Even worse, its not set for an external crystal, but an external clock, so you couldn't even just breadboard up a crystal connection to the chip.  The only way to recover from that kind of mistake is with a programmer capable of programming the chip in "parallel mode".

Hello,

thank you so much for your reply! OMG, this worked! Well, kind of. All keys now work, except for the spacebar, and the LED turns on too!

I checked the space bar switch for contiunuity and it works properly. But the strokes do not get registered or something. I also know something else is not right: the keyboard works only when I leave the UNO programmer wired to the encoder! The moment I disconnect the 5V line, the LED turns off and the keyboard is dead, as previously. How this could be? Could it be that I actually accidentaly programmed the 328P on the UNO which acts as a microcontroller to the keyboard? But the UNO is wired as a programmer (see the second photo) - there is nothing hooked to the UNO's ISP interface.

I'm sorry, I have almost no experience with Arduino and this microcontroller programming. I just want a properly working keyboard, but I'm lost again. Do you have any other hints?

This is already a lot of progress, though. Thanks a lot again!

Martin

IMG_5284.JPG

IMG_5285.JPG

From what I've read Gateron are one of the better Chinese knock-offs.  Many of the others are not considered to be as good as the Gaterons.

For a hobby keyboard on a retro machine, the Gateron are probably not a terrible choice since they are lilely to hold up fairly well given that they are not going to be likely to be used thousands of continuous hours like on someone's main productivity machines.  Or even worse expected to handle the intense usage that something like a gaming rig might get.  For those applications paying a bit more for the known quality of geniuine Cherry MX keyswitches would be quite understandable.  The cheaper knock-offs are going to be much more of a crap shoot.  They might be fine, they might not hold up.  You just never know.

Maybe your strobe signal is not clear enough? Does the micro has built in pull-up or pull-downs? Maybe tweak with the length of the strobe signal? Just some ideas.

nijssen wrote:

Maybe your strobe signal is not clear enough? Does the micro has built in pull-up or pull-downs? Maybe tweak with the length of the strobe signal? Just some ideas.

To my bitter dissapointment, after reprograming the encoder, the keyboard does not work again. The LED does not light up anymore and the keystrokes do not get registered. I really do not understand. I only tried an earlier version (1.6.4) of the binary file (as the spacebar did not function with after flashing with the 1.6.5 version - asdf-v1.6.5-atmega328p.hex) and I reprogrammed without unplugging the encoder from the keyboard (but the KBD was not plugged to the Apple II).

I'm executing exacly the same steps and the process looks exactly the same as for the previous, successful attempt: the activity LED on the Uno is blinking, flashing takes the same 7.54s to execute, the reported fuses are correct and the output is 100% the same. And yet, the KBD is dead. Could it be that I've damaged the Atmega 328P on the Encoder? But if so, how come it still gets programmed without giving any errors?

I'm not familiar with strobe signals, configurations, etc. I'm a beginner in microcontroller programming. I'm only learning it because I want to get a working keyboard after a significant investment and because I saw yesterday it could work. I'm confident I'm making a programming error. The KBD seems to be functioning fine electrically. I did not have an explaination why everything worked, except for the spacebar. That's why I tried a different hex file version, which brought me back to square one / with dead keyboard. The problem is persisting now also with the hex file that I use on my successfull attempt. 

I have a theory why the keyboard (except for the spacebar) worked, but only with the Uno attached. The Uno PCB has two crystal oscillators, while the Encoder board does not have any. I believe the 328P has an internal osci.  It may be that I'm programming the 328p to look for an external clock. When I hook the Uno, it provides this clock, but as soon as I unplug it, the 328p shuts down / does not work on its own. Could that be?

Unfortunately, my  knowledge is too limited on tweaking any configuration files, settings, etc. I'm using the default avrdude.conf file Arduino IDE, but it's contents are too long to paste here.

Any suggestions and ideas will be highly appreciated!

Output_Arduino_Programming_second_try_encoder_does_not_work.jpg

shortydos622 wrote:

I checked the space bar switch for contiunuity and it works properly. But the strokes do not get registered or something. I also know something else is not right: the keyboard works only when I leave the UNO programmer wired to the encoder! The moment I disconnect the 5V line, the LED turns off and the keyboard is dead, as previously. How this could be? Could it be that I actually accidentaly programmed the 328P on the UNO which acts as a microcontroller to the keyboard? But the UNO is wired as a programmer (see the second photo) - there is nothing hooked to the UNO's ISP interface.

This strongly implies that there is a problem with the 5V supply to the encoder board.  Without the programmer attached, but the board connected to the Apple II and powered up, check the voltage between pins 2 (+5V) and 6 (GND) of the ISP header.  It should read 5V, but based on what you have said, it may not.  If it does, then check the voltages between pins 7 (+5V) and 8 (GND) on the ATMega328.  Likewise, they should be 5V.  The programmer does not provide a clock for running the target microprocessor.  It's one of the reasons I posted the warning about changing the fuse settins.  If you accidentally programmed it for an external clock or crystal, there is no way to fix that with the serial ISP programmer, unless you have a way to attach and external crystal or clock to the target microcontoller.  You can narrow things down by unplugging all the ISP connections except +5V and GND.  If things still work, it's totally a power problem.  If things don't work then plugging connections in, one at a time, until things work again and note what it took.

All keys now work, except for the spacebar,

Given that other keys that share the row signal , P Z A Q, work and other keys that share the column signal, B G, work it is unlikely the problem is with the encoder board or the signals to it.  That leaves the spacebar itself.  You said you checked continuity on the spacebar, I'm going to assume that means you checked that there was continuity on the spacebar switch when pressed.  If you meant something else, confirm the switch has continuity when pressed.  Also check continuity on the PCB.  On the image below, check continuity between the two points circled in blue and check continuity between the two points circled in red.  

key_cont_test.png

I expect all will show continuity, since all the other button work, but it's always good to check everything -- even the things you are pretty sure are ok.

My guess is that there is a problem with the diode for the spacebar.  Either it's missing, bad, or it has a bad solder connection.  Since it looks like you used the surface mount diode option you would have avoided the option of "inserted backwards".  Let's assume its not just "missing" -- if it is, well that's an obvious fix.  Unplug the keyboard from the encoder.  Hopefully your meter has a diode test setting.  If so, set it to diode test an use the two points circled in red below to test the diode.  If you don't have a diode setting, use the ohms setting.   You want to test it in both directions.  One direction should give a reading, the other shouldn't.  If you have a diode setting one direction should give something between 0.5V and 0.8V.  The other direction should read nothing (--, OL, etc).  If using ohms, one direction will give a relatively low resistance and the other infinite.  In either case if you get nothing in either direction, the diode is bad or you have a bad solder joing, or just forgot to solder a pin.  Unlikely you will get a reading in both directions as that would impact the functionality of multiple keys.  However, a reading in both directions is bad as well.

key_diode_test.png

To my bitter dissapointment, after reprograming the encoder, the keyboard does not work again. The LED does not light up anymore and the keystrokes do not get registered. I really do not understand. I only tried an earlier version (1.6.4) of the binary file (as the spacebar did not function with after flashing with the 1.6.5 version - asdf-v1.6.5-atmega328p.hex) and I reprogrammed without unplugging the encoder from the keyboard (but the KBD was not plugged to the Apple II).

Now for the learning experience.  As you noted you have zero experience with microcontoller programming -- the space bar issue is, 99.99% chance, not a software problem.  But, don't feel bad for not knowing.  Things didn't work, and you made a change, the only change you knew to make, and tried a different firmware version.  It didn't fix things and, in fact, made things worse.  You didn't specify whether you have gone back to the 1.6.5 version, though your screenshot implies you did.   If not, do so.  Hopefully, things revert to the "everything works but the spacebar" state, with the ISP plugged in.

Thank you very much for your extensive reply. It helped a lot! Thanks to your comments, I found out that the spacebar diode was indeed faulty.

But let me go through everything you said:

"This strongly implies that there is a problem with the 5V supply to the encoder board.  Without the programmer attached, but the board connected to the Apple II and powered up, check the voltage between pins 2 (+5V) and 6 (GND) of the ISP header.  It should read 5V, but based on what you have said, it may not.  If it does, then check the voltages between pins 7 (+5V) and 8 (GND) on the ATMega328.  Likewise, they should be 5V."

Let me explain my setup again. I move the Uno and the Encoder, wired together between the PC for programming and the Apple II for testing. When I test on the Apple II, the Encoder gets power from the Apple, while the Uno is wired to the Encoder through the Encoder's ISP header. See the photo below. The Uno is not hooked to the PC or a third power source via the USB. It gets its 5V power solely from the Encoder.  Unplugging the 5V line cuts the Uno, but the Encoder is still powered the same way from the motherboard. And this is how the keyboard worked the first time after I flashed the 328p with the correct fuse settings per your first post.

IMG_5301.JPG

Nevertheless, I still checked all pins you suggested for 5V. On all pin pairs indicated on the photo below, I measure 4.97V. All other components and the connector to the keyboard itself also get 4.97V. That's why I believe everything is powered properly.

IMG_5302.jpg

"The programmer does not provide a clock for running the target microprocessor."

This is a very helpful comment. It means that the 328p on the Encoder worked on its own during the successful try yesterday. But if the Uno did not provide power, how else can be explained that the Encoder stopped working every time I detached the 5V line on the ISP and then jumped back to life immediately when I replugged it? I guess it really wasn't the clock that the 328 was missing, as it would continue to work if I detached any other wire on the ISP header.

"Given that other keys that share the row signal , P Z A Q, work and other keys that share the column signal, B G, work it is unlikely the problem is with the encoder board or the signals to it.  That leaves the spacebar itself."

Yes, this was spot-on! I measured successfully for continuity at the indicated locations. And yes, I meant to say that I measured the switch working properly (shorting) when pressed.

"My guess is that there is a problem with the diode for the spacebar. "

I do have a multimeter with diode testing mode. And the spacebar diode showed OL in both directions. It is now quite obvious that this was the cause for the spacebar, and not the programming, as you suggested. I bought a bunch of through-hole diodes for the encoder, so I replaced the faulty diade:

IMG_5300.JPG

Now I measure 0.63V in the operational direction and OL in the opposite direction. By the way, I tested and measured 0.63V/OL on every single diode on the keyboard and the Encoder, except for 4 out of the 8 diaodes on the Encoder below the ISP header. These are responsible for the DIP switches. In their case, I measure 0.63V in operational direction and ~2V or 1.8MOhms in reverse direction. All DIP switches were off. I hope this isn't an issue.

I must say, I'm pretty confident the spacebar would work now and I'm very grateful for your help. Unfortunately, the keyboard is still irresponsive, no matter how many times I reflash the 328p. And yes, I'm using version 1.6.5 of the hex file. The one with which it worked briefly.

I'm planning to buy a bunch of new 328p chips and see if I get the keyboard work again as it did yesterday. I'll source them from a different supplier, just in case. However, I can only hope this would make a difference and the keyboard would work without the Uno wired to it, or at all.Martin

Let me explain my setup again. I move the Uno and the Encoder, wired together between the PC for programming and the Apple II for testing. When I test on the Apple II, the Encoder gets power from the Apple, while the Uno is wired to the Encoder through the Encoder's ISP header. See the photo below. The Uno is not hooked to the PC or a third power source via the USB. It gets its 5V power solely from the Encoder.  Unplugging the 5V line cuts the Uno, but the Encoder is still powered the same way from the motherboard. And this is how the keyboard worked the first time after I flashed the 328p with the correct fuse settings per your first post.

...

...

This is a very helpful comment. It means that the 328p on the Encoder worked on its own during the successful try yesterday. But if the Uno did not provide power, how else can be explained that the Encoder stopped working every time I detached the 5V line on the ISP and then jumped back to life immediately when I replugged it? I guess it really wasn't the clock that the 328 was missing, as it would continue to work if I detached any other wire on the ISP header.

Thanks for the explanation.  That helps.  And you are correct that it would be the encoder board powering the programmer board in once disconnected from the PC. 

Question/clarification:  When you unplug the 5V between the programmer and the decoder, you are leaving the remaining programming pins connected?  If the answer is "yes",  this is likely what is causing the encoder to stop working.  I'd have have to be able to probe the MEGA328 base encoder board (I don't have one), to know exactly what the signal states are on the LED3, LED2, and OUT2 lines to understand exactly how it is interacting with the unpowered programmer board, but my guess is that when you unplug the 5V between the programmer and the decoder, the RESET line from the programmer ends up going towards 0V and holding the MEGA328 on the encoder in reset.  

As annoying as it is, you really don't want to leave the programmer attached, powered or not, when you power up the encoder board.  Some of the lines used to program the MEGA328 are used as outputs by the encoder -- and then you have the RESET line -- and you could potentially end up with the microprocessor on the programmer trying to drive the signal and the microprocessor on the encoder also trying to drive the signal.  If they are both driving it the same direction, there isn't likely to be a problem.  If they try and drive them in opposite direction... bad things will happenTM.  Since the you can still program the MEGA328 on the encoder, it is unlikely either microprocessor is significantly damaged.

One thing you should probably do, if you haven't is verify the flash contents after you program it -- "-U flash:v:<firmware file>:i" -- just to make sure the microprocessor is actually getting programmed with the contents you expect.  Replace <firmware file> with the same filename you use in the programming command.  Assuming it verifies successfully against v1.6.5, unplug all the programmer connections from the encoder and see if it works.I have to leave for a week long trip for work tomorrow, but the above doesn't get you a working keyboard, and you can wait 10 days or so, I'll put together a simple HEX file that does nothing but blink the power LED on the keyboard, as test for programming. 

Hi, 

thank you for your suggestions. I started a new, clean programming setup. I used my notebook to install Arduino IDE with avrdude for programming and followed all steps, with known correct steps and practiced, fuse settings, etc. 

I programmed the mega328 and got the same output as for the previous try. So I'm not sharing it again, as it can be seen in the previous comments.

I also followed your advice and used "-U flash:v:<firmware file>:i" to verify the flashed content against the asdf-v1.6.5-atmega328p.hex file. And I believe we found our smoking gun: the data is corrupted and shows a mismatch. I'm pasting the output below.I believe it fails at the first byte already. Also, the are some voltages reported 0.0V

Unhooking the Encoder and keyboard from the programmer and all wires and testing them on the Apple II produces the same failed result. LED does not light up and the keyboard is dead. I ordered a bunch of mega328 chips, because I believe this one got somehow corrupted/damaged. I'll program one after I got them, probably at the end of the week. I'm also open for any other suggestions, including testing a simple hex file.Of course, I'm not in a rush or anything and I will be willing to wait and also appreciate your time.

Thanks again,

Martin 

C:\Windows\System32>"C:\Users\Shorty\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/bin/avrdude" "-CC:\Users\Shorty\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf" -v -V -patmega328p -carduino "-PCOM3" -b19200 -D "-Uflash:v:C:\Temp\asdf-v1.6.5-atmega328p.hex:i"

avrdude: Version 6.3-20190619

         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\Shorty\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf"

         Using Port                    : COM3

         Using Programmer              : arduino

         Overriding Baud Rate          : 19200

         AVR Part                      : ATmega328P

         Chip Erase delay              : 9000 us

         PAGEL                         : PD7

         BS2                           : PC2

         RESET disposition             : dedicated

         RETRY pulse                   : SCK

         serial program mode           : yes

         parallel program mode         : yes

         Timeout                       : 200

         StabDelay                     : 100

         CmdexeDelay                   : 25

         SyncLoops                     : 32

         ByteDelay                     : 0

         PollIndex                     : 3

         PollValue                     : 0x53

         Memory Detail                 :

                                  Block Poll               Page                       Polled

           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack

           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------

           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff

           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff

           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00

           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00

           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00

           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00

           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00

           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : Arduino

         Description     : Arduino

         Hardware Version: 2

         Firmware Version: 1.18

         Topcard         : Unknown

         Vtarget         : 0.0 V

         Varef           : 0.0 V

         Oscillator      : Off

         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f (probably m328p)

avrdude: safemode: lfuse reads as D2

avrdude: safemode: hfuse reads as D9

avrdude: safemode: efuse reads as FF

avrdude: verifying flash memory against C:\Temp\asdf-v1.6.5-atmega328p.hex:

avrdude: load data flash data from input file C:\Temp\asdf-v1.6.5-atmega328p.hex:

avrdude: input file C:\Temp\asdf-v1.6.5-atmega328p.hex contains 6694 bytes

avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 4.41s

avrdude: verifying ...

avrdude: verification error, first mismatch at byte 0x00ad

         0x00 != 0xc1

avrdude: verification error; content mismatch

avrdude: safemode: lfuse reads as D2

avrdude: safemode: hfuse reads as D9

avrdude: safemode: efuse reads as FF

avrdude: safemode: Fuses OK (E:FF, H:D9, L:D2)

avrdude done.  Thank you.

dfnr2 wrote:

Hi Martin,

I am just not discovering the revival of this thread.  I am glad to see you had some progress and have been toughing it out despite some setbacks.  My apologies for the bad diode on the spacebar.  That's the first time I've seen a failure of one of those diodes, and I'm not sure how that happened.  Those diodes are pretty robust to ESD, but that's still a po

Hello Dave,

thanks for jumping in! Don't worry about the diode. The fix was trivial to do.

I'm including a couple of photos of the Encoder. Of course I checked the orientaions of all chips, sockets, etc. and the cable is not-off pin. 

I'm flashing and testing with DIP SW3 down (on). If I understood your instructions correctly, this should invoke the 0010 configuration (Apple II all caps). Is this correct?

Bear in mind, the Encoder + keyboard worked the first time I flashed the mega328 (except for the spacebar) so I know the kit was assembled electrically correct. However, I have difficulties to make the programming work and there are no instructions on how to do it. Also, for some weird reason the Encoder worked only while the programmer was wired to it.

I hope we'd be able to figure all this out. Please let me know if you get any other ideas, even if they are a wild guess. I really liked the look and feel of the keyboard and want a working one. I'm very lucky that I've found out about your project.

Martin

IMG_5331.JPG

IMG_5330.JPG

Good day everyone,

I'm very happy to report that my Unified keyboard is now fully working!

It seems that I somehow damaged my first mega328 chip after several flashes, presumably due to false fuse and/or other settings.

After I got a bunch of new mega328 chips, I flashed a couple of them with the correct fuse settings and the keyboard started working right away! I believe it was also essential to test the keyboard on the Apple II without any wires hanging to the Encoder's ISP header, as suggested by @wpmcnamara. Also, with the diode replacement, the spacebar now works as expected. 

One other thing is that the DIP switches needed to be switched to the down position to be set to OFF. I found the labeling on the DIP switch housing a little confusing and needed to flip a few switches until I found out what gets the Apple II all caps keymap loaded. 

I'm really grateful for all the invaluable advice I've gotten from @wpmcnamara and @dfnr2. I'm also very grateful to Dave for this project and that he sent me this wonderful kit. I've documented the whole assembly and programming method (the way it worked for me) and can share it to anyone interested.

I'll send you a couple of photos of the computer I'm planning to use the keyboard on. You'll then understand why I was so eager to get a brand new modern Apple II keyboard :)

Martin

IMG_5499.JPG

I know I'm late to this party, but as I've been building some really stupid keyboards recently for a different platform, one of the things that simplified my designs was discovering you can buy SMD diode arrays. 

I had a design that used 46 schottky diodes (Let's just say the keyboards on the VTech Creativision used a rather "exotic" encoding technique) and was able to bring that down to only 12 diode arrays.

If you ever do a new spin, and want to simplify things, search your favourite parts supplier for "diode array" and have a look.

Cheers!

Chesh.

In post #84, 'dfnr2' wrote:

" Finally, many PCB fabs are able to assemble SMT diodes onto the boards for practically pennies, which is the easiest option." 

Uncle Bernie comments:

Who is doing SMT assembly that cheap ? Please enlighten us ! I got  quotes from U.S. based assembly houses for some of my projects and found out they take an arm and a leg. Which translates to: "Don't bother us with your small hobby production runs". I think if I'd order a few thousand of these PCBs stuffed with SMDs then they would indeed be able to to that for pennies per SMD, even here in the USA. It's done by robots anyways. But I don't have these large lots. No way.

The Chinese based PCB/assembly houses may be cheaper but then you get your dozen assembled PCBs and get blackmailed by extortionist tariffs plus "handling fees" from greedy / parasitic carriers who want to take advantage of the chaotic tariff situation - it's not the tariffs, mind you, what really hurts is the "handling fees" which may be anywhere from $80-$200 for a parcel with PCBs worth $20. The maker space web is full of such horror stories. I never experienced that myself, though, as I stopped ordering from China before the tariffs went into effect.

This said, please tell us where we can get small production runs with SMD assembly for "practically pennies" - your words !

- Uncle Bernie

(as a side note, I think that with a properly designed keyswitch matrix, no full diode matrix is needed. The diodes can only prevent "ghosting" which normally does not happen even for very fast typists, if the keyswitch matrix was optimized for preventing "ghosting". A full one-diode-per keyswitch matrix once was advertised as being "professional grade" to justify the added expense, but IMHO the designers of these keyboards did not turn on their brains. Proof of my snarky thesis on the diodes: virtually NONE of the billions of keyboards that have been made up to now had a full diode matrix. None of these "rubber mat" or "contact foil" keyboards found in typical notebooks have a diode matrix - it simply would not be possibly with this cheap keyboard technology. Far more important than a full diode matrix is proper implementation of N-Key-Rollover).

In post #86, 'dfnr2' wrote:

" From my JLCPCB order history, my last pre-tariff order of the classic/apple/osi keyboard PCBs was June 2022 ... "

Uncle Bernie comments:

Oh, I see. It was a pre-tariff order. Alas, these good times are gone now ... which sucks badly. My own "YAAK" keyboard project also is affected, as I can't order any PCBs anymore from JLCPCB, so I'm stuck as I can't try out the minor mechanical improvements I'd like to do before I release the Gerbers. So, no trial run, no Gerbers can be released. The price quoted by OSHPARK for 3 PCBs of the YAAK keyboard was $314.95 - ridicolous. JLCPCB took $6 per PCB including FEDEX shipping to the USA - this was in January 2025, before the tariffs struck.

As for the diodes, I wasn't aware that your keyboard allows reassignment of the matrix. This gets you better flexibility but also the risk of matrix layouts which are more likely to produce "ghosting", so keeping the fully equipped diode matrix is the right design decision.

In the YAAK, to stay compatible, I had to use the matrix layout found in the Apple II keyboard version with the separate 25 pin encoder card. I think that this particular matrix is quite good and I never had "ghosting" problems with it, and I'm a very fast typist. Fast enough to drive the keyboard of my Taiwanese PC-48 Apple II clone nuts ... they built the encoder with TTL ICs and an EPROM, and if I type with my regular speed it swallows keystrokes :-(

Not sure if I would want to go through the ordeal to hand solder so many small SMD diodes, and I'm not alone with this concern (see the complaints above in this thread). This is why I made that remark about the diodes. Leaded (through-hole) versions are a dying species. Just a few weeks ago I got a warning about ST stopping to make leaded 1N5711 Schottky diodes. The industry trend is clear: through-hole components go the way of the dinosaur. And our electronics hobby will get more difficult.

- Uncle Bernie

Hello guys,

as promised, I'm sharing a few pictures of the project I needed the Unified keyboard for.

It's an Apple II Europlus, made entirely of new electronic components: the mainboard, the expansion cards, the PSU and System Saver are from various sources, like Reactivemicro, and the keyboard, of course, is the Apple II version of Dave's unified keyboard.

All other parts are new old stock, in mint condition.

Thank you to everyone for the help. And especially to Dave, whose project made this possible. The new keyboard was the piece that I was missing for years.

Martin

IMG_5910.JPG

IMG_5913.JPG

IMG_5912.JPG

IMG_5911.JPG

IMG_5907.JPG