Print

[AlexTheCat123]

The absence of PACKSEG has been really bothering me, and not being able to make a new set of LOS install disks or a LisaGuide disk has felt like a pretty major limitation of my source compilation efforts. So I got to work trying to write PACKSEG from scratch several days ago.

And wow, it's been a lot harder than expected. Partly due to Lisa Pascal's lack of bitwise operators and annoying tendency to treat everything as a signed integer. And partly because of the challenge of figuring out the specifics of the packing algorithm and how the other non-code blocks of an object file have to be updated for packed code.

But as of today, I have a mostly-working implementation going! It's not ready for release yet (I need to clean things up, add comments, and allow the user to specify input/output files instead of hard-coding them), but I've tried it on quite a few executables and it's able to pack them all. It can even produce a bootable packed copy of SYSTEM.OS, so clearly it's working pretty well. I haven't even bothered trying it on an intrinsic library yet, so I bet there will be a bunch of bugs to work out when it comes to writing to the library header blocks, but it works great for executables right now.

I'll keep providing updates as I get closer to having a copy that's ready for release!

[ried]

Alex, do you think it might be found on an early Twiggy disk? I uploaded a pre-release version of Lisa Pascal to the files section this week, for example. Happy to keep digging into old Twiggy disks if there's hope that it might have been included somewhere.

[stepleton]

Congrats! Are you making use of assembly code? If not, I recommend it; for small tasks like bitwise operations, it should be relatively easy to introduce subroutines that are callable from Pascal. Some examples here from earlier projects:

https://github.com/stepleton-xx/lisabbs/blob/master/LIBASM.TEXT (interface)
https://github.com/stepleton-xx/lisabbs/blob/master/LIBASM.ASM.TEXT (asm code)

https://github.com/stepleton/LisaMandelbrot/blob/master/Pro/MANDLIB.TEXT (interface plus some Pascal routines)
https://github.com/stepleton/LisaMandelbrot/blob/master/Pro/MANDLIB.ASM.TEXT (asm code)

[AlexTheCat123]

Alex, do you think it might be found on an early Twiggy disk? I uploaded a pre-release version of Lisa Pascal to the files section this week, for example. Happy to keep digging into old Twiggy disks if there's hope that it might have been included somewhere.

Hmm, whenever I try to list the directory of those disks with lisafsh-tool, they appear to be empty. It might just be a lisafsh-tool bug though. If anybody has a Lisa 1 (or LisaEm configured to work with Twiggies; I've never been able to get it to work) and is willing to look at these disks from the Workshop, let me know if you're able to find anything!

Congrats! Are you making use of assembly code? If not, I recommend it; for small tasks like bitwise operations, it should be relatively easy to introduce subroutines that are callable from Pascal. Some examples here from earlier projects:

I certainly thought about it, but no. Although that's definitely the way that I should've done it. I was initially thinking something along the lines of "this program is going to be so simple that it would feel weird not to write it all in Pascal", and by the time I realized that the program was not going to be quite that simple anymore, I had already written all the assembly-friendly stuff in Pascal. It might be worth going back and rewriting some of that stuff after I've got things fully-working though; I haven't checked the speed of the packing algorithm yet and it might be pretty slow in its current form when not being run at 512MHz in LisaEm.

[stepleton]

Eh, don't do it for speed, do it for fun/learning, says I 
(People are only going to run packseg a few times during a hands-off process and they'll already have arranged other things to do while they wait.)

But what I really came online to say was this:

Code: [Select]

~/Downloads/tmp/Pascal A5+$ ls -l
total 2616
-rw-r--r-- 1 tss tss 892928 Aug  4 02:36 Pascal_0
-rw-r--r-- 1 tss tss 892928 Aug  4 03:49 Pascal_1
-rw-r--r-- 1 tss tss 892928 Aug  4 05:03 Pascal_2
~/Downloads/tmp/Pascal A5+$ for i in *; do echo $i; strings $i | grep -i packseg; done
Pascal_0
Pascal_1
PACKSEG.OBJ
PACKSEG.OBJ
Pascal_2
~/Downloads/tmp/Pascal A5+$ strings Pascal_1 | grep -i pack
UNPACK  Jo
SYSTEM.UNPACK SYSTEM.OS
PACKSEG.OBJ
RAM STRINGMREPE ATMRECORDMPACK"EDMDOWN
PACKEDC
PackedCod
PACKTAB
PackVersion P
Unpacked
zePacked
packed
 SizePack
#TAdev = PACKED RECORD  {Type declaration for "Print Style"}
#TFntid = PACKED RECORD
#TLfntid = PACKED RECORD
#TMpccwid = PACKED ARRAY [TCc] OF TWid;
#TCharstyle = PACKED RECORD
PACKBITSPACKBITS
PACKRGN PACKRGN
UNPACKBIUNPACKBI
#KeyEvent        = Packed Record
 - !Unpacke
PACKSEG.OBJ
File is already packed.
EADPACK
PackTable record in
No PackTable record in
PACKTABLE.LIB
PACKTABLE.LIB
File with Pack Table [
Unpack error
Packing
Total code size packed   
Total code size unpacked
Read Pack Table ? (y/n)
File to pack [.OBJ] -
2Pack Code Segment Utility                 {A5.2.5}
NITPACK
AKEPACK
UNPACK 
NGMREPEATMRECO"RDMPACKEDMDOWN"
UNPACK *PACKM *@PAGEMMWRITELN
Variable cannot be packed field
Fields of packed records cannot be var parameters
Pack and unpack are not implemented
TNOrFd = PACKED RECORD
TARgCHAR = PACKED ARRAY[0..0] OF CHAR;
 TStn = PACKED RECORD ubt: TB; fDirty: TF; fLock: TF; fill: 0..63; END;
+(hdr: PACKED RECORD
8: (fun_field : packed record            (* one integer *)
%Pattern   =  PACKED ARRAY[0..7] OF 0..255;
PACKRGN NV

Obviously references to packed records and other things in there, but it really does seem like this disk contains PACKSEG.OBJ and PACKTABLE.LIB files. (If it doesn't, it used to and then the files were deleted.)

[AlexTheCat123]

Wow, it really does look like the original PACKSEG.OBJ is on there! How cool is that? Thanks @ried for those disk images! I guess all that work was for nothing...

Let me try and see if I can get LisaEm to work with Twiggies one last time. I've got to test that executable and see if it's good!

[AlexTheCat123]

Sure enough, that's the original PACKSEG. And after tinkering around in LisaEm a bit, I was able to test it and it actually works!

Well, it works under that beta version of the Workshop at least. Unfortunately PACKSEG doesn't work under LOS 3 because it relies on some intrinsic units that were present in the beta and not in the Spring release.

So I guess my efforts weren't for nothing after all. I'll keep on working to get my version finished. But regardless, it's really cool to have a copy of the original!

[ried]

Huzzah! I love it when a plan comes together. Cheers.

[AlexTheCat123]

An interesting thing that I somehow didn't discover until now: the Linker can't link a program with a packed intrinsic library file!

Of course, you can execute a program with a packed library after linking, but the linker has no idea how to read a packed library and will give an error if you try.

It turns out that, when you install LOS, it copies over packed copies of all the intrinsic libraries (IOSPASLIB, IOSFPLIB, SYS1LIB, SYS2LIB, QPLIB, TKLIB, TK2LIB, and so on). But then, when you go to install the Workshop, it replaces them all with unpacked versions so that you can link properly. This is why the Workshop installer is 6 disks instead of LOS's 5; the unpacked libraries take up some extra space.

Make sure not to install LOS back on top of the Workshop, or else it'll replace all of them with the packed versions again!

Regardless of whether you're installing LOS or the Workshop, the files on the first install disk must be packed, because there isn't room for all the necessary boot files otherwise.

And a progress update: I've finished writing PACKSEG at this point, and I'm just doing some stress testing and updating the build scripts to utilize it now. It takes about an hour to pack all the necessary files.

[AlexTheCat123]

Okay, it's all done and up on Github! The new LOS Compilation Base.image comes with the updated versions of all the scripts and the PACKSEG executable, but if you've already transferred all the source files over and want to update your existing LOS Compilation Base.image, then you just need to copy over the following files:

ALEX/ASM/LIBHW.TEXT
ALEX/ASM/LIBPL.TEXT
ALEX/MAKE/ALL.TEXT
ALEX/MAKE/APCL.TEXT
ALEX/MAKE/APHP.TEXT
ALEX/MAKE/APIM.TEXT
ALEX/MAKE/APIMDISK.TEXT
ALEX/MAKE/APPW.TEXT
ALEX/MAKE/DISK1.TEXT
ALEX/MAKE/DISK2.TEXT
ALEX/MAKE/DISK3.TEXT
ALEX/MAKE/DISK4.TEXT
ALEX/MAKE/DISK5.TEXT
ALEX/MAKE/DISKS.TEXT
ALEX/PACKSEG.TEXT
BUILD/PACKSEG.TEXT
ALEX/MAKE/ALL_NODISKS.TEXT
ALEX/MAKE/PACKSEG.TEXT
ALEX/PACK/OFFICE.TEXT

I've also updated lisa_serial_transfer.py to fix a minor bug, as well as patch_files.py to adjust its behavior on the Calculator, Clock, and Preferences now that we're making install disks. So if you've already copied the source code over to your Lisa, run patch_files on a fresh copy of the code and transfer the APHP, APCL, and APPW directories to replace whatever's currently on your Lisa!

Note that ALEX/MAKE/ALL_NODISKS.TEXT replaces ALEX/MAKE/ALL_NOFLOP.TEXT for the sake of increased clarity in the filenames. But now that we have PACKSEG, you can also run ALEX/MAKE/ALL.TEXT to build everything complete with install and LisaGuide disks!

Once you've built everything, you can make a set of all 5 install disks at any time by running ALEX/MAKE/DISKS.TEXT (or ALEX/MAKE/INSTALLER.TEXT if you want to rebuild the installer too). Individual disks can be made using ALEX/MAKE/DISKn.TEXT, where n is the disk number from 1 to 5.

To make a new LisaGuide disk, just run ALEX/MAKE/APIMDISK.TEXT.

Enjoy, and let me know if you encounter any problems!

[sigma7]

So far I've not made it through the entire make-all process; somewhere around the make/fullos stage something happens (I presume some newly built obj file comes into use), the Lisa crashes, and won't start up again due to an invalid OS system error.

I'm starting over with the Aug 14 disk image & scripts and a fresh source unzip, so hopefully whatever I screwed up is gone now, but so I don't make the same mistake again:

when you install LOS, it copies over packed copies of all the intrinsic libraries .... But then, when you go to install the Workshop, it replaces them all with unpacked versions so that you can link properly.
...
Make sure not to install LOS back on top of the Workshop, or else it'll replace all of them with the packed versions again!

Can someone be more specific about what not to do here? Obviously Alex isn't saying 'don't run the make/all' script, but ultimately isn't it installing "on top of the Workshop"?

eg. is the risk purely regarding packed files, or is there a risk that make/all failing in some particularly inconvenient spot will have deleted some required file before successfully building a new one, breaking the system (either to the point that it crashes, or to the point that the next attempt to make will aggravate the problem causing the crash)?

[AlexTheCat123]

Can someone be more specific about what not to do here? Obviously Alex isn't saying 'don't run the make/all' script, but ultimately isn't it installing "on top of the Workshop"?

eg. is the risk purely regarding packed files, or is there a risk that make/all failing in some particularly inconvenient spot will have deleted some required file before successfully building a new one, breaking the system (either to the point that it crashes, or to the point that the next attempt to make will aggravate the problem causing the crash)?

There isn't anything you really need to worry about here! I'm just saying that you should never try to install LOS over the top of a Workshop installation from the LOS install diskettes because the LOS installer will overwrite the unpacked Workshop versions of the libraries with the packed LOS versions of them. But in terms of the compilation process, you don't need to be concerned about anything. The build scripts will overwrite the original unpacked libraries with new unpacked ones; the script only goes to pack them when they get copied over to an LOS install diskette.

There shouldn't be any point (at least that I can think of) where the scripts delete a critical file before generating its replacement, so I'm guessing that your issue is related to something else. Hopefully starting fresh with all the new stuff will fix everything!