DUAL PORT SERIAL INTERFACE ADAPTER

[BigDumbDinosaur]

I have a C-128D and Lt. Kernal/Rear Admiral setup, for which I am going to develop some database code.  I do all my 6502 development on my trusty UNIX server, since it is able to assemble about 10,000 lines of code per second (just a tiny bit faster than DevPak running on a C-128).  The problem comes in getting working code onto the C-128D.  The method I have chosen is to use an EIA-232 data link between the UNIX box (which has a bunch of serial ports) and the C-128.  This method would ultimately be less involved than the hassle of having to run a program on a PC to get the code onto a floppy disk that the 128 can read.

Usually, serial interfacing to the C-128 is through the user port.  However, that means using the error-prone fake RS-232 routines in the kernel.  Also, those routines are terribly inefficient and needlessly limit the speed at which the link can be run.  So I decided to take a different tack.

Below are some pictures of the dual port serial interface adapter I made for the C-128.  This one uses an NXP SCC2692A dual ACIA, along with glue logic in a GAL and a ROM in the internal ROM socket to provide the driver code.  Also in the ROM will be conversion code that will accept Motorola S-records from the UNIX box and load the relevant areas of RAM with machine code that can be saved to disk.

The 2692 can run at up to 115.2 Kbps on each channel, a speed that is well beyond the capabilities of the C-128 (it would amount to some 23,000 IRQs per second, virtually saturating the 8502 with interrupts).  For my application, I'm going to limit the speed to 38,400 Kbps, which the C-128 can manage without too much difficulty.  Although the adapter has two serial ports, initially I'm only going to use one.  Eventually the driver code will take care of both ports, allowing, for example, two modems to be in simultaneous use on a single 128.

I've got the hardware completed and am banging away at the driver.  As I said above, it runs in a 32K x 8 ROM plugged into the internal socket.  To avoid a conflict with the boot ROM in the Lt. Kernal/Rear Admiral host adapter, I'm running my code in high ROM ($C000).  Doing so complicates things a bit, as I have to mirror some of the CBM kernel code to deal with interrupts when my ROM is in context.

I'll periodically add commentary as I work through this thing.  Due to the one megabyte file size limit per post several posts will follow with additional pictures.

[BigDumbDinosaur]

Second picture.

[BigDumbDinosaur]

Third picture.

[BigDumbDinosaur]

Fourth picture, showing the two serial ports, which are 8C8P (aka RJ-45), wired according to the Equinox SuperSerial standard.

[BigDumbDinosaur]

This picture shows the adapter plugged into the C-128D cartridge port.  The port pass-through connector is to the right to avoid having the Lt. Kernal host adapter stick out real far in the back.

[BigDumbDinosaur]

Here you can see the adapter's BIOS ROM in a ZIF socket plugged into the internal option ROM socket.  The ZIF socket makes it easy to swap out ROMs as I write and debug code.

[BigDumbDinosaur]

BIOS ROM power-up banner.  The ROM initialization occurs when the BASIC cold start code at $4000 calls the kernel PHOENIX routine.  At that time, part of the kernel is revectored so the ROM intercepts IRQs, as well as the tail end of RUN-STOP/RESTORE.  The latter restores the vectoring so the ROM continues to function.

The finished version of the ROM will also intercept the OPEN, CLOSE. CKIN, CKOUT, CLRCH, BASIN, GETIN and BSOUT kernel functions so opening device 2 will communicate with the adapter.  The result is that the BIOS will be transparent to BASIC and any M/L program that utilizes the kernel jump table for I/O.

[airship]

Very sweet, BDD! I love to see serious development projects come together for our marvelous machine.

[BigDumbDinosaur]

No project ever goes 100 percent smoothly and this one is no exception.  I have some problems "talking" to the ACIA, which turned out to be caused by the GAL not performing the required logic translations.  The interesting thing is that the GAL code simulates correctly, yet the GAL itself has a couple of outputs that aren't doing what they are supposed to do.  The problem is the same with another GAL, leading me to suspect my el cheapo Chinese burner is at fault.

This unit, a TOP853 that runs off a PC's USB port,  supposedly will correctly burn 16V8B GALs, which is what I am using.  The GAL appears to burn okay and the burner's software says it verifies okay.  However the GAL doesn't work right.  As a temporary measure, I'm going to duplicate the GAL's functions in discrete logic (a NAND and an inverterâ€"definitely nothing complicated) so I can continue with the driver development.

Looks as though a new burner is in order.  I never liked the software with this one anyway (typical low-grade Chinese crap), but didn't expect much with the low price.  The next burner will be about 10 times as expensive, but will also be able to burn CPLDs, which I will be using in an unrelated project.

Code Select Expand

Name      cbm_serial;
PartNo    B0111301;
Date      11/13/2010;
Revision  01;
Designer  BigDumbDinosaur;
Company   BCS Technology Limited;
Assembly  None;
Location  Ux;
Device    g16v8;


/*
* * * * * * * * * * *
* INPUT ASSIGNMENTS *
* * * * * * * * * * *
*/

pin 1     = PHI2;                       /* MPU clock */
pin 2     = RWB;                        /* MPU read/write signal */
pin 3     = RST;                        /* system reset */
pin 4     = CS;                         /* 0 = chip select */


/*
* * * * * * * * * * * *
* OUTPUT  ASSIGNMENTS *
* * * * * * * * * * * *
*/

pin 12     = _RST;                      /* ACIA reset */
pin 13     = !RD;                       /* ACIA read data */
pin 14     = !WD;                       /* ACIA write data */


/*
* * * * *
* LOGIC *
* * * * *
*/

_RST.oe    = 'b'1;
RD.oe      = 'b'1;
WD.oe      = 'b'1;

_RST       = !RST;                      /* invert reset */
RD         = !CS & RWB & RST;           /* read data */
WD         = !CS & !RWB & PHI2 & RST;   /* write data */

[BigDumbDinosaur]

Very sweet, BDD! I love to see serious development projects come together for our marvelous machine.

The irony is this serial adapter is a means to an end.  The real project is a database engine for the Lt. Kernal, aka Rear Admiral.

BTW, this adapter can be used with a C-64 or a 128 running in 64 mode.  Of course, a different device driver would be required.

[Hydrophilic]

Hang in there!  There is something seriously wrong if the GAL won't do a simple NAND / NOT combo.  I know what a FPGA is, but what is a CPLD?  Sounds similar...

[BigDumbDinosaur]

Hang in there!  There is something seriously wrong if the GAL won't do a simple NAND / NOT combo.  I know what a FPGA is, but what is a CPLD?  Sounds similar...

A CPLD (complex programmable logic device) is like a GAL on steroids, and an FPGA (field programmable gate array) is a CPLD on steroids.

GALs are a class of device called SPLDs (simple programmable logic device) and are descendents of the older PALs and PLAs (PALs and PLAs are essentially the same thing).  The PLA family could only do combinatorial logic (ANDs, ORs, etc.), whereas GALs are able to do registered logic, making it possible to synthesize flip-flops and state machines, as well as the usual logic gates.

The logic for the serial adapter is very simple and I did it in a GAL only to reduce the chip count.  Otherwise, there was no special advantage to using a GAL.

[scooter]

Simply an idea:
Why not the rom in the cartidge to make it plug and play?

[BigDumbDinosaur]

Simply an idea:
Why not the rom in the cartidge to make it plug and play?

I may eventually do that.  I didn't on this version because I wanted to keep the PCB real estate within a certain range, which would not have been possible if the ROM was on the board.

As I stated above, this adapter is a means to an end, which is to be able to do Lt. Kernal/Rear Admiral development on my UNIX box and send the binary code over to the C-128 for testing.  I ROMified the BIOS only as a matter of convenience to avoid having to load it from disk at each each reset.

Now, if I were going to produce this adapter for sale I'd embed the BIOS on the adapter and make it "plug and pray."    But, as we all know, there's no real market nowadays for something like this.

[BigDumbDinosaur]

Just thought I'd bump this topic by saying this project ended up unfinished because of the death of my C-128D's video monitor.  Being unable to run the computer, everything came to a halt and got packed away.