Overzealous Kickstart ROM - address decoding?

[robinsonb5]

As some of you might already know, I now have one of Majsta's prototype Vampire 500 FPGA accelerators to play with. (Yay! Something else to distract me from the things I *should* be doing! )

So I'm playing around with this thing on an old Revision 5 A500 motherboard with Kickstart 1.3. I've verified that reads and writes to and from Chip RAM, the Custom Chip registers and CIA registers are all working correctly - but I have a problem with the Kickstart ROM.

The ROM itself seems to be readable just fine at $fc0000 - the problem is it's showing up at $f00000 as well, but only under specific circumstances.

Using the dissasembly on this page as a reference: http://wandel.ca/homepage/execdis/exec_disassembly.txt (a different Kickstart version, but the relevant code is identical)
The ROM starts executing perfectly at $fc00d2 until the cmp at $fc00f4. It then reads from f00000, sees $1111, and thus jumps to $f00002, where it finds instructions to jump to $fc00d2 - thus creating an infinite loop!

What's weird is that isolated reads from the region at $f00000 return the junk data you'd expect for an undecoded region, but if a valid ROM address has been on the bus, the ROM seems to be shadowed at $f00000 provided there are no accesses to other regions in between the reads from $fcxxxx and $f0xxxx.

The board works fine with its original CPU.

Does anyone have any idea what could cause this?
(Is Gary not deasserting the ROMEN signal perhaps? But why would that happen?)

[FrenchShark]

Hello,
256 KB Kickstart ROM must be shadowed at address F80000 not F00000.
To me, it looks like a wrong address decoding is done by Gary.
IIRC, Gary is responsible of terminating bus accesses on most of the areas with the DTACK# signal.
Does Majsta uses 74LV latches in his design ? Maybe some address bits "get stuck" in the latches and Gary still "sees" a valid Kickstart ROM access.
Regards,

Frederic

[robinsonb5]

Originally Posted by FrenchShark

Hello,
256 KB Kickstart ROM must be shadowed at address F80000 not F00000.

Yes, that's what I thought, and I've verified that the ROM appears at FCxxxx, F8xxxx, F4xxxx and F0xxxx - it appearing at the latter two being incorrect.

To me, it looks like a wrong address decoding is done by Gary.

Yes indeed.

Does Majsta uses 74LV latches in his design?

No, 74ALVC transceivers - so there shouldn't be any danger of stale data getting latched. I wondered if the problem was a short between signals for A20 and A19 - but it seems it's not that simple.

Oh well - the bug-hunting continues

[robinsonb5]

And... it's alive!


The problem turned out to be a simple bad solder joint on one of the pins of the DIL socket! Ironic, given how long I spent scrutinizing the surface-mount components looking for the problem!

Mental note: always check the obvious first!