General Category > Building LOS From Source
Moving the many source files to the Lisa
stepleton:
Maybe I was playing fast and loose :)
To get directly to one of those lists of error codes, I Googled my favourite Lisa OS error code:
1162 "Power is already off"
(I would love to know the circumstances that could raise an 1162; in any case, I could not find an instance of the Lisa OS using it, though it does seem to define a constant called "pwr_already_off" in a few places.)
Anyway, the first Google hit was this 1982 document, and scrolling up to PDF page 44 brings us to a list of RS-232 errors. I suppose there is a chance that the list is out-of-date by version 3 of the OS, of course --- it's funny that the 643 code is undocumented in later resources like this one.
We can also do some sleuthing. The file LISA_OS/OS/source-rs232.text.unix.txt defines a constant called errbase with the value 640, and raises errors offset from that constant in several locations. The two places where the offset is 3 seem to involve copying data out of the "typeahead" buffer, though I find the code pretty difficult to understand at a glance if I'm being completely honest! There is mention of interrupts near the first offset-3 place.
I'll have to stop my investigations there. But if I can suggest a diagnostic experiment to @snua12, what if you do the following. Instead of having repeated "test123" strings, can you try having strings of varying lengths and with runs of spaces of varying lengths in them? I say this because the Lisa's text file format handles these things in interesting ways. Runs of spaces are "compressed" to save space, and the Lisa may need to do extra processing to do that kind of text encoding. Additionally, Lisa text files have a block structure, and a line of an inconvenient length at the right time may force the Lisa to close the current text file block and start a new one --- meaning it might be getting distracted at a critical moment while data continues to stream in. (Citation: PDF pages 37-38 here)
If a more interesting "artificial" file can cause this kind of trouble, we might get a clue from it, particularly if the text data (outside of the spaces and newlines) continues to be something boring like "test123".
sigma7:
--- Quote from: AlexTheCat123 on August 12, 2025, 05:02:45 pm ---
--- Quote from: sigma7 on August 12, 2025, 03:52:31 pm ---Where did you find that? It is missing from a few versions of the various workshop manuals that I examined.
--- End quote ---
Yeah, that's what I'm wondering too! I looked everywhere, including in the source code, and couldn't find it.
--- End quote ---
APLT/REC.TEXT contains this:
--- Code: --- if RecUartLen<>0 then {Any UART receives?}
CheckReceive:=True
else
if OnLine then begin
Read_Data (eCode, RefNum, Ord (@RecUartSeq), PaocSize, NrRead, Sequential, 0);
if eCode <> 0 then begin
if eCode = 643 then begin {input missed}
RecUartSeq [NrRead+1] := Chr(ParityChar);
NrRead := NrRead + 1;
end else begin
Close_Object (eCode, RefNum);
Unmount (eCode, UartPath [PortA]);
UartOpen:=False;
OnLine:=False;
GiveAlert (HTerm, AlrtNote, ALUart, SerialName [PortA], TheTitle, '');
NrRead:=0;
end;
end;
RecUartLen:=NrRead;
if NrRead>0 then
CheckReceive:=True;
end;
--- End code ---
Is {input missed} a useful comment? I'm not sure.
edit: seeing as it then adds a filler character, I'm supposing this means receive buffer overrun.
Perhaps Ales's computer or python implementation is particularly fast?
AlexTheCat123:
--- Quote from: sigma7 on August 12, 2025, 06:15:23 pm ---seeing as it then adds a filler character, I'm supposing this means receive buffer overrun.
Perhaps Ales's computer or python implementation is particularly fast?
--- End quote ---
The Python program checks the state of DTR before sending each byte, so we shouldn't have any buffer overruns here unless handshaking isn't functioning properly. An easy way for @snua12 to check: does the Python program ever pause transmitting in the middle of a file and start flashing the "Waiting for Lisa to catch up" message at the top of the terminal window? We expect it to pause at the end of a file regardless of whether or not handshaking is set up, but pauses in the middle of larger files (anything greater than about 8K) will indicate that handshaking is working properly.
--- Quote from: stepleton on August 12, 2025, 06:12:09 pm ---Runs of spaces are "compressed" to save space, and the Lisa may need to do extra processing to do that kind of text encoding. Additionally, Lisa text files have a block structure, and a line of an inconvenient length at the right time may force the Lisa to close the current text file block and start a new one --- meaning it might be getting distracted at a critical moment while data continues to stream in.
--- End quote ---
We shouldn't have to worry about the space compression here; don't 100% quote me on this, but I believe that the Pascal reference manual states somewhere that it doesn't automatically do this compression when you write data to a text file. It can read compressed text from a file and convert it to a regular string, but can't take a string and compress it into a file. I guess you have to write your own text file interface routines in order to take advantage of the compression.
The closing and opening of a block messing up timing might be a valid concern, although I'd assume that the SCC would keep us safe in this situation too. I'm guessing it would just keep receiving until its internal buffer filled up (not sure how big that is; I've never read the 8530 datasheet) and then deassert DTR to pause things until the OS finishes opening the new block and comes in to clear the buffer.
My best guess right now is that this is a problem with handshaking. If you're not getting the pauses in the middle of file transfers, then it might be a good idea to probe the DTR pin on Serial B and make sure that it's toggling. If it toggles after about 8K of data and then toggles again 30-45 seconds later, then your Lisa should be asserting it properly. If you're getting the toggling but not getting pauses in the Python program, then something's probably up with your USB to serial adapter.
sigma7:
--- Quote from: AlexTheCat123 on August 12, 2025, 08:27:32 pm ---checks the state of DTR
--- End quote ---
On my setup (not using Python to send data), I observed that toggling CTS was what worked for handshaking, DTR & DSR didn't throttle the data being sent to the Lisa. So I wired DSR from the Lisa to CTS on the USB-Serial adapter, and then handshaking worked in the driver. ie. I no longer needed to watch DTR or DSR, just turn on the driver's hardware handshake.
--- Quote from: stepleton on August 12, 2025, 06:12:09 pm ---Runs of spaces are "compressed" to save space, and the Lisa may need to do extra processing to do that kind of text encoding. Additionally, Lisa text files have a block structure, and a line of an inconvenient length at the right time may force the Lisa to close the current text file block and start a new one --- meaning it might be getting distracted at a critical moment while data continues to stream in.
--- End quote ---
My observation is that:
- the compression of spaces occurs only at the beginning of a line of text (not elsewhere in a line/paragraph)
- uploading using 'copy' from -keyboard or -console, implements that compression, however using Alex's Receive program, the compression does not occur
- the compression (and slowdown) when uploading using 'copy' does not occur while collecting it into the receive buffer, it happens later when when saving the file. I think this is also the point at which text blocks would be arranged so that lines are not split across blocks (assuming that is still the case in Workshop 3.0).
- charcount seems much faster when the file has not experienced compression (such as when saved by Alex's Receive program)
--- Quote ---it would just keep receiving until its internal buffer filled up (not sure how big that is)
--- End quote ---
The 8530 SCC has a 3 byte receive buffer. The pin compatible 85230 ESCC has a 5 byte buffer.
--- Quote ---then deassert DTR to pause things
--- End quote ---
To be clear, the SCC doesn't do the handshaking automatically, the 68k software needs to observe that it is running low on it's own RAM receive buffer and do the handshake. The size, low and high threshold settings are for the block of RAM the Lisa driver sets aside for the receive buffer.
Since the SCC buffer is barely large enough for an interrupt handler to get the bytes before losing some, once in the interrupt handler, it will keep checking for and collecting data, essentially locking out other processing.
AlexTheCat123:
Reading back over my post, I realized that I said DTR a few times when I meant DSR. Sorry about that! So when you're checking the signal coming out of the Lisa, make sure that you're checking DSR not DTR!
--- Quote from: sigma7 on August 13, 2025, 03:21:26 am ---On my setup (not using Python to send data), I observed that toggling CTS was what worked for handshaking, DTR & DSR didn't throttle the data being sent to the Lisa. So I wired DSR from the Lisa to CTS on the USB-Serial adapter, and then handshaking worked in the driver. ie. I no longer needed to watch DTR or DSR, just turn on the driver's hardware handshake.
--- End quote ---
I noticed the same thing; the serial driver wouldn't pay any attention to DTR and DSR no matter what I did. But I decided to use DSR anyway by manually polling it instead of connecting it to CTS so that people wouldn't have to make custom cables to do their transfers.
--- Quote from: sigma7 on August 13, 2025, 03:21:26 am ---To be clear, the SCC doesn't do the handshaking automatically, the 68k software needs to observe that it is running low on it's own RAM receive buffer and do the handshake. The size, low and high threshold settings are for the block of RAM the Lisa driver sets aside for the receive buffer.
--- End quote ---
Right, I understand that the big RAM buffer is completely managed by the serial driver and not the SCC itself. I just figured that, if the SCC's internal 3-byte buffer filled up and the 68K didn't come along to clear it, that it would automatically deassert DSR to tell the other computer to stop sending data until the 68K has the time to empty the SCC buffer. But I guess you're saying it's not that intelligent!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version