{"id":24399954,"url":"https://github.com/dirtbagxon/sunkbd","last_synced_at":"2026-06-20T18:31:30.605Z","repository":{"id":113118943,"uuid":"562162275","full_name":"DirtBagXon/sunkbd","owner":"DirtBagXon","description":"Sun Type 4 or 5 Keyboard to PS/2 via PIC16F628 (PIC)","archived":false,"fork":false,"pushed_at":"2022-11-05T14:22:59.000Z","size":5210,"stargazers_count":6,"open_issues_count":0,"forks_count":1,"subscribers_count":0,"default_branch":"main","last_synced_at":"2025-11-09T11:35:22.225Z","etag":null,"topics":["16f628a","assembly","keyboard","pic-microcontroller","pic16f628","ps2-keyboard","sparc","sun-microsystems","sunkbd","type4","type5"],"latest_commit_sha":null,"homepage":"","language":"Assembly","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/DirtBagXon.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-11-05T13:57:39.000Z","updated_at":"2025-10-28T17:12:46.000Z","dependencies_parsed_at":null,"dependency_job_id":"0bc45044-7466-4655-8a69-847f33de1bb2","html_url":"https://github.com/DirtBagXon/sunkbd","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/DirtBagXon/sunkbd","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DirtBagXon%2Fsunkbd","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DirtBagXon%2Fsunkbd/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DirtBagXon%2Fsunkbd/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DirtBagXon%2Fsunkbd/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/DirtBagXon","download_url":"https://codeload.github.com/DirtBagXon/sunkbd/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DirtBagXon%2Fsunkbd/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34581934,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-20T02:00:06.407Z","response_time":98,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["16f628a","assembly","keyboard","pic-microcontroller","pic16f628","ps2-keyboard","sparc","sun-microsystems","sunkbd","type4","type5"],"created_at":"2025-01-19T23:55:44.811Z","updated_at":"2026-06-20T18:31:30.600Z","avatar_url":"https://github.com/DirtBagXon.png","language":"Assembly","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Sun Type 5 to PS/2 : PIC-based converter\n\nAn archive of the project by [Alexander Zangerl](https://snafu.priv.at/mystuff/sunkbd.html).\n\nEver since I stopped using a Sun SparcStation as desktop _(around 94 or so)_ I wanted a decent Type 4 or 5 on my pc - alas, the Type 4/5 are serial keyboards and hence not directly supported by normal PC's.\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/sun5c.jpg\" width=200\u003e\u0026nbsp;\u003cimg src=\"images/projectbox.png\" width=200\u003e\n\u003c/p\u003e\n\n## Sun Type 5c goodness\nGetting the Type 5 to work under Linux wouldn't have been too hard _(it's serial after all)_, but that isn't good enough: I wanted a decent solution that also work for BIOS interaction and in Windows _(and even the Linux-only solution would have required soldering up a TTL inverter)_. So why not build a converter?\n\nBeing lazy until recently I compromised _(sort-of)_ by using an [IBM Model M](http://en.wikipedia.org/wiki/Model_M): my Model M was made in 84, weighs a ton and a half, and works beautifully...but it's very very noisy _(a consequence of the buckling spring mechanism)_ and that finally got on my nerves. About eight or nine years ago I saw this Sun to PS/2 [converter project](http://www.buzzard.me.uk/jonathan/sunkbd.html), which unfortunately is rather complex to build and uses very obsolete hardware to pull it off...too much of a hassle. And the few commercial converters that I could find were ridiculously expensive. So finally I built my own converter which needs only two active and one passive component: one PIC16F628a microprocessor to do the heavy lifting, one 7404 TTL inverter and one capacitor. Together with a bit of prototyping board, a PS/2 cable with plug and a female minidin-8 socket I estimate the total cost to be no higher than AUD15. Mine actually cost less: I bought some 16F628s in bulk some time ago, the 7404 was an ancient left-over _(markings indicate it was made in the 80s...)_, the PS/2 cable and plug came from a dead donor keyboard and the minidin-8 socket I recycled out of a dead Sun. And what about the software? That's my contribution. _(Open Source, of course.)_\n\nMore recently, after having decided to build my own PS/2-based converter I found out that [Marijn Kentie](http://kentie.net/article/sunkbd/) has created a PIC-based one that does Sun-Type-4/5-to-USB, with a PIC18F. Silly hat on. But his is written in C and therefore less cool than my handcrafted PIC assembler code. Silly hat off\n\n### Preliminaries: Sun\nThe Type 4 and 5 Sun keyboards are very simple beasts explained nicely in the [SPARC Keyboard Specs](datasheet/KBD.pdf): they communicate with the host using RS-232 at 1200 bps, 8N1 - but with inverted TTL logic levels _(0V = 1, 5V = 0)_. +5V power is provided together with the signal. All keys have a one-byte code that is sent on \"make\" _(key pressed)_ and code+0x80 is sent on \"break\" _(key release)_. No typematic repeat, that is handled by the host. The keyboard has a few more keys than normal pc keyboards, and one more LED, on the compose key. The keyboard also has only a few trivially simple commands _(reset, led setting, beeper on/off and click on/off)_. The pinout of the minidin-8 connector is straightforward. And that's all there is to it. Neat, simple, efficient. Dealing with this stuff on a PIC is easy, especially when you use one with USART built-in, like the 16F628 - the only necessary extra is a 7404 inverter to translate the signal levels.\n\n### Preliminaries: PS/2\nThe electrical PS/2 protocol is ugly, to put it politely. The PS/2 keyboard protocol is fucking horrible, and that's still putting it politely! The electrical part is described very well by [Adam Chapweske](datasheet/PS2_Keyboard.pdf). It's a two-wire bidirectional protocol, with a \"master\" _(the host)_ that isn't mastering anything but the art of interrupting progress at any time it feels like it: the only thing the master ever does is tell the slave to stop whatever it's doing or to start clocking. With PS/2 it's the slave that outputs the clock pulses. Device-to-host transmissions work different from host-to-device, adding to the fun for an implementor. At least all transmissions are done in bytes. Some of the borderline cases I didn't find any precise information on _(e.g. the timing sequence of the host-to-device clocking request; the best I could find is 'host pulls clock low, then pulls data low, then releases clock')_, but there seems to be a lot of leeway in the spec _(e.g. pulse length can be anything between 25us and 50us)_. And the electrical part is easy, compared to the backwards-compatible mess that the PS/2 keyboard protocol is: most of the crappy stuff dates back to 84-key PC/XT keyboards and contains lots of really lousy design decisions made by IBM.\n\n    IBM: It may be slow, but it's hard to use. -- Simon Cozens\n\nThe best explanation/material collection for the scan codes I found to be the one collected by [John Savard](datasheet/ScanCodesDemystified.pdf). In as few words as possible: keys send make and break codes _(\"scan codes\" in PS/2 parlance)_, just like the Sun does - but the codes follow no useful scheme whatsoever and differ in size: anywhere from 1 to 8 bytes. One key sends no break code at all, and in theory there's three different set of codes for any single key _(fortunately only Set 2 is required nowadays)_. And to make all this even more fun, the typematic repeat must be handled by the device, there's multiple repeat/delay rates as well, and there's a bunch of generally superfluous commands that a keyboard should understand as well. Lots of joy! My students got a really good laugh out of it when I told them last week that I write code in assembler for fun _(and indeed, the PS/2 part of this project was \"lots\" of fun, for masochistic values of lots)_.\n\n## My Converter\nThe PIC deals with the Sun using its built-in USART, with the 7404 inverter sitting inbetween. The PS/2 side is done \"manually\", bit-banging two ports of the PIC whose internal pullup resistors are enabled. The mechanical layout of my converter is trivial: a small piece of prototyping board holds two sockets for the PIC and the 7404, and one 22uF electrolytic capacitor sits near the PIC. One end of the board holds a female minidin-8 socket for the Sun keyboard plug, and the PS/2 cable was soldered in at the other end. Power comes from the PS/2 connector, and powers everything: the PIC, the 7404 and the Sun keyboard. Here is my prototype _(with extra in-circuit programming sockets)_:\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/prototype1.jpg\" width=200\u003e\u0026nbsp;\u003cimg src=\"images/prototype2.jpg\" width=200\u003e\n\u003c/p\u003e\n\nThe electrical setup is about as trivial, and shown on this schema.\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/schematic.png\" width=200\u003e\n\u003c/p\u003e\n\nI've even cooked up a small PCB design _(untested, though)_. These PNGs are 300dpi and if you use this for a toner transfer you'll have to mirror the silk side but not the solder side.\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/sunkbd-silk.png\" width=200\u003e\u0026nbsp;\u003cimg src=\"images/sunkbd-solder.png\" width=200\u003e\n\u003c/p\u003e\n\nThe pinouts for the female sockets, looking at the socket face:\n\n\u003cp align=\"center\"\u003e\n\u003cimg src=\"images/minidin6.png\" width=140\u003e\u0026nbsp;\u003cimg src=\"images/minidin8a.png\" width=140\u003e\n\u003c/p\u003e\n\nThe design also successfully works behind a _PS/2 to USB_ converter.\n \n### Limitations\n- My converter presents a somewhat dumb keyboard to the host: any and all PS/2 commands are acknowledged _(in best \"yes, minister!\" tradition)_ - and most are then completely ignored. Implemented are: Reset, Get ID and Set LEDs. The keyboard also doesn't request resends from the host, nor does it act upon the hosts' resend requests - I haven't seen any need for those in practice.\n\nApparently all modern keyboard controllers _(8042-clones embedded in the SuperIO chips)_ don't care about the extra commands and don't even pass them on to the keyboards.\n\n- The repeat rate is fixed at 250ms initial delay, then 30 keys per second.\n\n- The Compose LED on the Sun keyboard isn't known to PS/2, and the converter arbitarily associates it with bit 3 of the Set LEDs argument _(bits 0 to 2 are num, caps and scroll lock)_. If you can convince your OS/hardware to pass the extra bit then your compose LED will be controllable; otherwise it'll stay off.\n\n- The keyboard's buzzer or the key click functions are not accessible via PS/2, so those are off.\n\n- The handling of the Print Screen key is simplified: while the standards say that it should be wrapped in the scancodes for shift _(plus an extra annoyance byte)_, the converter doesn't do that. Neither does it create the sysreq scan code with alt held down.\n\nI have found that all OS's I tried _(linux and win)_ work fine with that - it looks like the keyboard controller fixes up the scancode as required.\n\n- Similarly, the numlock handling is simplified: According to this [MS keyboard scan code specification](datasheet/ms-scancode.pdf), a keyboard should remember all modifiers held down while numlock is in use and modify the scancodes sent accordingly. This is a ridiculously crappy setup _(what do we have the damn make/break codes for, except for the host to figure out which keys are currently down?)_ and it's also not necessary in practice.\n\n- The extra keys on the Sun keyboard were mapped to the nearest equivalents I could find in various sources.\n\nThe power key is mapped to ACPI Power, the brightness/volume and mute keys are mapped to the Windows Multimedia Keyboard scancodes and so is the Stop key.\n\nThe left and right Meta keys _(Diamond on the Sun keyboard)_ are mapped to Left and Right Window key, respectively. The Compose key is mapped to the Windows Menu key.\n\nFor the non-obvious ones _(Help, Undo/Again, Copy/Paste/Cut, Props, Front, Open, Find)_ I used scan codes from Savard's list.\n\nOn Unix systems the mapping of these is trivial _(Linux: setkeycodes for a few, then Xmodmap to make them available under X)_. on Windows systems you'll have to use a remapper tool or frob the registry by hand. I've tried [SharpKeys](http://www.randyrants.com/2006/04/sharpkeys_21.html) which works fine for the remapping, and [Hoekeys](http://www.bcheck.net/apps/hoe.htm) for attaching actions to keys.\n\n## Code! Code! Code!\nThe code is as simple and robust as I could make it, and pretty well documented - I think. The keycode to scancode translation is done with two tables, one 128 byte one _(for the one-byte scancodes)_ and one 27 byte one _(for the two byte scancodes)_. The Pause key is handled separately. As the 16F628 has only 128 byte of EEPROM the two tables are done using the trusty old computed-goto method. Sun input is handled via an interrupt handler which pushes key codes into a small _(8 byte)_ inbound fifo. The main loop monitors the PS/2 bus for activity _(remember, the PIC has to clock for the host on request)_ and otherwise processes key codes from the input fifo: it translates them into scan codes and pushes those into an output fifo _(16 bytes deep)_. The main loop also empties that fifo by sending out pending scancodes whenever the PS/2 bus allows it, and furthermore deals with the few PS/2 commands that are implemented. Sending to the Sun keyboard is done via the USART, and due to the PIC hardware that's a fire-and-forget operation _(for up to two sequential bytes)_. Another part of the interrupt handler deals with timeouts: a timer is armed whenever a make code is processed _(and disarmed on break)_ and when the timer expires the interrupt handler inserts another copy of the held-down key code into the inbound fifo and rearms the timer _(initial 250ms, then 33ms)_. And that's about it.\n\nFor those of you who like to tinker with the source: go for it! It is, as usual, [GPL-licensed](http://en.wikipedia.org/wiki/GPL) and as such freely available for your use. Here is the list of files:\n\n- The main program code: [sunkbd.asm](code/sunkbd.asm)\n- The fifo helper routines: [fifo.inc](code/fifo.inc)  \n- Some delay helper routines: [delay.inc](code/delay.inc)  \n- For convenience here's the compiled code, ready for your PIC: [sunkbd.hex](code/sunkbd.hex)\n- Datasheet for the [PIC16F62x](datasheet/PIC16F62x.pdf)\n\n\u0026copy; [Alexander Zangerl](https://snafu.priv.at/about/me/99contact.html)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdirtbagxon%2Fsunkbd","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdirtbagxon%2Fsunkbd","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdirtbagxon%2Fsunkbd/lists"}