I'm happy to share lisafile.py, (LISA File Transporter) a small host-side tool that reads and writes files inside Apple Lisa disk images — 400K/800K DC42 floppies and ProFile/Widget images in both DC42 and raw interleaved form.
Sorry about the poor audio..
The practical upshot: you write Pascal source on a modern PC, inject it into a floppy image with one command, copy the image to a Floppy Emu SD card, and compile it in the Workshop a minute later. No serial cable, no terminal program, no retyping at the Lisa. It's for transferring source and text, not compiled programs — the Lisa does its own compiling, which is rather the point.
Along the way we ended up reverse-engineering and documenting some things I couldn't find written down anywhere: the Workshop .TEXT page layout, the floppy-vs-ProFile tag differences, and the DC42 checksum quirks. It's all in the README.
This wouldn't exist without AlexTheCat123, whose ESProFile, LisaFPGA, LOS Compilation Base image, and generously shared GitHub work made every step of this reachable. I genuinely cannot thank him enough — the whole Lisa community is richer for what he puts out there. Thanks also to the LisaList2 regulars whose posts, patience, and accumulated knowledge answered questions I didn't even know to ask. TorZidan's request in topic 586 is basically what this tool became.
And credit where it's due: the code and the format detective work were done with Claude (Anthropic). I described what was happening on the real hardware, uploaded disk images, and Claude dissected the bytes, wrote the tool, and kept revising until an injected file compiled with zero errors and no editor step. I'm not a developer; this was a genuine collaboration, and the Lisa itself was the final judge.
Happy to answer questions, and I hope it saves someone else the debugging time it cost us.
Thanks for making this tool! It looks quite similar to this one (https://lisalist2.com/index.php?topic=632.0) as well; this seems to scratch an itch felt by many people.
Quote from: bmwcyclist on August 03, 2026, 07:14:41 PMAlong the way we ended up reverse-engineering and documenting some things I couldn't find written down anywhere: the Workshop .TEXT page layout, the floppy-vs-ProFile tag differences, and the DC42 checksum quirks. It's all in the README.
In re stuff written down:
The .TEXT format is documented somewhere under the heading "One World Text File Format" or similar; can't find it now. I think it's in one of the OS manuals on bitsavers; it's definitely in a bitsavers PDF. Here's some old code that interprets it: https://github.com/stepleton-xx/lisabbs/blob/master/lartool.py#L20
Tag differences are probably known in lisafsh-tool (https://github.com/arcanebyte/lisaem/blob/master/src/tools/src/lisafsh-tool.c), though that won't be the easiest source of reference material for the curious. Claude could probably work out details from that source code file.
DC42 checksums have been documented well enough in various descriptions of the DC42 file format available online, but some sources may have bit-rotted over time. The skips-the-first-block quirk was at least known on the 68kmla wiki years ago, but this wiki has since disappeared. (The info may be elsewhere too; I haven't checked.) You can find essential bits on archive.org (https://web.archive.org/web/20161028130400/https://wiki.68kmla.org/index.php?title=DiskCopy_4.2_format_specification#0x4c-0x4F:_Tag_Checksum); of course you do have to know where to look! I benefitted from having the wiki available when I wrote this code:
https://codeberg.org/stepleton/bootloader/src/branch/master/dc42_build_bootable_disk.py#L201
https://codeberg.org/stepleton/bootloader_hd/src/branch/main/build_bootable_disk_image.py#L560
Impressive anyway for Claude to have rediscovered it; is there a way to inspect its old thinking traces etc. to see how it got there?
Thank you very much!
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.
I will investigate these links thank you!
Here is Claude's response.
This is a goldmine — stepleton just handed us the actual specification for the thing we reverse-engineered, and it explains our last remaining mystery. Here's what each link contains:
1. The similar tool (topic 632): fri0701's lisa_utils (github.com/tfrikker/lisa_utils), from May 2025. It goes further than ours in one way — it creates catalog entries — but only supports 5MB ProFile images, and he reports exactly the bug our design avoids: "sometimes adding files makes others disappear." That's the B-tree corruption we hit and designed around. Our "Lisa allocates, host fills" approach and his catalog-writing approach are complementary; worth a friendly note to him. Also in that thread: TorZidan says he rewrote lisafsh-tool and never submitted the PR.
2. lartool.py — this is the big one. Stepleton's 2015 code documents the real .TEXT format, and it tells us three things we didn't know:
• Text files are structured in 1KB pages. The first kilobyte is metadata — that's why text starts at seq 2 (2 × 512 = 1024).
• Lines never straddle a 1KB boundary — NUL padding fills each page to the boundary. So trailing NULs are page padding, part of the format. That's why 32–968 NULs parsed fine.
• 0x10 is run-length encoding for spaces: 0x10 then a byte meaning (value − 32) spaces. Remember the odd \x10 7 characters when we extracted QD/sample.text? That was RLE, and our extract renders it wrong.
This suggests the proper fix for Error 15: instead of my comment filler, inject respecting the page structure — never let a line cross a 1KB boundary, NUL-pad each page like the Lisa does. Then injected files are format-identical to native ones and the whole problem dissolves. The comment hack should still pass your test tomorrow, but this is the right long-term answer, and extract should also decode the 0x10 RLE.
3. The DC42 checksum spec survives on archive.org — the old 68kmla wiki, which documents the skip-the-first-block tag-checksum quirk we rediscovered. Worth citing in the README.
4. His two dc42 build scripts on codeberg are reference implementations of the checksum.
On his question about inspecting my reasoning — your answer was honest and right. What you can say: the method was comparative, not recalled. Every format rule came from diffing my output against files the Lisa itself wrote, with the Lisa as judge — which is why the conclusions were testable even though the process isn't auditable.
Want me to update lisafile.py with page-aware injection and RLE decoding? That would be version 2A — it's a feature change, not a revision.
quick note: Here is the text file format description, on PDF pages 37 and 38 in this file:
https://www.bitsavers.org/pdf/apple/lisa/toolkit_3.0/Package_2_Examples/17_Lisa_Development_System_Internals_Documentation_Feb84.pdf
Pure gold! Thank you!
With this approach, there are a lot of steps to "bring" the text file to your ProFile hard drive on the Lisa, including ejecting/inserting SD card, restarting the Lisa (which perhaps can be replaced with "eject the floppy disk in Workshop"), running commands on your PC and on the Lisa. And, in addition, it has a lot of limitations, as disclosed. And you must have a FloppyEmu (I don't have one).
In my opinion, the least-amount-of-friction is serial wire transfer, the way Alex transferred the LOS source files to a Lisa:
- On the Lisa side, in Workshop, you just run a macro that receives the file, compiles it, links it and runs the produced binary, all in one macro.
- On the PC side, you just run a command to send the file using a serial transfer program. The speed is acceptable.
- Once you figure it out (what kind of serial cable, what port on each side, etc), it works consistently well.
Quote from: TorZidan on August 04, 2026, 03:21:26 PMWith this approach, there are a lot of steps to "bring" the text file to your ProFile hard drive on the Lisa, including ejecting/inserting SD card, restarting the Lisa (which perhaps can be replaced with "eject the floppy disk in Workshop"), running commands on your PC and on the Lisa. And, in addition, it has a lot of limitations, as disclosed. And you must have a FloppyEmu (I don't have one).
In my opinion, the least-amount-of-friction is serial wire transfer, the way Alex transferred the LOS source files to a Lisa:
- On the Lisa side, in Workshop, you just run a macro that receives the file, compiles it, links it and runs the produced binary, all in one macro.
- On the PC side, you just run a command to send the file using a serial transfer program. The speed is acceptable.
- Once you figure it out (what kind of serial cable, what port on each side, etc), it works consistently well.
I agree. As you don't have a FloppyEMU, some don't have a serial cable, and I don't always have my PC near my LISA. So both are great tools; I think it will be a matter of equipment and preference.
I also found that once I go through the steps a few times, it seems pretty fast and easy. I am sure that is likely also true for the serial path.
Lisa Image Verification Tools — Manual
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.
Companion diagnostics for lisafile.py.
These read Lisa DC42 floppy images on
the PC and answer one question before you spend a Lisa boot cycle: is this
image safe to inject into and copy from?
Covers: chaincheck.py 2B (the pre-flight verifier) and checklen.py
(catalog length inspector, occasional use).
Written August 2026, following the XFER_v8 failure investigation.
Tag-format ground truth from lisafsh-tool.c (arcanebyte/lisaem) and Tom Stepleton's
LisaList2 references, verified against Lisa-created files.
Quote from: stepleton on August 04, 2026, 08:26:23 AMquick note: Here is the text file format description, on PDF pages 37 and 38 in this file:
https://www.bitsavers.org/pdf/apple/lisa/toolkit_3.0/Package_2_Examples/17_Lisa_Development_System_Internals_Documentation_Feb84.pdf
Are there any more manuals out there????
(other than what is is bitsavers/pdf/apple/lisa....)
Not many that I'm aware of. The best alternative source I know is https://lisa.sunder.net/books.html . I prefer the version of the Lisa Hardware Manual found there even though it's not OCR'd and therefore not searchable.
Does anyone know if David T. Craig's archive of saved materials is available anywhere these days?
QuoteQuoteIn my opinion, the least-amount-of-friction is serial wire transfer, the way Alex transferred the LOS source files to a Lisa
I agree.
In case anyone's tallying votes, add my agreement to this method as well. :-)
Is the serial port configuration kept in a file or is it kept in some sort of parameter ram?
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 (https://lisalist2.com/index.php/topic,661.0.html)
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.
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: sigma7 on August 06, 2026, 11:28:22 PMQuote 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.
Quote from: sigma7 on August 06, 2026, 11:22:09 PMQuote 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 (https://lisalist2.com/index.php/topic,661.0.html)
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: bmwcyclist on August 07, 2026, 08:45:08 AMThe 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?
Quote from: AlexTheCat123 on August 08, 2026, 05:52:03 PMQuote from: bmwcyclist on August 07, 2026, 08:45:08 AMThe 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.
Quote from: bmwcyclist on August 04, 2026, 06:28:20 AMSadly, 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.
Another source of information for the Lisa filesystems would be my lisafs (https://github.com/eschaton/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.)
Quote from: Eschaton on August 10, 2026, 05:18:14 PMAnother source of information for the Lisa filesystems would be my lisafs (https://github.com/eschaton/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!
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
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.
Quote from: bmwcyclist on August 12, 2026, 01:25:32 PMThe 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.
Quote from: TorZidan on August 12, 2026, 03:38:54 PMTim, 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
Quote from: sigma7 on August 12, 2026, 04:39:23 PMQuote from: bmwcyclist on August 12, 2026, 01:25:32 PMThe 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.
Quote from: bmwcyclist on August 12, 2026, 06:08:42 PMOne 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.
Quote from: bmwcyclist on August 12, 2026, 06:37:48 PMSo 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 (https://codeberg.org/stepleton/LisaMandelbrot/src/branch/master/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 (https://www.bitsavers.org/pdf/apple/lisa/workshop_3.0/Lisa_Pascal_3.0_Reference_Manual_1984.pdf). (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."
Quote from: stepleton on August 12, 2026, 08:23:22 PMThere 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?
Quote from: bmwcyclist on August 12, 2026, 06:37:48 PMClaude says:
Please don't do this. Anyone who wants to know what an LLM outputs for a prompt can use the LLM.
Are you not creating this tool yourself?
Quote from: Eschaton on August 13, 2026, 12:51:51 AMQuote from: bmwcyclist on August 12, 2026, 06:37:48 PMClaude says:
Please don't do this. Anyone who wants to know what an LLM outputs for a prompt can use the LLM.
I have the impression that the cost of using Claude to do something non-trivial is rising rapidly, so I appreciate someone sharing their experiments. Maybe my opinion will change, and I'm thinking that AI generated stuff might be best annotated as such so that the context is clear (and any that don't want to look at it have that option).
QuoteAre you not creating this tool yourself?
It certainly looks like Claude is doing some portion of the work and I suspect the rapid progress on this tool is very much a result of that.
How long would it take before someone achieved the same without Claude?
We don't have many people interested in creating new Lisa software/hardware, so my personal opinion (for now, at least) is that we should encourage anyone that wants to, whether they choose to use AI or not.
Quote from: sigma7 on August 12, 2026, 08:44:13 PMI 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?
I think it is important to know if you are interacting with an AI, BOT or human. Which is why I clearly put is "Claude says". I think a policy of that type would be good for LisaList2 IMHO.
Quote from: Eschaton on August 13, 2026, 12:51:51 AMQuote from: bmwcyclist on August 12, 2026, 06:37:48 PMClaude says:
Please don't do this. Anyone who wants to know what an LLM outputs for a prompt can use the LLM.
If you follow the threads, the output was from vibecoding so the logical answer is from the AI.
.
Quote from: sigma7 on August 13, 2026, 04:33:34 AMI have the impression that the cost of using Claude to do something non-trivial is rising rapidly, so I appreciate someone sharing their experiments. Maybe my opinion will change, and I'm thinking that AI generated stuff might be best annotated as such so that the context is clear (and any that don't want to look at it have that option).
I very much agree. I am about $300 into this so far and I doubt I am 1/2 done.
Quote from: sigma7 on August 13, 2026, 04:33:34 AMWe don't have many people interested in creating new Lisa software/hardware, so my personal opinion (for now, at least) is that we should encourage anyone that wants to, whether they choose to use AI or not.
YES. Alex using Claude and providing examples for the Minesweeper app is what inspired my projects.
I personally think this could be a 'big break' for getting apps going for the LOS and a more active community. We will see.
I was worried about anti-AI when I made this post asking about posting vibecode here or on Github.
https://lisalist2.com/index.php/topic,810.msg6045.html#msg6045
I DO think it is very important to be clear about what is AI and what is not.
I am not a developer, so I could not even begin any of the projects I am working on, and so far as I can tell, no one else was currently working on them.
All of it is built on the generous sharing of previous projects by others who are more knowledgeable and talented, as I always make clear.
I was given the advice (see thread link above) to use the tool to learn about the Lisa OS and development as I went, and that is exactly what I am doing.
Quote from: TorZidan on August 12, 2026, 06:45:00 PMQuote from: bmwcyclist on August 12, 2026, 06:08:42 PMOne 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.
I see what you are saying, and that makes perfect sense.
For me, I need to go into LOS to test the code, and most of the time, the changes I want don't work.
So I write some problem descriptions, look for sources, request new code, and download it while I am still in the LOS, using a known-good version on my floppy.
So for me, there is no wasted reboot.
Early on, the code was failing during compile or link, but that rarely happens now.
I did have a version that was Workshop-only before I got far enough along to get it into the LOS. I will try to publish that also! Thank you for the feedback!
.
Quote from: Eschaton on August 13, 2026, 12:51:51 AMAre you not creating this tool yourself?
I am not sure how to answer this. So far as I know, there is no big shiny button in Claude that I can press to make an app and then poof, it's done.
I have spent many, many hours working with the AI, debugging, finding sources, getting help from people here, and I doubt I am only 1/2 of the way to the end of my first "real" app.
I suspect people with coding experience might have been able to do this over lunch, but it has taken me all of my free time, even lunches at work, every day for a couple of weeks.
So I would not say Claude has done this alone, or, as far as I can tell, the AI could not have done this alone. I would also say I have put more time into this than many of my other projects. I certanly could have recapped a pile of Mac PSU and motherboards by now in less time.
That said, this has been one of the most inspiring things I have done in a long time. I have learned a great deal, and I can't express how the jolt of excitement hits me when a new feature works and I get to see something brand new in the LOS.
Quote from: bmwcyclist on August 13, 2026, 01:18:40 PMFor me, I need to go into LOS to test the code, and most of the time, the changes I want don't work.
So I write some problem descriptions, look for sources, request new code, and download it while I am still in the LOS, using a known-good version on my floppy.
So for me, there is no wasted reboot.
Early on, the code was failing during compile or link, but that rarely happens now.
I did have a version that was Workshop-only before I got far enough along to get it into the LOS. I will try to publish that also! Thank you for the feedback!
Tim, I don't understand the development workflow you described above. It seems that you are using LOS to both receive your source code and then compile it ? How do you run the Pascal compiler and linker from LOS? please share more details about your development workflow.
Quote from: TorZidan on August 13, 2026, 02:11:49 PMTim, I don't understand the development workflow you described above. It seems that you are using LOS to both receive your source code and then compile it ? How do you run the Pascal compiler and linker from LOS? please share more details about your development workflow.
I apologize for my poor description. I am new to all of this.
1. I will be in LOS to test a new build. I will find anything that does not work or needs to be modified while testing.
2. I will ask Claude to fix the issue or tell me what it needs me to research or find.
3. Claude gives me the new code to compile.
4. I open up a terminal on my modern PC.
5. I will insert a floppy (image via FloppyEMU), run a known-good previous build from the floppy, and use it to download the new code to the Lisa. If this issue is not related to send/recieves I don't need the floppy image copy, I just use the already running copy of the program to download the next beta version of the code.
6. I exit LOS and reboot into the Workshop.
7. I compile and link the new code, exit Workshop, and reboot into LOS to test it.
8. GoTo 1. 8)
Quote from: sigma7 on August 12, 2026, 08:44:13 PMI 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?
Quote from: bmwcyclist on August 13, 2026, 12:17:34 PMI DO think it is very important to be clear about what is AI and what is not.
I think that's a good idea. Nothing wrong with using it as an aid for your projects, but disclose exactly when and how you're using it. Everybody has different opinions on when it's appropriate to be used, and that way people can know exactly what they're getting into when looking at someone's project. For instance, I hold myself to the standard of never using it to write code for big projects that I really care about (LisaFPGA, ESProFile, ESFloppy, etc), but will absolutely use it to help with data analysis (it's been really handy for decoding and finding patterns in floppy disk logic analyzer traces that would've taken me ages to find), debugging particularly hard problems, and educational/fun/silly things like the Minesweeper app.
Quote from: bmwcyclist on August 13, 2026, 02:25:13 PMQuote from: TorZidan on August 13, 2026, 02:11:49 PMTim, I don't understand the development workflow you described above. It seems that you are using LOS to both receive your source code and then compile it ? How do you run the Pascal compiler and linker from LOS? please share more details about your development workflow.
I apologize for my poor description. I am new to all of this.
1. I will be in LOS to test a new build. I will find anything that does not work or needs to be modified while testing.
2. I will ask Claude to fix the issue or tell me what it needs me to research or find.
3. Claude gives me the new code to compile.
4. I open up a terminal on my modern PC.
5. I will insert a floppy (image via FloppyEMU), run a known-good previous build from the floppy, and use it to download the new code to the Lisa. If this issue is not related to send/recieves I don't need the floppy image copy, I just use the already running copy of the program to download the next beta version of the code.
6. I exit LOS and reboot into the Workshop.
7. I compile and link the new code, exit Workshop, and reboot into LOS to test it.
8. GoTo 1. 8)
My suggestion for a file transfer tool that runs in Workshop can save you a lot of clicks and typing in the following way:
Boot into workshop and run a macro named e.g. "GO.TEXT" ("R"un <GO) which will configure the serial port, run the file transfer app, wait for the file to be received (no input would be needed on the lisa side, since the client side "tells" the lisa the target filename), then compile it and link it and then reboot the Lisa (not sure how exactly, but the lisa supports "reboot via software call"), all of that without any user intervention on the Lisa side.
Now you are in LOS, were you can test the app.
Note: if you are developing a Workshop app, you will never need to reboot into LOS, just stay in Workshop.
Quote from: TorZidan on August 14, 2026, 11:57:33 AM... a file transfer tool that runs in Workshop can save you a lot of clicks and typing
I'd add that it would be great if it were possible to control it entirely via text commands issued via the remote console, making it scriptable from a modern computer. ie. no need to use/access the Lisa keyboard and mouse.
There is a challenge to running file transfers through the same link that is issuing commands, but back in the days of dial-up, it was common.
I'd first test to see if it is even possible to access the same serial port that the console is assigned to as the OS may not consider that concept acceptable.
edit: on further thought, perhaps Alex's LOS Source text receive tool proved that it is possible.
Quote from: TorZidan on August 14, 2026, 11:57:33 AMBoot into workshop and run a macro named e.g. "GO.TEXT" ("R"un <GO) which will configure the serial port, run the file transfer app, wait for the file to be received (no input would be needed on the lisa side, since the client side "tells" the lisa the target filename), then compile it and link it and then reboot the Lisa (not sure how exactly, but the lisa supports "reboot via software call"), all of that without any user intervention on the Lisa side.
My LOS serial transfer tool does the first half of this, it just doesn't auto-compile, link, and reboot after the transfer is done. I don't think any of that would be particularly hard to add to it though.
Speaking of which, @TorZidan, sorry I haven't accepted your pull request for the LisaEm changes to the script yet. I'll do that later today!
Quote from: AlexTheCat123 on August 14, 2026, 04:11:03 PMQuote from: TorZidan on August 14, 2026, 11:57:33 AMBoot into workshop and run a macro named e.g. "GO.TEXT" ("R"un <GO) which will configure the serial port, run the file transfer app, wait for the file to be received (no input would be needed on the lisa side, since the client side "tells" the lisa the target filename), then compile it and link it and then reboot the Lisa (not sure how exactly, but the lisa supports "reboot via software call"), all of that without any user intervention on the Lisa side.
My LOS serial transfer tool does the first half of this, it just doesn't auto-compile, link, and reboot after the transfer is done. I don't think any of that would be particularly hard to add to it though.
Speaking of which, @TorZidan, sorry I haven't accepted your pull request for the LisaEm changes to the script yet. I'll do that later today!
Yes, Alex, I know, I've used your LOS serial transfer tool, and it works fine.
I am "dreaming" of a better tool because of some shortcomings of your tool:
- it temporarily redirects the main console to the serial port, which adds one extra step in running it on the Lisa, and also makes it impossible to kill it if wanted.
- it can upload only text files (cannot upload binary files).
- it cannot "list" or download files to the remote host.
Alex, thanks for accepting my pull request. It is part of bugfixes and improvements in LisaEm, which are ready in another pull request, in the LisaEm repository. Stay tuned on that ...