Print

[sigma7]

I started fresh with the Aug 14 2025 Alex github files, and:

• Applied patch_files.py to a freshly unzipped set of source files (it reported all patches successfully applied)
  
• Prepared a ProFile emulator with the Aug 14 version of Alex's ProFile image
  
• Transferred the patched source files to the Lisa
  
• (saved a copy of the updated image)
  
• ran ALEX/MAKE/ALL_NODISKS
  

Everything seemed to go fine, no interrupted scripts or errors reported. However, restart left me with error 10730.

I restored the image (saved after transferring the files), and worked through portions of the make process, periodically saving a copy of the image so I could go back a step, and testing that restarting still worked. (The Step option of exec processing is useful for narrowing down this kind of thing)

Ultimately I found that restarting stopped working after executing ALEX/LINK/SYSTEMOS, and specifically the last step where OBJECT/SYSTEM.OS is copied over SYSTEM.OS

I used DUMPOBJ to examine and compare the original SYSTEM.OS and the new OBJECT/SYSTEM.OS. Both have the same segmentation, number of entry points in the jump table, same segment names at the same segment addresses. The code size of every routine of the new make is a bit larger, I think due to including some debugger names.

I wondered if changing SYSTEM.OS while it is in use may be the issue, so I also tried hitting reset after copying over SYSTEM.OS (rather than formally exiting the shell and restarting) ... still error 10730.

I tried doing the complete build, skipping over the replacement of SYSTEM.OS, and doing that one step last ... still error 10730.

So wondering...

• Has anyone else (aside from Alex) been successful? Perhaps some are still working their way through the process, and no doubt some are waiting for success reports before embarking.
  
• Is there an issue with my machine configuration? It is a 2MB Lisa 2, one ProFile emulator attached to the built-in port. I think Alex uses a 2/10. I don't think he has mentioned working with two ProFiles, but maybe I missed it. If you have been successful, what is your machine configuration?
  
• Is it the case that one needs to be doing the make process on a volume that isn't the one in use (ie. other than the boot/system volume)?
  
• Is there a need to exit the Workshop and enter the LOS environment at some stage to prepare the disk for the new SYSTEM.OS?
  
• Any recommendations for how to troubleshoot what is wrong with SYSTEM.OS?

 

[sigma7]

To test the question of whether replacing the running SYSTEM.OS is an inherent problem, I tried duplicating it, then copying the duplicate over the running one. Restart works, test passed.
Then I tried: renaming the original, then renaming the copy to SYSTEM.OS. Restart works, test passed.
Not much of a test when the files are identical, but something.

I added a dual parallel port card, and set up another emulator on the lower port, initialized to the image as of the post ALEX/MAKE/LIBS_PARTIAL step of MAKE/ALL_NODISKS. Set the prefix to -#2#1, and ran ALEX/MAKE/FULLOS.

During the processing, I could see most reads & writes were occurring on the #2#1 expansion slot device, with occasional accesses to the built-in port that seemed to correspond to launching the Pascal compiler, assembler, or linker.

After completion, I moved the external device to the internal port, and tried to boot from it... error 10730.

I observe that during the processing on the #2#1 external device, the linker refers to the internal device to read INTRINSIC.LIB... could that be referring to a pre-new-make version when it shouldn't be? eg.

Code: [Select]

  {V3.0} WORKSHOP: FILE-MGR, SYSTEM-MGR, Edit, Run, Debug, Pascal, Basic, Quit, ?L
  Linker - M68000 Object Code     {3.0} June 1, 1984
Copyright Apple Computer, Inc. 1984

Beginning memory:           714072
After initial allocation:   676996
Input file [.OBJ] ? OBJECT/NWSHELL
Input file [.OBJ] ? SYS1LIB
Input file [.OBJ] ? IOSPASLIB
Input file [.OBJ] ?
Listing file [-CONSOLE] / [.TEXT]
Output file ? [.OBJ] PROGS/NWSHELL
Reading file: OBJECT/NWSHELL.OBJ
Reading file: SYS1LIB.OBJ
Reading file: IOSPASLIB.OBJ
Input summary:   
       3 Files     , max =   100
      31 Segments  , max =  4096
     193 Modules   , max = 32768
     168 Entries   , max = 65536
     400 Ref. Lists, max = 65536
     919 References, max = 65536
Linking Main Program.
Reading Library Directory: -#11-INTRINSIC.LIB
Active: 53 of 193 read.
Visible: 8 of 168 read.
Global data: $000154
Common data: $000000
  Number of segments in file = 3, number of Jump Table entries = 8
Linking segment:          file (JT) seg:   1 size:    11552
Linking segment: PFileSeg file (JT) seg:   2 size:     5232
Linking segment: FileSeg  file (JT) seg:   3 size:     8948
   0 Errors detected.

The output is an executable program file.

Elapsed time: 30.300 seconds.
That's all Folks!

  {V3.0} WORKSHOP: FILE-MGR, SYSTEM-MGR, Edit, Run, Debug, Pascal, Basic, Quit, ?
  {V3.0} WORKSHOP: FILE-MGR, SYSTEM-MGR, Edit, Run, Debug, Pascal, Basic, Quit, ?

  {V3.0} WORKSHOP: FILE-MGR, SYSTEM-MGR, Edit, Run, Debug, Pascal, Basic, Quit, ?F*
  FILE-MGR:  Backup, Copy, Delete, List, Online, Prefix, Rename, Transfer, Quit, ?C*Copy from what existing file(s)?  PROGS/NWSHELL.OBJ
Copy to what new file?  Shell.UltraDOS
One Moment Please
*" $ PROGS/NWSHELL.OBJ               is Selected
*

Copying selected file(s) from -#2#1 to -#2#1
-#2#1-PROGS/NWSHELL.OBJ           copied to  -#2#1-Shell.UltraDOS

  {V3.0} WORKSHOP: FILE-MGR, SYSTEM-MGR, Edit, Run, Debug, Pascal, Basic, Quit, ?

I'll try to make on a 2/10 next, after that I guess I'll be begging Alex for help...

[AlexTheCat123]

Wow, sorry that you're still having problems!

Is there an issue with my machine configuration? It is a 2MB Lisa 2, one ProFile emulator attached to the built-in port. I think Alex uses a 2/10. I don't think he has mentioned working with two ProFiles, but maybe I missed it. If you have been successful, what is your machine configuration?

Everything about your config sounds good to me. I used a 2/10 in real life, but a 2/5 in LisaEm. And everything builds fine under both, but I guess you could try a 2/10 just to be safe.

Is it the case that one needs to be doing the make process on a volume that isn't the one in use (ie. other than the boot/system volume)?

The build scripts assume that everything is on the boot volume, so it won't work if you have your code on a separate disk, even if you set the prefix to that disk.

Is there a need to exit the Workshop and enter the LOS environment at some stage to prepare the disk for the new SYSTEM.OS?

Nope, no need to do that!

Any recommendations for how to troubleshoot what is wrong with SYSTEM.OS?

The failure happens really early in the boot process, before the OS has loaded, so you won't be able to use WRITELN or anything like that. Doing RAM dumps from a debug build of LisaEm was really helpful for me when I was troubleshooting issues at this phase of boot; you can see which segments of the OS have been loaded into memory and where exactly it fails, which might give you some helpful info. And if you really need to "print" any debug messages, then you could do what I did and write a procedure that just throws debugging strings into RAM at some random address. I might be able to find the code I used if you really need it. Unfortunately, I can't replicate the problem on my end, so I'm not sure that I can be of any more help here without some more info about where exactly the OS load is failing.

SOURCE/LOADER.TEXT is the file that's generating the 10730 errors (look for the trap(bad_os) calls). This is where you'd want to put your custom "writeln" procedure. Note that this isn't part of the OS; it instead gets linked to form each of the System.BT bootloader files, which means that you'll have to rewrite the boot blocks on your boot volume with the new System.BT_Profile each time you modify and recompile this file (which you do by running ALEX/MAKE/BTDRIVERS.TEXT). There's an fs_utilities call that does this, with the caveat that the target volume can't be mounted when you try to rewrite the blocks. The other alternative is to copy the new System.BT_Profile (and new System.CD_Profile to make sure it's patched for large disk support) to a Workshop install disk #1 and reinstall the Workshop from this disk, which automatically rewrites the boot blocks at the end. Quite a pain to do this each time you modify the loader, but at least the 512MHz clock in LisaEm makes it a bit more pleasent!

In SOURCE/LOADER.TEXT, the four things that cause a 10730 are:
1. A SYSTEM.OS that doesn't have an executable code block in the right place after the header blocks.
2. A SYSTEM.OS that has more than 48 segments in it.
3. A segment in SYSTEM.OS that has a size of 0.
4. Failure to load any SYSTEM.OS segment into RAM.

I'd say that #4 is the most likely culprit (and the hardest to troubleshoot), but it's worth checking them all.

I observe that during the processing on the #2#1 external device, the linker refers to the internal device to read INTRINSIC.LIB... could that be referring to a pre-new-make version when it shouldn't be?

This is one of the reasons why you've got to have everything on the boot device; we need to be reading in and updating the same INTRINSIC.LIB during each link.