Bernie ][ The Rescue 2.6
Communications
1. Introduction
2. Credits
3.1 Choosing a Port: Port Menu Items3.1.1. Port Setting "Off"3.1.3. Port Setting "Printer Port" and "Modem Port"
3.2.1. Automatic Port Speed
4. Baud
Rate And Protocol Options
4.1 Special Baud Rate Considerations
5. Handshaking
5.1. Software Handshaking5.2.1. Ignore DTR
6.1. Port Active
Communications support is one of the most challenging tasks for emulation software. With Bernie, communications support has been implemented using a very hardware-oriented approach offering compatibility with virtually all software accessing the Apple IIgs' serial port architecture. Please note that Bernie does not support AppleTalk at this time.
Bernie's serial communications support is referred to as CerealPuffs (aka serial ports), and the port administration code - that also manages Mac serial ports for InkDirect - is called MuesliPump. This section describes Bernie's CerealPuffs technology, how to configure the ports, emulation limitations, and performance tips.
Speed is everything with telecommunications. It means bandwidth and getting things done sooner. For emulation software, communication speed also stands for added overhead because the same signals, flags, and maintenance tasks have to be processed at extremely high frequencies. As an example, a connection at 28,800 baud not only implies a throughput of (max.) 3.5kB per second but also an insane emulation-specific overhead of 28800 interrupts per second, or just a mere 34 microseconds for completely dealing with an emulated interrupt cycle (plus doing regular stuff). This example shows why choosing a high connection speed does not always lead to the expected outcome. In fact, it can place such a burden on the system that your there's no time left for doing anything reasonable!
If you have questions regarding communications, feel free to go to contact the communications guy.
It is very unusual to put the credits at such a prominent place, but F.E.Systems owes a few people that kind of appreciation.
We would like to thank Richard Bennett for helping during the entire development cycle at a level that goes far beyond the usual Q & A support. Richard has written Marinetti, the popular TCP/IP software for Apple IIgs computers, and implemented the serial drivers for Seven Hills Software's commercial Spectrum communications software. Put briefly, he's the guy who knows answers to serial questions. And, honestly, without Richard offering his help, we're not sure if we had tackled serial communications at all.
We would like to thank Ewen Wannop - another Spectrum programmer - who is getting increasingly involved with Bernie's serial communications, and are looking forward to improving Bernie to meet Spectrum's needs.
Writing software with that kind of support is just more fun.
Configuring serial ports is a snap:
Bernie is emulating both the Apple IIgs printer and modem ports. Each of the two ports can be connected with any serial port or device on your Mac (serial ports, most internal modems, some PC cards, third-party serial cards, etc.). Bernie is offering three different ports:
(InkDirect is a low-level printing technology and discussed in a separate chapter.) Each of these emulated Apple IIgs ports can be associated with a Mac serial port.
A port can be either off or linked to a Mac port. There's a 1:1 relationship between Apple IIgs ports and Mac ports, that is, a Mac port can only be linked to a single Apple IIgs port and vice versa.
When you have chosen a Mac port for, say, the Apple IIgs printer port, that Mac port is dimmed in all other port selection menus. You can't select that Mac port for any other emulated port. If you would like to reassign the Mac port to another port, you need to reset the original connection first (by setting the port to off) and then make your new choice.
Redirecting output to a File - as the port selection menus suggest - is not yet implemented and always dimmed. Let's have a more detailed look at each of the settings:
When a port is set to "Off", Bernie will only service the port so the software sees a fully functional serial controller that is not connected with the outer world. This setting is, for example, sufficient for running Diversi-Tune that is using the serial controller for timing purposes but does not actually transmit or fetch any data (as long as MIDI is disabled.)
This feature is not yet implemented and always dimmed.
These two are most commonly seen port types and correspond to the two serial ports that are ingredients of most if not all desktop Macs.
This port is usually what you get with a PowerBook or a Duo without docking station/minidock.
Communication support is only available in registered versions of Bernie. If your copy is not registered, then the port menus will only show the "Off" setting and the dimmed "File" option. You can get the rest of the menu at a very fair price.
With Bernie, you can tell Bernie to choose a port speed for you automatically or select a specific baud rate. The baud rates for each port are independent of each other.
Since Bernie is emulating the Zilog communications controller, it knows very well what port speed your Apple IIgs is requesting. Thus you can tell Bernie with the Auto setting to set the Macintosh port to whatever baud rate the Apple II software is asking for. For example, if your telecom software configures your Apple IIgs modem port to run at 9,600 baud, Bernie would tell your Mac to establish a 9'600 connection on the Mac side.
Unfortunately, there are some rather unusual port speeds not support by the Macintosh. In that case Bernie is picking the next higher port speed.
If you have a fast Macintosh and you want to take advantage of your systems performance, the port speed menu lets you select a specific port speed. The speed you select will be the rate at which Bernie will actually communicate with the outer world. The advantage of overriding port speed is that you can feed your Apple II software much faster than it was originally designed for. And because Bernie is typically running much faster than a stock Apple IIgs, it is very likely your software can deal with it.
Please note that you often can't increase port speed to an arbitrary value. For instance, if you have a serial device that can't go faster than 9600 baud, you won't be able to communicate at higher baud rates than this.
Except for the linking of Apple IIgs Ports to Mac ports, the whole configuration of the serial ports is done through your Apple II communications software. Please refer to the documentation of your telecomm software of how to adjust the baud rate and protocol options (parity, data and stop bits).
Bernie supports:
Bernie does not support AppleTalk at this time.
For example, the configuration screen in ProTerm looks like this:
These settings will configure the ports for 4800 baud, 8 data bits, no parity, 1 stop bit.
Understanding handshaking requires a thorough understanding of how communication devices interact. Feel free to skip this discussion if you're new to Bernie or just don't want to bother with technical details. Please come back when you'd like to use a modem or network.
Whenever two persons or machines are communicating, people and machines must agree upon certain gestures or signals to indicate that communication can start.
Handshaking controls the flow of data between two devices. When one device is tinkering with the handshaking signal, the other knows that there is some problem on the other end and communication should be suspended until further notice. This may happen because the device must pay attention to something else, it encountered an error or the unexpected happened.
In the communications world, there are two commonly used methods of implementing handshaking: software handshaking and hardware handshaking.
Software handshaking is based on a convention between the sender and receiver. They agree on special characters that signal "I'm ready" or "stop sending me data". This method is simple and works pretty well, but it has the big disadvantage that there are special characters that may not be used within regular data packets because they would be interpreted as handshaking signals. Therefore, software handshaking may not be used for transmitting binary data (8 bits) but with ASCII text only. Text messages have the property of making use of only a very limited range of characters so that certain symbols are used for controlling data flow.
Software handshaking is also called "XON/XOFF handshaking".
If you need to transmit data with full 8 bits, there's a special line commonly referred to as "Data Terminal Ready", or DTR. DTR indicates whether a device is ready for communication or not. It basically does the same thing as software handshaking but is making use of a hardware signal.
The problem with DTR is that it is not really popular on the Mac to use DTR for handshaking. Modems for example are using the DTR line for something else: to hangup. (You really wouldn't want to hangup and redial every time your Apple II software is requesting a short time-out!) Therefore, Bernie features a number of methods for emulating DTR - this enables your Apple IIgs software to rely on DTR while offering compatibility with Macintosh serial devices.
The Communications panel in the Preferences window includes a popup menu for choosing a DTR emulation. This menu is valid for both Apple IIgs ports. Each option will be discussed in detail hereafter.
The "Ignore" setting is a brute force approach - handshaking will simply be ignored. This means that your Apple IIgs has no means to indicate to the sender that it should stop sending data.
The preferred option is full hardware emulation of the DTR signal. This means that a device will see a change in DTR when your Apple II software is accessing DTR.
While this option could be described as the only faithful DTR emulation, it assumes that the serial device knows what a change in DTR means. Unfortunately, most of today's modems are using DTR for a different purpose, namely for holding a connection alive. Asserting the DTR line does not affect handshaking but disconnects your connection completely which is not exactly what you wanted. Please consult your modem's manual to see if it supports DTR for handshaking.
Hardware emulation is the preferred choice if your serial device supports DTR handshaking.
If you are only transmitting/receiving text data, Bernie allows you to map hardware handshaking to software handshaking. Changes in the DTR signal will be mapped to their software handshaking equivalent, that is Bernie is sending XON/XOFF characters depending on the state of the DTR signal.
Software emulation is the preferred choice when sending ASCII text.
The last choice is "emulated DTR", a pretty sophisticated Bernie special. Instead of actually routing DTR information to the serial device, the DTR signal is processed entirely within Bernie.
A request to stop sending data is typically caused because the software needs some time to recover from a task or save the previous data to disk. Bernie starts buffering the incoming data until your Apple II software is back and ready to fetch more data.
The drawback of this method is that Bernie's buffer is rather small and tends to overflow itself soon. So this implementation does not work when your software needs a long time to recover. Bernie does use software handshaking when it can't buffer data any longer, but then the same limitations as described in "Software" above apply.
Emulated DTR is the preferred choice when your Apple II software can keep up with data flow and only rarely needs time to recover.
Serial communication is truly a bottleneck, that's why Bernie is optimizing a few steps to make it go real fast. Unfortunately, one or two applications make very strong assumption on how much data comes in and when there's time left to process it. Too many assumptions for our taste.
Bernie's compatibility mode is slowing down bandwidth but addresses these problems. Applications affected are ProTerm and ReadyLink.
If you are looking for a solid telecommunications software that has been fully tested with Bernie ][ The Rescue, we recommend you to check out Spectrum (commercial) and Marinetti (currently freeware). These two products are mature products and still being worked on.
The communications window gives you an overview of your serial connections. The window consist of two panels, one for each emulated port:
Rx = "Receiver" (incoming characters), Tx = "Transmitter (outgoing characters)
Next to the Port A/B is a LED that goes on when the port is "connected", that is, when you have linked it to a Mac port. You can activated a port in the Communications panel of the Preferences window.
The "RD" light turns green whenever a read operation is in progress. Bernie is then fetching characters from the Mac's serial port and passes them to the Apple II software.
The "TR" light turns green whenever a send operation is in progress. Bernie is then transmitting characters the Apple II software feeded into the serial controller and passes it onto the serial port.
With every connection, communication errors may appear and have to be dealt with. The communication error happens between the serial device and Bernie (and not between the Apple II software and Bernie). Bernie is detecting errors and passes this information on to the Apple II software. When an error occurred, the "ERR" light goes on and an error message appears in the LCD display below.
These two indicators show whether data is "flowing" or transmission has been suspended. If the DTR Handshake is on, incoming characters will be buffered but not delivered to the Apple II software. Plus, the sender will be notified of the change in DTR. (Note that the exact behavior of DTR depends on how you have configured DTR emulation.)
Analogously, Tx Handshake reflects the state of outgoing characters. If the Tx Handshake LED is on, no characters will be transmitted.
The LEDs show how many bytes are waiting to be delivered to the Apple II software (Rx) or the serial device (Tx).
Lastly, each port is featuring a small display. This display keeps you informed on:
As you remember from the introduction, speed is very critical and communications support requires a lot attention from the CPU. We have stated that the faster a port is running, the more overhead is produced which in turn may degrade performance and reliability (since there's no hardware handshaking yet.)
Several real-world experiments and feedback from users showed that a good communication speed is around 9600 baud. On first-generation Macs (60-80 Mhz), real-world throughput is around 6000 or 7000 baud, so it is pointless to choose higher connection speeds. Instead, talking at 7200 or 9600 baud is a real gain because emulation overhead will give your Mac more room to breathe and actually allows for a steady communication at Bernie's maximum bandwidth.
If you own faster Macs, you can extrapolate reasonable settings for your machine. For 150 Mhz Macintosh computers, you might well experience best performance at 32,800 baud - it is left as an exercise to the user to find the best setting. There are simply too many external factors (overall system speed, background tasks, third-party tools slowing down) that we can give you an ultimate recommendation.