very simple Expansion Interface (new to CPC)

[Prox]

Am i too stupid for this?


I cannot even get a simple D-FF with the GAL....


here is the code:
https://pastebin.com/tkQ0Nw7y


I don't understand. the circuit is connected as the inputs show. and the output is connected to an LED Bar Graph.


also yes i did remove the pull downs from the address and data bus.


the CPC itself starts up but trying to do "OUT (&FFFF), &0F" or any value results in nothing changing on the output.


for some reason the output LEDs are constantly on, like there is constantly some value being written to it. but the CPC itself never does writes to &FFFF, right? and if there is, what should i decode to isolate that one port, so nothing from the CPC itself ever writes to it?


also as might be seen on the pastebin i use .SP to store the data, and the CLK input is the WR signal. i checked the timing of the GAL and the Z80 and the GAL should be fast enough to grab the data from the bus when the WR goes high.


i might try to seperate that signal from WR and use the system clock for that or something.

[LambdaMikel]

... one thing I might add is - if you relied on the pin numbering on the breakout header PCB, then this might be wrong... please make sure you really have the right pins. The pin marked "1" on the breakout header might not be the "real CPC expansion port 1"... it might be anything from from { 1, 2, 49, 50 }.
I guess I should have said that earlier, I am just not sure if 1 is really 1. Please check.


Well, I would probably start by identifying  VCC and GND and put an LED (with resistor) to make sure we have the right pins...

[LambdaMikel]

Do you have a logic probe?? This is incredibly useful and inexpensive for debugging these kinds of situations.


https://www.amazon.de/Laser-5263-Logiktester-DC/dp/B006IRIP8I/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=logic+probe&qid=1554399584&s=gateway&sr=8-1


Put it in pulse mode and check if you are correctly detecting the _IORQ & _WR (or _IORQ & _RD)

So, my suggestion is - buy that logic probe, define a WRITE and READ signal output in the GAL, that triggers when &FFxx is written or read, respectively, and then put the logic probe in PULSE mode and monitor your READ and WRITE GAL outputs.

Then write a BASIC program:

10 out &ffff,10
20 goto 10

10 a=inp(&ffff)
20 goto 10

and monitor READ and WRITE accordingly.

[Prox]

... one thing I might add is - if you relied on the pin numbering on the breakout header PCB, then this might be wrong... please make sure you really have the right pins. The pin marked "1" on the breakout header might not be the "real CPC expansion port 1"... it might be anything from from { 1, 2, 49, 50 }. I guess I should have said that earlier, I am just not sure if 1 is really 1. Please check. Well, I would probably start by identifying  VCC and GND and put an LED (with resistor) to make sure we have the right pins...

I used my Multimeter in continuity mode and put one probe on the +5V pin of the Power connector and went through each pin of the breakout board until i had it, from there it was obvious how the rest of the pins are layed out. and yes i got them all correct.

Do you have a logic probe?? This is incredibly useful and inexpensive for debugging these kinds of situations.


https://www.amazon.de/Laser-5263-Logiktester-DC/dp/B006IRIP8I/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=logic+probe&qid=1554399584&s=gateway&sr=8-1


Put it in pulse mode and check if you are correctly detecting the _IORQ & _WR (or _IORQ & _RD) So, my suggestion is - buy that logic probe, define a WRITE and READ signal output in the GAL, that triggers when &FFxx is written or read, respectively, and then put the logic probe in PULSE mode and monitor your READ and WRITE GAL outputs. Then write a BASIC program:10 out &ffff,1020 goto 10 10 a=inp(&ffff)20 goto 10 and monitor READ and WRITE accordingly.

well i cannot really do reads from the flip flop. that is why that part of the code is commented out. i tried to do that and it only resulted in the CPC acting strange, i was unable to use the majority of the keys on the keyboard so i changed the code up to always output the data and just hooked it up to some LEDs


also this would be a lot easier if the simulation function of WinCUPL would actually work and not just give a "Simulation Errors encounter" with nothing else to go by. no error code or anything.


i will still get myself a probe, it overall seems like a good idea

EDIT: ok for some reason the text was tiny, whoever programmed the formating on this site should really reconsider all of their life choices

[LambdaMikel]

well i cannot really do reads from the flip flop. that is why that part of the code is commented out. i tried to do that and it only resulted in the CPC acting strange, i was unable to use the majority of the keys on the keyboard so i changed the code up to always output the data and just hooked it up to some LEDs


i will still get myself a probe, it overall seems like a good idea

EDIT: ok for some reason the text was tiny, whoever programmed the formating on this site should really reconsider all of their life choices

yes i would get the combinational logic working first, and then work on doing the flip flop in the gal.
the latter is more difficult.


when you have READ and WRITE pulsing correclty, you can combine ADR & WRITE to trigger / load the external d flipflop you were using before. that is easier to debug.


when that is working, you can move the flipflop into the gal.

[IanS]

for some reason the output LEDs are constantly on, like there is constantly some value being written to it. but the CPC itself never does writes to &FFFF, right? and if there is, what should i decode to isolate that one port, so nothing from the CPC itself ever writes to it?

But you aren't checking for &ffff, you are only checking for A15 & A14 being high, so basically anything on this page http://www.cpcwiki.eu/index.php/I/O_Port_Summary that start with %xx will be matched by your device. (The CPC generally has a simplified addressing scheme, the on-board devices only check for a single bit being low). So even the ROM page address &df00 (%xx0xxxxx) will match along with the writes to the 8255 for reading the keyboard.

[LambdaMikel]

But you aren't checking for &ffff, you are only checking for A15 & A14 being high, so basically anything on this page http://www.cpcwiki.eu/index.php/I/O_Port_Summary that start with %xx will be matched by your device. (The CPC generally has a simplified addressing scheme, the on-board devices only check for a single bit being low). So even the ROM page address &df00 (%xx0xxxxx) will match along with the writes to the 8255 for reading the keyboard.

Right, partial decoding is dangerous...

[Prox]

But you aren't checking for &ffff, you are only checking for A15 & A14 being high, so basically anything on this page http://www.cpcwiki.eu/index.php/I/O_Port_Summary that start with %xx will be matched by your device. (The CPC generally has a simplified addressing scheme, the on-board devices only check for a single bit being low). So even the ROM page address &df00 (%xx0xxxxx) will match along with the writes to the 8255 for reading the keyboard.

I don't really have a lot of pins free on the GAL so i would need 2 to to properly decode everything.


might do that though and just literally check everry single bit to be 0xFFFF


actually when i do the math the 24 pin GAL i use have a total of 22 usable pins. so when i got the entire address bus on that i still would have 6 pins left over, either i can then hook up 6 individual IO Devices, or i can also encode those 6 bits and hook up to 64 different IO Devices (though i would need more GALs to decode those 64 output lines into something usable).


obviously not gonna do all that right away, i will just hook up a single IO Device and just use a single output from the GAL. but the idea is still good for larger things.


i really wish i could use these ATF2500C's i got lying around, so many IO Pins... but my programmer doesn't support them.

[LambdaMikel]

... this is also where the logic probe would have already helped you... you would have seen that the "on" LEDs have a pulse, rather than a steady "1", due to picking up different addresses and IO activity.

[Prox]

alright probe arrives tomorrow.


doesn't mean i just have to sit around.


so i tried to compile this code for the GAL. i didn't use fields or anything just to make it simplier on the chip...



https://pastebin.com/zKqrzqVq

and this doesn't compile... only error code i get is "CSIM Erros encountered", nothing more

and can i just say how i hate this program at times, it's quite clear this hasn't been updated since around Win 3.11.

it's functional, somewhat... but not comfortable. writing is strange and buggy, text colors only sometimes update, and the error codes are useless.

[LambdaMikel]

Can you try moving the negations (!'s) to the right sides of the equations?

[Prox]

Can you try moving the negations (!'s) to the right sides of the equations?

i can, but would that change anything? i used the same way of doing logic with another program that is used in my stand-alone Z80 Computer and it works fine.


oh well, better to try everything, right?


ok so after doing that i got the "Excessive number of Product terms" erro for both outputs


because doing it like this:

IORD = RD # IORQ # !A0 # !A1 # !A2 # !A3 # !A4 # !A5 # !A6 # !A7 # !A8 # !A9 # !A10 # !A11 # !A12 # !A13 # !A14 # !A15;
IOWR = WR # IORQ # !A0 # !A1 # !A2 # !A3 # !A4 # !A5 # !A6 # !A7 # !A8 # !A9 # !A10 # !A11 # !A12 # !A13 # !A14 # !A15;

aparently takes up more logic/cells on the chip than doing this:

!IORD = !RD & !IORQ & (A0 & A1 & A2 & A3 & A4 & A5 & A6 & A7 & A8 & A9 & A10 & A11 & A12 & A13 & A14 & A15);
!IOWR = !WR & !IORQ & (A0 & A1 & A2 & A3 & A4 & A5 & A6 & A7 & A8 & A9 & A10 & A11 & A12 & A13 & A14 & A15);

which is strange.



can't i just use less inputs and only decode the upper 8 bits of the Address bus?

[LambdaMikel]

You could try an auxiliary variable:

Y = ....
X = ! Y

Internally, that should not make any difference anyhow, because of the minimization / optimization performed by the program.

For readability, I would always write it as a conjunction and use parantheses:

X = ! ( A & B & ... )

[LambdaMikel]

Did you look at this?

https://github.com/lambdamikel/LambdaSpeak/blob/master/firmware/ls195/gal22v10/ls195-address-decoder-U1.PLD
That does very similar things and fits and compiles...

[Prox]

Did you look at this?

https://github.com/lambdamikel/LambdaSpeak/blob/master/firmware/ls195/gal22v10/ls195-address-decoder-U1.PLD
That does very similar things and fits and compiles...

well if i rewrite it to something similar i still get the CSIM Error.

Code Select Expand


Name     CPC464 ;
PartNo   00 ;
Date     01.04.2019 ;
Revision 01 ;
Designer Engineer ;
Company  Team Rocket ;
Assembly None ;
Location None ;
Device   G22V10 ;

/**************** INPUT PINS *********************/
PIN 1  = A0;
PIN 2  = A1;
PIN 3  = A2;
PIN 4  = A3;
PIN 5  = A4;
PIN 6  = A5;
PIN 7  = A6;
PIN 8  = A7;
PIN 9  = A8;
PIN 10 = A9;
PIN 11 = A10;
PIN 13 = A11;
PIN 14 = A12;
PIN 15 = A13;
PIN 16 = A14;
PIN 17 = A15;

PIN 18 = WR;
PIN 19 = RD;
PIN 20 = IORQ;


/**************** OUTPUT PINS *********************/
PIN 22 = IORD;
PIN 23 = IOWR;


/**************** DECLARATIONS *********************/

ADDR = A0 & A1 & A2 & A3 & A4 & A5 & A6 & A7 & A8 & A9 & A10 & A11 & A12 & A13 & A14 & A15;

/**************** EQUATIONS *********************/

!IORD = !RD & !IORQ & ADDR;
!IOWR = !WR & !IORQ & ADDR;


and if i try to do the decoding like you did (without the ! infront of the output) i just get the same "Excessive number of Product terms" error.

otherwise that is basically identical as far as i can see.

even trying this doesn't work and gives a CSIM error

Code Select Expand

FIELD ADDR = [A0..15];
ACTIVE = ADDR:'h'FFFF;


/**************** EQUATIONS *********************/

!IORD = !RD & !IORQ & ACTIVE;
!IOWR = !WR & !IORQ & ACTIVE;





I must be missing something massive because the error message itself says "warnings: 0, errors: 0"
yet still it doesn't compile.


my other code compiles without issue

[LambdaMikel]

Maybe you have configured the project not for the GAL22V10, but for some smaller device?
Are you sure the project device settings are correct?

If my code doesn't compile in your setup, then there is something wrong with project setup or program installation.

[Prox]

Maybe you have configured the project not for the GAL22V10, but for some smaller device?
Are you sure the project device settings are correct?

If my code doesn't compile in your setup, then there is something wrong with project setup or program installation.

wel i can close the project and reopen it. and the header is correct and works for the G22V10. (good way to test that was by setting one pin to be higher than 23, which causes an error)


and just using your code straight also gives the CSIM error.


it makes no sense since i can compile other programs.


and i just tried to copy the main part of the code into another project and it compiles perfectly fine


what the fuck is this, who wrote this program.

[LambdaMikel]

CSIM error makes no sense unless you are actually using the simulator?


Q. When I am compiling, I get CSIM errors, but I'm not trying to simulate it yet. [/size]A. Turn off simulation in the Compiler Options menu.


Well, there are alternatives to WinCUPL, but I never tried any of these.
Maybe somebody else can suggest an alternative for GALs.

[LambdaMikel]

i can, but would that change anything?

Well, at least in a classical programming language, the left sides of an assignment are not expressions, but "lvalues", and I am surprised that you are saying it works I must say. I did not see any CUPL example that ever used negation on the left side... IMHO that should just be a single variable. But my knowledge of this stuff is limited as well.

[LambdaMikel]

This one you already read, right?
http://ee-classes.usc.edu/ee459/library/documents/CUPL_Reference.pdf


https://class.ece.uw.edu/475/peckol/doc/cupl.html#programming



So, with all these references, a logic probe, trial and error and maintaining a calm attitude, I am sure you will figure it out!! Best of luck and keep us updated. 

[Prox]

CSIM error makes no sense unless you are actually using the simulator?


Q. When I am compiling, I get CSIM errors, but I'm not trying to simulate it yet. A. Turn off simulation in the Compiler Options menu.


Well, there are alternatives to WinCUPL, but I never tried any of these.
Maybe somebody else can suggest an alternative for GALs.

ok i turned "simulate" off and it worked too!


amazing, also the circuit itself is working.

Spoiler: ShowHide

https://i.imgur.com/jhpouGR.jpg

Spoiler: ShowHide

https://youtu.be/U7pflpQ1MFo

i forgot to cut out the audio of the video. so ignore the crackling.

Well, at least in a classical programming language, the left sides of an assignment are not expressions, but "lvalues", and I am surprised that you are saying it works I must say. I did not see any CUPL example that ever used negation on the left side... IMHO that should just be a single variable. But my knowledge of this stuff is limited as well.

well the youtube tutorial i watched also did the negations on the left side as well.

you can also asign negative pins

something like:

PIN 1 = !IN
PIN 20 = !OUT

it should function in the same way.

and as said before, not doing the negation actually uses up more logical space on the chip and is therefore a lot more limiting

[LambdaMikel]

you can also asign negative pins

something like:

PIN 1 = !IN
PIN 20 = !OUT

it should function in the same way.

Of course... but you were saying you used


!PIN 1 = IN


and that I never saw before. But anyhow 


Congrats to making it work!


Yes this program is a pain in the ****.