LisaList2
General Category => LisaList2 => Building LOS From Source => Topic started by: AlexTheCat123 on June 16, 2025, 02:09:07 pm
-
Some of you might be aware that I've been working towards building all of LOS from the Apple-provided source code over the past 5 months, and I'm happy to announce that I'm finally done!
I'm going to be exhibiting VCF Southwest this coming weekend, and I'll be giving a presentation with @warmech on Saturday at 10:30AM that goes over the entire journey and some of the interesting things that I discovered along the way. So if anyone else is going to be there, then feel free to come and see our table (the one with the 4 or 5 Lisas) and the presentation in person! If not, it'll be posted on YouTube about 24-48 hours afterwards.
I don't want to spoil anything before then, so I won't really be giving any more big details until the presentation, but of course I'll be providing a lot more info and releasing all of the Workshop EXEC scripts I created to automate the build process once I get back from VCF.
I also had to make changes to some of the source files (and had to create a couple new ones), but I'm not sure that I can share those thanks to Apple's license agreement. So I might just have to publish a list of the changes that you have to make, and then other people would have to patch their sets of files manually. Really, the most optimal way to share all my progress would be to provide a ready-to-go disk image with all the source files and build scripts in place, where the user could just run a build script and be all set, but the license stuff seems to prohibit this sort of thing.
If anyone knows of any ways to share both the code and build scripts without violating the license, I'd love to hear them!
-
I think you could get away with distributing xdelta or diff patches... That's how ROM hackers tend to usually escape Nintendo's ire, anyway.
-
I'm happy to announce that I'm finally done!
Wow, that's most excellent news! Congrats and what a fantastic contribution!
Perhaps Al Kossow has some suggestions for a good way to post updated code within the terms of the license agreement...
-
Congratulations! You know I'll watch that talk the minute it goes up!
-
This is amazing! I dove into the code recently to work towards the same goal, and learned a lot in the process. I can imagine how much work it took!
I'm very curious to see your presentation when it comes to YouTube, and hopefully you can find a license-appropriate way to share your work so we can all check it out. :)
-
I think you could get away with distributing xdelta or diff patches...
Hmm, that's a good idea. I'll definitely look into it!
Wow, that's most excellent news! Congrats and what a fantastic contribution!
Perhaps Al Kossow has some suggestions for a good way to post updated code within the terms of the license agreement...
Thanks James! And that's another good idea; maybe Al can comment here if he has any ideas.
Congratulations! You know I'll watch that talk the minute it goes up!
This is amazing! I dove into the code recently to work towards the same goal, and learned a lot in the process. I can imagine how much work it took!
I'm very curious to see your presentation when it comes to YouTube, and hopefully you can find a license-appropriate way to share your work so we can all check it out. :)
Thank you both!
@fri0701 I saw your thread a month ago about the awesome utility you wrote to get source files into LOS disk images, and I think that should help with the problem of not being able to provide a ready-made disk image to a certain extent too. I transferred all the files one by one over serial at 1200 baud, which takes forever and isn't practical, but a utility that can do it all in seconds is a much more convenient solution.
-
I transferred all the files one by one over serial at 1200 baud, which takes forever and isn't practical
Does this involve transferring every file separately? As in, within the Workshop transfer application, you say "Save to file" or whatever it is, type out the name of the file, push the file data from the other end of the link, then tell the Workshop application that the file is done? If so, that's an incredibly repetitive process for hundreds of files!
-
Does this involve transferring every file separately? As in, within the Workshop transfer application, you say "Save to file" or whatever it is, type out the name of the file, push the file data from the other end of the link, then tell the Workshop application that the file is done? If so, that's an incredibly repetitive process for hundreds of files!
Yes, that's exactly how I had to do it. I really should've written a program to pack all the files, transfer them as one, and then unpack them on the Lisa end or something, but for some reason I thought that this would be quicker. It was NOT fun in the slightest!
-
Nice! Congratulations!
-
Does this involve transferring every file separately? As in, within the Workshop transfer application, you say "Save to file" or whatever it is, type out the name of the file, push the file data from the other end of the link, then tell the Workshop application that the file is done? If so, that's an incredibly repetitive process for hundreds of files!
Yes, that's exactly how I had to do it. I really should've written a program to pack all the files, transfer them as one, and then unpack them on the Lisa end or something, but for some reason I thought that this would be quicker. It was NOT fun in the slightest!
So you have paid the real cost of this "free" source release: your time. 8)
-
So you have paid the real cost of this "free" source release: your time. 8)
A whole, whole lot of time!
-
Fantastic presentation!
Packed house with 2 rooms full of participants.
Made my trip from Cincinnati worth it!
People were talking about it in the hallways for half an hour and might still be.
Amazing work!!!!!
-
I'm gonna keep my eyes peeled, but in case anyone has a link to the recording and nobody has posted it yet --- please share!
-
Okay, the video just went up!
https://www.youtube.com/watch?v=X0btMjXEXgc (https://www.youtube.com/watch?v=X0btMjXEXgc)
As I think I mentioned earlier, I won't be back home until late this week, so give me a bit of time to actually get the build scripts and necessary code modifications prepared and uploaded. But I hope to have them ready by mid to late next week!
-
Alex, that is awesome! Nice work 8)
-
Alex, that is awesome! Nice work 8)
Thank you! I hope you enjoy the (rather long) presentation!
-
Thank you for all of your hard work!
Okay, the video just went up!
https://www.youtube.com/watch?v=X0btMjXEXgc (https://www.youtube.com/watch?v=X0btMjXEXgc)
As I think I mentioned earlier, I won't be back home until late this week, so give me a bit of time to actually get the build scripts and necessary code modifications prepared and uploaded. But I hope to have them ready by mid to late next week!
-
Okay, the video just went up!
https://www.youtube.com/watch?v=X0btMjXEXgc (https://www.youtube.com/watch?v=X0btMjXEXgc)
Very good presentation, and quite an achievement!
I suggest we add a new board/area for this topic eg. "LOS Source" or "Building LOS from Source" or something else suitable of your choice.
Thanks for all your hard work and the immense amount of time; I'm looking forward to flagging the bounty challenge as awarded!
-
Alex, that is awesome! Nice work 8)
Thank you! I hope you enjoy the (rather long) presentation!
Does Al Kossow know about your (amazing, inspiring) work? I know at one point he was complaining that he did a ton of work to get the Lisa OS source released, and then it seemed like no one did anything with it. I think he would be very happy to hear that situation has been rectified!
-
Congratulations again --- I wish the video had been twice the length! You really had to figure out puzzle after puzzle to get this thing to build. I'd love to hear more about some of the fixes mentioned in the talk, particularly the Y1.995K problem fix, but this can all come in good time.
-
Thank you all!
I suggest we add a new board/area for this topic eg. "LOS Source" or "Building LOS from Source" or something else suitable of your choice.
Good idea, I like "Building LOS From Source" but anything to that effect would be great!
Does Al Kossow know about your (amazing, inspiring) work? I know at one point he was complaining that he did a ton of work to get the Lisa OS source released, and then it seemed like no one did anything with it. I think he would be very happy to hear that situation has been rectified!
No idea if he does or not, but he is a member on this forum, so he's almost certain to find out eventually. Al, if you're reading this, then I'd love to hear your thoughts!
Congratulations again --- I wish the video had been twice the length! You really had to figure out puzzle after puzzle to get this thing to build. I'd love to hear more about some of the fixes mentioned in the talk, particularly the Y1.995K problem fix, but this can all come in good time.
Yeah, I wish we had more time for the presentation; fitting it all into an hour and a half was a massive challenge. It was indeed puzzle after puzzle, and I omitted many of the finer details and smaller problems I encountered for the sake of time.
The good news is that I was capturing video from the Lisa throughout the entire process using an RGBtoHDMI and narrating things as I went, so I'm hoping to edit down the over 1000 hours of footage into a series of YouTube videos that document the process as it occurred in real time. Hopefully it's not too boring given that it would include every single little thing that I did along the way, but at least everything would be fully and thoroughly documented!
-
i'm searching for packseg right now.
---
well, after several hours I realized it is a tool in the workshop, and the workshop wasn't included in the binder with the source disks
and I suspect all of the copies of workshop that have been found were from the Mac dev environment which didn't include it :-(
the right version of the workshop pre Mac used for building Lisa is incredibly difficult to find.
-
i'm searching for packseg right now.
---
well, after several hours I realized it is a tool in the workshop, and the workshop wasn't included in the binder with the source disks
and I suspect all of the copies of workshop that have been found were from the Mac dev environment which didn't include it :-(
the right version of the workshop pre Mac used for building Lisa is incredibly difficult to find.
Thanks for searching, hopefully you eventually run across a copy! It's a shame that the pre-Mac version of the Workshop is so hard to find. But I take this to mean that you do actually have the source code to some version of the Workshop at the very least?
-
Thanks for searching, hopefully you eventually run across a copy! It's a shame that the pre-Mac version of the Workshop is so hard to find. But I take this to mean that you do actually have the source code to some version of the Workshop at the very least?
I interpreted it as: the binary workshop distribution used to compile the Office System is hard to find or to recreate.
This said, I had a look at LISA_OS/OS/source-UNPACK.TEXT.unix.txt, and while it has a lot of buffer juggling going on (and although I'm not certain that this is the correct file), the algorithm there does not strike me as being very complicated. I think it works something like this:
Loop until finished:
Load a "flag byte" from the compressed input
For each bit in the flag byte:
If the bit is empty:
Copy two bytes from the compressed input to the decompressed output
If the bit is set:
Load one byte from the compressed input
Use that byte as an index into a table of "common" two-byte words
Copy the word at that index to the decompressed output
There is some accommodation for if the decompressed data is not made of an even number of bytes, plus the buffer juggling I mentioned. I'm probably missing things. Still, I think it might be possible to write a PACKSEG of our own. Note that PACKSEG will probably need to have access to (or will need to create) a file holding the "common word" table; the scripts in the source code appear to call this file packtable.lib.
-
I interpreted it as: the binary workshop distribution used to compile the Office System is hard to find or to recreate.
I think you're right; I just interpreted it wrong.
This said, I had a look at LISA_OS/OS/source-UNPACK.TEXT.unix.txt, and while it has a lot of buffer juggling going on (and although I'm not certain that this is the correct file), the algorithm there does not strike me as being very complicated. I think it works something like this:
Loop until finished:
Load a "flag byte" from the compressed input
For each bit in the flag byte:
If the bit is empty:
Copy two bytes from the compressed input to the decompressed output
If the bit is set:
Load one byte from the compressed input
Use that byte as an index into a table of "common" two-byte words
Copy the word at that index to the decompressed output
There is some accommodation for if the decompressed data is not made of an even number of bytes, plus the buffer juggling I mentioned. I'm probably missing things. Still, I think it might be possible to write a PACKSEG of our own. Note that PACKSEG will probably need to have access to (or will need to create) a file holding the "common word" table; the scripts in the source code appear to call this file packtable.lib.
I thought about doing this, I just decided against it for the time being since I was already in a massive time crunch to get things done in time for VCF anyway. But you're right, that's a pretty simple algorithm to implement!
-
Regarding licensing issues... I am definitely not a lawyer, but just looking at those terms:
- redistribute, publish, sublicense, sell, rent or transfer the Apple Software;
- publish benchmarking results about the Apple Software or your use of it;
- use the name, trademarks, service marks or logos of Apple to endorse or promote your modifications or other materials derived from the Apple Software.
Obviously, you can't distribute the source itself, but as blusnowkitty mentioned previously, you could publish diff patches of some sort the way ROM hackers do. However, the last two terms seem designed to prevent any human collaboration which could actually be used to further development of the LOS software, let alone optimizing the current version of it.
The term regarding benchmarking results seems like it could be used to broadly prohibit publishing information about how modifications have improved the software, which could cover just about any kind of documentation, release notes, etc.
Apple also doesn't want you using any of their trademarks/logos, etc. to promote the software modifications. That seems like it would prevent someone from even saying a LOS software patch is actually intended to be used for the Lisa in the first place, Lisa being a trademarked term.
It seems like, effectively, people cannot directly refer to the system a LOS patch is for, nor can people explain how an LOS patch improves the software. What are we even left with after that?
-
However, the last two terms seem designed to prevent any human collaboration
Interesting take...
If that was indeed the intent, I would expect them to oppose publishing any modifications, which isn't specifically prohibited even though modifications are mentioned as being allowed/expected.
My interpretation of the last phrase is to prevent misrepresenting eg. a modification as coming from Apple, and/or Apple being responsible for it; this topic of not mis-representing your own work as coming from the licensor is common in developer agreements.
I suppose the term "benchmark" may be ambiguous. Although one might lose in court, I think the public would consider publishing a bug fix or new feature, which permits "x" to function in some way that is functionally different from the standard, isn't the same as a benchmark result, which would typically be regarding some kind of 'performance' as a metric. I think this would be worded differently if they meant that one should not discuss the effect of a modification in general.
My impression from the wording is that they don't want 'embarrassing' comparisons of how the code could have been improved in speed or size. I can imagine this coming up in the boardroom where they are discussing the pros and cons of releasing old source code. Is finding an easy fix to a bug the same thing? Maybe, maybe not.
So my current thinking is that I would not be reluctant to publish details of a modification to fix a bug or add a feature, assuming it is done without re-publishing the source code.
Obviously we ought to sort out this issue as best we can, so further thoughts, opinions, and discussion would be helpful.
Ancillary thought: AFAIK, Lisa and the Lisa Logo are not actually trademarks. In general, they aren't accompanied by the informal trademark symbol "TM" or the registered trademark symbol "circle-R", although perhaps they are in some isolated literature.
-
However, the last two terms seem designed to prevent any human collaboration
I suppose the term "benchmark" may be ambiguous. Although one might lose in court, I think the public would consider publishing a bug fix or new feature, which permits "x" to function in some way that is functionally different from the standard, isn't the same as a benchmark result, which would typically be regarding some kind of 'performance' as a metric. I think this would be worded differently if they meant that one should not discuss the effect of a modification in general.
The term benchmark is what worried me the most - it stuck out to me as an odd thing to be against. A modified version of LOS has the obvious advantage of 40 years of hindsight, to say nothing of the kinds of pressures and deadlines the original developers were faced with. At least in my opinion, it seems like there are a lot of understandable reasons why there's room for optimization. I'm also reminded of Kaze Emanuar's optimizations of Super Mario 64; using the source code, he's made many substantial performance improvements to that game, and I don't think anyone would look at those and have a poorer opinion of the original SM64. Also, that source code was leaked!
Given the more general definition (from my Mac's dictionary, of all things) of the word "benchmark":
a standard or point of reference against which things may be compared or assessed
That to me seems like a way for Apple to prohibit the release of modifications without directly saying so. Perhaps they are less worried about benchmark comparisons and more worried about their own corporate image; perhaps releasing it with an explicit declaration against modification might make them appear user-hostile or re-enforce the perception of Apple as a large conglomerate. Typing that now, it sounds as equally dubious to me as a concern about benchmarking 40 year old software, but I'm sure anyone who's been following Apple's current legal escapades is aware of their tendency to frame themselves as much smaller than their competitors. Certainly now more than ever, they are desperate to avoid the external appearance of being overly controlling - this wasn't as big of a deal a couple years ago of course.
I guess the exact reasoning can only be speculated on without more direct insight.
Naturally, I don't like the thought of any of this; I'd love to see open development of Apple's old OSs as much as anyone else here.
-
The term benchmark is what worried me the most...
Given the more general definition (from my Mac's dictionary, of all things) of the word "benchmark":
a standard or point of reference against which things may be compared or assessed
The interpretation "bug fixed" vs the point of reference of "bug not fixed" as being a "benchmark result" seems valid enough in the literal sense.
That to me seems like a way for Apple to prohibit the release of modifications without directly saying so.
Perhaps it is intentionally vague, not so that they can catch someone out, but rather they have the option of suppressing something bad that arises which they hadn't anticipated.
Back to the actual phrase
"publish benchmarking results... "
I think publish involves making it publicly available, so it may be sufficient to put bug fixes, new features, and other items potentially covered by the broadest interpretation of "benchmark results" in a restricted/private area; requiring some kind of agreement/test for admission to establish that it is clearly not public.
Presumably there is a recognized way of ensuring that something accessed via the internet is not considered public... someone know offhand?
-
Okay, the video just went up!
https://www.youtube.com/watch?v=X0btMjXEXgc (https://www.youtube.com/watch?v=X0btMjXEXgc)
As I think I mentioned earlier, I won't be back home until late this week, so give me a bit of time to actually get the build scripts and necessary code modifications prepared and uploaded. But I hope to have them ready by mid to late next week!
Just finished this video and continue to be super impressed with your efforts and success. You guys should be super proud of what you managed to do here. Looking forward to what's to come!
-
Just finished this video and continue to be super impressed with your efforts and success. You guys should be super proud of what you managed to do here. Looking forward to what's to come!
Thank you James!
-
The term benchmark is what worried me the most - it stuck out to me as an odd thing to be against.
I'm not a lawyer and this isn't legal advice; in fact, it's not really advice at all.
My familiarity with big tech companies like Apple, however, is that attorneys cost money and are as underprovisioned as any other job role at the company. They will be busy and they will have loads of different people from all different departments asking them to please, please just take a look at this one thing, or review this one launch, or check this policy or approve that one contractor agreement and so on and so on for all time. Everything will be immediate and urgent because some product manager didn't realise that it was necessary to get legal review and $DEADLINE is right around the corner, or because some tech lead is gunning for promo this cycle and that means it is 150% time to launch ASAP so let's get legal to tick the box right now please and thank you. Everyone who talks to you, some Associate Counsel with an employee ID in the low millions, has the most startling and unusual crisis that absolutely must be dealt with right this second.
Therefore it will have been an achievement that the review necessary for this source release, which does very little to advance Apple's most pressing business aims, happened at all; I suspect some arms needed to be twisted in order to get anyone to think about licensing terms for a 40-year-old operating system for a rare computer that has very little relationship, practically speaking, to any of Apple's modern products. And, when someone finally did, I wouldn't necessarily have expected them to have put their absolute heart and soul into the job; it might have been fun to do something different for a change, but that product manager and that tech lead are still pinging them incessantly, and the PM has started muttering about "escalating"...
What I'm saying is that although the clauses are for sure legally binding (assuming the relevant authorities to you will consider them lawful; speak to your lawyer), they may not represent some profound, deeply thought-out plan or some specific attitude that Apple bears toward the Lisa Office System or its community of fans. Ambiguity or puzzlement may be a byproduct of the circumstances under which the agreement was composed. That doesn't mean that Apple's lawyers can't take advantage of that ambiguity later if they decide they want to ding you for sticking your neck out and comparing your improved task scheduler against the one that comes with the OS, but to my mind it means that the peculiarity itself may not really be a useful hint about Apple's motives.
Why does Apple not want you to "benchmark" and what does that mean? I don't really know. But I can't think about it without remembering that attorneys at tech firms cost money and are constantly being bothered to focus on work relating to important, imminent problems that relate pretty directly to the company's bottom line.
-
But I can't think about it without remembering that attorneys at tech firms cost money and are constantly being bothered to focus on work relating to important, imminent problems that relate pretty directly to the company's bottom line.
I don't doubt this... I was just offering my thoughts is all, given that both now and even a couple years ago when the code was released, people have been especially concerned about the restrictiveness of this license.
And with all due respect to Apple and all honesty, regarding entirely obsolete 40 year old code for which no amount of development could remotely create anything that would cannibalize Apple's existing revenue sources, in my opinion this license is probably irrelevant so long as people don't start selling copies of rebuilt Lisa software. The code is out there, and many people are going to scroll past the agreement, check the box, and then copy it, share it, and disregard the license entirely. One way or another, the cat is out of the bag.
-
Finally finished watching the Recompiling the Past talk. It really is impressive how you guys managed to accomplish this without going insane.
I appreciated the masterful artistry of the redrawn icons! It's also interesting to know what that file cabinet drawer in the desktop manager icon font represented.
That comment, in the preferences window? I don't think it's a reference to anything. Rather, the programmer who wrote it must have been driven past the point of insanity. Who knows if it was because of the preferences window in particular... although it does have a large amount of UI elements interacting with many different parts of the system. I almost went crazy trying to make a recreation of it in my JS project.
-
That comment, in the preferences window? I don't think it's a reference to anything. Rather, the programmer who wrote it must have been driven past the point of insanity. Who knows if it was because of the preferences window in particular... although it does have a large amount of UI elements interacting with many different parts of the system. I almost went crazy trying to make a recreation of it in my JS project.
Yeah, I guess so! I looked it up online and the only mention of that text was from someone else who found it in the source code, so it's got to be something original from the programmer. And awesome work with LisaGUI by the way; it's a really impressive project!
-
Forgive me if it was mentioned, but aside from using video capture instead of the CRT, did you have to take any extra measures to keep the Lisa(s) cool while you were transferring files and compiling code for hours on end? Or was it even an issue? I'm honestly afraid to keep my own 2/10 turned on for too long.
it's a really impressive project!
Thanks! :)
-
Forgive me if it was mentioned, but aside from using video capture instead of the CRT, did you have to take any extra measures to keep the Lisa(s) cool while you were transferring files and compiling code for hours on end? Or was it even an issue? I'm honestly afraid to keep my own 2/10 turned on for too long.
Since I didn't need the CRT, I was using the card cage outside of the Lisa chassis, with the motherboard edge connectors hooked to a breakout board that allows me to connect power, floppy, video through the RGBtoHDMI, and so on. And having the card cage open to the air like that instead of being constrained inside the Lisa already helps with cooling a great deal. Nothing felt like it was getting too hot (and I only had 2 hardware failures throughout the whole process, neither of which was related to overheating or to this project), so I just left it alone!
-
did you have to take any extra measures to keep the Lisa(s) cool
This is a really good point for this topic... building LOS is going to be stressful!
I suggest a fan drawing air through the power supply is the most critical thing for extended use.
Next would be turning down the brightness to minimize burn-in, and not use a vintage spinning disk (eg. disconnect your 2/10's widget if still installed and use an emulator).
Beyond that, you could remove or elevate the rear of the top cover for better cooling of the flyback and video board, and add a card-cage fan similar to the XLFan (https://lisalist2.com/index.php/topic,271.0.html) intended for the faster XLerators.
Since the Lisa was designed for convection (fanless) cooling, it doesn't take much additional airflow to make a substantial difference. Quiet fans are sufficient.
-
I suggest a fan drawing air through the power supply is the most critical thing for extended use.
I don't think I mentioned this, but I used an ATX power supply as part of my breakout board setup, so I didn't even consider cooling the original Lisa supply. But yeah, that's certainly a really good idea!
Next would be turning down the brightness to minimize burn-in, and not use a vintage spinning disk (eg. disconnect your 2/10's widget if still installed and use an emulator).
Yeah, you do NOT want to be using a spinning disk for this. For one, the code alone takes up over 20MB, and grows to fill up a 32MB volume after you've compiled everything. And also, you'll want to make frequent backups in case things go wrong and corrupt your OS install or filesystem, which has a decent chance of happening, especially if you're messing around with SYSTEM.OS, the configurable drivers, or the libraries. And backups/restores are much quicker and easier on an emulator (just choose the Copy option in the Selector if you have a Cameo/Aphid, ESProFile, or ArduinoFile) than they are on an actual disk!
-
Has anyone tried any of the Notca fans as a replacement for the built in fan? They are supposed to be very quiet.
-
Has anyone tried any of the Notca fans as a replacement for the built in fan? They are supposed to be very quiet.
The only original fan is under the widget, and it doesn't effectively cool anything else in the Lisa (such as the PSU). Those with a stock Lisa 1/2 without a Widget will find it doesn't have any fans.
While the Noctua fans are very good, inexpensive fans have improved a lot and low cost quiet fans (with low airflow) are adequate for this purpose IMHO.
I suppose if your room temperature is high then you might want a medium speed fan.
-
Sorry that it's taken a bit longer than originally promised, but I think I've gotten everything to a place where the documentation and build scripts are ready to release now! I'm just waiting on a friend of mine to proofread the readme for me, and then I'll make it public!
-
Sorry that it's taken a bit longer than originally promised, but I think I've gotten everything to a place where the documentation and build scripts are ready to release now! I'm just waiting on a friend of mine to proofread the readme for me, and then I'll make it public!
Alex - In your video I believe you mentioned needing to patch LisaEm to work around some issues. Any chance you could provide a diff of those changes so we might get things patched up?
-
Alex - In your video I believe you mentioned needing to patch LisaEm to work around some issues. Any chance you could provide a diff of those changes so we might get things patched up?
Absolutely! The patched glue.c will be included along with all the other stuff that I'll be releasing, hopefully within the next day or two. But I've also attached it here in case you don't want to wait. Basically, it's just hard-coding the check_running_lisa_os() function to always recognize the running OS as LOS 2.0/3.0 and sets the mouse scaling accordingly.
-
Sorry for the big delay, but I've finally gotten things ready to go! Just go to the following GitHub repo, and that should give you all the info you need to compile LOS for yourself! And of course let me know if you've got any questions!
https://github.com/alexthecat123/LisaSourceCompilation (https://github.com/alexthecat123/LisaSourceCompilation)
Enjoy!
-
Sorry for the big delay, but I've finally gotten things ready to go! Just go to the following GitHub repo, and that should give you all the info you need to compile LOS for yourself! And of course let me know if you've got any questions!
https://github.com/alexthecat123/LisaSourceCompilation (https://github.com/alexthecat123/LisaSourceCompilation)
Enjoy!
(https://media1.tenor.com/m/yz98kRcOqXsAAAAd/clap-clapping.gif)
-
Wow, thanks for the comprehensive write-up! I thought I'd give it a quick look, but now I've set it aside to peruse later at leisure :-)
-
I thought I'd give it a quick look, but now I've set it aside to peruse later at leisure :-)
I see what you did there!
-
Enjoy!
I'm delighted that it is such a detailed, almost tutorial level description, and I'm very impressed at the amount of work invested; I really did not expect to see success so soon, and expected the accomplishment to require many more contributors. Thank you!
I wonder if we can find a PACKSEG binary on one of the earlier workshop versions... perhaps it is practical to search the DC42 images for clues instead of having to install each one?
-
I'm delighted that it is such a detailed, almost tutorial level description, and I'm very impressed at the amount of work invested; I really did not expect to see success so soon, and expected the accomplishment to require many more contributors. Thank you!
Thank you James! It took nearly 6 months from start to finish, but it was a whole lot of fun and I learned way more about the Lisa OS than I could've ever imagined. I always try to write really detailed readmes for anything that I put on my Github, and this was no exception. Making the build process accessible to as many people as possible was one of my top priorities!
I wonder if we can find a PACKSEG binary on one of the earlier workshop versions... perhaps it is practical to search the DC42 images for clues instead of having to install each one?
Hmm, that's actually a good idea. I don't believe that I ever checked Workshop 1.0 to see if it included binaries, although I'm fairly sure that I checked 2.0 (and of course 3.0). One thing that I did check, however, was all the random Lisa images on Bitsavers, and I was able to find two copies in two of the Monitor images. But it seems that they were built using an older executable format that the Workshop can't recognize (and used much older versions of the system libraries too), so I couldn't get them to run on the Workshop after extracting them and moving them over to my Workshop disk image.
-
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
-
I thought I'd give it a quick look, but now I've set it aside to peruse later at leisure :-)
I see what you did there!
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 (https://github.com/stepleton-xx/lisabbs). I wouldn't advise trying to adapt this program, but I would suggest that the LIBPORT library (https://github.com/stepleton-xx/lisabbs/blob/master/LIBPORT.TEXT) 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 (https://bitsavers.org/pdf/apple/lisa/toolkit_3.0/Package_2_Examples/17_Lisa_Development_System_Internals_Documentation_Feb84.pdf)). 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 (https://dos2unix.sourceforge.io/) 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 (https://bitsavers.org/pdf/apple/lisa/workshop_3.0/Release_3.0_Notes_for_the_Operating_System_Reference_Manual_for_the_Lisa.pdf) ref2 (https://bitsavers.org/pdf/apple/lisa/workshop_3.0/Workshop_Users_Guide_3.0_Release_Notes.pdf). (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 (https://github.com/alexthecat123/LisaSourceCompilation?tab=readme-ov-file#all-the-files-that-form-an-losworkshop-installation) 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!
-
Wow, thanks for all the feedback!
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.
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!
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.
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.
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.
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.
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!
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!
-
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.
-
Is there anything stopping us from running the Workshop with say, an XLerator or something like it?
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?
-
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. :)
And given that I'm about to start grad school, it may be quite a while (if ever) before I get around to starting on something like that!
Perhaps LisaEm is ultimately the best solution?
LisaEm works pretty darn well and can build everything in about 10 minutes when clocked at 512MHz. The only issue is that it crashes a lot, which can be pretty infuriating and will often corrupt your disk image.
The thought of leaving my Lisa on for hours on end compiling code at 5MHz gives me a bit of a shiver.
Sure, it's about 9 hours the first time around, but just remember that you'll really only need to do that once. After that, you'll just be rebuilding whichever components you're making changes to, which will be significantly quicker. For instance, the OS itself only takes 45 minutes, and each of the applications is 45 minutes or less. Many of the libraries are quicker than that, at about 10-15 minutes each.
And for what it's worth, I've left my Lisa on for at least 1000 hours throughout this project, and it's handled everything flawlessly! Not to say that your experience will be the same, but I've been impressed by the reliability of everything.
-
Wow amazing work Alex!!!