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?

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

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 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/

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.

From where did you get those GALs?

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

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.)

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


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.

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.

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.


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!