Good info, but you don't happen to have pics do you? Its electronics porno.
Sure, I can take a bunch of pics. Since it's still apart.
Does the card have a seperate interface chip, or is that part of a custom ROM chip?
I ask because I thought DRAM required refreshing, and was wondering how that gets accomplished without a chip to control it. I'm not sure exactly how one would do the refreshes with just a ROM chip...<confused>
All arcade card extended memory can only be accessed via the arcade card 4 separate ports (
http://pastebin.com/raw.php?i=2FxpddLS <- a doc I was working on for how the arcade card works). So all refresh logic can be handled by the AC interface chip. The ROM chip is just the bios/code. It's separate from the AC IC.
IIRC, the rom is mirrored too up to the 512k(byte) lower range, which is why the AC special port mapped regs start at banks $40-43 (especially the 'Duo versions since they don't assert hucard present pin and only map in, into open bus areas). The DRAM is 70ns, but I'm not exactly sure what the refresh time is. Since it's port base and auto incremented (or decremented), all access could easily be buffered (read ahead). You figured a typical read is 5 cpu cycles (LDA <port>) or ~756ns, if did nothing but that (a series of LDA's).
Txx instructions are 6 cycels normally per byte from an address, and 7 cycles if you the destination is the $000-$7ff range of the hardware bank $ff (regardless of where it's mapped). So that's 980ns per read of the port via Txx to vram, or vram to AC memory - via using the bank $40-43. As you probably know, there's no /RDY on the card port. Only the back plane (on core systems) for CD addon and VDC use it (it has a single word fifo, SATB dma period will assert /RDY for up to 2.5-3 scanlines depending on the dot clock mode, when that fifo's filled and additional writes).
That makes it a huge pain to interface with DRAM via cart port (I've heard early models of CD addons with the base 64k use DRAM. Since /RDY is there it's not a problem. From my experience, on the 6280, I think there's an area in the cpu logical address range that somewhere in the $0000-$1fff range that either messes with timing or doesn't let /RDY effect it. I think it's more of timing. Try mapping any of the original 64k of CDRAM $80-$87 banks into MPR0. It'll get corrupt overtime. But SCD additional 192k SRAM or system SRAM has no problems working there). The arcade card method is best. I can only assume the refresh time for the DRAM is faster than 980ns since quite a few games use Txx instructions to and from AC ports. Whether it's fast enough to execute sequential code out of, is totally another thing and untested (like embedded graphics as ST1/ST2 opcodes, using banks $40-43 and an RTS as the end of the embedded string).