Sounds like a very educational project.
Typically, DRAM manufacturers specify that each row must have its storage cell capacitors refreshed every 64 ms or less.
My understanding is that you can use any one of the following 4 ways to keep the DRAM refreshed:
(a) My understanding is that all SDRAM has an internal on-chip timer that automatically refreshes the SDRAM when the SDRAM is placed in self-refresh mode and the clock to the SRDRAM is stopped.
My understanding is that most simple systems don't bother with self-refresh mode, and instead use one of the other methods of refreshing DRAM:
(b) Some systems have special refresh hardware that periodically pauses the CPU, performs a refresh, then resumes the CPU.
(c) A few systems have a special "refresh interrupt" -- a timer signal periodically triggers a hardware interrupt, and the software in the interrupt handler does a refresh, and returns.
(Some systems interrupt once every 64 ms,
and the interrupt handler reads N bytes -- one byte from every DRAM row -- refreshing all the DRAM in one whack, then returns.
Other systems interrupt once every 64/N ms,
increment a row counter and read one byte from that DRAM row, then return).
The "refresh interrupt" approach requires the least amount of hardware.
Alas, a "refresh interrupt" has the drawback that minor bugs in the refresh interrupt software, or bugs in any other software that delays the refresh interrupt too long, cause weird difficult-to-reproduce problems elsewhere when memory becomes corrupted.
(d) Many early computer systems had special DMA video hardware that pauses the CPU, reads video data from the DRAM, and sends it to the video hardware.
Many of them are set up such that the process of reading out all the video data, as a side effect, also reads at least 1 byte from every row of DRAM, indirectly refreshing all DRAM.
p.s.:
Are you actually using a (effectively) 32-bit 68000, like the original Macintosh and Palm Pilot?
If so, you may find it useful to check out the Minimig project, which uses a 68000 (and lots of SRAM), and the FPGA "soft cores" that execute the 68000 instruction set.
Or are you actually using an 8-bit Motorola 6800?
If so, I highly recommend you check out the N8VEM Home Brew Computer Project.
You will need to create what is called a mezzanine board. Your big problem is that the 5565 only needs ~ 25 signal pins (13 address, 8 data, 2 enables, 1 R/W, and 1 output enable), while an 8k x 8 dual port RAM needs at least twice as many. This means that your DPRAM will have a much larger (in terms of pins) package than the 5565.
A good starting point for DPRAMs is the IDT 7005, which can be found on eBay. This will come in various packages with 64 - 68 pins.
First, your game board will need to be modified to allow connection to the 5565. This can be done either by unsoldering the RAM and replacing it with a 28-pin DIP socket, or by soldering connector points to the RAM to connect with the new board. Replacing the IC with a socket is the better way to go, and I'll assume you take that route.
The mezzanine board will consist of 5 parts,
1) 28 pins sticking down to mate with the 5565 socket
2) a DPRAM with one side (call it side A) connected to the 5565 signals (with slight exceptions - see 4 and 5)
3) an interface connector to allow side B to be connected to your MCU, and
4) a small amount of logic to convert the 5565 chip enable lines to be compatible to the 7005. The 5565 uses 2 enable lines, one active high and the other active low, while the 7005 uses a single active low enable line.
5) some logic to indicate to the MCU that the game is writing to the same address that the MCU is trying to read. This can get tricky. I'd advise setting up address registers and an output register and not trying to read the 7005 directly, but rather slowing your MCU read cycles down enough to allow contention to resolve.
Oh yes, and be careful about how long a cable you use between the MCU and the board. You don't want ringing on your address lines. Series termination will be a good idea.
Best Answer
This is a very good application for a small FPGA. If you don't need much shared memory, you can use block RAM inside the FPGA. Otherwise, a small parallel SRAM or DRAM should suffice.