Print

[D.Finni]

I have a new TCP/IP stack and some applications which are designed to work on a Lisa 2 running MacWorks. The applications are a POP3 email client (just a slim prototype) and an HTTP/1.1 client.

Read about the project here: Sabina TCP

Owners of a Lisa 2 with MacWorks who are interested in beta testing can send me an email to df@macgui.com and I will send you the latest version on a 3.5" DiskCopy 4.2 image.

[rayarachelian]

I have a new TCP/IP stack and some applications which are designed to work on a Lisa 2 running MacWorks. The applications are a POP3 email client (just a slim prototype) and an HTTP/1.1 client.

Read about the project here: Sabina TCP

Excellent!

[stepleton]

Very impressive to fit TCP/IP into under 8K, so fewer than 4000 instructions. I'd be curious to know how you've done it

It's interesting to see TLS 1.3 as a possible future feature. Alongside the development of the Crypto Ancienne library supporting TLS 1.2, there was some very inconclusive speculation as to what the minimal system capable of doing TLS might be. The Crypto Ancienne github page reports a connection taking 22 seconds on a Mac IIci (25 MHz '030), and although it's a C implementation, I expect TLS may be beyond the Lisa's reach even in assembly. (Similarly, AmiSSL for Amiga appears to require '020 or better, though that's only based on what some forum person is saying.)

Anyway, my hat is still off to you, and I would love to be proved wrong!

[rayarachelian]

might be worth having an external box do the SSL, like this thing: https://www.vogons.org/viewtopic.php?f=24&t=67165

but would love to see this ported to LOS.

[D.Finni]

Re: code-size. Partly that's just the nature of 68000 assembly. Also, all my subroutines are register-based. Very early in April I almost decided to use stack-based parameter passing but decided not too because of the instruction overhead of LINK/UNLK, etc.

Re: TLS 1.3. The RFC specifies the minimum cipher needed for interoperability is AES. I've got an AES in 68000 assembly, but it probably needs to be modified to work in CBC and ECB modes. I'm not interested in speculating or guessing about whether it "will work" on a 68000; instead I prefer to write the code and find out first hand.

Other solutions that I have under consideration are stunnel and SOCKS5 proxy.

[compu_85]

but would love to see this ported to LOS.

Same here! There are so few Office System apps, ones which can make the system talk to the modern world would be extra interesting.

[D.Finni]

but would love to see this ported to LOS.

Same here! There are so few Office System apps, ones which can make the system talk to the modern world would be extra interesting.

Given documentation on LOS, porting the core TCP/IP probably wouldn't take more than a month's effort. There are almost no Toolbox calls. Really the only Mac-ism is using register A5 as an application globals pointer. The other big code dependency is the ROM-based serial driver.

[rayarachelian]

Given documentation on LOS, porting the core TCP/IP probably wouldn't take more than a month's effort. There are almost no Toolbox calls. Really the only Mac-ism is using register A5 as an application globals pointer. The other big code dependency is the ROM-based serial driver.

I suppose you could ignore the A5 code completely and instead call Lisa A-Line traps where equivalent, etc. not sure if the LOS serial driver is going to be good enough at higher speeds, (at least assuming from baud rate limitations in LisaTerminal) but you could try and see. I'm guessing your code is likely modular so you'd only replace the pieces that interface with the serial driver. Not sure if handles are a thing in LOS as well, since it has an MMU so it has less of a need to reorder the address spaces.

From what little I know of LOS programming, the serial ports behave mostly like files, so that's a nice copied unix-ism, (though I suppose that's similar to opening a driver on the mac side too) but ofc setting the parameters requires a different set of calls than in the Mac System.

Hmmm, I suppose it might be useful to have a Mac vs LOS programming guide to help port stuff back from Mac System X programming to the Lisa. Maybe stuff like Alice could be reverse engineered and re-ported to run on LOS, etc.

[D.Finni]

Yes, I took a fairly responsible approach to code design, and the serial interface is a separate module which could be replaced.

But I'm using all the advanced features of the Mac's serial driver: I use asynchronous I/O, a completion routine, and a VBL task. At 57600 baud, the serial driver's private buffer has to be at least 800 to 900 bytes to avoid over-runs.

The VBL task is timed to fire every 1/16th of a second, and reads up to 200 bytes from the serial driver's private buffer, and decodes the PPP framing. Then it copies the decoded data to a PPP reassembly buffer, and when a complete IP datagram is assembled, it is passed to the IP handler. This gives me almost the best possible serial performance, without writing my own custom interrupt handler for the SCC (which I came close to doing this summer), while also allowing for interactivity (reading only up to 200 bytes at a time ensures the CPU isn't monopolized).

But anything is possible. If Lisa doesn't have the same support infrastructure that the Mac does, the code could be modified to make do, but with a loss of performance. Unless I wrote a custom interrupt handler for the SCC! If so, then we're back in business! 

[rayarachelian]

Yes, I took a fairly responsible approach to code design, and the serial interface is a separate module which could be replaced.
...

Yeah, I don't know how good the LOS SCC driver is, it may turn out it needs to be replaced, or patched in many ways. I know things worked well with ZTerm on MacOS <6.0.3 on top of MacWorks, or with LocalTalk. I had a 25ft serial cable between my 1st Lisa and a PC back in the early 90s, and also had a PC Localtalk parallel port adapter with some custom software and they could talk to each other, but LOS might or might not need extra help there.

I didn't have LOS in those early days. At first I used the Lisa as a MacPlus replacement, and then eventually I built a IIcx hackintosh in a PC case and then used the Lisa only for Xenix as I was getting into unix at the time.

There is source for the UniPlus kernel and its drivers on bitsavers, so we can at least tell if it does enough of the right things for getting PPP going instead of UUCP by reading.

From reading the LOS Device Driver manual I recall that it might be necessary to have two drivers, like with the parallel port, one driver for the port itself and other for the PPP code. (In the case of the parallel port, the 2nd driver is for the ProFile/Widget driver.) I think that manual contains info about building drivers, and there's a dump of a driver, but not sure how much useful details it has - I don't know if there's a sample LOS driver on the LPW disks, for example. So there may be lots of gaps to back fill.

As Tom pointed out, LisaTerminal works well at high speeds when *software* handshaking is used. This won't be viable for PPP, but not sure if that's a driver or app issue. My experiments with trying to get the serial port going for LisaEm wound up showing that if new data comes into the port after it sends a ^S is that the bytes are read, but completely discarded, which is really bad design. Again, I couldn't tell if the driver did that or LisaTerminal. But that was the behavior.

And it behaved better at higher speeds than at lower speeds, which indicates that it likely allocates a larger buffer at higher speeds. Some context, in the emulator, the baud rate means absolutely nothing. Whether you choose 300bps or 19200, LisaEm will send bytes as quickly as it can, generating IRQs as soon as there is data, and it will buffer all the data internally so nothing gets lost (upto 32K, though I could make it much higher). However either LOS or LisaTerminal freaks out and discards bytes if it gets them faster than some rate it's expecting.

Hopefully that's just LisaTerminal behaving badly and not the driver, otherwise, the driver will need to be disassembled and rewritten to do the right stuff. and then that gets into the question of how does one write a driver installer disk for LOS as well - there is one example which is the 800k floppy driver for LOS here: https://macintoshgarden.org/apps/lisa-office-system-800k-driver which could be useful for that effort.

[D.Finni]

I think that we've got enough options for the serial interface, and it won't be the biggest challenge.

I think that the biggest challenge is the effort and knowledge required to write a new graphical Lisa tool. And following that, which application should we do first? Telnet seems like the best choice to me.

[stepleton]

Telnet would not be hard from a UI perspective, relatively speaking. The QuickPort library provides text-in-a-window capability with very little effort beyond basic Pascal console I/O. You even get terminal emulation for free --- I think VT100 and Soroc.

[rayarachelian]

So after telnet, how hard would it be to do something like an ftp client? Doesn't have to be as good as ncftp but as long as it does binary and mget/mput, that would be fantastic, for example, you could use it to back up a whole ProFile.

[D.Finni]

The QuickPort library provides text-in-a-window capability with very little effort beyond basic Pascal console I/O.

That sounds like a great place to start.

So after telnet, how hard would it be to do something like an ftp client? Doesn't have to be as good as ncftp but as long as it does binary and mget/mput, that would be fantastic, for example, you could use it to back up a whole ProFile.

Now FTP is where it starts to get tricky, and this is a protocol which pre-dates TCP/IP and as a result has a lot of baggage. If your goal is to back up a ProFile, I think you'd be better off inventing your own protocol. Or just start reading and sending each 512-byte data block in sequence as soon as a client connects to the Lisa's listening TCP port.

Then to get fancy, you add an option to type in a filename on the Lisa, and then the program sends just that file on the TCP socket instead of the whole drive.

[stepleton]

There's a (predictable) additional issue that the Lisa FS has metadata that you won't find on other operating systems. Besides the usual stuff you see in a file listing (creation time, modification time, and so on), there's also "type" and "subtype" fields (reminds me of filetype and creator for Macintosh) (see PDF pages 36-38, 155, 184-186 of the Workshop 3.0 system software manual), and you can also have a "label" of up to 127 bytes (PDF page 46).

I don't know what anyone used these fields for, but when I made a (somewhat buggy) file downloading utility (which used YMODEM over a null modem cable instead of TCP/IP), my solution was to package everything on the fly into a tar archive with three "files" inside. One file was a text file holding the filesystem metadata, one file was the contents of the label, and the final file was the actual file contents.

The Lisa's format for text files is a little weird --- it's faintly block oriented (files are always sized in multiples of 1K, IIRC), and it uses run-length encoding for runs of spaces. I'm still trying to track down where I saw the format documented (the documentation calls it the "One World Text File Format" or something like that), but here's a bit of Python that can decode it.

Lastly, there is the issue of protected files, which the Lisa OS will refuse to let you open. These files are interesting ones like Pascal compiler (Pascal.obj) and the various tools. It's possible that this more recently-discovered mechanism for jumping into supervisor mode can offer a workaround.


(Since we were talking about it earlier: the system software manual has the programmer's documentation for the QuickPort library, PDF pages 336-392.)