Hello!
While preparing firmware v0.1.7c for release I stumbled upon the Cx4 again - Rockman died in attract mode once again. After some nights of fiddling it turns out my timing is ass, and the Cx4 can pull off some more stuff than what the two games do. Bit of a shame actually it wasn't used for more stuff.
Anyway this should cover most of the unknown stuff about MMIO registers, pins, internal registers, instruction timing, cartridge RAM access, DMA, and some oddball stuff.
I did not touch unknown instructions and flags so far.
I tried to organize my notes a bit but it's probably still a mess, please ask if you are confused or need to know anything
So without further ado, here are the notes. Also available at https://sd2snes.de/files/cx4_notes.txt
While preparing firmware v0.1.7c for release I stumbled upon the Cx4 again - Rockman died in attract mode once again. After some nights of fiddling it turns out my timing is ass, and the Cx4 can pull off some more stuff than what the two games do. Bit of a shame actually it wasn't used for more stuff.
Anyway this should cover most of the unknown stuff about MMIO registers, pins, internal registers, instruction timing, cartridge RAM access, DMA, and some oddball stuff.
I did not touch unknown instructions and flags so far.
I tried to organize my notes a bit but it's probably still a mess, please ask if you are confused or need to know anything
So without further ado, here are the notes. Also available at https://sd2snes.de/files/cx4_notes.txt
Code:
=======================================
Cx4 notes by ikari_01 <otakon@gmx.net>
https://sd2snes.de
-> Version: 0.2
- add clarification on memory mapping
- point out that the CPU is halted until caching is complete
- cart bus only claimed on actual bus operations
- add register $7f48
- correct pin mapping (74 and 75 were swapped)
Version: 0.1 (initial)
=======================================
These notes add some information about previously unknown/undocumented aspects
of the Capcom Cx4 custom chip. It is NOT a complete documentation of the Cx4
but adds bits of information missing in existing documentation.
They were compiled while working with the Cx4 and are a bit chaotic, please
ask if anything is unclear.
Hardware:
=========
Pin 74: global memory output enable
Cx4 still exposes its MMIO and internal RAM etc. to the bus if this is
high, but no ROM or RAM connected to it.
Probably for use with cart ROM/RAM connected "alongside" the Cx4 but
independent of it.
Pin 75: Map select (0=LoROM; 1=HiROM)
Memory map
==========
LoROM mapping is widely known. Cart RAM is mapped at 70-7f:0000-7fff.
HiROM mapping is a bit botched at least on the MMX2 PCB. SNES A15 becomes A20
to the ROM, all other address lines are shifted down by one to close the gap.
So the mapping S-CPU -> Cart ROM goes as follows:
C0:0000 => 0x000000
C0:8000 => 0x100000
C1:0000 => 0x008000
C1:8000 => 0x108000
C2:0000 => 0x010000
...
DF:7FFF => 0x0FFFFF
DF:FFFF => 0x1FFFFF
ROM content must be rearranged to match, or rewired.
As a plus, in HiROM mode it is possible to use 32MBits of cart ROM in two
16Mbit chips (by leaving $7f52 at $01), from E0:0000 onward the second ROM
will be selected.
In HiROM mode ROM is mapped as follows (assuming $7f52 = $01)
00-3F:8000-FFFF ROM1 0x100000-0x1FFFFF, ROM2 0x100000-0x1FFFFF
40-7D:0000-FFFF NOTHING (open bus with a bit of noise)
80-BF:8000-FFFF ROM1 0x100000-0x1FFFFF, ROM2 0x100000-0x1FFFFF
C0-FF:0000-7FFF ROM1 0x000000-0x0FFFFF, ROM2 0x000000-0x1FFFFF
C0-FF:8000-FFFF ROM1 0x100000-0x1FFFFF, ROM2 0x100000-0x1FFFFF
Cart RAM mapping:
LoROM: 70-77:0000-7FFF
HiROM: 30-3F:6000-7FFF, B0-BF:6000-7FFF
MMIO mapping:
LoROM: 00-3F:6000-7FFF, 80-BF:6000-7FFF
HiROM: 00-2F:6000-7FFF, 80-AF:6000-7FFF (to make room for Cart RAM)
DMA
===
DMA source and destination CAN reference the same bus but not the same chip,
e.g. cart ROM <-> cart RAM is allowed but cart RAM <-> cart RAM isn't!
Same-bus DMA takes WS1+WS2 extra waitstates per cycle.
DMA from/to internal RAM only takes WS1 or WS2 extra waitstates depending
on the referenced mapping area.
Neither DMA source nor destination may point to unmapped areas (-> lockup).
ROM is disallowed as a DMA destination (-> lockup).
CPU misc. (caching)
===================
Cx4 has two program cache pages. They are the only way it can execute code,
the CPU CANNOT run directly from cart ROM/RAM.
The pages have tags to indicate what program page (from ROM) they currently
contain. The CPU will use these to determine whether a jump across page
boundaries requires re-buffering of one of the cache pages.
If execution reaches the end of cache page 0 and there is no STOP instruction,
page 1 will be buffered (according to contents of P register?) and execution
continues. On end of page 1, execution halts (implied STOP instruction) and
CPU goes idle.
During caching of a program page the CPU is halted until all bytes are copied.
For more details on caching see $7f4c.
For cartridge ROM/RAM access, there are two different configurable waitstate
counts (called WS1+WS2 here; see $7f50 below).
WS1 applies to cart ROM, WS2 applies to cart RAM.
Registers
=========
(for sake of completeness in conjunction with $7f47, $7f40-$7f46 are listed
here.)
$7f40: DMA source low byte
$7f41: DMA source high byte
$7f42: DMA source bank
$7f43: DMA length low byte
$7f44: DMA length high byte
$7f45: DMA destination low byte
$7f46: DMA destination high byte
$7f47: DMA destination bank (!)
ALSO: Trigger GPDMA (BUS<->internal map)
$7f48: R/W
Trigger program page caching
0: Page select (0/1)
This preloads a cache page with bus data (cart ROM/RAM) pre-set by the
offset select ($7f49-$7f4b) and program page select ($7f4d-$7f3e)
registers. The appropriate number of waitstates for the designated
memory type applies.
$7f4c: R/W
1: cache page 1 lock (1=locked)
0: cache page 0 lock (1=locked)
The cache page lock flags are used to prevent the CPU from buffering
to the corresponding cache page at runtime (e.g. when the pgm_page
register is prepared and a JMP/CALL P instruction is executed).
The cache pages can still be filled by writing to $7f48.
This is more or less a tuning mechanism for the developer who can decide
to keep certain code cached at all times.
Several constellations must be considered when code is executed in one
of the cache pages:
no pages locked:
================
If the other page already contains the program page required, the CPU
will just jump there. Otherwise the other page will be loaded with the
program page contents from ROM prior to jumping and its tag will be
updated.
either of the pages locked:
===========================
The other page cannot be used for buffering so unless it already
contains the desired program page the same page is used, overwriting
the code that is currently executed. If a RET occurs, the previous
program page is swapped back in. This requires reading 512 bytes from
cartridge ROM every time so it can get very slow.
both pages locked:
==================
ONLY the program pages that have been pre-cached by writing $7f4d/e and
$7f48 are available to the CPU. If a different program page is requested
prior to execution either by $7f4d/e -> $7f4f, or by a JMP/CALL P
instruction at runtime, execution will stop immediately.
$7f50: 7: -
6-4: WS1 (ROM read waitstates) (0-7)
3: -
2-0: WS2 (cart RAM read/write waitstates) (0-7)
$7f51: 0: IRQ ack / inhibit
(write 1 to ACK and disable further IRQ
write 0 to enable IRQ)
$7f52: ROM configuration select
LoROM: 0: 2x 8Mbit (A21 switches between ROM /CE1 and /CE2)
1: 1x 16Mbit (maybe A22 switches but 40-7f/c0-ff are inactive)
HiROM: 0: 2x 8Mbit (A20 switches)
1: 2x 16Mbit (A21 switches)
$7f53: READ (mirrors: $7f54-$7f57, $7f59, $7f5b-$7f5f)
7: CPU is accessing ROM bus (SNES cut off)
6: CPU is running
5-2: -
1: IRQ pending
0: Cx4 suspended (see $7f55-$7f5d)
WRITE (no mirrors)
Any write access returns the Cx4 to idle state immediately - useful to
recover from infinite loops ;)
$7f55: Any write access indefinitely suspends the Cx4 (registers can be
read and written but the CPU shows no reaction: no buffering occurs,
no code is run and $7f53 is not updated).
Cx4 status bit 0 is set.
$7f56: Any write: Suspend Cx4 for 32 cycles ( 1.6µs @20MHz)
$7f57: Any write: Suspend Cx4 for 64 cycles ( 3.2µs @20MHz)
$7f58: Any write: Suspend Cx4 for 96 cycles ( 4.8µs @20MHz)
$7f59: Any write: Suspend Cx4 for 128 cycles ( 6.4µs @20MHz)
$7f5a: Any write: Suspend Cx4 for 160 cycles ( 8.0µs @20MHz)
$7f5b: Any write: Suspend Cx4 for 192 cycles ( 9.6µs @20MHz)
$7f5c: Any write: Suspend Cx4 for 224 cycles (11.2µs @20MHz)
These registers can be used to obtain guaranteed access to ROM/RAM from the
SNES side while the Cx4 is running. CPU and/or ongoing DMA transfers are
suspended.
$7f5d: Any write clears the Cx4 suspend flag and the chip becomes
responsive again (presumably resumes execution).
$7f5e: Any write clears the IRQ pending flag WITHOUT touching the actual
cart IRQ signal (remains low)
If IRQ is enabled, /IRQ goes high->low when the Cx4 CPU stops, and stays low.
Software must ACK by writing 1 to $7f51 bit 0 -> /IRQ will go high again.
Software must then write 0 again to re-enable IRQ triggering for the next
execution.
CPU registers
=============
$20: PC (PC of current instruction + 1)
$28: ??? (always seems to return $2e)
$2e: cart ROM bus port (triggers cart ROM reads),
to be used with $61 opcode!
Waitstates = $7f50 bits 6-4.
$2f: cart RAM bus port (triggers cart RAM reads/writes),
to be used with $61 / $e1 opcode!
Waitstates = $7f50 bits 2-0.
$70-$7f are mirrors of $60-$6f ("R0-R15").
internal register address appears to be 7-bit, e.g. $e0-$ff are the same
as $60-$7f.
Instruction cycles
==================
1 cycle = 50ns (@20MHz) duh
The vast majority of instructions execute in a single cycle.
Exceptions/noteworthy details are:
- jmp/call takes 1 cycle if branch not taken, 3 cycles if taken
(regardless of p flag, crossing page boundaries comes at no extra cost)
- ret takes 3 cycles
- skip takes 1 cycle for itself, but it makes the skipped instruction count
for 1 cycle (injected NOP or equivalent)
- internal data rom/ram access takes 1 cycle only.
- cart ROM access from Cx4 code:
* Cartridge ROM is accessed by reading from register $2e to a special
internal register (fullsnes: ext_dta). (Opcode: $612e)
* The read itself is 0-waitstate and executes in a single cycle. However
the result will not be valid before the appropriate number of waitstates
is reached and the data is actually pulled in from the ROM.
* The CPU may execute other code in the meantime.
* To stall the CPU until the ROM read operation is complete, a wait
instruction can be issued ($1c00).
* The external bus address does not auto-increment; to do so, a special
instruction can be issued ($4000). There may be a decrement instruction
as well (as of yet unknown). It is useful to do this before the wait
instruction to save a cycle.
* The number of waitstates can be configured by setting $7f50 bits 6-4.
- cart RAM access from Cx4 code:
* Cartridge RAM is accessed by reading from register $2f to a special
internal register, or by writing to register $2f from the same.
(Opcode: $612f (read) / $e12f (write))
* Access handling appears to be the same as for cart ROM, and the
same for reading and writing:
issue read/write; alter bus address; wait for complete (or do
something else in the meantime)
* The number of waitstates can be configured by setting $7f50 bits 2-0.
Cartridge bus is only claimed by the Cx4 when DMA or caching occurs, or a bus access
is carried out by Cx4 code. At all other times the SNES address+data buses are forwarded
to the ROM/RAM even if the Cx4 CPU is running.
Flags
=====
As of yet untouched. higan seems to do a decent job at them already.
scribble / internal notes from testing
======================================
This is probably useless but eh.
Cx4 code base: 01:8000
PC always 00
1 cycle = 50ns
255 NOP + 1 STOP in 12.8us -> 50ns/inst -> 1 cycle/inst
255 JMP + 1 STOP in 38.4us -> 150ns/inst -> 3 cycles/inst
255 MOV -> A/R0 + 1 STOP in 12.8 us -> 50ns/inst -> 1 cycle/inst
255 RDWR ROM/RAM + 1 STOP in 12.8 us -> 50ns/inst -> 1 cycle/inst
255 RDBUS (612E) -> CRASH
127 RDBUS+WAIT + 1 STOP in 32us -> 250ns/pair -> 5 cycles total (WS = 4)
127 RDBUS+WAIT + 1 STOP in 19.2us -> 150ns/pair -> 3 cycles total (WS = 2)
127 RDBUS+WAIT + 1 STOP in 12.8us -> 100ns/pair -> 2 cycles total (WS = 1)
127 RDBUS+WAIT + 1 STOP in 12.8us -> 100ns/pair -> 2 cycles total (WS = 0!)
127 RDBUS+INC + 1 STOP in 12.8us + CRASH -> 100ns/pair -> 2 cycles total (WS = 4!!!!!)
85 RDBUS+INC+WAIT + 1 STOP in 21.4us -> 250ns/triple -> 5 cycles total (WS = 4)
85 WRBUS?!+INC+WAIT + 1 STOP in 21.4us -> 250ns/triple -> 5 cycles total (WS = 4)
Page file
======================
00 cx4_00_nop.bin 1
01 cx4_08_jmp.bin 3
02 cx4_64_mova.bin 1
03 cx4_e0_movr0.bin 1
04 cx4_70_rdrom.bin 1
05 cx4_68_rdram_r0.bin 1
06 cx4_6c_rdram_imm.bin 1
07 cx4_e8_wrram_r0.bin 1
08 cx4_ec_wrram_imm.bin 1
09 cx4_40_rdbus_wait.bin ?!
0a cx4_40_rdbus_nowait.bin 1
0b cx4_24_skip_unknown.bin 1
0c cx4_25_skip_nc.bin 1
0d cx4_25_skip_c.bin 1
0e cx4_28_call.bin 3
0f cx4_81_add_shl1.bin 1
10 cx4_61_bustest.bin - (1)
11 cx4_61_bustest_1c.bin 1+WS (1 cycle 612e; ->WS cycles 1c00)
12 cx4_61_bustest_40.bin 2+crash (1 cycle 612e; 1 cycle 4000)
13 cx4_61_bustest_401c.bin 2+(WS-1) (1 cycle 612e; 1 cycle 4000; ->WS cycles 1c00)
14 cx4_e0_bustest_401c.bin 1
15 cx4_e1_bustest_401c.bin 1
16 cx4_e12f_bustest_401c.bin 2+WS2-1 !!!!
17 cx4_612f_bustest_401c.bin 2+WS2-1 !!!!
18 cx4_e02f_bustest_401c.bin 3 (doesn't work!)
19 cx4_0a_jmp_p1.bin 3 (P test not applicable - see 1d+1e)
1a cx4_0a_jmp_p2.bin 3 (P test not applicable - see 1d+1e)
1b cx4_0c_jz.bin 1 (not taken), 3 (taken)
1c cx4_10_jc.bin 1 (not taken), 3 (taken)
1d cx4_3c_ret.bin 3
1e cx4_2a_call_p.bin 1 (not taken), 3 (taken)
1f cx4_25_skiptest_nc.bin 1 (not taken), 2 (taken)
20 cx4_25_skiptest_c.bin 1 (not taken), 2 (taken)
21 cx4_25_skiptest_nc_alljmp.bin
22 cx4_25_skiptest_c_alljmp.bin
23 cx4_xx_infloop.bin -
24 cx4_xx_busloop.bin (for 0x80 flag testing)
25 cx4_xx_dumpflags.bin (hopefully)
26 cx4_f0_xchg.bin 1
27 cx4_xx_opdump.bin -
28 cx4_xx_flagloop.bin -
29 cx4_xx_opdump2.bin -
2a cx4_xx_opdump3.bin -
opdump:
PC regs
---------------
00 04,05,06,07,09,0a,0b,0d,0e,0f,10,11,12,14,15,16
28 17,18,19,1a,1b,1d,1e,1f,20,21,22,23,24,25,26,27
50 28,29,2a,2b,2c,2d,30,31,32,33,34,35,36,37,38,39
78 3a,3b,3c,3d,3e,3f,40,41,42,43,44,45,46,47,48,49
a0 4a,4b,4c,4d,4e,4f,70,71,72,73,74,75,76,77,78,79
c8 7a,7b,7c,7d,7e,7f,80,81,82,83,84,85,86,87,88,89
f0 8a,8b,8c,8d,8e,8f,90
opdump2:
PC regs
---------------
00 91,92,93,94,95,96,97,98,99,9a,9b,9c,9d,9e,9f,a0
28 a1,a2,a3,a4,a5,a6,a7,a8,a9,aa,ab,ac,ad,ae,af,b0
50 b1,b2,b3,b4,b5,b6,b7,b8,b9,ba,bb,bc,bd,be,bf,c0
78 c1,c2,c3,c4,c5,c6,c7,c8,c9,ca,cb,cc,cd,ce,cf,d0
a0 d1,d2,d3,d4,d5,d6,d7,d8,d9,da,db,dc,dd,de,df,e0
c8 e1,e2,e3,e4,e5,e6,e7,e8,e9,ea,eb,ec,ed,ee,ef,f0
f0 f1,f2,f3,f4,f5,f6,f7
opdump3:
PC regs
---------------
00 f8,f9,fa,fb,fc,fd,fe,ff
Cx4 notes by ikari_01 <otakon@gmx.net>
https://sd2snes.de
-> Version: 0.2
- add clarification on memory mapping
- point out that the CPU is halted until caching is complete
- cart bus only claimed on actual bus operations
- add register $7f48
- correct pin mapping (74 and 75 were swapped)
Version: 0.1 (initial)
=======================================
These notes add some information about previously unknown/undocumented aspects
of the Capcom Cx4 custom chip. It is NOT a complete documentation of the Cx4
but adds bits of information missing in existing documentation.
They were compiled while working with the Cx4 and are a bit chaotic, please
ask if anything is unclear.
Hardware:
=========
Pin 74: global memory output enable
Cx4 still exposes its MMIO and internal RAM etc. to the bus if this is
high, but no ROM or RAM connected to it.
Probably for use with cart ROM/RAM connected "alongside" the Cx4 but
independent of it.
Pin 75: Map select (0=LoROM; 1=HiROM)
Memory map
==========
LoROM mapping is widely known. Cart RAM is mapped at 70-7f:0000-7fff.
HiROM mapping is a bit botched at least on the MMX2 PCB. SNES A15 becomes A20
to the ROM, all other address lines are shifted down by one to close the gap.
So the mapping S-CPU -> Cart ROM goes as follows:
C0:0000 => 0x000000
C0:8000 => 0x100000
C1:0000 => 0x008000
C1:8000 => 0x108000
C2:0000 => 0x010000
...
DF:7FFF => 0x0FFFFF
DF:FFFF => 0x1FFFFF
ROM content must be rearranged to match, or rewired.
As a plus, in HiROM mode it is possible to use 32MBits of cart ROM in two
16Mbit chips (by leaving $7f52 at $01), from E0:0000 onward the second ROM
will be selected.
In HiROM mode ROM is mapped as follows (assuming $7f52 = $01)
00-3F:8000-FFFF ROM1 0x100000-0x1FFFFF, ROM2 0x100000-0x1FFFFF
40-7D:0000-FFFF NOTHING (open bus with a bit of noise)
80-BF:8000-FFFF ROM1 0x100000-0x1FFFFF, ROM2 0x100000-0x1FFFFF
C0-FF:0000-7FFF ROM1 0x000000-0x0FFFFF, ROM2 0x000000-0x1FFFFF
C0-FF:8000-FFFF ROM1 0x100000-0x1FFFFF, ROM2 0x100000-0x1FFFFF
Cart RAM mapping:
LoROM: 70-77:0000-7FFF
HiROM: 30-3F:6000-7FFF, B0-BF:6000-7FFF
MMIO mapping:
LoROM: 00-3F:6000-7FFF, 80-BF:6000-7FFF
HiROM: 00-2F:6000-7FFF, 80-AF:6000-7FFF (to make room for Cart RAM)
DMA
===
DMA source and destination CAN reference the same bus but not the same chip,
e.g. cart ROM <-> cart RAM is allowed but cart RAM <-> cart RAM isn't!
Same-bus DMA takes WS1+WS2 extra waitstates per cycle.
DMA from/to internal RAM only takes WS1 or WS2 extra waitstates depending
on the referenced mapping area.
Neither DMA source nor destination may point to unmapped areas (-> lockup).
ROM is disallowed as a DMA destination (-> lockup).
CPU misc. (caching)
===================
Cx4 has two program cache pages. They are the only way it can execute code,
the CPU CANNOT run directly from cart ROM/RAM.
The pages have tags to indicate what program page (from ROM) they currently
contain. The CPU will use these to determine whether a jump across page
boundaries requires re-buffering of one of the cache pages.
If execution reaches the end of cache page 0 and there is no STOP instruction,
page 1 will be buffered (according to contents of P register?) and execution
continues. On end of page 1, execution halts (implied STOP instruction) and
CPU goes idle.
During caching of a program page the CPU is halted until all bytes are copied.
For more details on caching see $7f4c.
For cartridge ROM/RAM access, there are two different configurable waitstate
counts (called WS1+WS2 here; see $7f50 below).
WS1 applies to cart ROM, WS2 applies to cart RAM.
Registers
=========
(for sake of completeness in conjunction with $7f47, $7f40-$7f46 are listed
here.)
$7f40: DMA source low byte
$7f41: DMA source high byte
$7f42: DMA source bank
$7f43: DMA length low byte
$7f44: DMA length high byte
$7f45: DMA destination low byte
$7f46: DMA destination high byte
$7f47: DMA destination bank (!)
ALSO: Trigger GPDMA (BUS<->internal map)
$7f48: R/W
Trigger program page caching
0: Page select (0/1)
This preloads a cache page with bus data (cart ROM/RAM) pre-set by the
offset select ($7f49-$7f4b) and program page select ($7f4d-$7f3e)
registers. The appropriate number of waitstates for the designated
memory type applies.
$7f4c: R/W
1: cache page 1 lock (1=locked)
0: cache page 0 lock (1=locked)
The cache page lock flags are used to prevent the CPU from buffering
to the corresponding cache page at runtime (e.g. when the pgm_page
register is prepared and a JMP/CALL P instruction is executed).
The cache pages can still be filled by writing to $7f48.
This is more or less a tuning mechanism for the developer who can decide
to keep certain code cached at all times.
Several constellations must be considered when code is executed in one
of the cache pages:
no pages locked:
================
If the other page already contains the program page required, the CPU
will just jump there. Otherwise the other page will be loaded with the
program page contents from ROM prior to jumping and its tag will be
updated.
either of the pages locked:
===========================
The other page cannot be used for buffering so unless it already
contains the desired program page the same page is used, overwriting
the code that is currently executed. If a RET occurs, the previous
program page is swapped back in. This requires reading 512 bytes from
cartridge ROM every time so it can get very slow.
both pages locked:
==================
ONLY the program pages that have been pre-cached by writing $7f4d/e and
$7f48 are available to the CPU. If a different program page is requested
prior to execution either by $7f4d/e -> $7f4f, or by a JMP/CALL P
instruction at runtime, execution will stop immediately.
$7f50: 7: -
6-4: WS1 (ROM read waitstates) (0-7)
3: -
2-0: WS2 (cart RAM read/write waitstates) (0-7)
$7f51: 0: IRQ ack / inhibit
(write 1 to ACK and disable further IRQ
write 0 to enable IRQ)
$7f52: ROM configuration select
LoROM: 0: 2x 8Mbit (A21 switches between ROM /CE1 and /CE2)
1: 1x 16Mbit (maybe A22 switches but 40-7f/c0-ff are inactive)
HiROM: 0: 2x 8Mbit (A20 switches)
1: 2x 16Mbit (A21 switches)
$7f53: READ (mirrors: $7f54-$7f57, $7f59, $7f5b-$7f5f)
7: CPU is accessing ROM bus (SNES cut off)
6: CPU is running
5-2: -
1: IRQ pending
0: Cx4 suspended (see $7f55-$7f5d)
WRITE (no mirrors)
Any write access returns the Cx4 to idle state immediately - useful to
recover from infinite loops ;)
$7f55: Any write access indefinitely suspends the Cx4 (registers can be
read and written but the CPU shows no reaction: no buffering occurs,
no code is run and $7f53 is not updated).
Cx4 status bit 0 is set.
$7f56: Any write: Suspend Cx4 for 32 cycles ( 1.6µs @20MHz)
$7f57: Any write: Suspend Cx4 for 64 cycles ( 3.2µs @20MHz)
$7f58: Any write: Suspend Cx4 for 96 cycles ( 4.8µs @20MHz)
$7f59: Any write: Suspend Cx4 for 128 cycles ( 6.4µs @20MHz)
$7f5a: Any write: Suspend Cx4 for 160 cycles ( 8.0µs @20MHz)
$7f5b: Any write: Suspend Cx4 for 192 cycles ( 9.6µs @20MHz)
$7f5c: Any write: Suspend Cx4 for 224 cycles (11.2µs @20MHz)
These registers can be used to obtain guaranteed access to ROM/RAM from the
SNES side while the Cx4 is running. CPU and/or ongoing DMA transfers are
suspended.
$7f5d: Any write clears the Cx4 suspend flag and the chip becomes
responsive again (presumably resumes execution).
$7f5e: Any write clears the IRQ pending flag WITHOUT touching the actual
cart IRQ signal (remains low)
If IRQ is enabled, /IRQ goes high->low when the Cx4 CPU stops, and stays low.
Software must ACK by writing 1 to $7f51 bit 0 -> /IRQ will go high again.
Software must then write 0 again to re-enable IRQ triggering for the next
execution.
CPU registers
=============
$20: PC (PC of current instruction + 1)
$28: ??? (always seems to return $2e)
$2e: cart ROM bus port (triggers cart ROM reads),
to be used with $61 opcode!
Waitstates = $7f50 bits 6-4.
$2f: cart RAM bus port (triggers cart RAM reads/writes),
to be used with $61 / $e1 opcode!
Waitstates = $7f50 bits 2-0.
$70-$7f are mirrors of $60-$6f ("R0-R15").
internal register address appears to be 7-bit, e.g. $e0-$ff are the same
as $60-$7f.
Instruction cycles
==================
1 cycle = 50ns (@20MHz) duh
The vast majority of instructions execute in a single cycle.
Exceptions/noteworthy details are:
- jmp/call takes 1 cycle if branch not taken, 3 cycles if taken
(regardless of p flag, crossing page boundaries comes at no extra cost)
- ret takes 3 cycles
- skip takes 1 cycle for itself, but it makes the skipped instruction count
for 1 cycle (injected NOP or equivalent)
- internal data rom/ram access takes 1 cycle only.
- cart ROM access from Cx4 code:
* Cartridge ROM is accessed by reading from register $2e to a special
internal register (fullsnes: ext_dta). (Opcode: $612e)
* The read itself is 0-waitstate and executes in a single cycle. However
the result will not be valid before the appropriate number of waitstates
is reached and the data is actually pulled in from the ROM.
* The CPU may execute other code in the meantime.
* To stall the CPU until the ROM read operation is complete, a wait
instruction can be issued ($1c00).
* The external bus address does not auto-increment; to do so, a special
instruction can be issued ($4000). There may be a decrement instruction
as well (as of yet unknown). It is useful to do this before the wait
instruction to save a cycle.
* The number of waitstates can be configured by setting $7f50 bits 6-4.
- cart RAM access from Cx4 code:
* Cartridge RAM is accessed by reading from register $2f to a special
internal register, or by writing to register $2f from the same.
(Opcode: $612f (read) / $e12f (write))
* Access handling appears to be the same as for cart ROM, and the
same for reading and writing:
issue read/write; alter bus address; wait for complete (or do
something else in the meantime)
* The number of waitstates can be configured by setting $7f50 bits 2-0.
Cartridge bus is only claimed by the Cx4 when DMA or caching occurs, or a bus access
is carried out by Cx4 code. At all other times the SNES address+data buses are forwarded
to the ROM/RAM even if the Cx4 CPU is running.
Flags
=====
As of yet untouched. higan seems to do a decent job at them already.
scribble / internal notes from testing
======================================
This is probably useless but eh.
Cx4 code base: 01:8000
PC always 00
1 cycle = 50ns
255 NOP + 1 STOP in 12.8us -> 50ns/inst -> 1 cycle/inst
255 JMP + 1 STOP in 38.4us -> 150ns/inst -> 3 cycles/inst
255 MOV -> A/R0 + 1 STOP in 12.8 us -> 50ns/inst -> 1 cycle/inst
255 RDWR ROM/RAM + 1 STOP in 12.8 us -> 50ns/inst -> 1 cycle/inst
255 RDBUS (612E) -> CRASH
127 RDBUS+WAIT + 1 STOP in 32us -> 250ns/pair -> 5 cycles total (WS = 4)
127 RDBUS+WAIT + 1 STOP in 19.2us -> 150ns/pair -> 3 cycles total (WS = 2)
127 RDBUS+WAIT + 1 STOP in 12.8us -> 100ns/pair -> 2 cycles total (WS = 1)
127 RDBUS+WAIT + 1 STOP in 12.8us -> 100ns/pair -> 2 cycles total (WS = 0!)
127 RDBUS+INC + 1 STOP in 12.8us + CRASH -> 100ns/pair -> 2 cycles total (WS = 4!!!!!)
85 RDBUS+INC+WAIT + 1 STOP in 21.4us -> 250ns/triple -> 5 cycles total (WS = 4)
85 WRBUS?!+INC+WAIT + 1 STOP in 21.4us -> 250ns/triple -> 5 cycles total (WS = 4)
Page file
======================
00 cx4_00_nop.bin 1
01 cx4_08_jmp.bin 3
02 cx4_64_mova.bin 1
03 cx4_e0_movr0.bin 1
04 cx4_70_rdrom.bin 1
05 cx4_68_rdram_r0.bin 1
06 cx4_6c_rdram_imm.bin 1
07 cx4_e8_wrram_r0.bin 1
08 cx4_ec_wrram_imm.bin 1
09 cx4_40_rdbus_wait.bin ?!
0a cx4_40_rdbus_nowait.bin 1
0b cx4_24_skip_unknown.bin 1
0c cx4_25_skip_nc.bin 1
0d cx4_25_skip_c.bin 1
0e cx4_28_call.bin 3
0f cx4_81_add_shl1.bin 1
10 cx4_61_bustest.bin - (1)
11 cx4_61_bustest_1c.bin 1+WS (1 cycle 612e; ->WS cycles 1c00)
12 cx4_61_bustest_40.bin 2+crash (1 cycle 612e; 1 cycle 4000)
13 cx4_61_bustest_401c.bin 2+(WS-1) (1 cycle 612e; 1 cycle 4000; ->WS cycles 1c00)
14 cx4_e0_bustest_401c.bin 1
15 cx4_e1_bustest_401c.bin 1
16 cx4_e12f_bustest_401c.bin 2+WS2-1 !!!!
17 cx4_612f_bustest_401c.bin 2+WS2-1 !!!!
18 cx4_e02f_bustest_401c.bin 3 (doesn't work!)
19 cx4_0a_jmp_p1.bin 3 (P test not applicable - see 1d+1e)
1a cx4_0a_jmp_p2.bin 3 (P test not applicable - see 1d+1e)
1b cx4_0c_jz.bin 1 (not taken), 3 (taken)
1c cx4_10_jc.bin 1 (not taken), 3 (taken)
1d cx4_3c_ret.bin 3
1e cx4_2a_call_p.bin 1 (not taken), 3 (taken)
1f cx4_25_skiptest_nc.bin 1 (not taken), 2 (taken)
20 cx4_25_skiptest_c.bin 1 (not taken), 2 (taken)
21 cx4_25_skiptest_nc_alljmp.bin
22 cx4_25_skiptest_c_alljmp.bin
23 cx4_xx_infloop.bin -
24 cx4_xx_busloop.bin (for 0x80 flag testing)
25 cx4_xx_dumpflags.bin (hopefully)
26 cx4_f0_xchg.bin 1
27 cx4_xx_opdump.bin -
28 cx4_xx_flagloop.bin -
29 cx4_xx_opdump2.bin -
2a cx4_xx_opdump3.bin -
opdump:
PC regs
---------------
00 04,05,06,07,09,0a,0b,0d,0e,0f,10,11,12,14,15,16
28 17,18,19,1a,1b,1d,1e,1f,20,21,22,23,24,25,26,27
50 28,29,2a,2b,2c,2d,30,31,32,33,34,35,36,37,38,39
78 3a,3b,3c,3d,3e,3f,40,41,42,43,44,45,46,47,48,49
a0 4a,4b,4c,4d,4e,4f,70,71,72,73,74,75,76,77,78,79
c8 7a,7b,7c,7d,7e,7f,80,81,82,83,84,85,86,87,88,89
f0 8a,8b,8c,8d,8e,8f,90
opdump2:
PC regs
---------------
00 91,92,93,94,95,96,97,98,99,9a,9b,9c,9d,9e,9f,a0
28 a1,a2,a3,a4,a5,a6,a7,a8,a9,aa,ab,ac,ad,ae,af,b0
50 b1,b2,b3,b4,b5,b6,b7,b8,b9,ba,bb,bc,bd,be,bf,c0
78 c1,c2,c3,c4,c5,c6,c7,c8,c9,ca,cb,cc,cd,ce,cf,d0
a0 d1,d2,d3,d4,d5,d6,d7,d8,d9,da,db,dc,dd,de,df,e0
c8 e1,e2,e3,e4,e5,e6,e7,e8,e9,ea,eb,ec,ed,ee,ef,f0
f0 f1,f2,f3,f4,f5,f6,f7
opdump3:
PC regs
---------------
00 f8,f9,fa,fb,fc,fd,fe,ff
