LisaList2

Wow amazing work Alex!!!

It works! Well, it does whatever a DMA Test Card does... Behavior is consistent with other cards in this thread:

https://youtu.be/qFD37dJXe0E

Special thanks to stepleton for making his card's ROM available, and to Lisa2 for burning me a copy. You guys rock. 

Glad to hear it! Be sure to make a backup of your disk now before going any further, and let us know if you have any issues with actually building everything.

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.

I finally managed to transfer all the files successfully!

The issue turned out to be hardware-related: due to past battery leakage, the G (enable) pin of the AM26LS32ACN was not grounded correctly. After fixing that, I also built a short cable according to the pinout http://sigmasevensystems.com/blumanual.html

Lisa (DB25M)      PC (DE9F)
  2   Tx  > Rx      2
  3   Rx  < Tx      3
  7   Gnd           5
  6   DSR < RTS     7
 20   DTR > CTS     8

Finally, I had to tweak the Python transfer script to use CTS/RTS flow control instead of DSR/DTR.

diff --git a/scripts/lisa_serial_transfer.py b/scripts/lisa_serial_transfer.py
index 6a2b177..53fb4c1 100644
--- a/scripts/lisa_serial_transfer.py
+++ b/scripts/lisa_serial_transfer.py
@@ -99,7 +99,7 @@ def send_single_file(file_path, filename):
             while (byte := source_file.read(1)): # Read the file byte by byte.
                 state_start = time.time()
                 # Flow control in Pyserial is broken, so we have to check DSR manually. If it's low, we need to block until the Lisa's done processing data.
-                while not lisa.dsr:
+                while not lisa.cts:
                     # So say that we're waiting for the Lisa in the progress bar.
                     print_progress_bar(filename, total_files - len(path_list), total_files, source_file.tell(), os.path.getsize(file_path), size, start_time, True)
                     if time.time() - state_start > buffer_timeout: # And if it's not done processing in buffer_timeout seconds, print a warning.
@@ -138,7 +138,7 @@ def send_single_file(file_path, filename):
         print_progress_bar(filename, total_files - len(path_list), total_files, 0, 1, size, time.time(), True)
         time.sleep(2)
         state_start = time.time()
-        while not lisa.dsr: # Wait for the Lisa to be ready for our 'end of transfer' commands, just like above.
+        while not lisa.cts: # Wait for the Lisa to be ready for our 'end of transfer' commands, just like above.
             if time.time() - state_start > buffer_timeout:
                 print('WARNING: Lisa is taking forever to empty its buffer, probably hung!')
                 log_file.write('\nWARNING: Lisa is taking forever to empty its buffer, probably hung! ')
@@ -181,7 +181,7 @@ def send_single_file(file_path, filename):
     # This code executes at the end of a file transfer; it's very similar to the code from the Except above.
     # lisa.flush()
     state_start = time.time()
-    while not lisa.dsr: # Wait for the Lisa to finish processing its data buffer.
+    while not lisa.cts: # Wait for the Lisa to finish processing its data buffer.
         print_progress_bar(filename, total_files - len(path_list), total_files, os.path.getsize(file_path), os.path.getsize(file_path), size, start_time, True)
         if time.time() - state_start > buffer_timeout:
             print('\nWARNING: Lisa is taking forever to empty its buffer, probably hung!')
@@ -259,7 +259,7 @@ sys.stdout.flush()
 input('Run the EXEC file ALEX/TRANSFER.TEXT on your Lisa, and hit RETURN on this computer once the Lisa screen goes blank...')
 
 try: # Attempt to connect to the Lisa over serial, and exit with an error if we fail.
-    lisa = serial.Serial(port=sys.argv[1], baudrate=28800, bytesize=8, dsrdtr=True, timeout=1)
+    lisa = serial.Serial(port=sys.argv[1], baudrate=28800, bytesize=8, rtscts=True, timeout=1)

With these changes in place, the transfers seem to be now reliable.

Thanks again to everyone here for the advice and pointers — it definitely set me on the right track.

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.

  {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...

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?

 

It is certainly possible that I'm wrong that it shouldn't work (or maybe there are more specifics as to where it does and doesn't)...

I've now done some superficial testing and found that I was mostly incorrect.

In summary, the 2/10 I/O Board in an otherwise stock 2/5 does appears to work with Sony 800K drives, but doesn't work with a 400K drive.

With a Sony double sided drive, after swapping in the 2/10 I/O Board, the drive did seem to run normally and the floppy was readable (since this was a very superficial test, there could be more subtle issues such as slow performance, or not). I tested an MPF75W and MPF51W.

With a 400K single sided drive, after swapping in the 2/10 I/O Board, the drive did clearly misbehave; the motor would run, but not at the usual speed, or with the usual variations, and the disk was not readable. Upon swapping the Lite Adapter for the modified version described in the LisaFAQ http://lisafaq.sunder.net/lisafaq-hw-io_substitution.html, the 400K drive worked again.

I expect any Floppy Emulator won't need the motor speed signal, so would work like the Sony drives.

I didn't test any off-brand drives, such as the Chinon drive sold by Sun Remarketing for a while.

Apologies for the misdirection; I'll correct my previous post on this topic.

Rick,

I still have not had time to build a chip tester.

If your offer is still open, I would like to send you the card for diagnostics.

bmwcyclist, please PM me and I will help you.

Rick

But this might not be a 2/10 IO board, but a 2/5 board. Just not the common version that we see

Although it isn't impossible that new boards will be found, I don't think this is one... here is the schematic for the 2/10 I/O Board for verification: http://bitsavers.org/pdf/apple/lisa/hardware/Lisa_2_10_IO_Board/