Thanks for sharing your notes. I didn't realise that the 5110 had IEEE 488 support.
You are correct to guess that the "Controller" card in the 5110 is the processor, or at least a major part of it. Some things we might think of as part of the CPU might also be on other cards --- perhaps "Base I/O" contains some circuitry that helps implement the I/O instructions. But I don't know for certain.
Tapes
You are correct that the tape drive is not like a cassette-tape deck (although
SCAMP, the experimental machine that lead to the 5100 series, did use an ordinary tape recorder.) The tapes are cartridges about the size of three decks of cards laid side-by-side. The tape mechanism can and does go back and forth over the tape as it reads and writes. Here is a video of the tape mechanism in my 5100 at work loading an
APL workspace:
photos.app.goo.gl
(The loud fan noise is from the apparatus I use to convert power from 50 Hz 230 VAC to 60 Hz 120 VAC; my thumb is on the tape because the cartridge positioning/guide rollers inside the tape drive need servicing, and until they get it I need to hold the tape against the heads and capstan manually.)
Most systems that used tapes like this would have you "partition" (not the word they used) the tape into a series of "chunks" (also not the word they used), a bit like chapters in a book. In some cases you would read the entire chunk into memory, do some work, and then write the whole chunk back onto tape. (This is how APL workspaces worked.) In other cases you would read and write smaller records within a chunk. When you're loading a whole chunk, you usually just say which one you want to load: the computer then figures out where it is on the tape, rewinds or advances the tape to the chunk, then loads it.
You can find out more about tape usage in BASIC and APL by reading the IBM 5100 and 5110 manuals for both languages.
Disk drives for the 5100
With PALM assembly speaking to the I/O interface port on the back of the IBM 5100, you can talk to whatever you want so long as you have sorted out the hardware interfacing
. Floppy drive, flash drive, ethernet, why not.
I don't think IBM ever supported disk drives for the 5100, although some of its designers wanted to do it --- there just wasn't enough time to get it ready by the ship date. There was a third-party option by a company called Sykes Datatronics Inc., and you can find a brochure about it on bitsavers:
http://www.bitsavers.org/pdf/sykes/brochures/Sykes_Comm-Stor_5100_Brochure.pdf . It looks like this was a device that simply attaches to the
optional serial I/O adapter on equipped 5100s (not the Y-shaped connector), so I guess you could probably have used it with other machines that had a serial port. Regrettably my 5100 doesn't have the serial adapter fitted; I wish it did!
Miscellaneous
BSCA: Not a 5100 thing, so I don't know about it
I think you're correct that many of the questions you have about the communications options will be in the IBM manuals. I don't think any of the 5100-series speaks ASCII "natively" (i.e. without translator software or hardware); the 5110 might do an EBCDIC of some kind, but I think the 5100 has an internal character map that's proprietary to itself. Also, apparently a Katakana option was available for the 5100, although I've never seen it anywhere except the manuals.
Tape drive emulator for the I/O port connector: it does sound like the most useful option for all 5100-series users. Please go for it! You can count on having at least one customer...
What's wrong with your 5110's display? It looks to me like at one point the scan circuitry in your 5110's display failed, meaning that all of the video was collapsed into one very bright dot in the centre of your CRT. It doesn't take long for that to leave a permanent mark. If this happened, someone repaired the circuitry later, but by then the phosphor damage was done.
Send the non-executable ROS out of the I/O port? I think this is a great idea, and in fact I'd hoped to do it that way on my 5100. But my limited experiments to wiggle bits on the I/O connector were unsuccessful, and at the time I didn't have my assembler, so writing hex code was tedious (and typing it in was tedious too). I don't think I have the patience for this that you have! So instead I did an elaborate neural network approach. This was more fun than practical.