Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse engineering the 1988 NeXT keyboard protocol

journal.spencerwnelson.com

Post reply on HN
Print view View original

51–60 of 67 posts

Re: Reverse engineering the 1988 NeXT keyboard protocol

#51

Post by marcan_42 »

spenczar5 wrote: post #47
marcan_42 wrote: post #45

> When I told my Arduino to sleep for 51 microseconds, it was generally sleeping for either 56.2 or 61.3 microseconds. That seemed to easily be bad enough to cause lots of problems. This is why I've never quite liked the Arduino ecosystem, the way it exists. Sure, it works and it's accessible to newcomers... but it doesn't encourage understanding the inner workings of the platform enough, which is something that is e…

Right, it's complicated, isn't it? Like, I couldn't (or at least wouldn't) have gotten started on this project if I had to read the ATMega reference manuals from the very first step. But I did feel very frustrated that the Arduino "delayMicroseconds" function is so far off from accurate, and I felt frustrated also whenever I looked for deeper explanations of almost anything. It's a very copy-and-paste culture. I even…

I wish the Arduino IDE actually tried to be educational instead of just being a dumbed down wrapper around avr-gcc with automatic #includes. There are so many things that could be done... stuff like showing side by side disassembly of functions, with register names displayed symbolically. Or even just basic IDE stuff, like built in contextual function documentation.

And then it should have an "export self-contained project" feature that gives you a directory containing a Makefile and all the dependencies to build your .ino, as source code form (and none of the ones you don't use), so you can easily see exactly what is getting built under the hood and can use that as a bridge to working outside the ecosystem. At the scale of 8-bit micros there's no reason not to work with copies of your dependencies, and it's very educational seeing everything in one place (and being able to hack on it) instead of having it scattered in a bunch of global package paths.

The frameworks and libraries are useful (if opaque and quirky and underdocumented), but the IDE is just so underwhelming... heck, it doesn't even manage to be a decent text editor.

Getting started with Arduino makes total sense, nobody's expecting newcomers to start off with the IC datasheet... but they should be able to eventually read the parts they need and work with it directly, instead of relying only on software abstractions. That's the beauty of these systems.

Re: Reverse engineering the 1988 NeXT keyboard protocol

#52

Post by raverbashing »

marcan_42 wrote: post #45

> When I told my Arduino to sleep for 51 microseconds, it was generally sleeping for either 56.2 or 61.3 microseconds. That seemed to easily be bad enough to cause lots of problems. This is why I've never quite liked the Arduino ecosystem, the way it exists. Sure, it works and it's accessible to newcomers... but it doesn't encourage understanding the inner workings of the platform enough, which is something that is e…

Aah trying to bitbang with a Sleep? I agree, it's a case of "get off my lawn and go back to node.js" :)

Or, more accordingly, don't think the computer is magical.

Edit: it's a bit funny seeing someone trying to discover things by themselves but saying "it's difficult to measure pulse width with an oscilloscope" just triggered me - pun intended

Re: Reverse engineering the 1988 NeXT keyboard protocol

#53

Post by marcan_42 »

raverbashing wrote: post #52
marcan_42 wrote: post #45

> When I told my Arduino to sleep for 51 microseconds, it was generally sleeping for either 56.2 or 61.3 microseconds. That seemed to easily be bad enough to cause lots of problems. This is why I've never quite liked the Arduino ecosystem, the way it exists. Sure, it works and it's accessible to newcomers... but it doesn't encourage understanding the inner workings of the platform enough, which is something that is e…

Aah trying to bitbang with a Sleep? I agree, it's a case of "get off my lawn and go back to node.js" :) Or, more accordingly, don't think the computer is magical. Edit: it's a bit funny seeing someone trying to discover things by themselves but saying "it's difficult to measure pulse width with an oscilloscope" just triggered me - pun intended

Bitbanging like this is fine for synchronous protocols... but if you're trying to work with an async one like this one, there's just no safe way to do it in C unless your have a lot of leeway in your timing. Even if you get it to work today, there's no telling how a compiler update might change the instruction generation enough to change the timing and screw it up.

I know it's cliché to tell people to go code in assembler but... this is where you do it, and why you do it. And it's easy. Seriously. These things are so simple it is not hard at all to learn how to code for them in asm. And it opens up a whole world of cool timing hacks you just can't do in C.

I haven't done much microcontroller stuff recently, but here's a thing I wrote for an ATtiny a while ago. This kind of tight timing bit banging hack is just not possible to do reliably in C.

https://github.com/marcan/sigmafix

Re: Reverse engineering the 1988 NeXT keyboard protocol

#54

Post by spenczar5 »

marcan_42 wrote: post #53
raverbashing wrote: post #52

Earlier quoted context omitted.

Aah trying to bitbang with a Sleep? I agree, it's a case of "get off my lawn and go back to node.js" :) Or, more accordingly, don't think the computer is magical. Edit: it's a bit funny seeing someone trying to discover things by themselves but saying "it's difficult to measure pulse width with an oscilloscope" just triggered me - pun intended

Bitbanging like this is fine for synchronous protocols... but if you're trying to work with an async one like this one, there's just no safe way to do it in C unless your have a lot of leeway in your timing. Even if you get it to work today, there's no telling how a compiler update might change the instruction generation enough to change the timing and screw it up. I know it's cliché to tell people to go code in asse…

I would absolutely love to write assembly for the most time-sensitive parts, while keeping C for the parts that act as a USB HID library interfacing with the host computer. It really does feel like it would be so much simpler to be able to drop down into a little assembly sequence for reading back the response from the keyboard.

But - to your point about Arduino's gaps - I have just no idea whatsoever how to build something like that. Not so much how to write the assembly - I've written a bit, and I'm sure I could work that out. No, I mean literally how I link and assemble the final program and get it to work on the chip.

I don't know whether that's just an Arduino problem, either. I find this stuff hard to google, but maybe I'm using the wrong terms - these are the perils of learning as you go.

Re: Reverse engineering the 1988 NeXT keyboard protocol

#55

Post by raverbashing »

marcan_42 wrote: post #53
raverbashing wrote: post #52

Earlier quoted context omitted.

Aah trying to bitbang with a Sleep? I agree, it's a case of "get off my lawn and go back to node.js" :) Or, more accordingly, don't think the computer is magical. Edit: it's a bit funny seeing someone trying to discover things by themselves but saying "it's difficult to measure pulse width with an oscilloscope" just triggered me - pun intended

Bitbanging like this is fine for synchronous protocols... but if you're trying to work with an async one like this one, there's just no safe way to do it in C unless your have a lot of leeway in your timing. Even if you get it to work today, there's no telling how a compiler update might change the instruction generation enough to change the timing and screw it up. I know it's cliché to tell people to go code in asse…

> Bitbanging like this is fine for synchronous protocols

Yes, it might be (easier if the timings are more flexible), but a naive sleep (that might be trying to use an internal timer) will throw you off

That's exactly my point, they would need assembler for that (or at least "predictable" C instructions)

Re: Reverse engineering the 1988 NeXT keyboard protocol

#56

Post by PostThisTooFast »

marcan_42 wrote: post #45

> When I told my Arduino to sleep for 51 microseconds, it was generally sleeping for either 56.2 or 61.3 microseconds. That seemed to easily be bad enough to cause lots of problems. This is why I've never quite liked the Arduino ecosystem, the way it exists. Sure, it works and it's accessible to newcomers... but it doesn't encourage understanding the inner workings of the platform enough, which is something that is e…

No post body was provided.

Re: Reverse engineering the 1988 NeXT keyboard protocol

#57

Post by marcan_42 »

spenczar5 wrote: post #54
marcan_42 wrote: post #53

Earlier quoted context omitted.

Bitbanging like this is fine for synchronous protocols... but if you're trying to work with an async one like this one, there's just no safe way to do it in C unless your have a lot of leeway in your timing. Even if you get it to work today, there's no telling how a compiler update might change the instruction generation enough to change the timing and screw it up. I know it's cliché to tell people to go code in asse…

I would absolutely love to write assembly for the most time-sensitive parts, while keeping C for the parts that act as a USB HID library interfacing with the host computer. It really does feel like it would be so much simpler to be able to drop down into a little assembly sequence for reading back the response from the keyboard. But - to your point about Arduino's gaps - I have just no idea whatsoever how to build so…

Heh, I wrote a USB stack for PICs in assembler way back and... yeah, I wouldn't recommend that :-) (the official stack was written in C, but I refused to use C compilers for PICs at the time because they were expensive and terrible; things got better with SDCC, but oh god C18 was bad - thankfully C works very nicely on AVRs).

But yes, mixing asm and C should be a lot easier and well documented. The repo I linked is a simple example of how to do it stand-alone, without any libs or Arduino anything, but... yeah.

This isn't exactly an Arduino problem; the "template project" issue is pretty common across the embedded industry. But for something as popular as Arduino not to have done a better job is unfortunate.

Re: Reverse engineering the 1988 NeXT keyboard protocol

#58

Post by Agentlien »

yndoendo wrote: post #17
thought_alarm wrote: post #4

I like to think that there's an alternate universe where the entire industry adopted NeXT's idea of replacing the dedicated Caps Lock key with a Command+Shift key combination, because it's such a smart and obviously correct thing to do. Sadly, I'll never live in that universe.

That world does exist with programmable keyboards. Fn + Capslock = Capslock On / Off toggle. Capslock = Esc. Makes coding in VI / VIM quicker on the touch and lighter on the fingers. Just wish laptop manufacturers would include programmable keyboards so multi-boot allows retention instead of having to run a service to override the OS input device.

On Windows I use AutoHotkey to swap Caps Lock and Escape which makes Vim much smoother. I also set it up so that it automatically disables itself whenever a remote desktop window has focus.

Re: Reverse engineering the 1988 NeXT keyboard protocol

#59

Post by dasv »

marcan_42 wrote: post #51
spenczar5 wrote: post #47

Earlier quoted context omitted.

Right, it's complicated, isn't it? Like, I couldn't (or at least wouldn't) have gotten started on this project if I had to read the ATMega reference manuals from the very first step. But I did feel very frustrated that the Arduino "delayMicroseconds" function is so far off from accurate, and I felt frustrated also whenever I looked for deeper explanations of almost anything. It's a very copy-and-paste culture. I even…

I wish the Arduino IDE actually tried to be educational instead of just being a dumbed down wrapper around avr-gcc with automatic #includes. There are so many things that could be done... stuff like showing side by side disassembly of functions, with register names displayed symbolically. Or even just basic IDE stuff, like built in contextual function documentation. And then it should have an "export self-contained p…

I have found PlatformIO to be a good step up from the Arduino IDE: it generates a new environment for each project with a sane folder structure, and it is possible to dive into the implementation of any function just with the usual Ctrl+click. It helped me a lot to understand how the Arduino libraries worked under the hood and to make changes in them when I needed it.

Re: Reverse engineering the 1988 NeXT keyboard protocol

#60

Post by unwind »

spenczar5 wrote: post #54
marcan_42 wrote: post #53

Earlier quoted context omitted.

Bitbanging like this is fine for synchronous protocols... but if you're trying to work with an async one like this one, there's just no safe way to do it in C unless your have a lot of leeway in your timing. Even if you get it to work today, there's no telling how a compiler update might change the instruction generation enough to change the timing and screw it up. I know it's cliché to tell people to go code in asse…

I would absolutely love to write assembly for the most time-sensitive parts, while keeping C for the parts that act as a USB HID library interfacing with the host computer. It really does feel like it would be so much simpler to be able to drop down into a little assembly sequence for reading back the response from the keyboard. But - to your point about Arduino's gaps - I have just no idea whatsoever how to build so…

You'll figure it out, I'm sure! You can probably continue to piggy-back on the Arduino environment by using inline assembly (the asm("") statement), but it's annoying since you need to keep the assembly in a C++ string literal.

In the meantime, please read the manual or look up some tutorials on Youtube on how to use the oscilloscope. They're complicated for sure, but I think you had a popular hobbyist model and there should be help to be found. Failing that, look for the word "cursor" on the front panel; cursors is usually how you measure things and it's like at the core of scope functionality so it should not be hard.

Post reply on HN