LISA File Transporter tool moves files from modern computers to the Workshop

[bmwcyclist]

I 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.

[bmwcyclist]

Is 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?

[AlexTheCat123]

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.

I'm not quite sure how that could cause a problem, and I haven't observed anything like that myself, but it definitely needs to be fixed if it's truly an issue! Can you elaborate on what you think could be causing a problem when power is sustained after the Lisa is off?

[bmwcyclist]

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.

I'm not quite sure how that could cause a problem, and I haven't observed anything like that myself, but it definitely needs to be fixed if it's truly an issue! Can you elaborate on what you think could be causing a problem when power is sustained after the Lisa is off?

I'm trying to reproduce the issue. I can almost guarantee you. It's end user error and not a problem with either the 210 or the FPGA.

[Eschaton]

Sadly, with AI's, there's no real way to figure out what they're doing, which is a big problem in my field, which is information Security. You can have them give you a list of sources, but it's not always accurate.

Just to clear something up: When you ask an LLM to explain itself after the fact, it's never accurate to what the LLM was actually doing, because they are not minds with that kind of introspection ability. All the LLM is going to do is incorporate the existing transcript of your interactions and produce a stream of next-most-likely tokens that happen to look like the explanation you asked for, regardless of what was actually going on under the hood.

That doesn't mean it might not be useful to you, since after all it may point you to references and give reasonable explanations of what someone asked to solve that problem might do, which you can learn from. But its relationship to what the model already did is arms' length at best.

[Eschaton]

Another source of information for the Lisa filesystems would be my lisafs, which is extract-only at the moment but if someone did the work could be used to put content into disk images. (I didn't feel like writing the B-tree insert code that filesystem v3 would require, and I don't use or allow LLMs in any of my projects.)

[bmwcyclist]

Another source of information for the Lisa filesystems would be my lisafs, which is extract-only at the moment but if someone did the work could be used to put content into disk images. (I didn't feel like writing the B-tree insert code that filesystem v3 would require, and I don't use or allow LLMs in any of my projects.)

Thank you!

[bmwcyclist]

Newist version:

A native Apple Lisa Office System application for moving files between a Lisa and a modern computer over a serial cable. Open it from a desktop icon, choose Receive or Send, and watch the blocks tick by in its own window — no Workshop session, no floppy shuttling.

Runs on Lisa OS 3.x. Serial B, XMODEM checksum, 1200 through 38400 baud — and yes, 38400 works on real hardware, well past Apple's documented 19200 ceiling, confirmed on two Lisa 2/10s.

Working now: receive · send · browse the disk and pick a file by number · adjustable speed · progress and block counts as it goes · any key stops a transfer.

Planned:

• Terminal mode, so you can drive a real modem and dial out
• CRC-16 in addition to checksum
• YMODEM batch — send a whole folder in one go, filenames and all
• Background transfers, so the desktop stays fully interactive
• A proper file-picker dialog
• File listing on machines whose boot volume isn't a 2/10's internal disk

Beta testers welcome — bug reports and feature ideas to LisaList2.

Built with the generous help of two people's published work: Alex Anderson-McLeod's heavily commented LOS Minesweeper, which is a teaching course in Office System app structure, and Tom Stepleton's lisabbs and format documentation. See less

[TorZidan]

Tim, I appreciate the addition of this new tool. I haven't tried it, but I watched the video.
Here is my feedback:

A serial file upload/download tool would be most useful in Workshop, not in LOS, because this is where "Lisa software developers" want to upload and compile their code. Also, when you upload a file to Workshop, it becomes available in LOS, as they share the same file system (it will appear in LOS only if it's an UI application, as we know).

Here is my "file upload app" wish list, which  - I think - many will agree with:
Implement a "kermit server" for Workshop. You just launch it in Workshop and it listens for put/get/list commands from the other side.
Use a standard "kermit" program on the other side, e.g. "sudo apt install ckermit" to install kermit on Ubuntu Linux, "brew install c-kermit" for MacOS (untested). Kermit (in client mode) can upload, download and list files, all from the client side.

Some implementation details for the Lisa-side:
- Make sure you can kill it / exit it easily from Workshop itself (in addition to sending it a "BYE" command from the other side).
- Make sure it automatically converts linux and windows new-lines  (\r\n and \n) to Lisa new-lines (\r) during upload of text files, and vice versa during download.
- Make sure it is able to distinguish text from binary files and save them properly; perhaps check if the file name ends with ".text" and a bunch of other file extension.
- The source files should be available (e.g. on Github) with a generous "free to use, modify and redistribute" license.

Note: this tool should also be able to upload the LOS source files if needed, one at a time, e.g.
kermit -s Lisa_Source/APPS/APBG/apbg-BG.TEXT.unix.txt -a APBG/BG.TEXT -l /dev/ttyUSB0 -b 38400
Kermit does support multiple file uploaded at once using file name wildcards, but you loose the ability to specify a target filename which is needed for the LOS sources, hence the need for uploading one file at a time.

[sigma7]

The Workshop console's refusal to poll the keyboard is a documented dead end, not a bug to fix.

Can you say more about this? The impetus for my suggesting a peek/poke tool to use in workshop exec scripts was the need to poll the keyboard... I was not aware that it went further than just being a limitation of the exec processing.

[bmwcyclist]

Tim, I appreciate the addition of this new tool. I haven't tried it, but I watched the video.
Here is my feedback:

A serial file upload/download tool would be most useful in Workshop, not in LOS, because this is where "Lisa software developers" want to upload and compile their code.

Thanks for the feedback!

One thing: the files downloaded by the LOS app are indeed available in the Workshop. That is how I update the application! Unless you mean you don't want to switch to the Workshop from LOS? I am hoping this will also be useful to folks who are not developers. I do have a workshop version; it's just clunky without the interface

[bmwcyclist]

The Workshop console's refusal to poll the keyboard is a documented dead end, not a bug to fix.

Can you say more about this? The impetus for my suggesting a peek/poke tool to use in workshop exec scripts was the need to poll the keyboard... I was not aware that it went further than just being a limitation of the exec processing.

Claude says:




So the precise claim: from a user program, via the documented DEVICE_CONTROL interface, the console driver won't answer a "keys waiting?" query, and console reads block. That's the whole finding. It says nothing about going around the OS — which is exactly your peek/poke territory. The Workshop's own Editor obviously reads raw keys somehow, so the capability exists below the surface; it's just not exposed through the device-control path a Pascal program can reach. Your impetus stands, and if anyone knows a dccode or call that does work on MAINCONSOLE, I'd genuinely love to be corrected — I shipped a RETURN-between-slides fallback I'd happily delete.

For contrast: under the Office System this problem evaporates — the Window Manager delivers keyDown events normally, which is why the desktop version of the same program has live keys with no polling at all.

[TorZidan]

One thing: the files downloaded by the LOS app are indeed available in the Workshop. That is how I update the application! Unless you mean you don't want to switch to the Workshop from LOS? I am hoping this will also be useful to folks who are not developers. I do have a workshop version; it's just clunky without the interface

Once I upload some source code file to the Lisa, the next logical step is to compile it and link it. This can be done only in Workshop (asfarasiknow). It does not make sense to boot into LOS, receive the file, then reboot into Workshop to compile it.

[stepleton]

So the precise claim: from a user program, via the documented DEVICE_CONTROL interface, the console driver won't answer a "keys waiting?" query, and console reads block. That's the whole finding. It says nothing about going around the OS — which is exactly your peek/poke territory. The Workshop's own Editor obviously reads raw keys somehow, so the capability exists below the surface; it's just not exposed through the device-control path a Pascal program can reach.

This is really puzzling since "LisaMandelbrot Pro" (which is the silly name I used for LisaMandelbrot running in the Workshop --- the workshop is where the "pros" are, you see) listens to and responds to keystrokes. Here's where it happens in the main source file (gosh, kinda long, huh):

https://codeberg.org/stepleton/LisaMandelbrot/src/branch/master/Pro/MANDELQD.TEXT#L1073

The KeybdEvent function is part of the hardware interface and is documented starting on PDF page 395 of version 3 of the the Pascal Reference manual. (Actually I think every cover of that three-manual set shows a screenshot of some source code that calls this function    page 1 of each PDF.) Other functions and procedures described nearby provide other facilities that are useful for keyboard interrogation. So I'm puzzled.

My confusion may come from the discussion here being about two different things; there's whether EXEC scripts can take keyboard input and whether Workshop programs have versatile access to the keyboard. I forget about the former but for the latter, the answer is yes, absolutely. It sounds like Claude thinks differently, or at least has not found a way to do it via "the device control path".

There may or may not be a lesson here about letting Claude do a whole lot of the knowledge-building for you. My advice either way is to just to read all of the Workshop manuals --- yes, end to end. They're actually written pretty well, and while it's impossible to remember everything that they say, they will let you know what's possible. That way if Claude says "beep boop no keyboard" you can say "hang on, I'm pretty sure I remember something about this, I think it's possible somehow."

[sigma7]

There may or may not be a lesson here about letting Claude do a whole lot of the knowledge-building for you.

Agreed... I'm thinking part of the issue is the authoritative language that AI/Claude emits, when it really would be more productive acknowledging that it has no idea what it doesn't know. It looks easy to be misled that something is a dead end or otherwise onto a wrong path.

I think I've noticed that parts of some recent postings have a distinctly non-human style and now wondering if we should have a formal requirement to style such content so it is easy to recognize the portion that is AI output... comments/suggestions?