SnesLab - User contributions [en]

FROM (Super FX)

2024-07-15T12:48:45Z

MarioFanGamer: Added note on execution of MOVES.

{| class="wikitable" style="float:right;clear:right;width:50%"
!colspan="8"|Basic Info
|+
|'''Addressing Mode'''
|'''Opcode'''
|'''Length'''
|'''ROM Speed'''
|'''RAM Speed'''
|'''Cache Speed'''
|+
|[[Implied]] (type 1)
|Bn
|1 byte
|3 cycles
|3 cycles
|1 cycle
|}

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Affected
|+
|[[B Flag|B]]
|[[ALT1]]
|[[ALT2]]
|[[O/V]]
|[[Sign Flag|S]]
|[[CY]]
|[[Zero Flag|Z]]
|+
|.
|.
|.
|.
|.
|.
|.
|}

'''FROM''' is a [[Super FX]] register prefix instruction that specifies the [[source register]]. The exception is when the [[B Flag]] is set (i.e. a [[WITH]] instruction is executed immediately before) in which case a [[MOVES]] is executed instead with FROM acting as the source and WTIH as the destination.[1]

No flags are affected.

==== Syntax ====
<pre>
FROM Rn
</pre>

==== Example ====
To set R2 as the source register, run:
FROM R2

=== See Also ===
* [[TO (Super FX)]]
* [[WITH (Super FX)]]
* [[MOVES (Super FX)]]

=== Notes ===
[1] The information in the developer manual is actually contradictory. The description of FROM claims the transfer happens from Rn (set by FROM) to Dreg (set by WITH) whereas that of MOVES Rn, Rn' claims to transfer from Rn' (set by WITH) to Rn (set by FROM) instead. According to [[fullsnes]], it's the description of MOVES which is wrong.

=== External Links ===
* Official Nintendo documentation on FROM: 9.34 on [https://archive.org/details/SNESDevManual/book2/page/n204 page 2-9-48 of Book II]
* Official Nintendo documentation on Register Prefixes: [https://archive.org/details/SNESDevManual/book2/page/n129 page 2-6-7 of Book II]

[[Category:ASM]]
[[Category:Super FX]]
[[Category:Register Prefix Instructions]]
[[Category:One-byte Instructions]]

MOVE (Super FX)

2024-07-15T12:39:24Z

MarioFanGamer: Added technical details and components of MOVE Rn, Rn'.

{| class="wikitable" style="float:right;clear:right;width:50%"
!colspan="8"|Basic Info
|+
|'''Addressing Mode'''
|'''Opcode'''
|'''Length'''
|'''ROM Speed'''
|'''RAM Speed'''
|'''Cache Speed'''
|+
|
|2n'1n
|2 bytes
|6 cycles
|6 cycles
|2 cycles
|}

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Affected
|+
|[[B Flag|B]]
|[[ALT1]]
|[[ALT2]]
|[[O/V]]
|[[Sign Flag|S]]
|[[CY]]
|[[Zero Flag|Z]]
|+
|0
|0
|0
|.
|.
|.
|.
|}

'''MOVE''' is the name of a [[Super FX]] instruction and macro instructions that moves the value of a register or immediate value into another register or RAM.

The [[ALT0]] state is restored.

==== Syntax ====
<pre>
MOVE Rn, Rn'
MOVE Rn, #xx
MOVE Rn, (xx)
MOVE (xx), Rn
</pre>

==== MOVE Rn, Rn' ====

MOVE Rn, Rn' as a GSU instruction transfers the value from Rn' to Rn. The opcode is strictly speaking an alterantive execution of [[TO]], namely when the [[B flag]] is set i.e. a TO is executed immediately after a [[WITH]]. The register of WITH Rn' is the source and the register of TO Rn is the destination (for this reason, it is safe to assume that the transfer happens from Sreg to Dreg).

As such, the execution of both codes are identical:
<pre>
; R0 = 52BAh
WITH R0
TO R13
; R13 also is now 52BAh

; R0 = 52BAh
WITH R13,R0
; R13 also is now 52BAh
</pre>

==== Example ====
Let:
R14 = 4983h
R8 = 9264h
when MOVE R8, R14 is executed:
R8 = 4983h

=== See Also ===
* [[B flag]]
* [[MOVES]]
* [[MOVEW]]
* [[MOVEB]]
* [[LM]]
* [[LMS]]

=== External Links ===
* Official Super Nintendo development manual on MOVE: 9.57 on [https://archive.org/details/SNESDevManual/book2/page/n237 page 2-9-81 of Book II]
* Official Super Nintendo development manual on TO: 9.57 on [https://archive.org/details/SNESDevManual/book2/page/n277 page 2-9-48 of Book II]

[[Category:ASM]]
[[Category:Super FX]]
[[Category:Data Transfer Instructions]]
[[Category:Macro Instructions]]
[[Category:Two-byte Instructions]]

B Flag (Super FX)

2024-07-15T12:08:35Z

MarioFanGamer: Specified which opcodes the B-flag affects.

The '''B flag''' is on the [[Super FX]], and is set when [[WITH]] runs.

These instructions change their behaviour on the B flag:

* [[TO]] Rn' as [[MOVE]] Rn,Rn'
* [[FROM]] Rn' as [[MOVES]] Rn,Rn'

For both of them, the Rn is set by the preceeeding WITH Rn.

Many instructions clear the B flag, including:

* [[GSU/ADC|ADC]] Rn
* [[GSU/ADC|ADC]] #n
* [[ADD]] Rn
* [[ADD]] #n
* [[GSU/AND|AND]] Rn
* [[GSU/AND|AND]] #n
* [[ASR]]
* [[BIC]] Rn
* [[BIC]] #n
* [[CACHE]]
* [[CMODE]]
* [[GSU/CMP|CMP]] Rn
* [[COLOR]]
* [[GSU/DEC|DEC]] Rn
* [[DIV2]]
* [[FMULT]]
* [[GETB]]
* [[GETBH]]
* [[GETBL]]
* [[GETBS]]
* [[GETC]]
* [[HIB]]
* [[IBT]] Rn, #pp
* [[GSU/INC|INC]] Rn
* [[IWT]] Rn, #xx
* [[GSU/JMP|JMP]] Rn
* [[LDB]] (Rm)
* [[LDW]] (Rm)
* [[LEA]] Rn, xx
* [[LINK]] #n
* [[LJMP]] Rn
* [[LM]] Rn, (xx)
* [[LMS]] Rn, (yy)
* [[LMULT]]
* [[LOB]]
* [[LOOP]]
* [[GSU/LSR|LSR]]
* [[MERGE]]
* [[MOVE]] Rn, Rn'
* [[MOVES]] Rn, Rn'
* [[MULT]] Rn
* [[MULT]] #n
* [[GSU/NOP|NOP]]
* [[NOT]]
* [[OR]] Rn
* [[OR]] #n
* [[PLOT]]
* [[RAMB]]
* [[GSU/ROL|ROL]]
* [[ROMB]]
* [[GSU/ROR|ROR]]
* [[RPIX]]
* [[GSU/SBC|SBC]] Rn
* [[SBK]]
* [[SEX]]
* [[SM]] (xx), Rn
* [[SMS]] (yy), Rn
* [[STB]] (Rm)
* [[STOP]]
* [[STW]] (Rm)
* [[SUB]] Rn
* [[SUB]] #n
* [[SWAP]]
* [[UMULT]] Rn
* and presumably UMULT #n too

=== See Also ===
* [[Dither Flag]]
* [[Break Flag]]
* [[ALT1]]
* [[ALT2]]

=== Reference ===
* [https://archive.org/details/SNESDevManual/book2/page/n158 page 2-9-2 of Book II] of the official Super Nintendo development manual

[[Category:Flags]]
[[Category:Super FX]]
[[Category:ASM]]

WITH (Super FX)

2024-07-04T14:56:42Z

MarioFanGamer: Added opcode information (opcode, size) from fullsnes and a note

{| class="wikitable" style="float:right;clear:right;width:50%"
!colspan="8"|Basic Info
|+
|'''Addressing Mode'''
|'''Opcode'''
|'''Length'''
|'''ROM Speed'''
|'''RAM Speed'''
|'''Cache Speed'''
|+
|
|2n[1]
|1 byte
|
|
|
|}

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Affected
|+
|[[B Flag|B]]
|[[ALT1]]
|[[ALT2]]
|[[O/V]]
|[[Sign Flag|S]]
|[[CY]]
|Z
|+
|1
|
|
|
|
|
|
|}

'''WITH''' is an undocumented{{dubious}} (WITH is mentioned on pages 2-2-8 and 2-6-7 of Book II the Nintendo documentation) [[Super FX]] instruction that sets the register specified by the operand as both the [[source register]] and [[destination register]]. It also sets the B flag which makes it a prefix instruction, more specifically for [[TO]] and [[FROM]] which act like [[MOVE]] and [[MOVES]], respectively, with WITH carrying the source and the modified opcode the destination.

=== Notes ===
[1]The opcode lacks a dedicated description in the developer manual, this information comes from fullsnes instead. Furthermore, one can deduce that WITH is this opcode in that it's explicitely mentioned to be the first byte of the MOVE opcode which '''is''' documented in the manual.

=== See Also ===
* [[TO (Super FX)]]
* [[FROM (Super FX)]]
* [[B Flag]]
* [[MOVE (Super FX)]]
* [[MOVES (Super FX)]]

=== References ===
* ''Comprehensive Super FX ASM Guide'', part C (Basic operations): https://www.smwcentral.net/?p=viewthread&t=81548
* Official Nintendo documentation on Register Prefixes: [https://archive.org/details/SNESDevManual/book2/page/n129 page 2-6-7 of Book II]
* fullsnes, SNES Cart GSU-n CPU JMP and Prefix Opcodes: https://problemkaputt.de/fullsnes.txt

[[Category:ASM]]
[[Category:Super FX]]
[[Category:Register Prefix Instructions]]

GETB (Super FX)

2024-06-30T20:15:48Z

MarioFanGamer: /* See Also */ Added other GET* opcopdes.

{| class="wikitable" style="float:right;clear:right;width:50%"
!colspan="8"|Basic Info
|+
|'''Opcode'''
|'''Length'''
|'''ROM Speed'''
|'''RAM Speed'''
|'''Cache Speed'''
|+
|EF
|1 byte
|3 to 8 cycles
|3 to 9 cycles
|1 to 6 cycle
|}

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Affected
|+
|[[B Flag|B]]
|[[ALT1]]
|[[ALT2]]
|[[O/V]]
|S
|[[CY]]
|Z
|+
|0
|0
|0
|.
|.
|.
|.
|}

'''GETB''' (Get Byte) is a [[Super FX]] instruction that loads one byte from the [[ROM buffer]] into the low byte of the [[destination register]]. The high byte of the destination register is zeroed.

=== See Also ===
* [[GETBH]]
* [[GETBL]]
* [[GETBS]]
* [[GETC]]
* [[ROMB]]

=== External Links ===
* Official Super Nintendo development manual on GETB: 9.35 on [https://archive.org/details/SNESDevManual/book2/page/n205 Page 2-9-49 of Book II]
* example: [https://archive.org/details/SNESDevManual/book2/page/n206 page 2-9-50 of Book II], lbid

[[Category:ASM]]
[[Category:Super FX]]
[[Category:Data Transfer Instructions]]
[[Category:One-byte Instructions]]

TO (Super FX)

2024-06-30T19:09:42Z

MarioFanGamer: Removed code tags from sentence

{| class="wikitable" style="float:right;clear:right;width:50%"
!colspan="8"|Basic Info
|+
|'''Opcode'''
|'''Length'''
|'''ROM Speed'''
|'''RAM Speed'''
|'''Cache Speed'''
|+
|1n
|1 byte
|3 cycles
|3 cycles
|1 cycle
|}

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Affected
|+
|B
|[[ALT1]]
|[[ALT2]]
|[[O/V]]
|S
|[[CY]]
|Z
|+
|.
|.
|.
|.
|.
|.
|.
|}

'''TO''' is a [[Super FX]] register prefix instruction that specifies the [[destination register]]. The exception is when the [[B Flag]] is set (i.e. a [[WITH]] instruction is executed immediately before) in which case a [[MOVE]] is executed instead with WITH acting as the source and TO as the destination.

No flags are affected.

=== See Also ===
* [[FROM (Super FX)]]
* [[WITH (Super FX)]]
* [[MOVE (Super FX)]]

=== External Links ===
* Official Nintendo documentation on TO: [https://archive.org/details/SNESDevManual/book2/page/n277 page 2-9-121 of Book II]
* Official Nintendo documentation on Register Prefixes: [https://archive.org/details/SNESDevManual/book2/page/n129 page 2-6-7 of Book II]

[[Category:ASM]]
[[Category:Super FX]]
[[Category:Register Prefix Instructions]]
[[Category:One-byte Instructions]]

FROM (Super FX)

2024-06-30T19:08:57Z

MarioFanGamer: Added connection to the B Flag and MOVE.

{| class="wikitable" style="float:right;clear:right;width:50%"
!colspan="8"|Basic Info
|+
|'''Opcode'''
|'''Length'''
|'''ROM Speed'''
|'''RAM Speed'''
|'''Cache Speed'''
|+
|Bn
|1 byte
|3 cycles
|3 cycles
|1 cycle
|}

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Affected
|+
|B
|[[ALT1]]
|[[ALT2]]
|[[O/V]]
|S
|[[CY]]
|Z
|+
|.
|.
|.
|.
|.
|.
|.
|}

'''FROM''' is a [[Super FX]] register prefix instruction that specifies the [[source register]]. The exception is when the [[B Flag]] is set (i.e. a [[WITH]] instruction is executed immediately before) in which case a [[MOVES]] is executed instead with WITH acting as the source and FROM as the destination.

No flags are affected.

=== See Also ===
* [[TO (Super FX)]]
* [[WITH (Super FX)]]
* [[MOVES (Super FX)]]

=== External Links ===
* Official Nintendo documentation on FROM: [https://archive.org/details/SNESDevManual/book2/page/n204 Page 2-9-48 of Book II]
* Official Nintendo documentation on Register Prefixes: [https://archive.org/details/SNESDevManual/book2/page/n129 page 2-6-7 of Book II]

[[Category:ASM]]
[[Category:Super FX]]
[[Category:Register Prefix Instructions]]
[[Category:One-byte Instructions]]

TO (Super FX)

2024-06-30T19:06:50Z

MarioFanGamer: Added connection to the B Flag and MOVE.

{| class="wikitable" style="float:right;clear:right;width:50%"
!colspan="8"|Basic Info
|+
|'''Opcode'''
|'''Length'''
|'''ROM Speed'''
|'''RAM Speed'''
|'''Cache Speed'''
|+
|1n
|1 byte
|3 cycles
|3 cycles
|1 cycle
|}

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Affected
|+
|B
|[[ALT1]]
|[[ALT2]]
|[[O/V]]
|S
|[[CY]]
|Z
|+
|.
|.
|.
|.
|.
|.
|.
|}

'''TO''' is a [[Super FX]] register prefix instruction that specifies the [[destination register]]. The exception is when the [[B Flag]] is set (i.e. a [[WITH]] instruction is executed immediately before) in which case a [[MOVE]] is executed instead with <code>WITH</code> acting as the source and <code>TO</code> as the destination.

No flags are affected.

=== See Also ===
* [[FROM (Super FX)]]
* [[WITH (Super FX)]]
* [[MOVE (Super FX)]]

=== External Links ===
* Official Nintendo documentation on TO: [https://archive.org/details/SNESDevManual/book2/page/n277 page 2-9-121 of Book II]
* Official Nintendo documentation on Register Prefixes: [https://archive.org/details/SNESDevManual/book2/page/n129 page 2-6-7 of Book II]

[[Category:ASM]]
[[Category:Super FX]]
[[Category:Register Prefix Instructions]]
[[Category:One-byte Instructions]]

WITH (Super FX)

2024-06-30T19:05:46Z

MarioFanGamer: /* See Also */ Removed (Super FX) from B Flag

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Affected
|+
|B
|[[ALT1]]
|[[ALT2]]
|[[O/V]]
|S
|[[CY]]
|Z
|+
|1
|
|
|
|
|
|
|}

'''WITH''' is an undocumented{{dubious}} (WITH is mentioned on pages 2-2-8 and 2-6-7 of Book II the Nintendo documentation) [[Super FX]] instruction that sets the register specified by the operand as both the [[source register]] and [[destination register]]. It also sets the B flag which makes it a prefix instruction, more specifically for [[TO]] and [[FROM]] which act like [[MOVE]] and [[MOVES]], respectively, with WITH carrying the source and the modified opcode the destination.

=== See Also ===
* [[TO (Super FX)]]
* [[FROM (Super FX)]]
* [[B Flag]]
* [[MOVE (Super FX)]]
* [[MOVES (Super FX)]]

=== References ===
* ''Comprehensive Super FX ASM Guide'', part C (Basic operations): https://www.smwcentral.net/?p=viewthread&t=81548
* Official Nintendo documentation on Register Prefixes: [https://archive.org/details/SNESDevManual/book2/page/n129 page 2-6-7 of Book II]

[[Category:ASM]]
[[Category:Super FX]]
[[Category:Register Prefix Instructions]]

WITH (Super FX)

2024-06-30T19:05:23Z

MarioFanGamer: Added purpose as a register prefix.

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Affected
|+
|B
|[[ALT1]]
|[[ALT2]]
|[[O/V]]
|S
|[[CY]]
|Z
|+
|1
|
|
|
|
|
|
|}

'''WITH''' is an undocumented{{dubious}} (WITH is mentioned on pages 2-2-8 and 2-6-7 of Book II the Nintendo documentation) [[Super FX]] instruction that sets the register specified by the operand as both the [[source register]] and [[destination register]]. It also sets the B flag which makes it a prefix instruction, more specifically for [[TO]] and [[FROM]] which act like [[MOVE]] and [[MOVES]], respectively, with WITH carrying the source and the modified opcode the destination.

=== See Also ===
* [[TO (Super FX)]]
* [[FROM (Super FX)]]
* [[B Flag (Super FX)]]
* [[MOVE (Super FX)]]
* [[MOVES (Super FX)]]

=== References ===
* ''Comprehensive Super FX ASM Guide'', part C (Basic operations): https://www.smwcentral.net/?p=viewthread&t=81548
* Official Nintendo documentation on Register Prefixes: [https://archive.org/details/SNESDevManual/book2/page/n129 page 2-6-7 of Book II]

[[Category:ASM]]
[[Category:Super FX]]
[[Category:Register Prefix Instructions]]

Super FX

2024-06-30T18:20:16Z

MarioFanGamer: /* Status/Flag Register (SFR) */ Clarification that $3030 and $3031 refer to the CPU only.

'''Super FX''' is a [[Super NES]] [[enhancement chip]] developed by [https://en.wikipedia.org/wiki/Argonaut_Games Argonaut Games] and [http://en.wikipedia.org/wiki/Nintendo 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 ==
This embedded co-processor has a base clock speed of '''10.74 MHz''' - four times as fast as the S-CPU, which uses a base block of 2.68 Mhz. Its features include but are 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
* Parallel 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 =

[[File:Super FX System Configuration.png|thumb]]

== 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.

{| class="wikitable"
|+A list of their addresses and their secondary functions
|-
! 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, <code>IWT R15, #xxxx</code> on Super FX is equivalent to <code>JMP $xxxx</code> 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 on the CPU side.

{| class="wikitable"
|+Status/Flag Register bitwise
! !! B7 !! B6 !! B5 !! B4 !! B3 !! B2 !! B1 !! B0
|-
| $3031 || IRQ || - || - || B || IH || IL || ALT1 || ALT2
|-
| $3030 || - || R || G || OV || S || CY || Z || -
|}

{| class="wikitable"
|+Description of Flags
|-
! 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.

{| class="wikitable"
|+Screen Mode Register bitwise
! 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]]''.
{| class="wikitable"
|+Screen Dimensions
|-
! 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:
{| class="wikitable"
|+Screen Mode
|-
! 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:
{| class="wikitable"
|+Screen Mode
|-
! 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 Options Register (POR) ===

The Color Register controls how the colours are loaded into the COLR register as well as how they're drawn onto the buffer.
It's an 8-bit register which is set using the [[CMODE]] opcode on the GSU. There is no access from the CPU.

{| class="wikitable"
|+Screen Mode Register bitwise
! 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.

{| class="wikitable"
|+Description of Screen Mode Register
|-
! 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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
|rowspan="6"|$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
|-
|rowspan="6"|$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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
|rowspan="2"|$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 frequency as 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 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 (it's also this reason it isn't considered a general purpose register even though it can be used as such). The value then can be retrieved with [[GETB]] and similar opcodes (referred to just <code>GETB</code> from now on).

The GSU doesn't wait during the process of fetching. As a result, it is possible to call <code>GETB</code> some time after writing to R14. In fact, this is even recommend because calling <code>GETB</code> during the process of fetching will cause the GSU to halt for up to five cycles for executing <code>GETB</code>. Similarly, writing to <code>ROMB</code> will halt the code as well until the data has been fetched and enabling cache during the process of fetching will mess up the loaded ROM value.

=== 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 <code>LDA #$xx</code>, 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 accessible on the CPU side at 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. <code>IWT R15,#$8000</code>) 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:
<nowiki>BCC SkipCode
NOP ; Dummy NOP
...
SkipCode:</nowiki>

This proves to be inefficient, though. Most Super FX opcodes are one byte large and take 3 or 1 cycles (depending on whether the code is executed in cache or not) to execute including <code>NOP</code>. As a result, opcodes such as <code>SUB R0</code> can be put as a dummy opcode in place of <code>NOP</code>. The following example demonstrates it:
<nowiki>BCC SkipCode
;NOP ; Redundant
SUB R0 ; Set R0 to zero
STW (R1)
SkipCode:
IWT R0,#$1234</nowiki>
In the above code, R0 gets overwritten by <code>SUB</code> no matter whether the branch is taken. However, it later gets overwritten by <code>IWT</code>. As a result, it doesn't matter whether the dummy opcode is a <code>NOP</code> or <code>SUB</code> from the branch for the calculation. In fact, using a <code>NOP</code> 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 <code>ADD #x</code> (opcodes which are internally prefixed with <code>ALTn</code>), <code>WITH</code> (register prefixes which change which register is the source or destination), <code>BRA $10</code> (branches which always use two bytes) and <code>IWT</code> (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 <code>LDA #$12</code> when A is in 16-bit mode on the 65816. The following example demonstrates it:
<nowiki>BCC SkipCode
BRA Error ; Caution!

SkipCode:
INC R1 ; Will instead be read with the BRA as "BRA $D1".
...

Error:</nowiki>
In addition, the dummy opcode after a <code>STOP</code> '''must''' be a <code>NOP</code> 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 <code>STOP</code> is located at $XXXF in cache as the pipelined code may be located in unused cache and a value in ROM/RAM will be loaded instead.

== Bus Conflicts ==
Between both processors, only one of them can acess Game Pak ROM and RAM at a time so memory access must be controlled. Access is set by the SCMR, by the RON and RAN bits with 0 meaning CPU access and 1 meaning GSU access.

For the GSU, it's set to WAIT if it isn't granted access for the respective memory it tries to access (e.g. executing code in ROM, storing to RAM). Once it's granted access, the WAIT status is reset and execution resumes.

For the CPU, illegal memory access is different as it lacks a WAIT state or a comparable feature. For this reason, the processor instead reads garbage values.
The specific values actually depend on the type of memory: For illegal RAM access, the CPU reads from open bus instead but for illegal ROM access, the memory bus provides a dummy byte whose value depends on the lowest nibble of the address instead:
{| class="wikitable"
|-
! Address Low Nibble !! Byte
|-
| 0x0, 0x2, 0x6, 0x8, 0xC || 0x00
|-
| 0x4 || 0x04
|-
| 0xA || 0x08
|-
| 0xE || 0x0C
|-
| Other || 0x01
|}
The main purpose of the dummy data is to handle interrupts where the CPU needs to read from ROM to execute code at the given address. This is why on Super FX ROMs, interrupts point to these specific addresses, all of which are in WRAM:
{| class="wikitable"
|-
! Address !! Interrupt
|-
| $000100 || BRK
|-
| $000104 || COP
|-
| $000108 || NMI
|-
| $00010C || IRQ
|}
The pointers are spaced to leave enough space for a single <code>JML $xxxxxx</code> to jump to the actual interrupt code.
Relatedly, Super FX games upload their interrupt and invoke GSU codes into WRAM and execute them there to handle cases where e.g. an interrupt is fired during GSU execution.

No control exists for cache, it's always assumed to be granted access to the GSU but can be safely accessed by the CPU if the former isn't running.

This limitation specifically applies to Game Pak ROM and RAM; Super NES CPU ROM and Back-Up RAM, neither of which the GSU can access, are excluded from bus conflicts.

== Bitmap Processing ==

== External Links ==

* Patent: https://patentimages.storage.googleapis.com/de/a2/7a/f07754f66f39d9/US5724497.pdf

[[Category:SNES_Hardware]]
[[Category:Integrated Circuits]]
[[Category:Enhancement Chips]]
[[Category:Super FX]]

Super FX

2024-05-08T09:00:24Z

MarioFanGamer: /* Memory Map */ Removed header cells in multi-row cells due to a misunderstanding in table syntax.

'''Super FX''' is a [[Super NES]] [[enhancement chip]] developed by [https://en.wikipedia.org/wiki/Argonaut_Games Argonaut Games] and [http://en.wikipedia.org/wiki/Nintendo 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 ==
This embedded co-processor has a base clock speed of '''10.74 MHz''' - four times as fast as the S-CPU, which uses a base block of 2.68 Mhz. Its features include but are 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
* Parallel 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 =

[[File:Super FX System Configuration.png|thumb]]

== 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.

{| class="wikitable"
|+A list of their addresses and their secondary functions
|-
! 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, <code>IWT R15, #xxxx</code> on Super FX is equivalent to <code>JMP $xxxx</code> 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.

{| class="wikitable"
|+Status/Flag Register bitwise
! !! B7 !! B6 !! B5 !! B4 !! B3 !! B2 !! B1 !! B0
|-
| $3031 || IRQ || - || - || B || IH || IL || ALT1 || ALT2
|-
| $3030 || - || R || G || OV || S || CY || Z || -
|}

{| class="wikitable"
|+Description of Flags
|-
! 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.

{| class="wikitable"
|+Screen Mode Register bitwise
! 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]]''.
{| class="wikitable"
|+Screen Dimensions
|-
! 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:
{| class="wikitable"
|+Screen Mode
|-
! 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:
{| class="wikitable"
|+Screen Mode
|-
! 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 Options Register (POR) ===

The Color Register controls how the colours are loaded into the COLR register as well as how they're drawn onto the buffer.
It's an 8-bit register which is set using the [[CMODE]] opcode on the GSU. There is no access from the CPU.

{| class="wikitable"
|+Screen Mode Register bitwise
! 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.

{| class="wikitable"
|+Description of Screen Mode Register
|-
! 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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
|rowspan="6"|$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
|-
|rowspan="6"|$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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
|rowspan="2"|$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 frequency as 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 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 (it's also this reason it isn't considered a general purpose register even though it can be used as such). The value then can be retrieved with [[GETB]] and similar opcodes (referred to just <code>GETB</code> from now on).

The GSU doesn't wait during the process of fetching. As a result, it is possible to call <code>GETB</code> some time after writing to R14. In fact, this is even recommend because calling <code>GETB</code> during the process of fetching will cause the GSU to halt for up to five cycles for executing <code>GETB</code>. Similarly, writing to <code>ROMB</code> will halt the code as well until the data has been fetched and enabling cache during the process of fetching will mess up the loaded ROM value.

=== 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 <code>LDA #$xx</code>, 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 accessible on the CPU side at 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. <code>IWT R15,#$8000</code>) 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:
<nowiki>BCC SkipCode
NOP ; Dummy NOP
...
SkipCode:</nowiki>

This proves to be inefficient, though. Most Super FX opcodes are one byte large and take 3 or 1 cycles (depending on whether the code is executed in cache or not) to execute including <code>NOP</code>. As a result, opcodes such as <code>SUB R0</code> can be put as a dummy opcode in place of <code>NOP</code>. The following example demonstrates it:
<nowiki>BCC SkipCode
;NOP ; Redundant
SUB R0 ; Set R0 to zero
STW (R1)
SkipCode:
IWT R0,#$1234</nowiki>
In the above code, R0 gets overwritten by <code>SUB</code> no matter whether the branch is taken. However, it later gets overwritten by <code>IWT</code>. As a result, it doesn't matter whether the dummy opcode is a <code>NOP</code> or <code>SUB</code> from the branch for the calculation. In fact, using a <code>NOP</code> 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 <code>ADD #x</code> (opcodes which are internally prefixed with <code>ALTn</code>), <code>WITH</code> (register prefixes which change which register is the source or destination), <code>BRA $10</code> (branches which always use two bytes) and <code>IWT</code> (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 <code>LDA #$12</code> when A is in 16-bit mode on the 65816. The following example demonstrates it:
<nowiki>BCC SkipCode
BRA Error ; Caution!

SkipCode:
INC R1 ; Will instead be read with the BRA as "BRA $D1".
...

Error:</nowiki>
In addition, the dummy opcode after a <code>STOP</code> '''must''' be a <code>NOP</code> 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 <code>STOP</code> is located at $XXXF in cache as the pipelined code may be located in unused cache and a value in ROM/RAM will be loaded instead.

== Bus Conflicts ==
Between both processors, only one of them can acess Game Pak ROM and RAM at a time so memory access must be controlled. Access is set by the SCMR, by the RON and RAN bits with 0 meaning CPU access and 1 meaning GSU access.

For the GSU, it's set to WAIT if it isn't granted access for the respective memory it tries to access (e.g. executing code in ROM, storing to RAM). Once it's granted access, the WAIT status is reset and execution resumes.

For the CPU, illegal memory access is different as it lacks a WAIT state or a comparable feature. For this reason, the processor instead reads garbage values.
The specific values actually depend on the type of memory: For illegal RAM access, the CPU reads from open bus instead but for illegal ROM access, the memory bus provides a dummy byte whose value depends on the lowest nibble of the address instead:
{| class="wikitable"
|-
! Address Low Nibble !! Byte
|-
| 0x0, 0x2, 0x6, 0x8, 0xC || 0x00
|-
| 0x4 || 0x04
|-
| 0xA || 0x08
|-
| 0xE || 0x0C
|-
| Other || 0x01
|}
The main purpose of the dummy data is to handle interrupts where the CPU needs to read from ROM to execute code at the given address. This is why on Super FX ROMs, interrupts point to these specific addresses, all of which are in WRAM:
{| class="wikitable"
|-
! Address !! Interrupt
|-
| $000100 || BRK
|-
| $000104 || COP
|-
| $000108 || NMI
|-
| $00010C || IRQ
|}
The pointers are spaced to leave enough space for a single <code>JML $xxxxxx</code> to jump to the actual interrupt code.
Relatedly, Super FX games upload their interrupt and invoke GSU codes into WRAM and execute them there to handle cases where e.g. an interrupt is fired during GSU execution.

No control exists for cache, it's always assumed to be granted access to the GSU but can be safely accessed by the CPU if the former isn't running.

This limitation specifically applies to Game Pak ROM and RAM; Super NES CPU ROM and Back-Up RAM, neither of which the GSU can access, are excluded from bus conflicts.

== Bitmap Processing ==

== External Links ==

* Patent: https://patentimages.storage.googleapis.com/de/a2/7a/f07754f66f39d9/US5724497.pdf

[[Category:SNES_Hardware]]
[[Category:Integrated Circuits]]
[[Category:Enhancement Chips]]
[[Category:Super FX]]

Cache RAM

2023-11-29T12:16:11Z

MarioFanGamer: Added mapping on the CPU and Super FX category.

'''Cache RAM''' is a region of 512 bytes on the [[Super FX]]. Access to it is six times faster than [[Game Pak ROM]] or [[Game Pak RAM]].1 It is divided into 32 blocks, each block being 16 bytes.2

On the S-CPU, it is mapped to $xx:3100-$xx:32FF ($xx = $00-$3F, $80-$BF).3

=== See Also ===
* [[CACHE]]
* [[LJMP (Super FX)]]

=== References ===
# [https://archive.org/details/SNESDevManual/book2/page/n131 page 2-6-9 of Book II] of the official Super Nintendo development manual
# [https://archive.org/details/SNESDevManual/book2/page/n132 page 2-6-10 of Book II] of the official Super Nintendo development manual
# Cache RAM Access From The Super NES. [https://archive.org/details/SNESDevManual/book2/page/n133 page 2-6-12 of Book II] of the official Super Nintendo development manual
# Execution in Cache RAM. [https://archive.org/details/SNESDevManual/book2/page/n123 page 2-6-1 of Book II] of the official Super Nintendo development manual

[[Category:SNES Hardware]]
[[Category:Super FX]]
[[Category:Address Spaces]]

SBC (Super FX)

2023-11-29T12:10:55Z

MarioFanGamer: Added details like carry flag and subtraction with a constand with carry (or lack thereof)

{| class="wikitable" style="float:right;clear:right;width:40%"
!colspan="8"|Basic Info
|+
|'''Opcode'''
|'''Length'''
|'''ROM Speed'''
|'''RAM Speed'''
|'''Cache Speed'''
|+
|3D6n
|2 bytes
|6 cycles
|6 cycles
|2 cycle
|}

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Affected
|+
|B
|ALT1
|ALT2
|O/V
|S
|CY
|Z
|+
|0
|0
|0
|
|
|
|
|}

'''SBC''' (SuBtract with Carry) is a [[Super FX]] instruction that performs a subtraction with regards to the [[CY|carry flag]].
Unlike [[ADD (Super FX)]], [[ADC (Super FX)]] and [[SUB (Super FX)]], this one can only be used with registers, not with constant values since since the ALT3 version of SUB is a [[CMP (Super FX)]] instead.

=== See Also ===
* [[SBC]]
* [[ADC (Super FX)]]
* [[SUB (Super FX)]]

=== Reference ===
* [https://archive.org/details/SNESDevManual/book2/page/n264 page 2-9-108 of Book II] of the official Super Nintendo development manual

[[Category:ASM]]
[[Category:Super FX]]

SUB (Super FX)

2023-11-29T11:01:49Z

MarioFanGamer: /* See Also */ Replaced SBK (not a subtraction) by CMP and SBC (ALT-opcodes).

{| class="wikitable" style="float:right;clear:right;width:40%"
!colspan="8"|Basic Info
|+
|'''Opcode'''
|'''Length'''
|'''ROM Speed'''
|'''RAM Speed'''
|'''Cache Speed'''
|+
|6n
|1 byte
|3 cycles
|3 cycles
|1 cycle
|}

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Affected
|+
|B
|[[ALT1]]
|[[ALT2]]
|[[O/V]]
|S
|[[CY]]
|Z
|+
|0
|0
|0
|
|
|
|
|}

'''SUB''' is a [[Super FX]] instruction that performs a subtraction.

=== See Also ===
* [[ADD]]
* [[ADC (Super FX)]]
* [[ADC]]
* [[CMP (Super FX)]]
* [[SBC (Super FX)]]

=== External Links ===
* Official Nintendo documentation on SUB: [https://archive.org/details/SNESDevManual/book2/page/n274 page 2-9-118 of Book II]

[[Category:ASM]]
[[Category:Super FX]]
[[Category:Arithmetic Operation Instructions]]

ADC (Super FX)

2023-11-29T11:00:16Z

MarioFanGamer: Fixed opcode for ADC Rn.

{| class="wikitable" style="float:right;clear:right;width:60%"
!colspan="8"|Basic Info
|+
|'''Addressing Mode'''
|'''Opcode'''
|'''Length'''
|'''ROM Speed'''
|'''RAM Speed'''
|'''Cache Speed'''
|+
|
|3D5n
|2 bytes
|6 cycles
|6 cycles
|2 cycle
|+
|[[Immediate]]
|3F5n
|2 bytes
|6 cycles
|6 cycles
|2 cycle
|}

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Affected
|+
|B
|[[ALT1]]
|[[ALT2]]
|[[O/V]]
|S
|[[CY]]
|Z
|+
|0
|0
|0
|
|
|
|
|}

'''ADC''' (Add with carry) is a [[Super FX]] instruction that performs an addition. The [[source register]] is always the first addend. The second addend may be any of the 16 R registers or an immediate value. The third addend is [[CY]]. The sum is stored in the destination register.

=== See Also ===
* [[ADD]]
* [[ADC]]
* [[SUB]]

=== External Links ===
* Official Nintendo documentation on ADC: [https://archive.org/details/SNESDevManual/book2/page/n159 Page 2-9-3 of Book II]

[[Category:ASM]]
[[Category:Super FX]]
[[Category:Arithmetic Operation Instructions]]

FMULT (Super FX)

2023-11-28T18:10:55Z

MarioFanGamer: /* See Also */ Added link to LMULT.

{| class="wikitable" style="float:right;clear:right;width:50%"
!colspan="8"|Basic Info
|+
|'''Opcode'''
|'''Length'''
|'''ROM Speed'''
|'''RAM Speed'''
|'''Cache Speed'''
|+
|9F
|1 byte
|7 or 11 cycles
|7 or 11 cycles
|4 or 8 cycle
|}

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Affected
|+
|B
|[[ALT1]]
|[[ALT2]]
|[[O/V]]
|S
|[[CY]]
|Z
|+
|0
|0
|0
|.
|
|
|
|}

'''FMULT''' is a [[Super FX]] instruction that performs a signed multiplication. The two factors are the [[source register]] and R6. The upper 16 bits of the 32-bit product are stored in the [[destination register]]. Bit 15 of the product is stored in [[CY]]. The lower 15 bits of the product appear to be discarded.

The exact speed depends on the state of the [[CFGR]] register.

R4 cannot serve as the destination register.

=== See Also ===
* [[LMULT]]
* [[UMULT]]
* [[MULT]]

=== External Links ===
* Official Nintendo documentation on FMULT: [https://archive.org/details/SNESDevManual/book2/page/n202 Page 2-9-46 of Book II]

[[Category:ASM]]
[[Category:Super FX]]
[[Category:Arithmetic Operation Instructions]]
[[Category:One-byte Instructions]]

Talk:WITH (Super FX)

2023-11-27T09:41:41Z

MarioFanGamer: Detailed information about WITH and relation with MOVE(S).

== <code>WITH</code> affects <code>FROM</code> and <code>TO</code> and is opcode 2x ==
Though it is missing in Description of Instruction, one can still identify which number <code>WITH</code> is encoded thanks to information on page 2-6-7 (alongside 2-4-4 and 2-6-4 for completion): It mentions that <code>FROM</code> and <code>TO</code> are executed as <code>MOVE</code> and <code>MOVES</code>, respectively, if they follow a <code>WITH</code> thanks to the fact that the former are affected by the B flag and the latter sets it.
Said information also is useful to update [[Super FX Opcode Matrices|GSU opcode matrix]] if with a footnote that you can only deduce it by looking at the binary representation of <code>MOVE</code> and that <code>WITH</code> acts as its prefix opcode (it also allows you to deduce that <code>WITH</code> is the source and <code>FROM</code> or <code>TO</code> the destination). --[[User:MarioFanGamer|MarioFanGamer]] ([[User talk:MarioFanGamer|talk]]) 09:41, 27 November 2023 (UTC)

Emulation Mode Flag

2023-11-17T20:39:43Z

MarioFanGamer: Added relation about RESET and emulation mode.

The '''Emulation Mode flag''' controls whether the [[65c816]] is behaving like a 6502.

When clear, the MPU is in 65c816 native mode.

When set, the MPU is in 6502 emulation mode.

This flag cannot be modified directly and is normally hidden from the programmer. To modify it, use the [[XCE]] instruction to swap its value with the carry flag's value.

The flag is set when a [[RESET]] interrupt is fired. In other words, the CPU always starts in emulation mode at boot and after a reset.

[[Category:SNES Hardware]]
[[Category:ASM]]

forced blank

2023-11-17T20:17:58Z

MarioFanGamer: Added redirect.

#REDIRECT [[Blanking]]

Offset Change Mode

2023-11-17T20:09:28Z

MarioFanGamer: Corrected level number

[[File:touch fuzzy get dizzy still.png|thumb|offset change mode manipulating the ground background layer in stage 1-7 "Touch Fuzzy Get Dizzy" of ''Yoshi's Island'']]

The term '''Offset Change Mode''', also known as '''Offset per Tile''', describes an effect on the [[Super NES]] where the offset of each displayed column of a background tilemap can be overwritten by a different offset. Games such as ''Tetris Attack'' and ''Super Mario World 2: Yoshi's Island'' make use of it.

== Function ==
The Super NES console has got eight modes, numbered from 0 to 7, for displaying background layers, three of them (background modes 2, 4 and 6) supporting Offset Change Mode. In these background modes, the offsets for almost every column can be overwritten by a new value. Said offsets can be applies for both visible background layers in the horizontal and vertical direction.

In these background modes, the tilemap of background layer 3 is repurposed to contain offsets and not tile data. This is especially evident on Mode 2 which is otherwise identical to Mode 1: Two 4bpp backgrounds but only the latter has got three visible background layers. Furthermore, the Super NES is wired to always use background layer 3 for offsets even on Mode 6 which lacks layer 2.

=== Reading an Offset ===
Because an actual background tilemap is used to get the offsets, reading an offset follows similar rules as reading a tile. The formula of the first offset on a 32x32 tilemap looks like this:
<code>(BG3SC & 0xFC << 8) + (BG3VOFS & 0xF8 << 2) + (BG3HOFS & 0xF8 >> 3)</code>
where BG3SC is the value in $2109, BG3VOFS the value in $2112 and BG3HOFS the value in $2111. Because the offsets are affected by BG3VOFS and BG3HOFS, you can make use of a raster interrupt (i.e. [[IRQ]] and [[HDMA]]) to change the BG3 offsets and use a different offset for that portion of the screen.

Furthermore, the Super NES reads from the offset data twice in background modes 2 and 6: First to get a horizontal offset and then again offset by 32 bytes (i.e. a single row of tiles) to get the vertical offset. Mode 4, on the other hand, only allows offsets in one direction, controlled by bit 15 of the offset data.

=== Applying the Offset ===
The real difference comes in the tilemap data. Usually, the tiles use the <code>YXPCCCTT TTTTTTTT</code> format but offsets use the <code>D21---OO OOOOOOOO</code> format where D is the direction (0 = horizontal, 1 = vertical, only applicable in Mode 4), 2 and 1 are the affected background layers (0 = disabled, 1 = enabled) and the O bits are the offsets. Keep in mind that for horizontal offsets, the last three bytes are ignored and taken from the original background offset instead.

== Limitations ==
Besides the limitation of horizontal offsets as well as Mode 4, Offset Change Mode isn't able to apply an offset to the leftmost displayed column. This is because even though Offset Change Mode can change offsets on 32 different columns, there are actually up to 33 columns onscreen. This can be fixed either by masking out the eight leftmost pixels of the screen or treat the original background offset as the 0th column.

=== See Also ===
* [[Mosaic]]

=== References ===
* Official Super Nintendo development manual on Offset Change Mode: [https://archive.org/details/SNESDevManual/book1/page/n77 Page 2-12-1 of Book I]
* [https://archive.org/details/SNESDevManual/book1/page/n207 Appendix 13] on Offset Change Mode
* https://problemkaputt.de/fullsnes.htm#snesppuoffsetpertilemode

=== External Links ===
* Touch Fuzzy Get Dizzy example: https://youtu.be/Pus2I9aPUY4

[[Category:Video]]

Super FX

2023-10-29T20:38:42Z

MarioFanGamer: /* Bus Conflicts */ Added information about memory access and what happens if a processor isn't granted it.

'''Super FX''' is a [[Super NES]] [[enhancement chip]] developed by [https://en.wikipedia.org/wiki/Argonaut_Games Argonaut Games] and [http://en.wikipedia.org/wiki/Nintendo 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 ==
This embedded co-processor has a base clock speed of '''10.74 MHz''' - four times as fast as the S-CPU, which uses a base block of 2.68 Mhz. Its features include but are 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
* Parallel 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.

{| class="wikitable"
|+A list of their addresses and their secondary functions
|-
! 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, <code>IWT R15, #xxxx</code> on Super FX is equivalent to <code>JMP $xxxx</code> 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.

{| class="wikitable"
|+Status/Flag Register bitwise
! !! B7 !! B6 !! B5 !! B4 !! B3 !! B2 !! B1 !! B0
|-
| $3031 || IRQ || - || - || B || IH || IL || ALT1 || ALT2
|-
| $3030 || - || R || G || OV || S || CY || Z || -
|}

{| class="wikitable"
|+Description of Flags
|-
! 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.

{| class="wikitable"
|+Screen Mode Register bitwise
! 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]]''.
{| class="wikitable"
|+Screen Dimensions
|-
! 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:
{| class="wikitable"
|+Screen Mode
|-
! 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:
{| class="wikitable"
|+Screen Mode
|-
! 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 Options Register (POR) ===

The Color Register controls how the colours are loaded into the COLR register as well as how they're drawn onto the buffer.
It's an 8-bit register which is set using the [[CMODE]] opcode on the GSU. There is no access from the CPU.

{| class="wikitable"
|+Screen Mode Register bitwise
! 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.

{| class="wikitable"
|+Description of Screen Mode Register
|-
! 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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
!rowspan="6"|$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
|-
!rowspan="6"|$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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
!rowspan="2"|$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 frequency as 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 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 (it's also this reason it isn't considered a general purpose register even though it can be used as such). The value then can be retrieved with [[GETB]] and similar opcodes (referred to just <code>GETB</code> from now on).

The GSU doesn't wait during the process of fetching. As a result, it is possible to call <code>GETB</code> some time after writing to R14. In fact, this is even recommend because calling <code>GETB</code> during the process of fetching will cause the GSU to halt for up to five cycles for executing <code>GETB</code>. Similarly, writing to <code>ROMB</code> will halt the code as well until the data has been fetched and enabling cache during the process of fetching will mess up the loaded ROM value.

=== 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 <code>LDA #$xx</code>, 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 accessible on the CPU side at 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. <code>IWT R15,#$8000</code>) 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:
<nowiki>BCC SkipCode
NOP ; Dummy NOP
...
SkipCode:</nowiki>

This proves to be inefficient, though. Most Super FX opcodes are one byte large and take 3 or 1 cycles (depending on whether the code is executed in cache or not) to execute including <code>NOP</code>. As a result, opcodes such as <code>SUB R0</code> can be put as a dummy opcode in place of <code>NOP</code>. The following example demonstrates it:
<nowiki>BCC SkipCode
;NOP ; Redundant
SUB R0 ; Set R0 to zero
STW (R1)
SkipCode:
IWT R0,#$1234</nowiki>
In the above code, R0 gets overwritten by <code>SUB</code> no matter whether the branch is taken. However, it later gets overwritten by <code>IWT</code>. As a result, it doesn't matter whether the dummy opcode is a <code>NOP</code> or <code>SUB</code> from the branch for the calculation. In fact, using a <code>NOP</code> 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 <code>ADD #x</code> (opcodes which are internally prefixed with <code>ALTn</code>), <code>WITH</code> (register prefixes which change which register is the source or destination), <code>BRA $10</code> (branches which always use two bytes) and <code>IWT</code> (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 <code>LDA #$12</code> when A is in 16-bit mode on the 65816. The following example demonstrates it:
<nowiki>BCC SkipCode
BRA Error ; Caution!

SkipCode:
INC R1 ; Will instead be read with the BRA as "BRA $D1".
...

Error:</nowiki>
In addition, the dummy opcode after a <code>STOP</code> '''must''' be a <code>NOP</code> 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 <code>STOP</code> is located at $XXXF in cache as the pipelined code may be located in unused cache and a value in ROM/RAM will be loaded instead.

== Bus Conflicts ==
Between both processors, only one of them can acess Game Pak ROM and RAM at a time so memory access must be controlled. Access is set by the SCMR, by the RON and RAN bits with 0 meaning CPU access and 1 meaning GSU access.

For the GSU, it's set to WAIT if it isn't granted access for the respective memory it tries to access (e.g. executing code in ROM, storing to RAM). Once it's granted access, the WAIT status is reset and execution resumes.

For the CPU, illegal memory access is different as it lacks a WAIT state or a comparable feature. For this reason, the processor instead reads garbage values.
The specific values actually depend on the type of memory: For illegal RAM access, the CPU reads from open bus instead but for illegal ROM access, the memory bus provides a dummy byte whose value depends on the lowest nibble of the address instead:
{| class="wikitable"
|-
! Address Low Nibble !! Byte
|-
| 0x0, 0x2, 0x6, 0x8, 0xC || 0x00
|-
| 0x4 || 0x04
|-
| 0xA || 0x08
|-
| 0xE || 0x0C
|-
| Other || 0x01
|}
The main purpose of the dummy data is to handle interrupts where the CPU needs to read from ROM to execute code at the given address. This is why on Super FX ROMs, interrupts point to these specific addresses, all of which are in WRAM:
{| class="wikitable"
|-
! Address !! Interrupt
|-
| $000100 || BRK
|-
| $000104 || COP
|-
| $000108 || NMI
|-
| $00010C || IRQ
|}
The pointers are spaced to leave enough space for a single <code>JML $xxxxxx</code> to jump to the actual interrupt code.
Relatedly, Super FX games upload their interrupt and invoke GSU codes into WRAM and execute them there to handle cases where e.g. an interrupt is fired during GSU execution.

No control exists for cache, it's always assumed to be granted access to the GSU but can be safely accessed by the CPU if the former isn't running.

This limitation specifically applies to Game Pak ROM and RAM; Super NES CPU ROM and Back-Up RAM, neither of which the GSU can access, are excluded from bus conflicts.

== Bitmap Processing ==

== External Links ==

* Patent: https://patentimages.storage.googleapis.com/de/a2/7a/f07754f66f39d9/US5724497.pdf

[[Category:SNES_Hardware]]
[[Category:Integrated Circuits]]
[[Category:Enhancement Chips]]
[[Category:Super FX]]

Super FX

2023-10-20T07:00:14Z

MarioFanGamer: /* Pipeline Processing */ Spelling and error fixes.

'''Super FX''' is a [[Super NES]] [[enhancement chip]] developed by [https://en.wikipedia.org/wiki/Argonaut_Games Argonaut Games] and [http://en.wikipedia.org/wiki/Nintendo 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 ==
This embedded co-processor has a base clock speed of '''10.74 MHz''' - four times as fast as the S-CPU, which uses a base block of 2.68 Mhz. Its features include but are 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
* Parallel 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.

{| class="wikitable"
|+A list of their addresses and their secondary functions
|-
! 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, <code>IWT R15, #xxxx</code> on Super FX is equivalent to <code>JMP $xxxx</code> 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.

{| class="wikitable"
|+Status/Flag Register bitwise
! !! B7 !! B6 !! B5 !! B4 !! B3 !! B2 !! B1 !! B0
|-
| $3031 || IRQ || - || - || B || IH || IL || ALT1 || ALT2
|-
| $3030 || - || R || G || OV || S || CY || Z || -
|}

{| class="wikitable"
|+Description of Flags
|-
! 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.

{| class="wikitable"
|+Screen Mode Register bitwise
! 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]]''.
{| class="wikitable"
|+Screen Dimensions
|-
! 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:
{| class="wikitable"
|+Screen Mode
|-
! 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:
{| class="wikitable"
|+Screen Mode
|-
! 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 Options Register (POR) ===

The Color Register controls how the colours are loaded into the COLR register as well as how they're drawn onto the buffer.
It's an 8-bit register which is set using the [[CMODE]] opcode on the GSU. There is no access from the CPU.

{| class="wikitable"
|+Screen Mode Register bitwise
! 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.

{| class="wikitable"
|+Description of Screen Mode Register
|-
! 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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
!rowspan="6"|$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
|-
!rowspan="6"|$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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
!rowspan="2"|$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 as 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 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 (it's also this reason it isn't considered a general purpose register even though it can be used as such). The value then can be retrieved with [[GETB]] and similar opcodes (referred to just <code>GETB</code> from now on).

The GSU doesn't wait during the process of fetching. As a result, it is possible to call <code>GETB</code> some time after writing to R14. In fact, this is even recommend because calling <code>GETB</code> during the process of fetching will cause the GSU to halt for up to five cycles for executing <code>GETB</code>. Similarly, writing to <code>ROMB</code> will halt the code as well until the data has been fetched and enabling cache during the process of fetching will mess up the loaded ROM value.

=== 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 <code>LDA #$xx</code>, 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 accessible on the CPU side at 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. <code>IWT R15,#$8000</code>) 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:
<nowiki>BCC SkipCode
NOP ; Dummy NOP
...
SkipCode:</nowiki>

This proves to be inefficient, though. Most Super FX opcodes are one byte large and take 3 or 1 cycles (depending on whether the code is executed in cache or not) to execute including <code>NOP</code>. As a result, opcodes such as <code>SUB R0</code> can be put as a dummy opcode in place of <code>NOP</code>. The following example demonstrates it:
<nowiki>BCC SkipCode
;NOP ; Redundant
SUB R0 ; Set R0 to zero
STW (R1)
SkipCode:
IWT R0,#$1234</nowiki>
In the above code, R0 gets overwritten by <code>SUB</code> no matter whether the branch is taken. However, it later gets overwritten by <code>IWT</code>. As a result, it doesn't matter whether the dummy opcode is a <code>NOP</code> or <code>SUB</code> from the branch for the calculation. In fact, using a <code>NOP</code> 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 <code>ADD #x</code> (opcodes which are internally prefixed with <code>ALTn</code>), <code>WITH</code> (register prefixes which change which register is the source or destination), <code>BRA $10</code> (branches which always use two bytes) and <code>IWT</code> (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 <code>LDA #$12</code> when A is in 16-bit mode on the 65816. The following example demonstrates it:
<nowiki>BCC SkipCode
BRA Error ; Caution!

SkipCode:
INC R1 ; Will instead be read with the BRA as "BRA $D1".
...

Error:</nowiki>
In addition, the dummy opcode after a <code>STOP</code> '''must''' be a <code>NOP</code> 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 <code>STOP</code> is located at $XXXF in cache as the pipelined code may be located in unused cache and a value in ROM/RAM will be loaded instead.

== Bus Conflicts ==

== Bitmap Processing ==

== External Links ==

* Patent: https://patentimages.storage.googleapis.com/de/a2/7a/f07754f66f39d9/US5724497.pdf

[[Category:SNES_Hardware]]
[[Category:Integrated Circuits]]
[[Category:Enhancement Chips]]
[[Category:Super FX]]

Super FX

2023-10-20T06:51:29Z

MarioFanGamer: /* ROM */ Spelling errors and details.

'''Super FX''' is a [[Super NES]] [[enhancement chip]] developed by [https://en.wikipedia.org/wiki/Argonaut_Games Argonaut Games] and [http://en.wikipedia.org/wiki/Nintendo 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 ==
This embedded co-processor has a base clock speed of '''10.74 MHz''' - four times as fast as the S-CPU, which uses a base block of 2.68 Mhz. Its features include but are 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
* Parallel 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.

{| class="wikitable"
|+A list of their addresses and their secondary functions
|-
! 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, <code>IWT R15, #xxxx</code> on Super FX is equivalent to <code>JMP $xxxx</code> 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.

{| class="wikitable"
|+Status/Flag Register bitwise
! !! B7 !! B6 !! B5 !! B4 !! B3 !! B2 !! B1 !! B0
|-
| $3031 || IRQ || - || - || B || IH || IL || ALT1 || ALT2
|-
| $3030 || - || R || G || OV || S || CY || Z || -
|}

{| class="wikitable"
|+Description of Flags
|-
! 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.

{| class="wikitable"
|+Screen Mode Register bitwise
! 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]]''.
{| class="wikitable"
|+Screen Dimensions
|-
! 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:
{| class="wikitable"
|+Screen Mode
|-
! 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:
{| class="wikitable"
|+Screen Mode
|-
! 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 Options Register (POR) ===

The Color Register controls how the colours are loaded into the COLR register as well as how they're drawn onto the buffer.
It's an 8-bit register which is set using the [[CMODE]] opcode on the GSU. There is no access from the CPU.

{| class="wikitable"
|+Screen Mode Register bitwise
! 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.

{| class="wikitable"
|+Description of Screen Mode Register
|-
! 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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
!rowspan="6"|$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
|-
!rowspan="6"|$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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
!rowspan="2"|$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 as 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 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 (it's also this reason it isn't considered a general purpose register even though it can be used as such). The value then can be retrieved with [[GETB]] and similar opcodes (referred to just <code>GETB</code> from now on).

The GSU doesn't wait during the process of fetching. As a result, it is possible to call <code>GETB</code> some time after writing to R14. In fact, this is even recommend because calling <code>GETB</code> during the process of fetching will cause the GSU to halt for up to five cycles for executing <code>GETB</code>. Similarly, writing to <code>ROMB</code> will halt the code as well until the data has been fetched and enabling cache during the process of fetching will mess up the loaded ROM value.

=== 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 <code>LDA #$xx</code>, 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. <code>IWT R15,#$8000</code>) 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:
<nowiki>BCC SkipCode
NOP ; Dummy NOP
...
SkipCode:</nowiki>

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 <code>NOP</code>. As a result, opcodes such as <code>SUB R0</code> can be put as a dummy opcode in place of <code>NOP</code>. The following example demonstrates it:
<nowiki>BCC SkipCode
;NOP ; Redundant
SUB R0 ; Set R0 to zero
STW (R1)
SkipCode:
IWT R0,#$1234</nowiki>
In the above code, R0 gets overwritten by <code>SUB</code> no matter whether the branch is taken. However, it later gets overwritten by <code>IWT</code>. As a result, it doesn't matter whether the dummy opcode is a <code>NOP</code> or <code>SUB</code> from the branch for the calculation. In fact, using a <code>NOP</code> 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 <code>ADD #x</code> (which is internally prefixed with [[ALT2]]), <code>WITH</code> (register prefixes which change which register is the source or destination), <code>BRA $10</code> (branches which always use two bytes) and <code>IWT</code> (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 <code>LDA #$12</code> when A is in 16-bit mode on the 65816. The following example demonstrates it:
<nowiki>BCC SkipCode
BRA Error ; Caution!
...
SkipCode:
...
Error:
INC R1 ; Will instead be read with the BRA as "BRA $D1".</nowiki>
In addition, the dummy opcode after a <code>STOP</code> '''must''' be a <code>NOP</code> 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 <code>STOP</code> is located at $XXXF in cache as the pipelined code may be located in unused cache and a value in ROM/RAM will be loaded instead.

== Bus Conflicts ==

== Bitmap Processing ==

== External Links ==

* Patent: https://patentimages.storage.googleapis.com/de/a2/7a/f07754f66f39d9/US5724497.pdf

[[Category:SNES_Hardware]]
[[Category:Integrated Circuits]]
[[Category:Enhancement Chips]]
[[Category:Super FX]]

Mode 4

2023-07-19T18:49:18Z

MarioFanGamer: Added another property of Mode 4.

{| class="wikitable" style="float:right;clear:right;width:40%"
!colspan="4"|Layers Available
|+
| [[Layer 2]] || [[Layer 1]]
|+
| 2bpp || 8bpp
|}

'''Mode 4''' supports [[Offset Change Mode]] and [[Direct Color]].

=== See Also ===
{| class="wikitable"
!colspan="4"|Other Background Modes
|+
| [[Mode 0]] || [[Mode 1]] || [[Mode 2]] || [[Mode 3]]
|+
| [[Mode 4]] || [[Mode 5]] || [[Mode 6]] || [[Mode 7]]
|}

=== Reference ===
* https://nesdoug.com/2022/05/30/other-modes

[[Category:Video]]

IBT

2023-05-06T09:57:09Z

MarioFanGamer: Added description for high byte, added category.

'''IBT''' is a [[Super FX]] instruction that loads an immediate value into a specified register. Its upper eight bits will be set to the same value as bit 7, effectively loading a signed 8-bit value.

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Clobbered
|+
|B
|ALT1
|ALT2
|O/V
|S
|CY
|Z
|+
|0
|0
|0
|.
|.
|.
|.
|}

=== See Also ===
* [[IWT]]
* [[LDA]]

[[Category:ASM]]
[[Category:Enhancement Chips]]
[[Category:GSU_Control_Instructions]]

BLT (Super FX)

2023-05-06T09:40:48Z

MarioFanGamer: Removed redirect, added proper description.

'''BLT''' (Branch if Less Than ) is a [[Super FX]] opcode that performs a jump if the [[negative flag]] is unequal to the [[O/V]] flag, effectively checking for a signed less-than comparison (compare [[BCC]] which is an unsigned less-than comparison).

{| class="wikitable" style="float:right;clear:right;width:40%"
!colspan="8"|Basic Info
|+
|'''Opcode'''
|'''Length'''
|'''ROM Speed'''
|'''RAM Speed'''
|'''Cache Speed'''
|+
|06
|2 bytes
|6 cycles
|6 cycles
|2 cycles
|}

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Clobbered
|+
|B
|ALT1
|ALT2
|O/V
|S
|CY
|Z
|+
|0
|0
|0
|.
|.
|.
|.
|}

=== See also ===
* [[BGE]]
* [[BCC]]

[[Category:ASM]]
[[Category:Super FX]]
[[Category:GSU Control Instructions]]

BGE (Super FX)

2023-05-06T09:39:25Z

MarioFanGamer: Removed redirect, added proper description.

'''BGE''' (Branch if Greater or Equal) is a [[Super FX]] opcode that performs a jump if the [[negative flag]] is equal to the [[O/V]] flag, effectively checking for a signed greater-equal comparison (compare [[BCS]] which is an unsigned greater-equal comparison).

{| class="wikitable" style="float:right;clear:right;width:40%"
!colspan="8"|Basic Info
|+
|'''Opcode'''
|'''Length'''
|'''ROM Speed'''
|'''RAM Speed'''
|'''Cache Speed'''
|+
|07
|2 bytes
|6 cycles
|6 cycles
|2 cycles
|}

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Clobbered
|+
|B
|ALT1
|ALT2
|O/V
|S
|CY
|Z
|+
|0
|0
|0
|.
|.
|.
|.
|}

=== See also ===
* [[BLT]]
* [[BCS]]

[[Category:ASM]]
[[Category:Super FX]]
[[Category:GSU Control Instructions]]

SMW level data format

2023-05-06T07:12:42Z

MarioFanGamer: Fixed more formatting and turned text-tables into Wiki tables.

This article contains information about how levels are stored in [[Super Mario World]].

== Pointer tables ==

{| class="wikitable"
|-
! Address !! Usage !! Amount !! Bytes per level !! Total bytes
|-
| x2E200/$05E000 || Layer 1 data || 0x200 levels || 3 bytes || 1,536 bytes
|-
| x2E800/$05E600 || Layer 2 data || 0x200 levels || 3* bytes || 1,536 bytes
|-
| x2EE00/$05EC00 || Sprite data || 0x200 levels || 2** bytes || 1,024 bytes
|}

<nowiki>*)</nowiki> Layer 2 BG only uses the two lower bytes. The upper byte should be FF. The backgrounds are stored in bank 0C. 
<nowiki>**)</nowiki> The sprite data is located in bank 07. 

== Primary level header ==

The first five bytes of the Layer 1 data is the primary level header.

{| class="wikitable"
|-
! First !! Second !! Third !! Fourth !! Last
|-
| BBBLLLLL || CCCOOOOO || 3MMMSSSS || TTPPPFFF || IIVVZZZZ
|}

{| class="wikitable"
|-
! Bits !! Description
|-
| BBB || BG palette
|-
| LLLLL || Length of level (amount of screens)
|-
| CCC || BG color
|-
| OOOOO || Level mode
|-
| 3 || Layer 3 Priority
|-
| MMM || Music
|-
| SSSS || Sprite set
|-
| TT || Time
|-
| PPP || Sprite palette
|-
| FFF || FG palette
|-
| II || Item memory
|-
| VV || Vertical scroll
|-
| ZZZZ || Tile set
|}

== Secondary level header ==

The secondary level header consists of four bytes (These four bytes are not stored together):
* Location of Byte 1: x2F200/$05F000 + level number
* Location of Byte 2: x2F400/$05F200 + level number
* Location of Byte 3: x2F600/$05F400 + level number
* Location of Byte 4: x2F800/$05F600 + level number

{| class="wikitable"
|-
! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4
|-
| SSSSYYYY || 33TTTXXX || MMMMFFBB || IUVEEEEE
|}

{| class="wikitable"
|-
! Bits !! Description
|-
| SSSS || Layer 2 scroll settings
|-
| YYYY || Level entrance Y position
|-
| 33 || Layer 3 settings
|-
| TTT || Level entrance type
|-
| XXX || Level entrance X position
|-
| MMMM || Level entrance midway screen
|-
| FF || Level entrance FG init position
|-
| BB || Level entrance BG init position
|-
| I || Disable no-Yoshi intro flag
|-
| U || Unknown vertical position flag
|-
| V || Vertical positioning flag
|-
| EEEEE || Level entrance screen number
|}

=== Sprite header ===

The sprite header is the first byte of sprite data.

{| class="wikitable"
|-
! Byte
|-
| SBMMMMMM
|}

{| class="wikitable"
|-
! Bits !! Header text
|-
| S || Sprite buoyancy
|-
| B || Sprite buoyancy (no sprite-L2 interaction)
|-
| MMMMMM || Sprite memory*
|}

<nowiki>*)</nowiki> Values up to 0x3F are possible, but only up to 0x12 are valid according to Lunar Magic.

== Layer 1 ==

(Note that Direct Map16 is not documented, as it's a feature added by Lunar Magic)
 
The Layer 1 data begins with the primary level header, followed by the actual Layer 1 data. Each block is three bytes long, with the exception of the screen exit objects.

=== Standard objects ===

{| class="wikitable"
|-
! First !! Second !! Last
|-
| NBBYYYYY || bbbbXXXX || SSSSSSSS
|}

{| class="wikitable"
|-
! Bits !! Descripton
|-
| N || New Screen flag
|-
| BBbbbb || Object number
|-
| YYYYY || Y position
|-
| XXXX || X position
|-
| SSSSSSSS || Settings byte
|}

(Note: The first byte being FF marks the end of the data)

{| class="wikitable"
|-
! Num !! Descripton || Settings Byte
|-
| 00 || (Extended Objects) || Extended object number
|-
| 01 || Water (Blue) || {Height},{Width}
|-
| 02 || Invisible coin blocks || {Height},{Width}
|-
| 03 || Invisible note blocks || {Height},{Width}
|-
| 04 || Invisible POW coins || {Height},{Width}
|-
| 05 || Coins || {Height},{Width}
|-
| 06 || Walk-through dirt || {Height},{Width}
|-
| 07 || Water (Other color) || {Height},{Width}
|-
| 08 || Note blocks || {Height},{Width}
|-
| 09 || Turn blocks || {Height},{Width}
|-
| 0A || Coin ? blocks || {Height},{Width}
|-
| 0B || Throw blocks || {Height},{Width}
|-
| 0C || Black piranha plants || {Height},{Width}
|-
| 0D || Cement blocks || {Height},{Width}
|-
| 0E || Brown blocks || {Height},{Width}
|-
| 0F || Vertical pipes || {Height},{Type}
|-
| 10 || Horizontal pipes || {Type},{Width}
|-
| 11 || Bullet shooter || {Height},{Unused}
|-
| 12 || Slopes || {Height},{Type}
|-
| 13 || Ledge edges || {Height},{Type}
|-
| 14 || Ground ledge || {Height},{Width}
|-
| 15 || Midway/Goal point || {Height},{Type}
|-
| 16 || Blue coins || {Height},{Width}
|-
| 17 || Rope/Clouds || {Type},{Width}
|-
| 18 || Water surface (ani) || {Height},{Width}
|-
| 19 || Water surface (not ani) || {Height},{Width}
|-
| 1A || Lava surface (ani) || {Height},{Width}
|-
| 1B || Net top edge || {Height},{Width}
|-
| 1C || Donut bridge || {Unused},{Width}
|-
| 1D || Net bottom edge || {Height},{Width}
|-
| 1E || Net vertical edge || {Height},{Type}
|-
| 1F || Vert. Pipe/Bone/Log || {Height},{Unused}
|-
| 20 || Horiz. Pipe/Bone/Log || {Unused},{Width}
|-
| 21 || Long ground ledge || Width
|-
| 22 || Special - Used by LM ||
|-
| 23 || Special - Used by LM ||
|-
| 24 || Special - Used by LM ||
|-
| 25 || Special - Used by LM ||
|-
| 26 || Special - Used by LM ||
|-
| 27 || Special - Used by LM ||
|-
| 28 || Special - Used by LM ||
|-
| 29 || Special - Reserved ||
|-
| 2A || Special - Reserved ||
|-
| 2B || Special - Reserved ||
|-
| 2C || Special - Reserved ||
|-
| 2D || Special - Used by LM ||
|-
| 2E || Tileset Specific 1 ||
|-
| 2F || Tileset Specific 2 ||
|-
| 30 || Tileset Specific 3 ||
|-
| 31 || Tileset Specific 4 ||
|-
| 32 || Tileset Specific 5 ||
|-
| 33 || Tileset Specific 6 ||
|-
| 34 || Tileset Specific 7 ||
|-
| 35 || Tileset Specific 8 ||
|-
| 36 || Tileset Specific 9 ||
|-
| 37 || Tileset Specific 10 ||
|-
| 38 || Tileset Specific 11 ||
|-
| 39 || Tileset Specific 12 ||
|-
| 3A || Tileset Specific 13 ||
|-
| 3B || Tileset Specific 14 ||
|-
| 3C || Tileset Specific 15 ||
|-
| 3D || Tileset Specific 16 ||
|-
| 3E || Tileset Specific 17 ||
|-
| 3F || Tileset Specific 18 ||
|}

Note: Most objects separate their nibbles into upper and lower bytes with separate functions. They're specified as {Upper Nibble},{Lower Nibble} in this table.

=== Extended objects ===

(Standard object 00)

{| class="wikitable"
|-
! First !! Second !! Last
|-
| N00YYYYY || 0000XXXX || BBBBBBBB
|}

{| class="wikitable"
|-
! Bits !! Description
|-
| N || New Screen flag
|-
| YYYYY || Y position
|-
| XXXX || X position
|-
| BBBBBBBB || Extended object number
|}

{| class="wikitable"
|-
! Num || Desc
|-
| 00 ||Special - Screen Exit
|-
| 01 || Special - Screen Jump
|-
| 02-0F || Unused?
|-
| 10 || Small door
|-
| 11 || Invisible ? block (1-UP)
|-
| 12 || Invisible note block
|-
| 13 || Top left corner edge tile 1
|-
| 14 || Top right corner edge tile 1
|-
| 15 || Small POW door
|-
| 16 || Invisible POW ? block
|-
| 17 || Green star block
|-
| 18 || 3-UP moon
|-
| 19 || Invisible 1-UP #1
|-
| 1A || Invisible 1-UP #2
|-
| 1B || Invisible 1-UP #3
|-
| 1C || Invisible 1-UP #4
|-
| 1D || Red berry
|-
| 1E || Pink berry
|-
| 1F || Green berry
|-
| 20 || Always turning block
|-
| 21 || Bottom right of midway point (unused)
|-
| 22 || Bottom right of midway point (unused)
|-
| 23 || Note block (flower/feather/star)
|-
| 24 || ON/OFF block
|-
| 25 || Direction coins ? block
|-
| 26 || Note block
|-
| 27 || Note block, bounce on all sides
|-
| 28 || Turn block (Flower)
|-
| 29 || Turn block (Feather)
|-
| 2A || Turn block (Star)
|-
| 2B || Turn block (Star 2/1-UP/Vine)
|-
| 2C || Turn block (Multiple coins)
|-
| 2D || Turn block (Coin)
|-
| 2E || Turn block (Nothing)
|-
| 2F || Turn block (POW)
|-
| 30 || ? block (Flower)
|-
| 31 || ? block (Feather)
|-
| 32 || ? block (Star)
|-
| 33 || ? block (Star 2)
|-
| 34 || ? block (Multiple coins)
|-
| 35 || ? block (Key/Wings/Balloon/Shell)
|-
| 36 || ? block (Yoshi)
|-
| 37 || ? block (Shell)
|-
| 38 || ? block (Shell)
|-
| 39 || Turn block, unbreakable (Feather)
|-
| 3A || Top left corner edge tile 2
|-
| 3B || Top right corner edge tile 2
|-
| 3C || Top left corner edge tile 3
|-
| 3D || Top right corner edge tile 3
|-
| 3E || Top left corner edge tile 4
|-
| 3F || Top right corner edge tile 4
|-
| 40 || Transculent block
|-
| 41 || Yoshi Coin
|-
| 42 || Top left slope
|-
| 43 || Top right slope
|-
| 44 || Purple triangle, left
|-
| 45 || Purple triangle, right
|-
| 46 || Midway point rope
|-
| 47 || Door
|-
| 48 || Invisible POW door
|-
| 49 || Ghost house exit
|-
| 4A || Climbing net door
|-
| 4B || Conveyor end tile 1
|-
| 4C || Conveyor end tile 2
|-
| 4D || Line guide, top left 1/4 large circle
|-
| 4E || Line guide, top right 1/4 large circle
|-
| 4F || Line guide, bottom left 1/4 large circle
|-
| 50 || Line guide, bottom right 1/4 large circle
|-
| 51 || Line guide, top left 1/4 small circle
|-
| 52 || Line guide, top right 1/4 small circle
|-
| 53 || Line guide, bottom left 1/4 small circle
|-
| 54 || Line guide, bottom right 1/4 small circle
|-
| 55 || Line guide end, for horizontal line
|-
| 56 || Line guide end, for vertical line
|-
| 57 || Switch palace bottom right corner tile
|-
| 58 || Switch palace bottom left corner tile
|-
| 59 || Switch palace top right corner tile
|-
| 5A || Switch palace top left corner tile
|-
| 5B || Bit of brick background tile 1
|-
| 5C || Bit of brick background tile 2
|-
| 5D || Bit of brick background tile 3
|-
| 5E || Bit of brick background tile 4
|-
| 5F || Large background area
|-
| 60 || Lava/mud top right corner edge
|-
| 61 || Ghost house clock
|-
| 62 || Ghost house top left to bottom right beam 1
|-
| 63 || Ghost house top right to bottom left beam 1
|-
| 64 || Ghost house cobweb, top right
|-
| 65 || Ghost house cobweb, top left
|-
| 66 || Ghost house top right to bottom left beam 2
|-
| 67 || Ghost house top left to bottom right beam 2
|-
| 68 || Cloud fringe, bottom and right edge
|-
| 69 || Cloud fringe, bottom and left edge
|-
| 6A || Cloud fringe, bottom right
|-
| 6B || Cloud fringe, bottom left
|-
| 6C || Cloud fringe on white, bottom and right edge
|-
| 6D || Cloud fringe on white, bottom and left edge
|-
| 6E || Cloud fringe on white, bottom right
|-
| 6F || Cloud fringe on white, bottom left
|-
| 70 || Bit of canvass 1
|-
| 71 || Canvass 1
|-
| 72 || Canvass 2
|-
| 73 || Canvass 3
|-
| 74 || Canvass 4
|-
| 75 || Canvass tile 1
|-
| 76 || Canvass tile 2
|-
| 77 || Canvass tile 3
|-
| 78 || Canvass tile 4
|-
| 79 || Canvass tile 5
|-
| 7A || Canvass tile 6
|-
| 7B || Canvass tile 7
|-
| 7C || Bit of canvas 2
|-
| 7D || Bit of canvas 3
|-
| 7E || Bit of canvas 4
|-
| 7F || Torpedo launcher
|-
| 80 || Ghost house entrance
|-
| 81 || Water weed
|-
| 82 || Big bush 1
|-
| 83 || Big bush 2
|-
| 84 || Castle entrance
|-
| 85 || Yoshi's house
|-
| 86 || Arrow sign
|-
| 87 || ! block, green
|-
| 88 || Tree branch, left
|-
| 89 || Tree branch, right
|-
| 8A || Switch, green
|-
| 8B || Switch, yellow
|-
| 8C || Switch, blue
|-
| 8D || Switch, red
|-
| 8E || ! block, yellow
|-
| 8F || Ghost house window
|-
| 90 || Boss door
|-
| 91 || Steep left slope (vert. lev.)
|-
| 92 || Steep right slope (vert. lev.)
|-
| 93 || Normal left slope (vert. lev.)
|-
| 94 || Normal right slope (vert. lev.)
|-
| 95 || Very steep left slope (vert. lev.)
|-
| 96 || Very steep right slope (vert. lev.)
|-
| 97 || Switch palace right and bottom edge tile
|-
| 98-FF || Unused?
|}

=== Screen exits ===

(Extended object 00)

{| class="wikitable"
|-
! First !! Second !! Third !! Last
|-
| 000PPPPP || 0000WUSH || 00000000 || DDDDDDDD
|}

{| class="wikitable"
|-
! Bits !! Page number
|-
| PPPPP || Example
|-
| W || Water (secondary exit)
|-
| U || Secondary Exit? *
|-
| S || Secondary Exit
|-
| H || Unused **
|-
| DDDDDDDD || Lower 8 bits of destination level
|}

Creates a screen exit. Should be placed right before the end of the level.

<nowiki>*)</nowiki> Used by a Lunar Magic ASM hack: If set, the H bit will be used
 
<nowiki>**)</nowiki> Used by a Lunar Magic ASM hack: High bit of destination level (only if the U bit is set)

=== Screen jump ===

(Extended object 01)

{| class="wikitable"
|-
! First !! Second !! Last
|-
| 000PPPPP || 0000???? || 00000001
|}

{| class="wikitable"
|-
! Bit !! Description
|-
| PPPPP || Page to jump to
|-
| ???? || Unused?
|}

The loading routine jumps to another screen.

== Layer 2 ==
=== Background ===

Layer 2 backgrounds are compressed using a simple RLE system.

A background consists of any number of "lines". There are two types: Normal line and RLE line

Each line begins with a start byte. The highest bit decides what kind of line it is (0 = Normal, 1 = RLE). The other 7 bits are the "length" setting, which is the amount of tiles in the line minus 1.

A normal line is then followed by (length+1) bytes, each being a tile in the background. An RLE line is only followed by a single byte which is repeated (length+1) times.

The entire left half of the background is stored first, followed by the entire right half.

The line "FFFF" marks the end of the data.

=== Level ===

Layer 2 levels are stored in exactly the same way as Layer 1. The five byte header is there as well, but doesn't seem to be used.

== Sprites ==

The first byte of the sprite data is the sprite header. Each sprite is three bytes long.

{| class="wikitable"
|-
! First !! Second !! Last
|-
| YYYYEEsy || XXXXSSSS || NNNNNNNN
|}

{| class="wikitable"
|-
! Bits !! Description
|-
! yYYYY || Y position
|-
| EE || Extra bits
|-
| XXXX || X position
|-
| sSSSS || Screen number
|-
| NNNNNNNN || Enemy number
|}

(Note: The first byte being FF marks the end of the data)

== Secondary entrances ==

(Not yet documented.)

[[Category:Super Mario World]]

SMW level data format

2023-05-05T18:50:12Z

MarioFanGamer: Added table formatting to most tables, removed some unwanted formattings.

This article contains information about how levels are stored in [[Super Mario World]].

== Pointer tables ==

x2E200/$05E000 Layer 1 data 0x200 levels, 3 bytes each. (1,536 bytes)
x2E800/$05E600 Layer 2 data 0x200 levels, 3* bytes each. (1,536 bytes)
x2EE00/$05EC00 Sprite data 0x200 levels, 2** bytes each. (1,024 bytes)

<nowiki>*)</nowiki> Layer 2 BG only uses the two lower bytes. The upper byte should be FF.
The backgrounds are stored in bank 0C.
<nowiki>**)</nowiki> The sprite data is located in bank 07.

== Primary level header ==

The first five bytes of the Layer 1 data is the primary level header.

{| class="wikitable"
|-
! First !! Second !! Third !! Fourth !! Last
|-
| BBBLLLLL || CCCOOOOO || 3MMMSSSS || TTPPPFFF || IIVVZZZZ
|}

BBB =BG palette
LLLLL =Length of level (amount of screens)
CCC =BG color
OOOOO =Level mode
3 =Layer 3 Priority
MMM =Music
SSSS =Sprite set
TT =Time
PPP =Sprite palette
FFF =FG palette
II =Item memory
VV =Vertical scroll
ZZZZ =Tile set

== Secondary level header ==

The secondary level header consists of four bytes.
(These four bytes are not stored together)
Location of Byte 1: x2F200/$05F000 + level number
Location of Byte 2: x2F400/$05F200 + level number
Location of Byte 3: x2F600/$05F400 + level number
Location of Byte 4: x2F800/$05F600 + level number

{| class="wikitable"
|-
! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4
|-
| SSSSYYYY || 33TTTXXX || MMMMFFBB || IUVEEEEE
|}

S = Layer 2 scroll settings
Y = Level entrance Y position
3 = Layer 3 settings
T = Level entrance type
X = Level entrance X position
M = Level entrance midway screen
F = Level entrance FG init position
B = Level entrance BG init position
I = Disable no-Yoshi intro flag
U = Unknown vertical position flag
V = Vertical positioning flag
E = Level entrance screen number

=== Sprite header ===

The sprite header is the first byte of sprite data.

{| class="wikitable"
|-
! Byte
|-
| SBMMMMMM
|}

S = Sprite buoyancy
B = Sprite buoyancy (no sprite-L2 interaction)
MMMMMM = Sprite memory*

<nowiki>*)</nowiki> Values up to 0x3F are possible, but only up to 0x12 are valid according to Lunar Magic.

== Layer 1 ==

(Note that MAP16 is not documented, as it's a feature added by Lunar Magic)
The Layer 1 data begins with the primary level header, followed by the actual Layer 1 data.
Each block is three bytes long, with the exception of the screen exit objects.

=== Standard objects ===

{| class="wikitable"
|-
! First !! Second !! Last
|-
| NBBYYYYY || bbbbXXXX || SSSSSSSS
|}

N = New Screen flag
BBbbbb = Object number
YYYYY = Y position
XXXX = X position
SSSSSSSS = Settings byte

(Note: The first byte being FF marks the end of the data)

Settings byte
Num Desc Upper 4 Lower 4
------------------------------------------------------
00 (Extended Objects) Extended object number
01 Water (Blue) Height Width
02 Invisible coin blocks Height Width
03 Invisible note blocks Height Width
04 Invisible POW coins Height Width
05 Coins Height Width
06 Walk-through dirt Height Width
07 Water (Other color) Height Width
08 Note blocks Height Width
09 Turn blocks Height Width
0A Coin ? blocks Height Width
0B Throw blocks Height Width
0C Black piranha plants Height Width
0D Cement blocks Height Width
0E Brown blocks Height Width
0F Vertical pipes Height Type
10 Horizontal pipes Type Width
11 Bullet shooter Height Unused
12 Slopes Height Type
13 Ledge edges Height Type
14 Ground ledge Height Width
15 Midway/Goal point Height Type
16 Blue coins Height Width
17 Rope/Clouds Type Width
18 Water surface (ani) Height Width
19 Water surface (not ani) Height Width
1A Lava surface (ani) Height Width
1B Net top edge Height Width
1C Donut bridge Unused Width
1D Net bottom edge Height Width
1E Net vertical edge Height Type
1F Vert. Pipe/Bone/Log Height Unused
20 Horiz. Pipe/Bone/Log Unused Width
21 Long ground ledge Width
22 Special - Used by LM
23 Special - Used by LM
24 Special - Used by LM
25 Special - Used by LM
26 Special - Used by LM
27 Special - Used by LM
28 Special - Used by LM
29 Special - Reserved
2A Special - Reserved
2B Special - Reserved
2C Special - Reserved
2D Special - Used by LM
2E Tileset Specific 1
2F Tileset Specific 2
30 Tileset Specific 3
31 Tileset Specific 4
32 Tileset Specific 5
33 Tileset Specific 6
34 Tileset Specific 7
35 Tileset Specific 8
36 Tileset Specific 9
37 Tileset Specific 10
38 Tileset Specific 11
39 Tileset Specific 12
3A Tileset Specific 13
3B Tileset Specific 14
3C Tileset Specific 15
3D Tileset Specific 16
3E Tileset Specific 17
3F Tileset Specific 18

=== Extended objects ===

(Standard object 00)

{| class="wikitable"
|-
! First !! Second !! Last
|-
| N00YYYYY || 0000XXXX || BBBBBBBB
|}

N = New Screen flag
YYYYY = Y position
XXXX = X position
BBBBBBBB = Extended object number

Num Desc
----------------------------------------------------
00 Special - Screen Exit
01 Special - Screen Jump
02-0F Unused?
10 Small door
11 Invisible ? block (1-UP)
12 Invisible note block
13 Top left corner edge tile 1
14 Top right corner edge tile 1
15 Small POW door
16 Invisible POW ? block
17 Green star block
18 3-UP moon
19 Invisible 1-UP #1
1A Invisible 1-UP #2
1B Invisible 1-UP #3
1C Invisible 1-UP #4
1D Red berry
1E Pink berry
1F Green berry
20 Always turning block
21 Bottom right of midway point (unused)
22 Bottom right of midway point (unused)
23 Note block (flower/feather/star)
24 ON/OFF block
25 Direction coins ? block
26 Note block
27 Note block, bounce on all sides
28 Turn block (Flower)
29 Turn block (Feather)
2A Turn block (Star)
2B Turn block (Star 2/1-UP/Vine)
2C Turn block (Multiple coins)
2D Turn block (Coin)
2E Turn block (Nothing)
2F Turn block (POW)
30 ? block (Flower)
31 ? block (Feather)
32 ? block (Star)
33 ? block (Star 2)
34 ? block (Multiple coins)
35 ? block (Key/Wings/Balloon/Shell)
36 ? block (Yoshi)
37 ? block (Shell)
38 ? block (Shell)
39 Turn block, unbreakable (Feather)
3A Top left corner edge tile 2
3B Top right corner edge tile 2
3C Top left corner edge tile 3
3D Top right corner edge tile 3
3E Top left corner edge tile 4
3F Top right corner edge tile 4
40 Transculent block
41 Yoshi Coin
42 Top left slope
43 Top right slope
44 Purple triangle, left
45 Purple triangle, right
46 Midway point rope
47 Door
48 Invisible POW door
49 Ghost house exit
4A Climbing net door
4B Conveyor end tile 1
4C Conveyor end tile 2
4D Line guide, top left 1/4 large circle
4E Line guide, top right 1/4 large circle
4F Line guide, bottom left 1/4 large circle
50 Line guide, bottom right 1/4 large circle
51 Line guide, top left 1/4 small circle
52 Line guide, top right 1/4 small circle
53 Line guide, bottom left 1/4 small circle
54 Line guide, bottom right 1/4 small circle
55 Line guide end, for horizontal line
56 Line guide end, for vertical line
57 Switch palace bottom right corner tile
58 Switch palace bottom left corner tile
59 Switch palace top right corner tile
5A Switch palace top left corner tile
5B Bit of brick background tile 1
5C Bit of brick background tile 2
5D Bit of brick background tile 3
5E Bit of brick background tile 4
5F Large background area
60 Lava/mud top right corner edge
61 Ghost house clock
62 Ghost house top left to bottom right beam 1
63 Ghost house top right to bottom left beam 1
64 Ghost house cobweb, top right
65 Ghost house cobweb, top left
66 Ghost house top right to bottom left beam 2
67 Ghost house top left to bottom right beam 2
68 Cloud fringe, bottom and right edge
69 Cloud fringe, bottom and left edge
6A Cloud fringe, bottom right
6B Cloud fringe, bottom left
6C Cloud fringe on white, bottom and right edge
6D Cloud fringe on white, bottom and left edge
6E Cloud fringe on white, bottom right
6F Cloud fringe on white, bottom left
70 Bit of canvass 1
71 Canvass 1
72 Canvass 2
73 Canvass 3
74 Canvass 4
75 Canvass tile 1
76 Canvass tile 2
77 Canvass tile 3
78 Canvass tile 4
79 Canvass tile 5
7A Canvass tile 6
7B Canvass tile 7
7C Bit of canvas 2
7D Bit of canvas 3
7E Bit of canvas 4
7F Torpedo launcher
80 Ghost house entrance
81 Water weed
82 Big bush 1
83 Big bush 2
84 Castle entrance
85 Yoshi's house
86 Arrow sign
87 ! block, green
88 Tree branch, left
89 Tree branch, right
8A Switch, green
8B Switch, yellow
8C Switch, blue
8D Switch, red
8E ! block, yellow
8F Ghost house window
90 Boss door
91 Steep left slope (vert. lev.)
92 Steep right slope (vert. lev.)
93 Normal left slope (vert. lev.)
94 Normal right slope (vert. lev.)
95 Very steep left slope (vert. lev.)
96 Very steep right slope (vert. lev.)
97 Switch palace right and bottom edge tile
98-FF Unused?

=== Screen exits ===

(Extended object 00)

{| class="wikitable"
|-
! First !! Second !! Third !! Last
|-
| 000PPPPP || 0000WUSH || 00000000 || DDDDDDDD
|}

PPPPP = Page number
W = Water (secondary exit)
U = Secondary Exit? *
S = Secondary Exit
H = Unused **
DDDDDDDD = Lower 8 bits of destination level

Creates a screen exit. Should be placed right before the end of the level.

*) Used by a Lunar Magic ASM hack: If set, the H bit will be used
**) Used by a Lunar Magic ASM hack: High bit of destination level (only if the U bit is set)

Screen jump

(Extended object 01)

{| class="wikitable"
|-
! First !! Second !! Last
|-
| 000PPPPP || 0000???? || 00000001
|}

PPPPP = Page to jump to
???? = Unused?

The loading routine jumps to another screen.

== Layer 2 ==
=== Background ===

Layer 2 backgrounds are compressed using a simple RLE system.

A background consists of any number of "lines". There are two types: Normal line and RLE line

Each line begins with a start byte. The highest bit decides what kind of line it is.
(0 = Normal, 1 = RLE)
The other 7 bits are the "length" setting, which is the amount of tiles in the line minus 1.

A normal line is then followed by (length+1) bytes, each being a tile in the background.
An RLE line is only followed by a single byte which is repeated (length+1) times.

The entire left half of the background is stored first, followed by the entire right half.

The line "FFFF" marks the end of the data.

=== Level ===

Layer 2 levels are stored in exactly the same way as Layer 1.
The five byte header is there as well, but doesn't seem to be used.

== Sprites ==

The first byte of the sprite data is the sprite header.
Each sprite is three bytes long.

{| class="wikitable"
|-
! First !! Second !! Last
|-
| YYYYEEsy || XXXXSSSS || NNNNNNNN
|}

yYYYY = Y position
EE = Extra bits
XXXX = X position
sSSSS = Screen number
NNNNNNNN = Enemy number

(Note: The first byte being FF marks the end of the data)

== Secondary entrances ==

(Not yet documented.)

[[Category:Super Mario World]]

Super FX

2023-05-05T15:04:02Z

MarioFanGamer: Added links to most mentionings of opcodes, refined certain sentences.

'''Super FX''' is a [[Super NES]] [[enhancement chip]] developed by [https://en.wikipedia.org/wiki/Argonaut_Games Argonaut Games] and [http://en.wikipedia.org/wiki/Nintendo 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.

{| class="wikitable"
|+A list of their addresses and their secondary functions
|-
! 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, <code>IWT R15, #xxxx</code> on Super FX is equivalent to <code>JMP $xxxx</code> 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.

{| class="wikitable"
|+Status/Flag Register bitwise
! !! B7 !! B6 !! B5 !! B4 !! B3 !! B2 !! B1 !! B0
|-
| $3031 || IRQ || - || - || B || IH || IL || ALT1 || ALT2
|-
| $3030 || - || R || G || OV || S || CY || Z || -
|}

{| class="wikitable"
|+Description of Flags
|-
! 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.

{| class="wikitable"
|+Screen Mode Register bitwise
! 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.
{| class="wikitable"
|+Screen Dimensions
|-
! 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:
{| class="wikitable"
|+Screen Mode
|-
! 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:
{| class="wikitable"
|+Screen Mode
|-
! 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 how they're drawn onto the buffer.
It's an 8-bit register which is set using the [[CMODE]] opcode on the GSU. There is no access from the CPU.

{| class="wikitable"
|+Screen Mode Register bitwise
! 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.

{| class="wikitable"
|+Description of Screen Mode Register
|-
! 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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
!rowspan="6"|$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
|-
!rowspan="6"|$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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
!rowspan="2"|$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 <code>GETB</code> from now on).

The GSU doesn't wait during the process of fetching. As a result, it is possible to call <code>GETB</code> some time after writing to R14. In fact, this is even recommend because calling <code>GETB</code> during the process of fetching will cause the GSU to halt up five cycles for executing <code>GETB</code>. Similarly, writing to <code>ROMB</code> 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 <code>LDA #$xx</code>, 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. <code>IWT R15,#$8000</code>) 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:
<nowiki>BCC SkipCode
NOP ; Dummy NOP
...
SkipCode:</nowiki>

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 <code>NOP</code>. As a result, opcodes such as <code>SUB R0</code> can be put as a dummy opcode in place of <code>NOP</code>. The following example demonstrates it:
<nowiki>BCC SkipCode
;NOP ; Redundant
SUB R0 ; Set R0 to zero
STW (R1)
SkipCode:
IWT R0,#$1234</nowiki>
In the above code, R0 gets overwritten by <code>SUB</code> no matter whether the branch is taken. However, it later gets overwritten by <code>IWT</code>. As a result, it doesn't matter whether the dummy opcode is a <code>NOP</code> or <code>SUB</code> from the branch for the calculation. In fact, using a <code>NOP</code> 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 <code>ADD #x</code> (which is internally prefixed with [[ALT2]]), <code>WITH</code> (register prefixes which change which register is the source or destination), <code>BRA $10</code> (branches which always use two bytes) and <code>IWT</code> (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 <code>LDA #$12</code> when A is in 16-bit mode on the 65816. The following example demonstrates it:
<nowiki>BCC SkipCode
BRA Error ; Caution!
...
SkipCode:
...
Error:
INC R1 ; Will instead be read with the BRA as "BRA $D1".</nowiki>
In addition, the dummy opcode after a <code>STOP</code> '''must''' be a <code>NOP</code> 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 <code>STOP</code> is located at $XXXF in cache as the pipelined code may be located in unused cache and a value in ROM/RAM will be loaded instead.

== Bus Conflicts ==

== Bitmap Processing ==

[[Category:SNES_Hardware]]
[[Category:Integrated Circuits]]
[[Category:Enhancement Chips]]

DIV2 (Super FX)

2023-05-05T14:43:14Z

MarioFanGamer: Added links to other bitshift operators, explanation to most significant bit and differenciation to ASR.

'''DIV2''' (DIVide by 2) is a [[Super FX]] instruction that shifts a register's bits one place to the right while also leaving the most significant bit unchanged. Unlike [[ASR]], the output becomes zero if the input is 0xFFFF.

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Clobbered
|+
|B
|ALT1
|ALT2
|O/V
|S
|CY
|Z
|+
|0
|0
|0
|.
|
|
|
|}

=== See Also ===
* [[ASL]]
* [[ASR]]
* [[LSR]]

[[Category:ASM]]
[[Category:Enhancement Chips]]

ASR (Super FX)

2023-05-05T14:40:10Z

MarioFanGamer: Added link to similar DIV2 as well as explanation to most significant.

'''ASR''' (Arithmetic Shift Right) is a [[Super FX]] instruction that shifts all bits to the right while also leaving the most significant bit unchanged.

{| class="wikitable" style="float:right;clear:right;width:30%"
!colspan="9"|Flags Clobbered
|+
|B
|ALT1
|ALT2
|O/V
|S
|CY
|Z
|+
|0
|0
|0
|.
|
|
|
|}

=== See Also ===
* [[ASL]]
* [[LSR]]
* [[DIV2]]

[[Category:ASM]]
[[Category:Enhancement Chips]]

Yoshi's Island

2023-04-27T07:14:19Z

MarioFanGamer: Fixed redirection.

#REDIRECT [[Super Mario World 2: Yoshi's Island]]

Super Metroid

2023-04-27T07:01:26Z

MarioFanGamer: Created page.

Super Metroid, also known as Metroid 3, is the third enty of the Metroid series, being famously known for codifying the Metroidvania genre (alongside Castlevania: Symphony of the Night).

[[Category:Games]]

Final Fantasy Mystic Quest

2023-04-27T06:53:42Z

MarioFanGamer: Added category.

'''Final Fantasy Mystic Quest''' is a JRPG developed by Square.

== Easter Eggs ==

FFMQ provides a convenient way to discover your SNES' chip revisions. When in the pause menu, press Start and Select simultaneously, and the revisions for the CPU, PPU1, and PPU2 will be displayed.

[[File:FFMQ chipset.png|thumb|Pause menu displaying some of the SNES chipset]]

[[Category:Games]]

Seiken Densetsu 3

2023-04-27T06:53:06Z

MarioFanGamer: Added category.

''Seiken Densetsu 3'' is a 1995 JRPG developed by Squaresoft.

It was fan-translated into English by Neill Corlett, and later received an offical English translation.

[[Category:Games]]

F-Zero

2023-04-27T06:52:37Z

MarioFanGamer: Added category.

'''F-Zero''' is a racing game.

[[Category:Games]]

The Legend of Zelda: A Link to the Past

2023-04-27T06:51:35Z

MarioFanGamer: Added category.

''The Legend of Zelda: A Link to the Past'' is the third entry in the Zelda series. It returned gameplay to an overhead perspective.

[[Category:Games]]

Category:Compression Formats

2023-03-24T19:53:18Z

MarioFanGamer: Create category.

Informations about common compression formats used on the SNES.

Super FX

2023-03-24T19:52:03Z

MarioFanGamer: Added category.

'''Super FX''' is a [[Super NES]] [[enhancement chip]] developed by [https://en.wikipedia.org/wiki/Argonaut_Games Argonaut Games] and [http://en.wikipedia.org/wiki/Nintendo 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.

{| class="wikitable"
|+A list of their addresses and their secondary functions
|-
! Name !! Address !! Secondary Function
|-
| R0 || $3000 || Default source/destination register.
|-
| R1 || $3002 || <code>PLOT</code> X position
|-
| R2 || $3004 || <code>PLOT</code> Y position
|-
| R3 || $3006 ||
|-
| R4 || $3008 || Low word for <code>LMULT</code> result
|-
| R5 || $300A ||
|-
| R6 || $300C || Second input for <code>LMULT</code> and <code>FMULT</code>
|-
| R7 || $300E || <code>MERGE</code> source 1
|-
| R8 || $3010 || <code>MERGE</code> source 2
|-
| R9 || $3012 ||
|-
| R10 || $3014 ||
|-
| R11 || $3016 || <code>LINK</code> destination
|-
| R12 || $3018 || <code>LOOP</code> counter
|-
| R13 || $301A || <code>LOOP</code> 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 <code>GETB</code> 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, <code>IWT R15, #xxxx</code> on Super FX is equivalent to <code>JMP $xxxx</code> 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.

{| class="wikitable"
|+Status/Flag Register bitwise
! !! B7 !! B6 !! B5 !! B4 !! B3 !! B2 !! B1 !! B0
|-
| $3031 || IRQ || - || - || B || IH || IL || ALT1 || ALT2
|-
| $3030 || - || R || G || OV || S || CY || Z || -
|}

{| class="wikitable"
|+Description of Flags
|-
! 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 <code>ALT1</code>.
|-
| ALT2 || Opcode modifier 2, set when executing <code>ALT2</code>.
|-
| IL || Immediate lower 8-bit flag.
|-
| IH || Immediate higher 8-bit flag.
|-
| B || Set when executing <code>WITH</code>.
|-
| 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 <code>LJMP</code> on GSU side.

=== Game Pak ROM Bank Register (ROMBR) ===

This register controls the bank where ROM is read. It's set using the <code>ROMB</code> 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 <code>RAMB</code> 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 <code>CACHE</code> and <code>LJMP</code> 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.

{| class="wikitable"
|+Screen Mode Register bitwise
! 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.
{| class="wikitable"
|+Screen Dimensions
|-
! 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:
{| class="wikitable"
|+Screen Mode
|-
! 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:
{| class="wikitable"
|+Screen Mode
|-
! 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 <code>COLOR</code> and <code>GETC</code> 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 <code>CMODE</code> opcode on the GSU. There is no access from the CPU.

{| class="wikitable"
|+Screen Mode Register bitwise
! 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.

{| class="wikitable"
|+Description of Screen Mode Register
|-
! 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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
!rowspan="6"|$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
|-
!rowspan="6"|$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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
!rowspan="2"|$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 <code>ROMB</code> 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 <code>GETB</code> and similar opcodes (referred to just <code>GETB</code> from now on).

The GSU doesn't wait during the process of fetching. As a result, it is possible to call <code>GETB</code> some time after writing to R14. In fact, this is even recommend because calling <code>GETB</code> during the process of fetching will cause the GSU to halt up five cycles for executing <code>GETB</code>. Similarly, writing to <code>ROMB</code> 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 <code>CACHE</code> opcode or by a <code>LJMP</code> 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 <code>INC</code> which take two cycles to process, the same amount of cycles as <code>LDA #$xx</code>, 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. <code>IWT R15,#$8000</code>) as well as halting the GSU such as with <code>STOP</code>. 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 <code>NOP</code> after the R15 modifying opcode such as in this example:
<nowiki>BCC SkipCode
NOP ; Dummy NOP
...
SkipCode:</nowiki>

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 <code>NOP</code>. As a result, opcodes such as <code>SUB R0</code> can be put as a dummy opcode in place of <code>NOP</code>. The following example demonstrates it:
<nowiki>BCC SkipCode
;NOP ; Redundant
SUB R0 ; Set R0 to zero
STW (R1)
SkipCode:
IWT R0,#$1234</nowiki>
In the above code, R0 gets overwritten by <code>SUB</code> no matter whether the branch is taken. However, it later gets overwritten by <code>IWT</code>. As a result, it doesn't matter whether the dummy opcode is a <code>NOP</code> or <code>SUB</code> from the branch for the calculation. In fact, using a <code>NOP</code> 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 <code>ADD #x</code> (which is internally prefixed with <code>ALT2</code>), <code>WITH</code> (register prefixes which change which register is the source or destination), <code>BRA $10</code> (branches which always use two bytes) and <code>IWT</code> (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 <code>LDA #$12</code> when A is in 16-bit mode on the 65816. The following example demonstrates it:
<nowiki>BCC SkipCode
BRA Error ; Caution!
...
SkipCode:
...
Error:
INC R1 ; Will instead be read with the BRA as "BRA $D1".</nowiki>
In addition, the dummy opcode after a <code>STOP</code> '''must''' be a <code>NOP</code> 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 <code>STOP</code> 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.

== Bus Conflicts ==

== Bitmap Processing ==

[[Category:SNES_Hardware]]

LZ5

2023-03-24T19:50:49Z

MarioFanGamer: Added category.

LZ5 or LC_LZ5, as named by Lunar Compress, is a lossless data compression format, used by [[Super Mario Kart]] to compress graphics and other data. The LZ5 compression format is a slight enhancement of the [[LZ2]] compression format, due to new commands.

== Compression ==

The compressed data consists of "chunks", each with a header:

<pre>
bits
76543210
CCCLLLLL
CCC: Command bits
LLLLL: Length
</pre>

If the header byte is $FF, the end of the compressed data has been reached, and decompression will be aborted.

The commands mostly remain their LC_LZ2 commands. However, there are new commands too. Here is a list of commands bits which the LC_LZ5 decompression function can use during the decompression:

<pre>
000 "Direct Copy"
Followed by (L+1) bytes of data
001 "Byte Fill"
Followed by one byte to be repeated (L+1) times
010 "Word Fill"
Followed by two bytes. Output first byte, then second, then first,
then second, etc. until (L+1) bytes has been outputted
011 "Increasing Fill"
Followed by one byte to be repeated (L+1) times, but the byte is
increased by 1 after each write
100 "Repeat"
Followed by a word (little-endian) containing address relative
to the output buffer's first byte to copy (L+1) bytes from.
Basically it's this math: (Output buffer offset + word value)
101 "XOR Repeat"
Same concept as above, except all the copied bytes are getting
XOR'd by the value $FF.
110 "Negative Repeat", followed by a byte subtracted by the CURRENT index
to the output buffer, to copy (L+1) bytes from.
Basically it's this math: (Output buffer offset's index - byte value)
111 "Long length"
This command has got a two-byte header:
111CCCLL LLLLLLLL
CCC: Real command
LLLLLLLLLL: Length
</pre>

<pre>
Long Length-exclusive command
111 "Negative XOR repeat"
Same concept as "Negative Repeat", except all the copied bytes
are getting XOR'd by the value $FF.
</pre>

Seeing that the long length command uses ten bits for its length, the maximum length is 1024 bytes/1kB, while the normal length is 32 bytes.

== Decompression ==

During the decompression, the decompressed chunks are outputted into a buffer which is either [[RAM]] or [[SRAM]].

== Usage ==

You can use the LZ5 compression to mainly compress graphics and data. Technically you can compress anything with this format.

[[Category:Compression Formats]]

LC LZ2

2023-03-24T19:50:21Z

MarioFanGamer: Added category.

{{DISPLAYTITLE:LC_LZ2}}
LZ2 or LC_LZ2, as named by [[Lunar Compress]], is a lossless data compression format, used by [[Super Mario World]] to compress graphics. It is also used by [[Super Mario World 2: Yoshi's Island]].

== Compression ==

The compressed data consists of "chunks", each with a header:

<pre>
bits
76543210
CCCLLLLL

CCC: Command bits
LLLLL: Length
</pre>

If the header byte is $FF, the end of the compressed data has been reached, and decompression will be aborted.

Here is a list of commands bits which the LC_LZ2 decompression function can use during the decompression:

<pre>
000 "Direct Copy"
Followed by (L+1) bytes of data
001 "Byte Fill"
Followed by one byte to be repeated (L+1) times
010 "Word Fill"
Followed by two bytes. Output first byte, then second, then first,
then second, etc. until (L+1) bytes has been outputted
011 "Increasing Fill"
Followed by one byte to be repeated (L+1) times, but the byte is
increased by 1 after each write
100 "Repeat"
Followed by two bytes (big endian byte order) containing address (in the
output buffer) to copy (L+1) bytes from
101 (Unused command)
110 (Unused command)
111 "Long length"
This command has got a two-byte header:
111CCCLL LLLLLLLL
CCC: Real command
LLLLLLLLLL: Length
</pre>

== Decompression ==

During the decompression, the decompressed chunks are outputted into a buffer which is either RAM or SRAM. SMW uses the RAM address $7E:AD00 as its decompression buffer.

== Usage ==

You can use the LC_LZ2 compression to mainly compress graphics. Technically you can compress anything with this format, but graphics is preferred due to their big size. Seeing the SNES isn't fast, the decompression takes a while to finish, so whenever you overuse the compression the loading time will increase.

== Other ==

You can see an LC_LZ2 decompression routine setup at SNES $00:B888. The decompression routine itself is located at SNES $00:B8DE.

== External links ==

[https://fusoya.eludevisibility.org/lc/index.html Lunar Compress], a library by [[FuSoYa]] made to handle loading various game graphics format, including LZ2.

[[Category:Compression Formats]]

RLE2

2023-03-24T19:50:04Z

MarioFanGamer: Added category.

RLE2 or LC_RLE2, as named by [[Lunar Compress]], is a lossless data compression format, used by [[Super Mario World]] to compress the entire overworld layer 2 tilemap.

== Compression ==

The compression is a simple run-length encoding format. However, this one is two-dimensional, which means the decompressed data gets stored every other byte in the output buffer unlike LC_RLE1. Therefore, the decompression routine needs to be run entirely two times. Also, there are two compressed tables.

The compressed data consists of "chunks", each with a header:

<pre>
bits
76543210
CLLLLLLL
C: Command bit
LLLLLLL: Length
</pre>

Here's a list of the command bit values the LC_RLE2 routine can use during decompression:

<pre>
0 "Direct Copy"
Followed by (L+1) bytes of data
1 "RLE"
Followed by one byte to be repeated (L+1) times
</pre>

There is no byte which marks the end of the compressed data. You have to specify the length of the original, decompressed data so the decompression goes without any problems.

== Two tables and decompression ==

The decompressed data gets written to the output buffer every other byte. This means that the bytes are stored as [XX] [YY] [XX] [YY] [XX] [YY] [..]. The XX bytes are from table 1, the YY bytes are from table 2. Technically, when the compressed data is read, the index to the compressed data increases by one, while the index to the output buffer increases by two, which causes this effect. The tables' original decompressed length should be half of the original, decompressed data altogether. So if you specify the length as $4000 bytes, table 1's output should be $2000 bytes, and table 2's output should be $2000 bytes too.

== Usage ==

You can use the LC_RLE2 compression to mainly compress raw [[VRAM]] tilemap. Technically you can compress anything with this format, but raw VRAM tilemaps are preferred due to the often-occuring repeating every-other bytes.

== Other ==

You can see an LC_RLE2 decompression routine setup at SNES $04:DC6F (SMW). The decompression routine itself is located at SNES $04:DABA. The decompression routine does not support data which crosses bank boundaries. Therefore, you will have to take care of that.

[[Category:Compression Formats]]

LZ3

2023-03-24T19:49:49Z

MarioFanGamer: Added category.

LZ3 or LC_LZ3, as named by Lunar Compress, is a lossless data compression format, used by Pokemon Gold/Silver to compress graphics and other data. The LZ3 compression format is similar the [[LZ2]] compression format.

== Compression ==

The compressed data consists of "chunks", each with a header:

<pre>
bits
76543210
CCCLLLLL
CCC: Command bits
LLLLL: Length
</pre>

If the header byte is $FF, the end of the compressed data has been reached, and decompression will be aborted.

Here is a list of commands bits which the LC_LZ3 decompression function can use during the decompression:

<pre>
000 "Direct Copy"
Followed by (L+1) bytes of data
001 "Byte Fill"
Followed by one byte to be repeated (L+1) times
010 "Word Fill"
Followed by two bytes. Output first byte, then second, then first,
then second, etc. until (L+1) bytes has been outputted
011 "Zero Fill"
Repeat a $00 (L+1) times
100 "Repeat"
Followed by one or two bytes. The first byte is AYYYYYYY.
If bit A is set, (L+1) bytes are copied from the current
address in the output buffer minus (Y+1)
If bit A is reset, a second byte ZZZZZZZZ is read, and
(L+1) bytes are copied from the address (Y*0x100)+Z
relative to the first byte in the output buffer
101 "Bit-Reverse Repeat"
Same concept as above, except all the copied bytes are
reversed in bit order. ($AF = %10101111 -> $F5 = %11110101)
110 "Backwards Repeat"
Same concept as "Repeat", except the bytes are copied in
reversed order. The address points to the first byte to be copied,
and it decrements as each byte is copied.
111 "Long length"
This command has got a two-byte header:
111CCCLL LLLLLLLL
CCC: Real command
LLLLLLLLLL: Length
</pre>

Seeing that the long length command uses ten bits for its length, the maximum length is 1024 bytes/1kB, while the normal length is 32 bytes.

== Decompression ==

During the decompression, the decompressed chunks are outputted into a buffer in the RAM.

== Usage ==

You can use the LC_LZ3 compression to mainly compress graphics and data. Technically you can compress anything with this format.

[[Category:Compression Formats]]

LZ1

2023-03-24T19:49:27Z

MarioFanGamer: Added category.

{{DISPLAYTITLE:LZ1}}
LZ1 or LC_LZ1, as named by [[Lunar Compress]], is a lossless data compression format, used by [[A Link to the Past]] to compress graphics. It is also used by [[Super Mario World]] japanese version only.

== Compression ==

The compressed data consists of "chunks", each with a header:

<pre>
bits
76543210
CCCLLLLL

CCC: Command bits
LLLLL: Length
</pre>

If the header byte is $FF, the end of the compressed data has been reached, and decompression will be aborted.

Here is a list of commands bits which the LZ1 decompression function can use during the decompression:

<pre>
000 "Direct Copy"
Followed by (L+1) bytes of data
001 "Byte Fill"
Followed by one byte to be repeated (L+1) times
010 "Word Fill"
Followed by two bytes. Output first byte, then second, then first,
then second, etc. until (L+1) bytes has been outputted
011 "Increasing Fill"
Followed by one byte to be repeated (L+1) times, but the byte is
increased by 1 after each write
100 "Repeat"
Followed by two bytes (small endian byte order, this being the only difference between LZ1 and LZ2) containing address (in the
output buffer) to copy (L+1) bytes from
101 (Unused command)
110 (Unused command)
111 "Long length"
This command has got a two-byte header:
111CCCLL LLLLLLLL
CCC: Real command
LLLLLLLLLL: Length
</pre>
== Decompression ==
During the decompression, the decompressed chunks are outputted into a buffer in the RAM.

== Usage ==

You can use the LZ1 compression to mainly compress graphics. Technically you can compress anything with this format, but graphics is preferred due to their big size. Seeing the SNES isn't fast, the decompression takes a while to finish, so whenever you overuse the compression the loading time will increase.

== External links ==

[https://fusoya.eludevisibility.org/lc/index.html Lunar Compress], a library by [[FuSoYa]] made to handle loading various game graphics format, including LZ1.

[[Category:Compression Formats]]

RLE1

2023-03-24T19:48:45Z

MarioFanGamer: Added category.

RLE1 or LC_RLE1, as named by [[Lunar Compress]], is a lossless data compression format, used by [[Super Mario World]] to compress the overworld layer 2 event data's tilemap properties.

== Compression ==

The compression is a simple run-length encoding format. It's one-dimensional, which means the decompressed data gets stored normally in the output buffer unlike LC_RLE2.

The compressed data consists of "chunks", each with a header:

<pre>
bits
76543210
CLLLLLLL
C: Command bit
LLLLLLL: Length
</pre>

Here's a list of the command bit values the LC_RLE1 routine can use during decompression:

<pre>
0 "Direct Copy"
Followed by (L+1) bytes of data
1 "RLE"
Followed by one byte to be repeated (L+1) times
</pre>

The end of the decompression data is reached when the header byte and the following byte both are $FF. This means that the compression does not support 128 bytes of $FF compressed (because the result will be $FF $FF, which aborts the decompression). However, you can compress 127 bytes instead so that the result becomes $FE $FF)

== Decompression ==

During the decompression, the decompressed chunks can be outputted into a buffer which is either RAM or SRAM. SMW uses the RAM address $7F:0000 as its decompression buffer. The maximum RLE decompression length is 128 bytes.

== Usage ==

You can use the LC_RLE1 compression to mainly compress things like tilemap. Technically you can compress anything with this format, but tilemaps are preferred due to the often-occuring consecutive repeating bytes.

== Other ==

You can see an LC_RLE1 decompression routine setup at SNES $04:DD40 (SMW). The decompression routine itself is located at SNES $04:DD57. The decompression routine does not support data which crosses bank boundaries. Therefore, you will have to take care of that.

[[Category:Compression Formats]]

List of SNES ROM hacking tools

2023-03-12T06:26:36Z

MarioFanGamer: /* Emulators/Debuggers */ Replaced Mesen-S with Mesen2.

== General ==
=== ASM patchers ===
* [https://github.com/RPGHacker/asar Asar]
* [https://byuu.org/tool/bass bass]
* [https://www.smwcentral.net/?p=section&a=details&id=4615 xkas] (legacy, but very known)

=== Binary patchers ===
* [https://github.com/Alcaro/Flips FLIPS] (.bps, .ips) -- Windows binary: https://sneslab.net/tools/floating.zip
* [https://fusoya.eludevisibility.org/lips/index.html Lunar IPS] (.ips)

=== Emulators ===
* [https://byuu.org/emulation/bsnes/ bsnes]
* [https://github.com/snes9xgit/snes9x Snes9x]
* [https://zsnes.com/ ZSNES] (inaccurate, but fast and used to be very popular)

=== Emulators/Debuggers ===
* [https://github.com/devinacker/bsnes-plus bsnes-plus]
* [https://github.com/SourMesen/Mesen2 Mesen]

== SMW Hacking ==
=== Editors ===
* [https://fusoya.eludevisibility.org/lm/index.html Lunar Magic]

=== Inserters ===
* [https://github.com/VitorVilela7/UberASMTool UberASM Tool]
* [https://github.com/JackTheSpades/SpriteToolSuperDelux PIXI]
* [https://smwc.me/1491239 GIEPY]
* [https://www.smwcentral.net/?p=section&a=details&id=17546 AddmusicK]

=== Converters ===
* [https://github.com/VitorVilela7/SPCtoMML SPCtoMML]
* [https://github.com/VitorVilela7/SnesGFX SnesGFX]

== YI Hacking ==
=== Editors ===
* [https://www.smwcentral.net/?p=section&a=details&id=4645 Golden Egg]

=== Inserters ===
* [https://dl.dropbox.com/s/oqsnu42mg76runs/AddMusicY%20Beta.zip AddmusicY]

Super FX

2023-02-27T07:07:53Z

MarioFanGamer: /* Hardware Registers */ Described all Super FX registers. TODO: Add links for further references.

'''Super FX''' is a [[Super NES]] [[enhancement chip]] developed by [https://en.wikipedia.org/wiki/Argonaut_Games Argonaut Games] and [http://en.wikipedia.org/wiki/Nintendo 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.

{| class="wikitable"
|+A list of their addresses and their secondary functions
|-
! Name !! Address !! Secondary Function
|-
| R0 || $3000 || Default source/destination register.
|-
| R1 || $3002 || <code>PLOT</code> X position
|-
| R2 || $3004 || <code>PLOT</code> Y position
|-
| R3 || $3006 ||
|-
| R4 || $3008 || Low word for <code>LMULT</code> result
|-
| R5 || $300A ||
|-
| R6 || $300C || Second input for <code>LMULT</code> and <code>FMULT</code>
|-
| R7 || $300E || <code>MERGE</code> source 1
|-
| R8 || $3010 || <code>MERGE</code> source 2
|-
| R9 || $3012 ||
|-
| R10 || $3014 ||
|-
| R11 || $3016 || <code>LINK</code> destination
|-
| R12 || $3018 || <code>LOOP</code> counter
|-
| R13 || $301A || <code>LOOP</code> 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 <code>GETB</code> 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, <code>IWT R15, #xxxx</code> on Super FX is equivalent to <code>JMP $xxxx</code> 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.

{| class="wikitable"
|+Status/Flag Register bitwise
! !! B7 !! B6 !! B5 !! B4 !! B3 !! B2 !! B1 !! B0
|-
| $3031 || IRQ || - || - || B || IH || IL || ALT1 || ALT2
|-
| $3030 || - || R || G || OV || S || CY || Z || -
|}

{| class="wikitable"
|+Description of Flags
|-
! 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 <code>ALT1</code>.
|-
| ALT2 || Opcode modifier 2, set when executing <code>ALT2</code>.
|-
| IL || Immediate lower 8-bit flag.
|-
| IH || Immediate higher 8-bit flag.
|-
| B || Set when executing <code>WITH</code>.
|-
| 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 <code>LJMP</code> on GSU side.

=== Game Pak ROM Bank Register (ROMBR) ===

This register controls the bank where ROM is read. It's set using the <code>ROMB</code> 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 <code>RAMB</code> 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 <code>CACHE</code> and <code>LJMP</code> 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.

{| class="wikitable"
|+Screen Mode Register bitwise
! 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.
{| class="wikitable"
|+Screen Dimensions
|-
! 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:
{| class="wikitable"
|+Screen Mode
|-
! 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:
{| class="wikitable"
|+Screen Mode
|-
! 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 <code>COLOR</code> and <code>GETC</code> 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 <code>CMODE</code> opcode on the GSU. There is no access from the CPU.

{| class="wikitable"
|+Screen Mode Register bitwise
! 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.

{| class="wikitable"
|+Description of Screen Mode Register
|-
! 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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
!rowspan="6"|$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
|-
!rowspan="6"|$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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
!rowspan="2"|$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 <code>ROMB</code> 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 <code>GETB</code> and similar opcodes (referred to just <code>GETB</code> from now on).

The GSU doesn't wait during the process of fetching. As a result, it is possible to call <code>GETB</code> some time after writing to R14. In fact, this is even recommend because calling <code>GETB</code> during the process of fetching will cause the GSU to halt up five cycles for executing <code>GETB</code>. Similarly, writing to <code>ROMB</code> 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 <code>CACHE</code> opcode or by a <code>LJMP</code> 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 <code>INC</code> which take two cycles to process, the same amount of cycles as <code>LDA #$xx</code>, 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. <code>IWT R15,#$8000</code>) as well as halting the GSU such as with <code>STOP</code>. 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 <code>NOP</code> after the R15 modifying opcode such as in this example:
<nowiki>BCC SkipCode
NOP ; Dummy NOP
...
SkipCode:</nowiki>

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 <code>NOP</code>. As a result, opcodes such as <code>SUB R0</code> can be put as a dummy opcode in place of <code>NOP</code>. The following example demonstrates it:
<nowiki>BCC SkipCode
;NOP ; Redundant
SUB R0 ; Set R0 to zero
STW (R1)
SkipCode:
IWT R0,#$1234</nowiki>
In the above code, R0 gets overwritten by <code>SUB</code> no matter whether the branch is taken. However, it later gets overwritten by <code>IWT</code>. As a result, it doesn't matter whether the dummy opcode is a <code>NOP</code> or <code>SUB</code> from the branch for the calculation. In fact, using a <code>NOP</code> 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 <code>ADD #x</code> (which is internally prefixed with <code>ALT2</code>), <code>WITH</code> (register prefixes which change which register is the source or destination), <code>BRA $10</code> (branches which always use two bytes) and <code>IWT</code> (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 <code>LDA #$12</code> when A is in 16-bit mode on the 65816. The following example demonstrates it:
<nowiki>BCC SkipCode
BRA Error ; Caution!
...
SkipCode:
...
Error:
INC R1 ; Will instead be read with the BRA as "BRA $D1".</nowiki>
In addition, the dummy opcode after a <code>STOP</code> '''must''' be a <code>NOP</code> 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 <code>STOP</code> 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.

== Bus Conflicts ==

== Bitmap Processing ==

Super FX

2023-02-26T10:00:42Z

MarioFanGamer: Prepared hardware registers, filled some of them, fixed some typos in other sections.

'''Super FX''' is a [[Super NES]] [[enhancement chip]] developed by [https://en.wikipedia.org/wiki/Argonaut_Games Argonaut Games] and [http://en.wikipedia.org/wiki/Nintendo 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.

{| class="wikitable"
|+A list of their addresses and their secondary functions
|-
! Name !! Address !! Secondary Function
|-
| R0 || $3000 || Default source/destination register.
|-
| R1 || $3002 || <code>PLOT</code> X position
|-
| R2 || $3004 || <code>PLOT</code> Y position
|-
| R3 || $3006 ||
|-
| R4 || $3008 || Low word for <code>LMULT</code> result
|-
| R5 || $300A ||
|-
| R6 || $300C || Second input for <code>LMULT</code> and <code>FMULT</code>
|-
| R7 || $300E || <code>MERGE</code> source 1
|-
| R8 || $3010 || <code>MERGE</code> source 2
|-
| R9 || $3012 ||
|-
| R10 || $3014 ||
|-
| R11 || $3016 || <code>LINK</code> destination
|-
| R12 || $3018 || <code>LOOP</code> counter
|-
| R13 || $301A || <code>LOOP</code> 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 <code>GETB</code> 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, <code>IWT R15, #xxxx</code> on Super FX is equivalent to <code>JMP $xxxx</code> 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.

{| class="wikitable"
|+Status/Flag Register bitwise
! !! B7 !! B6 !! B5 !! B4 !! B3 !! B2 !! B1 !! B0
|-
| $3031 || IRQ || - || - || B || IH || IL || ALT1 || ALT2
|-
| $3030 || - || R || G || OV || S || CY || Z || -
|}

{| class="wikitable"
|+Description of Flags
|-
! Flag !! Description
|-
| Z || Zero flag, set when
|-
| 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
|-
| ALT1 || Opcode modifier 1, set when executing <code>ALT1</code>
|-
| ALT2 || Opcode modifier 2, set when executing <code>ALT2</code>
|-
| IL || Immediate lower 8-bit flag
|-
| IH || Immediate higher 8-bit flag
|-
| B || Set when <code>WITH</code>
|-
| 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 <code>LJMP</code> on GSU side.

=== Game Pak ROM Bank Register (ROMBR) ===

This register controls the bank where ROM is read. It's set using the <code>ROMB</code> 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 <code>RAMB</code> 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) ===

=== Screen Base Register (SCBR) ===

=== Screen Mode Register (SCMR) ===

=== Color Register (COLR) ===

=== Plot Option Register (POR) ===

=== Backup RAM Register (BRAMR) ===

=== Version Code Register (VCR) ===

=== Config Register (CFGR) ===

=== Clock Select Register (CLSR) ===

== 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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
!rowspan="6"|$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
|-
!rowspan="6"|$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:
{| class="wikitable"
|-
! Banks !! Address !! Description
|-
!rowspan="2"|$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 <code>ROMB</code> 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 <code>GETB</code> and similar opcodes (referred to just <code>GETB</code> from now on).

The GSU doesn't wait during the process of fetching. As a result, it is possible to call <code>GETB</code> some time after writing to R14. In fact, this is even recommend because calling <code>GETB</code> during the process of fetching will cause the GSU to halt up five cycles for executing <code>GETB</code>. Similarly, writing to <code>ROMB</code> 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 <code>CACHE</code> opcode or by a <code>LJMP</code> 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 <code>INC</code> which take two cycles to process, the same amount of cycles as <code>LDA #$xx</code>, 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. <code>IWT R15,#$8000</code>) as well as halting the GSU such as with <code>STOP</code>. 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 <code>NOP</code> after the R15 modifying opcode such as in this example:
<nowiki>BCC SkipCode
NOP ; Dummy NOP
...
SkipCode:</nowiki>

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 <code>NOP</code>. As a result, opcodes such as <code>SUB R0</code> can be put as a dummy opcode in place of <code>NOP</code>. The following example demonstrates it:
<nowiki>BCC SkipCode
;NOP ; Redundant
SUB R0 ; Set R0 to zero
STW (R1)
SkipCode:
IWT R0,#$1234</nowiki>
In the above code, R0 gets overwritten by <code>SUB</code> no matter whether the branch is taken. However, it later gets overwritten by <code>IWT</code>. As a result, it doesn't matter whether the dummy opcode is a <code>NOP</code> or <code>SUB</code> from the branch for the calculation. In fact, using a <code>NOP</code> 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 <code>ADD #x</code> (which is internally prefixed with <code>ALT2</code>), <code>WITH</code> (register prefixes which change which register is the source or destination), <code>BRA $10</code> (branches which always use two bytes) and <code>IWT</code> (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 <code>LDA #$12</code> when A is in 16-bit mode on the 65816. The following example demonstrates it:
<nowiki>BCC SkipCode
BRA Error ; Caution!
...
SkipCode:
...
Error:
INC R1 ; Will instead be read with the BRA as "BRA $D1".</nowiki>
In addition, the dummy opcode after a <code>STOP</code> '''must''' be a <code>NOP</code> 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 <code>STOP</code> 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.

== Bus Conflicts ==

== Bitmap Processing ==