Live data from Hacker News

Reverse engineering the 1988 NeXT keyboard protocol

journal.spencerwnelson.com

11–20 of 67 posts

Re: Reverse engineering the 1988 NeXT keyboard protocol

#11
post #2

Had one of these with my original NeXT Cube that I bought new while in grad school. Still one of my favorite keyboards ever. And the Cube itself was so far ahead of everything else out there at the time that it felt like pure magic.

> And the Cube itself was so far ahead of everything else out there at the time that it felt like pure magic.

Ah, the good old days, when I used to argue with my buddy that my SGI Indigo was more magical than his NeXTcube. It was even more fun than the old Mac/PC arguments. The Android/iOS fights today just don't have the same lustre.

Re: Reverse engineering the 1988 NeXT keyboard protocol

#12
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.

Last time I tried a cheap ($8) saleae fx2la clone using pulseview/sigrok (open source combo for visualization, with open source fx2lafw), I didn't find a continuous option, but that might have been a GUI issue, thanks for the tip!

Re: Reverse engineering the 1988 NeXT keyboard protocol

#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 an Arduino. OpenHantek looks pretty great over in oscilloscope-land. What else is out there, and what's better or worse, or why?

Re: Reverse engineering the 1988 NeXT keyboard protocol

#14
post #7

ADB? This means I can use an old Mac keyboard on NeXT, or vice-versa?

I used to use an Apple Extended Keyboard II on my NeXTStation Turbo Color. The later NeXT models had full ADB support. The early Cubes did not.

I also sometimes used an ADB NeXT keyboard with various Macs in the 1990s.

Re: Reverse engineering the 1988 NeXT keyboard protocol

#16

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 understand it was quite popular in the MSX world.

Re: Reverse engineering the 1988 NeXT keyboard protocol

#17

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.

Re: Reverse engineering the 1988 NeXT keyboard protocol

#19
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…

Haven’t used them ever, but Red Pitaya[1] had a compelling pitch.

[1] https://redpitaya.com/

Re: Reverse engineering the 1988 NeXT keyboard protocol

#20
post #12
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.

Last time I tried a cheap ($8) saleae fx2la clone using pulseview/sigrok (open source combo for visualization, with open source fx2lafw), I didn't find a continuous option, but that might have been a GUI issue, thanks for the tip!

You can just set the sample count really high (up to 1 trillion). The samples are not compressed in RAM, so the maximal capture time is determined by the size. For 8 GiG and 24 MHz this means you can capture for ~6 minutes.

I tend to simply set the sample count higher than needed and stop the capture prematurely.

Post reply on HN