6502.org Forum Projects Code Documents Tools Forum
It is currently Fri Nov 22, 2024 1:06 am

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Hardware

All times are UTC




Post new topic Reply to topic  Page 5 of 14
  [ 209 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8 ... 14  Next
  Previous topic | Next topic 
Author Message
DerTrueForce
PostPosted: Thu Apr 26, 2018 9:42 am 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
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.
Top
 Profile  
Reply with quote  
BigEd
PostPosted: Thu Apr 26, 2018 10:59 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
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.
Top
 Profile  
Reply with quote  
DerTrueForce
PostPosted: Sat Apr 28, 2018 6:26 am 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
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...
Top
 Profile  
Reply with quote  
DerTrueForce
PostPosted: Sat Jun 02, 2018 8:34 am 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
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.


Attachments:
ranges.txt [3.68 KiB]
Downloaded 141 times
IttiaraDecoder4-0.PLD.txt [2.06 KiB]
Downloaded 143 times


Last edited by DerTrueForce on Sat Jun 02, 2018 10:11 am, edited 1 time in total.
Top
 Profile  
Reply with quote  
LIV2
PostPosted: Sat Jun 02, 2018 9:49 am 
Offline

Joined: Wed Feb 12, 2014 1:39 am
Posts: 173
Location: Sweden
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:
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];
Top
 Profile  
Reply with quote  
DerTrueForce
PostPosted: Sat Jun 02, 2018 10:22 am 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
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.
Top
 Profile  
Reply with quote  
GaBuZoMeu
PostPosted: Sat Jun 02, 2018 12:37 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
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).
Top
 Profile  
Reply with quote  
DerTrueForce
PostPosted: Sat Jun 02, 2018 1:41 pm 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
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.
Top
 Profile  
Reply with quote  
GaBuZoMeu
PostPosted: Sat Jun 02, 2018 3:41 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
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.
Top
 Profile  
Reply with quote  
floobydust
PostPosted: Sat Jun 02, 2018 5:38 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
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:
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);

_________________
Regards, KM
https://github.com/floobydust
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Sat Jun 02, 2018 9:53 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
floobydust wrote:
Perhaps you need to define the full address range...

Same thing I'm thinking.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
GaBuZoMeu
PostPosted: Sat Jun 02, 2018 10:40 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
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.
Top
 Profile  
Reply with quote  
DerTrueForce
PostPosted: Sun Jun 03, 2018 12:08 am 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
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.
Top
 Profile  
Reply with quote  
DerTrueForce
PostPosted: Sun Jun 03, 2018 10:36 am 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
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)
Top
 Profile  
Reply with quote  
GaBuZoMeu
PostPosted: Sun Jun 03, 2018 11:32 am 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
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.
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 5 of 14
  [ 209 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8 ... 14  Next

Board index » 6502.org Users Forum » Hardware

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 16 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
6502.org is an ongoing project by Mike Naberezny and contributors.