The one being offered here is a 32K system. The 5100 had 8K RWS modules (16K per slot, up to 4 slots = 64K total).
You can also tell from the register display, where 0x00AB == 0x7FFF (the bootup ROS initializes this "end of RWS" marker, row 5 and 6 about 3/4th of the way on the right in the auction image). On the 5110, those use 16K RWS modules (32K per slot, up to 2 slots = 64K total). I'm not sure if the RWS modules are interchangeable between the two systems (I suspect not, but the PALM Controller card is).
The (BASIC) Language Support section of the 5100 MIM (6-3) indicates that the User Work Area in BASIC starts at
0x111E (4382 bytes), this is why you only see ~28K available on the BASIC screen. You get slightly more workspace in the APL mode. On the 5110, this information is in the BASIC User Guide (Storage Considerations) "In all models, approximately 4K bytes are used for system-related functions." (registers, the screen buffer 64x16 = 1K for that, IO buffer, and basically scratch areas for the emulators).
Also some other fun notes about the core PALM processor:
16-bit Address, 8-bit ALU
Registers stored in the first 128 bytes of RWS (i.e. NOT onboard the processor)
(16x 2-byte registers per 4x interrupt levels)
[this is why the 32L/32R switch is 32-- to "zoom in" on those set of 16-registers, where each of its 2 bytes is shown "vertically" when in Register mode]
Oscillator/clock = 15.1MHz, MCC (multiclock cycle) = I-phase (instruction) and E-phase (execute)
I-phase = 3x I-cycles = 3x pulses 8x pulses 3x pulses, or 14 pulses total)
E-phase = 1 to 5 E-cycles = either 3x pulses or 8x pulses (depends on instruction)
NOTE: from software, you can turn off the display to speed up processor (the display does some "cycle stealing" to stay refreshed). I believe also just using the L32 or R32 mode also speeds things up.
The 5100 also had an "Expansion Feature" in Slot B that could either be "Communication Card" or Async Comm/Serial IO. In the 5100 MIM is the following diagram: the upper rear connector port is for Serial I/O (Async Comm), and the lower rear connector is for the Communications Adapter (it wasn't quite yet called a Modem or BSCA/DDSA device yet, that terminology came with the 5110).
There is a mention in the 5100 MIM that when using the Async Comm / Serial IO, the 5100 strictly becomes a "2740 terminal only" (and neither BASIC or APL is available - I think you use the DCP to load the IMF program that uses this comm capability, so you're basically stuck in a Telix/QModem/Procom terminal-like program of some sort). I don't think you could program your own terminal from within BASIC or APL (but you could write one in machine code, which is essentially what the IMF program is).
The 5110 expanded upon the communication features by offering:
- Parallel I/O card (that offered some kind of IEEE-488 interface)
- Binary Synch. Comm. Adapter (Expansion Feature) [BSCA, 2770 or 3741 terminal]
integrated modem, Digital Data Service Adapter (DDSA), external modem (EIA RSR232C or CCITT V.24 V.28)
So, I'm not sure if it's 16-bit... The registers are somewhat artificially 16-bit, since the system just reserves 2-bytes of RWS/RAM for those registers. The addressing is still byte addressable, and the ALU is 8-bit. Again,
that's native specs of the PALM processor (which also I'm not sure if it's fair to call it 15MHz, but that is technically what the clock is at). All that is used to emulate a (sort of) 32-bit system (System/3 in the BASIC case, System/370 in the APL case). The BASIC ROS *is* System/3 machine code/opcodes, that gets interpreted and executed in terms of native PALM opcodes (similarly for the APL ROS, which on the 5100 is ~96K -- it still 16-bit addressed, but is a full "word"/32-bit per address; on the 5110 the APL ROS is ~120K, using legit System/370 machine code -- and in the Controller ROS {PALM} reverse engineered, you find code like "if this_system_370_opcode then emulate_it_like_this_using_my_PALM_instructions"). And note, this is why the performance scores of the 5100/5110 around 1980 weren't that stellar (compared to some other contemporary systems) -- because it sort of had the Java JVM effect going on, 20 years before Java was a thing -- however, it could run a lot of existing mainframe software (OR you use the device to remote-desktop into a mainframe, and run/develop your stuff there).
To me, the IBM 5100 is interesting because right at about the same time you had the Altair 8800 and the IBM 5100 -- fairly extremely opposite ends of the "first personal computer" spectrum, one being ~$500 kit and the other being a $20k dream-machine. In today's money, that $20k in 1975 is about $100k. I estimate average income in 1975 at about $15k (data entry, accountants, etc.) - so from a business perspective, the IBM 5100 just had to replace about 2 or 3 employees (which is rather heartless, but - business is business) to justify the cost -- also, as office equipment, it had a tax write-off.
The thing is, IBM kept the PALM machine code fairly "secret" about the 5100 (their internal documentation about it is marked "CONFIDENTIAL"). That's why I'm curious about why Harry Katzan epic 500+ page "5100 Portable Computer" book doesn't even mention it (no mention of DCP, PALM, System/XYZ anything) - was he too unaware of this capability (the built in machine-code entry)? It is obscure in the 5100 MIM manuals (Appendix C has the native PALM opcodes, but no examples -- and that appendix was entirely removed for the 5110 MIM, even though it's exactly the same processor. It's why I was hoping to reach Mr. Katzan, to see if he has any specific recollection (could just be a simple "not in scope of the book" reason). As for why IBM marked it CONFIDENTIAL -- maybe not just for business IP reasons, but also perhaps for international-competition reasons (cold war and all that).
On the other hand, would it have mattered? i.e. the folks who were interested and afford a cost-one-year-salary system like the IBM 5100 probably weren't interested in learning any machine code to write software. They had a business to run and wanted payroll, accounting, inventory software -- from which there was nearly a decade of mainframe software ready to "bum" from. At the opposite spectrum (before Bill's under 4K BASIC for the Altair), that base system was flipping switches and STORing machine codes one instruction at a time - but with a processor the size of your thumb and stamped out in millions (as opposed to the PALM being the size of a book, and "CONFIDENTIAL"). Then the Sol-20 showed how to really "kit-out" an Altair. What a wild time; Gates wrote his "stop stealing my BASIC" letter, while a whole generation was bumming software off mainframes to kickoff startup software contracting shops; those mostly-college-folks of the 60s that wrote all that pioneering software are unsung heroes (from compilers, assemblers, emulators, to also accounting, inventory, payroll, etc.). Of course, they in turn built upon the electronic pioneers of the 30s/40s, and the very early compilers of the 1950s...
NOTE the BASIC of the IBM 5100/5110 doesn't have a
PEEK/POKE capability (at least as far as I've been able to determine), so you can't write directly to memory (e.g. to POKE the screen memory and PEEK keyboard inputs). I'm not sure if it is a missing capability (wasn't available on the mainframes), or a not-yet-thought-of capability, but it's the prime reason someone might want to use native PALM machine code (and to interact with the IO ports at the back, to maybe do some industrial automation stuff -- which it is said PALM was used in some other such applications).
And someone asked about adding APL to a BASIC-only 5100... Hate to say a hard "no", but It's not trivial - it's not just inserting the APL ROS cards and done. Slot H has an "APL Supervisor" which is probably omitted on the BASIC-only systems. If you had a wrecked APL 5100 (like crushed keyboard, blown out CRT), but somehow all the cards were still good -- you could salvage those cards and place all those cards into a BASIC 5100 (I think the overall wiring on the A1 board is identical between them). But as someone mentioned, then the next step is some adjustment to the A1 board Z3 connector is needed to get the machine to recognize the desire to bootup in APL mode. I do think the MIM would have enough information to figure out how to do that, but it would never look "quite factory" (you could drill into the front panel and make a pretty close approximation). I don't think a change to the keyboard would be necessary - obviously the keycaps wouldn't have the APL symbols, but electrically I think you'd press keys (as marked in the MIM) and the APL symbols would show up on the screen (since you've transplanted all the APL cards over, the Display should have that font set).
Note that the APL ROS has been extracted (for both 5100 and 5110). We're still working on a viable 5100 emulator -- but there are a couple 5110 emulators (that run the actual APL ROS) that can give you a taste of APL programming without needing the actual hardware. Like maybe to compress/encrypt your private keys in some obscure APL matrix code, using an extremely obscure instruction set that just isn't cost effective to bother hacking.
