The project is peripheral (!) to 65xx hardware, so I though I'd post it.

It's a dual channel serial adapter that works in the cartridge port of a Commodore 64 or 128. It's actually a means to an end, as it's purpose is to link my UNIX software development box to a C-128D for some database code testing. Rather than fooling around with copying an executable program to a CBM compatible floppy disk and then loading from that disk in the C-128D, I'll just send the file over through a serial interface in S-record format and decode it on the fly. Once the binary has been loaded into RAM on the 128 I can save it to disk inside the built-in M/L monitor.

This adapter borrows some of its circuitry from my POC computer, with a 16V8 GAL being used to provide the required glue logic. The cartridge port is passed through so another device can coexist with the serial adapter.

Schematic

PCB Layout

PCB Component Side

PCB Solder Side

Assembled Adapter

Adapter Plugged into C-128D #1

Adapter Plugged into C-128D #2

Looks good, no? Too bad it doesn't work.

As I said, the glue logic is in a 16V8B GAL and therein lies the trouble. Although the GAL code compiles and simulates fine, the GAL itself (an Atmel part) doesn't produce the expected outputs. Fortunately, someone is going to help me out with this. He noted that he's had trouble with Atmel parts, which may explain why they're cheap. We'll see...

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Did only a quick look. Where is your /CS coming from? From the GAL? You'd need at least the I/O1 or I/O2 signals to map the adapter into the C128 I/O space and I don't see them at the GAL

André

Sorry, overlooked the jumper to set /CS to either I/O1 or I/O2 :-)

Other point:

The c64 (and I assume the C128 as well) only have Phi2 for the CPU access on the bus - phi1 is reserved for video chip memory access. This means that the address lines only become valid at the beginning and some time into phi2. This posed a problem with the VIA 6522 that requires the address lines to be fixed during phi2 - so with the VIA the rising edge (only - not the falling edge) of phi2 is normally delayed before the clock is given to the VIA. Can this be a problem of your schematics as well?

André

Yes, the 6522 needs the RS and R/W lines to be valid and stable quite awhile before phase 2 rises; so I remedied the problem as shown here

Hi BDD, I had a similar problem with Atmel 22V10Cs... Daryl apparently was having similar problems with the Atmel parts and suggested using Lattice parts. I do believe he was using a similar programmer? (Genius G540/840) though...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Correct on that.


You've just highlighted one of several reasons why I have never liked the 65C22 and have found no use for it (its totem pole IRQ output is another).


The NXP2692A doesn't have the timing constraints of the 6522 (other than the caveat about allowing three X1 clocks between setup register accesses—X1 being the 3.6864 MHz baud rate generator clock). Therefore, the relationship between Ø2 and the address lines is of no particular importance, especially with a machine as slow as a C-64 or C-128.

The only thing that needs to be qualified with Ø2 is /WD (/WEN on the 2692), and that is to avoid spurious writes. As the C-128 expansion port is clocked at an effective 1 MHz, even in FAST mode, I'm not anywhere near the timing limits of the 2692 (A0-A3 setup time to RDN or WRN low is only 10 ns). BTW, I currently have POC V1 running with a 12.5 MHz Ø2 clock, and the 2692 is able to easily stay with it.

It appears at this time that the Atmel 16V8 GAL is the culprit. Although my programmer said it correctly programmed it, the GAL's outputs are completely wrong. For test purposes, I'm going to dig some discrete gates out of the "used parts" bin and jury-rig them into the GAL's socket to see how (if) the adapter works with regular 74AC logic.

I should have some programmed Lattice GALs here soon, which should put this issue to bed.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I contacted Daryl about it, and it was he who pointed the finger at Atmel. Daryl's burned a couple of Lattice GALs from my CUPL and is sending them to me. If they work then I'm going to return the four Atmel parts I have and demand my money back. It's not a lot of money but it's the principle of the matter.

What puzzles me is how can a semi manufacturer ship stuff that doesn't work and manage to stay in business. If we shipped servers that didn't work, we wouldn't last a week.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I suspect a large part of it might be that their business in PALs is insignificant compared to their business in microcontrollers, which DO work as advertised, and quite well too.

Until I read this thread, for example, I simply never knew Atmel made PALs.

It seems that with Xilinx and Lattice having exited the low-end PLD business, only Atmel is left. They'll probably keep shipping them for some time to come because not every project needs the capabilities of an FPGA or high end CPLD. It's the same reason that total discontinuance of discrete logic hasn't entirely happened.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Why a GAL? A 74LS139 will do as well and no programming needed :)

You feed input A1 with RWB, B1 with PHI2 and G1 with /CS. Y12 becomes /WD and Y13 becomes /RD.
You feed A2 with /RST and both B2 and G2 with GND. Y21 becomes RST.

I used the above already in 1988 to use 8250's (UART) with my C64/128's.

_________________

'Cuz I had the GALs, so I figured why not use one? Also, I don't have any 74LS logic here anymore. I haven't used that series in some 15 years. I do have some NANDs and inverters in 74ABT and 74AC logic, so I might just monkey-rig them into the board in the interim.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

My guess is that the programming algorithm needed to program their GAL's is different than the one used for Lattice and that our low-end, Chinese-based programmers just assumed the Lattice one would work for all.

In reading the Atmel datasheets and application notes, I found a list of programmers that are supposed to work. These are the higher end units make by Needham and the likes.

I'm sure Atmel's parts work when used with approved programming tools. However, it's a shame they don't make the algorithms needed available to all who want it.

Daryl

Figuring out and publishing those algorithms sounds like a good reverse-engineering project.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!