General Category > Building LOS From Source
Moving the many source files to the Lisa
AlexTheCat123:
Okay, I've made some changes to my code, and I'm now able to get about 120 CPS (average, including the breaks when the buffer gets full) for large files and 400-ish for smaller ones that don't fill up the buffer. It also turns out that automatic handshaking is completely broken in the Pyserial library, so I have to manually poll DSR and stop transmitting when it goes low. But that's not a big deal at all now that I've figured it out.
The new version of the program isn't quite ready to be put on Github yet, but I'm hoping to have it up by the end of the day!
Also, I just tried out CONCAT, and unfortunately it doesn't preserve the high bit either. So we'll need to find another solution there.
Progress is coming along pretty well on the auto-patch program too, so hopefully I'll be able to release that by the end of the weekend. That way, the only patches that would need to be done manually (unless we find a way to automate them too) are the corrupt character ones on the Lisa end.
stepleton:
I wonder if it may be time to DIY a transfer program on the Lisa side. It is at least possible to send 8-bit data from a program running on Lisa OS over the serial port; the YMODEM implementation I made requires it, so the problem does not lie in the Lisa OS serial driver or in the OS libraries. But setting YMODEM aside, I've mooted a wire "protocol" for text file transmission upthread, which Alex's python program could reproduce with minor modification; the major work of course is on the Lisa side.
I barely have time to tie my shoes these days (after-market elastic drawstring shoelaces for the win), but if I were doing this I would start from LIBPORT.TEXT and write a function called TimedReadLine that reads "\r"-terminated lines from the serial port (the few string library functions starting from PDF page 142 here may help).
From there on it's a matter of reading lines and then writing them to files, I should think.
The largest source file (APDM-DESK.TEXT.unix.txt) is under 256k, so we might even consider loading all incoming files directly into RAM, provided it's not difficult for Workshop programs to allocate so much memory. Storing file data in RAM should be about as fast as it gets, and that would maximise throughput. But this would be something to fix only after a simpler approach was working, I think.
sigma7:
--- Quote from: stepleton on July 25, 2025, 06:39:52 pm ---it may be time to DIY a transfer program on the Lisa side
--- End quote ---
A transfer program could certainly help a lot with the speed.
From looking at source code and dumping some bytes from text files, I think the issue is that the system is designed around an "international text" concept so input text gets filtered before being stored in a file in what looks vaguely like a precursor to UTF-16.
It may be possible to pre-code the highbit characters or perhaps implement a base64 decoder or something like that since there aren't a lot of files that need that support.
Still, it may be easier to ( have Alex :) ) change the high bit characters to hex values instead of string constants.
AlexTheCat123:
I have a suspicion that maybe PORTCONFIG is the problem, and that it always sets the port up in 7-bit mode given that it never asks you what you want. So I think the next thing I'm going to do is to write a simple Pascal program that forces the port into 8-bit mode. Hopefully that fixes things. If not, then I guess it's got to be something with COPY.
And by the way, the new faster version of the transfer tool is on Github now.
Edit: It looks like my suspicion was unfounded. After looking at some documentation, it seems like the driver automatically chooses 7 or 8 bits depending on whether you enable or disable parity, which PORTCONFIG most certainly allows you to do. I think I'm going to try and write a simple program to replace COPY that actually supports 8-bit bytes, and hopefully that'll fix the problem.
AlexTheCat123:
Good news, I figured it out!
It turns out that it has nothing to do with the OS, the driver, PORTCONFIG, or COPY being weird and intentionally deciding to strip the high bit, but instead it's an annoying quirk of LIBPL (the Pascal runtime library). Whenever you use the LIBPL routines to open the console for reading and it detects that the console has been mapped to the serial port, it automatically assumes that you're using the high bit for parity and discards it. The solution here is to use the OS routines (look in LIBOS/SYSCALL) to open and read the console, since these just give you the data untouched.
I've written a replacement for the COPY program that uses these discoveries to preserve the high bit, so we should be able to send all the Lisa characters over properly now. I'll put the new version of the disk image and transfer program on Github either tonight or tomorrow.
Now it's just a matter of finishing the program that patches all the source files (I'm pretty close at this point), and then people should be able to copy everything over to their Lisas and start compiling without having to make any changes to stuff!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version