Any advice for running swiftlink + USR 28.8k modem?

[dr.v]

Hi guys.  I have a swiftlink and a USR 28.8 sportster (as the post title suggests).  Unfortunately I don't have the documentation for this USR modem.  I found dox on the USR website for the 33.6k sportster which I figure can't be too different.  The really important thing is the list of AT commands - and I figure those will pretty much be the same for the 28.8 and 33.6 sportster.

I would like to get it working.  I tried to configure it for my Cnet 128 system - but no luck so far.  I tried to get it working on Novaterm 10 and Desterm 2.0 as well.  Not happening.  The modem goes TR (terminal ready) and the lights for send/recieve data do flash during initialization through Cnet, Novaterm, etc.  But when I try to dial out the modem just makes a "CLICK" noise and that's about it.

I'm sure I have some guys defaults set in my NVRAM (I bought this modem used a few weeks ago).  I would like to set up NVRAM as per my C128D - but it seems a bit tricky.

I found an article in CW#14 by Max Cottrell (in the "SysOp's Corner") in which the author touts the use of USR modems with swiftlink for a BBS.  He gives his settings, and I have tried those.  But I think he is using a 14.4k (though this is not explicitly stated in the article).  I know that Eric Pearson mentioned in the Cnet 7.0 documentation that he was able to run Cnet128 stable at 28.8k with a swiftlink + ?? modem (I forget what he used).

Any advice is appreciated.

Tom

[RobertB]

I have a swiftlink and a USR 28.8 sportster...

Have you given it the AT command to reset the modem to a clean state?  (Now what was that command...)

     FWIW, I've never had any success with a US Robotics 28.8k modem. 

          I use a Zoom external modem on my C128DCR,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug
          The Other Group of Amigoids
          http://www.calweb.com/~rabel1/
          Southern California Commodore & Amiga Network
          http://www.sccaners.org

[Blacklord]

at&f

[dr.v]

Yeah I spent a couple hours playing with it again today.  Still not working.  I'm pretty certain the Swiftlink cartridge is working fine (anyone know of diagnostic software for the swiftlink?).  I can use the ATIn commands to see the stored template configurations, I can get lists of commands from the modem printed to the terminal, I can get the  modem to print all the S-registers, etc.  So the modem seems to be communicating with the Swiftlink appropriately.

FWIW, I've never had any success with a US Robotics 28.8k modem. 

          I use a Zoom external modem on my C128DCR

Robert - So can I use a 33.6k Zoom?  I know the Swiftlink can handle communication speeds upto 38.4k (at least, the Swiftlink documentation says so).  I have been under the impression that for speeds higher than 28.8k the turbo232 is the preferred high speed ACIA device.

Looks like I can get an external 33.6 Zoom new and sealed with documentation at a cheap price.  Think it will work with my Swiftlink?

Thanks,

Tom

[BigDumbDinosaur]

Hi guys.  I have a swiftlink and a USR 28.8 sportster (as the post title suggests).  Unfortunately I don't have the documentation for this USR modem.

First off, the Sportster you have has the same AT command set as the faster unit.  So anything you read on the US Robotics site is applicable.

Back in the days when we used to provide a diagnostic modem (a USR Courier) with each of our UNIX servers, we used the following configuration:

Switch   Setting   Function
---------------------------------------------------------------
   1       Off     Respond to data terminal ready (DTR) signal.
   2       Off     Send verbal responses
   3       On      Display results.
   4       Off     Echo off-line commands.
   5       Off     Automatically answer call.
   6       Off     Normal carrier detect (CD) operation.
   7       On      Display responses only in originate mode.
   8       On      Enable AT command set.
   9       On      Do not disconnect on +++ sequence.
  10       Off     Load defaults from NVRAM at reset.
---------------------------------------------------------------


Command   Effect
-----------------------------------------------------------------------------
   B0     ITU handshake required to connect.
   C1     Transmitter on.
   E1     Command echo on.
   F1     On-line echo off (full duplex).
   M1     Speaker on until call has been negotiated.
   Q2     Suppress responses when answering call (switch 7).
   V1     Display verbal responses (switch 2).
   X6     Display verbose verbal responses.
   &A3    Display all result code subsets (e.g., ARQ, etc.).
   &B1    Fixed serial interface rate.
   &C1    Normal carrier detect (CD) operation (defaulted by switch 6).
   &D2    Respond to data terminal ready (DTR) signal (switch 1).
   &G0    No guard tone.
   &H1    Hardware (CTS/RTS) flow control enabled.
   &I0    Software (XOFF/XON) flow control disabled.
   &K1    Automatic data compression enabled.
   &L0    Normal dialup phone line.
   &M4    Normal/ARQ mode error control.
   &N0    Variable rate connection enabled.
   &P0    North American pulse dial rate.
   &R2    Send data to computer upon receipt of request to send (RTS) signal.
   &S0    Data set ready (DSR) signal always true.
   &T5    Block remote attempts to run loop-back test.
   &Y1    Expedited, destructive backspace.
-----------------------------------------------------------------------------


Register   Setting   Function
-------------------------------------------------------------------------------------
    0          2     Number of rings before automatic answer.
    7         30     Number of seconds to wait for carrier.
   10         10     Delay in 10ths of a second to disconnect following carrier loss.
   13          1     Modem resets when DTR is deasserted.
   14          2     Defaulted by switch 7.
   15         32     Enable destructive backspace.
   32          6     Voice/data push button acts as hardware reset.
-------------------------------------------------------------------------------------

Not all of the above are applicable to the Sportster (it was a dumbed-down version of the Courier in a cheap plastic case), so some experimentation may be required.

Some things to note:

   
• The behavior of the DTR signal being emitted by the SwiftLink is a matter of some concern.  USR generally set up their modems so that DTR had to be asserted before the modem would accept commands or seize the phone line.  Depending on how the modem was set up before you got hold of it, it may be that S-register 13 is loaded wth the value 1, which will cause the modem to go through a hardware reset each time DTR is de-asserted (see above).  Also, verify the setting of the relevant switch (it's 1 on a Courierâ€"I don't have any familiarity with the Sportser's switches)

   
• CTS/RTS handshaking must be enabled in order to operate the host side of the modem at anything faster than 9600 bps, as well as to take advantage of line-side error correction.  This means the cable you are using to connect the modem to the SwiftLink must pass through all relevant lines.  XON/XOFF handshaking is generally unreliable with these modems and should be avoided.

   
• Modems of this type are normally configured to operate the host side at a fixed speed, hence the use of AT&B1 to lock the host side rate.  If your software issues AT&B0, the host side speed will change to match the speed detected on an incoming call negotiation, mimicking the old Bell 103/212A behavior  You really don't want this to happen.

   
• As the C-128's ability to process interrupts is limited, I recommend operating the host side no faster than 38.4 Kbps.  Anything faster will simply flood the 128 with interrupts that it won't be able to service in a timely manner.  The reality is the 128 can't support CBAT at that speed, so why push it?

   
• The host side speed itself has no bearing on the line side speed.  All modems built to ITU standards (which includes yours) automatically negotiate the line-side speed during connection.  As I said, you don't want thisâ€"you'll just drive yourself nuts trying to fix "no connect" problems.

[dr.v]

Once again, thank you for your insightful posts BDD.  I fully suspect that I will find the solution to my problem in your post.  What you said about the modem going into a hardware reset each time DTR is de-asserted feels very much like the problem I'm dealing with.  After spending some hours playing with the modem (and relearning all the AT commands I once knew) I have a much better understanding of what is going on. 

I am not near my 128D right now - but I will spend some time on this tomorrow.

Thanks again,

Tom

[RobertB]

So can I use a 33.6k Zoom?  I know the Swiftlink can handle communication speeds upto 38.4k (at least, the Swiftlink documentation says so).  I have been under the impression that for speeds higher than 28.8k the turbo232 is the preferred high speed ACIA device.

Looks like I can get an external 33.6 Zoom new and sealed with documentation at a cheap price.  Think it will work with my Swiftlink?

Probably.  I've used my 56K Zoom external modem with both a Turbo-232 and a Swiftlink without any problems.  I can only get up to 28.8K with the 56K Zoom and the Turbo-232 here in my town, due to slow phone lines.  However, in the San Francisco area, that same combination gives me up to 40K, due to better lines there.

          Truly,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug
          The Other Group of Amigoids
          http://www.calweb.com/~rabel1/
          Southern California Commodore & Amiga Network
          http://www.sccaners.org

[BigDumbDinosaur]

The host side speed itself has no bearing on the line side speed.  All modems built to ITU standards (which includes yours) automatically negotiate the line-side speed during connection.  As I said, you don't want thisâ€"you'll just drive yourself nuts trying to fix "no connect" problems.

The wording of the above is ambiguous.  The auto-negotiation is fine.  It's the changing of the host side speed that is undesirable.  An AT&B1 command during modem initialization will take care of that.

[BigDumbDinosaur]

Speaking of the SwiftLink, I've developed a new serial interface that plugs into the C-64/128 expansion socket and has two EIA-232 ports.  This project is meant to facilitate software development for the Lt. Kernal (aka Rear Admiral), and had its genesis in yet another project from last year.

In 2009, I designed and built a single-board computer powered by a W65C816S MPU (16 bit big brother of the 65C02), and used an NXP2692A DUART to drive the console, a WYSE GPT terminal I had laying around.  The GPT's serial interface can be driven at speeds up 115.2 Kbps, and I was determined to take advantage of that fact.  Now, in interrupt-driven I/O, 115.2 Kbps can theoretically produce some 23,000 IRQs per second if doing character-at-a-time I/O.  However, the 2692 has a three-deep FIFO on each channel and can be programmed to either generate an interrupt for each character received or transmitted, or only when the FIFO is full (receive) or empty (transmit side).  So it seemed likely I could meet my goal without having to clock the MPU real high.

The significant work with adapting this DUART to the SBC was in interfacing it to the '816 bus.  The 2692 has separate read and write control inputs, and an active high reset input.  The '816, on the other hand, is essentially a souped up 65C02 with 16 bit registers, so it has the single R/

• W[/o] output and only an active low reset.  However, with careful timing analysis and judicious use of glue logic (74ABT parts to minimize prop delays), I got it working, and during testing, was able to achieve sustained 115.2 Kbps CBAT on both ports with the MPU clocked at a modest 8 MHz (FMAX for the '816 is 20 MHz when VCC = five volts).
  
  Connecting the DUART to the C-64/C-128 bus required some minor alterations to account for the lack of the VDA and VPA bus arbitration signals present with the '816, as well as to deal with the genrally noisy nature of these machines.  I ended up replacing the 74ABT logic with a 16V8C GAL, which simplified the circuit and reduced the required PCB space.  I've completed all the logic simulations, so the only thing left is to build it and see if it goes or blows.  For now, I'm going to run the driver in an EPROM plugged into the internal ROM socket.
  
  Back to why I'm doing this.  I'm gearing up to do some fairly complicated software development for the Lt. Kernal/Rear Admiral.  Given the ultimate size of the code that will be involved, editing and assembly on the 128 isn't really practicalâ€"assembly, in particular, will be a slow process.  Therefore, coding will be done on my UNIX box and the assembled binary will be sent over to the 128 via a serial link.  Having the DUART driver in ROM means I can immediately restart it if the 128 crashes during testing, as I can arrange for the ROM to wedge itself into the interrupt system at boot time.
  
  BTW, there is a bit of hinkiness involved in getting interrupt-driven code to run in a function ROM.  The C-128's interrupt handler writes %00000000 into the MMU configuration register, which immediately maps in all system ROMsâ€"function ROMs get mapped out.  Therefore, a small piece of anchor code has to be present in low RAM to intercept the interrupt handler and remap the system to expose the function ROM.  Fortunately, there are several places where this code can be stashed without getting in the way of anything.
  
  As soon as this thing sees the light of day, I'll post some info and pictures.

[Hydrophilic]

I'm going off topic here, but BDD brought a few interesting ideas.  First it's good to see you putting the single-board-PC to use.

Second, HOW did you get the overline in R/W in your post.  Oh wait, now I see it next to underline and strike-through... has that always been there?

Third, for logic simulations, which software do use or recommend?  Could come in handy for Z80 4MHz mod.

Fourth, you're going through a lot of trouble just to program a C128... but as long as you're having fun...

Fifth, I agree, CBM made it difficult to integrate software with system ROMs.  Like BASIC has some nice vectors to add your own tokens (or mod existing ones), but it invokes BANK14 (with RAM 0 or RAM 1 randomly underneath) before it uses them, requiring a similar clumsy low-RAM redirect.

[BigDumbDinosaur]

I'm going off topic here, but BDD brought a few interesting ideas.  First it's good to see you putting the single-board-PC to use.

I'm already working on the second generation design, which uses 512 KB of SRAM, has SCSI-SE, and should be able to run at 20 MHz.  A CPLD will handle all of the glue logic, except Ø2 clock generation.  That will come from a can oscillator fed through a 74ABT74 flip-flop.

Second, HOW did you get the overline in R/W in your post.  Oh wait, now I see it next to underline and strike-through... has that always been there?

First time I recall seeing it was when Lance upgraded the forum software a while back.

Third, for logic simulations, which software do use or recommend?  Could come in handy for Z80 4MHz mod.

I use Atmel's WinCUPL package, which incorporates an editor, compiler and simulator.  It works with most industry-standard SPLDs, such as the 16V8, 22V10, etc., as well as Atmel's CPLDs.  The compiler generates standard JEDEC files that many device burners can use.  My el cheapo TOP853 EPROM burner can work with these files.

Fourth, you're going through a lot of trouble just to program a C128... but as long as you're having fun...

No trouble at all.  The assembler on my UNIX box can run through 10,000 lines of code in about a secondâ€"that's for both passes.  10,000 lines of code on the 128 would take hours to assemble.  So being able to develop on the UNIX side and quickly sent the code over to the 128 at high speed will greatly speed up the development cycle.

BTW, if there's enough interest, I may consider making the dual port serial adapter available for purchase.  In theory, a dual line BBS could be run on a single 128 with it (although coding something like that would definitely not be a simple undertaking).

Fifth, I agree, CBM made it difficult to integrate software with system ROMs.  Like BASIC has some nice vectors to add your own tokens (or mod existing ones), but it invokes BANK14 (with RAM 0 or RAM 1 randomly underneath) before it uses them, requiring a similar clumsy low-RAM redirect.

The entire architecture is geared toward supporting BASIC programs, not M/L programs tapping into BASIC ROM subs.  In that respect, the C-64 is less a pain.  That said, the only time I tap into the BASIC ROMs is when I'm writing something in M/L into which variables are to be passed.  I don't even look at the math routinesâ€"they're not at all accurate.