6502.org

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: and a couple of pics (apologies for the colour: screen grabs), first the decoding: 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

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

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...

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.

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...
Yup, all three there, zero measurable ohms to the various signals. Possible, but (a) repeatedly checked, and (b) on two PCBs?
This is my biggest suspicion, particularly as it's happening on two. But I can't find anything.
Breadboards are an abomination unto Nuggan! They are to be shunned with extreme prejudice!
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).
Probably right. The programmer is a homebrew and I need to improve the testing but it does seem to work most of the time
Well, after fifty years' practice, I would hope not but again, it's on two boards.
Neil

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!

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

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

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

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. Front view: My beautiful bodge wires Neil

I think they are beautiful So, maybe I didn't get it subtly enough, does it work now?
Been there done that! Good story and perception, BDD. Something we should all remember.

Chad

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

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