I have been attempting to connect my IIGS to a Raspberry Pi so that I can access telnet BBSs. Hopefully, one of you smart guys can see what I have been doing wrong.
Where to begin?
Since this (TCPSER) is supposed to be emulating a Hayes modem, my assumption is that if I type in "AT", I should get the "OK" response. Is this what you see? I am getting no echo from the modem on my keyboard entry so I have to believe that there is a communication problem, which may or may not be hardware (cable) related.
I thought that the problem was in the cable.
I found the following in a text file created by TCPSER author Jim Brain.
File located at: http://mirrors.apple2.org.za/ground.icaen.uiowa.edu/News/tcpser
"Existing null-modem cables can be used with TCPSER, though TCPSER uses
the DTR line on the PC/workstation to emulate the DCD modem signal. Null
modem cables normally tie DCD and DSR together. If proper DCD support
is required and DSR must be high on the target platform, a small cable
modification that disconnects DSR from DCD and bridges to DTR may be
required. On target systems that float DSR high, simply pulling the DSR
pin on the null modem cable end that attaches to the target computer
will suffice."
DSR is not assigned to the 8-pin mini-DIN from the IIGS serial ports (RS-422) so it should not present a problem in this configuration.
So, using pinout on the ADTPro website, I built the following cable.
(http://adtpro.sourceforge.net/connectionsserial.html)
Apple
MiniDIN8 DE-9 RS-232
Pin# Pin# Name
-------- ---- ------
5 ----- 3 TxD
3 ----- 2 RxD
4 --,-- 5 GND
8 --'
1 ----- 8 CTS
2 --,-- 7 RTS
'-- 4 DTR
7 ----- 1 DCD
No luck. Attempting communication with TCPSER at various modem speeds yielded nothing valuable. I have not ruled out the cable, however.
As for the RasPi end, I have a USB-to-DB9 serial adapter that appears to be properly installed.
pi@raspberrypi:~ $ dmesg | grep usb
[ 0.639442] usbcore: registered new interface driver usbfs
[ ...
[ 13.156093] usbcore: registered new interface driver usbserial
[ 13.156223] usbcore: registered new interface driver usbserial_generic
[ 13.156347] usbserial: USB Serial support registered for generic
[ 13.251372] usbcore: registered new interface driver ftdi_sio
[ 13.251618] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 13.398961] usb 1-1.4: Detected FT232RL
[ 13.412782] usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB0
I guess the first thing to do is describe how I have been invoking TCPSER modem emulation.
I had been calling it at startup by entering the following line in /etc/rc.local:
tcpser -d /dev/ttyUSB0 -s 2400
I have tried both turning hardware handshaking on and off...
HARDWARE HANDSHAKING ON
tcpser -d /dev/ttyUSB0 -s 2400
On my IIGS, I have the modem port set to the following settings:
Device Connected: Modem (DEFAULT)
Line Length: Unlimited (DEFAULT)
Delete first LF after CR: No (DEFAULT)
Add LF after CR: No (DEFAULT)
Echo: No (DEFAULT)
Buffering: No (DEFAULT)
Baud: 2400
Data/Stop Bits: 8/1 (DEFAULT)
Parity: None (DEFAULT)
DCD Handshake: Yes (DEFAULT)
DSR/DTR Handshake: Yes (DEFAULT)
XON/XOFF Handshake :No (DEFAULT)
HARDWARE HANDSHAKING OFF
tcpser -d /dev/ttyUSB0 -s 2400 -i "&k0"
On my IIGS, I have the modem port set to the following settings:
Device Connected: Modem (DEFAULT)
Line Length: Unlimited (DEFAULT)
Delete first LF after CR: No (DEFAULT)
Add LF after CR: No (DEFAULT)
Echo: No (DEFAULT)
Buffering: No (DEFAULT)
Baud: 2400
Data/Stop Bits: 8/1 (DEFAULT)
Parity: None (DEFAULT)
DCD Handshake: No
DSR/DTR Handshake: No
XON/XOFF Handshake : Yes
I have also tried swapping the control lines by adding "&c0" to the initialization string under both conditions with no success, as was suggested by CWJ_WILCO.
I am using terminal mode in ProTERM 3.1 to communicate with the emulated modem. I set the "Online-Parameters" to:
2400 bps
8N1
Full duplex
No Emulation
Online
I have not attempted to specify flow control parameters since I have toggled XON/XOFF in the serial (modem) port appropriately. ProTERM 3.1 documentation allows the following acceptable entries for the FLOW OFF/FLOW ON fields:
Notation Method Meaning
^char Software Send CONRTOL-char
char Software Send char
R0 Hardware Drop RTS
R1 Hardware Raise RTS
D0 Hardware Drop DTR
D1 Hardware Raise DTR
Standard XON/XOFF is CTL-Q/CTL-S [ASCII DEC 17/19 (HEX 31/33)]. I can find no documentation for TCPSER that indicates a non-standard XON/XOFF handshake might be required.
Again, emulating a Hayes modem, my assumption is that if I type in "AT", I should get the "OK" response. I am getting no echo from the modem on my keyboard entry and no response from an entry of "AT".
Next, attempted to invoke TCPSER from the command line instead of the startup script. I turned on the verbose debug output and got the following:
pi@raspberrypi:~ $ tcpser -d /dev/ttyUSB0 -s 2400 i "&k0" -l 7
2016-08-19 20:47:04:-1225658368:DEBUG:Read configuration for 1 serial port(s)
2016-08-19 20:47:04:-1225658368:ENTER_EXIT:Exitting init function
2016-08-19 20:47:04:-1225658368:ENTER_EXIT:Entering ip_init_server_conn function
2016-08-19 20:47:04:-1225658368:DEBUG:Creating server socket
2016-08-19 20:47:04:-1225658368:DEBUG:Binding server socket to port 6400
2016-08-19 20:47:04:-1225658368:INFO:Server socket bound to port
2016-08-19 20:47:04:-1225658368:INFO:Server socket listening for connections
2016-08-19 20:47:04:-1225658368:ENTER_EXIT:Exitting ip_init_server_conn function
2016-08-19 20:47:04:-1225658368:ENTER_EXIT:Entering dce_init_conn function
2016-08-19 20:47:04:-1225658368:ENTER_EXIT:Entering ser_init_conn function
2016-08-19 20:47:04:-1225658368:ENTER_EXIT:Entering ser_get_bps_const function
2016-08-19 20:47:04:-1225658368:DEBUG:Checking speed: 2400
2016-08-19 20:47:04:-1225658368:ENTER_EXIT:Exitting ser_get_bps_const function
2016-08-19 20:47:04:-1225658368:INFO:Opening serial device
2016-08-19 20:47:04:-1225658368:INFO:Opened serial device /dev/ttyUSB0 at speed 2400 as fd 8
2016-08-19 20:47:04:-1225658368:INFO:serial device configured
2016-08-19 20:47:04:-1225658368:ENTER_EXIT:Exitting ser_init_conn function
2016-08-19 20:47:04:-1225658368:ENTER_EXIT:Exitting dce_init_conn function
2016-08-19 20:47:04:-1225658368:DEBUG_X:Waiting for incoming connections and/or indicators
2016-08-19 20:47:04:-1227479968:ENTER_EXIT:Entering run_bridge function
2016-08-19 20:47:04:-1227479968:DEBUG_X:CTRL thread ID=-1237322656
2016-08-19 20:47:04:-1227479968:DEBUG_X:IP thread ID=-1245711264
2016-08-19 20:47:04:-1227479968:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2016-08-19 20:47:04:-1227479968:ENTER_EXIT:Entering dce_set_control_lines function
2016-08-19 20:47:04:-1227479968:DEBUG_X:Setting CTS pin high
2016-08-19 20:47:04:-1227479968:DEBUG_X:Setting DCD pin low
2016-08-19 20:47:04:-1237322656:ENTER_EXIT:Entering ctrl_thread function
2016-08-19 20:47:04:-1245711264:ENTER_EXIT:Entering ip_thread function
2016-08-19 20:47:04:-1237322656:ENTER_EXIT:Entering dce_check_control_lines function
2016-08-19 20:47:04:-1227479968:ENTER_EXIT:Exitting dce_set_control_lines function
2016-08-19 20:47:04:-1227479968:ENTER_EXIT:Entering mdm_disconnect function
2016-08-19 20:47:04:-1227479968:INFO:Disconnecting modem
2016-08-19 20:47:04:-1227479968:INFO:Disconnecting
2016-08-19 20:47:04:-1227479968:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2016-08-19 20:47:04:-1227479968:ENTER_EXIT:Entering dce_set_control_lines function
2016-08-19 20:47:04:-1227479968:DEBUG_X:Setting CTS pin high
2016-08-19 20:47:04:-1227479968:DEBUG_X:Setting DCD pin low
2016-08-19 20:47:04:-1227479968:ENTER_EXIT:Exitting dce_set_control_lines function
2016-08-19 20:47:04:-1227479968:ENTER_EXIT:Exitting mdm_disconnect function
2016-08-19 20:47:04:-1227479968:ENTER_EXIT:Entering mdm_parse_cmd function
2016-08-19 20:47:04:-1227479968:DEBUG:Evaluating AT
2016-08-19 20:47:04:-1227479968:DEBUG:Command: (-1), Flags: -1, index=0, num=0, data=0-0
2016-08-19 20:47:04:-1227479968:DEBUG:Sending OK response to modem
2016-08-19 20:47:04:-1227479968:DEBUG_X:Sending text response
2016-08-19 20:47:04:-1227479968:DEBUG_X:Waiting for modem/control line/timer/socket activity
2016-08-19 20:47:04:-1227479968:DEBUG_X:Command Mode=1, Connection status=0
SUMMARY:
Port opened at (default) 6400 for TCP socket.
Serial device opened at /dev/ttyUSB0 at 2400 bps.
Control line check appears to pass, although the initial condition of CTS and DCD are exactly what the test condition result should be so this test really doesn't prove anything.
Modem is reset and control lines reset.
It appears to be sitting idle, waiting for a connection.
I think that I have provided a pretty good synopsis of where I am at. I hope one of you fine fellows may have an idea or two while I try to sort this out in my own head.
Hey again therelic, sorry that you're still having trouble with this!
Your assumption is correct. When all is working as it should, typing AT will cause the modem to answer OK.
I noticed in the IIgs settings you were trying XON/XOFF handshaking. Turn this OFF. I've never had any luck with it, and it's not needed in a modern context. &k0 in the modem string tells TCPSER not to use hardware handshaking, while &k3 and &k4 tells it to use RTS/CTS and XOFF/XON flow control, respectively. Just set it to &k0 and never change it (in my opinion).
Unless that fixes everything, I guess now it comes down to troubleshooting.
For the purposes of troubleshooting, turning off hardware control means that you need only focus on the RX and TX lines, as they are the only ones being used (and ground).
Firstly, independently test the IIgs serial port by performing a serial loopback test. By connecting the IIgs TX line to the RX line, you should see an echo of whatever characters you are typing into ProTerm. If you are using hardware handshaking you may also need to connect CTS to RTS and/or DTR to DSR. More info here: http://www.ni.com/tutorial/3450/en/
If you see an echo of your typed characters - great! The IIgs serial port is working and configured correctly. Note that the IIgs echo setting set to NO means that you will only see one character per character typed - if set to YES, typing a character will produce ttwwoo cchhaarraacctteerrss lliikkee tthhiiss.
You can perform the same loopback test with the USB to Serial port on the Pi. I have been let down with USB to Serial converters in the past, so it's worth checking. On Linux you can use minicom to bring up a terminal program, or if using Windows you can just use putty. Exactly the same process, connect TX to RX and look for an echo.
If that works, at this point, you can confirm that both serial ports are working as they should. This is more of a sanity check than anything else, and it really helps to rule both of these out as problems.
Next, check the cable that you are using. Never trust that the cable is working, or even that it was sold to you as described (i.e. null modem or not). Using a multimeter or continuity tester, make a note of every pin on each end of the cable, and check to make sure that each pin leads to where it should. Make sure that TX/RX are or aren't reversed, depending on whether you are using a null modem cable. Check for any shorts that may have occurred. Be very patient with this and check everything twice.
(Note - I was so paranoid about the first serial cable that I tried on my //e that I actually ended up building my own, to be certain that everything was as it should be. Simply gather up the required wires in different colours and solder a DB9 and DIN8 plug at each end. You can also use a serial breakout board to easily swap physical lines, or add in LEDs to check whether data is being sent over TX and RX, etc).
If the cable looks good, reconnect everything again. This time, ignore TCPSER for the moment, and load ProTerm on your IIgs and minicom or putty on Linux or Windows respectively. I suggest trying this on both a Linux AND Windows machine to rule out any OS specific problems. You should also try another terminal program on the IIgs to rule out problems with ProTerm specifically - I suggest ZLink, a bare-bones terminal that can even load a saved configuration automatically on boot, saving time.
With BOTH terminals alive on each computer, you should now be able to type characters into one and see them appear on the other, and vice versa. Check this thoroughly and make sure that each terminal can read and write your typed characters, even try different baud rates and data/stop bit settings. Obviously without TCPSER, typing AT will not generate OK - this is pure serial communications with no middle-man.
If that works, you know that the physical connection between each machine is solid. Thus, the problem must lie in TCPSER. Again to rule out problems with the OS, I would try running TCPSER under Windows, or you could try a different modem emulation program such as Commodore BBS Server (still works for Apples!) or tcpser4j. I recommend Commodore BBS Server, especially for troubleshooting, as it has 'virtual' LEDs for each of the lines, showing activity, and the GUI is a little easier to manage sometimes. It does have some stability problems though.
At this point, you need to try every configuration possible until you come across something that works. You know that the physical connection is solid, so it's all up to software. On my Apple //e, for some inexplicable reason, setting Data/Stop bits to 7/1 on the //e side only will sometimes be more stable than matching 8/1 on both sides of the connection. Literally, exhaust your configuration options.
If you still have no luck, there are still some things that you can try, for the sake of a sanity check. For instance, you could connect your Pi running TCPSER to another modern desktop computer with a second USB to Serial converter, or better yet, to another (older) PC with an actual serial port. In this configuration, if TCPSER started responding with OK, the problem may lie deeper inside the IIgs.
That's about all I can think of for now, do hope you get it working!
Thanks, CWJ_Wilko.
You've given me a good plan to follow starting with the loopback test. I really appreciate the advice and now it's time to get to work.
therelic
Quick update:
1) Cable (null modem) continuity: VERIFIED
2) IIGS loopback test (cable included): VERIFIED
3) RasPi USB-to-Serial dongle loopback test: VERIFIED
4) RasPi-to-IIGS direct serial communication (bi-directional): VERIFIED
I'm going to get back to it in the morning. It's bedtime.
Checking back in...
First, let me say that I haven't solved the problem with TCPSER. After more than a week of research and experimentation, I have had some success to report but operational function remains elusive.
TCPSER requires a null modem cable, according to Jim Brain. I started out using the cable described earlier that I built to the wiring description on the ADTPro website. I ran several tests, as suggested by CJW_WILCO.
* Cable continuity and isolation: VERIFIED
* Loopback
- IIGS with cable (at DB9): VERIFIED
- RasPi USB-to-RS232 dongle (at DB9): VERIFIED
* RasPi-to-IIGS direct serial communication (bi-directional): VERIFIED
Next, I tried connecting through my terminal program (ProTERM 3.1) and communicating with the TCPSER ethernet modem. At 1200 and 2400bps, I was getting no response from an "AT" command. At 4800bps, I was getting my screen filled with both high and low ASCII characters. I was able to repeat these results multiple times. At 9600bps, I was seeing characters in the terminal as I typed "AT" but the characters returned from TCPSER were different. Also, the response was two characters so I think it was trying to reply with "OK".
I played with the various data-parity-stop bit combinations at 9600bps but was unable to improve anything.
I really started questioning the cable thinking that it may not be suitable for this operation. As I previously stated in a prior post, I was using the null modem cable described on the ADTPro website. Jim Brain's text file suggested that all null modem cables are not created equal so there was legitimate cause for concern.
While researching the cable configuration, I ran across some references to a Lantronix device, UDS-10, which was being used in the same way as the RasPi. I purchased a UDS-10 on eBay for under 10 bucks which, if it were to work, would be an even cheaper solution than the Raspberry Pi. The UDS-10 is a single-port server that can be configured to behave as a Hayes-compatible modem. The device is about as big as a pack of cigarettes. It has an RS-232 (DB25) port on one end and an ethernet (RJ45) port on the other. More on this the UDS-10 later.
I needed more information on the IIGS modem port. Apple's signal naming on the 8-pin serial port bares little resemblance to RS-232C. I reviewed the Hardware and Firmware references but there was no information equating Apple's signal names with its RS-232C counterparts. After a couple of days of fruitless searching, I started looking for Macintosh serial port information. I struck gold here: http://terpconnect.umd.edu/~zben/mac/MacSerHard.html
In the meantime, I received the UDS-10, which is supposed to work with a hardware handshaking (CTS/RTS) cable. The unit I purchased was used and probably installed as a network interface to an industrial PLC. The UDS-10 has a fixed IP address so it had to be reconfigured for my LAN. There are a couple of ways to do this. First, there is a Windows device installer. That let's me out since all I have are Linux and Macintosh boxes. I thought about installing Windows as a virtual machine but was concerned that was just one more complication that I preferred to avoid, if at all possible. The other method uses the serial port. I used a straight thru modem cable (DB9-to-DB25) connected to the Raspberry Pi and PuTTY serial terminal to obtain the MAC address, and assign an IP address, Baud rate, etc. I followed the instructions that I found in a PDF posted here:
http://atariage.com/forums/blog/567/entry-10980-what-is-the-lantronix-uds-10-and-what-can-it-do-for-me-modified-82315/
PDF instructions: http://atariage.com/forums/index.php?app=core&module=attach§ion=attach&attach_id=364106
Lantronix UDS-10 Manual: http://www.lantronix.com/wp-content/uploads/pdf/UDS10-UDS100_UG.pdf
The main settings that need to be configured in the UDS-10 besides assigning your IP and entering the LAN information (gateway IP and subnet mask) are:
BAUD RATE: 9600
I/F MODE: 4C (8N1)
FLOW: 02 (HARDWARE CTS/RTS)
CONNECT MODE: D6 (MODEM MODE - ACCEPT INCOMING UNCONDITIONALLY AND ECHO)
A better explanation of all possible configurations and using the Setup Mode can be found in the UDS-10 manual linked above.
My existing IIGS modem cable was built to Oggman's (Paul Parkhurst) specification for HST and HST Dual Standard Modems. In combination with Guy Rice's Fastport CDA, you could connect to a GBBS system with Oggman's 19200/38400 mod and take full advantage of the on-the-fly hardware compression available in the HST modems. I assumed that I would be in business but was mistaken. Again, I was getting no reply from the UDS-10 just as I first experienced with the RasPi/TCPSER setup. I wanted to check the cable against Oggman's pinout so I went looking for his description of the cable online only to come up empty. I was certain that I had archived it so I dug through my floppy collection and, after emptying a couple of file boxes full of 3.5's, scored.
I will attach Oggman's HST info, which includes the modem cable pinout, to this post. It's an interesting read, if you haven't seen it before. I rang out the cable and it complied so now I was really left scratching my head.
I returned to the file referenced above (http://terpconnect.umd.edu/~zben/mac/MacSerHard.html) which described the serial port signals and various cable configurations for connecting devices to the IIGS serial port. Finally having something to work with, I built the following basic cable described as Mac-to-modem WITH hardware handshake:
I tested the cable from ProTERM and the UDS-10 responded with "OK" following an "AT" command. I tried dialing a telnet BBS but it seemed to hang. I was not getting any data from the host system. A minor success (partial function) but still not there.
I suspected that something was missing and that it was related to one of the three signals not included in my cable - CD (Carrier Detect), DSR (Data Set Ready), and DTR (Data Terminal Ready). CD is used to hang up after a lost carrier so it seemed to me that this was probably not root cause for lack of data from the host. It made more sense that DTR (my IIGS would be the terminal at this point) was causing the problem so I wrapped around DSR and DTR by shorting their respective pins on the DB25 termination. Problem solved.
The one downside is that the UDS-10, unlike the Raspberry Pi, cannot resolve IP addresses from domain names so that has to be done from another computer. It's a minor inconvenience, IMHO.
The pinout for the working UDS-10 modem cable is:
The IIGS serial port settings are as follows:
Device Connected: Modem (DEFAULT)
Line Length: Unlimited (DEFAULT)
Delete first LF after CR: No (DEFAULT)
Add LF after CR: No (DEFAULT)
Echo: No (DEFAULT)
Buffering: No (DEFAULT)
Baud: 9600
Data/Stop Bits: 8/1 (DEFAULT)
Parity: None (DEFAULT)
DCD Handshake: Yes (DEFAULT)
DSR/DTR Handshake: Yes (DEFAULT)
XON/XOFF Handshake :No (DEFAULT)
Now that I had a working cable, I tried connecting it to the RasPi with a null modem adapter inserted in the cabling chain. I experienced partial success, much like I did with the UDS-10 prior to shorting pins 6 and 20. I had been using a wifi adapter on my RasPi so I retried the setup with CAT5 cable and no wifi adapter. Unfortunately, there was no resulting change.
I ordered a couple of modem cables for $3.66 each. They weren't much more expensive than the mini-DIN8 connectors from Digi-Key (PN CP-2080-ND) and I don't have to go through the bother of terminating the mini-DIN end. I'll cut the DB25 off and install a DB9 to mate with the USB-to-RS232 dongle. I think I have a pretty good starting point with what I've learned about the IIGS serial port. With some luck, I'll work out a functional null modem cable. I really need to get it working with the RasPi/TCPSER setup because I won't be able to rest until then.
Here is the Oggman HST text file (actually 3 files combined) mentioned in the previous post:
How to get
S P E E D
out of your HST and HST Dual Standard Modem
using
ACOS Version 2.01d5
and an Apple IIGS
-------------------------------------------------------------------------------
Brought to you by The Oggman, creator of OGG-Net Networking Systems
Call Infinity's Edge (415) 820-9401 or any OGG-Net BBS
-------------------------------------------------------------------------------
HST Basics
----------
Those of you who have spent big bucks on the HST modem, hoping to get 14.4K bps, have probably been disappointed, misled, or both. When used with ACOS, the HST will only get throughput of 9600 bps with NO COMPRESSION. Why is this? Well, its actually pretty simple.
When you're dealing with high speed modems, you have to differenciate between "connect rate" and "DTE rate." Connect rate is the speed in which both modems are talking with each other. You can get the connect rate by looking at the number after the CONNECT message (ig 1200, 2400, 9600) or by looking up the numeric result code. DTE rate is the rate at which the serial port is set at when it makes the call.
HST's can be communicated to with DTE rates of up to 38400 bps. This means that, even though its only (!) a 9600 bps modem (so to speak), you can actually send commands to it at baud rates of up to 38400. In normal operations, the DTE rate will drop down to the connect rate as soon as the modem completes a call to the other modem.
Compression and 14.4K
---------------------
In order to use V.42 or MNP Level 5 data compression, THE DTE RATE HAS TO BE HIGHER THAN THE CONNECT RATE. Likewise, to get actual throughput of higher than 9600 bps (12K, 14.4K), the DTE rate will have to be higher than 9600. So, for the Apple, this generally means your serial port will HAVE TO STAY AT 19,200 BAUD.
Do you see the problem? ACOS autobauds the serial port to whatever the connect rate is. If someone connects at 9600 baud, then the serial port is set to 9600 baud, making data compression and high speed totally useless. So, what to do about this problem?
Making the Change
-----------------
To make your HST operate at its optimum efficiency, you'll have to fix the DTE rate of your modem and make a little change to your ACOS.OBJ file. First, run the CONFIG.SYS program and choose GS Modem Port and the HST modem (sorry, I haven't deciferd what to do for the SSC yet. Maybe later). Change the init string so &D2 is replaced by &B1 (&D2 does absolutely nothing), and the X6 is changed to X4. &B1 will fix your modem's DTE rate. Pick 19200 for the default baud rate. You should also make sure your NVRAM settings include &K1 and &H1. These settings are needed for data compression and flow control.
Now, load BASIC.SYSTEM and type the following:
bload acos.obj,a$800 (loads the ACOS.OBJ file)
call -151 (enter monitor)
ff0:ea ea ea ea ea ea (make the change)
bsave acos.obj,a$800,l$5300 (save it)
Now, all you have to do is run your board and you're set. The modem will fix its DTE (the &B1) at 19200 (the default baud rate). When someone calls, ACOS will no longer reset the DTE rate to the connect rate, but keep it at 19200. Info(2) will still contain the connect rate/300, however.
Warp Speed on the HST
---------------------
So, now we have our HST's zooming along with a fixed DTE rate of 19200. This is the best we can get, right? Well, we know that the HST will operate at DTE rates of up to 38400 baud, but the Apple IIGS serial port will only go to 19200. Or will it?
Well, very recently, Apple guru Guy T. Rice came out with a little CDA called Fastport GS 38.4 that will actually open up the Apple IIGS modem port at 38400 baud. It appears that 19200 is only a firmware limit, not a limit of the SCC chip. After decifering Mr. Rice's little desk accessory, I mananged to incorporate it into an ACOS mod that will actually fix the DTE rate of the modem port to 38400, allowing the maximum throughput of the HST for ACOS 2.0d5 bulletin boards.
WARNING: Even with a 7 mhz Transwarp GS card installed, 38400 baud is VERY fast and you'll probably get dropped characters. This might not be a problem once we get 10 or 13 mhz out of our amazing machines, but until then, do this mod with caution. I personally have found no problem with this mod on my 6.25 mhz GS.
First, run CONFIG.SYS just as above making the same changes. Run BASIC.SYSTEM and type the following:
bload acos.obj,a$800 (loads the ACOS.OBJ file)
call -151 (enter monitor)
ff0:ea ea ea ea ea ea (make the change)
ffd:20 30 10 ea ea ea ea ea ea ea ea ea ea
1030:78 a9 0c 8d 38 c0 a9 01 8d 38 c0 a9 0d 8d 38 c0 a9 00 8d 38 c0 60
bsave acos.obj,a$800,l$5300 (save it)
Calling Out
-----------
As a BBS user, you will also have to do your part in getting the best throughput for your HST.
First, you will also have to fix your modem's DTE rate to the highest baud rate possible (19200 normally, 38400 using the Fastport CDA). To do this, set your baud rate at its highest level, and type AT&B1&K1&H1 and return while in the terminal mode of your term program.
Now for the hard part. Proterm and most every other term program for the Apple has the same problem that ACOS has; it autobauds. I don't have a quick fix for this, but you can get around it. Just call the HST board with a baud rate of 19200 (or 38400). It will connect at 9600 like normal. Once it connects, however, change the baud rate back to what it was. In Proterm, do an OA-O and put it back to 19200. If you have the Fastport CDA installed, activate it once you connect with the HST board.
That should do it. If you have any questions, I can be reached at my board Infinity's Edge (user #1) or through any board in the OGG-Net network.
Paul Parkhurst
The Oggman
==============================================================
How to get
S P E E D
out of your HST and HST Dual Standard Modem
using
ACOS Version 2.01d5
and an Apple IIGS
<==== PART II ====>
-------------------------------------------------------------------------------
Brought to you by The Oggman, creator of OGG-Net Networking Systems
Call Infinity's Edge (415) 820-9401 or any OGG-Net BBS
-------------------------------------------------------------------------------
Flow Control Problems
---------------------
Those of you who have made the ACOS mod that I suggested in my last text files may be experiencing some problems with low speed users (300-1200) getting dumped when large text files greater than 1.5K are being displayed, such as menus or BBS lists. Well, here's the reason.
The HST and Dual Standard modems have what is called Transmit Data Flow Control. It is controlled with the &Hx command. As I mention in the last text file, this command should be set to &H1, enabling hardware CTS (clear to send) flow control, whenever you have a fixed DTE rate . There was one problem that I forgot to mention; the CTS line on your modem is probably wired to the DSR (data set ready) line of the computer, along with the DCD (carrier detect). Since DSR is used to detect carrier, it will always be active when a caller is on and, hence, so will CTS. In other words, flow control is made useless when a caller is on. Data will just dump out to the serial port without abandon, eventually overflowing the 1.5K (or 2K with error control) buffer of the HST which is spoon-feeding the data over to the 300 or 1200 baud modem. This apparently causes the HST to drop carrier.
Solution
--------
So, what to do about this dilemma? Well, since carrier is detected using the DSR line of the serial port (assuming you chose the "DSR Cable" option from CONFIG.SYS), the actual DCD line (also called the GP line or general purpose line, pin 7) on the serial port isn't being used for anything. Well, lucky for us, the firmware has a handshaking option called "DCD Handshaking" in which the DCD or GP line of the serial port is checked before data is transmitted. This is a perfect solution to our problem: all we have to do is connect CTS (modem pin 5) to the GP line (pin 7) of the serial port, make sure DSR (serial port pin 2) and CTS are NOT connected, and enable DCD handshaking from the control panel. Flow control will now work properly!
And Now for Something Completely Different....
----------------------------------------------
While I'm at it, I'll try to solve another problem that tends to plague sysops using HST modems on their GS modem ports. Do you have the problem of your board not detecting carrier loss when your caller hangs up in the middle of something? Well, you're not alone; I had this same problem when I first got my HST (my Courier 2400 worked fine for some reason, though) and I know quite a number of sysops who also have this problem.
After hooking a tester up to the cable, I noticed that when carrier wasn't on, the DCD line from the modem was turned completely off. When carrier WAS active, the DCD line was raised. For some reason, the GS modem port takes a line that is turned completely off as being high. Thus, the DSR line was ALWAYS active.
The problem lies in the inherant design of the cable. For some reason, most Mac to Hayes cables jumper pin 4 of the serial port (Ground) to pin 8 (Rx+). Why they do this, I have no idea, because its not needed, at least on the GS All you need to do is remove this jumper and you'll be detecting carrier just fine.
New Cable Pin-out
-----------------
Now for the hard part: here are the pin-outs for a new cable that will 1) enable the modem to use CTS flow control and 2) eliminate the carrier loss detection problem with GBBS:
GS Modem Port HST/Dual Standard Modem
(Male Mini DIN-8) (Male DB-25)
1 (DTR)-------------------------20 (DTR)
2 (DSR)------------------------- 8 (DCD)
3 (Tx Data)--------------------- 2 (Tx)
4 (Ground)---------------------- 1 (Chassis Ground) and 7 (Sig Grd)
5 (Rx Data)--------------------- 3 (Rx)
7 (DCD/GP)---------------------- 5 (CTS)
You will also need to set your control panel to "DCD Handshaking: Yes" and choose the the "DSR Cable" option when asked in CONFIG.SYS. If you have to run CONFIG.SYS again (ie you had previously chosen "DCD Cable"), then make sure to put the mods to ACOS back in, as described in Part 1 of this document.
Alternate Carrier Fix
---------------------
If you don't wish to make a new cable for yourself and you're not interested in the 19200/38400 mod, you can make a mini patch box that will also fix the carrier loss detection problem. Note that this WILL NOT enable flow control, but will help those of you who just want your board to detect carrier loss for a change.
First, go to your nearest computer supply store and buy a mini patch box. This will look like a DB25 gender changer, but will have a male connector on one end and a female on the other, and of course, be functionally different. Open the patch box up and jumper pins 1-3, 5, 7, 8, and 20 straight across (ie 1 to 1, 2 to 2, 3 to 3, 5 to 5, etc). Now, put an additional jumper from pin 8 to pin 12 of the MODEM SIDE. If you jumper it on the cable side, you'll accomplish absolutely nothing.
The reason this works is rather strange. Since Mac to Hayes cables cause CD to be off when not present, there needed to be some way to put the line in a low state for the software to recognize it. Pin 12 of the modem is the speed indicator and is always in the low state (at least when there is no caller). Jumpering it to pin 8 will cause CD to be in the low state. When you receive a carrier, CD will then overide pin 12's low state with its own high state. Carrier will then be detected properly.
In Conclusion....
-----------------
That should do 'er! Again, if you have any problems, or want information on OGG-Net Networking Systems (blatant plug), then call my board Infinity's Edge, (415) 820-9401.
One more thing: there might be a copy of the first text file around that has some wrong nomenclature. In the first document, I was confusing data link rate (which is the same as connect rate) with DTE rate. This was wrong and I fixed it on a later copy of that document. Sorry for the wrong terminology.
Paul Parkhurst
"The Oggman"
4/9/90
==============================================================
How to get
S P E E D
out of your HST and HST Dual Standard Modem
using
ACOS Version 2.01d5
and an Apple IIGS
<==== PART III ====>
-------------------------------------------------------------------------------
Brought to you by The Oggman, creator of OGG-Net Networking Systems
Call Infinity's Edge (415) 820-9401 or any OGG-Net BBS
-------------------------------------------------------------------------------
Technical Notes
---------------
I've written part III of this series for those of you who might be interested in a little bit of a technical description of the 19200 and 38400 mods for the HST Modem. I'm not an expert on the new ACOS, so my explanations might be a bit off, but at least you'll see what's going on.
The code that autobauds the serial port starts at $FA7. If you disassemble the MDMRING code (which starts at $F02), you'll notice it calls this routine right near where it returns. The autobaud routine starts out something like this:
ORG $FA7
AUTOBD PHX ;SAVE THE REGISTERS
PHY
LDA #01 ;SET THE DEFAULT BAUD RATE (300)
STA SPCINIT ;SAVE IT FOR INFO(2) (SPCINIT = $E02)
CPY #00 ;Y CONTAINS BAUD 0=300 1=1200 2=2400 3=4800 4=9600
BEQ SKIP ;LEAVE IT AS 1
ASL SPCINIT ;MULTIPLY BY 4 (1200 BAUD NEXT STEP UP FROM 300)
INFO2 ASL SPCINIT
DEY ;EVENTUALLY BAUD/300 WILL BE IN SPCINIT
BNE INFO2
SKIP PLA ;GET BACK ORIGINAL
BNE NEXT ;IF ITS 0, JUST SET IT FOR 300
LDX #B300
BRA SETBAUD
NEXT CMP #01 ;IS IT 1200?
BNE NEXT1
LDX #B1200
BRA SETBAUD
NEXT1 CMP #02 ;IS IT 2400?
.
.
.
.
It continues in this fashion, up to 9600. The "B300" and "B1200" labels are my own (I don't have original source code, remember) and represent text strings stored starting at $102D. The strings stored there are used to set the baud rate by using the firmware routines. This is done by sending xxB to the serial port. xx is a number representing the baud rate and can be found in the Firmware Reference or in some other IIGS books. Some values are "6B" for 300 baud, "8B" for 1200, "10B" for 2400, and "14B" for 9600. When it has the proper address for the string in the X and A registers, it branches to the SETBAUD routine (again, my label, not Lance's). SETBAUD starts at location $FF0 and goes something like this:
ORG $FF0
SETBAUD STX BAUDVAL+1 ;STORE THE LOCATION. SELF-MODIFYING CODE
STA BAUDVAL+2 ;(MESSY, BUT IT WORKS)
LDX #$C2
LDA #$20
JSR INIT ;CALLS THE FIRMWARE INITIALIZE ROUTINE
LDX #0 ;PREPARE FOR LOOP
BAUDVAL LDA BTABLE,X ;GET THE CHARACTER TO SEND TO FIRMWARE
BEQ SETPORT ;KEEP GOING UNTIL 0 REACHED (DELIMITER)
JSR MDMOUT ;SEND TO SERIAL PORT
INX
BRA BAUDVAL ;NEXT CHARACTER
SETPORT ......
It then goes on to set other parameters of the serial port, such as no parity, 8 data bits, 1 stop bit, ignore control-A, etc. Then, it returns.
What the 19,200 Mod Does
------------------------
The 19,200 mod simply puts NOP's (hex EA) in place of the STX BAUDVAL+1 and STA BAUDVAL+2 at the SETBAUD label. BTABLE starts with the default baud rate, which was set to 19,200 in the CONFIG.SYS program. So, if you don't store anything over the original BAUDVAL+1 and BAUDVAL+2, it will remain at the 19,200 default and, thus, the port will always open at 19,200 baud.
What the 38,400 Mod Does
------------------------
The 38,400 mod is a little bit more involved, but not much. It also replaces the STX BAUDVAL+1 and STA BAUDVAL+2 with NOP's. In addition, the BAUDVAL program segment:
LDX #0
BAUDVAL LDA BTABLE,X
BEQ SETPORT
JSR MDMOUT
INX
BRA BAUDVAL
is replaced with the following:
JSR BTABLE+3
NOP
NOP
.
.
.
NOP ;10 NOPS
thus removing the entire segment of code that sets baud rate and replaces it with a new routine. The new routine is stored over the baud rate text table, since it is no longer needed. It starts at $1030 instead of $102D because the first couple of bytes of this table are modifed every time the board cycles to hold the default baud rate. The new 38,400 routine is also really easy:
BTABLE DS 3 ;YOU HAVE TO SKIP THE FIRST FEW BYTES
SEI ;DISABLE INTERRUPTS FOR NOW...
LDA #$0C
STA $C038 ;THIS IS THE SCC COMMAND REGISTER FOR PORT B
LDA #$01
STA $C038
LDA #$0D
STA $C038
LDA #$00
STA $C038
RTS
What exactly this does, I'm not sure. I only know that it sets the port to 38,400 baud. I haven't bought an SCC tech sheet yet, so I'm not up on the commands and such you send to the serial port. Like I said in the first file, I got this code after decifering Guy T. Rice's "Fastport" CDA.
What to Look For
----------------
Now that you have the mod in, how do you know its working? Well, if your board doesn't crash or hang, this is a good sign
Also, you'll be getting calls in an interesting new way....
First off, EVERY CALL YOU GET WILL LOOK LIKE A 9600 CALL. Actually, it will be either 19200 or 38400, and will be VERY fast. Even 300 baud calls will come across like this.
You will also have to get used to delays in your user's responses. Remember, you're sending this information to the modem at 19200/38400, but the other guy is only receiving it at 1200 or 2400. It will take awhile for the information you just shot over to him to be displayed on his screen. If you have a lot of 300 baud callers (ack!), then you might want to change the timeouts on your board so the board won't get impatient waiting for the other side to input something.
To make sure your CTS flow control is working, you will need to watch the next time a 300 or 1200 baud caller displays a big text file (depending on the size of the file, this may also apply to 2400 baud callers). When the modem's send buffer gets 90% filled, the CS light on the front of the modem will go out. When this happens, the board should stop sending characters. When the buffer is emptied to 50% of its size, the CS light will come back on and your board should start sending again. If this doesn't happen and, instead, your users are getting abruptly booted off your board, then 1) you made a mistake making the cable described in part II, or 2) you forgot to put "DCD Handshaking" for the modem port to "Yes" in the control panel. Check the control panel and/or use a volt meter or cable tester on your cable to find out what the culprit is.
Hope that helps. I can be reached on my board Infinity's Edge (415) 820-9401, on any OGG-Net board through netmail, or L&L Support #598. I don't get around to calling L&L that much, so the first two are the best bets.
Paul Parkhurst
"The Oggman"
4/10/90
Well, I outsmarted myself by purchasing the cheapo cables. My order arrived yesterday so I got to work.
It turns out the terminations at the mini-DIN8 are problematic. In both cables, I found shorts and "NO CONNECTS" at the mini-DIN while ringing them out. Both cables are wired differently so it is just poor workmanship. You get what you pay for. I just ordered connectors from Digi-Key. One other thing that I should point out is that the cables were built with solid wire (26AWG). Solid wire should only be used for a static application. Solid wire cables, which are subject to dynamic flexure, eventually fail due to fatigue.
It looks like I'll be building these from scratch when my hardware arrives. I'm probably going to do an autopsy (FA) on the connectors since I'll have a few days to kill. The shells are molded in place so it's time to fire up the Dremel.