General Category > Building LOS From Source
I've successfully built LOS from source!
danm:
Update: Noticed afterwards that Alex probably already found this. Oh well, easy access for anyone else who might want to try to dissect it.
Not sure how useful it is, but PACKSEG.OBJ exists on at least some of the Monitor versions. Here's one dated 28 Mar 1983 from Monitor 12.2
Monitor 12.2 1 Contents: https://macgui.com/spyglass/r/7e8a7a533c8dfb56
Disk Image: https://macgui.com/downloads/?file_id=35032
stepleton:
--- Quote from: AlexTheCat123 on July 09, 2025, 06:41:34 pm ---
--- Quote from: stepleton on July 09, 2025, 05:27:21 pm ---I thought I'd give it a quick look, but now I've set it aside to peruse later at leisure :-)
--- End quote ---
I see what you did there!
--- End quote ---
I have now perused! I really enjoyed reading the document; it reminded me of those tours or videos where a guide takes you behind the scenes of some major piece of infrastructure: you get to see the turbines inside the hydroelectric dam or the control centre with the illuminated diagrammatic map of the railway or whatever it is.
It seems to me that one thing we dearly need is a good way to get lots of files on and off of the Lisa. Better file transfer should be possible in a few ways; 1200 BPS 7E1 is a pretty narrow straw for so much text. Nothing's off-the-shelf, but the most straightforward is probably to write a different program to talk to the serial port instead of the Transfer application. I took a crack at this with moderate but not total success about ten years ago, writing a program that allowed you to transfer files off (but not onto) the Lisa using the YMODEM protocol: you can see it here. I wouldn't advise trying to adapt this program, but I would suggest that the LIBPORT library inside of it can save anyone aiming to write serial port code a whole lot of effort.
At a minimum, the new program could use 8-bit bytes, which might save some of the hassle around Lisa-only characters that don't make it through the 7-bit transfer. You can also imagine coming up with a way that would allow you to transfer many files in one go. YMODEM actually allows this kind of batch transfer, though I never got it to work with the program I linked above. (Incidentally, I think YMODEM is a pretty good protocol to use here: XMODEM lacks batch transfer, while ZMODEM is technically better but more complicated to implement.) But since we are transferring text files, a simpler method could do the job, one where each file is sent straight over the wire with some kind of special divider string separating them. This would require some programming on the other side of the null modem cable too, but not too much.
One of the reasons I avoided writing code to upload files to the Lisa is because careful handling is required for text files. It's fine to send binary files to the Lisa directly, but if you want to send a text file from a modern computer so that it behaves like a text file on a Lisa, you will need to either open a file as text from your Pascal code when creating it or do a binary translation of the modern-computer text file to "The Last Whole Earth Text File Format", which is how text files are represented at a low level (see PDF pages 37-38 here). TL/DR: text comes in 1K blocks, the first block is metadata, lines of text can't straddle blocks, blocks are null-padded and need at least one null, and there is a run-length encoding scheme for the space (that is, ' ') character only.
One final note for text files: for converting \n to \r, the process_source.py script does the job and has proven itself to work. That said, many Linux distributions will be able to install the dos2unix package, which also contains the helper programs mac2unix and unix2mac. I will indulge myself a bit of shell flexing and pose that this line does in bash what the script does:
for i in `find . -name *.unix.txt`; do unix2mac -n $i `echo $i | sed s/.unix.txt$//`; rm $i; done
Beware that I have not tried it and the command calls `rm` in the context of a recursive directory scan! Use at your own risk!
Coming back to the OS itself, I was surprised not to see more signs that hinted at 7/7's ability to embed stuff made by one tool into a document belonging to another tool. You can put LisaDraw drawings into a LisaWrite document, for example; I might have expected more code that was obviously shared between tools in order to make that possible. Maybe it's there but it's in a regular non-intrinsic library somewhere.
As a minor nitpick, the doc describes files in the Workshop with names like ALEX/FOO.TEXT as being in the "ALEX" directory, but / is not a path delimiter in the Workshop and is just a part of the filename. For most of its life the Workshop never had directories at all; Workshop 3 finally debuted a hierarchical filesystem with directories called "catalogs" and "subcatalogs". The path delimiter was -. ref1 ref2. (You may have known this and had just wished to spare readers the extra detail.) It looks like / was a pretty common file naming idiom in lieu of directories.
Other thoughts... I like how LisaTerminal didn't really even turn up in the story; it seems to be a tool that gave you very little trouble!
I really liked this table at the bottom of the document.
I thought I'd take a look at my Workshop 1.0 installation to see if PACKSEG.OBJ might be there, but no luck unfortunately.
Not much more to say other than continued appreciation for the feat that was (re)building the OS at last. Just for the symbolism of it, someone should run a freshly-compiled Lisa OS on one of those Apple Lisa clones!
AlexTheCat123:
Wow, thanks for all the feedback!
--- Quote from: stepleton on July 19, 2025, 06:46:44 pm ---It seems to me that one thing we dearly need is a good way to get lots of files on and off of the Lisa.
--- End quote ---
Agreed. The current method with the Transfer program is pretty terrible, and I feel kind of embarassed that I didn't provide a better solution. I think the YMODEM idea is the way to go, unless anybody can think of anything better, and 8-bit transfers would hopefully solve the "special character" issue. From everything I've seen, the Pascal routines for handling text files seem like they'd do the job nicely, so I don't think we'd have any problem with writing the weird text files on the Lisa end of things. I was originally hoping to write some kind of improved transfer program myself, but spending nearly 6 months in the Workshop is a lot, and I feel like I need to take a break and move onto other things for a little while!
--- Quote from: stepleton on July 19, 2025, 06:46:44 pm ---As a minor nitpick, the doc describes files in the Workshop with names like ALEX/FOO.TEXT as being in the "ALEX" directory, but / is not a path delimiter in the Workshop and is just a part of the filename.
--- End quote ---
Don't worry, I know they're not actually directories or anything. I was just doing that for the sake of simplicity. And since all the source code already used the "/" as a delimiter for its fake directories, I decided I'd do the same instead of actually making catalogs.
--- Quote from: stepleton on July 19, 2025, 06:46:44 pm ---Coming back to the OS itself, I was surprised not to see more signs that hinted at 7/7's ability to embed stuff made by one tool into a document belonging to another tool. You can put LisaDraw drawings into a LisaWrite document, for example; I might have expected more code that was obviously shared between tools in order to make that possible. Maybe it's there but it's in a regular non-intrinsic library somewhere.
--- End quote ---
I think most of that stuff is going to be in the Scrap library (LIBSU), which ultimately gets linked into SYS1LIB. And then each application can just put things into (cut/copy) or grab things out of (paste) the scrap, as well as check what type of items (graphics, text, etc) are in the Scrap.
--- Quote from: stepleton on July 19, 2025, 06:46:44 pm ---Other thoughts... I like how LisaTerminal didn't really even turn up in the story; it seems to be a tool that gave you very little trouble!
--- End quote ---
Yeah, there were some things like LisaTerminal and several of the libraries that went so smoothly that they aren't even worthy of mentioning! Granted, "smoothly" is relative; LisaTerminal still took the better part of a day to get going if I remember correctly, but that's nothing compared to some of the other stuff!
blusnowkitty:
This is likely a very stupid question but it just popped into my head now. Is there anything stopping us from running the Workshop with say, an XLerator or something like it? The thought of leaving my Lisa on for hours on end compiling code at 5MHz gives me a bit of a shiver.
sigma7:
--- Quote from: blusnowkitty on August 13, 2025, 05:31:46 pm ---Is there anything stopping us from running the Workshop with say, an XLerator or something like it?
--- End quote ---
Yes, there is a compatibility problem:
To obtain fast access to memory, the XLerators don't use the Lisa's MMU, so the Workshop and LOS that make heavy use of the MMU aren't compatible with the XLerators. (At least, not for now, and maybe never)
I suspect there isn't an alternative 68000 accelerator board that would show much improvement, as the best it could do while using the CPU board MMU amounts to caching instructions/data (or so I speculate).
A 'real' drop-in solution would be a new accelerator design that incorporates a fast version of the MMU. Although that's been suggested, Alex hasn't finished it yet. :)
Perhaps LisaEm is ultimately the best solution?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version