Starting with my first SBC Project, Plans and Confusions

[BigEd]

(BDD's expression of disdain for USB in hobby projects is of course a personal take - it's by no means universal, or, I would say, even a very common position to take.)

[BillO]

Dr Jefyll wrote:

DerTrueForce wrote:

Are you sure you don't need VCORE? That sounds pretty critical to me.

I agree it sounds critical. Surprisingly, it may be "left unterminated."

VCORE is the 1.8V output from the internal regulator. The device's own core runs at 1.8V. They provide this output so that you can power the I/O though VCCIO when you are interfacing with other 1.8V devices. Just a convenience.

[Proxy]

BigDumbDinosaur wrote:

That is to say, you may have another "head slapper" situation.

I hate the fact that you were correct.

i finally got the FTDI Chip to work
it shows as as COM Port 6 on my PC, and i wanted to test it with a simple "Hello World" Program

.

but then i ran into some problems, when it tried to read from 0xDF01 (which is the status of the FT240X) it just came back with 0xFF everytime, so i checked with my logic probe and for some reason it my GALs don't decode the address correctly

sadly cannot really verify the chips are being programmed properly (damn security fuse or something), which is a problem because it doesn't seem like they're working right.

Code: Select all

!IO_EN    = A15 & A14 & !A13 & A12 & A11 & A10 & A9 & A8;

this little snippet right here is supposed decode all IO Addresses so that IO_EN is low when the high byte of the input address is 0xDF. but when trying on the actual PCB it doesn't work at all... IO_EN never goes low, i checked all 8 inputs manually and it should've worked.

even more strange, this logic works with ROM and RAM (RAM even uses IO_EN in it's logic, which makes this even more strange as when ROM_CS and IO_EN are both high RAM gets accessed, but it doesn't when accessing 0xDFXX so that means internally it gets decoded but the output pin just doesn't get set)

to be honest i think i'll switch to CPLDs for my next project, fuck these GALs.
the ATF1504AS looks good. i just need sockets, PLCC chip puller, software to write circuits, and a programmer for it.

[BigDumbDinosaur]

Proxy wrote:

BigDumbDinosaur wrote:

That is to say, you may have another "head slapper" situation.

I hate the fact that you were correct...but then i ran into some problems, when it tried to read from 0xDF01 (which is the status of the FT240X) it just came back with 0xFF everytime, so i checked with my logic probe and for some reason it my GALs don't decode the address correctly

sadly cannot really verify the chips are being programmed properly (damn security fuse or something), which is a problem because it doesn't seem like they're working right.

Code: Select all

!IO_EN    = A15 & A14 & !A13 & A12 & A11 & A10 & A9 & A8;

Please post the entire file, not just one statement. I have a suspicion...

Quote:

this little snippet right here is supposed decode all IO Addresses so that IO_EN is low when the high byte of the input address is 0xDF. but when trying on the actual PCB it doesn't work at all... IO_EN never goes low, i checked all 8 inputs manually and it should've worked.

Could be you have a faulty GAL. Incidentally, active-low pins should be declared active low, and positive logic should be used. The correct way to do this is:

Code: Select all

PIN 21 = !IO_EN;               /* I/O enable (active low) */

...

IO_EN = A15 & A14 & !A13 & A12 & A11 & A10 & A9 & A8; /* I/O at $DFxx */

Always declare output pins as either active low or active high according to what is expected when the logic controlling said pins is true, and write your equations so when the condition is true the output of the equation is 1. Avoid negation on the left side of the expression, as it forces the GAL to internally invert everything, which is something they don't efficiently handle.

Quote:

even more strange, this logic works with ROM and RAM (RAM even uses IO_EN in it's logic, which makes this even more strange as when ROM_CS and IO_EN are both high RAM gets accessed, but it doesn't when accessing 0xDFXX so that means internally it gets decoded but the output pin just doesn't get set)

...and you've verified that nothing is preventing the GAL from sinking IO_EN, right?

Quote:

to be honest i think i'll switch to CPLDs for my next project, fuck these GALs.
the ATF1504AS looks good. i just need sockets, PLCC chip puller, software to write circuits, and a programmer for it.

You'd be using WinCUPL to program the CPLD, so you won't be gaining anything other than a device with more logic resources and more I/O pins. I suggest you solve the fundamental problem with the GAL before you chuck your work out the window and start over.

BTW, you mentioned the GAL's security fuse. Did you program the GAL or was it done for you?

[Proxy]

BigDumbDinosaur wrote:

Please post the entire file, not just one statement. I have a suspicion...

here is the complete code:

Code: Select all

Name     65C02_GAL_H ;
PartNo   00 ;
Date     24.01.2020 ;
Revision 01 ;
Designer Engineer ;
Company  Team Rocket ;
Assembly None ;
Location None ;
Device   G22V10 ;

/* *************** INPUT PINS *********************/
PIN 1  = PH2;
PIN 2  = RW;
PIN 3  = A15;
PIN 4  = A14;
PIN 5  = A13;
PIN 6  = A12;
PIN 7  = A11;
PIN 8  = A10;
PIN 9  = A9;
PIN 10 = A8;
PIN 11 = DIS_ROM;
PIN 13 = DIS_RAM;

/* *************** OUTPUT PINS *********************/
PIN 23 = RDY;
PIN 22 = OE_MEM;
PIN 21 = WE_MEM;
PIN 20 = CS_ROM;
PIN 19 = CS_RAM_0;
PIN 18 = CS_RAM_1;
PIN 17 = EN_IO;

/* ****************** LOGIC ************************/

/* RDY.D     = RDY & !(CS_ROM & IO_EN & RDY); */

!OE_MEM   = (PH2 & RW);
!WE_MEM   = (PH2 & !RW);

!CS_ROM   = A15 & A14 & A13 & DIS_ROM;
!IO_EN    = A15 & A14 & !A13 & A12 & A11 & A10 & A9 & A8;
!CS_RAM_0 = CS_ROM & IO_EN & !A15 & DIS_RAM;
!CS_RAM_1 = CS_ROM & IO_EN & A15 & DIS_RAM;

since it works for ROM and RAM i didn't think there was a reason it wouldn't work with IO.

BigDumbDinosaur wrote:

Could be you have a faulty GAL. Incidentally, active-low pins should be declared active low, and positive logic should be used. The correct way to do this is:

Code: Select all

PIN 21 = !IO_EN;               /* I/O enable (active low) */

...

IO_EN = A15 & A14 & !A13 & A12 & A11 & A10 & A9 & A8; /* I/O at $DFxx */

Always declare output pins as either active low or active high according to what is expected when the logic controlling said pins is true, and write your equations so when the condition is true the output of the equation is 1. Avoid negation on the left side of the expression, as it forces the GAL to internally invert everything, which is something they don't efficiently handle.

oh i see, i can try that a bit later.

BigDumbDinosaur wrote:

...and you've verified that nothing is preventing the GAL from sinking IO_EN, right?

IO_EN goes from the first GAL directly into the second one. there are no resistors or other components connected to it, so there is nothing that can hold it high.

BigDumbDinosaur wrote:

You'd be using WinCUPL to program the CPLD, so you won't be gaining anything other than a device with more logic resources and more I/O pins. I suggest you solve the fundamental problem with the GAL before you chuck your work out the window and start over.

BTW, you mentioned the GAL's security fuse. Did you program the GAL or was it done for you?

I think i'd still go with the CPLDs, more IO and cells means i would only need a single one of those instead of multiple GALs. plus i should be able to program them without taking them off the PCB.
I programmed the GALs myself, but i bought them from Ebay so who knows if they were already used before...

[floobydust]

Well, using programmable logic chips is still quite new for me and I'll be the first to admit I'm not that good at it. Using WinCUPL can be painful, confusing, agonizing and downright frustrating. I actually have a situation with a 16V8 that makes no sense... but I'll avoid bringing it up here!

What I will say is that, when I do an initial programming to a device, I put it on a breadboard and hook all of the defined inputs to a DIP switch with a pull-up resistor pack and the outputs to a group of 1ma LEDs with a resistor pack to +5V. I also put a clock oscillator on the clock input. This allows me to verify the decode logic by setting the DIP switches and watching the LEDs light up accordingly. Granted, this works for a basic logic decode setup, but likely wouldn't work for more complex configurations.

Just a thought... as BDD noted. do post the full WinCUPL source, as it will be more useful for some folks to try and assist with debugging it.

[Proxy]

floobydust wrote:

Well, using programmable logic chips is still quite new for me and I'll be the first to admit I'm not that good at it. Using WinCUPL can be painful, confusing, agonizing and downright frustrating. I actually have a situation with a 16V8 that makes no sense... but I'll avoid bringing it up here!

What I will say is that, when I do an initial programming to a device, I put it on a breadboard and hook all of the defined inputs to a DIP switch with a pull-up resistor pack and the outputs to a group of 1ma LEDs with a resistor pack to +5V. I also put a clock oscillator on the clock input. This allows me to verify the decode logic by setting the DIP switches and watching the LEDs light up accordingly. Granted, this works for a basic logic decode setup, but likely wouldn't work for more complex configurations.

Just a thought... as BDD noted. do post the full WinCUPL source, as it will be more useful for some folks to try and assist with debugging it.

I thought testing it on the PCB would be enough since i always see the current address, and my program is looping so i can just sit there with my logic probe checking all inputs seperately.
but i can try with a breadboard later today, because the way i did it doesn't seem to be working

[BigDumbDinosaur]

Proxy wrote:

BigDumbDinosaur wrote:

Please post the entire file, not just one statement. I have a suspicion...

here is the complete code:

Code: Select all

Name     65C02_GAL_H ;
PartNo   00 ;
Date     24.01.2020 ;
Revision 01 ;
Designer Engineer ;
Company  Team Rocket ;
Assembly None ;
Location None ;
Device   G22V10 ;

/* *************** INPUT PINS *********************/
PIN 1  = PH2;
PIN 2  = RW;
PIN 3  = A15;
PIN 4  = A14;
PIN 5  = A13;
PIN 6  = A12;
PIN 7  = A11;
PIN 8  = A10;
PIN 9  = A9;
PIN 10 = A8;
PIN 11 = DIS_ROM;
PIN 13 = DIS_RAM;

/* *************** OUTPUT PINS *********************/
PIN 23 = RDY;
PIN 22 = OE_MEM;
PIN 21 = WE_MEM;
PIN 20 = CS_ROM;
PIN 19 = CS_RAM_0;
PIN 18 = CS_RAM_1;
PIN 17 = EN_IO;

/* ****************** LOGIC ************************/

/* RDY.D     = RDY & !(CS_ROM & IO_EN & RDY); */

!OE_MEM   = (PH2 & RW);
!WE_MEM   = (PH2 & !RW);

!CS_ROM   = A15 & A14 & A13 & DIS_ROM;
!IO_EN    = A15 & A14 & !A13 & A12 & A11 & A10 & A9 & A8;
!CS_RAM_0 = CS_ROM & IO_EN & !A15 & DIS_RAM;
!CS_RAM_1 = CS_ROM & IO_EN & A15 & DIS_RAM;

Fundamentally, the logic seems okay. It occurred to me that due to the inversion involved with the IO_EN term coupled with the amount of logic needed to control that output you may be bumping into a limitation of the GAL that the WinCUPL fitter doesn't recognize.

Quote:

I think i'd still go with the CPLDs, more IO and cells means i would only need a single one of those instead of multiple GALs. plus i should be able to program them without taking them off the PCB.

The ATF15xx series has a standard JTAG port, which is simple to implement on your board. Microchip makes a programmer that attaches to a USB port and works well.

Quote:

I programmed the GALs myself, but i bought them from Ebay so who knows if they were already used before...

It wouldn't surprise me if you had gotten pulls. In fact, one of my parts suppliers has told me just about all of the Lattice GALs being sold through eBay are fakes. Microchip (formerly Atmel) is the only producer of new GALs at this time, and theirs has an idiosyncratic programming algorithm that many programmers don't support.

BTW, in the above I saw some code that implements wait-stating with RDY. There are some problems with using RDY in that fashion. At this time, it appears clock stretching is more reliable and easier to implement. I'm on the verge of testing a circuit that does just that and may soon have results.

[leepivonka]

PIN 17 = EN_IO; <--- should this be IO_EN ?

[BigEd]

Always good to see a debugging story.

If there's one thing shared by people who are very effective at debugging, it's their sense of doubt. Whether it's something you did, something you saw, something you read, something you remembered - if the thing isn't working, then something isn't right, and the way to find out what's wrong is to doubt everything. Then work through very methodically, checking assumptions and checking measurements and checking implementation.

This way you can find bad soldering, missing wires, swapped pins, mistakes in datasheets, transcription errors, and so on. Sometimes it's the software you're using, or the devices you've bought, but not terribly often.

[drogon]

Proxy wrote:

I programmed the GALs myself, but i bought them from Ebay so who knows if they were already used before...

I get Lattice GALs (22v10D) from ebay (Chinese seller) and not had a significant problem yet. (Although I think I've just had my "working" one hit the re-program limit and now refuses to program any more). They are board pulls that have been cleaned up - I never checked if they had anything in, I just erased them, put in a simple test and started to use them. I use a Genius G540 programmer on an old WinXP laptop. I use GALasm under Linux to generate the JED file for it.

You can test your decoder on a breadboard. Just plug the GAL in, give it power and Gnd at 5v, then use jumper wires to hardwire the inputs to 5v/0v and stick an LED and resistor on the outputs. That's what I do, anyway.

I would suggest to sticking to the simple solution for now - looks like it might be a mis-labeled pin name, but I'm surprised WinCupl doesn't pick that up. I'll post my decoder later - it's not a million miles different from yours.

ruby-02.pld.txt

(1.6 KiB) Downloaded 60 times

Cheers,

-Gordon

(edited to add the file which is GALasm format, but ought to be trivial to work out what's going on)

[Proxy]

BigDumbDinosaur wrote:

Fundamentally, the logic seems okay. It occurred to me that due to the inversion involved with the IO_EN term coupled with the amount of logic needed to control that output you may be bumping into a limitation of the GAL that the WinCUPL fitter doesn't recognize.

Well yes but actually no, as leepivonka said:

leepivonka wrote:

PIN 17 = EN_IO; <--- should this be IO_EN ?

I fucked up the variable names... that's why it worked internally but never outputted the value...
at this time there were 3 mistakes on my board that were all minor stupid mistakes.
1. Reset button wrong
2. wrong caps on the USB Data lines
3. wrong variable name in logic circuit

BigDumbDinosaur wrote:

The ATF15xx series has a standard JTAG port, which is simple to implement on your board. Microchip makes a programmer that attaches to a USB port and works well.

Yea either i get that one or make a custom one with an arduino... so probably just gonna buy one.

BigDumbDinosaur wrote:

It wouldn't surprise me if you had gotten pulls. In fact, one of my parts suppliers has told me just about all of the Lattice GALs being sold through eBay are fakes. Microchip (formerly Atmel) is the only producer of new GALs at this time, and theirs has an idiosyncratic programming algorithm that many programmers don't support.

my TL866II Plus Programmer does list them in the supported devices, so i could easily use the Atmel chips (ATF22V10x) not the 15xx or 25xx ones.

BigDumbDinosaur wrote:

BTW, in the above I saw some code that implements wait-stating with RDY. There are some problems with using RDY in that fashion. At this time, it appears clock stretching is more reliable and easier to implement. I'm on the verge of testing a circuit that does just that and may soon have results.

Yea i noticed as well that it doesn't seem to work, which is strange as i build that exact same circuit in a logic simulator and it worked...
currently i just have that line disabled and run the CPU at 1MHz for Testing.
not sure how i would do "clock stretching" with my current PCB, since the Clock sadly doesn't connect to one of the GAL's outputs.

.

anyways, after fixing that i ran right into the next problem, when the CPU writes data into the FT240X i only receive 0xFF on the Terminal. checking with my logic probe the WE on the FT240X gets set to low while PH2 is High. and clearly it is writing something, otherwise it wouldn't send anything.
and checking with my arduino logic probe i can see that it actually outputs a valid value while PH2 is high...
so there has to be some timing issue between the FT240X and the CPU.
the WR timing on the FT240X is rather weirdly formated: DATASHEET (Section 3.7)
on the falling edge of the WR (and PH2) pin it reads the data into the chip. this is the reverse of my RAM for example, which reads data in on the rising edge of the WR (and therefore also PH2) signal.

i can try to invert the WE output. but i'm not sure that would work

[Dr Jefyll]

floobydust wrote:

when I do an initial programming to a device, I put it on a breadboard and hook all of the defined inputs to a DIP switch with a pull-up resistor pack and the outputs to a group of 1ma LEDs with a resistor pack to +5V. I also put a clock oscillator on the clock input. This allows me to verify the decode logic [...]

It's a good idea to verify actual behavior, especially since doubts have been raised about CUPL and about the PLD itself. But instead of setting up a breadboard in order to verify behavior, you could verify using the project itself.

All that's needed is a way to single-step the clock -- and some patience as you single-step your way through a short test program that exercises the logic in question. Garth has some single-step circuits toward the end of this page on his web site.

Yes this means you need to create the single-step circuit, but you don't need to create the PLD test jig. And using the project itself you'll test more than just the PLD -- you may unexpectedly discover info about the project.

BigDumbDinosaur wrote:

Always declare output pins as either active low or active high according to what is expected when the logic controlling said pins is true, and write your equations so when the condition is true the output of the equation is 1. Avoid negation on the left side of the expression, as it forces the GAL to internally invert everything, which is something they don't efficiently handle.

BDD, I'm scratching my head over that last sentence. The software would have to be REALLY dumb if it wastes logic resources simply because the user input took one form rather than another form which can quite easily be seen to be equivalent.

I do seem to recall that CUPL doc suggests output pins should be defined as you say, but I expect it is a suggestion only, not a warning. IOW, they're recommending a style which they think humans will find less confusing. What I don't recall is anything that'd indicate the software itself is trivially subject to confusion.

Is it your own conclusion that inefficiency can result from an issue of coding style, or can you supply a reference to elsewhere? I admit there's probably a lot in the doc I missed. Or can you show a case where two logically equivalent input files fail to produce the same output file? If so, I call that a bug report!

-- Jeff

edit: Link, brevity, misc

[BigDumbDinosaur]

leepivonka wrote:

PIN 17 = EN_IO; <--- should this be IO_EN ?

Yes it should. As I've noted elsewhere, my vision is not quite up to eagle standards.

[Proxy]

so i got the FT240X to work... basically i just turned the WR output from the GAL from Active-Low to Active-High and it works now.

except now i seem to have a logic error in my program and i cannot fiquire out why.

just to be sure i understand this correctly (i come from the Z80, so the 6502 is quite strange with some things for me)
the Overflow (V) flag i supposed to be set when some arithmetic instruction... well overflows.
so like adding 0x01 to the Accumulator when it contains 0xFF.
and when it doesn't overflow it gets cleared, right?

then i don't get why this code doesn't work, all i'm doing is using X as an index to a String, but once i increment X at the end (from 0 to 1) the V flag gets set for some reason. i know that because right afterwards is a conditional relative jump that i supposed to jump back to the start of the loop when the overflow is not set. and when it is set it completely restarts the function (ie all registers back to 0 and SP back to 0xFF)

I grabbed a snippet from my Arduino Logic Analyzer and split it into the sperate instructions with some comments.

Instructions are labeled with ">>>>" infront of them

Code: Select all

This part just loads 0xFF into the SP.

>>>>LDX 0xFF
A: 0xE001;  D: 0xA2; RD;  HIGH
A: 0xE002;  D: 0xFF; RD;  HIGH

>>>>TXS
A: 0xE003;  D: 0x9A; RD;  HIGH

This part sets all Registers to 0x00 (A, X, Y)

>>>>LDA 0x00
A: 0xE004;  D: 0xA9; RD;  HIGH
A: 0xE004;  D: 0xA9; RD;  HIGH
A: 0xE005;  D: 0x00; RD;  HIGH

>>>>TAX
A: 0xE006;  D: 0xAA; RD;  HIGH

>>>>TAY
A: 0xE007;  D: 0xA8; RD;  HIGH
A: 0xE007;  D: 0xA8; RD;  HIGH

This is the start of the "main Loop", as you can see the address loaded equals the address accessed, so X must equal 0 here

>>>>LDA 0xE022,X
A: 0xE008;  D: 0xBD; RD;  HIGH 
A: 0xE008;  D: 0xBD; RD;  HIGH
A: 0xE009;  D: 0x22; RD;  HIGH
A: 0xE00A;  D: 0xE0; RD;  HIGH
A: 0xE022;  D: 0x48; RD;  HIGH

Compare A to 0x00 to see if the String is over

>>>>CMP 0x00
A: 0xE00B;  D: 0xC9; RD;  HIGH
A: 0xE00C;  D: 0x00; RD;  HIGH

If it is jump to the "Exit"

>>>>BEQ 0x11 (0xE020)
A: 0xE00D;  D: 0xF0; RD;  HIGH
A: 0xE00E;  D: 0x11; RD;  HIGH

Push the read value onto the Stack (gotta test RAM somehow)

>>>>PHA
A: 0xE00F;  D: 0x48; RD;  HIGH
A: 0xE010;  D: 0xAD; RD;  HIGH (useless read)
A: 0x01FF;  D: 0x48; WR;  HIGH

This checks the FT240X's status pins, in this case if data can be written to the Chip

>>>>LDA 0xDF01
A: 0xE010;  D: 0xAD; RD;  HIGH
A: 0xE011;  D: 0x01; RD;  HIGH
A: 0xE012;  D: 0xDF; RD;  HIGH
A: 0xDF01;  D: 0xFE; RD;  HIGH

I only care about bit 0 so i AND away everything else

>>>>AND 0x01
A: 0xE013;  D: 0x29; RD;  HIGH
A: 0xE014;  D: 0x01; RD;  HIGH

>>>>CMP 0x01
A: 0xE015;  D: 0xC9; RD;  HIGH
A: 0xE016;  D: 0x01; RD;  HIGH

If bit 0 was set, jump back and check again, repeat until it's 0

>>>>BEQ 0xF7 (0xE010)
A: 0xE017;  D: 0xF0; RD;  HIGH
A: 0xE018;  D: 0xF7; RD;  HIGH

Grab the character from the stack again

>>>>PLA
A: 0xE019;  D: 0x68; RD;  HIGH
A: 0xE01A;  D: 0x8D; RD;  HIGH (useless read)
A: 0x01FE;  D: 0x86; RD;  HIGH (useless read)
A: 0x01FF;  D: 0x48; RD;  HIGH

Load it into the FT240X

>>>>STA 0xDF00, A
A: 0xE01A;  D: 0x8D; RD;  HIGH
A: 0xE01B;  D: 0x00; RD;  HIGH
A: 0xE01C;  D: 0xDF; RD;  HIGH
A: 0xDF00;  D: 0x48; WR;  HIGH

Increment X (the pointer into the String)

>>>>INX
A: 0xE01D;  D: 0xE8; RD;  HIGH

Check if X overflowed (overflew?), if it didn't go back to the "Main Loop"

>>>>BVC 0xE8 (0xE008)
A: 0xE01E;  D: 0x50; RD;  HIGH
A: 0xE01E;  D: 0x50; RD;  HIGH
A: 0xE01F;  D: 0xE8; RD;  HIGH

This is the "Exit", if the CPU reaches this the string either ended or X overflowed (overflew?)

>>>>BRA 0xDF (0xE001)
A: 0xE020;  D: 0x80; RD;  HIGH
A: 0xE021;  D: 0xDF; RD;  HIGH
A: 0xE022;  D: 0x48; RD;  HIGH (useless read)

Repeat from the very start
A: 0xE001;  D: 0xA2; RD;  HIGH
A: 0xE002;  D: 0xFF; RD;  HIGH

sorry for kinda switching topics so quickly