LisaList2

Solved — (I think )

it was both documented causes at once, and Workshop 3.0 behaves differently from 1.0.

I wrote a probe that runs every required DEVICE_CONTROL group with its own ecode printed, then OPEN, then MOUNT, then OPEN again. Before the fix, every DEVICE_CONTROL group returned 1101 (Invalid device name), MOUNT returned 1051 (No device or volume by that name), and OPEN returned 946 both times — three different File System calls all saying the same thing: the OS had no device called RS232B at all.

The fix came in two layers:

   1.   Configuration list. The manual states a device can be accessed only if it's "specified in the configuration list created by the Preferences tool," physically connected, and mounted. This volume had the Office System on it, so I booted the desktop and set Preferences → Connect Devices → Serial B Connector to Serial Cable. That's per-volume and persists. Back in the Workshop, every DEVICE_CONTROL group now returned 0, and the readback confirmed 9600 baud had taken.

   2.   MOUNT. OPEN still returned 946 after successful configuration. But MOUNT then returned 0, and OPEN after MOUNT returned 0 — port open, refnum issued, clean close. So on Workshop 3.0 the serial ports are not mounted at boot; the program has to MOUNT them. This explains the LisaBBS discrepancy: it never calls MOUNT and worked on Workshop 1.0, so 1.0 evidently mounted the ports itself. 3.0 doesn't.

Recipe for anyone hitting this on Workshop 3.0: assign the port in Preferences once (needs an Office System install on the same volume), then in your program MOUNT the port each session before configuring and opening it. PORTCONFIG's "Invalid device name" is just ecode 1101 passed through — if you see it on every group, the port isn't in the configuration list.

One open question: whether a Workshop-only volume (no Office System installed, so no way to run Preferences) can be fixed at all without one?

PORTCONFIG: "Invalid device name" on both RS-232 ports, three Workshop volumes, two machines

I'm trying to open a serial port from a Workshop Pascal program and can't get past device configuration. PORTCONFIG fails on every DEVICE_CONTROL group with "Invalid device name" — parity, output handshake, baud, input waiting, type-ahead, disconnect detection, output timeout, automatic linefeed. All of them, in order, every time.

What I've ruled out:

   •   Both ports. RS-232 A and RS-232 B fail identically. The port letter is accepted at the prompt — anything other than A or B is rejected — so PORTCONFIG believes it has a valid selection before it starts.

   •   Both machines. Lisa FPGA and a real 2/10. Identical output on both.

   •   Three volumes. Alex's LOS Compilation Base (94,170 blocks), a Workshop 3.0 + LOS 3.1 volume (19,418 blocks), and one other.

   •   The driver table. I extracted system.cdd from two of the failing volumes and diffed them on a PC — byte-identical, 1536 bytes. Both contain the expected bindings including Serial Cable → lisaserial and Modem A → LISASERIAL.

   •   The hardware. The same FPGA runs Serial B fine under the Office System from a LOS 3 volume, 9600 8N1 through LisaTerminal — but only after assigning a device in Preferences → Connect Devices → Serial B Connector, which read "Nothing" until I set it.

I am assuming the port needs to be in the configuration list Preferences builds, and none of these Workshop volumes has ever had Preferences run on it. (By me anyway)

Preferences isn't installed on the Workshop 3.0 volume — the System-Mgr menu lists it, but launching gives error 131.

So: is there something a Workshop-only volume needs in order to use a serial port that an Office System volume gets from Preferences? And if so, how do you do it without Preferences — a MOUNT call, a file to copy across, or something else?

Writing directly with SysCall, OPEN on -RS232B-XYZ returns ecode 946. I have the OS Reference Manual's Table 2-1 and 2-2 and I'm following the required group order; my next test adds an explicit MOUNT before OPEN, but I'd rather ask than keep guessing.

sigma7 — you posted a PORTCONFIG EXEC script last July that configures port B for 9600 8N1. Does that run on a plain Workshop volume, or does yours have something mine doesn't?

Am I assuming correctly that if you have to reset on reboot the settings are stored in RAM?

Quote from: sigma7 on August 06, 2026, 11:30:45 PMFor the 7/7 applications, I believe you can just re-install (drag a fresh copy from a floppy that isn't serialized or has been deserialized).

I expect one can edit the ProFile image to deserialize too; Ray may have posted details about what is required.

Thanks! I have some floppy images that I think are not serialized. Image editing seems like more work... I noticed his instructions in a document somewhere.

Quote from: sigma7 on August 06, 2026, 11:22:09 PM

Quote from: bmwcyclist on August 06, 2026, 09:36:16 PMIs the serial port configuration kept in a file or is it kept in some sort of parameter ram?

It defaults to 9600 baud at startup; one can reconfigure it using the startup exec script feature, eg: Portconfig Exec Script

For "voting on the best method" purposes, I'd select "all of the above" as different situations benefit from different methods.

Perhaps when (if) there is a workshop + LOS tool that does binary and multiple files rapidly, then that will win out.

The portconfig.obj tool is giving me errors on both A and B. "invalid device name"

.
So it is writing to a file or ram?

Quote from: sigma7 on August 06, 2026, 11:28:22 PM

Quote from: bmwcyclist on August 05, 2026, 06:45:41 AMI have found that FloppyEMU disk images on MicroSD cards often get corrupted. There are various reasons such as incomplete shutdowns etc. These tools will help check and verify LOS 3.x disk images.

AFAIK, corruption of FloppyEMU disk images is not a common complaint - please correct me if I'm wrong.

So I wonder if the image corruption you've experienced is a result of experiments in editing them, or if your particular FEMU has a technical problem. Did you experience corruption before the editing experiments?

The issue seems to be from the FPGA since it keeps power to the EMU after the "lisa" is shut down. Too hasty a card removal can cause issues, apparently.

For the 7/7 applications, I believe you can just re-install (drag a fresh copy from a floppy that isn't serialized or has been deserialized).

I expect one can edit the ProFile image to deserialize too; Ray may have posted details about what is required.

Quote from: bmwcyclist on August 05, 2026, 06:45:41 AMI have found that FloppyEMU disk images on MicroSD cards often get corrupted. There are various reasons such as incomplete shutdowns etc. These tools will help check and verify LOS 3.x disk images.

AFAIK, corruption of FloppyEMU disk images is not a common complaint - please correct me if I'm wrong.

So I wonder if the image corruption you've experienced is a result of experiments in editing them, or if your particular FEMU has a technical problem. Did you experience corruption before the editing experiments?

Quote from: bmwcyclist on August 06, 2026, 09:36:16 PMIs the serial port configuration kept in a file or is it kept in some sort of parameter ram?

It defaults to 9600 baud at startup; one can reconfigure it using the startup exec script feature, eg: Portconfig Exec Script

For "voting on the best method" purposes, I'd select "all of the above" as different situations benefit from different methods.

Perhaps when (if) there is a workshop + LOS tool that does binary and multiple files rapidly, then that will win out.

Is the serial port configuration kept in a file or is it kept in some sort of parameter ram?