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
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
