Some tidbits about the Cx4 (attn: byuu, nocash)

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
ikari_01
Posts: 141
Joined: Sat Jul 04, 2009 2:28 pm
Location: Wunstorf, Germany

Some tidbits about the Cx4 (attn: byuu, nocash)

Post by ikari_01 »

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

Code: Select all

=======================================
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
     i­nstruction 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

Last edited by ikari_01 on Wed Aug 10, 2016 5:59 am, edited 1 time in total.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: Some tidbits about the Cx4 (attn: byuu, nocash)

Post by Near »

Great work, thank you very much for sharing it with us!

I can't say I understand all of your notes, but there's some stuff I should be able to improve. Really surprised that almost all instructions really do run at 20MIPS ... this thing is indeed a beast!

When a program cache needs to be loaded, does the Cx4 stall and read in the entire page all at once? Or is it an on-demand thing, fetching the bytes as they execute? Given the way the Cx4 has to pull the ROM off the bus, I assume the former.

Also, I'm unsure about emulating the HiROM mapping mode. I want to, but the weird address mangling you mention isn't something I'm going to want to do. If I do support it, I'll probably allow a non-mangled ROM to be used instead. Add something like mode=banked|linear to the cx4 node in the manifest.
User avatar
ikari_01
Posts: 141
Joined: Sat Jul 04, 2009 2:28 pm
Location: Wunstorf, Germany

Re: Some tidbits about the Cx4 (attn: byuu, nocash)

Post by ikari_01 »

byuu wrote:When a program cache needs to be loaded, does the Cx4 stall and read in the entire page all at once? Or is it an on-demand thing, fetching the bytes as they execute? Given the way the Cx4 has to pull the ROM off the bus, I assume the former.
The former is correct. It always reads an entire cache page's worth of bytes (512) from cart ROM/RAM, that is its granularity for the cache tags.

Oh, it may be worth mentioning that the Cx4 only acquires the bus when it is actually accessing it. This is a given for buffering/DMA but it also applies to individual bus read instructions carried out by Cx4 code.
E.g. with 4 waitstates (as set by RMX2/3), when a $612e;$4000;1c00 happens, it will only acquire the bus and apply its own address for 250ns, and forward the SNES CPU bus at all other times.
byuu wrote:Also, I'm unsure about emulating the HiROM mapping mode. I want to, but the weird address mangling you mention isn't something I'm going to want to do.
I'd say it is safe to assume a "classical" HiROM mapping, my guess is that the pin was just intended for the Cx4 to respond on HiROM-ish addresses, requiring a dedicated PCB layout for the rest. It is set by a pin, not a register after all.
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: Some tidbits about the Cx4 (attn: byuu, nocash)

Post by AWJ »

ikari_01 wrote:
byuu wrote:When a program cache needs to be loaded, does the Cx4 stall and read in the entire page all at once? Or is it an on-demand thing, fetching the bytes as they execute? Given the way the Cx4 has to pull the ROM off the bus, I assume the former.
The former is correct. It always reads an entire cache page's worth of bytes (512) from cart ROM/RAM, that is its granularity for the cache tags.
I think what he meant to ask is does the Cx4 wait for the entire cache page to be loaded before resuming execution, or does it start executing as soon as the address being jumped to is in the cache? I.e. is jumping to the first address in a 512-byte page any faster than jumping to an address near the end of the page?
User avatar
ikari_01
Posts: 141
Joined: Sat Jul 04, 2009 2:28 pm
Location: Wunstorf, Germany

Re: Some tidbits about the Cx4 (attn: byuu, nocash)

Post by ikari_01 »

Oh ok. No, the CPU is halted until the entire page has been filled.

EDIT: Oh, looks like I forgot to mention one other thing:
Writing to $7f48 is used by SNES code to preload at least one of the cache pages. This is required before starting the CPU using $7f4f. Bit 0 determines which of the two pages to write to. Waitstates as usual are according to $7f50 and the source address set at $7f49-$7f4b.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Some tidbits about the Cx4 (attn: byuu, nocash)

Post by tepples »

byuu wrote:Also, I'm unsure about emulating the HiROM mapping mode. I want to, but the weird address mangling you mention isn't something I'm going to want to do. If I do support it, I'll probably allow a non-mangled ROM to be used instead.
Agreed. The situation reminds me of the "swapbin" utility. Rearrange the banks of the ROM image into what the program sees, and just assume the HiROM boards have a funny swapped ROM pinout.
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: Some tidbits about the Cx4 (attn: byuu, nocash)

Post by AWJ »

In which 65816 banks are the Cx4 registers and internal RAM mapped in each mode (LoROM/HiROM)? The HiROM mapping you've shown for external RAM overlaps with the register/internal RAM mapping.
qwertymodo
Posts: 775
Joined: Mon Jul 02, 2012 7:46 am

Re: Some tidbits about the Cx4 (attn: byuu, nocash)

Post by qwertymodo »

Great to see somebody finally figured out pins 74 and 75. Now we have a complete pinout :)
Markfrizb
Posts: 607
Joined: Sun Dec 02, 2012 8:17 am
Location: East Texas

Re: Some tidbits about the Cx4 (attn: byuu, nocash)

Post by Markfrizb »

So if you hold pin75 high, is this basically tri-stating the outputs of the CX4?
qwertymodo
Posts: 775
Joined: Mon Jul 02, 2012 7:46 am

Re: Some tidbits about the Cx4 (attn: byuu, nocash)

Post by qwertymodo »

Markfrizb wrote:So if you hold pin75 high, is this basically tri-stating the outputs of the CX4?
If I read it right, you can still read and write to the Cx4 itself (i.e. the internal registers) but it no longer passes through reads and writes to the ROM/SRAM. Theoretically, you could have a ROM/RAM dedicated to just the Cx4, and then a separate ROM/RAM for the main cart address space, though you'd probably need a separate address decoder in that case.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: Some tidbits about the Cx4 (attn: byuu, nocash)

Post by Near »

qwertymodo wrote:If I read it right, you can still read and write to the Cx4 itself (i.e. the internal registers) but it no longer passes through reads and writes to the ROM/SRAM. Theoretically, you could have a ROM/RAM dedicated to just the Cx4, and then a separate ROM/RAM for the main cart address space, though you'd probably need a separate address decoder in that case.
I would think that would make the chip useless. If you don't have ROM, you can't load in program cache pages. If you don't have RAM, you don't really have space to write out any results from your code executing. If you don't have either, you have a 20MHz paperweight.

If the Cx4 had its own little pool of program RAM and data RAM, that might be a useful feature to exist.

At any rate, I'm definitely not emulating this mode.
User avatar
ikari_01
Posts: 141
Joined: Sat Jul 04, 2009 2:28 pm
Location: Wunstorf, Germany

Re: Some tidbits about the Cx4 (attn: byuu, nocash)

Post by ikari_01 »

AWJ wrote:In which 65816 banks are the Cx4 registers and internal RAM mapped in each mode (LoROM/HiROM)? The HiROM mapping you've shown for external RAM overlaps with the register/internal RAM mapping.
LoROM: 00-3f:6000-7fff, 80-bf:6000-7fff
HiROM: 00-2f:6000-7fff, 80-af:6000-7fff (30-3f, b0-bf is used for cart RAM)
User avatar
ikari_01
Posts: 141
Joined: Sat Jul 04, 2009 2:28 pm
Location: Wunstorf, Germany

Re: Some tidbits about the Cx4 (attn: byuu, nocash)

Post by ikari_01 »

qwertymodo wrote:If I read it right, you can still read and write to the Cx4 itself (i.e. the internal registers) but it no longer passes through reads and writes to the ROM/SRAM. Theoretically, you could have a ROM/RAM dedicated to just the Cx4, and then a separate ROM/RAM for the main cart address space, though you'd probably need a separate address decoder in that case.
This. I could only imagine this to be useful when in need of vastly more ROM than the Cx4 can address itself, or when it's absolutely necessary for the SNES to run from ROM while the Cx4 is working.
IIRC the only real world example that uses such a setup is the SPC7110.
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: Some tidbits about the Cx4 (attn: byuu, nocash)

Post by AWJ »

byuu wrote:
qwertymodo wrote:If I read it right, you can still read and write to the Cx4 itself (i.e. the internal registers) but it no longer passes through reads and writes to the ROM/SRAM. Theoretically, you could have a ROM/RAM dedicated to just the Cx4, and then a separate ROM/RAM for the main cart address space, though you'd probably need a separate address decoder in that case.
I would think that would make the chip useless. If you don't have ROM, you can't load in program cache pages. If you don't have RAM, you don't really have space to write out any results from your code executing. If you don't have either, you have a 20MHz paperweight.
The Cx4 would have ROM, it just wouldn't be visible to the S-CPU (and vice-versa, the S-CPU's ROM wouldn't be visible to the Cx4). It would be a bit similar to the GSU configuration that's described in documents but not used by any actual games, where SNES-only ROM is mapped in the fast banks.
User avatar
ikari_01
Posts: 141
Joined: Sat Jul 04, 2009 2:28 pm
Location: Wunstorf, Germany

Re: Some tidbits about the Cx4 (attn: byuu, nocash)

Post by ikari_01 »

Updated the notes with some feedback, also I got the pins the wrong way around :oops:
Post Reply