Live data from Hacker News

Reverse engineering the 1988 NeXT keyboard protocol

journal.spencerwnelson.com

41–50 of 67 posts

Re: Reverse engineering the 1988 NeXT keyboard protocol

#41

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.

But then whenever you use somebody else's keyboard you're in a different world

Re: Reverse engineering the 1988 NeXT keyboard protocol

#42

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.

I have a custom keyboard from WASD that is mostly* the NeXT layout, and I use Karabiner (macOS) to program it to behave like one. It's wonderful.

*The keyboard in the post has | in the right place but all my NeXT keyboards had it in some wackass position over the ten-key. Ridiculous.

Re: Reverse engineering the 1988 NeXT keyboard protocol

#43
>I don’t really understand all of the details, but from what I can gather, AM radios require a little clock component, and it’s desirable for this component to not be too close to any actively-used broadcast frequencies.

https://en.wikipedia.org/wiki/Intermediate_frequency#Uses

Re: Reverse engineering the 1988 NeXT keyboard protocol

#44
post #13

Nelson seems to have been using a Rigol benchtop scope and some proprietary software that came with his generic logic analyzer. But from long experience I'm wary of investing my time in proprietary vendor tools. Does anyone have a good overview of the free-software signal-analyzer-software/oscilloscope-software landscape? I've played with sigrok a little bit, enough to get it to decode some PS/2 signals I captured on…

Check out Sigrok: https://www.sigrok.org

https://sigrok.org/wiki/Kingst_LA2016 to be exact. LA1016 is supported, but LA1010 seems to be even more cut down version.

Indeed teardown reveals https://blog.lvu.kr/kingst-la1010-logic-analyzer/ is using older FPGA and no dedicated memory buffer. Compare to LA1016 https://www.cnx-software.com/2014/12/30/la1016-la2016-and-la...

> 100 m @ 3 channels, 50 m @ 6 channels, 32 m @ 9 channels, 16 m @ 16 channels

all Edit: ah, so its further optimized https://sigrok.org/wiki/KingST_KQS3506-LA16100 direct Salea logic16 clone, everything makes sense.

Re: Reverse engineering the 1988 NeXT keyboard protocol

#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 extremely valuable and accessible when you're working with simple 8-bit microcontrollers. Learning about hardware registers and clocks and cycle accuracy really isn't that scary, that's the point of using a tiny (and frankly obsolete) 8-bit platform!

But when you give people an API that takes an integer number of microseconds, and then approximates it, people are going to think they can bit bang an async serial protocol in C using it, and they will be very confused when it doesn't work (as happened here), and you end up in cargo cultish land of trying to work with bad data instead of developing an actual understanding of the hardware you're working with.

I've seen so many people thinking they need to design their bespoke board around an Arduino shield connector because the thought of just throwing on the ATMega directly scares them, even though the thing only needs 5V, GND, and crystal (if that), because what would they do outside the comfortable ecosystem? And it just makes me sad. If you're at the point you're designing your own semi complex boards and you haven't graduated from Arduino yet, you're not letting yourself grow.

(Or maybe I'm just an old millennial and I think these zoomers should be learning microcontrollers by programming in assembly like I did when I was 10 and using the PIClist delay routine generator and counting my cycles before Arduino existed, now get off my lawn? You decide :-) )

Re: Reverse engineering the 1988 NeXT keyboard protocol

#46
post #9

Earlier quoted context omitted.

Benchtop logic analyzers used to be more complicated. They are still technically superior with better probe termination, higher sample rates, and sophisticated hardware triggering.

The big down side is of course the limited sample memory. Many (especially the very popular, because cheap, fx2la) pc-based ones simply stream the data, which enables the use of all PC RAM and essentially infinite capture times.

If you have a decent oscilloscope with logic/protocol analyzer features, you can trigger the analog scope side of the tool on data. This is a very powerful debugging tool for finding the physical cause of odd data. Yes, with a pc-based tool you can capture everything to disk and go back and search, but that usually works out to be kind of clumsy.

Re: Reverse engineering the 1988 NeXT keyboard protocol

#47

> 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 eventually did find programming things more directly to be quite rewarding and worthwhile. My code is still in a ".ino" file, and uses some Arduino stuff, but it's basically built around ISRs in some frankencode middle state.

There's a lot of room for someone to create good tutorials and material for ramping up and out of Arduino. Would have helped me a lot, at least.

Re: Reverse engineering the 1988 NeXT keyboard protocol

#48
post #34

off-topic: any chhance for an RSS feed?

This is a nice suggestion, and fairly flattering. Maybe I'll get around to adding one in the next week or so. My site is put together with a weird pile of goofy Python scripts and pandoc; generating an RSS file doesn't sound too hard.

Re: Reverse engineering the 1988 NeXT keyboard protocol

#50
post #9

Earlier quoted context omitted.

The big down side is of course the limited sample memory. Many (especially the very popular, because cheap, fx2la) pc-based ones simply stream the data, which enables the use of all PC RAM and essentially infinite capture times.

If you have a decent oscilloscope with logic/protocol analyzer features, you can trigger the analog scope side of the tool on data. This is a very powerful debugging tool for finding the physical cause of odd data. Yes, with a pc-based tool you can capture everything to disk and go back and search, but that usually works out to be kind of clumsy.

Tektronix introduced some nice LA units 20+ years ago that could be configured with analog mux outputs to pass probe channels over to a scope. The instruments could be cross triggered if you wanted to but it was fun to cycle through a whole address and data bus in real time and look for SI problems.
Post reply on HN