I used a Minipro TL866A. I was aware that there were some issues surrounding their programming, but I did not know what they were. Their page does say that it supports that specific Atmel part, but when I contacted them over a wierd transient problem(I hope it was transient), they said they hadn't actually tested it.

Hmph. If it doesn't use the standard programming algorithm, they shouldn't be allowed to market the thing as a standard part. And they shouldn't be allowed to advertise that a programmer can blast this thing if they haven't actually tested it. I suppose it makes business sense to someone who's only really in it for the money, and not too honest...

But if the VIA test program works, does that not point to the GAL working? I'll pull it out and test it, see if I've wasted my money on a falsely advertised part...

If you unplug EEPROM, RAM, DUART and VIA and then wire (use 3K3 resistors) the databus with the pattern $EA = 11101010 binary, you present your CPU a NOP instruction all the time. So it cycles (beginning at $FFFC,$FFFD then hopping to $EAEA through all addresses, endlessly. If you then additionally connect one of the various /CS you have to the RUN pin at your CPU the test will stop at the first address the GAL considered to be part of the address range related to that /CS.
Once halted check the addresslines.


edit(1): added "use 3K3 resistors"

I managed to pull the equation files for the PLD. They were in a virtual machine disk on an ext4 partition of my portable hard disk. I need them if I want to tweak the equations later, so I probably should have kept them closer to hand...
Anyroad, I have attached the CUPL equation file.

I also tested the chip select with the X-spitter rom(by tying to RDY), and it suspended with the DUART address on the upper four pins.

The logic mostly looks fine. However, as written, the following statements will not work as expected:

Code:

PIN 16   = RD                      ; /*                                 */
PIN 17   = WR                      ; /*                                 */
   ...

RD   = PHASE_2 & RW;
WR   = PHASE_2 & !RW;

In the above, you have declared the RD and WR pins as active high outputs, which is incorrect. RD = PHASE_2 & RW will cause RD to go high when Ø2 and RW (the 65C02's RWB output) are high. Similarly, the expression WR = PHASE_2 & !RW will cause WR to go high when Ø2 is high and RW is low.

The correct code would be:

Code:

PIN 16 = !RD;        /* declare as active low output */
PIN 17 = !WR;        /* declare as active low output */
   ...

RD = PHASE_2 & RW;   /* RD will go low when Ø2 & RWB are high       */
WR = PHASE_2 & !RW;  /* WR will go low when Ø2 is high & RWB is low */

The declaration of the pin name with the negation symbol (!) tells WINCUPL this is an active low output.

Some of your other logic can be rewritten as well, viz.:

Code:

PIN 13   = !UART;               /* declare UART chip select as low true     */
     ...
UART = !A15 & A14 & !A13 & A12; /* select UART if A15-A12 = %0101, or $5xxx */

Depending on the device being used, the above may use fewer product terms than the same statement as you wrote it.

Give it a try and see if it will work.

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

I am really amazed that some of your small test programs did work anyway

Thx to BDD it is clear that /RD and /WR didn't work correctly. During accessing the DUART this is evident while accessing the VIA RWB is used and /RD or /WR doesn't matter.

What puzzles me is how any program could run. Accessing the ROM uses /RD but /RD becomes 1 during phase_2. So only during the narrow spot where PHI2=0, A15..0 and RWB finally becomes valid the ROM was adressed and selected. All along PHI2=1 nothing drives the databus and only stray capacitances could preserve the information. Looks like the VIAs "bus holding devices" perform this "magic".

But perhaps once you have reprogrammed your GAL and get your DUART running we know that using the Minipro TL866A for ATMEL GALs is possible (at least for basic logic).

Yes, good point.

Hmm, the spot isn't as narrow as you might think. It would be narrow if the CPU were running at or close to its 14 MHz limit. But it rapidly becomes wider as clock frequency is reduced. That's because the delay from the start of a cycle until A15..0 and RWB are valid is rated as 10 ns max. The 10 ns figure remains in effect even at lower clock frequencies.

Good point about capacitance. That would preserve the information.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

you are right, I have to get rid of the NMOS figures (tADS = 300ns, tACC = 575ns) in my mind.

Absolutely correct. My focus was on why the DUART was not responding.

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

I was shure /RD (at least) was working correct, due to the other running test programs. That side effect the bus holding devices of the VIA implements wasn't obvious to me.

I thought if anything the bus hold devices would be on the VIA's peripheral ports (ie, not on the data bus). Am I mistaken? To me, bus capacitance is an adequate explanation for why the defective circuit still worked. (But bus hold devices would also explain it.)

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

The "actual" datasheet http://6502.org/documents/datasheets/wdc/wdc_w65c22_sep_13_2010.pdf , page 50:

Still, the capacitance goes a long way in holding the bus value, assuming all loads are CMOS which basically take no DC input current. When I was writing the code to test the memory modules I sell, I noticed the value on an undriven bus being held for at least a millisecond (not just microsecond)! I did not experiment to find out how long I could drag it out.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The read/write logic to the VIA would work correctly, as it has nothing to do with the GAL. All the GAL would be responsible for on a VIA access would be generating a chip select.

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

Ouch, I hadn't seen that! I've fixed that now:

I did it this way because I think in terms of the electrical signal, not necessarily what that level means. I haven't burned the GAL yet, because I need a copy of WinCUPL, and I never put the install file on a portable disk.

Speaking of WinCUPL, does anyone know if it works under WINE? Or if there are any alternatives for Linux?

EDIT: I should say that I just need it to do 16V8s, and it doesn't necessarily have to be CUPL.
EDIT 2: I got hold of WinCUPL(I had to go to the Microchip site to do it, and the Atmel site says absolutely nothing about it). I have compiled the file, and I'm about to restart into Windows to write the PLD, because the Linux minipro software crashes(with a floating point exception, of all things) when I try to use it for 16V8s. Pain in the butt, but there's not really anything I can do about it.

Good advice on the programmer and GAL compatibility. The Atmel stuff is a bit different it seems, as many folks out here have noted issues trying to program them. I bit the bullet a few years ago and splurged on a Dataman 40Pro. Not cheap at $595 but they update their software frequently which includes an extensive list of devices they support. It's been a great programmer, but for the high cost I expect nothing less. I also picked up some adapters for PLCC chips, like 28 and 32-pin PLCCs and the cost can ramp up with these options.

In short, I prefer the hobby side working towards a finished product that works and either meets or exceeds expectations and design goals. I don't want to spend a lot of additional time experimenting and fighting the tools and such to get there. After all, I work on all my own cars as well, but I buy top quality tools and many of the manufacturer specific tools and test equipment, otherwise it's not a rewarding hobby but more of a garage nightmare, which can be quite dangerous.

_________________
Regards, KM
https://github.com/floobydust