C-128D on the Way

[BigDumbDinosaur]

Well, after being left powered on for several days, it appears the "new" C-128D is healthy.  It is also apparent that adding a cooling fan to it does a lot to keep the internal temperature down.  My only reservation at this point is the video monitorâ€"it's old and who knows when something will go bang in it.  Sooner or later, I'll have to figure out how to connect a standard VGA monitor to the D.  But for now, the old CBM 1084 will do.

My next project with this machine is to arrange so I can transfer files from my UNIX development system to it.  As my UNIX box has a plethora of serial ports (16, to be exact), I can rig up a serial interface between the two machines.  On the UNIX end it's easy: a shell script can cat the file to the appropriate serial port.  At the C-128D end, it's a bit more involved.  The fake RS-232 routines in the kernel are error-prone at higher speeds and the problem is exacerbated by a bug in many 6526 CIA chips that causes dropped interrupts in some cases.

Accordingly, I've concocted a dual-port serial interface card that can plug into the 128's expansion port, and can operate continuously at a maximum of 115.2 Kbps.  The core of the card is an NXP 2692A dual ACIA or "DUART," which contains two independent EIA-232 channels with FIFOs, as well as some extras, such as programmable timers.  The 2692 was originally targeted at the Motorola 68000 MPU bus, so some glue logic is needed to adapt the DUART to the 128's busâ€"several signals on the DUART have inverted meanings relative to the 8502 MPU equivalents.  As I have already worked out the details of interfacing the 2692 to a W65C816S MPU, which uses a bus structure that is almost identical to that of the 8502, the adaptation required only minor engineering to work on the 128's expansion port (see attached schematic).

Although each channel of the DUART is capable of operation at a maximum of 115.2 Kbps, 38.4 Kbps is probably the maximum practical speed with the 128 running in FAST mode.  With both ports continuously receiving and transmitting at that speed, the MPU would have to process as many as 15,360 IRQs per second.  When interrupt latency is figured into the equation (up to seven clock cycles if an indexed read-modify-write instruction is being processed) and execution time for the IRQ handler itself is added, as much as 25 percent of the 128's maximum possible throughput would be consumed in processing DUART IRQs.  So a steady data flow will definitely slow down the machine.

To make this work, a driver will have to be installed on the 128D to service the DUART, and code will have to be written to receive Motorola S-records and generate a binary image to save to disk.  I may burn the driver and processing code onto an EPROM and install it into the empty ROM socket in the 128.  That would solve two problems: 1) getting the driver itself over to the 128; and 2) not using up a lot of RAM to ensconce the driver.  The two RS-232 buffers at $0C00 and $0D00 can be usurped, along with the appropriate zero page pointers, to handle the data stream.  The rest of it is an IRQ handler and a front end in low RAM to map in the ROM as needed.  Writing this code should keep me out of mischief for a while. 

[RobertB]

Accordingly, I've concocted a dual-port serial interface card that can plug into the 128's expansion port, and can operate continuously at a maximum of 115.2 Kbps.

It sounds like you've created a modified CMD Turbo-232 interface.

          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

[airship]

Would you get more or less speed buffering to an REU?

[BigDumbDinosaur]

Accordingly, I've concocted a dual-port serial interface card that can plug into the 128's expansion port, and can operate continuously at a maximum of 115.2 Kbps.

It sounds like you've created a modified CMD Turbo-232 interface.

          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

Not exactly.  The CMD cartridge used a Motorola 6850 type UART,  which does not have a FIFO (or a second channel).  The 2692 I'm using has both input and output FIFOs for both channels to reduce the interrupt processing load, so it can generally sustain a higher transfer rate.

In this design I didn't implement carrier detect, since the logic to accept and drop calls is in all modern modems.  All the host machine has to do is provide a data stream, and assert or de-assert DTR as required to indicate when it (the host) is able to process.

Would you get more or less speed buffering to an REU?

You would get less speed.  Serial I/O is byte-at-a-time processing, which is something that is not efficiently handled with an REU.  Each access to an REU, whether for 10 bytes or 10 kilobytes,  requires a setup procedure to configure the REU's DMA controller according to what is to be done.  Also, while the transfer between host bus and REU is in process, the 6510 or 8502 microprocessor itself is halted, which means that interrupt processing is also halted.  In a case of high speed serial I/O, the required interrupt rate may be such that the time required for the REU to finish its work results in too much real time elapsing before the MPU can resume processing interrupts.  The result, in the case of serial input, will be a data overrun.

This fundamental and unavoidable problem of limited serial I/O performance is a result of the relatively low clock rate at which the MPU is run, and in the case of the C-128, the memory mapping gyrations that must occur before the interrupt handler can actually get some useful work accomplished.  While there have been reports of people achieving very high serial speeds with C-128s through the user port, it has been accomplished by optimized code that does nothing but service serial data flow interrupt, leaving no time to accomplish anything else.  The intensive nature of serializing/deserializing data is why UARTs were invented.  The work is off-loaded into another piece of hardware (the UART), which only interrupts the microprocessor when there's a complete byte to process.

UARTs like the 16550/16650 found in a lot of PCs, as well as the 2692 I like to use, also have a data FIFO, which acts like a small buffer.  The 16550 type can buffer up to 16 bytes before a data overrun occurs, which means the MPU isn't hammered as much with interrupts as it would otherwise be.  This was important in the case of PCs because much of the x86 processor family has relatively poor interrupt performance when compared to other processors.  The 65xx/85xx family actually has very good interrupt performance, and exhibits low latency (never more than seven clock cycles).  In contrast, some processors may goes 20 or more cycles before getting around to acknowledging an interrupt.

The 2692 DUART has a 3 byte FIFO, but owing to the relatively low interrupt latency of the 8502, the FIFO won't be important until the data rate gets up to 57.6 Kbps or higher.

[XmikeX]

Sadly, I have no time to read the voluminous amount of text that precedes this reply.  Please excuse any repetition of ideas. etc., that may follow ..
--

This thread, seen from a distance, reminds me of a time when I used to xfer files in the following configuration:

PC <-nullmodem-> C128 mode 2MHz @ 115.2k 6551 ACIA, as follows:
.. using ACE R16 on the c128 side (no apparent hiccups at R16 (1997 AD) for me, but results may vary)
.. and ace's FX on the PC side =)

As some of you may recall, when Craig Bruce (ACE & ZED128 author) did his "crystal magic" on the Swiftlink (6551)  ...and posted results to comp.sys.cbm,  Turbo232 from CMD mysteriously appeared shortly after (or so it would seem).

ACE R16 list  -- http://csbruce.com/~csbruce/cbm/ace/files-doc.html

XmX
--

EDIT - snippet of crystal mod below... with respect to a version of ACE prior to R16

>From: csbr...@ccnga.uwaterloo.ca (Craig Bruce)
>Subject: Even swifter
>Date: Sat, 11 Nov 1995 11:40:11 GMT

>I have just made a trivial but important hardware hack to one of my (two)
>SwiftLink cartridges to see if I could make it go faster, and IT DOES!
>As anyone who has read the SL technical documentation knows, CMD chose to
>use a double-speed clock crystal in the SL in order to allow it to work at
>speeds up to 38,400 bps, doubling the maximum baud setting for the 6551 chip
>of 19,200 bps ($0f in the control register).  For the general purposes for
>which the SL is intended, this was an excellent design decision.

>However, the 6551 also has the ability to use 1/16x the external clock rate
>in order to generate "non-standard" baud rates (well, non-standard in 1987),
>for rates up to 125,000 bps.  The speed of the double-speed clock crystal is
>3.6864 MHz, so 16x slower than this is 230,400 bps.  I tried this rate out
>and it didn't work at all.

>I replaced this crystal with a 1.8432 MHz crystal, which is the standard
>frequency for serial-chip crystals.  One 16th the rate of this crystal is
>115,200 bps, which is both below the 125,000-bps limit of the 6551 and is a
>standard serial speed for newer, high-speed modems, such as my USRobotics
>28.8 Sportster.

>I tried it out and it works; I can communicate with my modem successfully at
>115,200 bps using ACEterm on a 2-MHz C128.  Well, mostly.  The problem with
>such a high baud rate is that 11,520 interrupts per second have to be
>handled by the processor, which means that each interrupt must be handled in
>177 clock cycles (at 2 MHz).  ACE can normally handle this (much to my
>surprise), but occasionally it cannot and so it gets trampled by interrupts
>and crashes.  This apparently happens when it is about to assert hardware
>flow control.  I should be able to tune the interrupt routines to always be
>able to handle this baud rate.  This baud rate doesn't work at all with the
>processor at 1 MHz--ACEterm crashes immediately.  It is likely that this
>baud rate will work perfectly with the upcoming Super-64 accelerators from
>CMD.

[BigDumbDinosaur]

As some of you may recall, when Craig Bruce (ACE & ZED128 author) did his "crystal magic" on the Swiftlink (6551)  ...and posted results to comp.sys.cbm,  Turbo232 from CMD mysteriously appeared shortly after (or so it would seem).

ACE R16 list  -- http://csbruce.com/~csbruce/cbm/ace/files-doc.html

XmX
--
>From: csbr...@ccnga.uwaterloo.ca (Craig Bruce)
>Subject: Even swifter
>Date: Sat, 11 Nov 1995 11:40:11 GMT

>However, the 6551 also has the ability to use 1/16x the external clock rate
>in order to generate "non-standard" baud rates (well, non-standard in 1987),
>for rates up to 125,000 bps.  The speed of the double-speed clock crystal is
>3.6864 MHz, so 16x slower than this is 230,400 bps.  I tried this rate out
>and it didn't work at all.

No knocks on Craig (he's a very smart fellow) but why would he expect the 6551 to operate on a 3.6864 MHz clock crystal?  The NMOS silicon in the 6551 can't switch that fast.

>I replaced this crystal with a 1.8432 MHz crystal, which is the standard
>frequency for serial-chip crystals.  One 16th the rate of this crystal is
>115,200 bps, which is both below the 125,000-bps limit of the 6551 and is a
>standard serial speed for newer, high-speed modems, such as my USRobotics
>28.8 Sportster.

Actually, this feature of the 6551 (it's not a "trick") was noted in the late 1970s by someone (Lance Leventhal?) whose name escapes me now.  I recall reading about it back when I was trying to hack a real 6551 onto a C-64 (I ended up with a 6850 design instead).

>I tried it out and it works; I can communicate with my modem successfully at
>115,200 bps using ACEterm on a 2-MHz C128.  Well, mostly.  The problem with
>such a high baud rate is that 11,520 interrupts per second have to be
>handled by the processor, which means that each interrupt must be handled in
>177 clock cycles (at 2 MHz).

I alluded to that earlier, which is why I decided to use the 2692A dual ACIA.  While the absolute interrupt rate with high speed communication can't be avoided, the FIFOs in the 2692 tend to reduce burst activity, making the workload more manageable.  Very tight coding is required, however, to maintain good throughput at anything above 38.4 Kbps.  Compounding the difficulty is the fact that any I/O access on the C-128 is at 1 MHz, regardless of MPU clock rate, which applies when reading or writing to any UART register.  The effect is almost like wait-stating the MPU for one Ø2 cycle.

Craig's interrupt rate is based on single-directional communication, not CBAT, which is far more demanding.  CBAT at 115.2 Kbps would result in over 23K interrupts per second, which would virtually saturate the 128 running in FAST modeâ€"at best, only 88 clocks would separate consecutive interrupts.  After factoring in minimal overhead in the interrupt handler's front and back ends, about 65 cycles would be left to actually process dataâ€"and that would not include the code required to determine if the UART was actually the interrupt source.

Point to note: if the UART is attached to IRQ instead of NMI, as is often done, no interrupts will be dropped if they overlap, as IRQ is a level-sensitive input and will re-interrupt the MPU if an unserviced IRQ is pending.  However, such a condition would soon lead to a data overrun.

All that aside, the 6551 is a pretty lame design with quirky behavior.  The CMOS version isn't much better.  Although the Motorola 6850 UART is as old a design as the 6551, it is a better performer in almost all respects, and was not at all difficult to interface to a 65xx bus (except for reset).  However, more modern ACIAs (e.g., the 16550 and 2692) are even better due to on-chip FIFOs and more sophisticated control functions.  In particular, the 2692 is natively clocked at 3.6864 MHz and runs asynchronously to the MPU bus, so high BPS rates are no big deal.  I wouldn't even consider a 6551 at this point in time.  Better alternatives exist.

[XmikeX]

No knocks on Craig (he's a very smart fellow) but why would he expect the 6551 to operate on a 3.6864 MHz clock crystal?  The NMOS silicon in the 6551 can't switch that fast.

Curiousity, I suppose?  ..at least the 6551 in my SL seems to handle ~2 MHz.... whew.

All that aside, the 6551 is a pretty lame design with quirky behavior.  The CMOS version isn't much better.  Although the Motorola 6850 UART is as old a design as the 6551, it is a better performer in almost all respects, and was not at all difficult to interface to a 65xx bus (except for reset).  However, more modern ACIAs (e.g., the 16550 and 2692) are even better due to on-chip FIFOs and more sophisticated control functions.  In particular, the 2692 is natively clocked at 3.6864 MHz and runs asynchronously to the MPU bus, so high BPS rates are no big deal.  I wouldn't even consider a 6551 at this point in time.  Better alternatives exist.

....and then there's something like this : http://www.westerndesigncenter.com/wdc/w65c51s-chip.cfm .. keeping the tradition, and software-lock-in, alive.....maybe.

XmX

[RobertB]

....and then there's something like this : http://www.westerndesigncenter.com/wdc/w65c51s-chip.cfm ..

Hmm, very interesting!

          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]

....and then there's something like this : http://www.westerndesigncenter.com/wdc/w65c51s-chip.cfm .. keeping the tradition, and software-lock-in, alive.....maybe.

The W65C51S' only real advantage over the NMOS part is its ability to operate at much higher bus speeds.  Otherwise, it's the same old, same old...

As I said before, much better UARTs are available.  Why bother?