stepleton
Veteran Member
Your investigation of retrieving the non-executable ROS reminds me of my own experience with a similar effort, which I wrote about here:
You'll notice a similar table to the one you've made for the BASIC/Common ROS. I don't know why there is the repetition that we both observe, but as I say in the writeup, I feel like a clever person could work out the reason behind the behaviour.
With regard to your earlier remarks:
- Good thinking about using the composite signal from the back of the monitor. I remember now that I investigated this option, although at the time (and even today) the only capture device I had to hand is a NeXTdimension board in a NeXT computer. For some reason, photography seemed simpler.
- The "tape status" register --- per the 5100 MIM, the "tape status byte" lives in the "Common Language Control Area" (PDF p.98). Unlike the registers (which are memory-mapped to address $0000 and up), I don't think this byte is part of the hardware in the same way --- instead, my guess is that it's an ordinary memory location maintained by software that the Executable ROS loads and sets up in RWS from the non-executable ROS.
My point in saying this is that you might need this software to be running in order for that byte to be useful. What does "running" mean? Well, it could mean a couple of things. It could be that any change to the state of the tape triggers an interrupt that will cause the PALM to run that software and update the byte. Or it could be that that byte only changes if another program calls that software, as the APL interpreter would when executing the `)LIB` command, for example.
TL/DR: Don't be too disappointed if that byte doesn't change even if you manipulate signals on the I/O port. Consider using a specially-written PALM program to poll the tape hardware directly.
- I don't remember BX and can't recall what it means. It might not be in the 5100, or just as likely that I missed it. It's nice to know about the machine check jumper.
- Don't you have two 16K RWS cards? Remember the diagram you shared much earlier: each card only occupies half the slot. (It looks like the 5110 uses a single plastic bracket to hold both cards.)
Here's a little video of some of the 5100's 8K RWS cards. I made it as part of this video.
5100NonExecutableROSDecode/DATA.md at main · stepleton/5100NonExecutableROSDecode
Recover the Non-executable ROS (ROM) of an IBM 5100 from screen photographs, using image processing, machine learning, and trial-and-error. - stepleton/5100NonExecutableROSDecode
github.com
You'll notice a similar table to the one you've made for the BASIC/Common ROS. I don't know why there is the repetition that we both observe, but as I say in the writeup, I feel like a clever person could work out the reason behind the behaviour.
With regard to your earlier remarks:
- Good thinking about using the composite signal from the back of the monitor. I remember now that I investigated this option, although at the time (and even today) the only capture device I had to hand is a NeXTdimension board in a NeXT computer. For some reason, photography seemed simpler.
- The "tape status" register --- per the 5100 MIM, the "tape status byte" lives in the "Common Language Control Area" (PDF p.98). Unlike the registers (which are memory-mapped to address $0000 and up), I don't think this byte is part of the hardware in the same way --- instead, my guess is that it's an ordinary memory location maintained by software that the Executable ROS loads and sets up in RWS from the non-executable ROS.
My point in saying this is that you might need this software to be running in order for that byte to be useful. What does "running" mean? Well, it could mean a couple of things. It could be that any change to the state of the tape triggers an interrupt that will cause the PALM to run that software and update the byte. Or it could be that that byte only changes if another program calls that software, as the APL interpreter would when executing the `)LIB` command, for example.
TL/DR: Don't be too disappointed if that byte doesn't change even if you manipulate signals on the I/O port. Consider using a specially-written PALM program to poll the tape hardware directly.
- I don't remember BX and can't recall what it means. It might not be in the 5100, or just as likely that I missed it. It's nice to know about the machine check jumper.
- Don't you have two 16K RWS cards? Remember the diagram you shared much earlier: each card only occupies half the slot. (It looks like the 5110 uses a single plastic bracket to hold both cards.)
Here's a little video of some of the 5100's 8K RWS cards. I made it as part of this video.