Issues with access ROM when using GAL

[Gurft]

I've been redoing my memory map and decided to use a GAL for decoding, wrote up the CUPL code, programmed the GAL, hooked up some DIPs and LEDs and it works as expected. (GAL20V8B)

What's odd is when I have the GAL in place, system won't start. Logic analyzer shows OE and CE on the ROM (28C65BP getting pulled low) and address lines show FFFC, FFFD, then some random addresses, loops up to FFFE and FFFF, the back to random addresses again. If I take the GAL out of the way and just pull OE and CE on the ROM (28C65BP) to GND it works fine, so I know the issue is with the GAL being in place. I hooked the GAL output to my scope and see that it's definitely pulling them below the TTL logic low (165mV)

I'm just at a loss as to what this could be, I tried switch out for another GAL, making sure all of the unused inputs/outputs were pulled to VCC, and nothing seem to be working. I'm 100% sure it's something silly but I've been diving into this too long and need another set of eyes. This is my first time working with GALs, so I'm hoping it's a PEBKAC situation.

Here's the code for the GAL (https://github.com/ktelep/zkt6502/tree/ ... oryDecoder)

Code: Select all

/* *************** INPUT PINS ********************* */
PIN [9..2] = [addr15..8];  /* Incoming high address lines */
PIN 10 = p2clock; /* Phase 2 Clock for RAM */

/* *************** OUTPUT PINS ********************* */
PIN 15    = !ROM_sel  ; /*    OE & CE tied together,       */ 
PIN 16    = !VIA1_sel ; /*                                 */ 
PIN 17    = !VIA2_sel ; /*                                 */ 
PIN 18    = !RAM_sel  ; /*    NAND with Phase2 clock?       */
PIN 19    = !ACIA1_sel; /*                                 */
PIN 20    = !ACIA2_sel;

/* Memory Map    */
/* 0x0000 - 0x0FFF  RAM   */
/* 0x1000 - 0x1FFF  RAM   */
/* 0x2000 - 0x2FFF  RAM   */
/* 0x3000 - 0x3FFF  RAM   */
/* 0x4000 - 0x4FFF  RAM   */
/* 0x5000 - 0x5FFF  RAM   */
/* 0x6000 - 0x6FFF  RAM   */
/* 0x7000 - 0x7FFF  RAM   */
/* 0x8000 - 0x8FFF  RES   */
/* 0x9000 - 0x9FFF  RES   */
/* 0xA000 - 0xAFFF  RES   */
/* 0xB000 - 0xB0FF  MEMORY CONTROL??   */
/* 0xB100 - 0xB1FF  VIA1   */
/* 0xB200 - 0xB2FF  VIA2   */
/* 0xB300 - 0xB3FF  ACIA1  */
/* 0xB400 - 0xB4FF  ACIA2  */
/* 0xC000 - 0xCFFF  RES    */
/* 0xD000 - 0xDFFF  RES    */
/* 0xE000 - 0xEFFF  ROM    */
/* 0xF000 - 0xFFFF  ROM    */


ROM_sel = addr15 & addr14 & addr13;   /* 0xE000 to 0xFFFF Only 8k today*/
RAM_sel = !addr15 & p2clock;          /* 0x0000 to 0x7FFF */             

VIA1_sel = addr15 & !addr14 & addr13 & addr12 & !addr11 & !addr10 & !addr9 & addr8;  /* 0xB100 to 0xB1FF */ 
VIA2_sel = addr15 & !addr14 & addr13 & addr12 & !addr11 & !addr10 & addr9 & !addr8;  /* 0xB200 to 0xB2FF */ 
ACIA1_sel = addr15 & !addr14 & addr13 & addr12 & !addr11 & !addr10 & addr9 & addr8;  /* 0xB300 to 0xB3FF */ 
ACIA2_sel = addr15 & !addr14 & addr13 & addr12 & !addr11 & addr10 & !addr9 & !addr8; /* 0xB400 to 0xB4FF */ 

[Dr Jefyll]

Quote:

system won't start

Does the GAL have any relevance to the CPU's /RST /NMI and /IRQ inputs? Please tell us about the system, starting with a schematic or at least a block diagram, and ideally including some photos as well. (Reminder: on this forum you're allowed to attach images with your posts.)

-- Jeff

[Gurft]

So, I figured it out! In my effort to take some photos of the analyzer and show the difference between when it works and doesn't I noticed something peculiar that I was ignoring, but shouldn't have been.


When it *worked* with CE and OE grounded, I saw this on the anaylzer:

Code: Select all

ADDR      DATA      ROMEN
FFFC        00          0
FFFD        00          0      <--- this should be E0
0000        A9          0      <--- But the code is at E0, not 00.... wait a minute....
0001        12          0
0002        4C          0
0003        00          0
0004        E0          0      
E000        A9          0      <--- The code is at E0 too!
E001        12          0
E002        4C          0
E003        00          0
E004        E0          0

This made me realize that with CE and OE pulled to ground, the ROM (E000-FFFF) was effectively mirrored every 2K across the entire address space. When the system was starting up, it was getting 0000 instead of E000, but since the ROM was mirrored into 0000-1FFF it worked fine, then got to the branch sending it to E000 and it went right there. I was measuring the address lines at the CPU, not at the ROM. I moved them to the ROM and discovered that A12 was always showing low. Quick continuity check and realized I had A12 tied to pin 21 and not 22 on the CPU <doh!> Problem solved!

I knew it was something silly, thanks for driving me to take the second look.

[Dr Jefyll]

Glad you've been successful!

As an aside, I'm tempted to remark that Logic Analyzers are a little too tempting -- a powerful tool, yes, but rather inefficient when all you have is a "head smack" type of problem. Anyway, live and learn.

BTW your schematic needs updating. I hardly think the machine would function with RDY pulled *low*. Cheers!

Jeff

[Sheep64]

Quote:

Location: Limerick, PA

A GAL programmer from Limerick
Asked why a config didn't tick.
None the wiser
With logic analyzer,
Cross wires were found from a pic.

[enso]

A circuit repairman from Boise,
Frustrated (his circuit was noisy...)
A probe stopped his fall
By impaling his ball, and
He lost his concern with courtoisie.