Ittiara, a 65C02 handheld

[DerTrueForce]

I did use that, actually.
I think I must have made a greenhorn mistake in not realising what I was doing. Negative layers make sense when I think about it, but I never saw anything about the soldermask being negative anywhere. It's still going to be irritating soldering those tiny ICs.

[BigEd]

I suppose an actual checklist could be a good thing - that's one of the approaches we use in chip design, where there are lots of possible checks and many possible pitfalls, and it's so expensive and time-consuming to go to manufacture that it's worth having a tedious process to go through very carefully. Same thing for pre-flight checklists in aviation: perform each check, call it out, confirm it.

[DerTrueForce]

I just discovered another mistake I made, this time in the design. My /RD and /WR logic works as intended, so that's good, but the write-protect logic on the ROM's /WE line is wrong. Turns out that I should have bought an OR gate instead of a NOR.
I got it off the board without destroying it, and I'll short that to VCC for now, until I order and receive the right part.

Oh, wait a minute... I probably shouldn't have mounted that ROM socket. That'll make putting that gate in a lot harder... Good thing I caught it before I put in the RAM socket, or it would be nearly impossible. And if I can't put that in, there's really no need for the wire...

[DerTrueForce]

Yesterday I realised that I could run the VIA without RAM, and without getting in the way of the soldering iron. I tried an up-counter out of both VIA ports, and it failed to work, regardless of what I tried.

Today, I started trying to test the PLD I use for my address decoder. Initially, I did this by hand, but quickly realised there was going to be a vast number of addresses to test. However, I did notice that some ranges seemed to be selecting everything.
I realised(with a bit of help) that I could test exactly what it was doing using an Arduino.
I had it apply all possible addresses, read out the results, and report them over the serial port. I captured that in TeraTerm, and had it log the output. Then I ran that through a program I wrote in Java to condense it into ranges that produced the same output pattern, adn also indicate what is being selected.

It is indeed selecting everything in certain ranges, but the ranges it does this in seem to be a little inconsistent.
The intended ranges for the 65SPI, DUART, and VIA are correct. The ranges $3F00-$7FC0(RAM) and $BF00-$FFFF(ROM) are also correct.
The rest are about half-and-half correct and select-all. It seems that the select-all conditions occur when A8 and A14 are low.
I haven't actually analysed the whole lot yet. It's gone from 4096 addresses to 131 ranges. I tried to apply WinSim to those ranges, but it overflows and crashes when I try to put anything into the 65th vector. And CSIM does nothing but report errors for me.

I've attached the range file and the PLD file I'm trying to use, if anyone wants to take a look. The rage file only has three hex digits, because that's all the PLD takes.
I'm going to try re-programming the 16V8, see if that makes a difference.

EDIT: Re-programming made no difference. The readout remained the same. I think this means that it's my CUPL equations at fault.

[LIV2]

I could be wrong but does it have something to do with ADDRESS being 12-bit while your equations all specify 16-bit numbers?
You might need to chop off the lower 4 bits of your addresses to make it work properly. i.e
(I'm not sure if the syntax is correct but you should get the point)

Code: Select all

FIELD ADDRESS = [A15..4];

/*RAM  = ADDRESS :[000..7FC];*/
/* I have to do this to get around the insufficient product terms error*/
RAM  = !UART & !VIA & !SPI & !ADDRESS :[800..FFF];
UART = ADDRESS :[7FD];
VIA  = ADDRESS :[7FE];
SPI  = ADDRESS :[7FF]; /* The 65SPI only has 4 addresses, */
                              /* but it is assigned 16 bytes in  */
                              /* the memory map due to not having*/
                              /* enough pins to decode beyond 8, */
                              /* and being the odd one out.      */
ROM  = ADDRESS :[800..FFF];

[DerTrueForce]

You may be right. I thought that since it was specified as A4 to A15, that doing it like I did was indicated. And it does seem to expand it correctly in the .doc.
I'll try it. If it works, that'll be one of those "gotchas" that WinCUPL seems to be full of.

EDIT: Nope. That leaves ranges where nothing is selected, and puts ROM and RAM around the wrong way. It was a good thought, though.

[GaBuZoMeu]

DerTrueForce wrote:

The rest are about half-and-half correct and select-all. It seems that the select-all conditions occur when A8 and A14 are low.

Perhaps there is a short between A8 A14 (or they are heavily loaded perhaps by a capacitor?). They are neighbors at the address decoder (p15/p16).

[DerTrueForce]

It would have to be an internal short, I'd think, because I have to pull it out to test it, and it's been in three different wiring configurations(Ittiara, the manual tester, and the Arduino tester) and given similar results. Mind you, it's a good thought, and I'll poke it and the boards it sits in with a multimeter.

[GaBuZoMeu]

Well, I don't know what happened in the lifespan of that PLD. It could be broken, it could be programmed improper.

If you have a known good (unused) spare device you could program it and then verify it by using the Arduino setup or the programmer itself.
If this works properly then I would pull out the strange one, then use a multimeter to check for short circuits against each other (A8 - A14) and against VCC/GND as well. If there is no sign of an error then I would try the new one - perhaps having a finger on its back to sense whether it went hot.

If your programmer can use test vectors you may also test the strange one. And then reprogram it and test it again.

The last two buys I took (10 pieces and 50 pieces) there where each time one device that could not be programmed/verified correctly. Perhaps the one you are using is such one.

[floobydust]

Perhaps you need to define the full address range:

FIELD ADDRESS = [A15..0];

and specify "h" for hex addresses

RAM = ADDRESS:['h'0000..7FFF];

Below is what I used for a single glue chip on a recent project:

Code: Select all

Name     Glue3 ;
PartNo   01 ;
Date     10/31/2017 ;
Revision 01 ;
Designer KM ;
Company  Analogue Technologies ;
Assembly SBC2 ;
Location  ;
Device   g22v10 ;

/* *************** INPUT PINS *********************/
PIN 1    = CLK                       ; /*                                 */ 
PIN 2    = A15                       ; /*                                 */ 
PIN 3    = A14                       ; /*                                 */ 
PIN 4    = A13                       ; /*                                 */ 
PIN 5    = A12                       ; /*                                 */ 
PIN 6    = A11                       ; /*                                 */ 
PIN 7    = A10                       ; /*                                 */ 
PIN 8    = A9                        ; /*                                 */ 
PIN 9    = A8                        ; /*                                 */ 
PIN 10   = A7                        ; /*                                 */ 
PIN 11   = A6                        ; /*                                 */ 
PIN 13   = A5                        ; /*                                 */ 
PIN 23   = RW                        ; /*                                 */ 

/* *************** OUTPUT PINS *********************/
PIN 14   = !IO1                      ; /*                                 */ 
PIN 15   = !IO2                      ; /*                                 */ 
PIN 16   = !IO3                      ; /*                                 */ 
PIN 17   = !IO4                      ; /*                                 */ 
PIN 18   = !IO5                      ; /*                                 */ 
PIN 19   = !ROM                      ; /*                                 */ 
PIN 20   = !RAM                      ; /*                                 */ 
PIN 21   = !MWR                      ; /*                                 */ 
PIN 22   = !MRD                      ; /*                                 */ 

/** Declarations and Intermediate Variable Definitions  **/
FIELD ADDRESS = [A15..0];

RAM = ADDRESS:['h'0000..7FFF];
IO1 = ADDRESS:['h'FE00..FE1F];
IO2 = ADDRESS:['h'FE20..FE3F];
IO3 = ADDRESS:['h'FE40..FE5F];
IO4 = ADDRESS:['h'FE60..FE7F];
IO5 = ADDRESS:['h'FE80..FE9F];
ROM = ADDRESS:['h'8000..FDFF]
        # ADDRESS:['h'FEA0..FFFF];
/** Logic Equations **/
MWR = (CLK & !RW);
MRD = (CLK & RW);

[BigDumbDinosaur]

floobydust wrote:

Perhaps you need to define the full address range...

Same thing I'm thinking.

[GaBuZoMeu]

I downloaded the PLD source and create some testvectors. To my surprise it appears to work. But I would either use the full range or LIV2s suggestion just to be sure.

[DerTrueForce]

I do not believe that my programmer(TL866A) supports test vectors. And since I can't get CSIM to work(or even give me an error code), I can't really simulate it at all.
I have tested specifying hex and using [A15..0] instead of [A15..4]. I get the same results as when I do neither.
I put a continuity tester on A8 and A14. They do not appear to have continuity in either direction(even with the Arduino wires connected), and neither does the board.
The 16V8 does seem to get rather warmer than I'd have expected when it's in the board and running.

My problem with all this is that the conditions I've set up should be mutually exclusive. The equations for everything except the ROM select has A15 negated. The other selects shouldn't assert if A15 is high, even according to the expanded product terms in the doc file.
I think I'm going to try something simpler, with fewer product terms involved, and see if it still misbehaves.

[DerTrueForce]

I fiddled with the CUPL code for a while without success. I just now tried the 16V8 I'd used in the previous prototype, with the code I originally came up with, and the ranges are correct. It was a dodgy device all along.
Ittiara still doesn't work, for some reason, but the automated test says the PLD is correct.

I've marked the offending device.(I'm not quite prepared to toss it just yet; I only have two)

[GaBuZoMeu]

If your Arduino test verifies the GAL properly well then it should work in the new board. There may be still other reasons that prevent the board from working fine.
But you are using a CMOS CPU. So you can use a toggle switch (debounced please) instead of the oscillator and check all signals whether they appear or not. You may also use your Arduino to do that if you careful select which signals you need to verify. If you can verify that reading or writing at different addresses precisely generates the correct /CS-signals and /WE or /OE than you can step by step reduce the list of possible mistakes.