+
+#if 0
+Rolling Thunder Memory map
+--------------------------
+Most of the decoding is done by custom chips (CUS47 and CUS41), so the memory
+map is inferred by program behaviour. The customs also handle internally irq
+and watchdog.
+The main CPU memory map is the same in all games because CUS47 is used by all
+games. The sub CPU and sound CPU, on the other hand, change because CUS41 is
+replaced by other chips.
+All RAM is shared between main and sub CPU, except for sound RAM which is shared
+between main and sound CPU; the portion of object RAM that is overlapped by sound
+RAM is used exclusively by the sub CPU.
+
+MAIN CPU:
+
+Address Dir Data Name Description
+------------------- --- -------- --------- -----------------------
+000x xxxx xxxx xxxx R/W xxxxxxxx SCROLL0 tilemap 0/1 RAM (shared with sub CPU)
+001x xxxx xxxx xxxx R/W xxxxxxxx SCROLL1 tilemap 2/3 RAM (shared with sub CPU)
+0100 00xx xxxx xxxx R/W xxxxxxxx SOUND sound RAM (through CUS30, shared with MCU)
+0100 0000 xxxx xxxx R/W xxxxxxxx portion holding the sound wave data
+0100 0001 00xx xxxx R/W xxxxxxxx portion holding the sound registers
+010x xxxx xxxx xxxx R/W xxxxxxxx OBJECT work RAM (shared with sub CPU) [1]
+0101 1xxx xxxx xxxx R/W xxxxxxxx portion holding sprite registers
+011x xxxx xxxx xxxx R xxxxxxxx ROM 9D program ROM (banked) [2]
+1xxx xxxx xxxx xxxx R xxxxxxxx ROM 9C program ROM
+1000 00-- ---- ---- W -------- watchdog reset (RES generated by CUS47)
+1000 01-- ---- ---- W -------- main CPU irq acknowledge (IRQ generated by CUS47)
+1000 1x-- ---- ---- W -------- BANK tile gfx bank select (data is in A10) (latch in CUS47)
+1001 00-- ---- -x0x W xxxxxxxx LATCH0 tilemap 0/1 X scroll + priority
+1001 00-- ---- -x10 W xxxxxxxx LATCH0 tilemap 0/1 Y scroll
+1001 00-- ---- --11 W ------xx BAMNKM ROM 9D bank select
+1001 01-- ---- -x0x W xxxxxxxx LATCH1 tilemap 2/3 X scroll + priority
+1001 01-- ---- -x10 W xxxxxxxx LATCH1 tilemap 2/3 Y scroll
+1001 01-- ---- --11 W ------xx BAMNKS ROM 12D bank select
+1100 00-- ---- ---- W xxxxxxxx BACKCOLOR background color
+
+[1] Note that this is partially overlapped by sound RAM
+[2] In Rolling Thunder and others, replaced by the ROM/voice expansion board
+
+
+SUB CPU:
+
+Address Dir Data Name Description
+------------------- --- -------- --------- -----------------------
+000x xxxx xxxx xxxx R/W xxxxxxxx SUBOBJ work RAM (shared with main CPU)
+0001 1xxx xxxx xxxx R/W xxxxxxxx portion holding sprite registers
+001x xxxx xxxx xxxx R/W xxxxxxxx SUBSCR0 tilemap 0/1 RAM (shared with main CPU)
+010x xxxx xxxx xxxx R/W xxxxxxxx SUBSCR1 tilemap 2/3 RAM (shared with main CPU)
+011x xxxx xxxx xxxx R xxxxxxxx ROM 12D program ROM (banked) [1]
+1xxx xxxx xxxx xxxx R xxxxxxxx ROM 12C program ROM
+1000 0--- ---- ---- W -------- watchdog reset (MRESET generated by CUS41)
+1000 1--- ---- ---- W -------- main CPU irq acknowledge (generated by CUS41)
+1101 0--- ---- -x0x W xxxxxxxx LATCH0 tilemap 0/1 X scroll + priority
+1101 0--- ---- -x10 W xxxxxxxx LATCH0 tilemap 0/1 Y scroll
+1101 0--- ---- --11 W ------xx BAMNKM ROM 9D bank select
+1101 1--- ---- -x0x W xxxxxxxx LATCH1 tilemap 2/3 X scroll + priority
+1101 1--- ---- -x10 W xxxxxxxx LATCH1 tilemap 2/3 Y scroll
+1101 1--- ---- --11 W ------xx BAMNKS ROM 12D bank select
+
+[1] Only used by Rolling Thunder
+
+
+MCU:
+
+Address Dir Data Name Description
+------------------- --- -------- --------- -----------------------
+0000 0000 xxxx xxxx MCU internal registers, timers, ports and RAM
+0001 xxxx xxxx xxxx R/W xxxxxxxx RAM 3F sound RAM (through CUS30, partially shared with main CPU)
+0001 0000 xxxx xxxx R/W xxxxxxxx portion holding the sound wave data
+0001 0001 00xx xxxx R/W xxxxxxxx portion holding the sound registers
+0010 0--- --00 ---x R/W xxxxxxxx YMCS YM2151
+0010 0--- --01 ---- n.c.
+0010 0--- --10 ---- R xxxxxxxx PORTA switch inputs
+0010 0--- --11 ---- R xxxxxxxx PORTB dip switches
+01xx xxxx xxxx xxxx R xxxxxxxx ROM 6B program ROM (lower half)
+10xx xxxx xxxx xxxx R xxxxxxxx ROM 6B program ROM (upper half)
+1011 0--- ---- ---- W unknown (CUS41)
+1011 1--- ---- ---- W unknown (CUS41)
+1111 xxxx xxxx xxxx R xxxxxxxx MCU internal ROM
+
+
+Notes:
+-----
+- we are using an unusually high CPU interleave factor (800) to avoid hangs
+ in rthunder. The two 6809 in this game synchronize using a semaphore at
+ 5606/5607 (CPU1) 1606/1607 (CPU2). CPU1 clears 5606, does some quick things,
+ and then increments 5606. While it does its quick things (which require
+ about 40 clock cycles) it expects CPU2 to clear 5607.
+ Raising the interleave factor to 1000 makes wndrmomo crash during attract
+ mode. I haven't investigated on the cause.
+
+- There are two watchdogs, one per CPU (or maybe three). Handling them
+ separately is necessary to allow entering service mode without manually
+ resetting in rthunder and genpeitd: only one of the CPUs stops writing to
+ the watchdog.
+
+- The sprite hardware buffers spriteram: the program writes the sprite list to
+ offsets 4-9 of every 16-byte block, then at the end writes to offset 0x1ff2 of
+ sprite RAM to signal the chip that the list is complete. The chip will copy
+ the list from 4-9 to 10-15 and use it from there. This has not been verified
+ on the real hardware, but it is the most logical way of doing it.
+ Emulating this behaviour and not using an external buffer is important in
+ rthunder: when you insert a coin, the whole sprite RAM is cleared, but 0x1ff2
+ is not written to. If we buffered spriteram to an external buffer, this would
+ cause dangling sprites because the buffer would not be updated.
+
+- spriteram buffering fixes sprite lag, but causes a glitch in rthunder when
+ entering a door. The *closed* door is made of tiles, but the *moving* door is
+ made of sprites. Since sprites are delayed by 1 frame, when you enter a door
+ there is one frame where neither the tile-based closed door nor the
+ sprite-based moving door is shown, so it flickers. This behavior has been
+ confirmed on a real PCB.
+
+TODO:
+----
+- The two unknown writes for the MCU are probably watchdog reset and irq acknowledge,
+ but they don't seem to work as expected. During the first few frames they are
+ written out of order and hooking them up in the usual way causes the MCU to
+ stop receiving interrupts.
+
+#endif