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 - .
I have tried to implement this usng a 16v8 GAL using WinCUPL -
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?
Wait state using a 16V8 GAL
Re: Wait state using a 16V8 GAL
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
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
Re: Wait state using a 16V8 GAL
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:
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.
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);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.
Re: Wait state using a 16V8 GAL
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
Daryl
Please visit my website -> https://sbc.rictor.org/
Re: Wait state using a 16V8 GAL
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
Daryl
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.
- BigDumbDinosaur
- Posts: 9428
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: Wait state using a 16V8 GAL
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.
x86? We ain't got no x86. We don't NEED no stinking x86!
Re: Wait state using a 16V8 GAL
BigDumbDinosaur wrote:
From where did you get those GALs?
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.)
Re: Wait state using a 16V8 GAL
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
Daryl
Code: Select all
FF.d = !rom & !FFRe: Wait state using a 16V8 GAL
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.
I can confirm that WinCUPL does not like Windows 10, a use Windows XP and even then I have unexpected crashes.
- BigDumbDinosaur
- Posts: 9428
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: Wait state using a 16V8 GAL
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.
Quote:
I can confirm that WinCUPL does not like Windows 10, a use Windows XP and even then I have unexpected crashes.
x86? We ain't got no x86. We don't NEED no stinking x86!