Riddle me this...

[barnacle]

I've obviously done something stupid in the hardware, but I'm going blind looking for it. The situation is that what I expected to be an almost copy and paste from a previous design simply doesn't work: it appears to access the eeprom and reboot and run rom-only code. I am unable to test the ram as yet, as I can't get the UART to run. The reason that the UART doesn't run is that it's never selected, along with a (not fitted) VIA and a (not fitted yet) CF interface. The reason for that is... well, I'll explain later.

First, some code shown to work on the similar board:

Code: Select all

init:					; test address decode
	bra init
	lda 0x8000
	lda 0x8400
	lda 0x8800
	lda 0x8c00
	lda 0x9000
	lda 0x9400
	lda 0x9800
	lda 0x9c00
	lda 0xa000
	lda 0xa400
	lda 0xa800
	lda 0xac00
	lda 0xb000
	lda 0xb400
	lda 0xb800
	lda 0xbc00
	bra init

and a couple of pics (apologies for the colour: screen grabs), first the decoding:

Screenshot from 2025-12-03 10-56-55.png (10.96 KiB) Viewed 1035 times

and the processor:

The processor, in the absence of the VIA, also has a pull-up on ~IRQ (pin 4). Not shown are the EEPROM which has its ~OE driven by the ~RD signal and ~CS by ~EEPROM. The clock is from an oscillator module at 1.8432MHz; the reset is handled by an APX823 with its watchdog input line left floating (per the datasheet) to avoid timeout resets.

So on the processor, ~IRQ, ~NMI, ~SO, BE, and RDY are all pulled high; ~RST is held high by the APX chip.

So far, so good. The UART, RAM, VIA, and CF parts are not shown; they're currently not fitted. So the code is (should be) running entirely in the rom and trying to read each 1k boundary between $8000 and $C000. Which should drive the select pins in sequence on that '138, but those pins remain steadfastly high. No select.

The select should occur on addresses %1000 00xx xxxx xxxx to %1001 11xx xxxx xxxx; the remaining reads don't talk to anything and were left in for testing. However, they don't, and as far as I can see the reason is that of the address lines, A9-10-11-12-13-14-15 (yes, seven of them) are all identical and are all an inversion of the ~EEPROM signal.

One curious point: running on the not-working board, R~/W from the processor goes low synchronously with ~EEPROM but not the same signal. On a read-only program. (Yellow is ~EEPROM; blue is R/~W and had no earth attached). It doesn't do that on the working system; as expected, it remains high.

Obviously with that, there is never an occasion when E2 on the '138 is high and ~E1 and ~E0 are low, hence no output. I have changed (and proved in the working board) EEPROM, processor, '138, '00, and even the damn circuit board to no effect.

I am very very confused at this point. It looks as if there is something at issue with the board, but it's nothing I can see. No errors from the schematic tester; no errors from the pcb test except relating to the prototype area I added.

No doubt this is something very stupid and obvious, but a fresh couple of hundred pairs of eyes would be very much appreciated!

Thank you!

Neil

[sburrow]

This sort of thing happens to me all the time! I am completely dumb-founded. Nothing makes sense. I have checked and rechecked everything logically, and logically it should be fine. So what's wrong?

Here are things that have happened in my past:

0) Power, Reset, and Clock. These are the first three things to check, but you already new that.

1) Soldering issues. They *look* fine, but for some reason, they are not. Very frustrating.

2) PCB errors. I have actually had it where the PCB should have connected these places together, but it just didn't for some reason, so I had to bodge it. Very frustrating.

3) Breadboards... If you are (by chance) using a breadboard, that's a major concern. I have *never* *ever* gotten breadboards to work properly for me. Very frustrating!

4) Soldering issues. Are you using SMT by chance? Or that prototype area you mentioned, are all the bodges looking ok? Even if they are, they might not be!

5) EEPROM programming right? I know it probably self checks, but have you hexdump'd the binary just to make sure? Do you see reset vectors on the addresses and data buses upon change in VP pin? Check with the scope.

6) Did I mention soldering issues???

When something like this happens I call it "loopy-land" and it takes me hours, days, to figure out, oh yeah, I have been assuming something. Assuming the soldering was ok, for example.

I looked at your schematics and all that looks fine. So yeah, I suspect something way way out there. Literally anything you are assuming, toss it out the window and start thinking it over fresh.

Thanks for sharing Hopefully this list is at least funny to read, actually helpful second.

Chad

[daniMolina]

I am seeing something so obvious, that nobody else is pointing out, that I am completely sure i am 100% wrong but....

Doesn't that first instruction. BRA init. mean that all the LDA are never executed? You don't mention where the code starts but I am assuming, it starts at init.

You mention your code works on a different design, so again, I have to be wrong... but just in case...

Code: Select all

init:               ; test address decode
   bra init
   lda 0x8000
   lda 0x8400
   lda 0x8800
   lda 0x8c00
   lda 0x9000
   lda 0x9400
   lda 0x9800
   lda 0x9c00
   lda 0xa000
   lda 0xa400
   lda 0xa800
   lda 0xac00
   lda 0xb000
   lda 0xb400
   lda 0xb800
   lda 0xbc00
   bra init

[gfoot]

Agreed about "bra init", good spot, sometimes these things are easy to overlook! It wouldn't explain the RWB/EEPROM oscilloscope trace but maybe that was a probing error? JSR is the only instruction I can think of that executes two write cycles (but not three) in a row, but JSR requires more read cycles in between the writes.

I would recommend hoglet's decoder for these sorts of situations in general as it can very quickly point to the problem, both giving you a trace of what is actually going on, and telling you when that deviates from what it would expect the system to do.

[barnacle]

Thanks guys... bra init was a temporary test I added to the list and subsequently removed; it is running the full loop (on the working system, anyway...

sburrow wrote:

This sort of thing happens to me all the time! I am completely dumb-founded. Nothing makes sense. I have checked and rechecked everything logically, and logically it should be fine. So what's wrong?

Here are things that have happened in my past:

0) Power, Reset, and Clock. These are the first three things to check, but you already new that.

Yup, all three there, zero measurable ohms to the various signals.

Quote:

1) Soldering issues. They *look* fine, but for some reason, they are not. Very frustrating.

Possible, but (a) repeatedly checked, and (b) on two PCBs?

Quote:

2) PCB errors. I have actually had it where the PCB should have connected these places together, but it just didn't for some reason, so I had to bodge it. Very frustrating.

This is my biggest suspicion, particularly as it's happening on two. But I can't find anything.

Quote:

3) Breadboards... If you are (by chance) using a breadboard, that's a major concern. I have *never* *ever* gotten breadboards to work properly for me. Very frustrating!

Breadboards are an abomination unto Nuggan! They are to be shunned with extreme prejudice!

Quote:

4) Soldering issues. Are you using SMT by chance? Or that prototype area you mentioned, are all the bodges looking ok? Even if they are, they might not be!

No SMT in the affected area apart from the oscillator and the reset manager; both working apparently (on both dodgy boards); the CF card is SM and a right pain to solder cleanly, but the only direct connection to the processor is on A0-A2, and they are not shorted to each other or anything inconvenient (and the CF card is not present).

Quote:

5) EEPROM programming right? I know it probably self checks, but have you hexdump'd the binary just to make sure? Do you see reset vectors on the addresses and data buses upon change in VP pin? Check with the scope.

Probably right. The programmer is a homebrew and I need to improve the testing but it does seem to work most of the time

Quote:

6) Did I mention soldering issues???

Well, after fifty years' practice, I would hope not but again, it's on two boards.

Quote:

Thanks for sharing Hopefully this list is at least funny to read, actually helpful second.
Chad

Neil

[barnacle]

Again, ~EEPROM in blue.
Vector pull, which is definitely surprising:

And Sync:

Sync looks right, I think. Seven clock cycles between instructions, which doesn't look right; should be four for an absolute address, no?

Neil

[gfoot]

barnacle wrote:

Again, ~EEPROM in blue.
Vector pull, which is definitely surprising:
...
And Sync:
...
Sync looks right, I think. Seven clock cycles between instructions, which doesn't look right; should be four for an absolute address, no?

Neil

Ah I see, I misread the horizontal scale on the scope. In that case it is consistent with your previous capture with ~EEPROM and R~W and looks correct for a continual sequence of interrupts being taken, probably BRK instructions but potentially continual NMIs could also cause this I suppose. Either way you'd expect two cycles fetching an instruction (apparently, from RAM), then three writing to the stack, then two fetching the vector. You'd also get a SYNC pulse on the instruction fetch.

You really need to see what's on the address and data buses, especially what instruction is being presented to it, which vector is it loading from, and what address is it actually then requesting on the next cycle - as it looks like that is in fact coming from RAM. If you don't have a proper logic analyser, then since at least the error is occuring quickly after reset (hopefully straight away!) it could at least be worth rigging up a manually-stepped clock so that you can step single cycles and then probe the pin levels by hand. I think it will reveal a lot and be worth the effort of any desoldering that's necessary to set this up.

If I had to put money on a long shot at this stage, I'd say either D6 or D7 is not making its way from the EEPROM to the MPU - but that is a "WAG" for sure!

[plasmo]

Ah, the joy of bringing up a new board. Sometimes it was so weird, I wondered whether basic laws of physics were altered! Building two boards is the logical diagnostic step, then visual inspection, then the simplest tests with fewest components. Don’t add, subtract, simplify instead. Check the heart beat signals (reset, clock, controls), check for contentions (all signals should swing high or low, no in-between). Good luck!
Bill

[barnacle]

Interesting: this is sync (yellow) against D3; the other signals are vaguely similar but all show zero during the sync. Which is likely where it's getting a BRK from.

And here's the board; can't get much emptier than that...

But I may have just had a brainwave... wait one.

Neil

[barnacle]

D'oh.

Carefully generated a ~RD signal for the 8080-style CF interface. Fed it to R/~W on the ram and eeprom.

cut cut edit edit solder solder... now at least it's executing, though with not quite the result I expected. Still investigating.

Thanks all.

Neil

[barnacle]

OK, I misspoke on the last post

Here's what appears to work (at least as far as (a) the walking pins on the '138 and (b) reading a CF card as far as getting the cf_info data block):

~RD is generated by R/~W NAND PH2I; and fed to the RAM and EEPROM ~OE inputs, and the ~IORD for the CF.
~WR is generated by ~(R/~W) NAND PH2I; it feeds ~WE on the RAM and ~IOWR on the CF

Which I think is where I started... but what I missed was remembering that I only wanted the bottom half of the EEPROM to be active. I attached A14 to its address bus, instead of tying that to ground as I should have done... (it's still a d'oh moment, of course.) A bit of a pain to ground it, since the A14 trace to the ram went through it.

Here's the final (well, current!) circuit diagram, incorporating corrections.

6502_cf_2_a.pdf

(586.3 KiB) Downloaded 37 times

Front view:

My beautiful bodge wires

Neil

[BigDumbDinosaur]

barnacle wrote:

OK, I misspoke on the last post...Which I think is where I started... but what I missed was remembering that I only wanted the bottom half of the EEPROM to be active. I attached A14 to its address bus, instead of tying that to ground as I should have done... (it's still a d'oh moment, of course.) A bit of a pain to ground it, since the A14 trace to the ram went through it.

I sorta had a similar problem with POC V1.2, which seemed to be DOA the first time I powered it.  However, it wasn’t an actual design error.  Yet it looked like a hardware problem and almost had me reaching for the flush cutters, soldering iron and bodge wire.

All the address lines on the ROM were correctly hooked up and, using the clock single-stepper, testing with the logic probe proved that the ROM was being selected at reset, and its /OE was being asserted during a read cycle.  Watching VDA and VPA with the probe while manually cycling Ø2 showed that the MPU was doing something, which further confused the issue.  Adding insult to injury, when I let the Ø2 clock run free, other hardware would be randomly selected—the machine appeared to be possessed. 

The mistake was stupidly simple, a “forehead-slapper,” as Garth described it.  I had reorganized the memory map when I designed V1.2, moving the I/O block from $00D000 to $00C000 and the start of ROM from $00E000 to $00D000.  The object of doing so was to increase ROM space from 8KB to 12KB.  With these changes and due to the way in which I implemented the decoding, $00D000 on the address bus would translate to $1000 in the ROM.  However, while burning the firmware into the ROM, I forgot about that and instead used $0000 as the starting address, as I had done a gazillion times with the ROM in POC V1.1.

The MPU reset vector $00FFFC-$00FFFD translates to $3FFC-$3FFD in the ROM, which was above the address range that had been programmed.  So the MPU was fetching $FF and $FF for the address of the reset code and then randomly executing garbage.    That explained the symptoms—unlike the 65C02, all 256 opcodes are valid instructions in the 65C816, so the bogus reset vector did lead to executable code, just not the right executable code. 

When I reprogrammed the ROM so the firmware started at $1000, V1.2 booted.    I was muttering “Stupid, stupid!” under my breath the rest of the evening and my wife was wondering if she should call for medical assistance. 

[sburrow]

barnacle wrote:

My beautiful bodge wires

I think they are beautiful So, maybe I didn't get it subtly enough, does it work now?

BigDumbDinosaur wrote:

When I reprogrammed the ROM so the firmware started at $1000, V1.2 booted.

Been there done that! Good story and perception, BDD. Something we should all remember.

Chad

[barnacle]

Yep, it's working now. Although, come to think of it, I haven't tried incoming data, but I don't see why not. It _can_ see the internal registers for the IDE interface, and the CF card is responding both at the system and stored data level (memo to brain: the commands are different even though the access is the same).

The IDE bus is isolated via a '245 because it's potentially a capacitative load, and for the record, the series resistors in the data lines (which may or may not be necessary; they're not there at all on the levitating board) are 220 ohms, carefully calculated by not actually having any of the 100 ohms resistors I saw suggested. The board is working at 5v from a USB port, pulling mostly about 75mA (some of that is the FTDI serial-usb adaptor); I don't know how much the CF card takes in continuous access operation. Clock speed is 1.8432 MHz and sometime I'll get around to testing at double that speed, and perhaps at 3v3 - the board has an option to use an external voltage input with an LDO linear regulator.

Neil

[sburrow]

Glad it's working I really like your 62256 dual footprint, very elegant and also resourceful! Any particular reason why it's running specifically at 1.8432 MHz? What are some of the project goals with this particular device?

Chad