Wait state using a 16V8 GAL

For discussing the 65xx hardware itself or electronics projects.
Post Reply
malcnorth
Posts: 17
Joined: 23 Oct 2013

Wait state using a 16V8 GAL

Post by malcnorth »

I have been reading the posts elsewhere on here about inserting wait states and I also found an old Apple I manual with a wait state using a D flop and a nand gate -
WAIT - Schematic.pdf
Circuit from Apple manual
(7.39 KiB) Downloaded 239 times
.

I have tried to implement this usng a 16v8 GAL using WinCUPL -
wait.txt
Wait state & decode CUPL source
(1.61 KiB) Downloaded 200 times
I keep getting errors when I use ready.io, ready.dfb or ready.dq.

I was just wondering if anybody else had tried this and had any idea what I am doing wrong?
granati
Posts: 83
Joined: 24 Jun 2013
Location: Italy

Re: Wait state using a 16V8 GAL

Post by granati »

Hello,
you cannot drive clock input od d-ff on gal16v8 from a feedback signal from output macrocell, so you must connect phi1 directly to pin 1 (clock input), but i think you need an external inverter to get phi1 because no more input pin available in your application.
And more: pin 11 of gal16v8 used in "registered" mode will be connected to gnd, because in this configuration macrocell output are trhee-state (but im not sure, look at datasheet).
For RDY generation: you can use directly the rising edge of phi2 if you use the cmos version (65c02), because it sample rdy at end of phi2, instead nmos version need rdy low while phi1 time.

Greetings
Marco
http://65xx.unet.bz/ - Hardware & Software 65XX family
malcnorth
Posts: 17
Joined: 23 Oct 2013

Re: Wait state using a 16V8 GAL

Post by malcnorth »

OK thanks for that but that bit compiles ok.

I am not using pin 11 so I can ground that.

The problem I am getting is at compile time with the ready.d line:

Code: Select all

ready.d = !(ready.dq & rom);
i've tried different extensions for the feedback term but all of them produce a compiler error.

The error is: "The pin number assigned to the variable is invalid for the target device specified."

tried .int, .dq, .dfb, .io, none of which work. I can't find any other extensions.

According to the datasheet there is a feedback path available from the not dq output.

TBH it's not worth the hassle I'll just stick a 74ac74 in and feedback through pins 9 and 12.
User avatar
8BIT
Posts: 1787
Joined: 30 Aug 2002
Location: Sacramento, CA
Contact:

Re: Wait state using a 16V8 GAL

Post by 8BIT »

I helped with a wait-state generator using the 16V8 a few years back. The info is on my website, including winCUPL source. You can find it here -> http://sbc.rictor.org/wsgen.html

Daryl
Please visit my website -> https://sbc.rictor.org/
malcnorth
Posts: 17
Joined: 23 Oct 2013

Re: Wait state using a 16V8 GAL

Post by malcnorth »

8BIT wrote:
I helped with a wait-state generator using the 16V8 a few years back. The info is on my website, including winCUPL source. You can find it here -> http://sbc.rictor.org/wsgen.html

Daryl
Thank you Daryl. I have seen your posts but didn't come across the link before. I'll give that a try.

Although, I have just programmed some devices with an external hc74 and i'm only getting 2 volts on some of the outputs so I think I have some dodgy GALs.
User avatar
BigDumbDinosaur
Posts: 9428
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Wait state using a 16V8 GAL

Post by BigDumbDinosaur »

malcnorth wrote:
Although, I have just programmed some devices with an external hc74 and i'm only getting 2 volts on some of the outputs so I think I have some dodgy GALs.
From where did you get those GALs?
x86?  We ain't got no x86.  We don't NEED no stinking x86!
malcnorth
Posts: 17
Joined: 23 Oct 2013

Re: Wait state using a 16V8 GAL

Post by malcnorth »

BigDumbDinosaur wrote:
From where did you get those GALs?
Various sources: ATF16V8Cs, ATF22V10 from Mouser. (unable to program)

Lattice 16V8D-15 Ebay ... UK Source.

Atmel 16V8Bs from Ebay. Can program

Just ordered some Lattice 22V10-7s on Ebay from Israel.

It looks like my mod caused the 2V problem, I had 2 outputs against each other. Fixed that but don't seem to be able to get any of these GALs to work (had same problem in different board.)
malcnorth
Posts: 17
Joined: 23 Oct 2013

Re: Wait state using a 16V8 GAL

Post by malcnorth »

8BIT wrote:
I helped with a wait-state generator using the 16V8 a few years back. The info is on my website, including winCUPL source. You can find it here -> http://sbc.rictor.org/wsgen.html

Daryl
I have just been trying this. As I only require 1 wait-state I entered the following:

Code: Select all

FF.d = !rom & !FF
Unfortunately the compiler just simply crashes so I am going to have to try and find an older version of windows to run on as it seems the compiler doesn't like Windows 10.
User avatar
cbscpe
Posts: 491
Joined: 13 Oct 2013
Location: Switzerland
Contact:

Re: Wait state using a 16V8 GAL

Post by cbscpe »

As for the ATF SPLDs, the Wellon VP-290 seems to support these GALs as stated by the member Martin A of this board. It's about 120USD and available from Kanda and others. The problem with your design is that GALs do not provide internal feedbacks of FF outputs to be used as input. And as such the .io extension is not valid. You need to used dedicated pins and connect them externally. Not all extensions are valid for all devices.

I can confirm that WinCUPL does not like Windows 10, a use Windows XP and even then I have unexpected crashes.
User avatar
BigDumbDinosaur
Posts: 9428
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Wait state using a 16V8 GAL

Post by BigDumbDinosaur »

cbscpe wrote:
As for the ATF SPLDs, the Wellon VP-290 seems to support these GALs as stated by the member Martin A of this board. It's about 120USD and available from Kanda and others. The problem with your design is that GALs do not provide internal feedbacks of FF outputs to be used as input. And as such the .io extension is not valid. You need to used dedicated pins and connect them externally. Not all extensions are valid for all devices.
Also note that since you cannot internally feed back flop outputs you incur 2x prop delay if you do need to set up feedback, since the prop delay of the part is rated pin-to-pin.
Quote:
I can confirm that WinCUPL does not like Windows 10, a use Windows XP and even then I have unexpected crashes.
WinCUPL is touchy software and appears to have memory leakage problems, especially with the simulator. Only fix for that is to periodically close the program and restart it.
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Post Reply