LisaList2
General Category => LisaList2 => Topic started by: stepleton on January 19, 2023, 10:34:38 am
-
On this heavy occasion it is worth pointing out that the source code to the Lisa OS and the Office System application suite is now available at the Computer History Museum website.
https://computerhistory.org/blog/the-lisa-apples-most-influential-failure/
I think I recall hearing that LisaEm was helpful for its preparation, and it would be nice to hear about that if it was. Even if not, it will be a useful tool for exploring the OS in the future.
-
Thanks Al! This is going to be interesting to dig into.
Looks like the Twiggy driver was still in the source, so maybe we can run Office System 7/7 on a Lisa 1?
There's another piece of source - SOURCE-STARTUP I think - making reference to Office System 3.1 being internally versioned as 13.3.1.
SOURCE-NWSHELL looks like an interesting artifact from the early days. Anyone know anything about "UltraDOS Shell?"
The desktop shell is under /APDM and apparently was known internally as LisaDesk.
Environments window is under /APEW. Also references the Pepsi system at least once.
The OS installer is under /APIN. APIN-OFFICE.TEXT has some fun comments! Pepsi is referenced multiple times, and the comments also imply it was/is possible to restore the system from a Priam tape drive? This directory's also got a bunch of fun internal tools used to actually generate the installer disks.
/APLC and /APLD are LisaCalc and LisaDraw, respectively, and wow, these are some giant programs.
-
Just downloaded it too. Now we can figure out how the file systems worked. :-)
Thanks, Al!
Note for Mr. Hsu's article: the spelling for "stationery pad" is with an e in stationery.
-
The definition of the MDDF disk header is found in LISA_OS/LIBS/LIBOS/libos-bless.text.unix.txt
Each field name is present, with comment on its purpose.
Also check out LISA_OS/OS/source-scavenger.text.unix.txt
-
I'd be interested to know how intrinsic libraries are created. I know there's some documentation about this if you look for it, but I don't think there's the full picture. We should now have a full example.
I wonder if there's any special reason why Apple didn't want people to know --- most likely is they just didn't get around to telling, but maybe they also wanted to avoid DLL hell.
Last one to implement a TCP/IP stack is a rotten egg!
-
As I click thru these mostly Pascal source files I'm blown away by how the big picture of Lisa is that it was a prototype of Macintosh. Macintosh in a large way was a refactoring of Lisa sources in Pascal to 68000 assembly. So many of the concepts are direct translations or borrows from Lisa-- far more than is common knowledge.
-
LIBHW-LEGENDS is very interesting too. Header says it's assembly glue to the keyboard. We know that there was a US, French, German, and I think one other keyboard language that was released but it seems there were at least prototypes of keyboards in UK, Italian, Swedish, Swiss German, Spanish, Dutch, French Canadian, and Danish. LIBHW-KEYBOARD also says there was a DVORAK layout?
We've known for a while that the Lisa's mouse port was wired for up to three buttons, but only one was used in the end. Someone on here wondered what would happened if you wired in the other two buttons, and according to LIBHW-SPRKEYBD, nothing will happen. LIBHW-CURSOR (or was it LIBHW-MOUSE) says you can load your own mouse driver, though.
LIBHW-SPRKEYBD also implies we could have had three Sony drives?! SOURCE-SONY implies we could have had an internal and an external drive like the Mac at the very least. Currently the ext_drive_cb struct hardcodes the Sony driver to only a single internal disk drive.
SOURCE-HDISK's header says you can have a Profile up to 32MB! And it tells you where to go (SOURCE-PROFASM) if you want to have a disk larger than that! SOURCE-FS* appears to be everything related to the Lisa's filesystems. SOURCE-FSPRIM suggests that the copy protection ("theft protection") is handled at the filesystem level?
master_machine_id, serial_no, "protected master" and the word "theft" might be good strings to grep if one wants to neuter the copy protection in software.
LIBPM-PMDOC has some interesting devices in the CONST table - apparent support for a modem, something called a Marksman that may have changed to Priam, the AppleNet card, Corvus which is also marked as may change to Priam, and a laser printer.
/LIBSB and /LIBWM may be the window manager...?
-
Remember there's photos of a "3 Port Card" floating around.
A friend also has a card which IIRC has a Twiggy, and Sony interface on it. I'll ask him to get a photo.
-J
-
A while ago I made somewhat of a joke thread about the Lisa "Pepsi" system, and we weren't quite sure what Pepsi actually was. I think the source drop pretty much confirms that Pepsi was the codename for the 2/10. There was also this find:
./LISA_OS/OS/SOURCE-CD.TEXT.unix.txt: iob_twiggy = -1; {Pepsi, BUT with twiggies}
Now this I'd like to see!
The Whopper, on the other hand, there are only two explicit references to the Whopper. Whopper probably never got too far away from the original Lisa design before the entire system was cancelled. I can find no references to the GLM at all with a simple grep.
-
To figure out what Pepsi referred to as well, and it looks like part of it is a new I/O board.
In this article (https://macgui.com/news/article.php?t=518) I wrote that Pepsi was the code name for a Lisa 2 with Sony drive. Source code notes from today's release show that Lisa Team were working with Sony drive since at least September 1983.
-
So, based on the license Apple put this under, if we make modifications to the code are we allowed to share them?
The benchmarking line makes me think we can't even talk about using LOS??
-J
-
So, based on the license Apple put this under, if we make modifications to the code are we allowed to share them?
Well, check out section 2 where it begins "If you create modifications of the Apple Software,..."
The benchmarking line makes me think we can't even talk about using LOS??
Would be good to have a clarification on this point.
-
This is especially bittersweet. Had Ray had access to this code would it have helped him with the development of LisaEm? I presume this will at least make software development for the Lisa easier in the future.
-
This is especially bittersweet. Had Ray had access to this code would it have helped him with the development of LisaEm? I presume this will at least make software development for the Lisa easier in the future.
It's beyond question: yes, immensely.
-
We know that the Lisa's underlying OS had a primary screen, where all of the pretty GUI magic happened, and if you installed the Workshop, you'd have a secondary screen where you could dump your debug output. At a cursory glance, it appears as if the secondary screen is in memory at all times whether or not you're debugging a program. More worryingly, it looks like every single piece of code - OS, drivers, LisaDesk/Filer, Lisa applications - just dumps loads of debug WRITELNs (pascal's printf?) to the secondary screen whenever anything happens, and none of it appears to be #ifdef'd out. Maybe that's another reason why the Office System is so slow, every time you click the mouse button it prints a debug statement to the debug screen!
Trying to find an old post of mine now, one time I had something in the OS crash so hard it printed the crash/debug messages to the primary display instead of throwing up a "The Lisa is having technical difficulties" dialog. I want to grep that and see if I can find that in the source anywhere...
-
Worth noting that the ToolKit documentation talks about being able to switch to the screen with that debug output --- IIRC with the help of an extra menu that pops up for suitably compiled programs or something like that. I remember thinking that the debugging facilities for ToolKit programs sounded considerably more powerful than I'd expected.
-
More worryingly, it looks like every single piece of code - OS, drivers, LisaDesk/Filer, Lisa applications - just dumps loads of debug WRITELNs (pascal's printf?) to the secondary screen whenever anything happens, and none of it appears to be #ifdef'd out. Maybe that's another reason why the Office System is so slow, every time you click the mouse button it prints a debug statement to the debug screen!
How much faster do you think an optimized Office System 3.2 would end up being just from that alone? There must be other fixes and optimizations just waiting to be discovered here.
-
I have two questions:
1. Did the dump include the Pascal Workshop and/or any of the compilers? If not, what are we missing?
2. Do we have enough to do a fresh build of the OS? I would be more than happy to work on an Office System 4 release if anyone's interested in that. (Stuff like Y2K support would be nice, as I recall the Office System doesn't have it)
-
1. I don't think so, but Al Kossow found some related bits and mentioned them in this thread: https://lisalist2.com/index.php/topic,348.15.html
I haven't looked too closely at what's in some of the shared archives, but I wouldn't be surprised if creature comforts like the Workshop shell and the editor are missing. I'm not sure whether the code generator, linker, or assembler are there either, not to mention various libraries.
2. This is unknown! But I think lots of folks would love to find out if it's possible.
-
There are no Workshop components other than the toolkit 3.0 sources in what was released.
Also, I pushed out the rest of what I have on Lisa 1.75 this morning. It looks like the project was
abandoned when Pepsi started and Twiggies were killed. The Pepsi codename obviously comes from Sculley
who started Apr, 1983
-
Honestly, I think the source code drop might be more useful as a tool for a C rewrite. The Workshop is so difficult to use, and who even understands Pascal anymore? With the supporting LisaEm tools I think it'd be feasible to do a C rewrite targeting gcc/llvm; maybe keep the assembly bits as they are since they're going to be the most optimized bits of code we have.
-
who even understands Pascal anymore?
Hey now! (https://lisalist2.com/index.php/topic,352.0.html)
Pascal is not a very complicated language: there are not very many language constructs to know about, and the language was made with clarity in mind, to the point where the programmer (in my very limited experience) sometimes wishes they could be more subtle but has no option for it. I think a relatively experienced coder could be pretty much ready to go with Pascal in a couple of days.
I would expect the job of learning Lisa OS interfaces and concepts to be about the same in any language.
None of this is to say that an rewrite targeting GCC/LLVM wouldn't be amazing (I think you'd need a custom backend to do Lisa-specific things like the TST.W trick before allocating space on the stack). But I guess if I had to bet on the one thing that would accelerate Lisa development based on this source code at this stage, it's finding a way to host the files on a modern computer and treat an encapsulated LisaEm instance there as a build system/compiler: if you want to build a new OS, you start some kind of LisaEm+workshop container (running at 160x or whatever) that compiles the source, writes the output back to the modern computer (or to a disk image), and shuts down.
-
I had hoped MAME would have been farther along by now than it is, because of the integrated debugger.
Pretty much everything is known, albeit very scattered on the runtime system to bootstrap a different shell in place of the one in the workshop or to rewire the I/O system to pipe it out to a system running the emulator.
Also, the sources to lisabug are up (sort of) as part of the things I just put up for the YACC
http://bitsavers.org/pdf/apple/mac/prototypes/1985_YACC
-
Something fun to do would be an intelligent network card that had the whole IP stack on it and wire it into the OS with a remote procedure library. Something a little more sophisticated than the Unibone for PDP-11 computers.
-
There are no Workshop components other than the toolkit 3.0 sources in what was released.
Al, any chance we'll ever get Workshop and/or compiler source releases? I'm incredibly grateful for all your hard work in securing what we have, make no mistake!
Re: Pascal. Some people on here might not be aware, but the excellent FreePascal compiler has a Mac Pascal compatibility mode. I've been exploring the possibility of "porting" LisaOS to a new abstraction layer (would require a rewrite of QuickDraw and other assembly-written portions of course) that could run as an application on Linux or something like that.
-
Re: Pascal. Some people on here might not be aware, but the excellent FreePascal compiler has a Mac Pascal compatibility mode. I've been exploring the possibility of "porting" LisaOS to a new abstraction layer (would require a rewrite of QuickDraw and other assembly-written portions of course) that could run as an application on Linux or something like that.
Something like this was actually the reason I wrote the Clascal grammar for the compiler project I mentioned elsewhere --- instead of aiming for binary compatibility, I was wondering if it might be possible to achieve source compatibility for ToolKit apps that would compile to Python.
The python code itself wouldn't aim to be usable in other Python applications: instead, the Python interpreter would behave like an extremely CISCy microprocessor, with compiled subroutines/objects/methods using a large array of bytes (a megabyte or two) as a stand-in for the Lisa's RAM. Pointers would work in this scheme: they'd just be array indices. Integers in the array would be stored in the "RAM" in big-endian order, just like in the Lisa: in fact, the idea would be to try to store all user-defined "stack" and "heap" data in the same way that the Lisa would store them.
The hope is that this would be a development aid for people who wanted to write new ToolKit applications (for you see I would have written a runtime that recreated the ToolKit as well): if it compiled and worked under this system, then you could be reasonably confident in it compiling and working on the real Lisa.
Naturally this would have been a huge undertaking, but the pandemic had not been going for very long by then and who knew how long we were going to be cooped up at home? Anyway, we got as far as the parser.
-
Yeah for sure. I think the fact that we have access to the source now means that trying to get it work under FreePascal would be the way to go. I would be, if nothing else, a very neat hack to have 40 year old code running as a native application on a modern OS. I am reasonably certain that Clascal should compile under MacPas mode with FreePascal. The harder part is doing e.g. the QuickDraw rewrite.
-
Al, any chance we'll ever get Workshop and/or compiler source releases?
I found the pascal compiler source on some floppies I had along with a few other things.
http://bitsavers.org/pdf/pascal_monitor/floppy
I'm waiting to see what happens in the future WRT Apple and future code releases.
Lisa was a much bigger deal than the previous code drops and there hasn't been any
official reaction from Apple. I'm hoping to be able to talk to some people in person
at the CHM event on the 31st.
One of the important things to think about is what is going to be done with this code.
If people just carve it up or publish fgreps of how many times 'fuck' appears in it
it is going to be really hard to justify why they should release more.
-
Yeah for sure. I think the fact that we have access to the source now means that trying to get it work under FreePascal would be the way to go.
The point was getting a historical artifact of a complete operating system and applications in source form, not doing some Frankenstein hack to reanimate it on another system in 2023.
I wrote a post that they decided not to run on the 19th coming out on the 24th that explains this.
Personally, I'm disappointed that so far no one has started to make a bugfix list. As far as I know, no one
has said that source patches couldn't be released.
-
Well, doesn't the license say we aren't allowed to discuss or distribute any patches made? :o
I'd love for my understanding to be wrong on this.
If we wanted to start a bug fix / feature request list, would a Google sheet be appropriate?
-J
-
I think a bug fix/feature request list is a great idea :)
I think Y2K support would be an excellent candidate. I'm pretty good with Object Pascal, I'd be more than happy to contribute
-
Here's the start of a bug / feature list. If you want write access to the sheet just ask me.
https://docs.google.com/spreadsheets/d/1bP4ad3zF4Vy0UQ_-CiGT5f5SDYZy13ba3xez9iaGvi0/edit?usp=sharing
-J
-
Can we list "OS has copy protection features" as a bug? :P
More seriously, a good feature to put on the list I think would be to put Twiggy support back in. Maybe look at the Sony driver to see what it'd take to add back in external drive support, that'd be convenient. Maybe add 800k and 1.44MB drive support while we're at it? Though I don't think the original IWM can do HD.
Looking through the Lisa 1.75 docs, there's a reference to someone prototyping a disk drive card that could run Apple II, 871/Twiggy, and Sony drives.
-
Here's the start of a bug / feature list.
Thanks for putting XLerator support on the list of potential features... I've been pondering whether that's of interest for a long while.
Also -- SCSI hard disk driver?
-
On the subject of hard drives, I will echo what I believe others have said, that VirtualBox-style shared folders would be immensely helpful. Obviously, that would require LisaEm support as well.
-
You guys have a lot of exciting ideas, but have any of you started to actually study the source to understand its structure and design?
-
You guys have a lot of exciting ideas, but have any of you started to actually study the source to understand its structure and design?
I think right now we're in the wish list phase...
-
You guys have a lot of exciting ideas, but have any of you started to actually study the source to understand its structure and design?
Eh, there are plenty of things I've dreamed about doing with a computer or with programming that I filed away for years until I decided to mess around with it one day, or until I knew enough about the topic to actually accomplish what I wanted to do. The Lisa isn't going anywhere. So there's plenty of time to dream. (Of course Apple can terminate the license at any point with 30 days' notice, but let's hope they don't :) ).
Once we have a good set of ideas, it may be possible to treat them like a curriculum --- we can do what we guess are the easy ones first and learn as we go to build up to harder and harder ones. For example, maybe Twiggy support isn't so tough and is a good place to start: perhaps it's an artificial limitation where the OS just detects a Lisa 1 and throws up an error, and this check can be defeated.
-
have any of you started to actually study the source to understand its structure and design?
I have spent some time looking at the code for the Priam drivers; partially to help troubleshoot the DataTower I have that no longer works, and partially with the hope that tape drive support can be added to BLU someday (which entails sub-projects of troubleshooting tape drives and drive bands).
Having done so (and having worked on low-level SCSI code before), I'm thinking that writing the code for a SCSI driver is not a huge project. However a big unknown (to me) is how one gets the driver from source code to a binary installed in the OS.
So I agree with the others that have suggested:
- task 1 is being able to compile and install the code as-is, and documenting how to do that;
- task 0 is brainstorming what might be done with this fantastic opportunity -- thanks Al !!
As Al has pointed out, it is crucially important that Apple not regret releasing the code, so an overriding consideration is how Apple may be affected... eg. would they see a SCSI driver as a good thing, bad thing, or neutral/don't care? To me, this isn't a simple question; hopefully Al's upcoming post will help frame this objective.
-
You guys have a lot of exciting ideas, but have any of you started to actually study the source to understand its structure and design?
Pretty sure we're all in agreement the first order of business is to figure out how to get the OS built in the first place, preferably through a more modern environment.
I don't think there is any agreement about that at all AFA doing it in a modern enviroment beyond having it emulated with a decent debugger.
-
You're right, sorry; corrected my post!
-
A while ago I made somewhat of a joke thread about the Lisa "Pepsi" system, and we weren't quite sure what Pepsi actually was.
From APIN-OFFICE.TEXT:
{constants used to check the value returned by the Mach_Info call
(the I/O board part of the record)}
IOlisa = 0; { Old I/O board (lisa) w/Twiggys }
IOpepsi = 1; { New I/O board (pepsi) w/Sonys and Widget }
IOlisaLite = 2; { Old I/O board (lisa) w/Sonys }
IOpepsiLite = 3; { New I/O board (pepsi) w/Sonys, no Widget }
And there we have it. I didn't know a Widgetless 2/10 was called a PespiLite. Better than Diet Pepsi I suppose?
-J
-
Reconnected with Ron this weekend.
Here is a talk where he talks about AppleNet
https://www.youtube.com/watch?v=pFxNwUhL3Wg
-
AppleNet is between 27:15 to 29:35 if anyone's in a hurry, but he goes on to talk about LocalTalk and continues from there through the G5 and beyond. Thanks for the link!
-
Here's another tidbit I saw in source-PROFILE.TEXT
(*Drive types*)
T_Profile = 0;
T_Seagate = 1;
T_Widget = 2;
if (discsize <= 9728) or (discsize > 30000)
then drivetype:= T_Profile (* set drivetype to profile *)
else
if drivetype <> 0 then
begin (*widget*)
remap_interleave := false;
drivetype:=T_Widget;
rvrs_hdr:=20; (*headers are at end of sector*)
end
else
begin (*Seagate*)
drivetype:=T_Seagate;(*10mb seagate*)
(I cut some lines out of this code). So if the disk is exactly 5mb, or over 15mb use the Profile driver. If it's a Widget use that driver, otherwise use the 10MB Seagate (10mb profile??) driver.
-J
-
One thing that I think would be really useful is a Language Service Provider for Clascal, so the Lisa sources can be more easily browsed in tools like BBEdit, Visual Studio Code, and so on.
Also, here’s some stuff I’ve done to my own copy of the sources. (Sorry I can’t share them, I have some employer-related rules I need to follow…)
- Put the sources as-is into a local git repository so I can commit every subsequent change in case I screw something up.
- Get rid of all the Lisa-format text files, since they’ve all been converted to UNIX text.
- Get rid of the “.unix.txt” extensions on all of the UNIX text format files, so they all have “.TEXT” as a suffix again.
- Replace the “.TEXT” suffix where possible with a semantic suffix: “.pas” for Pascal/Clascal code, “.asm” for 68K assembly code, “.exec” for EXEC scripts, “.alerts” for alert definitions, and so on.
Having done all of that I now have a nicely-browsable version of the code that actually gets some degree of syntax highlighting and so on. What LSP would provide is better syntax highlighting for Clascal constructs, as well as being able to jump to definitions and such.
-
...You'd have a secondary screen where you could dump your debug output. At a cursory glance, it appears as if the secondary screen is in memory at all times whether or not you're debugging...
I found the way the alt console is activated is Option + Enter. I haven't observed anything writing to it.
I also found you can add the 3D QuickDraw boxes demo to the Environments window, just copy boxes.obj to shell.Boxes Demo.
-J
-
Something new uploaded to workshop3 on bitsavers
A development system internals guide ca. 1984
that was donated by the author at the jan 31st event
-
Looks like this is the one (the Lisa section is so big on bitsavers now that it can take a while to find things!):
http://www.bitsavers.org/pdf/apple/lisa/workshop_3.0/Lisa_Develpment_System_Internals_Documentation_198402.pdf
Thanks for all the recent additions!
-
Lisa source browser
https://github.com/rochus-keller/LisaPascal
and I see someone has put the sources on github :-(
https://github.com/azumanga/apple-lisa
-
I'm giving a Lisa related talk at VCF East this year, and want to cover the sources. For those that understand the code more than me... are there any tidbits I should cover?
Thanks,
-J