Struggling with EEPROM addressing ...

[Michael]

Built the backplane, 6502 and IO boards. Put Greg's 'hello world' on an EEPROM and powered up. Didn't go as well as I had hoped.

So, I went back to my usual process for bringing up a new 6502 board which is to slow the clock WAY down and use some LEDs.
Started with an 8K EEPROM (28C64) filled with NOPs and watched A0..A4 count up nicely in binary.

Changed to an actual program with a loop of 256 NOPs (and the rest of the EEPROM filled with 0x00) : no success. So, it seems like I don't understand how the addressing works. Clearly the CS logic for the EEPROM is working (it wouldn't do such a nice binary count on the address lines if it wasn't reading 0xEAs from the EEPROM).

I made a (private) youtube video showing how I did this testing:
https://www.youtube.com/watch?v=Q99VXCovgvk

After I made the video I noticed that the start of my 8K EEPROM (28C64) is 0xE000 :

So, I did some more testing:
- moving the program in the EEPROM from 0xE000 to 0xF000
- switching IO to 0xD000
- trying again with IO at 0xE000
- trying the same with 32K EEPROM (28C256)
Same random results on the address lines : no nice binary count on A0..A4 as I expect to see.

Here's my NOP program for reference:

Code: Select all

F000  D8        CLD                 
F001  A2 FF     LDX #$FF            
F003  9A        TXS                 
F004  EA        NOP                 
F005  EA        NOP                 
F006  EA        NOP                 
F007  EA        NOP                 
F008  EA        NOP                 
F009  EA        NOP                 
F00A  EA        NOP                 
F00B  EA        NOP                 
F00C  EA        NOP                 
F00D  EA        NOP                 
F00E  EA        NOP                 

< trimmed >


F039  EA        NOP                 
F03A  EA        NOP                 
F03B  EA        NOP                 
F03C  EA        NOP                 
F03D  EA        NOP                 
F03E  EA        NOP                 
F03F  EA        NOP                 
F040  EA        NOP                 
F041  EA        NOP                 
F042  EA        NOP                 
F043  EA        NOP                 
F044  80 BE     BRA $F004 (-66)     
F046  EA        NOP                 
F047  DB        STP                 

F048  40        RTI                 

F049  40        RTI                 

0xFFFA 0xF048 // NMI vector
0xFFFC 0xF000 // Reset vector
0xFFFE 0xF049 // IRQ vector

So, if the entire EEPROM is filled with 0xEA, it steps through nicely. As soon as I rely on jumping from the RESET vector to the start of my program, it fails. Clearly I just don't understand the memory map in the default 56K+8K CPLD

What am I missing?

PS - if ever there was reason to have some 8-bit_LED_Things ...

[Editor]

Hi Michael,

Sorry to hear you're not up and running.

I watched your video, but no sudden inspirational thought jumped out at me.
Note: As I'm not yet familiar with your Hopper environment, that part of the video was less understandable.

But, back to basics, with the simple ROM code you have (or even Hello world), we are not even accessing RAM. Pretty much as simple as just addressing, reading and executing the ROM code.

This kinda makes me think of 2 things first, after watching your video:

1. I've only ever used an AT28C256 EEPROM. Now, understanding the 28C64 is pin compatible (with the 2 high address lines as NC pins), it should of course be fine. But, I just mention this as I have no AT28C64's in my stock, to allow fully replicating your setup.
According to the AT28C64 datasheet, Pin 1 is an output, but only Open Drain and only asserted during a write operation (programming), so this shouldn't conflict with the A14 address line.
Again, I only pass this observation for completeness, as I don't have an AT28C64 to try, and I'm always careful when a datasheet specifies a pin as No-Connect (NC). I take it literally! Although, I do note that MicroChip (to their credit), does differentiate a "Don't Connect" (DC) pin!

2. I'm sure you have done this (so I do apologise / no offense intended), but I'll add to the list anyway... Have you thoroughly inspected (and re-inspected), the assembled circuit board for any solder-bridges / shorts / bad connections, in particular related to the address lines?
With the ICs removed you could also try some basic connectivity / no-short tests with your multimeter etc.

Other than that..
a. Obviously the CPU is working (as evident by your LED activity).
b. The RAM isn't being used. So, (in theory), you could remove the SRAM from the board, just to take it out of the equation (e.g. In case it is faulty and shorting a bus line etc.)
c. The PLD is pre-tested in my board just before shipping, so it should be okay! But, if you have a suitable programmer we could try re-programming it, just to satisfy that it is working okay. Even better, if you have WinCUPL installed, you could load the PLD source and re-compile / re-program.

Not sure what else to add at this stage. Hopefully, the above thoughts may trigger some ideas?

PS. Good catch on the missing '#' typo on the first LDX! But, as you pointed out, it makes no difference as we're not using the Stack.
But, I should have noticed this simple typo! I'm not using RetroAssembler any more, as it was quite basic, and the default Ctrl-Shift-B to build doesn't even give you a listing file to easily check the output.

[Michael]

Thanks for the thoughtful response.

> AT28C64:

I figured as much so I've been mostly testing with an AT28C256. (my prior experience with the AT28C64 is that I can just drop it into a circuit intended for a AT28C256 and it simply 'replicates' the content x4 across the address range). But still, one less variable is good so I'm sticking to the AT28C256 till it works.

> Inspection:

No such thing as stupid questions : often they lead us down a path we may not have thought of yet .. no worries.

Since the address lines make it through to my breadboard (I'm now watching 12 of the 16) I think they are good. I also slowed the clock down to as low as 1Hz to watch what is going on. If ever there way a good use for your LED things ...

I've seen it light up the MSB as 0xEA at the start when the entire ROM is 0xEA (implying at least some of the data lines are good).
I reflowed all the solder on the 4 chips, the resistor packs and the DIP-8 switches. I visually inspected under a magnifier looking for missing solder and bridges. Nada.
I also inspected:
- all the sockets for bent over pins (not through the hole)
- all the chips for bent over pins (not in the socket)

I stickered the CPU and ROM with Grant Searle's stickers (had to use a lookalike for the ROM). Then checked each address and each data line for:
- connectivity between CPU and ROM
- shorts against ANY other pin on the CPU
using my meter in audio continuity mode.

I moved both boards (CPU and breadboard) to different slots in the backplane.

Spot anything obvious? (note: I inserted the DIP switches upside down (1..8 is L..R and "on" is up) : I'm assuming that configuration is 0xD000 (anywhere not in the top 8K for now).

https://imgbly.com/ib/jFp0Z7lRPE

My current working theory is that it isn't jumping to the correct address for the restart vector : the initial MSB is 0xEA (which it obviously grabbed from some 'random' / wrong location) according to the LEDs whereas the program should have started at 0xE0xx (with 8K x 0xEA except for the loop jump and the vectors at the top). In other words, probably an address line problem.

PS - I made a video about assembly (not posted on my channel yet) where I describe how awesome your kits are : everything labeled and well packed, etc.

Notes/Suggestions for electronics gumbies (like me):

PCB:
- beautiful boards : consistent footprints and labels, easy to solder for older eyes and hands
- most important : the 'green' / cheap ZIF sockets have bigger pins that you allot for the EEPROM (can't be inserted) - if there is a revision, use footprint with bigger holes for the EEPROM

Silkscreen:
- I prefer to clearly mark the negative side for electrolytic caps (since that is the side marked on the cap) - holes were a bit tight too
- I know there is a square corner but probably better to put the label on the 'up' side of the can oscillators (same orientation as text on cans)

Assembly video:
- in future videos, call attention to components with orientation snafu potential (resistor arrays, my idiotic inversion of the DIP switches)
- jumpers : you never mention the ROM WE jumper : putting one on the RD side may seem obvious but less ambiguity is better
- removing the fume extractor noise : do you use OBS Studio? I was advised to add the RNNoise filter to remove my very loud keyboard noise - may work for fume extractor too

USB power:
- I can confirm that the USB breakout without the 5.1k resistors does not activate power from a pure USB-C supply (only works if you plug into a USB-A on the other end) (I made a video on this issue recently https://www.youtube.com/watch?v=X-WS2iYegAA)

That's all the feedback I can remember for now.

[Michael]

Fixed one bad assumption : moved the reset from my clock generator MCU from the jumper header (which wasn't connected to anything with the reset chip removed) to C31 : now it reliably does the wrong thing ..

[Editor]

I've seen it light up the MSB as 0xEA at the start when the entire ROM is 0xEA (implying at least some of the data lines are good).

When you say "entire ROM", do you mean the reset vector as well? Or, is this observation even with the $F000 (or $E000) vector still in-place?

My current working theory is that it isn't jumping to the correct address for the restart vector : the initial MSB is 0xEA (which it obviously grabbed from some 'random' / wrong location) according to the LEDs whereas the program should have started at 0xE0xx (with 8K x 0xEA except for the loop jump and the vectors at the top). In other words, probably an address line problem.

So, assuming a reset vector of $E000, you are saying that you are visibly seeing an $EA (with your very slow clock on a CMOS WDC CPU), as the first read byte following the reset initiation cycles?

If so, if you change the reset vector to something like $0000, do you see the exact same result?
i.e. If so, this would seem to further confirm the reset vector is not being loaded from the ROM data at $FFFC/FD.

With your slow clock, is it then possible to try and narrow down the likely address it is loading the PC from?
e.g. By filling the ROM with an incrementing number?

Notes/Suggestions for electronics gumbies (like me):

Suggestions noted, and very welcome. Being so close to the project, makes it harder to see these potentially helpful amendments.

I'm just starting the layout of a new PCB, so I'll re-read-through your suggestions again tomorrow, and see what improvements I can implement on a new board (before revisiting the existing PCBs).

PS: Yes, I find the "8-bit LED Thing" very handy and quick to utilise, when I'm prototyping or debugging hardware!

[Michael]

I'm just starting the layout of a new PCB, so I'll re-read-through your suggestions again tomorrow, and see what improvements I can implement on a new board (before revisiting the existing PCBs).

One more : wider footprints for the resistors.
https://imgbly.com/ib/xZOhagiXWT

Yes, I find the "8-bit LED Thing" very handy and quick to utilise, when I'm prototyping or debugging hardware!

Dave got a case of FOMO when I shared my debugging issues.
Luckily for him, you had the LED Things in stock today .. I'll have to queue up another order...

[Michael]

Or, is this observation even with the $F000 (or $E000) vector still in-place?

Yes. Proper program generated by my Hopper 6502 Assembler.

With your slow clock, is it then possible to try and narrow down the likely address it is loading the PC from?
e.g. By filling the ROM with an incrementing number?

Or .. just add more LEDs ... I think I'll solder up a batch of smaller LEDs (easier to fit on the breadboard) with 470ohm resistors.

I am making progress : I went out and picked up some isopropyl alcohol and scrubbed all the boards (now someone needs a new toothbrush).
There must have been some cruft because now it appears to be working better (still doesn't start reliably every time but that could just be my test rig).

This is the current test program that seems to be working (currently running at a blazing clock speed of 5Hz):

Code: Select all

program NOPs
{
    #define CPU_65C02S
    #define ROM_4K
    
    NMI()
    {
    }
    IRQ()
    {
    }
    Hopper()
    {
        loop {
            NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP
            NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP
        } // loop
    }
}

And the listing:

Code: Select all

// /Source/Testing/Minimal/nops2.asm:13
// ####  NOPs.Hopper()  ####                                                    0x0000

0xF000  0xD8            CLD                     
0xF001  0xA2 0xFF       LDX # 0xFF              
0xF003  0x9A            TXS                     
0xF004  0xEA            NOP                     
0xF005  0xEA            NOP                     
0xF006  0xEA            NOP                     
0xF007  0xEA            NOP                     
0xF008  0xEA            NOP                     
0xF009  0xEA            NOP                     
0xF00A  0xEA            NOP                     
0xF00B  0xEA            NOP                     
0xF00C  0xEA            NOP                     
0xF00D  0xEA            NOP                     
0xF037  0xEA            NOP                     


< snipped .... >


0xF038  0xEA            NOP                     
0xF039  0xEA            NOP                     
0xF03A  0xEA            NOP                     
0xF03B  0xEA            NOP                     
0xF03C  0xEA            NOP                     
0xF03D  0xEA            NOP                     
0xF03E  0xEA            NOP                     
0xF03F  0xEA            NOP                     
0xF040  0xEA            NOP                     
0xF041  0xEA            NOP                     
0xF042  0xEA            NOP                     
0xF043  0xEA            NOP                     
0xF044  0x80 0xBE       BRA 0xF004 (-66)        // }    loop                         nops2.asm:17
0xF046  0xEA            NOP                     
0xF047  0xDB            STP                     // }                                 nops2.asm:18

// /Source/Testing/Minimal/nops2.asm:7
// ####  NOPs.NMI()  ####                                                       0x0001

0xF048  0x40            RTI                     // }                                 nops2.asm:8

// /Source/Testing/Minimal/nops2.asm:10
// ####  NOPs.IRQ()  ####                                                       0x0002

0xF049  0x40            RTI                     // }                                 nops2.asm:11

0xFFFA 0xF048 // NMI vector
0xFFFC 0xF000 // Reset vector
0xFFFE 0xF049 // IRQ vector

[Editor]

I am making progress : I went out and picked up some isopropyl alcohol and scrubbed all the boards (now someone needs a new toothbrush).
There must have been some cruft because now it appears to be working better (still doesn't start reliably every time but that could just be my test rig).

That is sounding like you are making progress!

I'm just curious if it is possible that you used some old (really old) solder?

I just ask as I had some really old solder spools that I found in storage, and I used them a couple of years ago, and I then had unexplained board failures that (in the end), seemed to be attributable to a level of conductivity in the flux residue?

Sounds crazy (I'm not a chemist, so don't really know), but after cleaning the boards with IPA and an ultrasonic bath, the boards worked okay.
I obviously learnt a lesson and quickly disposed of the old solder spools. New solder, and never had that problem again.

[Editor]

One more : wider footprints for the resistors.

Noted. But perhaps also / instead?, I should specify the wattage of the resistors. My resistors are a lot smaller (hence the PCB footprint size).
Larger 1/2w, or even 1/4w resistors, are not really required here. Perhaps mine are 1/8w? I'll need to look into further.

[Michael]

Noted. But perhaps also / instead?, I should specify the wattage of the resistors. My resistors are a lot smaller (hence the PCB footprint size).
Larger 1/2w, or even 1/4w resistors, are not really required here. Perhaps mine are 1/8w? I'll need to look into further.

I believe mine are 1/4W.