There's a rumor that there's something embedded in the IBM 5100 which makes it useful for codebreaking.
What is the legitimacy of that claim?
Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this communityThere's a rumor that there's something embedded in the IBM 5100 which makes it useful for codebreaking.
What is the legitimacy of that claim?
The 5100 had programmable microcode which could be used to implement crypto-specific opcodes1,2,3. Then there's the whole John Titor4,5 thing...
1 Such as population count
2 I'm unaware of anyone actually having done so.
3 Certain agencies are very interested in such things though.
4 Perhaps it wasn't code-breaking in the traditional sense. If you have software with extra opcodes along with the corresponding microcode for the added instructions (but no description of the CPU's wiring or non-custom microcode) it is conceivable that you would need original 5100 hardware to determine how it would run.
5 No, I don't think he's for real.
I think the original argument (both in the John Titor hoax and in Steins;Gate) goes like this:
The IBM 5100 can emulate the IBM mainframe ISA (that's true, and that's how the APL running on the IBM 5100 was implemented: They took the mainframe APL implementation, because they didn't have enough time to develop a native APL. That also makes it slow...), and therefore the IBM 5100 can help to break some other unspecified programs that were written for the IBM mainframes.
While that in principle is also true, it's also not particularly clever: An emulator for IBM mainframes can also be written for any other available computer, see e.g. the Hercules emulator.
In the Anime series, one of the characters then goes on to use the IBM 5100 to break into CERN's computers (CERN, or "SERN" in Japanese spelling, gets assigned the role of the evil enemy for some reason). So I guess that could be another source for the "codebreaking" meme. But that's of course entirely unfounded.
I've never heard the argument that the IBM 5100 microcode could be used to implement cryptographic primitives in that connection (though this is also true).
Details on how the IBM 5100 emulated the IBM mainframe ISA can be found in this listing of the "APL executable ROS".
One should also note that the "Microcode" is a 16-bit ISA with 16 registers, not that different from a modern microcontroller ISA, and not at all like the "microcode" on other CPUs with a large numbers of bits used to control the various elements of the CPU.
The original John Titor passage on why he needs an IBM 5100:
I was "sent" to get an IBM computer system called the 5100. It was one the first portable computers made and it has the ability to read the older IBM programming langages in addition to APL and Basic. We need they system to "debug" various lagacy computer programs in 2036. UNIX has a problem in 2038.
I have an IBM 5100. There were some versions with APL-only and some versions with BASIC-only, while also yet another version that did have "the switch" as mentioned to toggle between either language (during startup, not during runtime) - I don't know how many of each version were sold, but we've seen them, and the IBM manual list part numbers for each variation. My daughter made me watch that anime series - as I recall, the story didn't explicitly mention needing APL or BASIC (it mentions the capability, but it doesn't mention either of those as being the essential aspect of the system for that story). The IBM 5100 has a native instruction set called PALM, which consists of about 45 opcodes (these are described in Appendix C of the original IBM 5100 MIM (Maintenance Information Manual, but there is an internal IBM document marked confidential that elaborates on these opcodes and gives examples of using them). The Executive ROS of the IBM 5100 uses PALM and coordinates the execution of either the BASIC ROS or APL ROS (as selected). This is slow because, yes, it is an emulation of those older IBM systems - but it is also slow because you effectively have a 16-bit system emulating a 32-bit system (the set of 45 opcodes primarily only operates on the low-order bytes, so lots of extra shifting is needed). If you ignore the BASIC and APL stuff, the native PALM is actually decent performance on its own (but curious that IBM didn't allow more public disclosure about PALM; for example, nothing about the DSP or PALM are mentioned in HarryK's extensive IBM 5100 book). What I think most people miss here is that the IBM 5100 has another special feature, which in the MIM is described as "expansion feature" that goes into slot B of the A1 mainboard. MIM 2-51 notes this as a "communication adapter". In the expansion area at the back of the IBM 5100, there was a slot for up to two options: a typical asynchronous serial IO, and then a nebulous "communication" option. Recall IBM systems were big into running the stock market and systems that interconnected the World Banks. But it's possible this "expansion feature" wasn't a comm device at all, and was a special decrypt hardware (that only PALM instructions could execute). OR, it was a special government communication device, with protocols that maybe allowed access to special (launch) codes. Also to note, the only "problem with unix" in the future might possibly be the use of 32-bit System Time (number of seconds since 1970). But, 4.2 billion seconds is 136 years (assumed unsigned, but nobody would use a signed value for a counter, right? otherwise Y2038 is looking bad rather than Y2106). Anyhow, no, there isn't anything inherent to the IBM 5100 itself - but the rather undocumented "expansion feature" for Slot B is mysterious.
Apologies, this didn't occur to me in my earlier Reply: There is also one other special feature of the IBM 5100. A long time ago with typewriters, you could backspace, and "overstruck" a new character on top of the already stamped character. Like to make a classic "cent" symbol, you could type "c" then backspace and type "1" to put a line through the c. Also some original typewriters didn't have the number "0" because you could just type "O" (it was just ink, not data, on those days). Anyway, the IBM 5100 uses this concept in a clever way, you can "overstruck" certain key combinations and get a different symbol (and thus scancode) for that symbol (this is also true on BASIC-only models, since it still has the APL characters in the video ROM all the same). The most common example is notice that the IBM5100 has no key for "!", a very common symbol. That's because as a scientific machine (not a dumb word processor), "!" obviously means Factorial (not exclamation), so that symbol is entered using an overstruck sequence of ' (apostrophe) followed by left arrow (to move back over the '), then type . (period), then immediately on the display the symbol becomes "!". Note, while not mentioned in the manual, I learned you can type these overstruck sequences in either order (try SHIFT+G, left arrow, SHIFT+T for a NOR symbol). And the list of overstruck symbols is apparently only in the APL manual (Appendix B), but again it works equally on the BASIC-only models or in BASIC-mode (you can try it on the IBM 5110 online emulator as well). The concept is like how Asian languages are typed on English keyboards today - you have to type a combination of 2-4 characters in order to make the one intended symbol, but software monitors for this and adapts on the fly (perhaps another reason why the 5100's were relatively slow). But as mentioned, these symbols just translate to scancodes that are a bit sequences, so it shouldn't be as thought of a code-breaking capability of the 5100 - except, of course, there are undocumented overstruck keys that maybe do who-knows-what! ;) OR if you didn't know the scancode values (EMP wiped digital records), but had a photograph image of a password expressed only in APL symbols, then yeah, having a 5100 with a working keyboard might be the only way to decypher that (if you knew that SERN only accepted IBM5100 scan codes -- which, BTW, the scancodes used on the 5100 are different than what is used on the 5110 -- they use different character codes for the CRT as well).