Faster Baud and More Serial Ports (CSI Hurdler, SerialDMA, QuadraLink)

[David Cook]

I recently acquired a CSI Hurdler II NuBus card that adds serial ports to the Macintosh. Using the card and upgrading it sent me down a rabbit hole.

When I received it, the CSI Hurdler indicated that it was a "dual" (HDS) serial port card, although it had all four ports soldered in place, along with some empty DIP sockets. Based on the existing chips, I guessed that it was missing an additional Zilog Z8530A SCC, (2) AM26LS32 line receivers, and (2) AM26LS30 line drivers. So, I added those. Unfortunately, that did not result in immediately converting the card to a "quad" serial port card.

I then reached out to @Byte Knight , who runs the Captain's Quarters II BBS with a quad (HQS) CSI Hurdler. He immediately sent me a copy of the ROM. (Thank you!!). Burning and installing the quad ROM indeed successfully finished the conversion of the dual card to a quad card.

The rear slot cover of the card only exposes two of the four serial ports. I simply unscrewed and removed the slot cover to access all four ports. However, I am considering drilling the other holes.

One of the nice features of the CSI Hurdler II is that it can double or quadruple the baud / bit rate that the application chooses. For example, if your terminal program is set for 57600, the CSI can secretly set itself for 115200 or 230400. These values were not originally supported by the Macintosh System Software and thus aren't listed in old terminal programs. CSI notes that many baud rates don't double nicely. For example, 38400 doubles to 76800 -- which is not a standard rate. Watch out for that.

With the Dual ROM installed, my CSI card offers the 2x option, but not the 4x option.

With the Quad ROM installed, my CSI card does not offer any speed increase.

This could be a limitation in the ROM, as my Dual ROM is a newer version. Or, it could be that the card itself is not fast enough to service the four ports at double speed. It turns out that CSI had two faster cards, the CSI Hustler and the CSI Lightening. These cards were capable of the faster speeds. I have not been able to locate either of these cards for purchase.


Updating Tiny Transfer

To make use of these extra ports (and extra speed), I updated my Tiny Transfer software to detect the ports and speeds. Detecting the ports was easy, as the naming convention simply continues from the standard Apple modem ('.AOut') and printer ports ('.BOut'), to CSI Hurdler 1 ('.COut'), etc. This makes it compatible with pre-Communications Toolbox operating systems.

Applied Engineering's QuadraLink serial card includes AE Shadow software to provide old-style serial ports, although theirs are named ".QuadraLink Port 1 OutC" (and so on). This is frustrating as the code needs to follow a different pattern to check for the ports. But, this is also good, as the names don't conflict with the CSI Hurdler. Theoretically, you can end up with 10 or more serial ports.



Faster Baud Slightly More Complicated

Detecting the ability for the Macintosh to use a faster baud rate is not as straightforward. Let's ignore the nice feature where the CSI Hurdler secretly doubles the chosen baud rate. Instead, what if the application really wants to directly offer 115200 or 230400? Apple's technical note TN 1018 "Understanding the DMA Serial Driver" illuminates the new Control calls to select the faster rate. If the Control call returns an error, then the rate is not available. Basically, you need a Centris 660AV or better to even have a chance that Apple's serial ports support the faster rates.

That's simple enough. But, the software needs to make these calls on all of the additional ports, because those are not Apple drivers and are running different hardware. So, the application may need to select a slower rate if the user switches ports.

I successfully got my software to run at 115200 on a Power Macintosh G3 connected to Basilisk II. But, even though the drivers did not return an error, I could not get it to talk at all at 230400. I tried using a different USB-to-serial cable without luck. Eventually, I connected a Power Macintosh 4400 to another Power Macintosh 4400, which ran successfully at 230400. So, I believe there is a 230400 baud bug or limitation in Basilisk II.

In the screenshot below, I got 4x the throughput on a Power Macintosh 4400 at 230400. The reason the speed only lists 88.37 kb/s, is that BinHex adds bloat and XModem doesn't have a sliding window which means the channel is not saturated. So, the effective speed is only 38%. It would be worse still on a slower Macintosh where the CPU can't keep up. I noticed the IIci on a CSI Hurdler double rate of 115200 was not effectively double 57600, due to the CPU bottleneck.

If I switched to a binary transfer with a sliding window protocol and fast compression on a fast CPU, then the effective throughput could exceed 100% of the baud. However, Tiny Transfer is designed for period compatibility, not maximum speed.


Not Out of the Woods Yet - Serial Driver Version

Oddly, my Power Macintosh 8600/300 did not support 115200 and 230400 baud, even though it is newer and faster than the Power Macintosh 4400. What's going on?

The technical note indicates that you can detect the driver version with a Status call. The version is a single byte.

Uh oh. Inside Macintosh Devices says the version is a word (a short, aka two bytes).

Let's see how to make a status call. Got it? Status(refNum, 9, &myByteOrShortVersion);

Making the Status call the naive way I describe above results in memory corruption. I just haven't played with Status calls enough to understand the weak documentation. It turns out that the Status call always copies a much larger structure (22 bytes) over to the provided pointer, even if the driver only populates a byte or a short. I made the choice to use the more complicated but definitive PBStatusSync (new naming convention) call with the full ParamBlockRec structure. Then, I read only the portion relevant to the serial driver version -- which is a byte (not a short).

After doing this, the Tiny Transfer About Box now includes the serial driver version:


Here's what I've found so far...

// Serial driver versions
// Version 0 is ROM based - not verified
// Version 1 is the RAM version - not verified
// Version 2 is the Plus ROM - not verified
// Version 5 in IIci with System 7.1
// Version 9 on PowerMac 7100 with System 8.1. Supports 115 and 230
// Version 9 on PowerMac G3 with System 9.2.2. Supports 115 and 230
// Version 10 on a PowerMac 8600 (604ev@300) with System 8.1. Doesn't support 115 and 230

That last line is the killer. The Power Macintosh 8600/300 has a newer driver (version 10) which dropped support for the faster baud rates. What?? I assume this was a mistake as the later G3 switched back to version 9. I need to try installing the Serial DMA extension from Apple to see if this will override the ROM version and restore the faster baud rates.

Files

Attached are the CSI Hurdler II ROMs, the TN 1018 Serial DMA note, and a link to the AE Shadow software.

- David

https://macintoshgarden.org/apps/applied-engineering-quadralink-ae-shadow

 

[joevt]

For the Power Mac 8600/300, you could use the driver to initialize the serial port, than add your own initialization to write directly to the serial port to enable 115.2 and 240.5 kbps.

Is there a way to get the addresses for the SCC registers of the CSI card using the drivers or accessing low memory globals? If not, then you would have to extract the .HQS DRVR from the "CSI_HQS_3.09B.BIN" Slot ROM and disassemble it to find the addresses.

It looks like the .HQS driver has hard coded driver names .CIn, .COut, .DIn, .DOut, .EIn, .EOut, .FIn, .FOut so you can't use two of these cards?

It looks like the .HDS driver has hard coded driver names .CIn, .COut, .DIn, .DOut so adding a second one of these cards would not add .EIn, .EOut, .FIn, .FOut.

What computer/serial port are you running Basilisk II? If there's a bug in Basilisk II then you can try a different app such as Serial.app.
https://www.decisivetactics.com/products/serial/
Or use a command in Terminal.app (cu or screen).
#3

 

[David Cook]

I broke out the oscilloscope to determine if something is wrong with Basilisk II. I believe there is.

First, here is a Quadra 840av transmitting at 230400. The RS-422 voltage only swings from 4.4V to -4.5V. That's within Apple's specs. The width of two bits measures 8.760 microseconds. (It was easiest to reliably measure the end of the start high bit, across a low bit, to the end of another high bit). So, each bit is 4.38 microseconds, which is approximately 228310 baud. Given that I measured by eye, I'd say that's 230K.

Now let's look at my PC running Hyperterminal at 230400. This is an RS-232 signal going from 9.5V to -9.8V. So, maybe the difference in voltage levels at such high speeds is the source of communication errors. The width of two bits is 8.68 microseconds. Which gives 230414 baud. That means the Mac and PC are close enough that there should not be a problem.

Now let's run Basilisk II at 230400 (same PC, same USB adapter). Uh oh, the width of two bits is 7.64 microseconds, which is 261780 baud. That's too fast.

 

[David Cook]

Welp, there's the problem. They are using 256000 baud because there doesn't seem to be a predefined CBR value for 230400 baud. I can't locate an answer online for generating the correct baud rate.

And another problem that I noticed, 14400 is missing. This is an easy fix.

 

[Byte Knight]

I then reached out to @Byte Knight , who runs the Captain's Quarters II BBS with a quad (HQS) CSI Hurdler. He immediately sent me a copy of the ROM. (Thank you!!). Burning and installing the quad ROM indeed successfully finished the conversion of the dual card to a quad card.

No problem - that Slotrom program you suggested worked slick! Didn't even have to break out the ROM burner...

Just for clarification, CQ II BBS runs on a Mac Mini via telnet connections all year round. I've used the CSI Hurdler in my IIci during #MARCHintosh to host a Hermes II BBS (called The Crow's Nest) with 6 wifi modems.

And I'm still holding out hope that you'll eventually host a BBS with the 4-port Hurdler!

 

[dougg3]

Welp, there's the problem. They are using 256000 baud because there doesn't seem to be a predefined CBR value for 230400 baud. I can't locate an answer online for generating the correct baud rate.

Interesting! It appears that the DCB structure also allows just setting it to an arbitrary number, according to Microsoft's docs. For example the CBR_115200 constant is simply defined as 115200. It might be worth trying to patch the code to see if assigning 230400 "just works" for you.

It does appear that the higher bit rate likely won't work on all hardware, though. My motherboard's built-in COM port doesn't accept 230400 or 256000 in PuTTY, but an FTDI USB-to-serial cable does. (I didn't test if the requested rate was actually applied though). So you might want to see if PuTTY allows you to open the port as 230400 with your hardware before trying.

 

[David Cook]

CQ II BBS runs on a Mac Mini

Ahh. That is much more practical.

It appears that the DCB structure also allows just setting it to an arbitrary number

I did not previously notice the line "This member can be an actual baud rate value"

 

[JDW]

David, I found your thread an interesting read!

What is your practical use-case for all that speed?

 

[Kai Robinson]

David, I found your thread an interesting read!

What is your practical use-case for all that speed?

Because.... Why not?

 

[JDW]

Because.... Why not?

Oh, so it's a "techno-geek experiment" then. I see.

I was just curious because when I do geeky things like overclock a motherboard, and that geeky act has certain key benefits for me in terms of computing power, performance, better game play, and the list goes on. I was just curious if that was true in this case of this faster serial ports thread.

Another example is the SCSI Booster clone created by @max1zzz , which is super duper techno-geeky stuff, but it has real-world benefits for anyone who uses a drive in a NuBus Mac (and who has a Radius Rocket too, of course).

This is not to say experiments and tinkering is bad. We are TINKERdifferent after all.

 

[David Cook]

What is your practical use-case for all that speed?

Lol. After I released Tiny Transfer, someone on the forum said "Hey! Did you know the serial ports can go faster?" So, I had that itch in the back of my mind. When I bought and upgraded the CSI Hurdler card, I knew I was going to have to code in the extra serial ports, but I then recalled the faster baud rates.

Some interesting things I learned:
1. I always assumed the error rate would increase with faster speed, given the amount of documentation from the early Mac days saying "9600 is what the ports are actually designed for". But, it turns out that I've never had a problem with any baud rate from the earliest to the newest vintage Mac. I think the problem was the protocol not allowing the old Macs enough time to perform writes.

2. By the time Apple implemented 115200 and 230400, local networks had given way to ethernet (etc) and modems still hadn't reached 56k. So, the faster serial speeds were not seriously exercised.

When repairing old computers, I find that I use Tiny Transfer all the time. Mainly it is used to transfer some driver software to the ZuluSCSI to test a new card, and then send screenshots back. The nice thing about it is that serial ports usually work, I don't need to care about what version of the operating system is being used, and that my target can be a SCSI drive/floppy drive/FloppyEMU. Rather than making sure I've got copies of all the needed utilities in all formats, I can just transmit whatever I'm missing at the moment.

Unfortunately, while I'd like to use the faster speeds now, I tend to work on 68K based Macs and only the AV pair support the faster speeds.

- David

 

[Mk.558]

David,

I love your work. You're the kind of person this community needs. I think I only used your program once or twice, but I have no doubt it's probably pretty slick for Pluses and earlier. You are correct that BinHex file transfers are slower: normally, I use FTP to transfer stuff from my 7.1 Macs to the G4 Mac mini, and the transfer speed is noticably slower with BinHex versus some Binary file. I should probably add two lines comparing the two in the Data Transfer Rates section...

However I'm not moving off BinHex as a preservation method on foreign file systems because of one reason: compatibility. MacBinary II requires System 6 or higher, which cuts off the 128K, the 512K and 512Ke can do it, but not comfortably. In addition, it's just a text file, and that has other methods of exchange (any one remember embedding a binhex file in an email message?).

Would you by chance be interested in another project? We don't have any software programs to help align and check floppy drives. SonyTest, off the Macintosh Garden, probably only works with the 128K/512K and 400KiB MFS drives. We're reduced to guesswork and cross-checking with other floppy drives.

What is your practical use-case for all that speed?

You'll be thinking about this speed once you try to transfer a 300KiB file over at 9600bps As shown in the Data Transfer Rates section (link below), a 512Ke using MacTerminal 1.1 at 19200bps with an XModem file transfer is about 0.488KiB/sec, and that's the download speed. The internal floppy drive is about 10 times faster, but then you're looking at the problems with floppies.

Most LocalTalk speeds are either 10KiB/sec or 20KiB/sec. The first is roughly 115200bps, the latter is close to 230400bps. If that's too fast, well, the early versions of MacTerminal can go down to 50bps. Good luck.

 

[JDW]

David,
I love your work. You're the kind of person this community needs.

He sure is. David is absolutely brilliant and a very kind person too. Thanks for being an important part of this forum, David!

You'll be thinking about this speed once you try to transfer a 300KiB file over at 9600bps

Meaning, the "practical use case" is "file transfers."
I appreciate that. When transferring via SERIAL between 2 vintage Macs with serial ports, by way of David's Tiny Transfer app, the benefit of all that speed is clear.

David also mentions here that "USB serial" can be used with a modern computer. I've not tried that, but I assume you would just need a USB-to-serial adapter for your modern Mac to connect to the vintage Mac's serial port, then use the Tiny Transfer app on the vintage machine and a "terminal application" on the Mac? Being able to take advantage of increased serial speed with a modern computer is certainly something of interest.

 

[Mk.558]

yeah

I write all about that below. I haven't kept up on serial transfer stuff for Windows/Linux/OS X since 2015 which is when that whole section was written, that was Windows 7 days. But any compatible XModem/ZModem/ASCII capable program can do it on the more modern machine. The limitation is really the vintage mac: you'll find that beyond 57600bps on 68030 hardware is where things can get interesting because the CPU isn't fast enough to keep up with it. DMA serial chipsets like on the Quadra 840AV and other machines doesn't have that problem, but those all support Ethernet.

In general, unless you have a 128K, you're much, much better off using AFP. An AppleTalk bridge for 512K, 512Ke, Plus, Classic, Portable, Classic II machines and anything else that doesn't have an Ethernet option available to you, and Ethernet for everything else, is not only faster, but more convenient. Particularly with Netatalk 4.0, it's the way to go.

However, this may not always be available to you. This is why I made Network Access Disks compatible with all the older Macs: aside from the one meant for a 128K, they all come with AppleShare, MacTerminal, so if you have a serial port open, you can jumpstart your system. All of them come with BinHex 4.0 and either PackIt and/or MacBinary II.

 

[David Cook]

However I'm not moving off BinHex as a preservation method on foreign file systems because of one reason: compatibility. MacBinary II requires System 6

I agree. Despite the increase in size, BinHex 4 has stood the test of time!

We don't have any software programs to help align and check floppy drives. SonyTest

I was not aware of this. I'll download it and take a look.

- David

 

[David Cook]

"USB serial" can be used with a modern computer. I've not tried that, but I assume you would just need a USB-to-serial adapter for your modern Mac to connect to the vintage Mac's serial port, then use the Tiny Transfer app on the vintage machine and a "terminal application" on the Mac?

Yes, you can do that. But, better still, run Tiny Transfer on the vintage Mac and run Tiny Transfer in Basilisk II on the modern Mac.

 

[David Cook]

In general, unless you have a 128K, you're much, much better off using AFP. An AppleTalk bridge for 512K, 512Ke, Plus, Classic, Portable, Classic II machines and anything else that doesn't have an Ethernet option available to you, and Ethernet for everything else, is not only faster, but more convenient. Particularly with Netatalk 4.0, it's the way to go.

I agree. For bulk transfers, your approach and ZuluSCSI sneakernet are faster and more convenient.

I just saw the enormous write-up you did for networking old Macs. Bravo!

 

[JDW]

...run Tiny Transfer on the vintage Mac and run Tiny Transfer in Basilisk II on the modern Mac.

So...
We should the following?

1. Connect one end of a normal Mac serial cable to the vintage Mac.
2. Connect the other end to a serial-to-USB adapter, then connect the USB plug into the modern Mac.
3. Launch Basilisk II (System 7.1? 7.5.5?), then launch TinyTransfer from within Basilisk II.
4. Launch TinyTransfer on the vintage Mac to transfer files in either direction, from either Mac.

I've not tried any of that. Just wanted to confirm if that's the proper way of going about it. If it is that simple, that's awesome!

 

[David Cook]

I've not tried any of that. Just wanted to confirm if that's the proper way of going about it. If it is that simple, that's awesome!

Almost. You just need to put a null modem adapter between the two cables.

Because you are a 128K fan:

 

[Mk.558]

I did a comparison test with FTP yesterday, results are in the Data Transfer Rates section.

MacBinary II (transferred as raw data, in the Binary mode) encoded files are indeed faster to send over the wires. You get about a 10% speed hit, ish, by using BinHex encoded ASCII files. I don't think that is really a big deal with smaller files.

By your estimation, how much extra bloat would be added to Tiny Transfer if it supported MacBinary II?