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

Reply via email to