19 Sep
2025
19 Sep
'25
2:07 p.m.
I've been digging through CHM and bitsavers and haven't found an IMF for
5100 or 5110 yet. It seems a lot of CE material was just not saved.
However, I've been tracing execution of ExecROS and the APL ROS - thanks
to your excellent emulator and the extracted ROS files this works well.
Have learned a few things about the jump tables, I'd imagine that the
type 23 files would likely install themselves in high memory and modify
an IOCB jump entry to point to the new/patch code. Kind of like how you
take over the printer IOCB.
One little issue I found with your emulator is behavior of interrupts
while in HOLD.
Per the APL and BASIC manuals, pressing HOLD while a program is running
should pause the output (mostly so you can read the screen before output
scrolls up), and then pressing HOLD again is supposed to continue execution.
In emu5110 that didn't work, pressing HOLD always stopped but a 2nd
press wanders off in to never land (hang or bogus error or junk on screen).
While tracing & learning I noticed that if code was being executed from
one of the language ROS, HOLD would fail. But HOLD/resume worked fine
on an idle machine - idle is a short loop that just blinks the _ cursor
at location 0x0200+902 in APL.
So looking through the pseudo-schematics/block diagrams in SY31-0552-3
IBM 5110 System Logic there is quite a bit of gate logic on the multiple
ROS cards, plenty of wires between them. Maybe, hardware interrupts are
held off in hardware when we are doing reads from the language ROS
cards. The interrupt bits are properly shown in a register, but nothing
detailing gating of interrupt -> CPU.
To test the idea I made this change in emu.c:
175c175,176
< check_int(); /* check for pending interrupts */
---
if(curr_ros==ExecROS) /* if in ExecROS we can
HOLD/resume */
check_int(); /* check for pending interrupts
*/
and now HOLD works as expected.
Norbert's JavaScript port had the same issue with HOLD, he ported the
above and confirmed that the HOLD now works properly.
As a side note, the MAME emulation (which may have been done
independently) has the same problem, likely could use the same fix.
Anyone know how to contact the MAME author?
There was a lot of interest in the CHM release of APL\360 source along
with auto-operator and I've tried contact a few of those folks, we just
need one CE or user who kept a box of floppies.
-Robert
20 Sep
20 Sep
1:21 p.m.
New subject: IBM 5110 IMFs
The 5100 is the unicorn of IBM systems. It was 2001 space odyssey special.
On Sat, Sep 20, 2025 at 5:41 AM Robert Marinelli via cctalk <
cctalk(a)classiccmp.org> wrote:
I've been digging through CHM and bitsavers and
haven't found an IMF for
5100 or 5110 yet. It seems a lot of CE material was just not saved.
However, I've been tracing execution of ExecROS and the APL ROS - thanks
to your excellent emulator and the extracted ROS files this works well.
Have learned a few things about the jump tables, I'd imagine that the
type 23 files would likely install themselves in high memory and modify
an IOCB jump entry to point to the new/patch code. Kind of like how you
take over the printer IOCB.
One little issue I found with your emulator is behavior of interrupts
while in HOLD.
Per the APL and BASIC manuals, pressing HOLD while a program is running
should pause the output (mostly so you can read the screen before output
scrolls up), and then pressing HOLD again is supposed to continue
execution.
In emu5110 that didn't work, pressing HOLD always stopped but a 2nd
press wanders off in to never land (hang or bogus error or junk on screen).
While tracing & learning I noticed that if code was being executed from
one of the language ROS, HOLD would fail. But HOLD/resume worked fine
on an idle machine - idle is a short loop that just blinks the _ cursor
at location 0x0200+902 in APL.
So looking through the pseudo-schematics/block diagrams in SY31-0552-3
IBM 5110 System Logic there is quite a bit of gate logic on the multiple
ROS cards, plenty of wires between them. Maybe, hardware interrupts are
held off in hardware when we are doing reads from the language ROS
cards. The interrupt bits are properly shown in a register, but nothing
detailing gating of interrupt -> CPU.
To test the idea I made this change in emu.c:
175c175,176
< check_int(); /* check for pending interrupts */
---
if(curr_ros==ExecROS) /* if in ExecROS we can
HOLD/resume */
check_int(); /* check for pending
interrupts */
and now HOLD works as expected.
Norbert's JavaScript port had the same issue with HOLD, he ported the
above and confirmed that the HOLD now works properly.
As a side note, the MAME emulation (which may have been done
independently) has the same problem, likely could use the same fix.
Anyone know how to contact the MAME author?
There was a lot of interest in the CHM release of APL\360 source along
with auto-operator and I've tried contact a few of those folks, we just
need one CE or user who kept a box of floppies.
-Robert
10:38 a.m.
New subject: IBM 5110 IMFs
> The 5100 is the unicorn of IBM systems. It was
2001 space odyssey special.
On Mon, 22 Sep 2025, Christian Corti via cctalk wrote:
And this means what? Is that related to interrupts?
(wondering and scratching my head...)
Perhaps John Titor might know?
3:55 a.m.
New subject: IBM 5110 IMFs
On Fri, 19 Sep 2025, Robert Marinelli wrote:
So looking through the pseudo-schematics/block
diagrams in SY31-0552-3 IBM
5110 System Logic there is quite a bit of gate logic on the multiple ROS
cards, plenty of wires between them. Maybe, hardware interrupts are held off
in hardware when we are doing reads from the language ROS cards. The
interrupt bits are properly shown in a register, but nothing detailing gating
of interrupt -> CPU.
Hm, this is a very good point! Actually, thinking about it, the system
ISRs are located in the ExecROS (e.g. keyboard ISR), so you may be correct
about "ANDing" the interrupt line with the ExecROS select line, *if* the
interrupt mode bit for that level (i.e. 0-3) says that the ISR is in a
ROS. On the other hand, you can have an ISR in RWS, so that could be
called anytime.
To test the idea I made this change in emu.c:
175c175,176
< check_int(); /* check for pending interrupts */
---
This may break an ISR in RWS, but I haven't tested this with your
modification.
Christian
if(curr_ros==ExecROS) /* if in ExecROS we can
HOLD/resume */
> check_int(); /* check for pending interrupts */
8:47 a.m.
New subject: IBM 5110 IMFs
Yes, that is a very good point. With long running APL and BASIC code,
execution traces show instructions from an executable language ROS,
interleaved with ExecROS. I have the impression that they system was
designed so all language ROS paths "come up for air" in ExecROS
periodically.
But I agree that there are cases such as tape or disk that could need to
avoid holding off interrupts. Could be that just holding off level 3 is
enough.
Before gating the interrupt I would watch traces where the first HOLD
went through your (nicely annotated) ExecROS code and correctly got to
the HALT. But if the code had not been running from ExecROS, a
subsequent HOLD intended to resume execution instead wandered around
executing until it hit a 0x000 and halted.
There were many visible symptoms such as random bits of unrelated error
messages or parts of the screen changing, all making me feel that the
instruction counter was in the wrong bank and basically just lost.
Since adding if(curr_ros==ExecROS) that's resolved.
Robert
On 9/22/25 1:55 AM, Christian Corti via cctalk wrote:
On Fri, 19 Sep 2025, Robert Marinelli wrote:
So looking through the pseudo-schematics/block
diagrams in
SY31-0552-3 IBM 5110 System Logic there is quite a bit of gate logic
on the multiple ROS cards, plenty of wires between them. Maybe,
hardware interrupts are held off in hardware when we are doing reads
from the language ROS cards. The interrupt bits are properly shown
in a register, but nothing detailing gating of interrupt -> CPU.
Hm, this is a very good point! Actually, thinking about it, the system
ISRs are located in the ExecROS (e.g. keyboard ISR), so you may be
correct about "ANDing" the interrupt line with the ExecROS select
line, *if* the interrupt mode bit for that level (i.e. 0-3) says that
the ISR is in a ROS. On the other hand, you can have an ISR in RWS, so
that could be called anytime.
To test the idea I made this change in emu.c:
175c175,176
< check_int(); /* check for pending interrupts */
---
This may break an ISR in RWS, but I haven't tested this with your
modification.
Christian if(curr_ros==ExecROS) /* if in ExecROS we can
HOLD/resume */
> check_int(); /* check for pending interrupts */
33
days inactive
36
days old
5 comments
4 participants
participants (4)
-
Christian Corti -
Fred Cisin -
Jim Davis -
Robert Marinelli