Issue with ATF22V10C

[Chromatix]

CUPL syntax is fairly simple in its basics. However, many of its extended features are device-specific; there's more than just GALs supported by it. So when you read a document explaining CUPL (such as the WinCUPL manual), a lot of things might look useful but simply don't apply to your device - you have to carefully cross-reference each one to the datasheet. And a lot of datasheets (Atmel's included) do a really bad job of explaining precisely what the device can handle.

A CUPL tutorial would do well to take the GAL22V10 as a standard platform, and teach the relevant subset of CUPL and the capabilities of that device well.

[djkat]

Got it! Thanks for all the helpful tips everyone.
I'm going to try some things out and report back, maybe there is a way to get this working with either the power down pin or some other way (if I can find other peoples code for the ATF22V10 that should work).

[djkat]

This document: http://ww1.microchip.com/downloads/en/D ... oc0737.pdf
seems to indicate that only ATF1500 family devices from Atmel support the OE extension, although it's interesting that the Lattice GAL chips support it. I've seen documents claiming per pin OE support on the ATF22V10C as well but can't find the document now (and google doesn't seem to find any documents or code using the OE feature).

[drogon]

djkat wrote:

This document: http://ww1.microchip.com/downloads/en/D ... oc0737.pdf
seems to indicate that only ATF1500 family devices from Atmel support the OE extension, although it's interesting that the Lattice GAL chips support it. I've seen documents claiming per pin OE support on the ATF22V10C as well but can't find the document now (and google doesn't seem to find any documents or code using the OE feature).

That would be a deal breaker for me if I ever wanted to use them - I did buy a few a while back but my programmer didn't support them, so I got some Lattice ones. Like you, I need to tristate some output pins so my ATmega can poke the SRAM. I'm using GALasm under Linux thoug, but if the ATF chips won't support tristate outputs, then they can't claim to be compatible at all!

My GALasm logic looks like:

Code: Select all

; Write and Read signals for the RAM - qualified with the 6502 phase2 clock

/WR.T = CLK * /RW * BE
/RD.T = CLK *  RW * BE

; Single Enable input to tristate the chip select, etc. outputs

WR.E = BE
RD.E = BE

I'm wondering if you could simplify your design using the BE input to the 65C02? that's what I'm using - pull it low and the C02 tristates the address and data bus (but not the RW output) I drive it from the ATmega side and it goes into the GALs and the C02 (and '816)

-Gordon

[djkat]

Hi Gordon, great to hear from you, I recently looked at your blog as I'm interested in other peoples designs and I really like your idea of using an atmega for SD card input etc. to avoid bitbanging it on the 6502.

My design actually already uses an atmega4809 chip, initially just as a bootloader to fill up my SRAM to avoid slow EEPROM chips (like you I assume?).
I'm redesigning a test on breadboard right now to try to make a new solution (inspired by yours!) to have a shared part of SRAM to communicate back and forth between the two chips.
I hope I can ask some questions if I run into problems?

Regarding your post above, I have never used GALasm, why do you prefer it? I would be happy to use something other than wincupl in any case.

Cheers,
Daniel

[Chromatix]

Apparently Atmel's preferred current production is the ATF22LV10CQZ. The datasheet for this clearly shows OE product terms for each output pin. This is also their "zero power" variant which automatically switches off the power-hungry product term circuitry when there are no input transitions to follow.

[drogon]

djkat wrote:

Hi Gordon, great to hear from you, I recently looked at your blog as I'm interested in other peoples designs and I really like your idea of using an atmega for SD card input etc. to avoid bitbanging it on the 6502.

My design actually already uses an atmega4809 chip, initially just as a bootloader to fill up my SRAM to avoid slow EEPROM chips (like you I assume?).
I'm redesigning a test on breadboard right now to try to make a new solution (inspired by yours!) to have a shared part of SRAM to communicate back and forth between the two chips.
I hope I can ask some questions if I run into problems?

Sure - here or in email is OK, and yes, I wanted a minimal design with no slow ROM type chips. The shared window I have is at $FFxx just 256 bytes, but it's reduced to about 132 bytes when the system is running as the upper half page is used for the hardware and operating system vectors.

Quote:

Regarding your post above, I have never used GALasm, why do you prefer it? I would be happy to use something other than wincupl in any case.

Cheers,
Daniel

I used GALasm because it was the only thing that runs under Linux that I could find. 100% Linux user here - well, almost. I thought it would be good when I saw that my TIL programmer would run under Linux, but I got the older one that wouldn't program GALs (turned out to be one of the clones too, bother). So I resurrected an ol dWinXP laptop and bought a Genius G540 programmer for the Lattice GALs, but it won't touch the ATmel ones.

Cheers,

-Gordon

[floobydust]

Chromatix wrote:

Apparently Atmel's preferred current production is the ATF22LV10CQZ. The datasheet for this clearly shows OE product terms for each output pin. This is also their "zero power" variant which automatically switches off the power-hungry product term circuitry when there are no input transitions to follow.

Atmel (now Microchip) still show the ATF22V10B, ATF22V10C, ATF22V10CQ and ATF22V10CQZ in current production. The main differences are power consumption, temperature range, rated clock speed and propagation time. The CQZ is the slowest, with a maximum rated clock speed of 50MHz, while the ATF22V10B versions at 83MHz and the ATF22V10C versions go up to 166MHz.

https://www.microchip.com/wwwproducts/en/ATF22V10B
https://www.microchip.com/wwwproducts/en/ATF22V10C
https://www.microchip.com/wwwproducts/en/ATF22V10CQ
https://www.microchip.com/wwwproducts/en/ATF22V10CQZ

As noted, programming them (Atmel/Microchip) can be difficult with many of the low-cost programmers. I've been using a Dataman 40pro for about 7 years now... it wasn't cheap, but (software) updates are still frequent and it handles the Atmel versions without any issue.

I use the CQZ version is my current SBC for a single glue logic chip.... it hovers around 40ma IIRC.

[cbscpe]

I have been using GALs a lot. However I always had many difficulties finding a programmer that supported the brands I got like Lattice, NS, TI etc. Also when buying Lattice GALs they are now mostly pulled devices and I did not always receive working ones. Using used and new GALs is always additional trouble-shooting as you never know is it the design, your setup, the programmer which did something wrong or is it a bad GAL. Programmers which officially support certain brands are mostly very expensive. The batch of China programmers all claim they can do all those chips but in a corner case you will be lost. Today only Microchip produces the ATF16V8 and ATF22V10 GALs. Many users in the internet claim the TL866II Plus supports them.

However this programmer was not available when I gave up the GALs. Or I should say, I completely switched to Microchip (former Atmel) CPLDs ATF1504 and ATF1508. As BDD says a ATF1504 in a PLCC-44 package does not use significantly more space than a ATF22V10. (DIP-24), but offers much more options and resources.

I can only recommend that you have a look into these CPLDs. They are extremely flexible and you get a USB Download Cable ATDH1150USB to program the for the same price you would pay for a TL866II Plus. But different to the TL866II Plus the USB Cable is an official Atmel product that supports the CPLDs. The required software is free and can be retrieved from Microchip. WinCUPL is quite flexible and allows you to create your designs in a very simple way. The programmer requires the Atmel ISP software which is as well a free download from Microchip.

Getting used to CPLDs may not always be easy but it was worth the effort I spent in learning how to use them. I'm happy to share my experience and give advice if you like. Some of my projects can be seen http://www.5votls.ch

Using these CPLDs requires some understanding of how they are internally structured and not always WinCUPL does what you want and honestly I had many strange results and a bad design file easily crashes WinCUPL. The error messages are cryptic and not always very useful. Eventually I will add my findings on my homepage.

Peter

[GARTHWILSON]

cbscpe wrote:

Getting used to CPLDs may not always be easy but it was worth the effort I spent in learning how to use them. I'm happy to share my experience and give advice if you like. Some of my projects can be seen http://www.5votls.ch

I get the error message, "Hmm. We’re having trouble finding that site. We can’t connect to the server at http://www.5votls.ch.

[thedrip]

Looks like a typo, should have been http://www.5volts.ch , not 5votls.ch

[cbscpe]

Sorry, yes of course, my bad.

[SteveD]

Hi all,
have recently been using WinCUPL 5.30.4 to design logic for a retro 6502 computer project of mine.

I've used both the ATF22V10C and ATF16V8B, programmed successfully with a genuine TL866II+.

I initially tried running WinCUPL in a Win 7 x64 virtual machine and it was awful. It would crash constantly, often without giving any useful error information. In frustration I tried running it up in a Win 7 x32 VM. This has done the trick, stable, working, all good. It's obviously 32 bit software.

[BigDumbDinosaur]

SteveD wrote:

I initially tried running WinCUPL in a Win 7 x64 virtual machine and it was awful. It would crash constantly, often without giving any useful error information. In frustration I tried running it up in a Win 7 x32 VM. This has done the trick, stable, working, all good. It's obviously 32 bit software.

Actually, WinCUPL dates back to the days of Windows 3.1 which, of course, ran on top of a 16-bit operating system. Because it is free software, Microchip has not felt any motivation to clean up WinCUPL and address the bugs.

[BigEd]

(welcome, SteveD! It would be good to see a thread about your 6502 retro project some time...)