Super FX
Super FX is a Super NES enhancement chip developed by Argonaut Games and Nintendo. It's also known as the "Graphical Support Unit" (short for "GSU") for its greater graphical capabilities compared to the S-CPU whereas its first revision, used for Star Fox, uses the name "Mathematical, Argonaut, Rotation, & Input/Output" or short MARIO chip. It also is know for the use in Super Mario World 2: Yoshi's Island.
During this article, GSU refers to Super FX whereas CPU refers to the Super NES CPU.
Features
The embedded co-processor has got a base clock speed of 10.74 MHz which is four times as fast as the S-CPU which uses a base block of 2.68 Mhz. Its features includes but not limited to:
- A RISC-like processor where most opcodes have an instruction size of one byte and are executed in a single cycle when in cache.
- 512 bytes of cache RAM for faster processing of instructions.
- A large memory capactiy, a total capacity of 8 MiB ROM, of which two MiB are shared by CPU and GSU, and 256 KiB RAM, of which 128 KiB are shared by CPU and GSU.
- A separate bus for ROM and RAM to handle memory in parallel
- Paralell processing with the CPU
- Fast Bitmap to Planar conversion
- Pipeline processing to fetch opcodes twice as fast, effectively increasing the processing speed to 21.48 MHz.
Technical Information
Hardware Registers
Super FX comes with various hardware registers of various functions. Most (but not all) of the GSU hardware registers can be accessed from the CPU when the GSU is idling. They are located in the $3000-$3FFF region in banks $00-$3F and $80-$BF.
General Registers (R0-R13)
These registers are more or less equivalent to the A, X and Y registers on the 65c816. They all are parameters to many opcodes, though not all of them are valid (e.g. R0 can't be a parameter for the logical operators), and are all 16-bit. Some of them come with a secondary use for certain opcodes. The CPU can directly read from and write to these registers $3000-$301B.
| Name | Address | Secondary Function |
|---|---|---|
| R0 | $3000 | Default source/destination register. |
| R1 | $3002 | PLOT X position
|
| R2 | $3004 | PLOT Y position
|
| R3 | $3006 | |
| R4 | $3008 | Low word for LMULT result
|
| R5 | $300A | |
| R6 | $300C | Second input for LMULT and FMULT
|
| R7 | $300E | MERGE source 1
|
| R8 | $3010 | MERGE source 2
|
| R9 | $3012 | |
| R10 | $3014 | |
| R11 | $3016 | LINK destination
|
| R12 | $3018 | LOOP counter
|
| R13 | $301A | LOOP start
|
Game Pak ROM Address Pointer (R14)
R14 is the ROM Pointer register and is mapped to $301C-$301D on the SNES. It's the pointer for the GETB opcodes which allows the GSU to read from ROM.
It otherwise acts like any normal general register and is sometimes used as such.
Program Counter (R15)
R15 is the program counter and is mapped to $301E-$301F on the SNES. Unlike on the 65c816 processor, the program counter (excluding the bank) can be directly read or modified within code
as it acts like a general register. This makes it possible to e.g. jump to a certain address without the use of a dedicated opcode.
For example, IWT R15, #xxxx on Super FX is equivalent to JMP $xxxx on the 65c816.
In addition, writing to $301E on the CPU side invokes the GSU.
Status/Flag Register (SFR)
Super FX comes with a 16-bit register of various flags, mostly from calculations (e.g. a carry flag) but also other flags like whether Super FX is currently running. They can be read and written through $3030 and $3031.
| B7 | B6 | B5 | B4 | B3 | B2 | B1 | B0 | |
|---|---|---|---|---|---|---|---|---|
| $3031 | IRQ | - | - | B | IH | IL | ALT1 | ALT2 |
| $3030 | - | R | G | OV | S | CY | Z | - |
| Flag | Description |
|---|---|
| Z | Zero flag, set when result is zero. |
| CY | Carry flag, set at result overflow (unsigned). |
| S | Sign flag, set when number is negative. |
| OV | Overflow flag, set at result overflow (signed). |
| G | Go flag, set when GSU is running. |
| R | Set when reading from ROM. |
| ALT1 | Opcode modifier 1, set when executing ALT1.
|
| ALT2 | Opcode modifier 2, set when executing ALT2.
|
| IL | Immediate lower 8-bit flag. |
| IH | Immediate higher 8-bit flag. |
| B | Set when executing WITH.
|
| IRQ | Interrupt flag, set when GSU stopped. |
Program Bank Register (PBR)
The program bank is the bank where GSU code is executed. It's a readable and writable 8-bit register which is mapped to $3034 on the CPU side.
Unlike R15, this can only be modified indirectly using LJMP on GSU side.
Game Pak ROM Bank Register (ROMBR)
This register controls the bank where ROM is read. It's set using the ROMB on the GSU side.
It's a readable only 8-bit register which is mapped to $3036 on the CPU side.
Game Pak RAM Bank Register (RAMBR)
This register is the RAM equivalent to ROMBR. It's set using the RAMB on the GSU side.
It's a readable only 1-bit register which is mapped to $303C on the CPU side.
Cache Base Register (CBR)
The Cache Base Register is the address where cache has been enabled through and tells the GSU where to run code in cache.
It's readable 16-bit register accessible through $303E and $303F from the CPU and written by the GSU with the CACHE and LJMP opcodes.
The lowest four bits of this register are open bus since cache is stored in 16-byte blocks.
Screen Base Register (SCBR)
The Screen Base Register is the high byte of the image buffer i.e. the plotting destination. It's a writeable 8-bit register mapped to $3038 on the CPU side.
Screen Mode Register (SCMR)
The Screen Mode Register contains the settings for the image buffer (dimensions, bitdepth) but also access to ROM and RAM. It's a writeable 8-bit register mapped to $303A on the CPU side.
| B7 | B6 | B5 | B4 | B3 | B2 | B1 | B0 |
|---|---|---|---|---|---|---|---|
| - | - | HT1 | ROM | RAN | HT0 | MD1 | MD0 |
The image buffer dimensions are given by HT0 and HT1. They all are 256 pixels wide but have different heights. A special case exists when both bits are 1 which enables OBJ mode which is used to plot single sprites like in Yoshi's Island.
| HT1 | H00 | Mode |
|---|---|---|
| 0 | 0 | 256 by 128 |
| 0 | 1 | 256 by 160 |
| 1 | 0 | 256 by 192 |
| 1 | 1 | OBJ mode |
The bitdepth of the image buffer is set by the MD0 and MD1 bits:
| MD1 | MD0 | Mode |
|---|---|---|
| 0 | 0 | 4-color mode (2bpp) |
| 0 | 1 | 16-color mode (4bpp) |
| 1 | 0 | Not used |
| 1 | 1 | 256-color mode (8bpp) |
The SCMR register also controls whether Game Pak ROM and RAM can be accessed by the CPU or GSU:
| Bit | Description |
|---|---|
| RON | Gives ROM access to the CPU when 0 and GSU when 1. |
| RAN | Gives RAM access to the CPU when 0 and GSU when 1. |
Color Register (COLR)
The Color Register contains the colour for the pixel which is to be plotted.
It's an 8-bit register which is set using the COLOR and GETC opcodes on the GSU. There is no access from the CPU.
Plot Option Register (POR)
The Color Register controls how the colours are loaded into the COLR register as well as .
It's an 8-bit register which is set using the CMODE opcode on the GSU. There is no access from the CPU.
| B7 | B6 | B5 | B4 | B3 | B2 | B1 | B0 |
|---|---|---|---|---|---|---|---|
| - | - | - | OBJ | FH | HN | DT | TP |
Note that these abbreviations are inofficial and have been included for simplification.
| Bit | Description |
|---|---|
| OBJ | OBJ Flag |
| FH | Freeze High Flag |
| HN | High Nibble Flag |
| DT | Dither Flag |
| TP | Transparent Flag |
Backup RAM Register (BRAMR)
This controls whether Back-up RAM (not to be confused with Game Pak RAM) becomes “protected”.1 It's a 1-bit register mapped to bit 0 of $3033 which can be written by the CPU.
1The definition of “protected” isn't very clear, though it can be assumed that Back-up RAM can't be written when it's set to be protected.
Version Code Register (VCR)
The Version Code Register contains the version code of the Super FX chip. It's an 8-bit read-only register and accessed $303B on the CPU side.
Config Register (CFGR)
The Config Register contains two flags: The IRQ flag which allows the GSU to fire an interrupt to the CPU should it stop and the MS0 which controls the speed of the multiplication. It's mapped to bit 0 of $3039 and is writeable from the CPU.
Clock Select Register (CLSR)
This register sets the clock speed of Super FX and enables pipelining in the process. When clear, Super FX runs at 10.74 MHz, when set, at 21.48 MHz. It's mapped to bit 0 of $3039 and is writeable from the CPU.
Supposedly, the CLSR and MS0 flags must not be set 1 at the same time but no side effects are known.
Memory and Bus
Memory Map
One advantage of Super FX is that it naturally supports ROMs with a size of up to 8 MiB. However, Super FX can only use the first two MiB of a ROM. Similarly, even though a single cartridge may have up to 256 KiB of SRAM, only half of them can be used by Super FX. As a result, there is a difference between the CPU and GSU mapping.
This is how the ROM is mapped from the perspective of the CPU:
| Banks | Address | Description |
|---|---|---|
| $00-$3F | $0000-$1FFF | WRAM mirror |
| $2100-$21FF | PPU registers | |
| $3000-$3FFF | Super FX registers | |
| $4200-$43FF | CPU registers | |
| $6000-$7FFF | SRAM mirror | |
| $8000-$FFFF | ROM (LoROM) | |
| $40-$5F | $0000-$FFFF | Mirror of ROM in banks $00-$3F (HiROM) |
| $60-$6F | $0000-$FFFF | Unmapped |
| $70-$71 | $0000-$FFFF | SRAM |
| $7C-$7D | $0000-$FFFF | Backup RAM |
| $7E-$7F | $0000-$FFFF | WRAM |
| $80-$BF | $0000-$1FFF | WRAM mirror |
| $2100-$21FF | PPU registers | |
| $3000-$3FFF | Super FX registers | |
| $4200-$43FF | CPU registers | |
| $6000-$7FFF | SRAM mirror | |
| $8000-$FFFF | ROM (LoROM) | |
| $C0-$FF | $8000-$FFFF | ROM (HiROM) |
The GSU memory map looks similar to the CPU mapping but only with access to ROM and SRAM as well as only access to 2 MiB of ROM and 128 KiB of SRAM. As a result, it looks more like this:
| Banks | Address | Description |
|---|---|---|
| $00-$3F | $0000-$7FFF | Unmapped |
| $8000-$FFFF | ROM (LoROM) | |
| $40-$5F | $0000-$FFFF | Mirror of ROM in banks $00-$3F (HiROM) |
| $60-$6F | $0000-$FFFF | Unmapped |
| $70-$71 | $0000-$FFFF | SRAM |
| $72-$7F | $0000-$FFFF | Unmapped |
| $80-$FF | $0000-$FFFF | Mirror of $00-$7F |
Finally, it should be noted that banks $40-$5F are HiROM mirrors of the LoROM banks $00-$3F interlaced so addresses such as $008000 and $400000 contain the same value.
ROM
ROM on Super FX can be up to 8 MiB large. However, even though the size is theoretically doable, the largest published Super FX games had a ROM size of 2 MiBs. As a result, not many emulators (not even BSNES as of 2021) emulate this feature properly and such ROM sizes only exist in homebrewing and modding.
Super FX has also has got limitations with ROM access. This first example is the ROM size. Even though a Super FX ROM can be as large as 8 MiB (in theory), the GSU's data bus is only connected to 2 MiB of it. Said portion of ROM which the processor can access is called GamePak ROM while the additional 6 MiB, called the Super NES ROM, can only be accessed by the CPU. A second limitation is the clock speed. The GSU is clocked very fast at 10,74 Mhz (which can be doubled with pipelining) but ROM is clocked at 3,58 Mhz (unlike on SA-1 where ROM is clocked at the same frequence the coprocessor). As a result, all opcodes, when they are executed in ROM, take at least three cycles to process while reads from ROM are very slow.
To counteract against this limitation, the GSU uses a buffering system. In order to load a value from ROM, the bank must first be set in ROMBR (set by ROMB in the GSU code) while the address is set in register R14. Any write to R14 initiates the buffering process. The value then can be retrieved with GETB and similar opcodes (referred to just GETB from now on).
The GSU doesn't wait during the process of fetching. As a result, it is possible to call GETB some time after writing to R14. In fact, this is even recommend because calling GETB during the process of fetching will cause the GSU to halt up five cycles for executing GETB. Similarly, writing to ROMB will halt the code as well until the data has been fetched enabling cache during the process of fetching will mess up the ROM value instead.
RAM
Cache
In order to improve the speed of the processor, it includes a 512 byte large memory with the same frequency as the GSU as a cache. This allows Super FX to execute a single opcode with only a single cycle (i.e. three times as fast as in regular use). The cache is separated into 32 16-byte blocks, each with a flag which denotes that a block is used, and is indexed by the cache base register (CBR) which is used to keep track of where cache has been invoked. The cache flags and CBR are reset whenever a zero is written to the GO flag but simply halting or invoking the GSU preserves the content of the cache which in turn can be read by the CPU.
Cache on the SNES is mapped to addresses $xx:3100-$xx:32FF ($xx = $00-$3F, $80-$BF), though the start of the cached code (see below) also is dependent on the CBR (start = $3100 + (CBR & 0x1FF)).
There are two methods to fill the cache:
- Manual caching
- Automatic caching
Manual caching involes using the CPU and transfer the code to cache. Keep in mind that Super FX will only execute the cache block which has been set to be used. That means, the code has to be transfered as a full 16 byte block, though strictly speaking, only the last byte of the block (address $XXXF) needs to be written to count the block as used. In order to execute GSU code in cache, R15 has to be set to $0000-$01FF.
Automatic caching is instead handled by the GSU itself. This is handled either by the dedicated CACHE opcode or by a LJMP opcode, the latter because of the lack of bank information for the cache. Both of them clear the cache flags and store the current PC with the lowest nibble masked out into the CBR (CBR = PC & 0xFFF0). Afterwards, each executed opcode will be written into cache starting from CBR & 0x1FF.
As a result, this use of cache is recommend for loops and the first loop will always run slower than the remaining loops. Should all the blocks be used, any remaining code will be left uncached and executed in the original memory.
Another side effect is that cache is neither ROM nor GamePak RAM so any Super FX code in cache can run in parallel to the SNES even when access to ROM and RAM is given to the CPU instead of GSU.
Pipeline Processing
In order to boost the processing speed of the GSU, it uses a technique called "pipeline processing". Pipelining exists to a lesser extend on the 65c816, where opcodes are prepared while the remaining bytes of the opcodes are fetched (this is notable on single byte opcodes such as INC which take two cycles to process, the same amount of cycles as LDA #$xx, a two byte opcode) but the GSU takes it further by fetching the next opcode during the current opcode's execution.
This runs the code double as fast, virtually increasing the clock speed to 21.48 MHz at the cost of adding more care of the coder whenever R15 — the programm counter — is changed, either through branching or through direct writes to R15. In addition, internal processes such as multiplication and memory access can't take advantage of the virtual increment in clock speed.
Pipelining is controlled with bit 0 of CLSR, where clear means pipelining disabled and set means pipelining enabled. It's accessable on the CPU side with the address $3037.
For the most part, having pipelining enabled doesn't change the code. The only exceptions are when R15 is modified outside of fetching opcodes i.e. the use of branches and writes to R15 (e.g. IWT R15,#$8000) as well as halting the GSU such as with STOP. In these cases, the opcode following that instruction will be executed after the branch. A common solution for the unwanted opcode execution is to put a dummy NOP after the R15 modifying opcode such as in this example:
BCC SkipCode NOP ; Dummy NOP ... SkipCode:
This proves to be inefficient, though. Most Super FX opcodes are one byte larger and take 3 or 1 cycles (depending on whether the code is executed in cache or not) to execute including NOP. As a result, opcodes such as SUB R0 can be put as a dummy opcode in place of NOP. The following example demonstrates it:
BCC SkipCode ;NOP ; Redundant SUB R0 ; Set R0 to zero STW (R1) SkipCode: IWT R0,#$1234
In the above code, R0 gets overwritten by SUB no matter whether the branch is taken. However, it later gets overwritten by IWT. As a result, it doesn't matter whether the dummy opcode is a NOP or SUB from the branch for the calculation. In fact, using a NOP increases the code size by one byte which can matter when the code is executed in cache as well as increase the cycle count by 1 or 3 cycles each time the branch is executed, causing in total a minor speed penality.
This doesn't work for every opcode, though. Opcodes such as ADD #x (which is internally prefixed with ALT2), WITH (register prefixes which change which register is the source or destination), BRA $10 (branches which always use two bytes) and IWT (immediate value transfers which use two or three bytes) can only be used as a dummy opcode in very specific circumstances. The latter two can even misalign the program counter not unlike executing LDA #$12 when A is in 16-bit mode on the 65816. The following example demonstrates it:
BCC SkipCode BRA Error ; Caution! ... SkipCode: ... Error: INC R1 ; Will instead be read with the BRA as "BRA $D1".
In addition, the dummy opcode after a STOP must be a NOP because putting the GSU in WAIT will not clear the opcode in the pipeline. Extra care should be taken when pipeliend code is executed and a STOP is located at $XXXF in cache as the pipelined code may be located in unused cache and a value in RAM will be loaded instead.