General Category > Building LOS From Source
Moving the many source files to the Lisa
sigma7:
--- Quote from: stepleton on July 20, 2025, 06:55:18 pm ---Is there a way on the Workshop side to write data from the console directly into a file?
--- End quote ---
One is the "DumpPatch" utility, which (if I'm reading the workshop manual accurately) permits entering data in hexadecimal form, then saving to a specified filename.
"Copy" is another option suitable for ordinary text... console can be the input and output can be pre-directed to a file.
IIRC, one can also "Copy" from a serial port to a file (or vice-versa as one might do to dump a file to a printer), dunno whether this works concurrently with mapping Console to the same serial port, or if there would be any advantage to doing so.
AlexTheCat123:
I really like the simplicity of just driving the Workshop directly, if we can get that to work! And I think the direct Copy option from the File-Mgr is probably simpler to get running than DumpPatch. Although DumpPatch could be handy if some of the special characters can't be directly typed over serial and would need to be entered in hex instead.
--- Quote from: sigma7 on July 20, 2025, 02:36:41 pm ---Alex reported in his VCF presentation that floppy transfers introduced corruption; perhaps solving this problem is a possibility.
--- End quote ---
Just to provide a bit more detail, MacCom would always cut off the start of each file and append some garbage (or sometimes text from another file) onto the end of each file. So it seemed to me like the pointer to the start of the file was getting offset slightly ahead of where the file actually began on disk. Not that this matters anyway, because I think that fully automating the process is absolutely the way to go!
sigma7:
Some discoveries in working on uploads...
Aside from > and < used for redirecting to/from a filename or KEYBOARD/CONSOLE, the < and > characters shown below are not typed.
To configure the serial port, starting at the main Workshop menu:
--- Code: ---rportconfig<return>
--- End code ---
then type return to go through the settings.
To switch the console to RS-232 port B, starting at the main Workshop menu, ending in the System-Mgr menu:
--- Code: ---scrby
--- End code ---
To switch the console back to main when finished using the serial port, starting at the main Workshop menu, ending in the System-Mgr menu:
--- Code: ---scmy
--- End code ---
To start uploading a file, to be named "filename", starting at the main Workshop menu:
Note: ".text" is appended to the filename unless it already includes it
with echo to the screen
--- Code: ---rcopy<return>
>filename<return>
--- End code ---
without echo to the screen
--- Code: ---rcopy<return>
<-KEYBOARD,>filename<return>
--- End code ---
To end uploading (sometimes one less <ctrl-m> is needed, perhaps patience makes a difference?)
--- Code: ---<ctrl-n><ctrl-m><ctrl-m>
--- End code ---
To run the charcount function on a file named filename, starting at the main Workshop menu:
--- Code: ---rcharcount<return>
<filename,>-CONSOLE<return>
--- End code ---
To interrupt an operation (equivalent of Apple-. or ctrl-c)
--- Code: ---<ctrl-[>
--- End code ---
Text File Compression
The Workshop manual mentions something about compressing the leading spaces on each line in a text file, using a DLE character and a space count character. Presumably this is to not punish indentation styles. I believe line lengths are limited to 255 characters so a single count character is always sufficient.
In terms of the size of a file as reported by charcount vs the size of a file prior to upload, it seems that you can get the numbers to match when:
- the line ending is considered a single character
- the compression reduces the size by the number of leading spaces greater than 2 on each line
- the compressed size is 2 greater than that derived from the two preceding rules
I haven't investigated how the data is actually stored on the disk (eg. is a line with 2 spaces DLE 0x02 or ' '? etc., and why/where are 2 characters added... a 16 bit file length perhaps?)
DLE (aka "Data Link Escape") is 0x10 in the ASCII table.
A line starting with 6 spaces is encoded as 0x10 0x26
I'm closing in on an AppleScript solution using Roger Meier's CoolTerm https://www.freeware.the-meiers.org
CoolTerm claims to be python scriptable too and is available for Windows and Linux. The pacing option that waits for a character's echo seems particularly well suited to this task. YMMV
edit: for clarity... english is hard
edit2: added charcount and copy without echo
edit3: added thoughts about the leading spaces compression in text files
AlexTheCat123:
That's some great progress! I wonder how high we're going to be able to go with the baud rate? I started experiencing corruption with anything over 1200, but maybe other people will have better results.
stepleton:
If the proposed method doesn't display text on the screen during the transfer, then it may be possible to use a higher baud rate. I suspect a major reason for the LisaTerminal slowness is because (if I recall correctly) it draws the text to the display while it receives it. If I'm wrong about that, then disregard. If I'm right, then that surely steals a lot of cycles.
The Lisa serial port has hardware flow control capability, which may be a bit more dependable than XON/XOFF flow control. Some USB/serial adapters may not be as good at it, though. I wonder if it would help.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version