godzil/quickdev16
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add missing docs

Browse Source
This commit is contained in:
optixx 2016-02-15 17:42:39 +01:00
parent 7270dac4c8
commit f743bf5ea9
110 changed files with 73404 additions and 3351 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
files/Quickdev16_1.5_sdcard.txt Normal file
View File

@ -0,0 +1,45 @@
--------------------------------
SDcard Board
--------------------------------
Connector
1 DO -> 7
2 GND -> 6
3 VCC -> 4
4 CS -> 1
5 DI -> 2
6 CLK -> 5
-
SDcard
------------------\
| \
| 8 7 6 5 4 3 2 1 9 |
| |
1 CS
2 CMD/DI
3 GND
4 VCC
5 CLK/SCLK
6 GND
7 DAT/DO
8 --
9 --
--------------------------------
Quickdev Header
--------------------------------
top/usb
1 GND -> GND
2 ISP RST - RESET -
3 ISP SCK - PB7 - CLK
4 ISP MISO - PB6 - DI
5 ISP MOSI - PB5 - DO
6 MMC CS - PB4 - CS
7 VCC -> VCC
#define SPI_DI 6 MISO
#define SPI_DO 5 MOSI

BIN
files/Quickdev16_Seeedstudio2.6_orderlist.ods Normal file
View File

Binary file not shown.

BIN
files/Quickdev16_Seeedstudio2.6_parts_2.6_reichelt_CSD.ods Normal file
View File

Binary file not shown.

29
files/Quickdev16_ascii_banner.txt Normal file
View File

@ -0,0 +1,29 @@
________ .__ __ ________ ____ ________
\_____ \ __ __|__| ____ | | __\______ \ _______ _/_ |/ _____/
/ / \ \| | \ |/ ___\| |/ / | | \_/ __ \ \/ /| / __ \
/ \_/. \ | / \ \___| < | ` \ ___/\ / | \ |__\ \
\_____\ \_/____/|__|\___ >__|_ \/_______ /\___ >\_/ |___|\_____ /
\__> \/ \/ \/ \/ \/
___.
__ __ _____\_ |__
| | \/ ___/| __ \
| | /\___ \ | \_\ \
|____//____ >|___ /
\/ \/

BIN
files/Quickdev16_label.odt Normal file
View File

Binary file not shown.

BIN
files/Quickdev16_label_rund.odt Normal file
View File

Binary file not shown.

BIN
files/docs/avr/A200_PDIUSBD12-08.pdf Normal file
View File

Binary file not shown.

18951
files/docs/avr/A300_atmega644-xx.pdf Normal file
View File

File diff suppressed because one or more lines are too long

25130
files/docs/avr/at90usb.pdf Normal file
View File

File diff suppressed because one or more lines are too long

BIN
files/docs/avr/at90usb646.pdf Normal file
View File

Binary file not shown.

BIN
files/docs/avr/at90usb_overview.pdf Normal file
View File

Binary file not shown.

BIN
files/docs/avr/at90usb_short.pdf Normal file
View File

Binary file not shown.

BIN
files/docs/avr/stk500.pdf Normal file
View File

Binary file not shown.

BIN
files/docs/ftdi/DS_FT232R_V202.pdf Normal file
View File

Binary file not shown.

BIN
files/docs/ftdi/FT232RL.pdf Normal file
View File

Binary file not shown.

2248
files/docs/snes/65816.STD Normal file
View File

File diff suppressed because it is too large Load Diff

515
files/docs/snes/65816/addrmode.txt Normal file
View File

@ -0,0 +1,515 @@
G65SC802 and G65SC816
Microprocessor Addressing modes
The G65SC816 is capable of directly addressing 16 MBytes of memory.
This address space has special significance within certain addressing
modes, as follows:
Reset and Interrupt Vectors
The Reset and Interrupt vectors use the majority of the fixed addresses
between 00FFE0 and 00FFFF.
Stack
The Native mode Stack address will always be within the range 000000 to
00FFFF. In the Emulation mode, the Stack address range is 000100 to 0001FF.
The following opcodes and addressing modes can increment or decrement beyond
this range when accessing two or three bytes:
JSL; JSR (a,x); PEA; PEI; PER; PHD; PLD; RTL; d,s; (d,s),y.
Direct
The Direct addressing modes are often used to access memory registers and
pointers. The contents of the Direct Register (D) is added to the offset
contained in the instruction operand to produce an address in the range 000000
to 00FFFF. Note that in the Emulation mode, [Direct] and [Direct],y addressing
modes and the PEI instruction will increment from 0000FE or 0000FF into the
Stack area, even if D=0.
Program Address Space
The Program Bank register is not affected by the Relative, Relative Long,
Absolute, Absolute Indirect, and Absolute Indexed Indirect addressing modes
or by incrementing the Program Counter from FFFF. The only instructions that
affect the Program Bank register are: RTI, RTL, JML, JSL, and JMP Absolute
Long. Program code may exceed 64K bytes altough code segments may not span
bank boundaries.
Data Address Space
The data address space is contiguous throughout the 16 MByte address space.
Words, arrays, records, or any data structures may span 64K byte bank
boundaries with no compromise in code efficiency. As a result, indexing from
page FF in the G65SC802 may result in data accessed in page zero. The
following addressing modes generate 24-bit effective addresses.
* Direct Indexed Indirect (d,x)
* Direct Indirect Indexed (d),y
* Direct Indirect (d)
* Direct Indirect Long [d]
* Direct Indirect Indexed Long [d],y
* Absolute
* Absolute,x
* Absolute,y
* Absolute long
* Absolute long indexed
* Stack Relative Indirect Indexed (d,s),y
The following addressing mode descriptions provide additional detail as
to how effective addresses are calculated.
Twenty-four addressing modes are available for use with the G65SC802
and G65SC816 microprocessors. The "long" addressing modes may be
used with the G65SC802; however, the high byte of the address is not
available to the hardware. Detailed descriptions of the 24 addressing
modes are as follows:
1. Immediate Addressing -- #
The operand is the second byte (second and third bytes when in the 16-bit
mode) of the instruction.
2. Absolute -- a
With Absolute addressing the second and third bytes of the instruction form
the low-order 16 bits of the effective address. The Data Bank Register
contains the high-order 8 bits of the operand address.
__________________________
Instruction: | opcode | addrl | addrh |
~~~~~~~~~~~~~~~~~~~~~~~~~~
Operand
Address: | DB | addrh | addrl |
3. Absolute Long -- al
The second, third, and fourth byte of the instruction form the 24-bit
effective address.
__________________________________
Instruction: | opcode | addrl | addrh | baddr |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Operand
Address: | baddr | addrh | addrl |
4. Direct -- d
The second byte of the instruction is added to the Direct Register
(D) to form the effective address. An additional cycle is required
when the Direct Register is not page aligned (DL not equal 0). The
Bank register is always 0.
___________________
Instruction: | opcode | offset |
~~~~~~~~~~~~~~~~~~~
| Direct Register |
+ | offset |
---------------------
Operand
Address: | 00 | effective address |
5. Accumulator -- A
This form of addressing always uses a single byte instruction. The
operand is the Accumulator.
6. Implied -- i
Implied addressing uses a single byte instruction. The operand is implicitly
defined by the instruction.
7. Direct Indirect Indexed -- (d),y
This address mode is often referred to as Indirect,Y. The second byte of the
instruction is added to the Direct Register (D). The 16-bit contents of this
memory location is then combined with the Data Bank register to form a 24-bit
base address. The Y Index Register is added to the base address to form the
effective address.
___________________
Instruction: | opcode | offset |
~~~~~~~~~~~~~~~~~~~
| Direct Register |
+ | offset |
---------------------
| 00 | direct address |
then:
| 00 | (direct address) |
+ | DB |
-------------------------------
| base address |
+ | | Y Reg |
------------------------------
Operand
Address: | effective address |
8. Direct Indirect Indexed Long -- [d],y
With this addressing mode the 24-bit base address is pointed to by
the sum of the second byte of the instruction and the Direct
Register The effective address is this 24-bit base address plus the Y
Index Register
___________________
Instruction: | opcode | offset |
~~~~~~~~~~~~~~~~~~~
| Direct Register |
+ | offset |
---------------------
| 00 | direct address |
then:
| (direct address) |
+ | | Y Reg |
------------------------------
Operand
Address: | effective address |
9. Direct Indexed Indirect -- (d,x)
This address mode is often referred to as Indirect X The second
byte of the Instruction is added to the sum of the Direct Register
and the X Index Register. The result points to the low-order 16 bits
of the effective address. The Data Bank Register contains the high-
order 8 bits of the effective address.
___________________
Instruction: | opcode | offset |
~~~~~~~~~~~~~~~~~~~
| Direct Register |
+ | offset |
---------------------
| direct address |
+ | | X Reg |
---------------------
| 00 | address |
then:
| 00 | (address) |
+ | DB |
-------------------------------
Operand
Address: | effective address |
10. Direct Indexed With X -- d,x
The second byte of the instruction is added to the sum of the Direct Register
and the X Index Register to form the 16-bit effective address. The operand is
always in Bank 0.
___________________
Instruction: | opcode | offset |
~~~~~~~~~~~~~~~~~~~
| Direct Register |
+ | offset |
---------------------
| direct address |
+ | | X Reg |
-------------------------------
Operand
Address: | 00 | effective address |
11. Direct Indexed With Y -- d,y
The second byte of the instruction is added to the sum of the Direct Register
and the Y Index Register to form the 16-bit effective address. The operand is
always in Bank 0.
___________________
Instruction: | opcode | offset |
~~~~~~~~~~~~~~~~~~~
| Direct Register |
+ | offset |
---------------------
| direct address |
+ | | Y Reg |
-------------------------------
Operand
Address: | 00 | effective address |
12. Absolute Indexed With X -- a,x
The second and third bytes of the instruction are added to the
X Index Register to form the low-order 16 bits of the ef~ective ad-
dress The Data Bank Register contains the high-order 8 bits of the
effective address
____________________________
Instruction: | opcode | addrl | addrh |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| DB | addrrh | addrl |
+ | | X Reg |
-------------------------------
Operand
Address: | effective address |
13. Absolute Indexed With Y -- a,y
The second and third bytes of the instruction are added to the
Y Index Register to form the low-order 16 bits of the eftective ad-
dress The Data Bank Register contains the high-order 8 bits of tne
effective address.
____________________________
Instruction: | opcode | addrl | addrh |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| DB | addrrh | addrl |
+ | | Y Reg |
-------------------------------
Operand
Address: | effective address |
14. Absolute Long Indexed With X -- al,x
The second third and fourth bytes ot the instruction form a 24-bit base
address. The effective address is the sum of this 24-bit address and the
X Index Register.
____________________________________
Instruction: | opcode | addrl | addrh | baddr |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| baddr | addrrh | addrl |
+ | | X Reg |
-------------------------------
Operand
Address: | effective address |
15. Program Counter Relative -- r
This address mode referred to as Relative Addressing is used only with the
Branch instructions. If the conditlon being tested is met, the second byte
of the instruction is added to the Program Counter, which has been updated
to point to the opcode of the next instruction. The offset is a signed 8-bit
quantity in the range from -128 to 127 The Program Bank Register is not
affected.
16. Program Counter Relative Long -- rl
This address mode referred to as Relative Long Addressing is used only with
the Unconditional Branch Long instruction (BRL) and the Push Effective
Relative instruction (PER). The second and third 2 bytes of the instruction
are added to the Program Counter which has been updated to point to the opcode
of the next instruction. With the branch instruction the Program Counter is
loaded with the result With the Push Effective Relative instruction the result
is stored on the stack. The offset and result are both an unsigned 16-bit
quantity in the range 0 to 65535.
17. Absolute Indirect -- (a)
The second and third bytes of the instruction form an address to a pointer
in Bank 0. The Program Counter is loaded with the first and second bytes at
this pointer With the Jump Long (JML) instruction the Program Bank Register
is loaded with the third byte of the pointer
____________________________
Instruction: | opcode | addrl | addrh |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| baddr | addrrh | addrl |
Indirect Address = | 00 | addrh | addrl |
New PC = (indirect address)
with JML:
New PC = (indirect address)
New PB = (indirect address +2)
18. Direct Indirect -- (d)
The second byte of the instruction is added to the Direct Register to form
a pointer to the low-order 16 bits of the effective address. The Data Bank
Register contains the high-order 8 bits of the effective address.
___________________
Instruction: | opcode | offset |
~~~~~~~~~~~~~~~~~~~
| Direct Register |
+ | offset |
---------------------
| 00 | direct address |
then:
| 00 | (direct address) |
+ | DB |
-------------------------------
Operand
Address: | effective address |
19. Direct Indirect Long -- [d]
The second byte of the instruction is added to the Direct Register to form
a pointer to the 24-bit effective address.
___________________
Instruction: | opcode | offset |
~~~~~~~~~~~~~~~~~~~
| Direct Register |
+ | offset |
---------------------
| 00 | direct address |
then:
-------------------------------
Operand
Address: | (direct address) |
20. Absolute Indexed Indirect -- (a,x)
The second and third bytes of the instruction are added to the X Index
Register to form a 16-bit pointer in Bank 0. The contents of this pointer
are loaded in the Program Counter. The Program Bank Register is not changed.
____________________________
Instruction: | opcode | addrl | addrh |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| addrrh | addrl |
+ | | X Reg |
-------------------------------
| 00 | address |
then:
PC = (address)
21. Stack -- s
Stack addressing refers to all instructions that push or pull data from the
stack such as Push, Pull, Jump to Subroutine, Return from Subroutine,
Interrupts, and Return from Interrupt. The bank address is always 0.
Interrupt Vectors are always fetched from Bank 0.
22. Stack Relative -- d,s
The low-order 16 bits of the effective address is formed from the sum of the
second byte of the instruction and the Stack Pointer. The high-order 8 bits
of the effective address is always zero. The relative offset is an unsigned
8-bit quantity in the range of 0 to 255.
___________________
Instruction: | opcode | offset |
~~~~~~~~~~~~~~~~~~~
| Stack Pointer |
+ | offset |
---------------------
| 00 | effective address |
23. Stack Relative Indirect Indexed -- (d,s),y
The second byte of the instruction is added to the Stack Pointer to form
a pointer to the low-order 16-bit base address in Bank 0. The Data Bank
Register contains the high-order 8 bits of the base address. The effective
address is the sum of the 24-bit base address and the Y Index Register.
___________________
Instruction: | opcode | offset |
~~~~~~~~~~~~~~~~~~~
| Stack Pointer |
+ | offset |
---------------------
| 00 | S + offset |
then:
| S + offset |
+ | DB |
-------------------------------
| base address |
+ | | Y Reg |
------------------------------
Operand
Address: | effective address |
24. Block Source Bank, Destination Bank -- xyc
This addressing mode is used by the Block Move instructions.
The second byte of the instruction contains the high-order 8 bits of the
destination address.
The Y Index Register contains the low-order 16 bits of the destination
address. The third byte of the instruction contains the high-order 8 bits
of the source address.
The X Index Register contains the low-order 16 bits of the source address.
The Accumulator contains one less than the number of bytes to move.
The second byte of the block move instructions is also loaded into the Data
Bank Register.
____________________________
Instruction: | opcode | dstbnk | srcbnk |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dstbnk -> DB
Source Address: | scrbnk | X reg |
Destination Address: | DB | Y reg |
Increment (MVN) or decrement (MVP) X and Y.
Decrement A (if greaterthan zero) then PC-3 -> PC.

823
files/docs/snes/65816/detailop.txt Normal file
View File

@ -0,0 +1,823 @@
Table 9. Detailed Instruction Operation
ADDRESS MODE
CYCLE /VP /ML VDA VPA ADDRESS BUS DATA BUS R/W
1 Immediate -- #
(LDY,CPY,CPX,LDX,ORA,AND,EOR,ADC,BIT,LDA,CMP,SBC,REP,SEP)
(14 Op Codes)
(2 and 3 bytes)
(2 and 3 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 IDL 1
2a 1 1 0 1 PBR,PC+2 IDH 1
2a Absolute -- a
(BIT,STY,STZ,LDY,CPY,CPX,STX,LDX,ORA,AND,EOR,ADC,STA,LDA,CMP,SBC)
(16 Op Codes)
(3 bytes)
(4 and 5 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 AAL 1
3 1 1 0 1 PBR,PC+2 AAH 1
4 1 1 1 0 DBR,AA Data Low 1/0
(1) 4a 1 1 1 0 DBR,AA+1 Data High 1/0
2b Absolute (R-M-W) -- a
(ASL,ROL,LSR,ROR,DEC,INC,TSB,TRB)
(8 Op Codes)
(3 bytes)
(6 and 8 cycles)
1 1 1 1 1 PBA,PC Op Code 1
2 1 1 0 1 PBR,PC+1 AAL 1
3 1 1 0 1 PBR,PC+2 AAH 1
4 1 0 1 0 DBR,AA Data Low 1
(1) 4a 1 0 1 0 DBR,AA+1 Data High 1
(3) 5 1 0 0 0 DBR,AA+2 IO 1
(1) 6a 1 0 1 0 DBR,AA+3 Data Hiqh 0
6 1 0 1 0 DBR,AA Data Low 0
2c Absolute(JUMP) -- a
(JMP)(4C)
(1 Op Code)
(3 bytes)
(3 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 NEW PCL 1
3 1 1 0 1 PBR,PC+2 NEW PCH 1
1 1 1 1 1 PBR,NEWPC New Op Code 1
2d Absolute (Jump to subroutine) -- a
(JSR)
(1 Op Code)
(3 bytes)
(6 cycles)
(different order from N6502)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBA,PC+1 NEW FCC 1
3 1 1 0 1 PBR,PC+2 NEW PCH 1
4 1 1 0 0 PBR,PC+2 IO 1
5 1 1 1 0 0,S PCH 0
6 1 1 1 0 0,S-1 PCL 0
1 1 1 1 1 PBA,NEWPC New Op Code 1
3a Absolute Long -- al
(ORA,AND,EOR,ADC,STA,LDA,CMP,SBC)
(8 Op Codes)
(4 bytes)
(5 and 6 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 AAL 1
3 1 1 0 1 PBR,PC+2 AAH 1
4 1 1 0 1 PBR,PC+3 AAB 1
5 1 1 1 0 AAB,AA Data Low 1/0
(1) 5a 1 1 1 0 AAB,AA+1 Data High 1/0
3b Absolute Long (JUMP) -- al
(JMP)
(1 Op Code)
(4 bytes)
(4 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 NEW PCL 1
3 1 1 0 1 PBR,PC+2 NEW PCH 1
4 1 1 0 1 PBR,PC+3 NEW BR 1
1 1 1 1 1 NEW PBR,PC New Op Code 1
3c Absolute Long (Jump to Subroutine Long) -- al
(JSL)
(1 Op Code)
(4 bytes)
(7 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 NEW PCL 1
3 1 1 0 1 PBR,PC+2 NEW PCH 1
4 1 1 1 0 0,S PBR 0
5 1 1 0 0 0,S IO 1
6 1 1 0 1 PBR,PC+3 NEW PBR 1
7 1 1 1 0 0,S-1 PCH 0
8 1 1 1 0 0,S-2 FCL 0
1 1 1 1 1 NEW PBR,PC New Op Code 1
4a Direct -- d
(BIT,STZ,STY,LDY,CPY,CPX,STX,LDX,ORA,AND,EOR,ADC,STA,LDA,CMP,SBC)
(16 Op Codes)
(2 bytes)
(3,4 and 5 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 DO 1
(2) 2a 1 1 0 0 PBR,PC+2 IO 1
3 1 1 1 0 0,D+DO Data Low 1/0
(1) 3a 1 1 1 0 0,D+DO+1 Data High 1/0
4b Direct (R-M-W) -- d
(ASL,ROL,LSR,ROR,DEC,INC,TSB,TRB)
(8 Op Codes)
(2 bytes)
(5,6,7 and 8 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 DO 1
(2) 3a 1 1 0 0 PBR,PC+1 IO 1
3 1 0 1 0 0,D+DO Data Low 1
(1) 3a 1 0 1 0 0,D+DO+1 Data High 1
(3) 4 1 0 0 0 0,D+DO+1 IO 1
(1) 5a 1 0 1 0 0,D+D0+1 Data High 0
5 1 0 1 0 0,D+DO Data Low 0
5 Accumurator -- A
(ASL,INC,ROL,DEC,LSR,ROR)
(6 Op Codes)
(1 byte)
(2 cycles)
1 1 1 1 1 PBR,PC Op COde 1
2 1 1 0 0 PBR,PC+1 IO 1
6a Implied -- i
(DEY,INY,INX,DEX,NOP,XCE,TYA,TAY,TXA,TXS,TAX,TSX,TCS,TSC,TCD,TDC,
TXY,TYX,CLC,SEC,CLI,SEI,CLV,CLD,SED)
(25 Op Codes)
(1 byte)
(2 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 0 PBR,PC+1 IO 1
*6b Implied -- i
(XBA)
(1 Op Code)
(1 byte)
(3 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 0 PBR,PC+1 IO 1
3 1 1 0 0 PBR,PC+1 IO 1
ADDRESS MODE
CYCLE /VP /ML VDA VPA RDY ADDRESS BUS DATA BUS R/W
6c Wait for Interrupt
(WAI)
(1 Op Code)
(1 byte)
(3 cycles)
1 1 1 1 1 1 PBR,PC Op Code 1
(9) 2 1 1 0 0 1 PBR,PC+1 IO 1
3 1 1 0 0 0 PBR,PC+1 IO 1
IRQ,NMI 1 1 1 1 1 1 PBR,PC+1 IRO(BRK) 1
6d Stop-The-Clock
(STP)
(1 Op Code)
(1 byte)
(3 cycles)
1 1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 0 1 PBR,PC+1 IO 1
RES=1 3 1 1 0 0 1 PBR,PC+1 IO 1
RES=0 1c 1 1 0 0 1 PBR,PC+1 RES(BRK) 1
RES=0 1b 1 1 0 0 1 PBR,PC+1 RES(BRK) 1
RES=1 1a 1 1 0 0 1 PBR,PC+1 RES(BRK) 1
1 1 1 1 1 1 PBR,PC+1 BEGIN 1
See 21a Stack (Hardware interrupt)
ADDRESS MODE
CYCLE /VP /ML VDA VPA ADDRESS BUS DATA BUS R/W
7 Direct Indirect Indexed -- (d),y
(ORA,AND,EOR,ADC,STA,LDA,CMP,SBC)
(8 Op Codes)
(2 bytes)
(5,6,7 and 8 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 DO 1
(2) 2a 1 1 0 0 PBR,PC+1 IO 1
3 1 1 1 0 0,D+DO AAL 1
4 1 1 1 0 0,D+DO+1 AAH 1
(4) 4a 1 1 0 0 DBR,AAH,AAL+YL IO 1
5 1 1 1 0 DBR,AA+Y Data Low 1/0
(1) 5a 1 1 1 1 DBR,AA+Y+1 Data High 1/0
8 Direct Indirect Indexed Long -- [d],y
(ORA,AND,EOR,ADC,STA,LDA,CMP,SBC)
(8 Op Codes)
(2 bytes)
(6,7 and 8 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 DO 1
(2) 2a 1 1 0 0 PBR,PC+1 IO 1
3 1 1 1 0 0,D+DO AAL 1
4 1 1 1 0 0,D+DO+1 AAH 1
5 1 1 1 0 0,D+DO+2 AAB 1
6 1 1 1 0 AAB,AA+Y Data Low 1/0
(1) 6a 1 1 1 0 AAB,AA+Y+1 Data High 1/0
9 Direct Indexed Indirect -- (d,x)
(ORA,AND,EOR,ADC,STA,LDA,CMP,SBC)
(8 Op Codes)
(2 bytes)
(6,7 and 8 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 DO 1
(2) 2a 1 1 0 0 PBR,PC+1 IO 1
3 1 1 0 0 PBR,PC+1 IO 1
a 1 1 1 0 0,D+DO+X AAL 1
5 1 1 1 0 0,D+DO+X+1 AAH 1
6 1 1 1 0 DBR,AA Data Low 1/0
(1) 6a 1 1 1 0 DBR,AA+1 Data High 1/0
10a Direct,X -- d,x
(BIT,STZ,STY,LDY,ORA,AND,EOR,ADC,STA,LDA,CMP,SBC)
(12 Op Codes)
(2 bytes)
(4,5 and 6 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 DO 1
(2) 2a 1 1 0 0 PBR,PC+1 IO 1
3 1 1 0 0 PBR,PC+1 IO 1
4 1 1 1 0 0,D+DO+X Data Low 1/0
(1) 4a 1 1 1 0 0,D+DO+X+1 Data High 1/0
10b Direct,X (R-M-W) -- d,x
(ASL,ROL,LSR,ROR,DEC,INC)
(6 Op Codes)
(2 bytes)
(6,7,8 and 9 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 DO 1
(2) 2a 1 1 0 0 PBR,PC+1 IO 1
3 1 1 0 0 PBR,PC+1 IO 1
4 1 0 1 0 0,D+DO+X Data Low 1
(1) 4a 1 0 1 0 0,D+DO+X+1 Data High 1
(3) 5 1 0 0 0 0,D+DO+X+1 IO 1
(1) 6a 1 0 1 0 0,D+DO+X+1 Data High 0
6 1 0 1 0 0,D+DO+X Data Low 0
11 Direct,Y -- d,y
(STX,LDX)
(2 Op Codes)
(2 bytes)
(4,5 and 6 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 DO 1
(2) 2a 1 1 0 0 PBR,PC+1 IO 1
3 1 1 0 0 PBR,PC+1 IO 1
4 1 1 1 0 0,D+DO+Y Data Low 1/0
(1) 4a 1 1 1 0 0,D+DO+Y+1 Data High 1/0
12a Absolute,X -- a,x
(BlT,LDY,STZ,ORA,AND,EOR,ADC,STA,LDA,CMP,SBC)
(11 Op Codes)
(3 bytes)
(4,5 and 6 cycles)
1 1 1 1 1 PBR,PC Op code 1
2 1 1 0 1 PBR,PC+1 AAL 1
3 1 1 0 1 PBR,PC+2 AAH 1
(4) 3a 1 1 0 0 DBR,AAH,AAL+XL IO 1
4 1 1 1 0 DBR,AA+X Data Low 1/0
(1) 4a 1 1 1 0 DBR,AA+X+1 Data High 1/0
12b Absolute,X (R-M-W) -- a,x
(ASC,ROL,LSR,ROR,DEC,INC)
(6 Op Codes)
(3 bytes)
(7 and 9 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 AAL 1
3 1 1 0 1 PBR,PC+2 AAH 1
4 1 1 0 0 DBR,AAH,AAL+XL IO 1
5 1 0 1 0 DBR,AA+X Data Low 1
(1) 5a 1 0 1 0 DBR,AA+X+1 Data High 1
(3) 6 1 0 0 0 DBR,AA+X+1 lO 1
(1) 7a 1 0 1 0 DBR,AA+X+1 Data High 0
7 1 0 1 0 DBR,AA+X Data Low 0
*13 Absolute Long,X -- al,x
(ORA,AND,EOR,ADC,STA,LDA,CMP,SBC)
(8 Op Codes)
(4 bytes)
(5 and 6 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 AAL 1
3 1 1 0 1 PBR,PC+7 AAH 1
4 1 1 0 1 PBA,PC+3 AAB 1
5 1 1 1 0 AAB,AA+X Data Low 1/0
(1) 5a 1 1 1 0 AAB,AA+X+1 Data High 1/0
14 Absolute,Y -- a,y
(LDX,ORA,AND,EOR,ADC,STA,LDA,CMP,SBC)
(9 Op Codes)
(3 bytes)
(4,5 and 6 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 AAL 1
3 1 1 0 1 PBR,PC+2 AAH 1
(4) 3a 1 1 0 0 DBR,AAH,AAL+YL IO 1
4 1 1 1 0 DBR,AA+Y Data Low 1/0
(1) 4a 1 1 1 0 DBR,AA+Y+1 Data High 1/0
15 Relative -- r
(BPL,BMI,BVC,BVS,BCC,BCS,BNE,BEQ,BRA)
(9 Op Codes)
(2 bytes)
(2,3 and 1 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 Offset 1
(5) 2a 1 1 0 0 PBR,PC+2 IO 1
(61 2b 1 1 0 0 PBR,PC+2+OFF IO 1
1 1 1 1 1 PBR,NewPC New Op Code 1
*16 Relative Long -- rl
(BRL)
(1 Op Code)
(3 bytes)
(4 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 Offset Low 1
3 1 1 0 1 PBR,PC+2 Offset High 1
4 1 1 0 0 PBR,PC+2 IO 1
1 1 1 1 1 PBR,NewPC New Op Code 1
17a Absolute Indirect -- (a)
(JMP)
(1 Op Code)
(3 bytes)
(5 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 AAL 1
3 1 1 0 1 PBR,PC+2 AAH 1
4 1 1 1 0 0,AA NEW PCL 1
5 1 1 1 0 0,AA+1 NEW PCH 1
1 1 1 1 1 PBR,NewPC New Op Code 1
*17b Absolute Indirect -- (a)
(JML)
(1 Op Code)
(3 bytes)
(6 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 AAL 1
3 1 1 0 1 PBR,PC+1 AAH 1
4 1 1 1 0 0,AA NEW PCL 1
5 1 1 1 0 0,AA+1 NEW PCH 1
6 1 1 1 0 0,AA+2 NEW PBR 1
1 1 1 1 1 NEW PBR,PC New Op Code 1
**18 Direct Indirect -- (d)
(ORA,AND,EOR,ADC,STA,LDA,CMP,SBC)
(8 Op Codes)
(2 bytes)
(5,6 and 7 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 DO 1
(2) 2a 1 1 0 0 PBR,PC+1 IO 1
3 1 1 1 0 0,D+DO AAL 1
1 1 1 1 0 0,D+DO+1 AAH 1
5 1 1 1 0 DBR,AA Data Low 1/0
(1) 5a 1 1 1 0 DBR,AA+1 Data Low 1/0
*19 Direct Indirect Long -- [d]
(ORA,AND,EOR,ADC,STA,LDA,CMP,SBC)
(8 Op Codes)
(2 bytes)
(6,7 and 8 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 DO 1
(2) 2a 1 1 0 0 PBR,PC+1 IO 1
3 1 1 1 0 0,D+DO AAL 1
4 1 1 1 0 0,D+DO+1 AAH 1
5 1 1 1 0 0,D+DO+2 AAB 1
6 1 1 1 0 AAB,AA Data Low 1/0
(1) 6a 1 1 1 0 AAB,AA+1 Data High 1/0
20a Absolute Indexed Indirect -- (a,x)
(JMP)
(1 Op Code)
(3 bytes)
(6 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 AAL 1
3 1 1 0 1 PBR,PC+2 AAH 1
4 1 1 0 0 PBR,PC+2 IO 1
5 1 1 0 1 PBR,AA+X NEW PCL 1
6 1 1 0 1 PBR,AA+X+1 NEW PCH 1
1 1 1 1 1 PBR,NEWPC New Op Code 1
*20b Absolute Indered Indirect (Jump to Subroutine Indexed Indirect) -- (a,x)
(JSR)
(1 Op Code)
(3 bytes)
(8 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 AAL 1
3 1 1 1 0 0,S PCH 0
4 1 1 1 0 0,S-1 PCL 0
5 1 1 0 1 PBR,PC+2 AAH 1
6 1 1 0 0 PBR,PC+2 IO 1
7 1 1 0 1 PBR,AA+X NEW PCL 1
8 1 1 0 1 PBR,AA+X+1 NEW PCH 1
1 1 1 1 1 PBR,NEWPC New Op Code 1
21a Stack (Hardware Interrupts) -- s
(IRQ,NMI,ABORT,RES)
(4 hardware Interrupts)
(0 bytes)
(7 and 8 cycles)
1 1 1 1 1 PBR,PC IO 1
(3) 2 1 1 0 0 PBR,PC IO 1
(7) 3 1 1 1 0 0,S PBR 0
(10) 4 1 1 1 0 0,S-1 PCH 0
(10) 5 1 1 1 0 0,S-2 PCL 0
(10,11) 6 1 1 1 0 0,S-3 P 0
7 0 1 1 0 0,VA AAVL 1
8 0 1 1 0 0,VA+1 AAVH 1
1 1 1 1 1 0,AAV New Op Code 1
21b Stack (Software Interrupts) -- s
(BRK,COP)
(2 Op Codes)
(2 bytes)
(7 and 8 cycles)
1 1 1 1 1 PBR,PC Op Code 1
(3) 2 1 1 0 1 PBR,PC+1 Signature 1
(7) 3 1 1 1 0 0,S PBR 0
4 1 1 1 0 0,S-1 PCH 0
5 1 1 1 0 0,S-2 PCL 0
6 1 1 1 0 0,S-3 (COP Latches) P 0
7 0 1 1 0 0,VA AAVL 1
8 0 1 1 0 0,VA+1 AAVH 1
1 1 1 1 1 0,AAV New Op Code 1
21c Stack (Return from Interrupt) -- s
(RTI)
(1 Op Code)
(1 byte)
(6 and 7 cycles)
(different order from N6502)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 0 PBR,PC+1 IO 1
(3) 3 1 1 0 0 PBR,PC+1 IO 1
4 1 1 1 0 0,S+1 P 1
5 1 1 1 0 0,S+2 New PCL 1
6 1 1 1 0 0,S+3 New PCH 1
(7) 7 1 1 1 0 0,S+4 PBR 1
1 1 1 1 1 PBR,NewPC New Op Code 1
21d Stack (Return from Subroutine) -- s
(RTS)
(1 Op Code)
(1 byte)
(6 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 0 PBR,PC+1 IO 1
3 1 1 0 0 PBR,PC+1 IO 1
4 1 1 1 0 0,S+1 New PCL-1 1
5 1 1 1 0 0,S+2 New PCH 1
6 1 1 0 0 0,S+2 IO 1
1 1 1 1 1 PBR,NewPC New Op Code 1
*21e Stack (Return from Subroutine Long) -- s
(RTL)
(1 Op Code)
(1 byte)
(6 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 0 PBR,PC+1 IO 1
3 1 1 0 0 PBR,PC+1 IO 1
4 1 1 1 0 0,S+1 NEW PCL 1
5 1 1 1 0 0,S+2 NEW PCH 1
6 1 1 1 0 0,S+3 NEW PBR 1
1 1 1 1 1 NEWPBR,PC New Op Code 1
21f Stack (Push) -- s
(PHP,PHA,PHY,PHX,PHD,PHK,PHB)
(7 Op Codes)
(1 byte)
(3 and 4 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 0 PBR,PC+1 IO 1
3a 1 1 1 0 0,S Register High 0
3 1 1 1 0 0,S-1 Register Low 0
21g Stack (Pull) -- s
(PLP,PLA,PLY,PLX,PLD,PLB)
(Different than N6502)
(6 Op Codes)
(1 byte)
(4 and 5 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 0 PBR,PC+1 IO 1
3 1 1 0 0 PBR,PC+1 IO 1
4 1 1 1 0 0,S+1 Register Low 1
(1) 4a 1 1 1 0 0,S+2 Register High 1
*21h Stack (Push Effective Indirect Address) -- s
(PEI)
(1 Op Code)
(2 bytes)
(6 and 7 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 DO 1
(2) 2a 1 1 0 0 PBR,PC+1 IO 1
3 1 1 1 0 0,D+DO AAL 1
d 1 1 1 0 0,D+DO+1 AAH 1
5 1 1 1 0 0,S AAH 0
6 1 1 1 0 0,S-1 AAL 0
*21i Stack (Push Effective Absolute Address) -- s
(PEA)
(1 Op Code)
(3 bytes)
(5 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 AAL 1
3 1 1 0 1 PBR,PC+2 AAH 1
4 1 1 1 0 0,S AAH 0
5 1 1 1 0 0,S-1 AAL 0
*21j Stack (Push Effective Program Counter Relative Address) -- s
(PER)
(1 Op Code)
(3 bytes)
(6 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 Offset Low 1
3 1 1 0 1 PBR,PC+2 Offset High 1
4 1 1 0 0 PBR,PC+2 IO 1
5 1 1 1 0 0,S PCH+Offset+CARRY 0
6 1 1 1 0 0,S-1 PCL + Offset 0
*22 Stace Relative -- d,s
(ORA,AND,EOR,ADC,STA,LDA,CMP,SBC)
(8 Op Codes)
(2 bytes)
(4 and 5 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 SO 1
3 1 1 0 0 PBR,PC+1 IO 1
4 1 1 1 0 0,S+SO Data Low 1/0
(1) 4a 1 1 1 0 0,S+SO+1 Data High 1/0
*23 Stack Relative Indirect Indexed -- (d,s),y
(8 Op Codes)
(2 bytes)
(7 and 8 cycles)
1 1 1 1 1 PBR,PC Op Code 1
2 1 1 0 1 PBR,PC+1 SO 1
3 1 1 0 0 PBR,PC+1 IO 1
4 1 1 1 0 0,S+SO AAL 1
5 1 1 1 0 0,S+SO+1 AAH 1
6 1 1 0 0 0,S+SO+1 IO 1
7 1 1 1 0 DBR,AA+Y Data Low 1/0
(1) 7a 1 1 1 0 DBR,AA+Y+1 Data High 1/0
*24a Block Move Positive (forward) -- xyc
(MVP)
(1 Op Code)
(3 bytes)
(7 cycles)
+- 1 1 1 1 1 PBR,PC Op Code 1
| 2 1 1 0 1 PBR,PC+1 DBA 1
| 3 1 1 0 1 PBR,PC+2 SBA 1
N-2 | 4 1 1 1 0 SBA,X Source Data 1
Byte | 5 1 1 1 0 DBA,Y Dest Data 0
C=2 | 6 1 1 0 0 DBA,Y IO 1
+- 7 1 1 0 0 DBA,Y IO 1
+- 1 1 1 1 1 PBR,PC Op Code 1
| 2 1 1 0 1 PBR,PC+1 DBA 1
N-1 | 3 1 1 0 1 PBR,PC+2 SBA 1
Byte | 4 1 1 1 0 SBA,X-1 Source Data 1
C=1 | 5 1 1 1 0 DBA,Y-1 Dest Data 0
| 6 1 1 0 0 DBA,Y-1 IO 1
+- 7 1 1 0 0 DBA,Y-1 IO 1
+- 1 1 1 1 1 PBR,PC Op Code 1
| 2 1 1 0 1 PBR,PC+1 DBA 1
N Byte | 3 1 1 0 1 PBR,PC+2 SBA 1
Last | 4 1 1 1 0 SBA,X-2 Source Data 1
C=0 | 5 1 1 1 0 DBA,Y-2 Dest Data 0
| 6 1 1 0 0 DBA,Y-2 IO 1
| 7 1 1 0 0 DBA,Y-2 IO 1
+- 1 1 1 1 1 PBR,PC+3 New Op Code 1
x = Source Address
y = Destination
c = Number of Bytes to move -1
x,y Decrement
MVP is used when the destination start address is higher (more positive)
than the source start address.
FFFFFF
^ Dest Start
| Source Start
| Dest End
| Source End
000000
*24b, Block Move Negative (backward) -- xyc
(MVN)
(1 Op Code)
(3 bytes)
(7 cycles)
+- 1 1 1 1 1 PBR,PC Op Code 1
| 2 1 1 0 1 PBR,PC+1 DBA 1
| 3 1 1 0 1 PBR,PC+2 SBA 1
N-2 | 4 1 1 1 0 SBA,X Source Data 1
Byte | 5 1 1 1 0 DBA,Y Dest Data 0
C=2 | 6 1 1 0 0 DBA,Y IO 1
+- 7 1 1 0 0 DBA,Y IO 1
+- 1 1 1 1 1 PBR,PC Op Code 1
| 2 1 1 0 1 PBR,PC+1 DBA 1
N-1 | 3 1 1 0 1 PBR,PC+2 SBA 1
Byte | 4 1 1 1 0 SBA,X+1 Source Data 1
C=1 | 5 1 1 1 0 DBA,Y+1 Dest Data 0
| 6 1 1 0 0 DBA,Y+1 IO 1
+- 7 1 1 0 0 DBA,Y+1 IO 1
+- 1 1 1 1 1 PBR,PC Op Code 1
| 2 1 1 0 1 PBR,PC+1 DBA 1
N Byte | 3 1 1 0 1 PBR,PC+2 SBA 1
Last | 4 1 1 1 0 SBA,X+2 Source Data 1
C=0 | 5 1 1 1 0 DBA,Y+2 Dest Data 0
| 6 1 1 0 0 DBA,Y+2 IO 1
| 7 1 1 0 0 DBA,Y+2 IO 1
+- 1 1 1 1 1 PBR,PC+3 New Op Code 1
x = Source Address
y = Destination
c = Number of Bytes to move -1
x,y Increment
MVN is used when the destination start address is lower (more negative)
than the source start address.
FFFFFF
| Source End
| Dest End
| Source Start
v Dest Start
000000
Notes
(1) Add 1 byte (for immediate only) for M=O or X=O (i.e. 16 bit data),
add 1 cycle for M=O or X=0.
(2) Add 1 cycle for direct register low (DL) not equal 0.
(3) Special case for aborting instruction. This is the last cycle which
may be aborted or the Status, PBR or DBR registers will be updated.
(4) Add 1 cycle for indexing across page boundaries, or write, or X=0.
When X=1 or in the emulation mode, this cycle contains invalid
addresses.
(5) Add 1 cycle if branch is taken.
(6) Add 1 cycle if branch is taken across page boundaries in 6502 emutation
mode (E=1).
(7) Subtract 1 cycle for 6502 emulation mode (E=1).
(8) Add 1 cycle lor REP, SEP.
(9) Wait at cycle 2 for 2 cycles after /NMI or /IRQ active input.
(10) R/W remains high during Reset.
(11) BRK bit 4 equals "0" in Emulation mode.
Abbreviations
AAB Absolute Address Bank
AAH Absolute Address High
AAL Absolute Address Low
AAVH Absolute Address Vector High
AAVL Absolute Address Vector Low
C Accumulator
D Direct Register
DBA Destination Bank Address
DBR Data Bank Register
DO Direct Offset
IDH Immediate Data High
IDL Immediate Data Low
IO Internal Operation
P Status Register
PBR Program Bank Register
PC Program Counter
R-M-W Read-Modify-Write
S Stack Address
SBA Source Bank Address
SO Stack Offset
VA Vector Address
x, y Index Registers
* New G65SC816/802 Addressing Modes
** New G65SC02 Addressing Modes
Blank NMOS 6502 Addressing Modes

BIN
files/docs/snes/65816/diagram.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

72
files/docs/snes/65816/feature.txt Normal file
View File

@ -0,0 +1,72 @@
GTE G 65 SC 802 / G 65 SC 816
Microcircuits
CMOS 8/16-Bit Microprocessor Family
Features
Advanced CMOS design for low power consumption and increased
noise immunity
Emulation mode for total software compatibility with 6502 designs
Full 16-bit ALU, Accumulator, Stack Pointer, and Index Registers
Direct Register for ''zero page'' addressing
24 addressing modes (including 13 original 6502 modes)
Wait for Interrupt (WAI) and Stop the Clock (STP) instructions
for reduced power consumption and decreased interrupt latency
91 instructions with 255 opcodes
Co-Processor (COP) instruction and associated vector
Powerful Block Move instructions
Features (G65SC802 Only)
8-Bit Mode with both software and hardware (pin-to-pin) compatibility
with 6502 designs (64 KByte memory space)
Program selectable 16-bit operation
Choice of external or on-board clock generation
Features (G65SC816 Only)
Full 16-bit operation with 24 address lines for 16 MByte memory
Program selectable 8-Bit Mode for 6502 coding compatibility.
Valid Program Address (VPA) and Valid Data Address (VDA) outputs
for dual cache and DMA cycle steal implementation
Vector Pull (VP) output indicates when interrupt vectors are being
fetched. May be used for vectoring/prioritizing interrupts.
Abort interrupt and associated vector for interrupting any instruction
without modifying internal registers
Memory Lock (ML) for multiprocessor system implementation
General Description
The G65SC802 and G65SC816 are ADV-CMOS (ADVanced CMOS) 16-bit microprocessors
featuring total software compatibility with 8-bit NMOS and CMOS 6500 series
microprocessors. The G65SC802 is pin-to-pin compatible with 8-bit 6502 devices
currently available, while also providing full 16-bit internal operation. The
G65SC816 provides 24 address lines for 16 MByte addressing, while providing
both 8-bit and 16-bit operation.
Each microprocessor contains an Emulation (E) mode for emulating 8-bit NMOS
and CMOS 6500-Series microprocessors. A software switch determines whether the
processor is in the 8-bit ernulation mode or in the Native 16-bit mode.
This allows existing 8-bit system designs to use the many powerful features of
the G65SC802 and G65SC816.
The G65SC802 and G65SC816 provide the system engineer with many powerful
features and options. A 16-bit Direct Page Register is provided to augment the
Direct Page addressing mode, and there are separate Program Bank Registers
for 24-bit memory addressing.
Other valuable features Include:
* An Abort input which can interrupt the current instruction without
modifying internal registers
* Valid Data Address (VDA) and Valid Program Address (VPA) outputs which
facilitate dual cache memory by indicating whether a data or program
segment is being accessed.
* Vector modification by simply monitoring the Vector Pull (VP) output.
* Block Move Instructions
G65SC802 and G65SC816 microprocessors offer the design engineer a new freedom
of design and application, and the many advantages of state-of-the-art
ADV-CMOS technology.
This is advanced information and specifications are subject to change without notice.

455
files/docs/snes/65816/funcdesc.txt Normal file
View File

@ -0,0 +1,455 @@
Functional Description
The G65SC802 offers the design engineer the opportunity to utilize both
existing software programs and hardware configurations, while also
achieving the added advantages of increased register lengths and faster
execution times. The G65SC802's "ease of use" design and implementation
features provide the designer with increased flexibility and reduced
implementation costs In the Emulation mode, the G65SC802 not only offers
software compatibility, but is also hardware (pin-to-pin) compatible with
6502 designs plus it provides the advantages of 16-bit internal operation
in 6502-compatible applications. The G65SC802 is an excellent direct
replacement microprocessor for 6502 designs.
The G65SC816 provides the design engineer with upward mobility and software
compatibility in applications where a 16-bit system configuration is desired.
The G65SC816's 16-bit hardware configuration, coupled with current software
allows a wide selection of system applications. In the Emulation mode, the
G65SC816 ofters many advantages, including full software compatibility with
6502 coding. In addition, the G65SC816's powerful instruction set and
addressing modes make it an excellent choice for new 16-bit designs.
Internal organization of the G65SC802 and G65SC816 can be divided into two
parts: 1) The Register Section, and 2) The Control Section Instructions
(or opcodes) obtained from program memory are executed by implementing a
series of data transfers within the Register Section.
Signals that cause data transfers to be executed are generated within the
Control Section. Both the G65SC802 and the G65SC816 have a 16-bit internal
architecture with an 8-bit external data bus.
Instructlon Register and Decode
An opcode enters the processor on the Data Bus, and is latched into the
Instruction Register during the instruction fetch cycle. This instruction is
then decoded, along with timing and interrupt signals, to generate the
various Instruction Register control signals.
Timing Control Unit (TCU)
The Timing Control Unit keeps track of each instruction cycle as it is
executed. The TCU is set to zero each time an instruction fetch is executed,
and is advanced at the beginning of each cycle for as many cycles as is
required to complete the instruction Each data transfer between registers
depends upon decoding the contents of both the Instruction Register and
the Timing Control Unit.
Arithmetic and Logic Unit (ALU)
All arithmetic and logic operations take place within the 16-bit ALU. In
addition to data operations, the ALU also calculates the effective address
for relative and indexed addressing modes. The result of a data operation
is stored in either memory or an internal register. Carry, Negative, Over-
flow and Zero flags may be updated following the ALU data operation.
Internal Registers (Refer to Figure 2, Programming Model)
Accumulator (A)
The Accumulator is a general purpose register which stores one of the
operands, or the result of most arithmetic and logical operations. In the
Native mode (E=0), when the Accumulator Select Bit (M) equals zero, the
Accumulator is established as 16 bits wide. When the Accumulator Select
Bit (M) equals one, the Accumulator is 8 bits wide. In this case, the upper
8 bits (AH) may be used for temporary storage in conjunction with the
Exchange AH and AL instruction.
Data Bank (DB)
During the Native mode (E=0), the 8-bit Data Bank Register holds the default
bank address for memory transfers. The 24-bit address is composed of the
16-bit instruction effective address and the 8-bit Data Bank address. The
register value is multiplexed with the data value and is present on the
Data/Address lines during the first half of a data transfer memory cycle for
the G65SC816. The Data Bank Register is initialized to zero during Reset.
Direct (D)
The 16-bit Direct Register provides an address offset for all instructions
using direct addressing. The effective bank zero address is formed by adding
the 8-bit instruction operand address to the Direct Register. The Direct
Register is initialized to zero during Reset.
Index (X and Y)
There are two Index Registers (X and Y) which may be used as general purpose
registers or to provide an index value for calculation of the effective
address. When executing an instruction with indexed addressing, the
microprocessor fetches the opcode and the base address, and then modifies the
address by adding the Index Register contents to the address prior to
performing the desired operation.
Pre-indexing or postindexing of Indirect addresses may be selected. In the
Native mode (E=0), both Index Registers are 16 bits wide (providing the Index
Select Bit (X) equals zero). If the Index Select Bit (X) equals one, both
registers will be 8 bits wide.
Processor Status (P)
The 8-bit Processor Status Register contains status flags and mode select bits.
The Carry (C), Negative (N). Overflow (V), and Zero (Z) status flags serve to
report the status ot most ALU operations. These status flags are tested by use
of Conditional Branch instructions. The Decimal (D), IRQ Disable (I), Memory,
Accumuiator (M), and Index (X) bits are used as mode select flags. These flags
are set by the program to change microprocessor operations.
The Emulation (E) select and the Break (B) flags are accessible only through
the Processor Status Register. The Emulation mode select flag is selected by
the Exchange Carry and Emulation Bits (XCE) instruction.
Table 2, G65SC802 and G65SC816 Mode Comparison, illustrates the features of
the Native (E=0) and Emulation (E=1) modes. The M and X flags are always equal
to one in the Emulation mode. When an interrupt occurs during the Emulation
mode, the Break flag is written to stack memory as bit 4 of the Processor
Status Register.
Program Bank (PB)
The 8-bit Program Bank Register holds the bank address for all instruction
fetches. The 24-bit address consists of the 16-bit instruction effective
address and the 8-bit Program Bank address. The register value is multiplexed
with the data value and presented on the Data/Address lines during the first
half of a program memory read cycle. The Program Bank Register is initialized
to zero during Reset.
Program Counter (PC)
The 16-bit Program Counter Register provides the addresses which are used to
step the microprocessor through sequential program instructions. The register
is incremented each time an instruction or operand is fetched from program
memory.
Stack Pointer (S)
The Stack Pointer is a 16-bit register which is used to indicate the next
available location in the stack memory area. It serves as the effective address
in stack addressing modes as well as subroutine and interrupt processing. The
Stack Pointer allows simple implementation of nested subroutines and multiple-
level interrupts. During the Emulation mode, the Stack Pointer high-order byte
(SH) is always equal to 01. The Bank Address is 00 for all Stack operations.
Signal Description
The following Signal Description applies to both the G65SC802 and the
SSC816 except as otherwise noted.
Abort (/ABORT) -- G65SC816
The Abort input prevents modification of any internal registers during
execution of the current instruction. Upon completion of this instruction,
an interrupt sequence is initiated. The location of the aborted opcode is
stored as the return address in Stack memory. The Abort vector address is
00FFF8, 9 (Emulation mode) or 00FFE8, 9 (Native mode). Abort is asserted
whenever there is a low level on the Abort input. and the Phi2 clock is high.
The Abort internal latch is cleared during the second cycle of the interrupt
sequence. This signal may be used to handle out-of-bounds memory references
in virtual memory systems.
Address Bus (A0-A15)
These sixteen output lines form the Address Bus for memory and I/O exchange on
the Data Bus. When using the G65SC816, the address lines may be set to the
high impedance state by the Bus Enable (BE) signal.
Bus Enable (BE)
The Bus Enable input signal allows external control of the Address and Data
Buffers, as well as the R/W signal With Bus Enable high, the R/W and Address
Buffers are active. The Data/Address Buffers are active during the first half
of every cycle and the second half of a write cycle. When BE is low, these
buffers are disabled. Bus Enable is an asynchronous signal.
Data Bus (D0-D7) -- G65SC802
The eight Data Bus lines provide an 8-bit bidirectional Data Bus for use
during data exchanges between the microprocessor and external memory or
peripherals. Two memory cycles are required for the transfer of 16-bit values.
Data/Address Bus (D0/BA0-D7/BA7) -- G65SC816
These eight lines multiplex bits BAO-BA7 with the data value. The Bank Address
is present during the first half of a memory cycle, and the data value is read
or written during the second half of the memory cycle.
The Bank address external transparent latch should be latched when the Phi2
clock is high or RDY is low. Two memory cycles are required to transfer 16-bit
values. These lines may be set to the high impedance state by the Bus Enable
(BE) signal.
Emulation Status (E) -- G65SC816 (Also Applies to G65SC802, 44-Pin Version)
The Emulation Status output reflects the state of the Emulation (E) mode flag
in the Processor Status (P) Register. This signal may be thought of an opcode
extension and used for memory and system management.
Interrupt Request (/IRQ)
The Interrupt Request input signal is used to request that an interrupt
sequence be initiated. When the IRQ Disable (I) flag is cleared, a low input
logic level initiates an interrupt sequence after the current instruction is
completed. The Wait for Interrupt (WAI) instruction may be executed to ensure
the interrupt will be recognized immediately. The Interrupt Request vector
address is 00FFFE,F (Emulation mode) or 00FFEE,F (Native mode). Since IRQ is a
level-sensitive input, an interrupt will occur if the interrupt source was not
cleared since the last interrupt.
Also, no interrupt will occur if the interrupt source is cleared prior to
interrupt recognition.
Memory Lock (/ML) -- G65SC816 (Also Applies to G65SC802, 44-Pin Version)
The Memory Lock output may be used to ensure the integrity of Read-Modify-Write
instructions in a multiprocessor system. Memory Lock indicates the need to
defer arbitration of the next bus cycle. Memory Lock is low during the last
three or five cycles of ASL, DEC, INC, LSR, ROL, ROR, TRB, and TSB memory
referencing instructions, depending the state of the M flag.
Memory/Index Select Status (M/X) -- G65SC816
This multiplexed output reflects the state ot the Accumulator (M) and index (X)
select flags (bits 5 and 4 of the Processor Status (P) Register).
Flag M is valid during the Phi2 clock positive transition. Instructions PLP,
REP, RTI and SEP may change the state of these bits. Note that the M/X output
may be invalid in the cycle following a change in the M or X bits. These bits
may be thought of as opcode extensions and may be used for memory and system
management.
Non-Maskable Interrupt (/NMI)
A high-to-low transition initiates an intenupt sequence after the current
instruction is completed. The Wait for Interrupt (WAI) instruction may be
executed to ensure that the interrupt will be recognized immediately. The
Non-Maskable Interrupt vector address is 00FFFA,B (Emulation mode) or 00FFEA,B
(Native mode). Since NMI is an edge-sensitive Input, an interrupt will occur
if there is a negative transition while servicing a previous interrupt. Also,
no interrupt will occur if NMI remains low.
Phase 1 Out (Phi1 (OUT)) -- G65SC802
This inverted clock output signal provides timing for external read and write
operations. Executing the Stop (STP) instruction holds this clock in the low
state.
Phase 2 In (Phi2 (IN))
This is the system clock input to the microprocessor internal clock generator
(equivalent to Phi0 (IN) on the 6502). During the low power Standby Mode, Phi2
(IN) should be held in the high state to preserve the contents of internal
registers.
Phase 2 Out (Phi2 (OUT)) -- G65SC802
This clock output signal provides timing for external read and write
operations. Addresses are valid (after the Address Setup Time (TADS))
following the negative transition of Phase 2 Out. Executing the Stop (STP)
instruction holds Phase 2 Out in the High state.
Read/Write (R/W)
When the R/W output signal is in the high state, the microprocessor is reading
data from memory or I/O. When in the low state, the Data Bus contains valid
data from the microprocessor which is to be stored at the addressed memory
location. When using the G65SC816, the R/W signal may be set to the high
impedance state by Bus Enable (BE).
Ready (RDY)
This bidirectional signal indicates that a Wait for Interrupt (WAI) instruction
has been executed allowing the user to halt operation of the microprocessor.
A low input logic level will halt the microprocessor in its current state (note
that when in the Emulation mode, the G65SC802 stops only during a read cycle).
Returning RDY to the active high state allows the microprocessor to continue
following the next Phase 2 In Clock negative transition. The RDY signal is
internally pulled low following the execution of a Wait for Interrupt (WAI)
instruction, and then returned to the high state when a /RES, /ABORT, /NMI, or
/IRQ external interrupt is provided. This feature may be used to eliminate
interrupt latency by placing the WAI instruction at the beginning of the IRQ
servicing routine. If the IRQ Disable flag has been set, the next instruction
will be executed when the IRQ occurs. The processor will not stop after a WAI
instruction if RDY has been forced to a high state. The Stop (STP) instruction
has no effect on RDY.
Reset (/RES)
The Reset input is used to initialize the microprocessor and start program
execution. The Reset input buffer has hysteresis such that a simple R-C timing
circuit may be used with the internal pullup device. The /RES signal must be
held low for at least two clock cycles after VDD reaches operating voltage.
Ready (RDY) has no effect while RES is being held low. During this Reset
conditioning period, the following processor initialization takes place:
Registers
D = 0000 SH = 01
DB = 00 XH = 00
PB = 00 YH = 00
N V M X D I Z C/E
P = * * 1 1 0 1 * */1
* = Not Initialized
STP and WAI instructions are cleared.
Signals
E = 1 VDA = 0
M/X = 1 /VP = 1
R/W = 1 VPA = 0
SYNC = 0
When Reset is brought high, an interrupt sequence is initiated:
* R/W remains in the high state during the stack address cycles.
* The Reset vector address is 00FFFC,D.
Set Overtlow (/SO) -- G65SC802
A negative transition on this input sets the Overflow (V) flag, bit 6 of the
Processor Status (P) Register.
Synchronlze (SYNC) -- G65SC802
The SYNC output is provided to identify those cycles during which the
microprocessor is fetching an opcode. The SYNC signal is high during an opcode
fetch cycle, and when combined with Ready (RDY), can be used for single
instruction execution.
Valid Data Address (VDA) and
Valid Program Address (VPA) -- G65SC816
These two output signals indicate the type of memory being accessed by
the address bus. The following coding applies:
VDA VPA
0 0 Internal Operation -- Address and Data Bus available. Address
outputs may be invalid due to low byte additions only.
0 1 Valid program address -- may be used for program cache control.
1 0 Valid data address -- may be used for data cache control.
1 1 Opcode fetch -- may be used for program cache control
and single step control.
VDD and Vss
VDD Vss the positive supply voltage and Vss is system ground. When
using only one ground on the G65SC802 DIP package, pin 21 preferred.
Vector Pull (VP) -- G65SC816 (Also Applies to G65SC802 44-Pin Version)
The Vector Pull output indicates that a vector location is being addressed
during an interrupt sequence. /VP is low during the last two interrupt sequence
cycles, during which time the processor reads the interrupt vector. The /VP
signal may be used to select and prioritize interrupts from several sources by
modifying the vector addresses.
--------------------------------------------------------------------------
8 bits 8 bits 8 bits
DB DB Data Bank Register
XH XL Index Register (X)
YH YL Index Register (Y)
00 SH SL Stack Pointer (S)
AH AL Accumulator (A)
PB PCH PCL Program Counter (PC)
Program Bank Register (PB)
00 DH DL Direct Register (D)
L = Low, H = High
Processor Status Register (P)
____________________________
| 1 B E |
|__________________________|
| N V M X D I Z C |
|__________________________|
1 Always 1 if E=1
B Break 0 on Stack after interupt if E=1
E Emulation Bit 0= Native mode, 1= 6502 emulation
N Negative 1= Negative
V Overflow 1= True
M Memory/Acc. Select 1= 8 bit, 0= 16 bit
X Index Register Select 1= 8 bit, 0= 16 bit
D Decimal mode 1= Decimal Mode
I IRQ Disable 1= Disable
Z Zero 1= Result Zero
C Carry 1= True
Figure 2. Programming model
--------------------------------------------------------------------------
Table 1. G65SC802 and G65SC816 Compability
Function G65SC802/816 G65SC02 NMOS 6502
Emulation
Decimal Mode:
* After Interrupts 0 -> D 0 -> D Not initialized
* N, Z Flags Valid Valid Undefined
* ADC, SBC No added cycle Add 1 cycle No added cycle
Read-Modify-Write:
* Absolute Indexed, No Page Crossing
7 cycles 6 cycles 7 cycles
* Write Last 2 cycles Last cycle Last 2 cycles
* Memory Lock Last 3 cycles Last 2 cycles Not available
Jump Indirect:
* Cycles 5 cycles 6 cycles 5 cycles
* Jump Address, operand = xxFF Correct Correct Invalid
Branch or Index Across Page Boundary
Read last Read last Read invalid
program byte program byte address
0 -> RDY During Write G65SC802: Ignored Processor Ignored until
until read stops read
G65SC816: Processor
stops
Write During Reset No Yes No
Unused Opcodes No operation No operation Undefined
Phi1 (OUT), Phi2 (OUT), /SO, SYNC Signals
Available with Available Available
G65SC802 only
RDY Signal Bidirectional Input Input
--------------------------------------------------------------------------
Table 2. G65SC802 and G65SC816 Mode Comparison
Function Emulation (E = 1) Native (E = 0)
Stack Pointer (S) 8 bits in page 1 16 bits
Direct Index Address Wrap within page Crosses page boundary
Processor Status (P):
* Bit 4 Always one, except zero X flag (8/16-bit Index)
in stack after hardware
interrupt
* Bit 5 Always one M flag (8/16-bit Accumulator)
Branch Across Page Boundary
4 cycles 3 cycles
Vector Locations:
ABORT 00FFF8,9 00FFF8,9
BRK 00FFFE,F 00FFF6,7
COP 00FFF4,5 00FFF4,5
IRQ 00FFFE,F 00FFFE,F
NMI 00FFFA,B 00FFFA,B
RES 00FFFC,D 00FFFC,D (1 -> E)
Program Bank (PB) During Interrupt, RTI
Not pushed, pulled Pushed and pulled
0 -> RDY During Write
G65SC802: Ignored until read Processor stops
G65SC816: Processor stops
Write During Read-Modify-Write
Last 2 cycles Last 1 or 2 cycles depending
on M flag

91
files/docs/snes/65816/instnote.txt Normal file
View File

@ -0,0 +1,91 @@
Notes on G65SC802/816 Instructions
All Opcodes Function in All Modes of Operation
It should be noted that all opcodes function in all modes of operation.
However, some instructions and addressing modes are intended for G65SC816
24-bit addressing and are therefore less useful for the G65SC802. The
following is a list of Instructions and addressing modes which are primarily
intended for G65SC816 use:
JSL; RTL; [d]; [d],y; JMP al; JML; al; al,x
The following instructions may be used with the G65SC802 even though a
Bank Address is not multiplexed on the Data Bus:
PHK; PHB; PLB
The following instructions have "limited" use in the Emulation mode.
* The REP and SEP instructions cannot modify the M and X bits when in the
Emulation mode. In this mode the M and X bits will always be high (logic 1).
* When in the Emulation mode, the MVP and MVN instructions only move data
in page zero since X and Y Index Register high byte is zero.
Indirect Jumps
The JMP (a) and JML (a) instructions use the direct Bank for indirect
addressing, while JMP (a,x) and JSR (a,x) use the Program Bank for indirect
address tables.
Switching Modes
When switching from the Native mode to the Emulation mode, the X and M bits
of the Status Register are set high (logic 1), the high byte of the Stack is
set to 01, and the high bytes of the X and Y Index Registers are set to 00.
To save previous values, these bytes must always be stored before changing
modes. Note that the low byte of the S, X and Y Registers and the low and high
byte of the Accumulator AL and AH are not affected by a mode change.
WAI Instruction
The WAI instruction pulls RDY low and places the processor in the WAI
"low power" mode. /NMI, /IRQ or /RESET will terminate the WAI condition and
transfer control to the interrupt handler routine. Note that an /ABORT input
will abort the WAI instruction, but will not restart the processor. When the
Status Register I flag is set (IRQ disabled), the IRQ interrupt will cause the
next instruction (following the WAI instruction) to be executed without going
to the IRQ interrupt handler. This method results in the highest speed response
to an IRQ input. When an interrupt is received after an ABORT which occurs
during the WAI instruction, the processor will return to the WAI instruction.
Other than RES (highest priority), ABORT is the next highest priority, followed
by NMI or IRQ interrupts.
STP Instruction
The STP instruction disables the Phi2 clock to all circuitry. When disabled,
the Phi2 clock is held in the high state. In this case, the Data Bus will
remain in the data transfer state and the Bank address will not be multiplexed
onto the Data Bus. Upon executing the STP instruction, the /RES signal is the
only input which can restart the processor. The processor is restarted by
enabling the Phi2 clock, which occurs on the falling edge of the /RES input.
Note that the external oscillator must be stable and operating properly before
RES goes high.
Tranters trom 8-Bit to 16-Bit, or 16-Bit to 8-Bit Registers
All transfers from one register to another will result in a full 16-bit output
from the source register. The destination register size will determine the
number of bits actually stored in the destination register and the values
stored in the processor Status Register. The following are always 16-bit
transfers, regardless of the accumulator size:
TCS; TSC; TCD; TDC
Stack Transfers
When in the Emulation mode, a 01 is forced into SH. In this case, the B
Accumulator will not be loaded into SH during a TCS instruction. When in the
Native mode, the B Accumulator is transferred to SH. Note that in both the
Emulation and Native modes, the full 16 bits of the Stack Register are
transferred to the Accumulator, regardless of the state of the M bit in the
Status Register.

197
files/docs/snes/65816/instruct.txt Normal file
View File

@ -0,0 +1,197 @@
Table 5. Arithmetic and Logical Instructions
Mne- Operation Addressing Mode Status
monic M/X E=1 or E = 0 and dir, dir, (dir) (dir, (dir) [dir] abs abs, abs, absl absl d,s (d,s)
E=0 and M/X=1 M/X = 0 Immed Accu dir x y x) ,y x y ,x ,y N V M X D I Z C
ADC Pm AL + B + Pc -> AL A + W + Pc -> A 69 65 75 72 61 71 67 6D 7D 79 6F 7F 63 73 N V . . . . Z C
AND Pm AL /\B -> AL A /\W -> A 29 25 35 32 21 31 27 2D 3D 39 2F 3F 23 33 N . . . . . Z .
ASL Pm Pc <-B <- 0 Pc <- W <- 0 0A 06 16 0E 1E N . . . . . Z C
BIT Pm AL /\B A /\W 89 24 34 2C 3C N V . . . . Z .
CMP Pm AL - B A - W C9 C5 D5 D2 C1 D1 C7 CD DD D9 CF DF C3 D3 N . . . . . Z C
CPX Px XL - B X - W E0 E4 EC N . . . . . Z C
CPY Px YL - B Y - W C0 C4 CC N . . . . . Z C
DEC Pm B - 1 -> B W - 1 -> W 3A C6 D6 CE DE N . . . . . Z .
EOR Pm AL V- B -> AL A V- W -> A 49 45 55 52 41 51 47 4D 5D 59 4F 5F 43 53 N . . . . . Z .
INC Pm B + 1 -> B W + 1 -> W 1A E6 F6 EE FE N . . . . . Z .
LDA Pm B -> AL W -> A A9 A5 B5 B2 A1 B1 B7 AD BD B9 AF BF A3 B3 N . . . . . Z .
LDX Px B -> XL W -> X A2 A6 B6 AE BE N . . . . . Z .
LDY Px B -> YL W -> Y A0 A4 B4 AC BC N . . . . . Z .
LSR Pm 0 -> B -> Pc 0 -> W -> Pc 4A 46 56 4E 5E 0 . . . . . Z C
ORA Pm AL V B -> AL A V W -> A 09 05 15 12 01 11 17 0D 1D 19 0F 1F 03 13 N . . . . . Z .
ROL Pm Pc <- B <- Pc Pc <- W <- Pc 2A 26 36 2E 3E N . . . . . Z C
ROR Pm Pc -> B -> Pc Pc -> W -> Pc 6A 66 76 6E 7E N . . . . . Z C
SBC Pm AL - B - Pc -> AL A - W - Pc -> A E9 E5 F5 F2 E1 F1 F7 ED FD F9 EF FF E3 F3 N V . . . . Z C
STA Pm AL -> B A -> W 85 95 92 81 91 97 8D 9D 99 8F 9F 83 93 . . . . . . . .
STX Px XL -> B X -> W 86 96 8E . . . . . . . .
STY Px YL -> B Y -> W 84 94 8C . . . . . . . .
STZ Pm 0 -> B 0 -> W 64 74 9C 9E . . . . . . . .
TRB Pm /AL /\ B -> B /A /\ W -> W 14 1C . . . . . . Z .
TSB Pm AL V B -> B A V W -> W 04 0C . . . . . . Z .
V logical OR B byte per effective address
/\ logical AND W word per effective address
V- logical exclusive OR r relative offset
+ arithmetic addition A Accumulator, AL low half of Accumulator
- arithmetic subtraction X Index Register, XL low half of X register
!= not equal Y Index Register, YL low half of Y register
. status bit not affected Pc carry bit
/ negation M/X effective mode bit in Status Register (Pm or Px)
Ws word per stack pointer
Bs byte per stack pointer
Notes:
BIT instruction does not affect N and V flags when using immediate
addressing mode. When using other addressing modes, the N and V flags
are respectively set to bits 7 and 6 or 15 and 14 of the addressed memory
depending on mode (byte or word).
For all Read/Modify/Write instruction addressing modes except accumulator
Add 2 cycles for E=1 or E=0 and Pm=1 (8-bit mode)
Add 3 cycles for E=0 and Pm=0 (16-bit mode).
Add one cycle when indexing across page boundary and E=1 except for STA and
STZ instructions.
If E=1 then 1 -> SH and XL -> SL If E=0 then X -> S regardless of Pm or Px.
Exchanges the carry (Pc) and E bits. Whenever the E bit is set the following
registers and status bits are locked into the indicated state:
XH=0, YH=0, SH=1, Pm=1, Px=1.
Add 1 cycle if branch is taken. In Emulation (E= 1 ) mode only --add 1 cycle
if the branch is taken and crosses a page boundary.
Add 1 cycle in Emulation mode (E=1) for (dir),y; abs,x; and abs,y addressing
modes.
With TSB and TRB instruction, the Z flag is set or cleared by the result
of AAB or AAW.
For all Read/Modify/Write instruction addressing modes except accumulator --
Add 2 cycles for E=1 or E=0 and Pm=1 (8-bit mode)
Add 3 cycles for E=0 and Pm=0 (16-bit mode).
Table 6. Branch, Transter, Push, Pull, and Implied Addressing Mode Instructions
Operation Operation Status
Mnemonic Bytes M/X Cycles 8 Bit Cycles 16 Bit Implied Stack Relative N V M X D I Z C Mnemonic
BCC (6) 2 - 2 PC+r -> PC 2 PC+r -> PC 90 . . . . . . . . BCC
BCS (6) 2 - 2 PC+r -> PC 2 PC+r -> PC B0 . . . . . . . . BCS
BEQ (6) 2 - 2 PC+r -> PC 2 PC+r -> PC F0 . . . . . . . . BEQ
BMI (6) 2 - 2 PC+r -> PC 2 PC+r -> PC 30 . . . . . . . . BMI
BNE (6) 2 - 2 PC+r -> PC 2 PC+r -> PC D0 . . . . . . . . BNE
BPL (6) 2 - 2 PC+r -> PC 2 PC+r -> PC 10 . . . . . . . . BPL
BRA (6) 2 - 2 PC+r -> PC 2 PC+r -> PC 80 . . . . . . . . BRA
BVC (6) 2 - 2 PC+r -> PC 2 PC+r -> PC 50 . . . . . . . . BVC
BVS (6) 2 - 2 PC+r -> PC 2 PC+r -> PC 70 . . . . . . . . BVS
CLC 1 - 2 0 -> Pc 2 0 -> Pc 18 . . . . . . . 0 CLC
CLD 1 - 2 0 -> Pd 2 0 -> Pd D8 . . . . 0 . . . CLD
CLI 1 - 2 0 -> Pi 2 0 -> Pi 58 . . . . . 0 . . CLI
CLV 1 - 2 0 -> Pv 2 O -> Pv B8 . 0 . . . . . . CLV
DEX 1 Px 2 XL - 1 -> XL 2 X - 1 -> X CA N . . . . . Z . DEX
DEY 1 Px 2 YL - 1 -> YL 2 Y - 1 ->Y 88 N . . . . . Z . DEY
INX 1 Px 2 XL + 1 -> XL 2 X + 1 -> X E8 N . . . . . Z . INX
INY 1 Px 2 YL + 1 -> YL 2 Y + 1 -> Y C8 N . . . . . Z . INY
NOP 1 - 2 no operation 2 no operation EA . . . . . . . . NOP
PEA 3 - 5 W->Ws, S-2 ->S 5 same F4 . . . . . . . . PEA
PEI 2 - 6 W->Ws, S-2 ->S 6 same D4 . . . . . . . . PEI
PER 3 - 6 W ->Ws, S-2 ->S 6 same 62 . . . . . . . . PER
PHA 1 Pm 3 AL->Bs, S-1 ->S 4 A ->Ws, S-2 ->S 48 . . . . . . . . PHA
PHB 1 - 3 DB->Bs, S-1 ->S 3 same 8B . . . . . . . . PHB
PHD 1 - 4 D ->Ws, S-2 ->S 4 same OB . . . . . . . . PHD
PHK 1 - 3 PB->Bs, S-1 ->S same 4B . . . . . . . . PHK
PHP 1 - 3 P ->Bs, S-1 ->S 3 same 08 . . . . . . . . PHP
PHX 1 Px 3 XL->Bs, S-1 ->S 4 X-Ws, S-2 -> S DA . . . . . . . . PHX
PHY 1 Px 3 YL->Bs, S-1 ->S 4 Y ->Ws, S-2 ->S 5A . . . . . . . . PHY
PLA 1 Pm 4 S+1 ->S, Bs -> AL 5 S+2 ->S, Ws->A 68 N . . . . . Z . PLA
PLB 1 - 4 S+1 ->S, Bs -> DB 4 same AB N . . . . . Z . PLB
PLD 1 - 5 S+2 ->S, Ws -> D 5 same 2B N . . . . . Z . PLD
PLP 1 - 4 S+1 ->S, Bs -> P 4 same 28 N V M X D I Z C PLP
PLX 1 Px 4 S+1 ->S, Bs -> XL 5 S+2 ->S, Ws->X FA N . . . . . Z . PLX
PLY 1 Px 4 S+1 ->S, Bs -> YL 5 S+2 ->S, Ws->Y 7A N . . . . . Z . PLY
SEC 1 - 2 1 -> Pc 2 1 -> Pc 38 . . . . . . . 1 SEC
SED 1 - 2 1 -> Pd 2 1 -> Pd F8 . . . . 1 . . . SED
SEI 1 - 2 1 -> Pi 2 1 -> Pi 78 . . . . . 1 . . SEI
TAX 1 Px 2 AL -> XL 2 A -> X AA N . . . . . Z . TAX
TAY 1 Px 2 AL -> YL 2 A -> Y A8 N . . . . . Z . TAY
TCD 1 - 2 A -> D 2 A -> D 5B N . . . . . Z . TCD
TCS 1 - 2 A -> S A -> S 1B . . . . . . . . TCS
TDC 1 - 2 D -> A 2 D -> A 7B N . . . . . Z . TDC
TSC 1 - 2 S -> A 2 S -> A 3B N . . . . . Z . TSC
TSX 1 Px 2 SL -> XL 2 S -> X BA N . . . . . Z . TSX
TXA 1 Pm 2 XL -> AL 2 X -> A 8A N . . . . . Z . TXA
TXS 1 - 2 see note 4 2 X -> S 9A . . . . . . . . TXS
TXY 1 Px 2 XL -> YL 2 X -> Y 9B N . . . . . Z . TXY
TYA 1 Pm 2 YL -> AL 2 Y -> A 98 N . . . . . Z . TYA
TYX 1 Px 2 YL -> XL 2 Y -> X BB N . . . . . Z . TYX
XCE 1 - 2 see note 5 2 see note 5 FB . . . . . . . C XCE
See Notes on page 13.
Table 7. Other Addressing Mode Instructions
Status
Mnemonic Addressing Mode Opcode Cycles Bytes N V M X D I Z C Mnemonic Function
BRK stack 00 7/8 2 . . . . 0 1 . . BRK See discussion in Interrupt Processing Sequence section.
BRL relative long 82 3 3 . . . . . . . . BRL PC+r -> PC where -32768 < r < 32767.
COP stack 02 7/8 2 . . . . 0 1 . . COP See discussion in Interrupt Processing Sequence section.
JML absolute indirect DC 6 3 JMLW -> PC, B-PB
JMP absolute 4C 3 3 . . . . . . . . JMP W -> PC
JMP absolute indirect 6C 5 3 . . . . . . . . JMP W -> PC
JMP absolute indexed indirect 7C 6 3 . . . . . . . . JMP W -> PC
JMP absolute long 5C 4 4 JMP W -> PC, B -> PB
JSL absolute long 22 8 4 . . . . . . . . JSL PB -> Bs, S-1 -S, PC -> Ws, S-2 -> S, W -> PC, B -> PB
JSR absolute 20 6 3 . . . . . . . JSR PC -> Ws, S-2 -> S, W -> PC
JSR absolute indexed indirect FC 6 3 . . . . . . . . JSR PC -> Ws, S-2 -> S, W -> PC
MVN block 54 7/byte 3 . . . . . . . . MVN See discussion in Addressing Mode section
MVP block 44 7/byte 3 . . . . . . . . MVP
REP immediate C2 3 2 N V M X D I Z C REP P /\ /B -> P
RTI stack 40 6/7 1 N V M X D I Z C RTI S+1 -> S, Bs -> P, S+2 -> S, Ws -> PC,
if E=0 then S+1 -> S, Bs -> PB
RTL stack 6B 6 1 . . . . . . . . RTL S+2 -> S, Ws~1 -> PC, S+1 -> S, Bs -> PB
RTS stack 60 6 1 . . . . . . . . RTS S+2 -> S, Ws+1 -> PC
SEP immediate E2 3 2 N V M X D I Z C SEP PVB -> P
STP implied DB 3+ 1 . . . . . . . . STP Stop the clock. Requires reset to continue.
WAI implied CB 3+ 1 . . . . . . . . WAI Wait for inte-rupt. RDY held low until Interrupt.
XBA implied EB 3 1 N . . . . . Z . XBA Swap AH and AL. Status bits reflect final condition of AL.
Notes on page 13.
16

61
files/docs/snes/65816/intrrpts.txt Normal file
View File

@ -0,0 +1,61 @@
Interrupt Processing Sequence
The interrupt processing sequence is initiated as the direct result of hard-
vare Abort, Interrupt Request, Non-Maskable Interrupt, or Reset inputs.
The interrupt sequence can also be initiated as a result of the Break or
Co-Processor instructions within the software. The following listings
describe the function of each cycle in the interrupt processing sequence:
Hardware Interrupt /ABORT, /IRQ, /NMI, /RES Inputs
Cycle No.
E = 0 E = 1 Address Data R/W SYNC VDA VPA VP Description
1 1 PC X 1 1 1 1 1 Internal Operation
2 2 PC X 1 0 0 0 1 Internal Operation
3 [1] S PB 0 0 1 0 1 Write PB to Stack, S-1ÑS
4 3 S PCH [2] 0[3] 0 1 0 1 Write PCH to Stack, S-1ÑS
5 4 S PCL 12] 0[3] 0 1 0 1 Write PCL to Stack, S-1ÑS
6 5 S P [4] 0[3] 0 1 0 1 Write P to Stack, S-1ÑS
7 6 VL (VL) 1 0 1 0 0 Read Vector Low Byte,
0->PD, 1->P1, OO->PB
8 7 VH (VH) 1 0 1 0 0 Read Vector High 8yte
Software Interrupt - BRK, COP Instructions
Cycle No.
E = 0 E = 1 Address Data R/W SYNC VDA VPA VP Description
1 1 PC-2 X 1 1 1 1 1 Opcode
2 2 PC-1 X 1 0 0 1 1 Signature
3 111 S PB 0 0 1 0 1 Write PB to Stack, S-1ÑS
4 3 S PCH 0 0 1 0 1 Write PCH to Stack, S-1 - S
5 4 S PCL 0 0 1 0 1 Write PCL to Stack, S-1ÑS
6 5 S P 0 0 1 0 1 Write P to Stack, S-1ÑS
7 6 VL (VL) 1 0 1 0 0 Read Vector Low Byte,
0ÑPo, 1ÑPl, 00ÑPB
8 7 VH (VH) 1 0 1 0 0 Read Vector High Byte
Notes:
[1] Delete this cycle in Emulation mode.
[2] Abort writes address of aborted opcode.
[3] R/W remains in the high state during Reset.
[4] In Emulation mode, bit 4 written to stack is changed to 0.
Table 3. Vector Locations
Emulation Native Priority
Name Source (E = 1) (E = 0) Level
ABORT Hardware 00FFF8,9 00FFE8,9 2
BRK Software 00FFFE,F 00FFE6,7 N/A
COP Software 00FFF4,5 00FFE4,5 N/A
IRQ Hardware 00FFFE,F 00FFEE,F 4
NMI Hardware 00FFFA,B 00FFEA,B 3
RES Hardware 00FFFC.D 00FFFC,D 1

117
files/docs/snes/65816/mnemonic.txt Normal file
View File

@ -0,0 +1,117 @@
Table 4. G65SC802 and G65SC816 Instruction Set -- Alphabetical Sequence
ADC Add Memory to Accumulator with Carry
AND "AND" Memory with Accumulator
ASL Shift One Bit Left, Memory or Accumulator
BCC* Branch on Carry Clear (Pe = O)
BCS* Branch on Carry Set (Pe = 1)
BEQ Branch if Equal (Pz = 1)
BIT Bit Test
BMI Branch if Result Minus (PN = 1)
BNE Branch if Not Equal (Pz = 0)
BPL Branch if Result Plus (PN = 0)
BRA Branch Always
BRK Force Break
BRL Branch Always Long
BVC Branch on Overflow Clear (Pv = 0)
BVS Branch on Overflow Set (Pv = 1)
CLC Clear Carry Flag
CLD Clear Decimal Mode
CLI Clear Interrupt Disable Bit
CLV Clear Overflow Flag
CMP* Compare Memory and Accumulator
COP Coprocessor
CPX Compare Memory and Index X
CPY Compare Memory and Index Y
DEC* Decrement Memory or Accumulator by One
DEX Decrement Index X by One
DEY Decrement Index Y by One
EOR Exclusive "OR" Memory with Accumulator
INC* Increment Memory or Accumulator by One
INX Increment Index X by One
INY Increment Index Y by One
JML** Jump Long
JMP Jump to New Location
JSL** Jump Subroutine Long
JSR Jump to New Location Saving Return Address
LDA Load Accumulator with Memory
LDX Load Index X with Memory
LDY Load Index Y with Memory
LSR Shift One Bit Right (Memory or Accumulator)
MVN Block Move Negative
MVP Block Move Positive
NOP No Operation
ORA "OR" Memory with Accumulator
PEA Push Effective Absolute Address on Stack (or Push Immediate Data on Stack)
PEI Push Effective Indirect Address on Stack (add one cycle if DL f 0)
PER Push Effective Program Counter Relative Address on Stack
PHA Push Accumulator on Stack
PHB Push Data Bank Register on Stack
PHD Push Direct Register on Stack
PHK Push Program Bank Register on Stack
PHP Push Processor Status on Stack
PHX Push Index X on Stack
PHY Push index Y on Stack
PLA Pull Accumulator from Stack
PLB Pull Data Bank Register from Stack
PLD Pull Direct Register from Stack
PLP Pull Processor Status from Stack
PLX Pull Index X from Stack
PLY Pull Index Y form Stack
REP Reset Status Bits
ROL Rotate One Bit Left (Memory or Accumulator)
ROR Rotate One Bit Right (Memory or Accumulator)
RTI Return from Interrupt
RTL Return from Subroutine Long
RTS Return from Subroutine
SBC Subtract Memory from Accumulator with Borrow
SEC Set Carry Flag
SED Set Decimal Mode
SEI Set Interrupt Disable Status
SEP Set Processor Status Bits
STA Store Accumulator in Memory
STP Stop the Clock
STX Store Index X in Memory
STY Store Index Y in Memory
STZ Store Zero in Memory
TAX Transfer Accumulator to Index X
TAY Transfer Accumulator to Index Y
TCD* Transfer Accumulator to Direct Register
TCS* Transfer Accumulator to Stack Pointer Register
TDC* Transfer Direct Register to Accumulator
TRB Test and Reset Bit
TSB Test and Set Bit
TSC* Transfer Stack Pointer Register to Accumulator
TSX Transfer Stack Pointer Register to Index X
TXA Transfer Index X to Accumulator
TXS Transfer Index X to Stack Polnter Register
TXY Transfer Index X to Index Y
TYA Transfer Index Y to Accumulator
TYX Transfer Index Y to Index X
WAI Wait for Interrupt
XBA* Exchange AH and AL
XCE Exchange Carry and Emulation Bits
*) Common Mnemonic Aliases
Mnemonic Alias
BCC BLT
BCS BGE
CMP CPA
DEC A DEA
INC A INA
TCD TAD
TCS TAS
TDC TDA
TSC TSA
XBA SWA
**) JSL should be recognized as equivalent to JSR
when it is specified with long absolute addresses.
JML is equivalent to JMP with long addressing forced.
-13-

97
files/docs/snes/65816/opcodes.txt Normal file
View File

@ -0,0 +1,97 @@
Table 8. Opcode Matrix
MSD LSD MSD
--+-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------+--
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | C | D | E | F |
|-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------|
0 | BRK s |ORA(d,x)| COP s | ORA d,s | TSB d | ORA d | ASL d | ORA [d] | PHP s | ORA # | ASL A | PHD s | TSB a | ORA a | ASL a | ORA al | 0
| 2 8 | 2 6 | 2 8 | 2 4 | 2 5 | 2 3 | 2 5 | 2 6 | 1 3 | 2 2 | 1 2 | 1 4 | 3 6 | 3 4 | 3 6 | 4 5 |
|-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------|
1 | BPL r |ORA(d),y| ORA(d) |ORA(d,s),y| TRB d | ORA d,x| ASL d,x|ORA [d],y| CLC i | ORA a,y| INC A | TCS i | TRB a | ORA a,x| ASL a,x| ORA al,x| 1
| 2 2 | 2 5 | 2 5 | 2 7 | 2 5 | 2 4 | 2 6 | 2 6 | 1 2 | 3 4 | 1 2 | 1 2 | 3 6 | 3 4 | 3 7 | 4 5 |
|-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------|
2 | JSR a |AND(d,x)| JSL al | AND d,s | BIT d | AND d | ROL d | AND [d] | PLP s | AND # | ROL A | PLD s | BIT a | AND a | ROL a | AND al | 2
| 3 6 | 2 6 | 4 8 | 2 4 | 2 3 | 2 3 | 2 5 | 2 6 | 1 4 | 2 2 | 1 2 | 1 5 | 3 4 | 3 4 | 3 6 | 4 5 |
|-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------|
3 | BMI r |AND(d),y| AND (d)|AND(d,s),y| BIT d,x| AND d,x| ROL d,x|AND [d],y| SEC i | AND a,y| DEC A | TSC i | BIT a,x| AND a,x| ROL a,x| AND al,x| 3
| 2 2 | 2 5 | 2 5 | 2 7 | 2 4 | 2 4 | 2 6 | 2 6 | 1 2 | 3 4 | 1 2 | 1 2 | 3 4 | 3 4 | 3 7 | 4 5 |
|-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------|
4 | RTI s |EOR(d,x)| reserve| EOR d,s | MVP xya| EOR d | LSR d | EOR [d] | PHA s | EOR # | LSR A | PHK s | JMP a | EOR a | LSR a | EOR al | 4
| 1 7 | 2 6 | 2 2 | 2 4 | 3 7 | 2 3 | 2 5 | 2 6 | 1 3 | 2 2 | 1 2 | 1 3 | 3 3 | 3 4 | 3 6 | 4 5 |
|-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------|
5 | BVC r |EOR(d),y| EOR (d)|EOR(d,s),y| MVN xya| EOR d,x| LSR d,x|EOR [d],y| CLI i | EOR a,y| PHY s | TCD i | JMP al | EORa,x | LSRa,x | EOR al,x| 5
| 2 2 | 2 5 | 2 5 | 2 7 | 3 7 | 2 4 | 2 6 | 2 6 | 1 2 | 3 4 | 1 3 | 1 2 | 4 4 | 3 4 | 3 7 | 4 5 |
|-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------|
6 | RTS s |ADC(d,x)| PER s | ADC d,s | STZ d | ADC d | ROR d | ADC [d] | PLA s | ADC # | ROR A | RTL s | JMP (a)| ADC a | ROR a | ADC al | 6
| 1 6 | 2 6 | 3 6 | 2 4 | 2 3 | 2 3 | 2 5 | 2 6 | 1 4 | 2 2 | 1 2 | 1 6 | 3 5 | 3 4 | 3 6 | 4 5 |
|-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------|
7 | BVS r |ADC(d),y| ADC (d)|ADC(d,s),y| STZ d,x| ADC d,x| ROR d,x|ADC [d],y| SEI i | ADC a,y| PLY s | TDC i |JMP(a,x)| ADC a,x| ROR a,x| ADC al,x| 7
| 2 2 | 2 5 | 2 5 | 2 7 | 2 4 | 2 4 | 2 6 | 2 6 | 1 2 | 3 4 | 1 4 | 1 2 | 3 6 | 3 4 | 3 7 | 4 5 |
|-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------|
8 | BRA r |STA(d,x)| BRL rl | STA d,s | STY d | STA d | STX d | STA [d] | DEY i | BIT # | TXA i | PHB s | STY a | STA a | STX a | STA al | 8
| 2 2 | 2 6 | 3 3 | 2 4 | 2 3 | 2 3 | 2 3 | 2 6 | 1 2 | 2 2 | 1 2 | 1 3 | 3 4 | 3 4 | 3 4 | 4 5 |
|-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------|
9 | BCC r |STA(d),y| STA (d)|STA(d,s),y| STYd,x | STA d,x| STX d,y|STA [d],y| TYA i | STA a,y| TXS i | TXY i | STZ a | STA a,x| STZ a,x| STA al,x| 9
| 2 2 | 2 6 | 2 5 | 2 7 | 2 4 | 2 4 | 2 4 | 2 6 | 1 2 | 3 5 | 1 2 | 1 2 | 3 4 | 3 5 | 3 5 | 4 5 |
|-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------|
A | LDY # |LDA(d,x)| LDX # | LDA d,s | LDY d | LDA d | LDX d | LDA [d] | TAY i | LDA # | TAX i | PLB s | LDY a | LDA a | LDX a | LDA al | A
| 2 2 | 2 6 | 2 2 | 2 4 | 2 3 | 2 3 | 2 3 | 2 6 | 1 2 | 2 2 | 1 2 | 1 4 | 3 4 | 3 4 | 3 4 | 4 5 |
|-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------|
B | BCS r |LDA(d),y| LDA (d)|LDA(d,s),y| LDY d,x| LDA d,x| LDX d,y|LDA [d],y| CLV i | LDA a,y| TSX i | TYX i | LDY a,x| LDA a,x| LDX a,y| LDA al,x| B
| 2 2 | 2 5 | 2 5 | 2 7 | 2 4 | 2 4 | 2 4 | 2 6 | 1 2 | 3 4 | 1 2 | 1 2 | 3 4 | 3 4 | 3 4 | 4 5 |
|-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------|
C | CPY # |CMP(d,x)| REP # | CMP d,s | CPY d | CMP d | DEC d | CMP [d] | INY i | CMP # | DEX i | WAI i | CPY a | CMP a | DEC a | CMP al | C
| 2 2 | 2 6 | 2 3 | 2 4 | 2 3 | 2 3 | 2 5 | 2 6 | 1 2 | 2 2 | 1 2 | 1 3 | 3 4 | 3 4 | 3 4 | 4 5 |
|-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------|
D | BNE r |CMP(d),y| CMP (d)|CMP(d,s),y| PEI s | CMP d,x| DEC d,x|CMP [d],y| CLD i | CMP a,y| PHX s | STP i | JML (a)| CMP a,x| DEC a,x| CMP al,x| D
| 2 2 | 2 5 | 2 5 | 2 7 | 2 6 | 2 4 | 2 6 | 2 6 | 1 2 | 3 4 | 1 3 | 1 3 | 3 6 | 3 4 | 3 7 | 4 5 |
|-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------|
E | CPX # |SBC(d,x)| SEP # | SBC d,s | CPX d | SBC d | INC d | SBC [d] | INX i | SBC # | NOP i | XBA i | CPX a | SBC a | INC a | SBC al | E
| 2 2 | 2 6 | 2 3 | 2 4 | 2 3 | 2 3 | 2 5 | 2 6 | 1 2 | 2 2 | 1 2 | 1 3 | 3 4 | 3 4 | 3 6 | 4 5 |
|-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------|
F | BEQ r |SBC(d),y| SBC (d)|SBC(d,s),y| PEA s | SBC d,x| INC d,x|SBC [d],y| SED i | SBC a,y| PLX s | XCE i |JSR(a,x)| SBC a,x| INC a,x| SBC al,x| F
| 2 2 | 2 5 | 2 5 | 2 7 | 3 5 | 2 4 | 2 6 | 2 6 | 1 2 | 3 4 | 1 4 | 1 2 | 3 6 | 3 4 | 3 7 | 4 5 |
|-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------|
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | C | D | E | F |
--+-------+--------+--------+----------+--------+--------+--------+---------+-------+--------+-------+-------+--------+--------+--------+---------+--
Symbol Addressing mode
# immediate
A accumulator
r program counter relative
rl program counter relative long
i implied
s stack
d direct
d,x direct indexed (with x)
d,y direct indexed (with y)
(d) direct Indirect
(d,x) direct indexed Indirect
(d),y direct Indirect indexed
[d] direct indirect long
[d],y direct indirect indexed long
a absolute
a,x absolute indexed (with x)
a,y absolute indexed (with y)
al absolute long
al,x absolute indexed long
d,s stack relative
(d,s),y stack relative indirect Indexed
(a) absolute indirect
(a,x) absoite Indxed Indirect
xya block move
Legend
Instruction mnemonic Addressing mode
Base number of base number Cycles
of bytes

188
files/docs/snes/65816/scnfrmt.txt Normal file
View File

@ -0,0 +1,188 @@
[Image]
SNES Screen Format
[Image]
SNES GRAPHICS INFO FILE V1.0
----------------------------
By DAX on 28/2/93
This is a short text file on how the data for the gfx on the SNES are
set up..
Everything is based around an 8x8 pixel 'Tile' and thinking in terms of
tiles makes the whole thing a lot easier.
4 Colour mode - 2 Bitplanes
---------------------------
If you split the screen into 8x8 pixel tiles, the order of the graphics data
is tile 0,1,2,3,4 etc.(with tile 0 being the first, and 1 being the one on
the right of it.)
Then for each tile, the data is stored as shown below.
00 01 02 03 04 05 06 07
10 11 12 13 14 15 16 17 Each number representing one pixel in
20 21 22 23 24 25 26 27 the 8x8 tile.
30 31 32 33 34 35 36 37
40 41 42 43 44 45 46 47
50 51 52 53 54 55 56 57
60 61 62 63 64 65 66 67
70 71 72 73 74 75 76 77
The data is stored in the SNES binary in the following format.
Bitplane 0 .. Line 00-07 (One Byte)
Line 10-17
Line 20-27
Line 30-37
Line 40-47
Line 50-57
Line 60-67
Line 70-77
then Bitplane 1 .. Line 00-07
Line 10-17
Line 20-27
Line 30-37
Line 40-47
Line 50-57
Line 60-67
Line 70-77
then comes the data for the next tile (the one on the right).etc.
16 Colour - 4 Bitplanes
-----------------------
The data for this mode is stored in the same format, with one main change.
The data is stored in the format
Bitplane 0 .. Line 00-07
|
Line 70-77
Bitplane 1 .. Line 00-07
|
Line 70-77
Bitplane 2 .. Line 00-07
|
Line 70-77
Bitplane 3 .. Line 00-07
|
Line 70-77
then the data for the next tile.
256 Colour - 8 Bitplanes
------------------------
This is simply an expansion of the 4 and 16 colour modes.
Bitplane 0 .. Line 00-07
|
Line 70-77
Bitplane 1 .. Line 00-07
|
Line 70-77
Bitplane 2 .. Line 00-07
|
Line 70-77
Bitplane 3 .. Line 00-07
|
Line 70-77
Bitplane 4 .. Line 00-07
|
Line 70-77
Bitplane 5 .. Line 00-07
|
Line 70-77
Bitplane 6 .. Line 00-07
|
Line 70-77
Bitplane 7 .. Line 00-07
|
Line 70-77
then the data for the next tile.
256 Colours - Mode 7 format
---------------------------
This has some very major differences to the other graphics data formats
there are two mode7 modes, normal and EXTBG, the data is stored in the
same way in both, apart from in EXTBG the Bitplane 7 value will be a
priority bit for the pixel, which cuts the colours down to 128.
Each byte of 'graphics data' is actually the colour value for that pixel
on the screen, so if the value is 64, then the colour of that pixel will
be the contents of colour register 64.
The data is stored in VRAM differently to the other modes, with the tile
numbers, and the graphics data 'interleaved', starting at $0000 in VRAM,
with alternate bytes containing one byte of tile, one byte of gfx - this
is shown below.
Word of VRAM. HI LO
Bit 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
content |------------------------------||------------------------------|
Graphics data(CHAR DATA) Tile number(NAME)
Because of the storing of 16 bit data in reverse format (LO-HI) this means
that if you set the VRAM addr to $0.the first byte written should be the
tile name for that position on screen and the second byte should be the first
byte of the Mode7 graphics data.if the VRAM addr is set to $1 the first byte
written will be the tile name for that position on scr, and the second byte
should be the second byte of the mode7 graphics data.
ETC
In mode7 you can only have a maximum of 256 tiles, because of the fact that
the mode7 data only takes up the first half of VRAM(32k) you can only have 16k
of graphics data which is 256 tiles of 8x8 with 256 colours.
This is quite a limitation, but can be used quite effectively.
The tile numbers are stored in a format according to a 128x128 tile screen
so tile 128($80) would be the tile below 0($0) on the screen, and so on.
so VRAM addr $0 is the top left tile, and $1 is the one on the right of it
$80 is the one on the left side, one row down.
the graphics data is stored based on an 8x8 tile again.
but slightly different.
Each byte(pixel) is stored so...
Bit number Contents
0 Bitplane 0 pixel value
1 Bitplane 1 pixel value
2 Bitplane 2 pixel value
3 Bitplane 3 pixel value
4 Bitplane 4 pixel value
5 Bitplane 5 pixel value
6 Bitplane 6 pixel value
7 Bitplane 7 pixel value /
(EXTBG mode - Priority value)
The data is then stored in the sequence
00,01,02,03,04,05,06,07
10,11,12,13,14,15,16,16 (Look at diagram at start of file
| | | for explanation)
70,71,72,73,74,75,76,77
with one byte for each position(pixel), according to the 8x8 tile format,
with one tile after another.
---------------------------------------------------------------------------
I hope this text file helps those of you having trouble converting graphics
for use on the SNES, I have been asked a few times recently for this info
so I decided to type up this short text file on it.
Hopefully it should explain it!
[Image]
© 1996 Damaged Cybernetics
[Image]

14
files/docs/snes/65816/thetrip.tag Executable file
View File

@ -0,0 +1,14 @@
This File Passed thru:
_ _ _
/{____________ ___________ /{_______________________)\
\\ ; ----._/:\ : --./ \\ ; ----._/ .\. ,/ _ \
\. / :: \. ;/ \. / /; /. | /_; :
\_| / | ___/ \_| // ` / : :; ,/
| |/| .. |. \ | |/; . \ | |; |
/. \| :. |; __/\ /. \ \ .\|. |. |
\___ / \ || /____. ') \___ ./_ "/_ /____\ /
\/ \||/ \ ;/ \/ \/ \/ V
)/
` T1! 207.8.XXX.XX
SiteOp: Stumble

2762
files/docs/snes/65816info.txt Normal file
View File

File diff suppressed because it is too large Load Diff

0
files/docs/ArchitekturdesSNES-Final.doc → files/docs/snes/Architektur des SNES - Final.doc
View File

BIN
files/docs/snes/ArchitekturdesSNES-Final.doc Normal file
View File

Binary file not shown.

61
files/docs/snes/Intrrpts.txt Normal file
View File

@ -0,0 +1,61 @@
Interrupt Processing Sequence
The interrupt processing sequence is initiated as the direct result of hard-
vare Abort, Interrupt Request, Non-Maskable Interrupt, or Reset inputs.
The interrupt sequence can also be initiated as a result of the Break or
Co-Processor instructions within the software. The following listings
describe the function of each cycle in the interrupt processing sequence:
Hardware Interrupt /ABORT, /IRQ, /NMI, /RES Inputs
Cycle No.
E = 0 E = 1 Address Data R/W SYNC VDA VPA VP Description
1 1 PC X 1 1 1 1 1 Internal Operation
2 2 PC X 1 0 0 0 1 Internal Operation
3 [1] S PB 0 0 1 0 1 Write PB to Stack, S-1ÑS
4 3 S PCH [2] 0[3] 0 1 0 1 Write PCH to Stack, S-1ÑS
5 4 S PCL 12] 0[3] 0 1 0 1 Write PCL to Stack, S-1ÑS
6 5 S P [4] 0[3] 0 1 0 1 Write P to Stack, S-1ÑS
7 6 VL (VL) 1 0 1 0 0 Read Vector Low Byte,
0->PD, 1->P1, OO->PB
8 7 VH (VH) 1 0 1 0 0 Read Vector High 8yte
Software Interrupt - BRK, COP Instructions
Cycle No.
E = 0 E = 1 Address Data R/W SYNC VDA VPA VP Description
1 1 PC-2 X 1 1 1 1 1 Opcode
2 2 PC-1 X 1 0 0 1 1 Signature
3 111 S PB 0 0 1 0 1 Write PB to Stack, S-1ÑS
4 3 S PCH 0 0 1 0 1 Write PCH to Stack, S-1 - S
5 4 S PCL 0 0 1 0 1 Write PCL to Stack, S-1ÑS
6 5 S P 0 0 1 0 1 Write P to Stack, S-1ÑS
7 6 VL (VL) 1 0 1 0 0 Read Vector Low Byte,
0ÑPo, 1ÑPl, 00ÑPB
8 7 VH (VH) 1 0 1 0 0 Read Vector High Byte
Notes:
[1] Delete this cycle in Emulation mode.
[2] Abort writes address of aborted opcode.
[3] R/W remains in the high state during Reset.
[4] In Emulation mode, bit 4 written to stack is changed to 0.
Table 3. Vector Locations
Emulation Native Priority
Name Source (E = 1) (E = 0) Level
ABORT Hardware 00FFF8,9 00FFE8,9 2
BRK Software 00FFFE,F 00FFE6,7 N/A
COP Software 00FFF4,5 00FFE4,5 N/A
IRQ Hardware 00FFFE,F 00FFEE,F 4
NMI Hardware 00FFFA,B 00FFEA,B 3
RES Hardware 00FFFC.D 00FFFC,D 1

BIN
files/docs/snes/LoROM.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 158 KiB

65
files/docs/snes/Qaddress.txt Normal file
View File

@ -0,0 +1,65 @@
Addressing mode quick reference
By Qwertie (QwertMan@hotmail.com)
I lifted this straight from my emulator code, which I tend to comment heavily :)
Please correct me if any of this is wrong...
// ADDRESSING MODES - several categories, one mode from each category can be combined
// None of the instructions can use all combinations, and certain combinations are
// never used with any instruction.
// Used to calculate memory address:
// Absolute: Argument is two bytes and specifies a memory location
// + Long: Argument is three bytes instead opcode $addr
// Direct: Argument is one byte; memory address formed by adding D.
// Bank is always 0, unless indirect addressing is also used, in
// which case the bank is the program bank. opcode <$addr
// Stack Relative: Argument is one byte, which is added to the stack pointer
// to find the final address. opcode $addr,S
// Indexed addressing:
// Indexed: Memory location argument is added to X or Y to get the final
// memory location. opcode $addr,X or Y
// Note that certain indexed addressing modes only work with the X register
// or only with the Y register.
//
// Note! The above addressing mode specifiers are used only to specify the
// size of the argument and how it is used. The specifiers DO NOT SPECIFY
// anything about the actual memory location being referenced.
// For example, suppose the Absolute Indexed mode is used. This means that
// the argument to the opcode is 16 bits and will be added to an index
// register. It does not, however, mean that the value at the calculated
// memory location will be a 16-bit value. The size of the value at the memory
// location is determined by either:
// a. whether the processor is in 16-bit mode (and whether E=0), or
// b. if indirect addressing is used, whether the Long Indirect mode is used.
//
// Indirect addressing:
// Indirect: Uses indirection (pointers). In other words, after the memory
// location is found and the contents are loaded, the contents are used as
// a SECOND memory location and the value at the second memory location is
// used in the operation. opcode ($addr)
// + Direct Long: Normally, the pointer found at the specified location
// will be two bytes. If Direct Indirect Long is used, the pointer
// at the memory address found will be a three-byte long address.
// opcode [$addr]
// Indexed Indirect (preindexed; (arg,x)) vs. Indirect Indexed (postindexed;
// (arg),x): remember, these two are different!
//
// Stack relative addressing: denoted by arg,s, the address is calculated by
// adding the argument value to the stack pointer. Always accesses bank 0,
// since the stack is always in bank 0.
// There is also two more modes, which are never used with any other specifiers:
// Implied: Opcode has no arguments
// Immediate: The argument specifies an actual constant value to be used,
// rather than a memory address. [opcode #$XX or #$XXXX]
Vector Locations:
In Emulation Mode: In Native Mode:
00.FFFE /IRQ or BRK 00.FFEE /IRQ
00.FFFC /RESET 00.FFEC (Unused)
00.FFFA /NMI 00.FFEA /NMI
00.FFF8 /ABORT 00.FFE8 /ABORT
00.FFF6 (Unused) 00.FFE6 BRK
00.FFF4 CSP 00.FFE4 CSP
-The location after the one listed holds the high byte of the address
-CSP (Call system procedure) is same as the COP mnemonic

0
files/docs/SNES-Interrupts.txt → files/docs/snes/SNES-Interrupts.txt
View File

0
files/docs/SNES-KART.doc → files/docs/snes/SNES-KART.doc
View File

0
files/docs/SNES-Memorymap.txt → files/docs/snes/SNES-Memorymap.txt
View File

0
files/docs/SNES-Memorymap2.txt → files/docs/snes/SNES-Memorymap2.txt
View File

BIN
files/docs/snes/SNES-PIN Normal file
View File

Binary file not shown.

343
files/docs/snes/SNES-ROM.TXT Normal file
View File

@ -0,0 +1,343 @@
______ _____ _____ _______ ___ ___
/ __/ /. _ \ ___/ __/ |____ \___ /. \/ \
\___ .\// |. \ / . \__ .\ |. _/ \// .\
/. \\ |: .\ __/ \\ || | .\ ! \ \/. \
\______ /___|____/____\____ / |__| \\___/____||: \
By Mind Rape \___/ |______/
v1.5 (C) Damaged Cybernetics 1994-95
This document main goal is show where one can find the SNES ROM
information. Most of this information was collected thru hacking
the rom to death and help from Norm/Yoshi/chp.
License codes are taken from SU and probably incorrect.
Source? None here, if you are going to screw with the bin,
you probably know what you are doing (HOPEFULLY).
If you have any questions, comments,corrections, additional information,
you can either find me on IRC as (MindRape) or you can send me email
(much prefered) mind@primenet.com. Also if you write anything
interesting then send it to me!
You may distribute this document freely, but you may not change
the information here and redistribute. If you use this information
please credit me. You steal this information and say you did it,
you know it's a LIE and there you are.
=[SNES ROM Makeup]===========================================================
ROM Title : 21 Bytes
* Titles are all in upper case
* Japanese titles are in high ascii values
good rule of thumb if you can't read the title and
it's country code is Japan and your American,
you probably can't play it. :>
Rom Makeup : 7654 3210
0000-0000
|__| |__|
| |
| |___Bank Size 0001 = HiROM (64K Banks Mode 21)
| 0000 = Low Rom (32K Banks Mode 20)
|
|________ROM Speed 0111 = Fast Rom
0000 = Slow Rom
* Could someone give the correct
* speeds of the ROMs? I got
* conflicting answers.
ROM Type : 1 Byte
Hex ROM Type
---------------------
00 ROM
01 ROM/RAM
02 ROM/SRAM
03 ROM/DSP1
04 ROM/DSP1/RAM
05 ROM/DSP1/SRAM
06 FX
* SRAM = Save Ram
* DSP1 = Nintendo's 1st generation of DSP (Math coprocessor)
* FX = RISC based math coprocessor
Only a couple of games support the FX Chip, Star Fox
is the most well known one.
ROM Size : 1 BYTE
Hex Size
--------------
08 2 Mbit
09 4 Mbit
0A 8 Mbit
0B 16 Mbit
0C 32 Mbit
* As of this documentation 32MBit ROMs are the largest that
Nintendo currently uses. Rumors of a 40+ kart are around,
but cannot be verified.
* 8MBit ROMs are the most common in the entire library of
SNES karts
* ROMs are always multiples 2, thus 2MBit ROMs are the smallest
Space Invaders (c) Taito is a 2MBit ROM (Japan only)
* Easy way to calc rom size without a lookup table
1 << (ROM_SIZE - 7) MBits
ie. 8Mbit ROMs = 0Ah = 10d
1 << (0A-7) = 8 Mbit
SRAM Size : 1 BYTE
Hex Size
--------------
00 No SRAM
01 16 Kbit
02 32 Kbit
03 64 Kbit
* 64Kbit is the largest SRAM size that Nintendo currently uses.
* 256Kbit is standard for most copiers.
* Easy way to calc SRAM Size without a lookup table
1 << (3+SRAM_BYTE) Kbits
ie. 16Kbit = 01
1 << (3+1) = 16
COUNTRY CODE : 1 BYTE
Hex Country Video Mode
------------------------------------------
00 Japan (NTSC)
01 USA (NTSC)
02 Europe, Oceania, Asia (PAL)
03 Sweden (PAL)
04 Finland (PAL)
05 Denmark (PAL)
06 France (PAL)
07 Holland (PAL)
08 Spain (PAL)
09 Germany, Austria, Switz (PAL)
10 Italy (PAL)
11 Hong Kong, China (PAL)
12 Indonesia (PAL)
13 Korea (PAL)
* Country Codes are from SU.INI, could someone verify these?
LICENSE : 1 BYTE
0 <Invalid License Code>
1 Nintendo
5 Zamuse
8 Capcom
9 HOT B
10 Jaleco
11 STORM (Sales Curve) (1)
15 Mebio Software
18 Gremlin Graphics
21 COBRA Team
22 Human/Field
24 Hudson Soft
26 Yanoman
28 Tecmo (1)
30 Forum
31 Park Place Productions / VIRGIN
33 Tokai Engeneering (SUNSOFT?)
34 POW
35 Loriciel / Micro World
38 Enix
40 Kemco (1)
41 Seta Co.,Ltd.
45 Visit Co.,Ltd.
53 HECT
61 Loriciel
64 Seika Corp.
65 UBI Soft
71 Spectrum Holobyte
73 Irem
75 Raya Systems/Sculptured Software
76 Renovation Pruducts
77 Malibu Games (T*HQ Inc.) / Black Pearl
79 U.S. Gold
80 Absolute Entertainment
81 Acclaim
82 Activision
83 American Sammy
84 GameTek
85 Hi Tech
86 LJN Toys
90 Mindscape
93 Technos Japan Corp. (Tradewest)
95 American Softworks Corp.
96 Titus
97 Virgin Games
98 Maxis
103 Ocean
105 Electronic Arts
107 Laser Beam
110 Elite
111 Electro Brain
112 Infogrames
113 Interplay
114 LucasArts
115 Sculptured Soft
117 STORM (Sales Curve) (2)
120 THQ Software
121 Accolade Inc.
122 Triffix Entertainment
124 Microprose
127 Kemco (2)
130 Namcot/Namco Ltd. (1)
132 Koei/Koei! (second license?)
134 Tokuma Shoten Intermedia
136 DATAM-Polystar
139 Bullet-Proof Software
140 Vic Tokai
143 I'Max
145 CHUN Soft
146 Video System Co., Ltd.
147 BEC
151 Kaneco
153 Pack in Video
154 Nichibutsu
155 TECMO (2)
156 Imagineer Co.
160 Wolf Team
164 Konami
165 K.Amusement
167 Takara
169 Technos Jap. ????
170 JVC
172 Toei Animation
173 Toho
175 Namcot/Namco Ltd. (2)
177 ASCII Co. Activison
178 BanDai America
180 Enix
182 Halken
186 Culture Brain
187 Sunsoft
188 Toshiba EMI/System Vision
189 Sony (Japan) / Imagesoft
191 Sammy
192 Taito
194 Kemco (3) ????
195 Square
196 NHK
197 Data East
198 Tonkin House
200 KOEI
202 Konami USA
205 Meldac/KAZe
206 PONY CANYON
207 Sotsu Agency
209 Sofel
210 Quest Corp.
211 Sigma
214 Naxat
216 Capcom Co., Ltd. (2)
217 Banpresto
219 Hiro
221 NCS
222 Human Entertainment
223 Ringler Studios
224 K.K. DCE / Jaleco
226 Sotsu Agency
228 T&ESoft
229 EPOCH Co.,Ltd.
231 Athena
232 Asmik
233 Natsume
234 King/A Wave
235 Atlus
236 Sony Music
238 Psygnosis / igs
243 Beam Software
244 Tec Magik
255 Hudson Soft
* License Codes are from SU.INI, could someone verify these?
* I believe the # of licenses is low. Is it possible that
License and Country codes are used in conjuction to produce
that many more licenses?
VERSION - 1 byte
* The Version is interpeted this way.
1.?? - (thanks to yoshi for the correction)
CHECKSUM COMPLEMENT - 2 bytes the complement of the checksum :>
The bits are reversed of the CHECKSUM
CHECKSUM - 2 bytes Checksum of the bin
* Anyone know how the checksum is calculated for the ROM?
NMI/VBL Vector - 2 bytes - OFFSET 81FAh (lowrom)
OFFSET 101FAh (hirom)
RESET Vector - 2 bytes where to start our code at - OFFSET 81FCh (lowrom)
- OFFSET 101FAh (hirom)
* 8000h is common for Low Roms
=[READING THE CORRECT BIN INFORMATION]==================================
The bin information can be found in 2 possible places,
a) End of the 1st 32K bank (Low ROM) (81c0h/w 512 byte header)
b) End of the 1st 64K bank (HiROM) (101c0h/w 512 byte header)
You could use UCON's method (author chp).
The method is as followed:
UCON's method is to OR the Checksum and the Complement. If the
resulting value is FFFFh, then we found the correct location of
to extract rest of the data out. HOWEVER! This fails on several
karts, such as Castle Wolfenstien 3D and Super Tetris 3 for example.
Reason being is that not all developers put the correct complement
or bother even to implement it. I would suspect! That this maybe
a ploy to keep other developers out of the bin, for if they can't
find the reset vector, disassembling becomes a bit difficult.
=[Other Information on SNES?]================================================
Famicom Development FTP Site
busop.cit.wayne.edu - pub/famidev
Yoshi's SNES Documentation 2.3
This is considered the BEST source of SNES hardware information,
and the most complete!
busop.cit.wayne.edu - pub/famidev/incoming/sndoc230.lzh
=[w0rd!]=====================================================================
w0rd to all following console dudes
GoosE_,yoshi,sir jinx,chp,SHORYUKEN,_bubsy,felon,archimede
rugalz,SinZ,dragonz,procyon,royce,hoodlem,bri_acid,kamikitty,
norm,ZillionZ Members,grayarea,Victor,drunkfux(h0h0h0h0),dmessiah,
piratendo
<insert your favorite group(s) greet here> (heh)
Later Mind Rape

971
files/docs/snes/SNES.DOC Normal file
View File

@ -0,0 +1,971 @@
=-=-=
SNES Documentation v1.3: Written by Yoshi of Digital Exodus.
=-=-=
1) Memory Map.
i) "Main" memory map.
ii) Additional info.
2) SNES Color explaination.
3) SNES DMA Memory Map and explaination.
4) SNES Graphics (tiles) explaination.
5) SNES Screen mode definitions.
6) SNES OAM/Sprite explaination.
7) Magicom Disk registers and Memory controller locations.
69) About the author...
FF) Greetings, Thanx, etc...
=-=-=
1) Memory Map.
i) "Main" memory map.
-----------
Just so you know... the R and/or W's on the left side before the
memory location mean [R]eadable and/or [W]riteable. I don't know
what happens if you try to read from the write-only registers:
I think you get bogus data, but that's about it.
-----------
W |$2100: Screen display register.
x000bbbb
x: 0 = Screen on.
1 = Screen off.
bbbb: 0-$F = Brightness of screen.
*** If you increment $2100 so the register goes up
to $xF (x being whatever), you can make the
screen "fade in". Make -SURE- you do this only
during the VBlank period! If you don't, the screen
goes totally wacko! The 'GS programmers like myself
call it "Syncing to the VBL".
-----------
W |$2101: OAM (Sprite) sizes.
sssnnbbb
s: Size.
n: Name selection (upper 4k word address).
b: Base selection (8k word segment address).
*** The sizes are defined as follows:
000: 8x8 or 16x16
001: 8x8 or 32x32
*** I've never used this register, nor sprites.
Check Section 6 for information
which was not done by me: If you understand
it better than I do, good deal.
-----------
W |$2102: Address of OAM (Sprites).
???????? | ????????
*** This register i've never used. All I know is
that it's a -WORD- in length, not a byte.
-----------
W |$2104: Data for OAM (Sprites).
????????
*** I've never used this register. It's like $210D:
You have to store a value in it twice.
-----------
W |$2105: Screen mode.
abcdfeee
a: Plane 3 tile size.
b: Plane 2 tile size.
c: Plane 1 tile size.
d: Plane 0 tile size.
0 = 8x8 tiles.
1 = 16x16 tiles.
e: MODE definition.
f: Make Plane 2 take highest priority.
-----------
W |$2106: Screen pixelation (aka. MOSAIC) register.
xxxxabcd
x: 0-$F = Pixel size.
a: Affect plane 3.
b: Affect plane 2.
c: Affect plane 1.
d: Affect plane 0.
*** Just like $2100, this only works during VBlank.
I recommend you setup what planes you want to
affect at the start of the program, then to
make them change, do the following:
LDA #$03 ; Affect planes 0 and 1.
STA TempReg1
STA $2106
JSR WaitVBlank
LDA TempReg1
Loop STA $2106
CLC
ADC #$10
CMP #$F3
BNE Loop
-----------
W |$2107: Plane 0 VRAM location register.
xxxxxxab
x: Address of VRAM location.
ab: Virtual screen size selection.
*** The virtual screen size dealy goes like this:
32x32 to 32x64 to 64x32 to 64x64. Visually,
you only see 32x32(x25) at once unless you
change the ACTUAL screen size.
*** The way I use this register is pretty simple.
Lets say the VRAM is in $2000... Therefore,
we'd go like this:
LDA #$20
STA $2107
-----------
W |$2108: Plane 1 VRAM location register.
W |$2109: Plane 2 VRAM location register.
W |$210A: Plane 3 VRAM location register.
*** All of these follow the same definition as $2107.
-----------
W |$210B: Tile VRAM location register.
aaaabbbb
a: Location of tiles for Plane 1.
b: Location of tiles for Plane 0.
*** The way you use this register is fairly neat.
Since you only have a nybble to work with (which
ranges from $0-F only) your Tile location can
only be $0000 to $F000. You can't have an address
such as $5F91 or $1C4A which holds your tile
data. You just can't have it. :-)
-----------
W |$210C: Tile VRAM location register.
ccccdddd
c: Location of tiles for Plane 3.
d: Location of tiles for Plane 2.
*** Same stats for $210B go for this one; 'cept the
plane registers are different.
-----------
W |$210D: Plane 0 X-scroll register.
*** This register is really funky. You have to write
to it twice in a row (each piece of data being
1 byte). The register is setup as the following:
- You store the first 8 bits (the first byte) which
ranges from $00 to $FF. After you store this
value, you have to store the next 3 bits in the
same register.
*** The following code demonstrates how to move plane 0
left:
LDA Plane0X
DEC
STA Plane0X
STA $210D
STZ $210D
If you make that into a loop by itself, the result
is the plane keeps scrolling left forever; it even
wraps around back to the start.
*** Note: I've been told this is a nasty way to do it
because MODE 7 uses 13 bits of the above,
while the rest use 10. I'm not taking care of
the MSB. :-(
-----------
W |$210E: Plane 0 Y-Scroll register.
W |$210F: Plane 1 X-Scroll register.
W |$2110: Plane 1 Y-Scroll register.
W |$2111: Plane 2 X-Scroll register.
W |$2112: Plane 2 Y-Scroll register.
W |$2113: Plane 3 X-Scroll register.
W |$2114: Plane 3 Y-Scroll register.
*** All of these follow the same definition as $210D.
-----------
W |$2115: Video port control.
*** If you store the following listed values in this register,
the following happens:
$80: H/L increment which determines if the address will be
incremented after it reads/writes to/from $2118 and
$2139, or $2119 and $213A.
W |$2116: Video port address.
*** 16 bit VRAM address.
$2117: Video port address (continued, due to 16 bits).
W |$2118: Video port data.
*** Data register for writing VRAM data.
$2119: Video port data.
*** Same as above.
-----------
W |$211A: MODE 7 Information register.
xy????ab
a: Horizontal or Vertical flip.
b: Horizontal or Vertical flip.
x: Landscape repeat type.
y: Landscape repeat type.
*** I have not the SLIGHTEST idea what the hell
the original author means by this. If someone
can explain it, tell me.
-----------
W |$211B: COS (COSIN) rotate angle / X Expansion.
W |$211C: SIN (SIN) rotate angle / X Expansion.
W |$211D: SIN (SIN) rotate angle / Y Expansion.
W |$211E: COS (COSIN) rotate angle / Y Expansion.
W |$211F: 13 bit address for the center of Rotate X.
W |$2120: 13 bit address for the center of Rotate Y.
*** All above things i've never used, nor do I
have any explainations on them. Use them at
your own risk, or until I get info on 'em.
*** $211F and $2120 are like $210D: You have to
write a byte to them twice.
-----------
W |$2121: Color # (or pallete) selection register.
xxxxxxxx
x: Color # ($00-$FF).
*** This register is probably one of the most simple
registers I know of to use. You simply store the
# of the color you want to modify before writing
to $2122. This register is autoincrementing, so
you don't have to "LDA #$01, STA $2121, LDA #$02,
STA $2121, LDA #$03..." and so on...
Code is as follows:
STZ $2121 ; Start at color 0.
STZ $2122 ; Color #0 = 00 00
STZ $2122
LDA #$FF ; Color #1 = 7F FF (white).
STA $2122
LDA #$7F
STA $2122
LDA #$1F ; Color #2 = 00 1F (red).
STA $2122
STZ $2122
-----------
W |$2122: Color data register.
xxxxxxxx
x: Value of color.
*** Color on the SNES is trippy; it's 15 bit. Check
Section 2 on how the SNES colors are setup. Some
example code I listed for $2121... Anyways, this
register is like $210D (plane X-scroll) and those
types: You have to store the value in it twice.
For instance: If you wanted the color white (which
is $7FFF in SNES-color), you would have to do the
following:
LDA [whatever color #]
STA $2121
LDA #$FF ; We first store the "lower half"
STA $2122
LDA #$7F ; Then the upper...
STA $2122
It's really not that hard, but it'll take some
getting used to :-) Remember, check Section 2 on
how the SNES does it's color, and for tile-setup,
check Section 4.
-----------
W |$212C: Playfield/Sprite-enable register.
abcdefgh
a: Plane 3 enable (for Sprites).
b: Plane 2 enable (for Sprites).
c: Plane 1 enable (for Sprites).
d: Plane 0 enable (for Sprites).
e: Enable plane 3.
f: Enable plane 2.
g: Enable plane 1.
h: Enable plane 0.
*** This register allows you to enable which planes
you want to put sprites on (to move or etc.) and
to scroll, or other neato things. If you wanna
use all 4 planes, but no sprites, shove $0F into
this register. If you want to use all the planes,
but want sprites on planes 1 and 3, you would shove
$AF into this register. It's very easy to do.
-----------
W |$2133: Screen mode register.
????ab?c
a: Interlace Y.
b: Overscan.
c: Interlace X.
*** To be blatently honest, I have -NO IDEA- what
this register does; I don't understand what
Corsair & Dax meant by Interlace and Overscan.
If someone can explain this register to me, i'd
be very grateful :-).
-----------
R |$2139: VRAM port data (reading).
$213A: " "
-----------
?? |$2140 *** These are the audio registers. 'never used 'em.
?? |$2141 Try shoving data into them; who knows, if you get
?? |$2142 music sometime, then you know you're on the right
?? |$2143 track. :-)
-----------
?? |$4200: Counter Enable.
??yx???a
a: Joypad-read Enable (1 = Readable).
x: Horizontal Counter Enable.
y: Vertical Counter Enable.
-----------
?? |$4201: 8 bit parallel data.
*** This is the expansion bus for the Famicom.
-----------
RW |$420B: DMA enable register.
abcdefgh
a: DMA #7.
b: DMA #6.
c: DMA #5.
d: DMA #4.
e: DMA #3.
f: DMA #2.
g: DMA #1.
h: DMA #0.
*** I've personally never used DMA for anything. I hope
someone out there has, and can tell me how to use
it. :-)
-----------
?? |$420D: Memory select.
???????x
x: Fast/Normal ROM flip.
0 = Normal.
1 = Fast.
-----------
R |$4210: VBL register.
x???????
x: VBlank period
1 = On.
0 = Off.
*** This is probably the most important register
you should work with. Without it, you die,
and other things happen. :-) The following
routine allows you to sync to the VBL/wait
for the VBL to pass by so you can do your work:
- LDA $4210
AND #$80
BEQ -
LDA $4210
From a programmers' standpoint, the following
code should do the EXACT SAME as the above,
but faster. NOTE thou, that it doesn't. I
think the timing is off, that's why it doesn't
work right. But, here-goes:
- LDA $4210
BPL -
LDA $4210
-----------
?? |$4211: ?????.
x???????
x: IRQ Enable flag (1: Enabled).
*** I don't even know the DESCRIPTION of the reg-
ister! :-)
-----------
RW |$4212: Joypad-ready register.
???????x
x: Ready-state bit (1: Ready).
*** I'm not sure how this register is setup; all I know
is how to use it. Code is as follows:
PadLoop LDA $4212
AND #$01
BNE PadLoop
This waits for the joypad to become ready to read.
-----------
RW |$4218: Joypad #0 register (1 out of 2).
abcd0000
a: 0 = A button not pressed.
1 = A button pressed.
b: 0 = X button not pressed.
1 = X button pressed.
c: 0 = Top-left button not pressed.
1 = Top-left button pressed.
d: 0 = Top-right button not pressed.
1 = Top-right button pressed.
*** These are self-explainitory. To find out the
status of each bit, just AND #$ for that bit...
The code for checking is the following:
LDA $4218
AND #$80 ; Is the A button pressed?
BNE YesA ; Button pressed (bit is 1).
LDA $4218
AND #$40 ; Is button X pressed?
BNE YesX ; Button pressed (bit is 1).
LDA $4218
AND #$10 ; Is the top-right button pressed?
BNE YesTopR ; Button pressed (bit is 1).
...and so on. It's very simple.
*** Note: The Corsair & Dax document was -WRONG-.
It took me a good hour or two to find this
out, so I decided i'd better write down the
CORRECT way to do things).
-----------
RW |$4219: Joypad #0 register (2 out of 2).
abcdefgh
a: 0 = B button not pressed.
1 = B button pressed.
b: 0 = Y button not pressed.
1 = Y button pressed.
c: 0 = Select button not pressed.
1 = Select button pressed.
d: 0 = Start button not pressed.
1 = Start button pressed.
e: 0 = Up not pressed.
1 = Up pressed.
f: 0 = Down not pressed.
1 = Down pressed.
g: 0 = Left not pressed.
1 = Left pressed.
h: 0 = Right not pressed.
1 = Right pressed.
*** Same as $4218... Some demo code follows:
LDA $4219
AND #$80 ; Is the B button pressed?
BNE YesB ; Button pressed (bit is 1).
LDA $4219
AND #$04 ; Is Down pressed?
BNE YesDown ; Button pressed (bit is 1).
LDA $4219
AND #$02 ; Is Left pressed?
BNE YesLeft ; Button pressed (bit is 1).
-----------
RW |$421A: Joypad #1 register (1 out of 2).
RW |$421B: Joypad #1 register (2 out of 2).
RW |$421C: Joypad #2 register (1 out of 2).
RW |$421D: Joypad #2 register (2 out of 2).
RW |$421E: Joypad #3 register (2 out of 2).
RW |$421F: Joypad #3 register (2 out of 2).
*** Setup is the same as $4218 and $4219.
=-=-=
1) Memory Map
ii) Additional info.
-----------
RW |$FFC0: Cartridge title.
RW |$FFD6: ROM/RAM Info on cart..
RW |$FFD7: ROM Size.
RW |$FFD8: RAM Size.
RW |$FFD9: Maker ID Code.
RW |$FFDB: Version #.
RW |$FFDC: Checksum complement.
RW |$FFDE: Checksum.
RW |$FFEA: NMI vector/VBL Interrupt.
RW |$FFEC: Reset vector.
*** With SMC (Magicom) files the offset is $7e00 less
than above.
*** I've never actually used this information before:
This could be SMC header only; but then why would
there be memory locations for such? Strange. I'll
leave the information I put in up to SNESASM v1.05.
I use the psuedo-ops NAM, VER, and other things.
=-=-=
2) SNES Color explaination.
-----------
Oh BOY! So you're interested in finding out how the SNES does
it's color (via $2122), right? Well here ya go...
The SNES has a strange way of doing color (atleast that i've
seen in my lifetime). Color is 15 bit; each "RGB" value (red,
green, and blue) has 5 bits a piece.
When it comes to putting data into $2122, the format (in binary)
is the following (I put them into each byte):
0bbbbbgg gggrrrrr
|
|_ Someone needs to tell me what this bit
-REALLY- is. I've just been told to set
it to 0...
We guess that the Japanese didn't like the idea of putting them
in the "standard" order of R, G, then B: but instead wanted them
in alphabetical order. Silly! :-).
The way -I- do my color conversions is on a calculator... Just
plug in the bits you want to set in binary, then let the calc.
convert it into hexadecimal. It's pretty easy; or you can be
a Studly Programmer (hehehe) and do it in your head.
A quick color chart: $7FFF: White (0111 1111 1111 1111)
$001F: Red (0000 0000 0001 1111)
$03E0: Green (0000 0011 1110 0000)
$7C00: Blue (0111 1100 0000 0000)
$7C1F: Purple (0111 1100 0001 1111)
$7FE0: Aqua (0111 1111 1110 0000)
$03FF: Yellow (0000 0011 1111 1111);
Well there you have it. It's pretty simple after you get the hang
of it; when using the SNES, you get REALLY good with binary math:
You'll find this out after working with the machine for awhile.
=-=-=
3) DMA Memory Map and explaination.
-----------
?? |$43x0: DMA Control register (??? Not sure ???).
W |$43x1: DMA Destination register.
$18 = Video Port access.
$22 = Color pallete access.
*** This gives access to only some of the video chip.
registers. Hell if I know which ones.
-----------
W |$43x2: Source address.
*** THIS REGISTER IS A WORD IN LENGTH ***
*** The document I have says:
"lo-hi 16 lowest bits". Who knows...
-----------
W |$43x4: Source bank address.
*** The document I have says:
"8 highest bits".
-----------
W |$43x5: Transfer size register.
*** Same as above:
"lo-hi".
-----------
All the "x"s represent the DMA # (ranging from 0 to 7).
DMA #0: $4300-$4305.
DMA #1: $4310-$4315.
......
DMA #7: $4370-$4375.
=-=-=
4) SNES Graphics (tiles) explaination.
-----------
This is probably the most requested section of the document for
people whom are starting out on the SNES and want to learn just
how in the hell the SNES -DOES- do it's graphics.
There's so much to explain!!!
The SNES does it's graphics in tiles (surprise surprise!).
There are different MODEs on the SNES; the most famous being
is MODE 7. Alas: Most people think using $2106 is MODE 7 ($2106
is for screen pixelation: Where the pixels get "larger". Look
in Section 1 for an explaination of this register).
*** THIS IS NOT MODE 7!!! ***.
So the next time the pixels get really "big" (almost making them
look like IBM PC 320x200x256 mode :-)), and your friend says "WOW!
MODE 7 is COOL," punch 'em in the nose for me. Just kidding.
Also, another thing I should mention: Bitplanes are NOT THE SAME
AS PLANES. Planes are like "screens." You can scroll a plane, but
not a bitplane. Bitplanes are put ONTO a plane, which can be
scrolled any direction.
I'll be explaining MODE 1. MODE 7 is too tough for me to
explain, since you end up losing colors and other screwy things...
Check Section-5 for a mode-# list.
MODE #/Playfields MaxColor/Tile Palettes Colors
---------------------------------------------------------------------------
0 4 4 8 16
1 3 16/16/4 (HUH?) 8 128
MODE 0 is good for geometric shapes (if you were going to rotate
a wireframe cube), basic star scrolls, or a very "bland" text
scroller.
Let's start with MODE 1.
MODE 1 is best for really basic things: Star scrollers, text
scrolls, geometric (non detailed) art, or line drawings; it's
only 16 colors/bitplane, and there's only 4 bitplanes to play
with.
What you need is 4 bitplanes of data. You don't -HAVE- to
use 4 bitplanes... You can use 1 bitplane if you want, but
you only get 16 colors (NO!!! :-)).
You also need a plane map: You can't just have the predefined
graphics data and thats it: You have to "setup the plane" to
tell it what tile goes where.
For demonstration purposes, i'll use code to explain it.
-----------
The "lda #$0000" "tcd" transfers the DP location pointer to
where the scratchpad RAM is. This makes things go much faster,
because DP is always faster than normal RAM (yay for DP!!!)
The other part puts where the location of the data in the
binary/image is into two DP locations: font and font2.
font equ $00 ; Direct page equates.
font2 equ font+1
sei
phk
plb
clc
xce
rep #$30
lda #$0000
tcd
lda #charset
sta font
lda #charset2
sta font2
-----------
The following code tells the SNES where the actual data
is in VRAM memory.
lda #$10 ; Plane 0 text @ VRAM $1000.
sta $2107
lda #$02 ; Tiles for Plane 0 @ VRAM $2000.
sta $210b
-----------
The following code actually MOVES the data in the binary/image
into the SNES's VRAM.
sep #$20
ldx #$2000 ; This puts the data sent thru $2118 and
; $2119 into VRAM $2000.
stx $2116
ldy #$0000
- lda (font),y ; Get bitplane 0 data (font)
sta $2118 ; ... and store it in bitplane 0.
lda (font2),y ; Get bitplane 1 data (font2)
sta $2119 ; ... and store it in bitplane 1...
stz $2118 ; I don't want to use bitplane 2 and 3,
stz $2119 ; so I store zeros here. You could put
; more font data in there if you wanted.
iny
cpy #$0200
bne -
ldx #$1000 ; This puts the data sent thru $2118 and
stx $2116 ; $2119 into VRAM $1000.
ldx #$0000
- lda TEXT,x ; Get the character from TEXT...
and #$3f ; AND #$3F because we only want the first
; 64 characters in the font.
sta $2118 ;
stz $2119 ; Check near the end of this Section for
; an explaination on what the actual bits
; do instead of just storing 0 there all
; the time.
inx
cpx #$0400
bne -
-----------
Here's the actual data names (charset, charset2, and TEXT).
My new source has them in dcb % statements to make the font
more readable: The first time I did this, I had to convert
the binary stuff I wrote on paper into hex, then put them
into decent hex statements in an orderly fashion.
charset
dcb $00,$00,$00,$00,$00,$00,$00,$00 ;'@'
dcb $00,$3c,$66,$7e,$66,$66,$66,$00 ;'A'
dcb $00,$7c,$66,$7c,$66,$66,$7c,$00 ;'B'
dcb $00,$3c,$66,$60,$60,$66,$3c,$00 ;'C'
dcb $00,$78,$6c,$66,$66,$6c,$78,$00 ;'D'
dcb $00,$7e,$60,$78,$60,$60,$7e,$00 ;'E'
dcb $00,$7e,$60,$78,$60,$60,$60,$00 ;'F'
dcb $00,$3c,$66,$60,$6e,$66,$3c,$00 ;'G'
dcb $00,$66,$66,$7e,$66,$66,$66,$00 ;'H'
dcb $00,$3c,$18,$18,$18,$18,$3c,$00 ;'I'
dcb $00,$1e,$0c,$0c,$0c,$6c,$38,$00 ;'J'
dcb $00,$6c,$78,$70,$78,$6c,$66,$00 ;'K'
dcb $00,$60,$60,$60,$60,$60,$7e,$00 ;'L'
dcb $00,$63,$77,$7f,$6b,$63,$63,$00 ;'M'
dcb $00,$66,$76,$7e,$7e,$6e,$66,$00 ;'N'
dcb $00,$3c,$66,$66,$66,$66,$3c,$00 ;'O'
dcb $00,$7c,$66,$66,$7c,$60,$60,$00 ;'P'
dcb $00,$3c,$66,$66,$66,$3c,$0e,$00 ;'Q'
dcb $00,$7c,$66,$66,$7c,$6c,$66,$00 ;'R'
dcb $00,$3e,$60,$3c,$06,$66,$3c,$00 ;'S'
dcb $00,$7e,$18,$18,$18,$18,$18,$00 ;'T'
dcb $00,$66,$66,$66,$66,$66,$3c,$00 ;'U'
dcb $00,$66,$66,$66,$66,$3c,$18,$00 ;'V'
dcb $00,$63,$63,$6b,$7f,$77,$63,$00 ;'W'
dcb $00,$66,$3c,$18,$3c,$66,$66,$00 ;'X'
dcb $00,$66,$66,$3c,$18,$18,$18,$00 ;'Y'
dcb $00,$7e,$0c,$18,$30,$60,$7e,$00 ;'Z'
dcb $08,$00,$00,$00,$00,$00,$00,$00 ;'['
dcb $00,$00,$00,$00,$00,$00,$00,$00 ;'\'
dcb $00,$00,$00,$00,$00,$00,$00,$00 ;']'
dcb $00,$00,$00,$00,$00,$00,$00,$00 ;'^'
dcb $00,$08,$00,$00,$00,$00,$00,$00 ;'_'
dcb $00,$00,$00,$00,$00,$00,$00,$00 ;' '
dcb $00,$7E,$7E,$3C,$18,$00,$18,$00 ;'!'
dcb $00,$00,$00,$00,$00,$00,$00,$00 ;'"'
dcb $80,$80,$80,$80,$80,$80,$80,$80 ;'#'
dcb $FC,$FE,$FF,$F7,$F7,$FF,$FE,$FC ;'$'
dcb $3E,$42,$4E,$5C,$5C,$4E,$42,$3E ;'%'
dcb $00,$00,$00,$00,$00,$00,$00,$01 ;'&'
dcb $00,$00,$00,$07,$00,$00,$00,$00 ;'''
dcb $00,$04,$08,$08,$08,$08,$04,$00 ;'('
dcb $00,$20,$10,$10,$10,$10,$20,$00 ;')'
dcb $08,$08,$08,$F8,$08,$08,$08,$08 ;'*'
dcb $10,$10,$10,$1F,$10,$10,$10,$10 ;'+'
dcb $10,$10,$20,$C0,$00,$00,$00,$00 ;','
dcb $00,$00,$00,$FF,$00,$00,$00,$00 ;'-'
dcb $00,$00,$00,$00,$00,$18,$18,$00 ;'.'
dcb $00,$00,$00,$FF,$80,$80,$80,$80 ;'/'
dcb $00,$3c,$66,$6e,$76,$66,$3c,$00 ;'0'
dcb $00,$18,$38,$18,$18,$18,$7e,$00 ;'1'
dcb $00,$7c,$06,$0c,$30,$60,$7e,$00 ;'2'
dcb $00,$7e,$06,$1c,$06,$66,$3c,$00 ;'3'
dcb $00,$0e,$1e,$36,$7f,$06,$06,$00 ;'4'
dcb $00,$7e,$60,$7c,$06,$66,$3c,$00 ;'5'
dcb $00,$3e,$60,$7c,$66,$66,$3c,$00 ;'6'
dcb $00,$7e,$06,$0c,$0c,$0c,$0c,$00 ;'7'
dcb $00,$3c,$66,$3c,$66,$66,$3c,$00 ;'8'
dcb $00,$3c,$66,$3e,$06,$66,$3c,$00 ;'9'
dcb $00,$00,$00,$03,$04,$08,$08,$08 ;':'
dcb $00,$80,$80,$F0,$80,$80,$00,$00 ;';'
dcb $80,$80,$80,$FF,$00,$00,$00,$00 ;'<'
dcb $00,$00,$00,$C0,$20,$10,$10,$10 ;'='
dcb $08,$08,$04,$03,$00,$00,$00,$00 ;'>'
dcb $00,$00,$00,$00,$00,$00,$00,$00 ;'?'
charset2
dcb $00,$3C,$4E,$5E,$5E,$40,$3C,$00 ;'@'
dcb $00,$3c,$66,$7e,$66,$66,$66,$00 ;'A'
dcb $00,$7c,$66,$7c,$66,$66,$7c,$00 ;'B'
dcb $00,$3c,$66,$60,$60,$66,$3c,$00 ;'C'
dcb $00,$78,$6c,$66,$66,$6c,$78,$00 ;'D'
dcb $00,$7e,$60,$78,$60,$60,$7e,$00 ;'E'
dcb $00,$7e,$60,$78,$60,$60,$60,$00 ;'F'
dcb $00,$3c,$66,$60,$6e,$66,$3c,$00 ;'G'
dcb $00,$66,$66,$7e,$66,$66,$66,$00 ;'H'
dcb $00,$3c,$18,$18,$18,$18,$3c,$00 ;'I'
dcb $00,$1e,$0c,$0c,$0c,$6c,$38,$00 ;'J'
dcb $00,$6c,$78,$70,$78,$6c,$66,$00 ;'K'
dcb $00,$60,$60,$60,$60,$60,$7e,$00 ;'L'
dcb $00,$63,$77,$7f,$6b,$63,$63,$00 ;'M'
dcb $00,$66,$76,$7e,$7e,$6e,$66,$00 ;'N'
dcb $00,$3c,$66,$66,$66,$66,$3c,$00 ;'O'
dcb $00,$7c,$66,$66,$7c,$60,$60,$00 ;'P'
dcb $00,$3c,$66,$66,$66,$3c,$0e,$00 ;'Q'
dcb $00,$7c,$66,$66,$7c,$6c,$66,$00 ;'R'
dcb $00,$3e,$60,$3c,$06,$66,$3c,$00 ;'S'
dcb $00,$7e,$18,$18,$18,$18,$18,$00 ;'T'
dcb $00,$66,$66,$66,$66,$66,$3c,$00 ;'U'
dcb $00,$66,$66,$66,$66,$3c,$18,$00 ;'V'
dcb $00,$63,$63,$6b,$7f,$77,$63,$00 ;'W'
dcb $00,$66,$3c,$18,$3c,$66,$66,$00 ;'X'
dcb $00,$66,$66,$3c,$18,$18,$18,$00 ;'Y'
dcb $00,$7e,$0c,$18,$30,$60,$7e,$00 ;'Z'
dcb $00,$00,$00,$00,$00,$00,$00,$00 ;'['
dcb $09,$09,$00,$00,$00,$00,$00,$00 ;'\'
dcb $00,$00,$00,$00,$00,$00,$00,$00 ;']'
dcb $00,$00,$00,$00,$00,$00,$00,$00 ;'^'
dcb $00,$08,$00,$00,$00,$00,$00,$00 ;'_'
dcb $00,$00,$00,$00,$00,$00,$00,$00 ;' '
dcb $00,$7E,$7E,$3C,$18,$00,$18,$00 ;'!'
dcb $00,$00,$00,$00,$00,$00,$00,$00 ;'"'
dcb $80,$80,$80,$80,$80,$80,$80,$80 ;'#'
dcb $FC,$FE,$FF,$F7,$F7,$FF,$FE,$FC ;'$'
dcb $3E,$42,$4E,$5C,$5C,$4E,$42,$3E ;'%'
dcb $00,$00,$00,$00,$00,$00,$00,$01 ;'&'
dcb $00,$00,$00,$07,$00,$00,$00,$00 ;'''
dcb $00,$04,$08,$08,$08,$08,$04,$00 ;'('
dcb $00,$20,$10,$10,$10,$10,$20,$00 ;')'
dcb $08,$08,$08,$F8,$08,$08,$08,$08 ;'*'
dcb $10,$10,$10,$1F,$10,$10,$10,$10 ;'+'
dcb $10,$10,$20,$C0,$00,$00,$00,$00 ;','
dcb $00,$00,$00,$FF,$00,$00,$00,$00 ;'-'
dcb $00,$00,$00,$00,$00,$18,$18,$00 ;'.'
dcb $00,$00,$00,$FF,$80,$80,$80,$80 ;'/'
dcb $00,$3c,$66,$6e,$76,$66,$3c,$00 ;'0'
dcb $00,$18,$38,$18,$18,$18,$7e,$00 ;'1'
dcb $00,$7c,$06,$0c,$30,$60,$7e,$00 ;'2'
dcb $00,$7e,$06,$1c,$06,$66,$3c,$00 ;'3'
dcb $00,$0e,$1e,$36,$7f,$06,$06,$00 ;'4'
dcb $00,$7e,$60,$7c,$06,$66,$3c,$00 ;'5'
dcb $00,$3e,$60,$7c,$66,$66,$3c,$00 ;'6'
dcb $00,$7e,$06,$0c,$0c,$0c,$0c,$00 ;'7'
dcb $00,$3c,$66,$3c,$66,$66,$3c,$00 ;'8'
dcb $00,$3c,$66,$3e,$06,$66,$3c,$00 ;'9'
dcb $00,$00,$00,$03,$04,$08,$08,$08 ;':'
dcb $00,$80,$80,$F0,$80,$80,$00,$00 ;';'
dcb $80,$80,$80,$FF,$00,$00,$00,$00 ;'<'
dcb $00,$00,$00,$C0,$20,$10,$10,$10 ;'='
dcb $08,$08,$04,$03,$00,$00,$00,$00 ;'>'
dcb $00,$00,$00,$00,$00,$00,$00,$00 ;'?'
TEXT dcb " THIS IS YOUR ENTIRE SCREEN "
dcb " HERE... IF YOU REMOVE ONE OF "
dcb " THE LINES WHICH IS BLANK, THE "
dcb " SCREEN ENDS UP BEING FUNKY "
dcb " DOWN AT THE BOTTOM OF THE "
dcb " SCREEN. "
dcb " "
dcb " SO MAKE SURE YOU ALWAYS LEAVE "
dcb " ALL OF THIS TEXT THINGS IN! "
dcb " "
dcb " "
dcb " "
dcb " YOSHI THE DINO "
dcb " "
dcb " "
dcb " "
dcb " "
dcb " "
dcb " "
dcb " "
dcb " "
dcb " "
dcb " "
dcb " "
dcb " "
dcb " "
dcb " "
dcb " "
dcb " "
dcb "********************************"
dcb " "
dcb " "
-----------
Well there's some code for those whom want to rip it :-).
I hope I haven't confused you yet: If I have, go back and re-read
the code. I've been working with the SNES for awhile, so I under-
stand a little more than a beginner.
You're probably wondering how the heck the following line ends
up being an "@" on your TV, or whatever you have your SNES
hooked up to.
Lets look at charset and charset2.
charset
dcb $00,$00,$00,$00,$00,$00,$00,$00 ;'@'
charset2
dcb $00,$3C,$4E,$5E,$5E,$40,$3C,$00 ;'@'
Convert charsets hex-statements into binary. Consider each
new "$xx" statement a new pixel line. Tile size is 8x8.
00000000 = $00
00000000 = $00
00000000 = $00
00000000 = $00
00000000 = $00
00000000 = $00
00000000 = $00
00000000 = $00
Convert charset2s hex-statements into binary.
00000000 = $00
00111100 = $3C
01001110 = $4E
01011110 = $5E
01011110 = $5E
01000000 = $40
00111100 = $3C
00000000 = $00
*NOW* do you see the at-symbol? (and yes, I -DID- draw all
of the font by hand. It took me HOURS, but I did it).
You're probably now asking: "Well, that tells me how to define
where a pixel IS: but how do I define it's color?"
This is the fun part. It's sort-of hard to explain:
If you have a 0 for bitplane 0, a 0 for bitplane 1, a 0 for
bitplane 2, and a 0 for bitplane 3, you get the color 0.
i.e.: 0000 = Color #0
||||___________Bitplane 0
|||__________Bitplane 1
||_________Bitplane 2
|________Bitplane 3
So, think about a 0 for bitplane 0, a 1 for bitplane 1 & 2
and a 0 for bitplane 3.
i.e.: 0110 = Color #6
||||___________Bitplane 0
|||__________Bitplane 1
||_________Bitplane 2
|________Bitplane 3
This is probably the best explaination i've ever seen done about
SNES pixel-color definition, so don't plan on seeing one any
better anytime soon :-).
Anyway, the result above gives you the color # per pixel; it's
fairly interesting... it's like an "overlay" type of method.
I mentioned in the source above that you should check near the
end of the Section for info on why I "stz $2119". Well, here's
why: The bits in the tile-data are fairly "silly": The tile
"character" itself is 10 bits, while the other 6 are "fun bits,"
as I call them. Here's the explaination:
yx?cccNN | NNNNNNNN
y: Flip the tile vertically.
x: Flip the tile horiztonally.
?: Dunno! Set it to 1 and find out.
c: Pallete # (0-7).
N: Character itself.
So, I STZ there: Yes, I leave the top bits "unset," which means
you could get messed up data, but as far as I have checked, the
SNES has "clear memory" when you start it up: So the bits I don't
zero-out should be zeros anyways! :-) If you want to set them,
feel free to do so! The results of flipping Y and X are sortof
fun to play with. "To read this scrolly, you must stand on your
head" :-)
=-=-=
5) SNES Screen mode definitions.
-----------
MODE # of bitplanes Colors per plane Palletes Max. # of colors
---------------------------------------------------------------------------
0 2 4 8 32
1 4 16 8 128
2 ? ??? ? ???
3 8 256 1 256
4 ? ??? ? ???
5 ? ??? ? ???
6 ? 16 8 128 (Interlaced mode)
7 ? 256 1 256 (Yes, MODE 7)
---------------------------------------------------------------------------
The parms which have "?" or "???" mean I don't know what they REALLY
are: I got a document which explained them, but it was bogus: It
said a 16 color mode had -1- bitplane. Weird... I'm not even sure
about MODE 6. But, we know what MODE 7 is, even if I'm not sure how
many bitplanes it DOES use (the doc says 1, I say 8).
I've tested MODE 0 and 1 myself. MODE 3 I might test in the future,
but i've never had the desire to draw up 8 bitplanes of data by
hand ( I don't have a SNES-graphics-generator for the PC! :-( ).
=-=-=
6) SNES OAM/Sprite explaination.
-----------
The sprites use a lookup table that contains info on their X and
Y position on the screen, their size, if they're flipped horizontally
or vertically, their color, and the actual character.
The format you need to make the table in is as follows:
Size Address/Offset Explaination
---------------------------------------------------------------------------
*** SPRITE 0 ***
BYTE 0
xxxxxxxx
x: X location.
BYTE 1
yyyyyyyy
y: Y location.
WORD 2+3
abcdeeex | xxxxxxxx
a: Vertical flip.
b: Horizontal flip.
c: Playfield priority.
d: Playfield priority.
e: Pallete #.
x: Character #.
*** SPRITE 0 ***
BYTE 4
xxxxxxxx
x: X location.
BYTE 5
yyyyyyyy
y: Y location.
....... and so on .......
---------------------------------------------------------------------------
Continue this table all the way down to sprite #127 (the 128th
sprite).
Don't think you're

BIN
files/docs/snes/SNESKART.doc Normal file
View File

Binary file not shown.

BIN
files/docs/snes/SNESKart-TurtleGroupInc..pdf Normal file
View File

Binary file not shown.

1379
files/docs/snes/SNESMAP2.TXT Normal file
View File

File diff suppressed because it is too large Load Diff

92
files/docs/snes/SNESMNEM.TXT Normal file
View File

@ -0,0 +1,92 @@
add add adress for all instruction fetches
adc add memory to accumulator with carry
and 'and' memory with accumulator
asl arithmic shift left 1 bit (memory or accumulator)
bcc branch on carry clear C=0
bcs branch on carry set C=1
beq branch if equal Z=1
bit bit test
bmi branch if result is negative N=1
bne branch if not equal Z=0
bpl branch if result is plus N=0
bra branch always
brk force break
brl branch always long
bvc branch on overflow clear V=0
bvs branch on overflow set V=1
clc clear carry flag C=0
cld clear decimal mode D=0
cli clear interrupt disable bit I=0
clv clear overflow flag V=0
cmp compare memory and accumulator
cop coprocessor
cpx compare memory and index x
cpy compare memory and index y
dec decrement memory or accumulator by one
dex decrement index x by one
dey decrement index y by one
eor exclusive 'or' memory with accumulator
inc increment memory or accumulator by one
inx increment index x by one
iny increment index y by one
jml jump long other banks possible
jmp jump to location in same bank
jsl jump to subroutine long
jsr jump to subroutine in same bank
lda load accumulator with memory
ldx load index x with memory
ldy load index y with memory
lsr logical shift right by one bit (memory or accu)
mvn move block negative (uses x,y,a)
mvp move block positive (uses x,y,a)
nop no operation
ora 'or' memory with accumulator
pea push effective adres (or data) on stack
pei push effective indirect adres on stack
per push effective program counter relative adres on stack
pha push accumulator on stack
phb push data bank register on stack
phd push direct register on stack
phk push program bank register on stack
php push processor status on stack
phx push index register x on stack
phy push index register y on stack
pla pull accumulator from stack
plb pull data bank register from stack
pld pull direct register from stack
plp pull processor status from stack
plx pull index x from stack
ply pull index y from stack
rep reset processor status bits
rol rotate left one bit (memory or accu)
ror rorate right one bit (memory or accu)
rti return from interrupt
rtl return from subroutine long
rts return from subroutine
sbc subtract memory from accumulator with borrow
sec set carry flag C=1
sed set decimal mode D=1
sei set interrupt disable status I=1
sep set processor status bits
sta store accumulator in memory
stp stop the clock (only reset will help)
stx store index x in memory
sty store index y in memory
stz store zero in memory
tad (tcd) transfer accumulator to direct register
tas (tcs) transfer accumulator to stack pointer register
tax transfer accumulator to index x
tay transfer accumulator to index y
tda (tdc) transfer direct register to accumulator
trb test and reset bit
tsa (tsc) transfer stack pointer register to accumulator
tsb test and set bit
tsx transfer stack pointer register to index x
txa transfer index x to accumulator
txs transfer index x to stack pointer register
txy transfer index x to index y
tya transfer index y to accumulator
tyx transfer index y to index x
wai wait for interrupt
xba exchange accumulator high and low 8 bits
xce exchange carry and emulation bits

129
files/docs/snes/SNESMem.txt Normal file
View File

@ -0,0 +1,129 @@
+=-=-=-=-=-=-=-=-=-=-=+
| SNES Memory Mapping |
| By: ]SiMKiN[ |
| v2.0 |
+=-=-=-=-=-=-=-=-=-=-=+
• FastROM's can execute at 3.58Mhz
• SlowROM's can only execute 2.68Mhz
• The SNES lets you access ROM through bank $00 onwards and bank
$80 onwards such that locations $00:8000 and $80:8000 are congruent,
(they access the same locations.)
• When accessing bank $00 onwards the 65816 runs at 2.68Mhz. However,
when accessing bank $80 onwards the 65816 can run at 2.68Mhz or
3.58Mhz depending on how you set bit 0 of $420D.
• This Document Contains Information Regarding ROM's upto 32mbit.
If you have any information regarding ROM's above 32mbit please send
E-Mail to 'simkin@innocent.com'
+======================================================================+
| Mode 20: LoROM Memory Model (32k Banks) |
| --------------------------------------- |
| • $80-$ef : $8000-$ffff |
| Mirrored to $00-6f |
| • $f0-$ff : $8000-$ffff |
+=========+=============+====================================+=========+
| Bank | Offset | Definition | Shadow |
+=========+=============+====================================+=========+
| $00-$2f | $0000-$1fff | LowRAM, shadowed from $7e | $7e |
| | $2000-$2fff | PPU1, APU | $00-$3f |
| | $3000-$3fff | SFX, DSP, etc. | $00-$3f |
| | $4000-$41ff | Controller | $00-$3f |
| | $4200-$5fff | PPU2, DMA, etc. | $00-$3f |
| | $6000-$7fff | RESERVED | $00-$3f |
| | $8000-$ffff | (Mode 20 ROM) | ------- |
+---------+-------------+------------------------------------+---------+
| $30-$3f | $0000-$1fff | LowRAM, shadowed from $7e | $7e |
| | $2000-$2fff | PPU1, APU | $00-$3f |
| | $3000-$3fff | SFX, DSP, etc. | $00-$3f |
| | $4000-$41ff | Controller | $00-$3f |
| | $4200-$5fff | PPU2, DMA, etc. | $00-$3f |
| | $6000-$7fff | RESERVED | ------- |
| | $8000-$ffff | (Mode 20 ROM) | $80-$bf |
+---------+-------------+------------------------------------+---------+
| $40-$6f | $0000-$7fff | RESERVED | ------- |
| | $8000-$ffff | (Mode 20 ROM) | $C0-$EF |
+---------+-------------+------------------------------------+---------+
| $70-$77 | $0000-$ffff | (Mode 20 SRAM) 256KBytes | ------- |
+---------+-------------+------------------------------------+---------+
| $78-$7d | $0000-$ffff | RESERVED | ------- |
+---------+-------------+------------------------------------+---------+
| $7e | $0000-$1fff | LowRAM | $00-$3f |
| | $2000-$7fff | HighRAM | ------- |
| | $8000-$ffff | Expanded RAM | ------- |
+---------+-------------+------------------------------------+---------+
| $7f | $0000-$ffff | Expanded RAM | ------- |
+---------+-------------+------------------------------------+---------+
| $80-$ef | $0000-$ffff | Mirror of $00-$6f | $00-$6f |
+---------+-------------+------------------------------------+---------+
| $f0-$ff | $0000-$7fff | RESERVED | ------- |
| | $8000-$ffff | (Mode 20 ROM) | ------- |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
+======================================================================+
| Mode 21: HiROM Memory Model (64k Banks) |
| --------------------------------------- |
| • $C0-$ff : $0000-$ffff |
| High Parts ONLY '($8000-$ffff)' are Shadowed to $00-3f |
+=========+=============+====================================+=========+
| Bank | Offset | Definition | Shadow |
+=========+=============+====================================+=========+
| $00-$2f | $0000-$1fff | LowRAM, shadowed from $7e | $7e |
| | $2000-$2fff | PPU1, APU | $00-$3f |
| | $3000-$3fff | SFX, DSP, etc. | $00-$3f |
| | $4000-$41ff | Controller | $00-$3f |
| | $4200-$5fff | PPU2, DMA, etc. | $00-$3f |
| | $6000-$7fff | RESERVED | $00-$3f |
| | $8000-$ffff | (Mode 21 ROM) from $C0-$EF | $C0-$EF |
+---------+-------------+------------------------------------+---------+
| $30-$3f | $0000-$1fff | LowRAM, shadowed from $7e | $7e |
| | $2000-$2fff | PPU1, APU | $00-$3f |
| | $3000-$3fff | SFX, DSP, etc. | $00-$3f |
| | $4000-$41ff | Controller | $00-$3f |
| | $4200-$5fff | PPU2, DMA, etc. | $00-$3f |
| | $6000-$7fff | (Mode 21 SRAM) 256KBytes | ------- |
| | $8000-$ffff | (Mode 21 ROM) from $C0-$EF | $C0-$EF |
+---------+-------------+------------------------------------+---------+
| $40-$6f | $0000-$7fff | (Mode 21 ROM) from $C0-$EF | $C0-$EF |
+---------+-------------+------------------------------------+---------+
| $70-$77 | $0000-$ffff | (Mode 20 SRAM) 256KBytes | ------- |
+---------+-------------+------------------------------------+---------+
| $78-$7d | $0000-$ffff | RESERVED | ------- |
+---------+-------------+------------------------------------+---------+
| $7e | $0000-$1fff | LowRAM | $00-$3f |
| | $2000-$7fff | HighRAM | ------- |
| | $8000-$ffff | Expanded RAM | ------- |
+---------+-------------+------------------------------------+---------+
| $7f | $0000-$ffff | Expanded RAM | ------- |
+---------+-------------+------------------------------------+---------+
| $80-$bf | $0000-$ffff | Mirror of $00-$3f | $00-$3f |
+---------+-------------+------------------------------------+---------+
| $c0-$ff | $0000-$ffff | (Mode 21 ROM) | ------- |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
• ROM: The SNES ROM Image
• RAM: The SNES Work Memory (WRAM)
LowRAM, HighRAM, & Expanded RAM
All together = 128 Kilo-Bytes
• SRAM: Save RAM (Extra RAM added by Cart)
The SNES only utilizes 256 Kilo-bits
However 256 Kilo-Bytes are provided.
• APU: Audio Processing Unit
SPC700, Inside which has a DSP
• PPU: Picture Processing Unit
PPU1: 5c77-01
PPU2: 5c78-03
• SFX: Super FX Cart Chip, by Nintendo
• DSP: Digital Signal Processing Cart Chip
a.k.a. 'NEC mUPD77C25'
• Shadow: "Congruent Bank". Same meaning as Mirror.
_____________________________________________________
.o(_Thanx to: zsKnight, Lord Esnes, Y0SHi, and MintaBoo_)o.

82
files/docs/snes/SNESMem2.txt Normal file
View File

@ -0,0 +1,82 @@
+=-=-=-=-=-=-=-=-=-=-=+
| SNES Memory Mapping |
| By: ]SiMKiN[ |
| v1.0 |
+=-=-=-=-=-=-=-=-=-=-=+
• LoROM: Mode 20
• HiROM: Mode 21
• FastROM's can execute at 3.58Mhz
• SlowROM's can only execute 2.68Mhz
• The SNES lets you access ROM through bank $00 onwards and bank
$80 onwards such that locations $00:8000 and $80:8000 are congruent,
(they access the same locations.)
• When accessing bank $00 onwards the 65816 runs at 2.68Mhz. However,
when accessing bank $80 onwards the 65816 can run at 2.68Mhz or
3.58Mhz depending on how you set bit 0 of $420D.
+=========+=============+====================================+=========+
| Bank | Offset | Definition | Shadow |
+=========+=============+====================================+=========+
| $00-$2f | $0000-$1fff | LowRAM, each bank is shadowed | $00-$3f |
| | | From bank $7e | $7e |
| | $2000-$2fff | PPU1, APU | $00-$3f |
| | $3000-$3fff | SFX, DSP, etc. | $00-$3f |
| | $4000-$41ff | Controller | $00-$3f |
| | $4200-$5fff | PPU2, DMA, etc. | $00-$3f |
| | $6000-$7fff | Reserved? | $00-$3f |
| | $8000-$ffff | (Mode 20, 21 - ROM) | ------- |
+---------+-------------+------------------------------------+---------+
| $30-$3f | $0000-$1fff | LowRAM, each bank is shadowed | $00-$3f |
| | | From bank $7e | $7e |
| | $2000-$2fff | PPU1, APU | $00-$3f |
| | $3000-$3fff | SFX, DSP, etc. | $00-$3f |
| | $4000-$41ff | Controller | $00-$3f |
| | $4200-$5fff | PPU2, DMA, etc. | $00-$3f |
| | $6000-$7fff | (Mode 21 - SRAM) 256KBytes | ------- |
| | $8000-$ffff | (Mode 20, 21 - ROM) | ------- |
+---------+-------------+------------------------------------+---------+
| $40-$6f | $0000-$7fff | (Mode 21 - ROM) | ------- |
| | $8000-$ffff | (Mode 20, 21 - ROM) | ------- |
+---------+-------------+------------------------------------+---------+
| $70-$77 | $0000-$ffff | (Mode 20, 21 - SRAM) 256KBytes | ------- |
+---------+-------------+------------------------------------+---------+
| $78-$7d | $0000-$ffff | Never Used | ------- |
+---------+-------------+------------------------------------+---------+
| $7e | $0000-$1fff | LowRAM | $00-$3f |
| | | Shadowed to banks $00-$3f | ------- |
| | $2000-$7fff | HighRAM | ------- |
| | $8000-$ffff | Expanded Ram | ------- |
+---------+-------------+------------------------------------+---------+
| $7f | $0000-$ffff | More Expanded RAM | ------- |
+---------+-------------+------------------------------------+---------+
| $80-$ef | $0000-$ffff | Mirror of $00-$6f | $00-$6f |
+---------+-------------+------------------------------------+---------+
| $f0-$ff | $0000-$ffff | (Mode 21 - ROM) | ------- |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
• ROM: The SNES ROM Image
• RAM: The SNES Work Memory (WRAM)
LowRAM, HighRAM, & Expanded RAM
All together = 128 Kilo-Bytes
• SRAM: Save RAM (Extra RAM added by Cart)
The SNES only utilizes 256 Kilo-bits
However 256 Kilo-Bytes are provided.
• APU: Audio Processing Unit
SPC700, Inside which has a DSP
• PPU: Picture Processing Unit
PPU1: 5c77-01
PPU2: 5c78-03
• SFX: Super FX Cart Chip, by Nintendo
• DSP: Digital Signal Processing Cart Chip
a.k.a. 'NEC mUPD77C25'
• Shadow: "Congruent Bank". Same meaning as Mirror.
_________________________________________________
.o(_Thanx to: Y0SHi, zsKnight, MrGrim, and MintaBoo_)o.

35
files/docs/snes/SNESROM.PIN Normal file
View File

@ -0,0 +1,35 @@
Here's the pinout to a 4Mbit/*Mbit mask Rom used in SNES carts as I've
deduced from various specs and actual testing.
1 A17 ------\__/------ +5v 32
2 A18 | | *OE 31
3 A15 A19 30
4 A12 A14 29
5 A7 A13 28
6 A6 A8 27
7 A5 A9 26
8 A4 A11 25
9 A3 A16 24
10 A2 A10 23
11 A1 *CE 22
12 A0 D7 21
13 D0 D6 20
14 D1 D5 19
15 D2 D4 18
16 GND |---------------| D3 17
The design approximates std EPROM/SRAM pinouts except for the upper address
lines (A16-A19), and OE which sits where VPP or PRGM usually is for an EPROM.
This pinout approximates Fujitsu's tentative mask ROM pinouts (a package
called GAMEMEDC.ZIP seems to base itself on this and is consequently wrong).
Nintendo uses Fujitsu chips in some carts, but from my testing and card-edge
pinouts provided by other users, I conclude that Fujitsu must have modified
the designs.
NOTE!: Card-edge pin #40, address line 15 (A15) is not used by any cart I've
seen. And ROM pin #3 (see above) that I've determined to be A15 is connected
to card-edge pin#41, labeled on many pinouts schems as A16..not A15!!!
Would some one please verify this inconsistency.
PS: How many Megabits can the Snes address?

373
files/docs/snes/SNES_Lockout.txt Normal file
View File

@ -0,0 +1,373 @@
Disabling the Super NES/Super Famicom "Lockout Chip"
====================================================
(rev. 0.5 27-Dec-97)
[Expert summary: disconnect CIC pin 4]
This document is copyright © 1997 by Mark Knibbs <mark_k@iname.com>. The latest
version, and several other console-related documents, should be available at:
http://www.netcomuk.co.uk/~markk/index.html
The direct URL for this file is:
http://www.netcomuk.co.uk/~markk/Consoles/SNES_Lockout.txt
You are explicitly permitted to include the *unmodified* document on web sites,
FTP sites and the like. But it is best to simply link to the document on my web
page, as this means that you automatically pick up any changes made.
If you have any comments, suggestions or questions about this document, please
contact me. If you would like to perform a similar modification to your NES 8-
bit console, you should see:
http://www.netcomuk.co.uk/~markk/Consoles/NES_Lockout.txt
Revision History
----------------
0.1 27-Jul-97 First release.
0.2 19-Aug-97 Added information about another PCB revision and the lockout
chip used in U.S./Japanese consoles.Various other small
changes.
0.3 21-Aug-97 Added information about later model U.S. console (PCB
revision SNS-CPU-GPM-01). Added section about removing a game
pak with power on. Other minor changes.
0.4 22-Sep-97 Changed email address and web URLs. Added "Possible
Incompatibilities" section.
0.5 27-Dec-97 Added step describing how to dissipate stored charge in the
console before opening it. Added paragraph on precautions
against static electricity. Added pointer to my SNES 50/60Hz
modification document. Minor edits and changes.
Introduction
------------
This document details a simple modification that you can perform on your Super
NES or Super Famicom 16-bit video game console in order to disable the "lockout
chip" protection system. The "lockout chip" system means that no PAL games can
be played on an unmodified U.S. or Japanese console, or vice versa.
If you have a PAL model Super NES, I strongly recommend that you also fit a
switch to change between 50Hz and 60Hz modes. 60Hz mode runs games full-screen,
at the correct speed (20% faster than the usual PAL speed). Additionally, more
recent games (e.g. Super Mario All-Stars, Super Metroid) contain code to check
for 60Hz. So it is not usually possible to run, say, the Japanese version of
such a game on a PAL console. Details of this modification, and an accompanying
picture, can be found at:
http://www.netcomuk.co.uk/~markk/index.html
The procedure given here should work for ANY model Super NES or Super Famicom,
both NTSC and PAL versions. As of this writing I have only applied the
modification to two UK model PAL Super NES consoles.
Why might you want to do this? Well, I can think of a few reasons:
· You own a PAL Super NES, and currently have to use a clumsy "universal
adapter" to be able to use American or Japanese games - with this
modification you are able to directly use Japanese cartridges, and can use
American games either by cutting a larger hole for the cartridge, or using
an extension adapter (you can use your old universal adapter for this - you
will no longer need to plug in the second "domestic" cartridge);
· You own illicit or unlicensed games which can't be played on your console (I
have seen a counterfeit Street Fighter II cartridge which contains no lockout
chip, and thus normally requires that a universal adapter be used);
· If you own an American model console, you can make it run almost every SNES
game by removing the tabs behind the cartridge slot, disabling the lockout
chip, and fitting a 50Hz/60Hz switch. If you have a PAL or Japanese console,
you will need to file away the cartridge slot in order to accomodate the
larger U.S. cartridges, if you want to be able to directly run every game.
If you perform this procedure on your console, PLEASE LET ME KNOW WHETHER IT
WORKS! I want to update this document so that it's applicable to as many
consoles as possible. Please also tell me which PCB revision your console has
(e.g. "SHVC-CPU-01"), the model (e.g. "SNS-001"), serial number, and the date
code stamped on the label underneath (e.g. "9313"). I don't anticipate there
being many relevant differences between different SNES models, though. I would
welcome any comments you have about this document. Send them to the email
address given above.
If you are interested in the operation of the lockout chip and Nintendo's
history in general, you might like to read David Sheff's book "Game Over", and
consult U.S. patents 4,799,635 and/or 5,070,479. Indeed, I obtained the
information necessary to carry out this modification from one of the patents.
Background
----------
Before the NES was first released in the U.S.A., Nintendo developed a system
for preventing the use of unauthorised software with it. Much counterfeit
software had apparently been produced for their Famicom (Family Computer)
system, and Nintendo wanted to avoid this happening for the NES.
Another benefit (to Nintendo) of the system was that legal third-party
development was severely hindered. Only Nintendo licensees could buy the
lockout chips, one of which was fitted inside every game cartridge. Licensees
were apparently charged around US$9 for each chip, in addition to having to pay
steep royalties. Nintendo patented the lockout chip concept, and copyrighted
the code contain within it.
Nintendo also used the lockout system to provide "territorial protection". This
means that you can't use a U.K. or European NES game in a U.S. console, for
example.
Nintendo used exactly the same system for the Super NES. American and Japanese
consoles use identical lockout chips. You can run Japanese games on an American
console by simply removing two plastic tabs from behind the cartridge slot.
PAL versions of the Super NES use a different lockout chip. So PAL cartridges
cannot be played on an American or Japanese machine, or vice versa. Many
companies produced "universal adapters" to get around this problem. Typically,
these have two cartridge slots. You put the foreign game in one, and a domestic
game in the other. The adapter uses the lockout chip from the domestic game to
enable the foreign game to be played.
How the Lockout System Works
----------------------------
This is a very brief, simplified description. Consult Nintendo's patent for
detailed information.
Functionally identical chips are fitted in the console and inside every game
cartridge. (For the SNES, the chips are packaged differently - the one inside
the console is surface-mounted, and the one in game cartridges is usually a
normal DIL package.)
Depending on whether a certain pin (pin 4) of the chip is grounded or at +5V,
the chip functions as either a lock or as a key. Inside the console, pin 4 of
the lockout chip is at +5V (lock), and inside the game cartridge pin 4 is at 0V
(key).
When you switch on the console, the CPU and PPU chips are held in a reset
state. The two lockout chips talk to each other. Since they are identical, they
should be saying exactly the same thing at exactly the same time. Each chip
compares its output with that of its counterpart. If they match, the lock chip
releases the reset state of the console, and the game can start. The two chips
still talk to each other, and if their outputs ever differ, the lock chip
causes the console to reset, and the key chip (inside the game cartridge) may
use the chip select lines of the cartridge ROM chips to disable the ROMs.
The lockout chip is in fact a 4-bit microprocessor with its own internal ROM
and RAM. The program it runs was called "10NES" for the NES version of the
chip.
How the Modification Works
--------------------------
This depends on changing the lock device to think that it's actually a key. If
both devices are configured to be the same type (i.e., both keys), to quote
Nintendo's patent "an unstable state takes place and no operations are
performed at all." This means that the two chips will do nothing. So the
console will not be reset, and the key device will not disable the cartridge
ROM chips.
To carry out the modification you need to disconnect pin 4 of the lockout chip,
and connect this pin to ground (0V) instead. (In fact, it seems that you only
need to disconnect the pin.)
Whilst coming up with this method, I considered two other possible ways of
achieving the result. I have not tried either of these, and I would be
interested to hear if they work. If you feel like doing one of these, contact
me for pinout information. The first involves connecting the lockout chip's
input to its own output. Thus it may always think that its counterpart chip is
present. The second involves simply disconnecting the chip's clock input.
Performing the Modification
---------------------------
Whilst the modification is very simple, if you have not used a soldering iron
before I suggest that you ask someone who has some experience with soldering
and electronics in general to help you. Maybe your local TV repair person will
be willing to do it for you, if you provide a copy of this document and a
screwdriver for opening the Super NES case.
Game consoles, in common with most modern electronic devices are VERY SENSITIVE
TO STATIC ELECTRICITY. Ideally, wear a grounding strap and work on a conductive
surface when modifying your console. Avoid wearing clothes containing man-made
fibres, which are prone to static (e.g. nylon). As far as possible, avoid
touching component leads or PCB tracks. Handle the board by its edges.
Print out and read this document several times before opening your console.
You will need the following:
· A screwdriver suitable for opening the Super NES case. The screws are special
tamperproof screws, referred to as "System Zero" or "Line Head System". A
suitable screwdriver can be obtained from a company called MCM Electronics in
the USA (http://www.mcmelectronics.com/) or from RS Components in the UK.
· A crosshead screwdriver suitable for removing some screws inside the Super
NES (a "No. 1" bit will be suitable).
· A low power grounded soldering iron with a fine bit and some desoldering
braid.
· A thin needle or similar implement.
· A pair of sharp scissors.
When removing screws, make sure you remember which type goes in which hole!
Here are step-by-step instructions:
1. Turn off the console and remove all leads attached to it (AC adapter,
controller, A/V lead, etc.). After doing this, turn the power switch on for
a couple of seconds and then off again. This dissipates any stored charge
inside; you may see the power LED light for a moment as you do this. IT IS
*VERY IMPORTANT* THAT YOU DO THIS! YOU RISK DAMAGING YOUR CONSOLE IF YOU
DO NOT!
2. Turn the console upside-down, and remove the six screws from the base. Turn
it back over, and lift off the upper part of the case. Position the console
so that it is facing you.
3. Remove the eject lever. Pull up the right-hand side of the metal rod and
slide it out, then remove the lever and spring.
4. Remove the two screws which secure the power switch to the casing. Lift up
the switch so that you can get at the screw below.
5. Gently remove the ribbon cable which leads to the controller socket PCB
from the connector at the front of the PCB.
You do not need to do this if you have a late revision console. You can
identify this by the fact that there are only two screws holding down the
shielding, and you can see that the ribbon cable does not interfere with
removal of the shielding.
6. Now unscrew the metal shielding from in front of the cartridge slot. The
exact details of this step depend on which revision PCB your console has. I
will give specifics for the three variants that are known to me.
· For early consoles, which can be identified by the separate plug-in sound
module "SHVC-SOUND", there are six screws to remove from the shielding,
including the two which are on either side of the cartridge slot. (After
removing the shielding, you may see "SHVC-CPU-01" printed on the PCB if
you have a U.S. or Japanese console.)
· For later consoles, which have no separate sound module, there are four
screws to remove. (You may see "SNSP-CPU-02" printed on the PCB after
removing the shielding for a PAL console.)
· For still later consoles, there are two screws to remove. For this type
of console, there is no need to remove the controller ribbon cable. (You
may see "SNS-CPU-GPM-01" printed on the PCB after removing the shielding
for a U.S. model console.)
7. Carefully lift up the metal shielding. The edges may be quite sharp. You
will see various chips. There is more than one type of SNES PCB. Earlier
models can be distinguished because the sound hardware is contained in a
separate plug-in module labelled "SHVC-SOUND" (towards the rear right of
the console). Later revisions integrated this onto the main PCB.
The position of the lockout chip depends on which kind of PCB your console
has. For a U.S. model console with separate sound module, PCB revision
"SHVC-CPU-01", the lockout chip is labelled U8 on the PCB, and says:
F411
© 1990
Nintendo
It is located just behind the reset switch.
For a later revision PAL console with integrated sound, PCB revision
"SNSP-CPU-02", the lockout chip is labelled U8 on the PCB, and says:
F413A
© 1992
Nintendo
It is located towards the front left of the PCB, near the power switch.
For a still later revision U.S. console, PCB revision "SNS-CPU-GPM-01", the
lockout chip is labelled U8 on the PCB, and says:
F411A
© 1990
Nintendo
It is located behind and to the left of the reset switch.
8. Locate pin 4 of the lockout chip. The pins at each corner are numbered on
the PCB. Just count along from pin 1 to find pin 4.
9. Use the desoldering braid and soldering iron to remove some of the solder
from pin 4. It may help to cut the end of the braid into a "V" shape, so
that you don't inadvertently desolder any adjacent pins. Position the end
of the braid over where pin 4 meets the PCB, and briefly press down on this
with the soldering iron bit. You should see that some solder has been
"sucked into" the braid.
Using the needle, apply a gentle levering action to the pin as you
momentarily touch the soldering iron to it. The pin should come away from
the PCB. Carefully pull it up using the tip of the needle as a lever, so
that the end is a couple of millimetres away from the PCB.
10. That's it! You can optionally solder a short length of wire between pin 4
and 0V. Pin 9 of the lockout chip is at 0V, so you could connect these two
pins. Alternatively, you may wish to add a switch; see the "Possible
Incompatibilities" section below.
11. It is a good idea to test the console before putting it back together. Rest
the power switch on its mounting and connect the AC adapter, controller,
video lead and a game pak. Switch the console on. If all has gone well, the
display should appear as usual. Turn the console off, and insert a foreign
game pak (i.e., a U.S. or Japanese game pak if you have a PAL console; PAL
game pak if you have a U.S. or Japanese console). Turn the console off and
remove all attachments (AC adapter, etc.). Turn the power switch on and
then off.
12. Put the console back together. The procedure is the reverse of steps 2 to 7
above. You may find fitting the eject lever tricky. If so, put the metal
rod through the lever, and put the spring on the left end of this, so that
the outwards-pointing end of the spring is downwards. The outwards-pointing
end should be the longer of the two. Ease the spring and lever into
position, ensuring that the end of the spring goes into the recess in the
casing. Now carefully move the other end of the spring back until it is in
the recess in the lever.
Possible Incompatibilities
--------------------------
A few very recent titles may be incompatible with this modification. One
example is PAL "Street Fighter Alpha 2", used with a PAL SNES whose lockout
chip has been disabled. The graphics were reported to be corrupted in some way.
There is also reported to be more than one version of "Super Mario RPG", one of
which may be incompatible.
I know why this is. One explanation might be that Nintendo changed the lockout-
related circuitry inside the cartridges, to detect the "deadlock" situation
caused by disabling the console's lockout chip, and interfere with normal use
of the game in this case.
To solve this problem, and allow at least all domestic titles to be played, you
can fit a DPST switch to pin 4 of the lockout chip. Connect the middle switch
terminal to pin 4, and the other two terminals to +5V and ground respectively.
Then, with the switch in one position the lockout chip will be disabled, and in
the other it will operate as normal. Contact me if you are unsure of how to do
this.
At Your Own Risk!
-----------------
There are some interesting things which can be done now that the lockout chip
is disabled. If you try the following, it is at your own risk. Be aware that
removing a game pak while the console is on may damage your console or your
game pak.
If your SNES has an "eject prevention lever", you will have to try this before
fitting the case back on. (To see whether your console has one, open the game
pak shutter, and move the power switch. If you see a piece of plastic move out
when the switch is in the "on" position, that is the eject prevention lever.
Nintendo removed this from later U.S. models of the SNES, at least.)
Plug in a game pak; "Street Fighter II" is a suitable one. Turn on the console,
and wait until some music starts playing. Now carefully remove the game pak,
without turning off the console first. You should find that the display blanks,
but the music keeps playing until the end of the tune! This is because the
sound processor has its own RAM, and the music code is loaded into this. So
music continues to play even after removing the game pak.
---

302
files/docs/snes/SWC.TXT Normal file
View File

@ -0,0 +1,302 @@
E.V.O.L.U.T.I.O.N. A.U.S.T.R.A.L.I.A.
o o o
/\ /\ /\ ___o ___o
o_____________/ \_ _______o / \ / \_________| |____________o | |
\ __ / / |\ \ / ./ __\ \ _ \ |\ \ \ | .|
\ \__/_/___/ ./ |/\ /\ .\/ o/ | .\ \___\) .) .|/\ /\ \ \ \| o|
/\_______// o/ / / / o/ O/___| o|\ \ / o/ o/ / / o/ .\ \ O|
/ /_/ O/ O/| ( (_/ O/ /_) ) O|_) )/ O/| ( (_/ O/ o|\ |
\ ____/_________\ \___/_________/________// / |___\_______/| O| \___|
_\ \______________\ \_____________________/ / | |______
_________________________________________________/ Poise/RaZoR PC |__________
Presents : The Super Wild Card & Super Magicom Programmers Handbook.
Typed by : MicroChip/Evolution/Submission
Call the Evolution WHQ on : Southern Cross BBS (SNES/MD/PC/AMIGA)
--> +61-3-428-9359 (2 Nodes Ringdown)
***************************************************************************
HardWare Specifcations & Features
---------------------------------
1) DRAM - 28Mega Bits Maximum Available
2) SRAM - 256k (Battery Backup)
3) ROM - 128k (Firmware)
4) Floppy Drive Interface -
* Motorola MCS3201 Chip (NEC 765A Compatible)
* Compatible with IBM PC/AT & XT Disk Drive System
* Suports 3.5" & 5.25" Flopy Disk Drive.
* DB-25 Female Connector (non-standard)
* Supports only Non-DMA mode (polling)
5) Parallel Port Interface -
* 8 bits input, 4 bits output, 1 bit handshake.
* DB-25 Female Connector
* Use Male to Male DB-25 Connector to connect to PC's Parallel Port
6) Core Chip -
* Altera EP1810 Chip (First Generation)
* Front Far East FC9203 Chip (Currently Shipping)
* Front Far East FC9304 Chip (Not Avilable)
7) Versions -
Ver. Bios-Name Core Mode21 Saver Description
'A' Magicom EP1810 No Yes External Drive
'B' Wild Card EP1810 Yes Yes External or Bulid-in DD
'C' Wild Card FC9203 Yes Yes External or Bulid-in DD
'D' Wild Card FC9304 Yes Yes (Under Development)
'E' Wild Card EP1810 Yes No Magic Drive Adapter
'F' Wild Card FC9203 Yes No Magic Drive Adapter
SoftWare Specifications & Features
----------------------------------
1) Registers -
[Floppy Drive I/O]
C000R : Input Register
Bit 7 - MCS3201 IRQ Signal
Bit 6 - Drive 'Index' Signal (Disk Insert Check)
C002W : Digital Output Register
C004R : Main Status Register
C005RW: Data Register
C007R : Digital Input Register
C007W : Disk Control Register
* Consult the MCS3201 Data Sheet for more detailed information.
[Parallel I/O]
C008R : Bit 07 : Parallel Data Input (reading this register will
reverse the busy flag)
C008W : Bit 03 : Parallel Data Output
Bit 00 : 0=Mode 20, 1=Mode 21 (DRAM Mapping)
Bit 01 : 0=Mode 1, 1=Mode 2 (SRAM Mapping)
C009R : Busy Flag, Bit 7 (EP1810 Version)
C000R : Busy Flag, Bit 5 (FC9203 Version)
[Page Select]
E000W : Memory Page 0
E001W : Memory Page 1
E002W : Memory Page 2
E003W : Memory Page 3
[Mode Select]
E004W : System Mode 0 (Bios Mode, Power On Default)
E004W : System Mode 0 (Play Cartridge)
E004W : System Mode 0 (Cartridge Emulation 1)
E004W : System Mode 0 (Cartridge Emulation 2)
[Others]
E008W : 44256 Dram Type (For 2,4,6,8 Mega Dram Card.
E009W : 441000 Dram Type (For 8,16,24,32 Mega Dram Card)
E00CW : Enable cartridge page mapping at A000FFF (Sys Mode 0)
Disable cartridge page mapping at bank 205F,A0 (Sys Mode 2,3)
E00DW : Enable SRAM page mapping at A000FFF (Sys Mode 0)
Enable cartridge mapping at Bank 205F,A0 (Sys Mode 2,3)
* The bank address of the above registers is 007D,80.
* The above registers are available only in System Mode 0 (BIOS Mode)
* [Mode Select] registers also available in System Mode 2.
2) Memory Mapping -
[System Mode 0]
bb2000B3FFFRW : SRAM or Cartridge page mapping, bb=407D,C0
bb8000B9FFFRW : DRAM page mapping, bb=007D,80
bbA000bBFFFRW : SRAM or Cartridge page mapping, bb=007D,90
bbC000W : I/O Registers, bb=007D,80 (Registers)
bbE000bFFFFR : ROM Page mapping, bb=01 (Firmware)
* 1 Page = 8k Bytes, 1 Bank = 4 pages
* bb:000F = 4 Mega Bytes
* bb:001F = 8 Mega Bytes
* bb:002F = 12 Mega Bytes
* bb:003F = 16 Mega Bytes
[System Mode 1]
bb0000b7FFFR : Cartridge Mapping, bb=407D,C0 (Mode 21)
bb8000bFFFFR : Cartridge Mapping, bb=007d,80 (Mode 20,21)
[System Mode 2]
bb0000b7FFFR : DRAM Mapping, bb=407D,C00 (Mode 21)
bb8000BFFFFR : DRAM Mapping, bb=0070,800 (Mode 20,21)
70800070FFFFRW : SRAM Mode 1 Mapping
306000307FFFRW : SRAM Mode 2 Mapping, Page 0
316000317FFFRW : SRAM Mode 2 Mapping, Page 1
326000327FFFRW : SRAM Mode 2 Mapping, Page 2
336000337FFFRW : SRAM Mode 2 Mapping, Page 3
* bbE004bE007W : Mode Select Registers, bb=007D,80
[System Mode 3]
bb0000b7FFFR : DRAM Mapping, bb=406F,C0 (Mode 21)
bb8000BFFFFR : DRAM Mapping, bb=006F,80 (Mode 20,21)
70800070FFFFRW : SRAM Mode 1 Mapping
306000307FFFRW : SRAM Mode 2 Mapping, Page 0
316000317FFFRW : SRAM Mode 2 Mapping, Page 1
326000327FFFRW : SRAM Mode 2 Mapping, Page 2
336000337FFFRW : SRAM Mode 2 Mapping, Page 3
* Mode 21 - Even DRAM is mapped to bb0000b7FFF
Odd DRAM is mapped to bb8000bFFFF
3) Parallel I/O Protocol -
[Protocol used in PC]
* Byte Output procedure:
Wait Busy Bit = 1 Status Port Bit 7 (Hex n79,n7D)
Write One Bytes Data Latch (Hex n78,n7C)
Reverse Strobe bit Control Port Bit 0 (Hex n7a,n7E)
* Byte Input procedure:
Wait Busy Bit = 0 Status Port Bit 7 (Hex n79.n7D)
Read Low 4 bits of byte Status Port Bit 36 (Hex n79.n7D)
Reverse Strobe bit Control Port Bit 0 (Hex n7A.n7E)
Wait Bust Bit = 0 Status PortBit 7 (Hex n79.n7D)
Read High 4 Bits of byte Status Port Bit 36 (Hex n79.n7D)
Reverse Strobe Bit Control Port Bit 0 (Hex n7A.n7E)
* 5 Types of Commands
* Command length = 9 bytes
* Command Format:
Byte 1 D5 ID Code 1
Byte 2 AA ID Code 2
Byte 3 96 ID Code 3
Byte 4 00|01|04|05|06 Command Code
Byte 5 A1 Low Byte of Address
Byte 6 AH High Bytes of Address
Byte 7 LL Low Byte of Data Length
Byte 8 LH High Byte of data Length
Byte 9 CC Checksum = 81^Byte4^Byte5^Byte6^Byte7^Byte8
* Command [00] : Download Data
a1,ah = Address
11,1h = Data Length
Output Data after Command
* Command [01] : Upload Data
a1,ah = Address
11,1h = Data Length
Input Data after Command
* Command [04] : Force SFC Program to JMP
a1,ah = address
* Command [05] : Set Memory Page Number
a1 Bit 1 = Page Number
a1 Bit27 + ah Bit 1 = Bank Number
* Command [06] : SUB Function
a1 = 0 Initial Device
a1 = 1 Play Game in DRAM
a1 = 2 Play Cartridge
Password Format
---------------
1) Description -
Use the Data in the password to replace the data in the memory
at the offset address (according to the game file)
2) Format 1 -
* Game Doctor Gold Finger Format
* 20 bits address space assigment
* 3 data bytes per string
* [Gaaaaaddddddccc]
'G' = Means Game Doctor Format
aaaaa = Offser address of game file (Excluding 512 bytes header)
dddddd = 3 data Bytes (If the second ot the third data is '00',
this means that the data is uncganged in
the second of third byte)
ccc = Checksum (Not used in SWC and SMC)
3) Format 2 -
* 'FFE' Format
* 24 bit address space assigment
* 1 to 36 data bytes per string
* No Checksum
* [nnaaaaaadd....]
nn = Data bytes length
aaaaaa = Offset Address of Game file (excluding 512 bytes header)
dd.... = nn Bytes data (Should be nn*2 Characters)
File Header
-----------
1) Created by JSI/Front Far East
2) 512 Bytes Length
3) Byte
0 - Low Byte of 8k-Bytes page Counts
1 - High Byte of 8k-Bytes page Counts
2 - Emulation Mode Select
Bit 7 6 5 4 3 2 1
x : 1=Run in Mode 0 (Jump $8000)
x : 0=Last File of the Game (Multi-File)
x : 0=Mode 1, 1=Mode 2 (SRAM Mapping)
x : 0=Mode 20, 1=Mode 21 (DRAM Mapping)
x : 0=Run in Mode 3, 1=Run in Mode 2 (JMP Reset)
x : 0=Disable, 1=Enable (external cartridge
memory image at Bank 205F,A0 System Mode 2,3)
8 - File ID Code 1 (Should be 'AA')
9 - File ID Code 2 (Should be 'BB')
10 - Check this byte if ID 1 & 2 Match
02 : Magic Griffin Game File (PC Engine)
03 : Magic Griffin SRAM Data File
04 : SWC & SMC Game File (SNES)
05 : SWC & SMC Password, SRAM data, Saver Data File.
06 : SMD Game File (Megadrive)
07 : SMD SRAM Data File
37 - Reserved (Should be 00)
11511 - Reserved (Should be 00)
****************************** The End ***********************************
Personal Greetings go to:
Ice/ATX - See ya at the Rave!
Krayzi/PE - Stop pulling those pipes.
Krimsym - See ya at Insanity!
VIking Child/Submission - Use a condom next time!
Ginnie/Razor - PC's RULE - NOT!
TV & Revenger/Submission - Why an A4000?
Poise/Razor - Where's my text screen??
Itec/Submission - Lets get TCC going again?
Mixer/Mel - See ya at Kentucky!
WormEater & RAM - Call my board!
Kirk/Anthrox - How ya going Pete? Will Call ya soon!
Mat - Speed kills - NOT!
Choronzon - Let me see ya trade!
Sweet Thing - Thanx for the support!
Woody & Sandman - Call my bbs you lazy bastards.. hehe
Cameo - I want a pre-release...
Rotox - Call me..
Mr. IRQ - Dove' il mio manuale?
Jacknife - Thanx for the Support Dude!
And to all my friends I have forgotten about coz I am tired!
Group Greetings go to:
Submission, Magical, Anthrox, Paradox, Razor, Fairlight, BSL, Elitendo,
PE, Quartex, Skid Row and to all others I missed!
NOTE: If any Australian's wish to purchase a Super Wild Card they are
asked to call (03) 883-0297 (24hour paging service)............

BIN
files/docs/snes/SWC.ZIP Normal file
View File

Binary file not shown.

1216
files/docs/snes/Sneskart.txt Normal file
View File

File diff suppressed because it is too large Load Diff

48
files/docs/snes/Snesmath.txt Normal file
View File

@ -0,0 +1,48 @@
From: vic@physci.psu.edu (Vic Ricker)
To: "Super Famicom Development Group" <famidev@busop.cit.wayne.edu>
Subject: Re: Multiplying/Dividing?
Date: Sun, 26 Dec 93 16:29:09 EST
Take a look at this:
Address: $4202/$4203
Name: WRMPYA/WRMPYB
Description: Multiplier and multiplicand
D7 D6 D5 D4 D3 D2 D1 D0
| MULTIPLICAND-A | $4202
|_______________________________________|
D7 D6 D5 D4 D3 D2 D1 D0
| MULTIPLIER-B | $4203
|_______________________________________|
These registers perform absolute multiplication by multiplying
multiplicand A by multiplier B and return product C which can be read
from $4216/$4217 RDMPY.
Set register A, then B. After the B register is set, it will take 8
machine cycles for the multiplication to be completed.
* The A register will not be destroyed by the multiplication process.
^^^ does not refer to the accumulator. it means the multiplicand
Also, there is 8/16 multiply that shares the mode 7 matrix registers:
set 16 bit multiplier to $211b and 8 bit multiplicand to $211c the 24
bit product will be placed in $2134-$2136.
The shift-add routine is a great way to multiply. I'm suprised that
so many so-called assembly programmers don't know how to do it.
Regardless of how fast it is, the hardware stuff blows it away.
There is also a hardware divide:
$4204/4205 is the 16 bit dividend, $4206 is the 8bit divisor, the
quotient will be put in $4214, and the remainder in $4216/4217.
ANy questions, lemme know.

343
files/docs/snes/Snesrom.txt Normal file
View File

@ -0,0 +1,343 @@
______ _____ _____ _______ ___ ___
/ __/ /. _ \ ___/ __/ |____ \___ /. \/ \
\___ .\// |. \ / . \__ .\ |. _/ \// .\
/. \\ |: .\ __/ \\ || | .\ ! \ \/. \
\______ /___|____/____\____ / |__| \\___/____||: \
By Mind Rape \___/ |______/
v1.5 (C) Damaged Cybernetics 1994-95
This document main goal is show where one can find the SNES ROM
information. Most of this information was collected thru hacking
the rom to death and help from Norm/Yoshi/chp.
License codes are taken from SU and probably incorrect.
Source? None here, if you are going to screw with the bin,
you probably know what you are doing (HOPEFULLY).
If you have any questions, comments,corrections, additional information,
you can either find me on IRC as (MindRape) or you can send me email
(much prefered) mind@primenet.com. Also if you write anything
interesting then send it to me!
You may distribute this document freely, but you may not change
the information here and redistribute. If you use this information
please credit me. You steal this information and say you did it,
you know it's a LIE and there you are.
=[SNES ROM Makeup]===========================================================
ROM Title : 21 Bytes
* Titles are all in upper case
* Japanese titles are in high ascii values
good rule of thumb if you can't read the title and
it's country code is Japan and your American,
you probably can't play it. :>
Rom Makeup : 7654 3210
0000-0000
|__| |__|
| |
| |___Bank Size 0001 = HiROM (64K Banks Mode 21)
| 0000 = Low Rom (32K Banks Mode 20)
|
|________ROM Speed 0111 = Fast Rom
0000 = Slow Rom
* Could someone give the correct
* speeds of the ROMs? I got
* conflicting answers.
ROM Type : 1 Byte
Hex ROM Type
---------------------
00 ROM
01 ROM/RAM
02 ROM/SRAM
03 ROM/DSP1
04 ROM/DSP1/RAM
05 ROM/DSP1/SRAM
06 FX
* SRAM = Save Ram
* DSP1 = Nintendo's 1st generation of DSP (Math coprocessor)
* FX = RISC based math coprocessor
Only a couple of games support the FX Chip, Star Fox
is the most well known one.
ROM Size : 1 BYTE
Hex Size
--------------
08 2 Mbit
09 4 Mbit
0A 8 Mbit
0B 16 Mbit
0C 32 Mbit
* As of this documentation 32MBit ROMs are the largest that
Nintendo currently uses. Rumors of a 40+ kart are around,
but cannot be verified.
* 8MBit ROMs are the most common in the entire library of
SNES karts
* ROMs are always multiples 2, thus 2MBit ROMs are the smallest
Space Invaders (c) Taito is a 2MBit ROM (Japan only)
* Easy way to calc rom size without a lookup table
1 << (ROM_SIZE - 7) MBits
ie. 8Mbit ROMs = 0Ah = 10d
1 << (0A-7) = 8 Mbit
SRAM Size : 1 BYTE
Hex Size
--------------
00 No SRAM
01 16 Kbit
02 32 Kbit
03 64 Kbit
* 64Kbit is the largest SRAM size that Nintendo currently uses.
* 256Kbit is standard for most copiers.
* Easy way to calc SRAM Size without a lookup table
1 << (3+SRAM_BYTE) Kbits
ie. 16Kbit = 01
1 << (3+1) = 16
COUNTRY CODE : 1 BYTE
Hex Country Video Mode
------------------------------------------
00 Japan (NTSC)
01 USA (NTSC)
02 Europe, Oceania, Asia (PAL)
03 Sweden (PAL)
04 Finland (PAL)
05 Denmark (PAL)
06 France (PAL)
07 Holland (PAL)
08 Spain (PAL)
09 Germany, Austria, Switz (PAL)
10 Italy (PAL)
11 Hong Kong, China (PAL)
12 Indonesia (PAL)
13 Korea (PAL)
* Country Codes are from SU.INI, could someone verify these?
LICENSE : 1 BYTE
0 <Invalid License Code>
1 Nintendo
5 Zamuse
8 Capcom
9 HOT B
10 Jaleco
11 STORM (Sales Curve) (1)
15 Mebio Software
18 Gremlin Graphics
21 COBRA Team
22 Human/Field
24 Hudson Soft
26 Yanoman
28 Tecmo (1)
30 Forum
31 Park Place Productions / VIRGIN
33 Tokai Engeneering (SUNSOFT?)
34 POW
35 Loriciel / Micro World
38 Enix
40 Kemco (1)
41 Seta Co.,Ltd.
45 Visit Co.,Ltd.
53 HECT
61 Loriciel
64 Seika Corp.
65 UBI Soft
71 Spectrum Holobyte
73 Irem
75 Raya Systems/Sculptured Software
76 Renovation Pruducts
77 Malibu Games (T*HQ Inc.) / Black Pearl
79 U.S. Gold
80 Absolute Entertainment
81 Acclaim
82 Activision
83 American Sammy
84 GameTek
85 Hi Tech
86 LJN Toys
90 Mindscape
93 Technos Japan Corp. (Tradewest)
95 American Softworks Corp.
96 Titus
97 Virgin Games
98 Maxis
103 Ocean
105 Electronic Arts
107 Laser Beam
110 Elite
111 Electro Brain
112 Infogrames
113 Interplay
114 LucasArts
115 Sculptured Soft
117 STORM (Sales Curve) (2)
120 THQ Software
121 Accolade Inc.
122 Triffix Entertainment
124 Microprose
127 Kemco (2)
130 Namcot/Namco Ltd. (1)
132 Koei/Koei! (second license?)
134 Tokuma Shoten Intermedia
136 DATAM-Polystar
139 Bullet-Proof Software
140 Vic Tokai
143 I'Max
145 CHUN Soft
146 Video System Co., Ltd.
147 BEC
151 Kaneco
153 Pack in Video
154 Nichibutsu
155 TECMO (2)
156 Imagineer Co.
160 Wolf Team
164 Konami
165 K.Amusement
167 Takara
169 Technos Jap. ????
170 JVC
172 Toei Animation
173 Toho
175 Namcot/Namco Ltd. (2)
177 ASCII Co. Activison
178 BanDai America
180 Enix
182 Halken
186 Culture Brain
187 Sunsoft
188 Toshiba EMI/System Vision
189 Sony (Japan) / Imagesoft
191 Sammy
192 Taito
194 Kemco (3) ????
195 Square
196 NHK
197 Data East
198 Tonkin House
200 KOEI
202 Konami USA
205 Meldac/KAZe
206 PONY CANYON
207 Sotsu Agency
209 Sofel
210 Quest Corp.
211 Sigma
214 Naxat
216 Capcom Co., Ltd. (2)
217 Banpresto
219 Hiro
221 NCS
222 Human Entertainment
223 Ringler Studios
224 K.K. DCE / Jaleco
226 Sotsu Agency
228 T&ESoft
229 EPOCH Co.,Ltd.
231 Athena
232 Asmik
233 Natsume
234 King/A Wave
235 Atlus
236 Sony Music
238 Psygnosis / igs
243 Beam Software
244 Tec Magik
255 Hudson Soft
* License Codes are from SU.INI, could someone verify these?
* I believe the # of licenses is low. Is it possible that
License and Country codes are used in conjuction to produce
that many more licenses?
VERSION - 1 byte
* The Version is interpeted this way.
1.?? - (thanks to yoshi for the correction)
CHECKSUM COMPLEMENT - 2 bytes the complement of the checksum :>
The bits are reversed of the CHECKSUM
CHECKSUM - 2 bytes Checksum of the bin
* Anyone know how the checksum is calculated for the ROM?
NMI/VBL Vector - 2 bytes - OFFSET 81FAh (lowrom)
OFFSET 101FAh (hirom)
RESET Vector - 2 bytes where to start our code at - OFFSET 81FCh (lowrom)
- OFFSET 101FAh (hirom)
* 8000h is common for Low Roms
=[READING THE CORRECT BIN INFORMATION]==================================
The bin information can be found in 2 possible places,
a) End of the 1st 32K bank (Low ROM) (81c0h/w 512 byte header)
b) End of the 1st 64K bank (HiROM) (101c0h/w 512 byte header)
You could use UCON's method (author chp).
The method is as followed:
UCON's method is to OR the Checksum and the Complement. If the
resulting value is FFFFh, then we found the correct location of
to extract rest of the data out. HOWEVER! This fails on several
karts, such as Castle Wolfenstien 3D and Super Tetris 3 for example.
Reason being is that not all developers put the correct complement
or bother even to implement it. I would suspect! That this maybe
a ploy to keep other developers out of the bin, for if they can't
find the reset vector, disassembling becomes a bit difficult.
=[Other Information on SNES?]================================================
Famicom Development FTP Site
busop.cit.wayne.edu - pub/famidev
Yoshi's SNES Documentation 2.3
This is considered the BEST source of SNES hardware information,
and the most complete!
busop.cit.wayne.edu - pub/famidev/incoming/sndoc230.lzh
=[w0rd!]=====================================================================
w0rd to all following console dudes
GoosE_,yoshi,sir jinx,chp,SHORYUKEN,_bubsy,felon,archimede
rugalz,SinZ,dragonz,procyon,royce,hoodlem,bri_acid,kamikitty,
norm,ZillionZ Members,grayarea,Victor,drunkfux(h0h0h0h0),dmessiah,
piratendo
<insert your favorite group(s) greet here> (heh)
Later Mind Rape

34
files/docs/snes/Swchead.txt Normal file
View File

@ -0,0 +1,34 @@
This file was given to me by one of my friends from #emu, I can't remember who
it was. I believe it was taken from the person's SWC game manual, so it should
be accurate.
-avatar_Z - http://mana.nfinity.com/node99
------------------------------------------------------------------------------
byte 0 - numbers of block (low byte)
byte 1 - numbers of block (high byte)
total numbers of block = (byte1 * 256) + byte0
byte 2 - program execution mode
bit: 76543210
X : 0, reserved
X : 0=no more split file, the last fule
1=search for next split file
X : SRAM memory mapping,
0=mode20, 1=mode21
X : program memory mapping,
0=mode20, 1=mode21
XX : SRAM mode (size),
00=256K, 01=64K, 10=16K, 11=off
XX : 00, reserved
byte 3~7 - 00, reserved
byte 8 - aa, file id
byte 9 - bb, file id
byte 10 - file type
04: program
05: battery back-up data
08: real-time save data
byte 11~511 - 00, reserved

BIN
files/docs/snes/U12675EJ7V0DS00.pdf Normal file
View File

Binary file not shown.

BIN
files/docs/snes/board_cpld_01.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 132 KiB

BIN
files/docs/snes/book1.pdf Normal file
View File

Binary file not shown.

BIN
files/docs/snes/book2.pdf Normal file
View File

Binary file not shown.

227
files/docs/snes/csr-code.txt Normal file
View File

@ -0,0 +1,227 @@
_________________________________________________________________________
\_____________________ _______________________________________________/
_________ ___|! | ________
/ __ | / /: || __ \ -%*] THE HOLE / LSD USHQ! [*%-
o _(___( |! |/ /|o || |_)___)
/\ |: / __ ||! ______/ SYSOPS: OLDMAN, ETRON, HIGHLANDER
o o |o ( ( | ||: |_) ) D-MAN, ZANDOR
__________ | \___\ |___||o _____/_______________________ __
\________ \|___|__________|___|____/ ______________________> (__)
________\________ ____________/__________ _ _
\ __ !| | | /__/\__\ | | \ __ __ \ __ _)\ (_)
\ \| :|_| |/ \ OO / \| !|____\ \|! |_)___) \ \/ o\ O
\/| ___ / /_\/_\ \ :|\ \\/|: ______/ ) /|\__). o
/ | |! ( \/ ) o|_) )/ o |_) ) /_/\___/
/_____| |: \__________/________//__ _____/
__________|o |______________________| |____
/______________________________________________\
Node1 Node2 Node3
PRIVATE 419-899-2754 419-899-2765
RINGDOWN
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
This file was leeched from:
..THE..
_______/\_______ /\____ /\_________/\ _____/\/\_______/\______
/ \____ \ / \ \ / \ ______/\/ / \____ \____ \
// __|___ / | \/ \ \/ / ___/___ __/ \/ | \ | \
/ \__ \/ __/ \ / | | / |/ \ __/ | \\
\ | / \ \__ /\ \__ / | | / __/ /\ \ \ \|_ | /
\________\____|\ /__/\ / /\________| \__\ /\____/_|\ /______/
\ / \ /\/-rAt \ / \ /
<---- --- - ---- -\/--- ---\/---- ---- ------ -- \/-- - - --- -\/---- ---->
Q.U.A.R.T.E.X MEGA HQ (AMIGA+CONSOLE) & H.Y.B.R.I.D (IBM)
Uploaded at: 02:36:04 on: 23-Apr-93 By: RAMRAIDER
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
; Welcome to the first installment of "How to code SNES"
; This first volume will show you how to make a simple text intro. It uses
;mode 0 graphics with no DMAs (Horizontal or General) and is the simplest
;type of intro you can make. We're starting small so you can easily understand
;what to do. Other future volumes will contain other graphic modes,
;Horizontal DMA (HDMA, the SNES version of an amiga copperlist), General DMA,
;Interrupts, and a brief section on Sound. Originally we were going to release
;the full Super Famicom Programmer's Manual but believe it or not, this manual
;a pile of garbage. Contrary to the popular belief that we always had the
;manual, this is NOT true. The White Knight happened to meet a very cool
;guy at the CEBIT in Germany and has gotten the manual 2 weeks ago!
;Yes! What you have seen from us before was true coding. We started out
;by hacking and working our way to the top. We didn't wait until we bought
;a manual. In fact, the manual was sent to us for FREE! This book isn't
;worth paying for!
If White Knight had contacted us anytime in the last 6 months he could of had
a manual - instead he took the huff at Quattro's attitude.
;Let's clear up a few misunderstandings about that SNES manual!
;
;1) This book does NOT teach you assembly language!!
; It would help if you knew a little before trying to code this machine!
;
;2) This book was not written such as other reference guides you can find in
; a store, like Mapping the Amiga, or even Mapping the C64.
; It tells you barely and confusingly what the registers do. Period.
;
;3) This book is about 148 pages long and that includes the Sound Section.
; Some have said it was the size of a phone book. Unless live in
; Mud Hole, Kentucky this is NOT the case!
I dont know what fuckin manual you have got but mine is 300 pages and
includes a full section on the assembler as well.
The manual is a good reference manual, the english is a bit confusing but
it works well. It is not an idiots guide to the SNES, but it aint intended
as this - only veteran coders are supposed to have it.
;You cannot do this! $c000 is ROM and you can not write to ROM!
;To write to ram, simply write to any address between $0000-$1fff.
;If you need more memory you will find plenty at bank $7e and $7f
;These 2 banks contain memory from $0000-$ffff. These 2 banks each contain
;64k ofram totalling 128k for your own use!
;If you need to write to these directly, just use the LONG STA command
;example:
;sta $7ec000
;
;This will write to bank $7e at address $c000!
dont forget there is only 120k at the top of memory the other 8k is mapped
through the whole memory map at 0-$1fff.
;You will notice when looking at the source code something very strange.
;Some registers are written to twice in a row! This because some registers
;need more than one 8 bit info, such as the scroll X registers. In these
;registers you can enter any number between $0-$07ff, but they are written
;as two 8 bit numbers, one right after another.
;example:
;
;lda #$07
;sta $210d
;lda #$00
;sta $210d
;
;This writes #$0007 to $210d, plane 0 scroll x register.
why not use the efficient method
lda #$7
sta $210d
stz $210d
;The Super NES system has it own graphics processor. This requires its own
;ram to read/write graphics data. This ram can only be accessed through
;certain registers such as $2118 + $2119. To access Video Ram you MUST
;turn off the video or you must be in screen blank (horizontal or vertical).
;This is one of the downsides of the SNES.
;Video Ram allows the storage of map planes and tile graphics.
;VRAM is only 64k long and can not be used as regular ram. You can not
;program in it, it is a separate unit!
you can store wotevere ya want in vram, programs if ya want!!!!
you can put data in at anytime u like not just the blank times - less time
available outside of the blanks though..
apart from these little quotes of critism, not bad, a good idea would
be nice to see some intros that aren't lame - I thought they would
improve but the last few have been so shite it aint tru, i'm sure as we
ripped music 12 months ago, other peeps would be able to do it by now
and put it in intros.
I find it funny that PAN-HANDLE goes on about going the Klan and killing
a Nigger, I thought White Knight was slightly tainted in that direction,
so when ya gonna kill him then??? Leave the nogs for now and get those
bone-idle curry peddlers.................
hehehe rant rant rant - MAKE A EFFORT ON THE SNES DONT JUST PUT A PISS
SIMPLE INTRO OUT - PUSH THE FUCKIN MACHINE>>>>>>>>>>>>>>>>>>>>>
Corsair..........
Additional note about the source code :
A "veteran coder" would take one look at it and tell you it is inefficent.
RamRaider at the keys now :
If you really want to code on the SNES and need help from professionals :
Call The GRaVEYARD BBS QUARTEX MEGA-HQ +44-YOU-KNOW-IT, which has just
started running a developers conference to help promote professional coding.
Peeps In Charge : Corsair & Dax
Peep who pesters and Leaves stupid msgs about cheese : RamRaider!
Two Points :
1. SNASM for the 68k and 65816 (SNES) cracked will be available for
download from the above BBS in the developers conference.
It will be uploaded there and no where else. Unless someone spreads
it for the glory.
2. We also have the latest SNES manual with F/X, DSP1, DSP2 etc notes.
It is less than a week old.
PS. If ya take offence from this Text then fuck off.
Spelling Mistkes are Copyright.
PPS. We do not give a shit wot ya think, and if ya take it the wrong way
Then fuck you!
Quick greet from RamRaider to Beast/QTX, fuking southern wanker!! hahaha
And also to Dax who seems to be working FAR too HARD.
BBS Ads to follow this wonderfully Piece of text :
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
This file was leeched from:
..THE..
_______/\_______ /\____ /\_________/\ _____/\/\_______/\______
/ \____ \ / \ \ / \ ______/\/ / \____ \____ \
// __|___ / | \/ \ \/ / ___/___ __/ \/ | \ | \
/ \__ \/ __/ \ / | | / |/ \ __/ | \\
\ | / \ \__ /\ \__ / | | / __/ /\ \ \ \|_ | /
\________\____|\ /__/\ / /\________| \__\ /\____/_|\ /______/
\ / \ /\/-rAt \ / \ /
<---- --- - ---- -\/--- ---\/---- ---- ------ -- \/-- - - --- -\/---- ---->
Q.U.A.R.T.E.X MEGA HQ (AMIGA+CONSOLE) & H.Y.B.R.I.D (IBM)
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
[A¡RaDDer v3.1 By A¡Rcø]
------------------------------------------------------------------------------
CaLL THe øNe aND øNLY PLeaSuRE DøME
------------------------------------------------------------------------------
| ____ _ _____ _____ _____ ___|\ _____ _____ |
___|_/ _¬\_/¬| _/ __\_/ _ ¬\_/ ____\_/ | \_/ _¬\_/ __\_|__ _
ø: | | | | |_\| | | |___\| | | | _| |_\_:ø__
: | | | _| __/ | _ |\__ | | | _ \_ __/ _|__ _
: | | |__/¬| ¬|_/| | |\_| | | | | | ¬|_/ :ø
: | | | | | | | | | | | | | | | :
: | | | | | | | | | | | | | | | :
: | | | | | | | | | | | | | | | :
: ¬ _| | | | | | | | | | | | | | :
: __/ | | | | | | | | | | | | | | :
: ¬| | | | | | | | | | | | | | | :
_ø_:_ | | ¬ | ¬ | | | ¬ | ¬ | | | ¬ _:_ø_
| \__| ¯\_____/¯\_____/¯\ |___/¯\_____/¯\_____/¯\___| /¯\_____/ |
| \| |/ |-rS!
°° DD ° OO ° MM ° EE °°
NøDE 1(DHST):+43-XXXX-XXXX NøDE 2(HST):+43-XXXX-XXXX
DiaMøNDS & RuST euRøPeaN HQ
----------------------------------------
aMiGa / SNeS / GeNeSiS / iBM
SYSøPS: [-STE\/E/D&R-],BøøN KiD/D&R,eTRøN&JøKer,eDø,CeViN KeY

160
files/docs/snes/dma.txt Normal file
View File

@ -0,0 +1,160 @@
From: LAY@uk.tele.nokia.fi
To: "Super Famicom Development Group" <famidev@busop.cit.wayne.edu>
Subject: RE: Assorted questions...
>> 2) I asked a question before about HDMA, and I got replies saying that
>> it has something to do with the horizontal interrupt or horizontal
>> blank time (I forget which). Later on I saw people talking about
>> HDMA "channels". Could someone please tell me what the "channels"
>> are used for, or are they another name for a register or a memory
>> storage location?
It's probably best to start by explaning "normal" DMA. The SNES
supports 8 DMA channels which allow data to be copied to VRAM
extremely quickly, bypassing the 65c816 processor. Each channel
consists of the following registers.
Byte $43?0 DMA channel ? control register
Byte $43?1 DMA channel ? destination
Word $43?2 DMA channel ? source address offset
Byte $43?4 DMA channel ? source address bank
Word $43?5 DMA channel ? transfer bytes
where ? is 0..7
A value of $01 written to the DMA channel control register at
$43?0 indicates that we're using "normal" DMA. The graphics
register destination is formed by using $21 as the high byte
of the address and using the byte specified at $43?1 as the
low byte. Hence you can DMA to any of the graphics registers
between $2100..$21FF.
There is also a DMA control register.
Byte $420B DMA control register
Here bit 0 enables channel 0, bit 1 enables channel 1 etc...
For example, suppose I wanted to copy a 32 x 32 character
screen map (ie. $800 bytes) from location $18000 in ROM into
location $0000 of VRAM. I could do this using DMA channel 0
with the following code (A is 8-bits, X & Y are 16-bits).
ldx.w #$0000 ; set VRAM pointer to $0000
stx $2116
lda #$01 ; control value for "normal" DMA
sta $4300
lda #$18 ; dma to $2118
sta $4301
ldx.w #$8000 ; source offset
stx $4302
lda #$01 ; source bank
sta $4304
ldx.w #$0800 ; number of bytes
stx $4305
lda #$01 ; enable DMA channel 0
sta $420B
And that's all there is to it. After completion of the last
instruction "sta $420B" the $800 bytes at $18000 will have
been copied into VRAM at location $0000.
HDMA allows you to use any combination of these DMA channels
to modify graphics registers just before the start of every
horizontal scan line.
To use HDMA you have to write a value of $00 or $02 to the
DMA channel control register at $43?0 to indicate "horizontal"
DMA. Writing $00 indicates a byte is to be DMA'd each scan
line, writing $02 indicates a word. The DMA channel destination
at $43?1 works just as before with "normal" DMA. The source
address offset and bank registers at $43?2 & $43?4 will point
to a HDMA table. The transfer bytes register at $43?5 is not
used.
The format of the HDMA table depends on the value you have
written to the DMA channel control register. If you have
written $00 then a byte will be written to the selected
graphics register each scan line. The table should have the
following format.
hdma_table
Byte n ; number of bytes that follow (7-bit value 0..127)
Byte value_1, value_2, value_3 ... value_n
Byte n ; number of bytes that follow (7-bit value 0..127)
Byte value_1, value_2, value_3 ... value_n
.
etc
.
Byte 0 ; ends list
The table is made up of a number of entries. The first byte
in each entry is a count on the number of bytes that follow.
The table is terminated by a 0 entry.
If you have written $02 to the DMA channel control register
then a word will be written to the selected graphics register
each scan line. The table should have the following format.
hdma_table
Byte n ; # times to repeat next word (7-bit value 0..127)
Word value
Byte n ; # times to repeat next word (7-bit value 0..127)
Word value
.
etc
.
Byte 0 ; ends list
The table is made up of a number of entries. The first byte of
each entry indicates the number of times the following word is
to be repeated. The table is terminated by a 0 entry.
The only other thing you'll need to know is that there is a
HDMA control register.
Byte $420C HDMA control register
This is the same format as the DMA control register at $420B,
ie. bit 0 enables HDMA channel 0, bit 1 enables channel 1 etc...
For example, suppose halfway down the screen I want to scroll
graphics plane 0 left by 128 pixels.
lda #$02 ; word format HDMA (count, word)
sta $4300
lda #$0D ; plane 0 x-scroll at $210D
sta $4301
ldx.w #hdma_table&$FFFF ; hdma table offset
stx $4302
lda #hdma_table/$10000 ; hdma table bank
sta $4304
lda #$01 ; enable HDMA channel 0
sta $420c
.
.
.
hdma_table
dc.b 112 ; for first 112 scan lines
dc.w 0 ; set plane 0 x-scroll to 0
dc.b 1 ; on next scan line
dc.w 128 ; set plane 0 x-scroll to 128
dc.b 0
You can use HDMA channels in combination, ie. you could use HDMA
channel 0 to select a colour register and HDMA channel 1 to write
the RGB data for that colour register.
I don't have access to any of the official Nintendo documentation
so I may not have entirely understood everything about HDMA but
this is a much as I've been able to work out. Maybe there are other
(H)DMA modes too?
I'll should have put a simple HDMA demo with source code on the
busop.cit.wayne.edu ftp site (in pub/famidev/incoming/hdmademo.zip).
Hope that helps.
Paul.

759
files/docs/snes/fairligh.txt Normal file
View File

@ -0,0 +1,759 @@
This fine text file came from...
/\____ __/\____ /\ _______/\__/\________
/ __ //\ \_\/___ \ /\ \// _____/ /_/ /__ _ /
___/ /__\// \ /\ __/ / / / ___/\_/ /_ / /_/ / / / \/
\_/ /__/ / /\ \/ / / __/ / / \_/ // /_ \ / /_ / / /
_/ / / / \ \/__\ \__/ /_/\ / // /_/ / \/ / / / /
\_/[SP] \/ /\_____\ \_\____/ \/ \__ / / / \/
\/ \/ _/ / \/
\_/
S.H.Q
Far Out Multi Node System
Node1 +46-46-133489 Node2 +46-46-133482 Node3 +46-46-133424
If you want to read this then download it! No free loaders here!!
··············································································
--------> a SMaSHiNG 100% SUPER NiNTENDo oNLY SYSTEM <----------
___/\____/\____ /\______ /\ /\_____/\__________ /\ /\
\____ / __ \ / __ \ / \ /\ / _ ______ \/ \/ \
/ _/ _/ _/\/\ \/ / /\ \/ // / / /\// / / /\ \ _ \ \
/ \ \_ \ \ / \/ /_\ \/ / / / / \/ / \ /
\ /\ /______\ \ /\______/\___ /\____/ \ /\ /\__________/\ /
\/ \/ \/ \/ \/ \/ \/
---------> +46-431-51557 ----- SYSoP: SY-KLoNE - CoSYSoP: HiTMaN <-----------
²
; Corsair presents an example of how to drive the hardware - basically I used this intro
; cos everyone knows how it looks and thus it seemed a good bit of code to do..
; the comments outside the hardware stuff are a bit sparse - i'm not teaching you how
; Fairlight write code , just their use of hardware!!
;
; questions as usual leave on GRAVEYARD, Treasure Island or Oasis..
;
Start Of Intro From Fairlight
------------------------------------------------
00E000 78 SEI ; disable irq ints
00E001 A9 8F LDA #$8F ;
00E003 8D 00 21 STA Screen_Fader ; turn screen on at full brightness
00E006 9C 00 42 STZ $4200 ;
00E009 9C 0C 42 STZ Start_DMA_Hi ; disable all 8 DMA channels
00E00C 9C 0B 42 STZ Start_DMA_Lo ;
00E00F 18 CLC ;
00E010 FB XCE ; place in native (16 bit) mode
00E011 C2 30 REP #$30 ; set x,y,a all to 16 bit
00E013 A9 00 00 LDA #$0000 ;
00E016 5B TCD ; set direct register to bank zero
00E017 64 07 STZ $07 ; clear memory loc. 7
00E019 A9 20 00 LDA #$0020 ;
00E01C 85 0B STA $0B ; set $0b.w = $0020
00E01E E2 20 SEP #$20 ; set accum. to 8 bit
00E020 A9 80 LDA #$80 ;
00E022 8D 15 21 STA Video_Port_Control ; initialise Video Port Controller
00E025 A2 00 10 LDX #$1000 ;
00E028 8E 16 21 STX Video_Port_Address ; Point Vram Pointer To $1000
00E02B A9 5B LDA #$5B ;
00E02D 85 0D STA $0D ; Copies $5bx8 bytes of char
00E02F A2 00 00 LDX #$0000 ; data into Video Ram via the port
outer_loop: ; thus giving 2
00E032 A0 08 00 LDY #$0008 ;
inner_loop: ;
00E035 BD D3 E2 LDA CHAR_SET,X ; .: Character set for intro
00E038 8D 18 21 STA Video_Port_Lo ; and FLT logo.
00E03B 9C 19 21 STZ Video_Port_Hi ;
00E03E E8 INX ;
00E03F 88 DEY ;
00E040 D0 F3 BNE inner_loop ;
00E042 C6 0D DEC $0D ;
00E044 D0 EC BNE outer_loop ;
00E046 9C 05 21 STZ $2105 ; clear Video Reg. unknown
00E049 A9 04 LDA #$04 ; set Playfield 0 To $400 and 32x32 chars
00E04B 8D 07 21 STA Playfield_0_Addr ;
00E04E A9 08 LDA #$08 ; set Playfield 1 to $800 and 32x32 chars
00E050 8D 08 21 STA Playfield_1_Addr ;
00E053 A9 11 LDA #$11 ; Set Playfield 0+1 Tile Addr To $100
00E055 8D 0B 21 STA Tile01_Vram_Addr ;
00E058 A2 07 00 LDX #$0007 ;
00E05B 9E 0D 21 STZ Plane_0_Scroll_X,X ; Clear All The Scroll Pointers
00E05E 9E 0D 21 STZ Plane_0_Scroll_X,X ;
00E061 CA DEX ;
00E062 10 F7 BPL $00E05B ;
00E064 A2 07 00 LDX #$0007 ;
00E067 9E 23 21 STZ $2123,X ; Clear Video Registers $2123-$212a
00E06A CA DEX ;
00E06B 10 FA BPL $00E067 ;
00E06D A9 03 LDA #$03 ;
00E06F 8D 2C 21 STA Playfield_Enable ; Enable playfields 0 & 1
00E072 A2 04 00 LDX #$0004 ;
00E075 9E 2D 21 STZ $212D,X ; Clear Video Registers $212d-$2130
00E078 CA DEX ;
00E079 10 FA BPL $00E075 ;
00E07B 9C 33 21 STZ Interlace_Flags ; Disable Interlace Mode
00E07E A9 04 LDA #$04 ;
00E080 9C 16 21 STZ Video_Port_Address ; Set Video Port Address to $400
00E083 8D 17 21 STA Video_Port_Address+1 ;
00E086 A9 80 LDA #$80 ;
00E088 8D 15 21 STA Video_Port_Controller ; Initialise Video Controller
00E08B A2 00 08 LDX #$0800 ;
00E08E 9C 19 21 STZ Video_Port_Data+1 ; Clear $800 bytes of Vram from $400 upwards
00E091 CA DEX ;
00E092 D0 FA BNE $00E08E ;
00E094 A2 AB E5 LDX #$E5AB ; Display Text From $e5ab on..
00E097 20 3E E2 JSR DO_TEXT ;
00E09A A9 08 LDA #$08 ;
00E09C 9C 16 21 STZ Video_Port_Address ; Set Video Port Address to $800
00E09F 8D 17 21 STA Video_Port_Address+1 ;
00E0A2 9C 15 21 STZ Video_Port_Controller ; Clear Video Port Controller
00E0A5 A2 00 00 LDX #$0000 ;
00E0A8 BD 91 E6 LDA $E691,X ; Copy $a0 bytes down into Vram location
00E0AB 8D 18 21 STA Video_Port_Data ; $800 onwards
00E0AE E8 INX ;
00E0AF E0 A0 00 CPX #$00A0 ;
00E0B2 D0 F4 BNE $E0A8 ;
00E0B4 A9 20 LDA #$20 ;
00E0B6 8D 18 21 STA Video_Port_Data ; Fill One Screen Worth of VRAM with
00E0B9 E8 INX ; spaces
00E0BA E0 00 04 CPX #$400 ;
00E0BD D0 F7 BNE $E0B6 ;
00E0BF A9 A8 LDA #$A8 ;
00E0C1 8D 00 0C STA $0C00 ; $c00 = $a8
00E0C4 8D 00 0D STA $0D00 ; $d00 = $a8
00E0C7 A9 21 LDA #$21 ;
00E0C9 A2 00 00 LDX #$0000 ; set $c01-$c028 = $21
00E0CC 9D 01 0C STA $0C01,X ;
00E0CF E8 INX ; ie set up the color pointer table
00E0D0 E0 28 00 CPX #$0028 ;
00E0D3 D0 F7 BNE $E0CC ;
00E0D5 A9 F8 LDA #$F8 ;
00E0D6 F8 SED ; set decimal flag on
00E0D7 9D 01 0C STA $0C01,X ;
00E0DA A9 01 LDA #$01 ; set more low memory
00E0DC 9D 02 0C STA $0C02,X ;
00E0DF E8 INX ;
00E0E0 E0 A0 00 CPX #$00A0 ; and further color palette set-up
00E0E3 D0 F7 BNE $E0DC ;
00E0E5 9e 02 0C STZ $C02,X ;
00E0E8 A9 0B LDA #$0B ;
00E0EA A2 00 00 LDX #$0000 ; set even more low memory
00E0ED 9D 01 0D STA $0D01,X ; - seems to set it to $b and then clear it??
00E0F0 E8 INX ;
00E0F1 9E 01 0D STZ $0D01,X ;
00E0F4 1A INC A ; pallete data set up
00E0F5 E8 INX ;
00E0F6 E0 28 00 CPX #$0028 ;
00E0F9 D0 F2 BNE $E0ED ;
00E0FB 9D 01 0D STA $0D01,X ;
00E0FE E8 INX ;
00E0FF 9E 01 0D STZ $0D01,X ;
00E102 3A DEC A ; and more 'irelevant' low mem stuff
00E103 E8 INX ;
00E104 E0 50 CPX #$0050 ; more palette data set-up
00E107 D0 F2 BNE $E0FB ;
00E109 A9 F8 LDA #$F8 ;
00E10B 9D 01 0D STA $0D01,X ;
00E10E A9 FF LDA #$FF ; and more 'irelevant' low mem stuff
00E110 9D 02 0D STA $0D02,X ;
00E113 E8 INX ; more palette data set-up
00E114 E0 40 01 CPX #$0140 ;
00E117 D0 F7 BNE $E109 ;
00E119 9E 02 0D STZ $D02,X ;
00E11C 9C 0C 42 STZ DMA_Enable ; Disable all DMA channels
00E11F 9C 10 43 STZ DMA_Control_1 ;
00E122 A9 02 LDA #$02 ; set up control regs for channel 1+2
00E124 8D 20 43 STA DMA_Control_2 ;
00E127 A9 21 LDA #$21 ; Select pallete pointer + color for
00E129 8D 11 43 STA DMA_Destination_1 ; DMA dump destination
00E12C 1A INC A ;
00E12D 8D 21 43 STA DMA_Destination_2 ;
00E130 A2 00 0C LDX #$0C00 ;
00E133 8E 12 43 STX DMA_Source_Addr_1 ; Palette numbers from $0c00
00E136 A2 00 0D LDX #$0D00 ;
00E139 8E 22 43 STX DMA_Source_Addr_2 ; Palette data from $0d00
00E13C 9C 14 43 STZ DMA_Source_Bank_1 ;
00E13F 9C 24 43 STZ DMA_Source_Bank_2 ;
00E142 A9 06 LDA #$06 ; turn on DMA channels 1+2
00E144 8D 0C 42 STA DMA_Enable ;
00E147 A9 0F LDA #$0F ; turn off screen
00E149 8D 00 21 STA Screen_Fader ;
00E14C A9 01 LDA #$01 ;
00E14E 8D 00 42 STA $4200 ; errmm
00E151 20 C1 E1 JSR Pad_Poll_Hi ; Wait for poll hi
00E154 9C 21 21 STZ Palette_Color_Pointer ;
00E157 9C 22 21 STZ Palette_Color_Data ; set background to black
00E15A 9C 22 21 STZ Palette_Color_Data ;
00E15D 4C 97 E1 JMP $00E197
------------------------------------------------
00E160 20 C1 E1 JSR Pad_Poll_Hi ; wait for poll hi
00E163 20 13 E2 JSR PROC_B
00E166 AD 12 42 LDA Pad_Poll ; Wait until a button has been
00E169 4A LSR A ; pressed
00E16A B0 FA BCS $00E166 ;
00E16C 20 CD E1 JSR PROC_A ;
00E16F A9 F0 LDA #$F0 ;
00E171 25 0A AND $0A ;
00E173 F0 46 BEQ $00E1BB ;
00E175 5C 00 80 00 JMP GAME ; and run the game..
------------------------------------------------
00E179 A9 01 LDA #$01 ;
00E17B A2 01 00 LDX #$0001 ;
00E17E 20 C1 E1 JSR Pad_Poll_Hi ;
00E181 8D 06 21 STA Pixelation ;
00E184 20 C7 E1 JSR Pad_Poll_Lo ;
00E187 CA DEX ;
00E188 10 F4 BPL $00E17E ;
00E18A 18 CLC ;
00E18B 69 10 ADC #$10 ;
00E18D C9 01 CMP #$01 ;
00E18F D0 EA BNE $00E17B ;
00E191 20 40 E2 JSR $00E240 ;
00E194 20 C7 E1 JSR Pad_Poll_Lo ;
00E197 20 C1 E1 JSR Pad_Poll_Hi ; wait for b7 pad_poll to go hi.
00E19A 20 13 E2 JSR PROC_B ;
00E19D A9 F1 LDA #$F1 ;
00E19F A2 01 00 LDX #$0001 ; 'Reverse Pixelate' the text into vision
00E1A2 20 C1 E1 JSR Pad_Poll_Hi ;
00E1A5 8D 06 21 STA Pixelation ;
00E1A8 20 C7 E1 JSR Pad_Poll_Lo ;
00E1AB CA DEX ;
00E1AC 10 F4 BPL $00E1A2 ;
00E1AE 38 SEC ;
00E1AF E9 10 SBC #$10 ;
00E1B1 C9 F1 CMP #$F1 ;
00E1B3 D0 EA BNE $00E19F ;
00E1B5 20 C1 E1 JSR Pad_Poll_Hi ;
00E1B8 9C 06 21 STZ Pixelation ; set pixels to normal.
00E1BB 20 C7 E1 JSR Pad_Poll_Lo ;
00E1BE 4C 60 E1 JMP $00E160 ; and jump into the main loop
------------------------------------------------
00E1C1 2C 12 42 Pad_Poll_Hi BIT Pad_Poll ; wait until bit 7 of pad_ready goes hi
00E1C4 10 FB BPL Pad_Poll_Hi ;
00E1C6 60 RTS ;
------------------------------------------------
00E1C7 2C 12 42 Pad_Poll_Lo BIT Pad_Poll ;
00E1CA 30 FB BMI Pad_Poll_Lo ; wait until bit 7 of pad_ready goes lo
00E1CC 60 RTS ;
------------------------------------------------
00E1CD C2 20 PROC_A REP #$20 ; 16 bit accum.
00E1CF A2 00 00 LDX #$0000 ;
00E1D2 A9 FF 7F LDA #$7FFF ;
00E1D5 E4 0B CPX $0B ;
00E1D7 F0 07 BEQ $00E1E0 ; set up table of $7fff in memory
00E1D9 9D B0 0D STA $0DB0,X ;
00E1DC E8 INX ;
00E1DD E8 INX ;
00E1DE 80 F5 BRA $00E1D5 ;
00E1E0 A0 00 00 LDY #$0000 ; and then follow the table with 5 zeros
00E1E3 B9 C3 E2 LDA $E2C3,Y ;
00E1E6 9D B0 0D STA $0DB0,X ;
00E1E9 C8 INY ;
00E1EA C8 INY ;
00E1EB E8 INX ;
00E1EC E8 INX ;
00E1ED C0 10 00 CPY #$0010 ;
00E1F0 D0 F1 BNE $00E1E3 ;
00E1F2 A9 FF 7F LDA #$7FFF ; and if x<>$90 then add more $7fff's
00E1F5 E0 90 00 CPX #$0090 ;
00E1F8 F0 07 BEQ $00E201 ;
00E1FA 9D B0 0D STA $0DB0,X ;
00E1FD E8 INX ;
00E1FE E8 INX ;
00E1FF 80 F4 BRA $00E1F5 ;
------------------------------------------------
00E201 A6 07 LDX $07 ; preserve old pad data
00E203 AD 18 42 LDA Pad_0_Data_Lo ; get new data
00E206 85 07 STA $07 ; and store it as the old
00E208 8A TXA ; wop it in accum.
00E209 49 FF FF EOR #$FFFF ; not the old data
00E20C 25 07 AND $07 ; and then use as a mask on new data
00E20E 85 09 STA $09 ; and then store in 9
00E210 E2 20 SEP #$20 ; and back to 8 bit accum..
00E212 60 RTS ; and back..
------------------------------------------------
00E213 9C 15 21 PROC_B STZ Video_Port_Control ; Reset Video Port
00E216 A9 04 LDA #$04 ;
00E218 9C 16 21 STZ Video_Port_Addr ; set video ram pointer to $400
00E21B 8D 17 21 STA Video_Port_Addr_Hi ;
00E21E 9C 19 21 STZ Video_Port_Data_Hi ;
00E221 9C 00 43 STZ DMA_Control_0 ; reset dma controller #0
00E224 A9 18 LDA #$18 ;
00E226 8D 01 43 STA DMA_Destination_0 ; point dma #0 to vram
00E229 A2 00 04 LDX #$0400 ;
00E22C 8E 02 43 STX DMA_Source_Addr_0 ; copy from address $400 to vram
00E22F 9C 04 43 STZ DMA_Source_Bank_0 ;
00E232 A2 00 04 LDX #$0400 ; copy $400 bytes into vram
00E235 8E 05 43 STX DMA_Size_0 ;
00E238 A9 01 LDA #$01 ; and enable dma #0
00E23A 8D 0B 42 STA DMA_Enable ;
00E23D 60 RTS
------------------------------------------------
00E23E 86 00 DO_TEXT STX $00 ; store text location
00E240 A2 00 04 LDX #$0400 ; set pointer to text
00E243 86 02 STX $02 ; store text location again
00E245 64 06 STZ $06 ; clear 6
00E247 A2 00 00 LDX #$0000 ;
00E24A B2 00 LDA ($00) ; get next char
00E24C 30 55 BMI $00E2A3 ; if bit 7 set then off we go..
00E24E C9 20 CMP #$20 ; is it a space
00E250 90 11 BCC $00E263 ; branch if less than a space..
00E252 92 02 STA ($02) ; store char
00E254 E8 INX ;
00E255 E6 00 INC $00 ; next char
00E257 D0 02 BNE $00E25B ;
00E259 E6 01 INC $01 ;
00E25B E6 02 INC $02 ; next dest spot
00E25D D0 EB BNE $00E24A ;
00E25F E6 03 INC $03 ;
00E261 80 E7 BRA $00E24A ;
------------------------------------------------
00E263 E6 00 INC $00 ; increment counter
00E265 D0 02 BNE $00E269 ; if not end of 255 boundary skip
00E267 E6 01 INC $01 ; increment hi byte of pointer
00E269 48 PHA ;
00E26A A9 20 LDA #$20 ;
00E26C E0 20 CPX #$0020 ;
00E26F F0 0B BEQ $E27C ;
00E271 92 02 STA ($02) ; basically these routines strip
00E273 E8 INX ; chars unnecessary and prepare the
00E274 E6 02 INC $02 ; text for output..
00E276 D0 F4 BNE $00E26C ;
00E278 E6 03 INC $03 ; these lines increment the 16 bit pointer
00E27A 80 F0 BRA $00E26C ; as 2 8 bit pointers
------------------------------------------------
00E27C 68 PLA ;
00E27D A2 00 00 LDX #$0000 ;
00E280 E6 06 INC $06 ;
00E282 C5 06 CMP $06 ;
00E284 D0 E3 BNE $00E269 ;
00E286 B2 00 LDA ($00) ;
00E288 E6 00 INC $00 ;
00E28A D0 02 BNE $00E28E ;
00E28C E6 01 INC $01 ;
00E28E 85 0D STA $0D ;
00E290 64 0E STZ $0E ;
00E292 A9 20 LDA #$20 ;
00E294 E4 0D CPX $0D ;
00E296 F0 B2 BEQ $00E24A ;
00E298 92 02 STA ($02) ;
00E29A E8 INX ;
00E29B E6 02 INC $02 ;
00E29D D0 02 BNE $00E2A1 ; and again increment pointer as 2 8 bit
00E29F E6 03 INC $03 ;
00E2A1 80 F1 BRA $00E294 ;
------------------------------------------------
00E2A3 A5 06 LDA $06 ;
00E2A5 C9 20 CMP #$20 ;
00E2A7 F0 19 BEQ $00E2C2 ;
00E2A9 A9 20 LDA #$20 ;
00E2AB E0 20 CPX #$0020 ;
00E2AE F0 0B BEQ $E2BB ;
00E2B0 92 02 STA ($02) ;
00E2B2 E8 INX ;
00E2B3 E6 02 INC $02 ;
00E2B5 D0 F4 BNE $00E2AB ;
00E2B7 E6 03 INC $03 ;
00E2B9 80 F0 BRA $00E2AB ;
------------------------------------------------
00E2BB A2 00 00 LDX #$0000 ;
00E2BE E6 06 INC $06 ;
00E2C0 80 E1 BRA $00E2A3 ;
00E2C2 60 RTS ;
------------------------------------------------
The End..

151
files/docs/snes/famitec2.txt Normal file
View File

@ -0,0 +1,151 @@
Version 1.1
Corrected an error in screen sizes and removed a quesry on sound registers.
Corsair + Kari presents the first dox of Fami hardware register
locations and brief explanation of them..
If you would like to add any info found in this list please leave
a mail message to Corsair or RamRaider on GRAVEYARD BBS +44-91-5160560
or anything to do with the FAMICON/SNES..
We have an INTERNET address if ya want it leave true e-mail!
Or better still if ya can get the Programmers handbook (Both) please call
and leave mail :) , or even the 100,000 quid SCSI SNASM board for FAMICON
development :)
Also if you want more info contact us the same way..
We are esp looking for contacts to help get to grips with this new platform
everybody welcome!
Special greetings to Starr/QUARTEX and any other True Console Dude!
coming soon is some sound chip info........
Memory Map
~~~~~~~~~~
Bank Address
~~~~ ~~~~~~~
00- 0000-1fff Lo RAM (same as at $7e0000-$7e1fff)
7d 2100-2142(?) Videochip Registers
4300-437f DMA Registers
8000-ffff ROM:This contains 32k block of game ROM.
So, the games are divided to 32k chunks
which locate always at address $8000-$ffff,
but in different banks. This means that the first
32k of game is at $008000-$00ffff and next 32k
is at $018000-$01ffff etc.
7e 0000-1fff Lo RAM (same as always at $0000-$1fff) \
2000-ffff RAM \ I'm not sure about } 128k RAM??
7f 0000-ffff RAM / this RAM /
7f-ff all Not used???
$ffec($fffc) contains reset vector and $ffea($fffa) is NMI vector. The NMI is
actually vertical blank interrupt.
Video Chip
~~~~~~~~~~
size loc.
~~~~ ~~~~
B 2100 Screen fade x000bbbb x=screen on/off b=brightness(0-f)
B 2106 Screen Pixelation xxxxbbbb x=pixel size b=planes to expand
B 2107 Plane 0 location in vram xxxxxxab x=address ab=32/64 width xy
B 2108 Plane 1 location in vram xxxxxxab as above
B 2109 Plane 2 location in vram xxxxxxab as above
B 210a Plane 3 location in vram xxxxxxab as above
B 210b Tile VRAM address aaaabbbb a=Playfield 0 b=Playfield 1
B 210c Tile VRAM address ccccdddd c=Playfield 2 d=Playfield 3
2B 210d Plane 0 scroll x 8+3 bits (0-7ff) put first 8 bits and then
2B 210e Plane 0 scroll y 8+3 bits (0-7ff) 3 highest bits
2B 210f Plane 1 scroll x as above
2B 2110 Plane 1 scroll y as above
2B 2111 Plane 2 scroll x as above
2B 2112 Plane 2 scroll y as above
2B 2113 Plane 3 scroll x as above
2B 2114 Plane 3 scroll y as above
B 2115 Video port control
W 2116 Video port address (lo-hi)
W 2118 Video port data (lo-hi) (address is incremented by 2)
B 2121 Palette color nr
B 2122 Palette color data
B 212C Playfield Enable xxxxabcd a-d = playfield number..
B 2133 Screen mode 0000ab0c a=Interlace Y b=Overscan c=Interlace X??
2140-2142 Audio Registers
I/O
~~~
W B 420b Start dma (enable bits) bits: 76543210 = dma nr (8 DMA's)
R B 4212 Pad ready to be read
R W 4218 Pad 0 data 76543210 = A-B-Select-Start-U-D-L-R
4219 76543210 = X-Y-Top Left-Top Right-0000
R W 421a Pad 1 data as above
R W 421c Pad 2 data as above
R W 421e Pad 3 data as above
DMA registers ($4300-$437f)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
B 43X0 DMA control reg??(not sure!)
B 43X1 DMA destination (Access only to some of the video chip
registers ($2100-$21ff)
$18=video port $22=color palette
W 43X2 Source address lo-hi 16 lowest bits
B 43X4 Source Bank addr. 8 highest bits
W 43X5 Transfer size lo-hi
X=dma number (0-7) DMA #0= 4300-4305
DMA #1= 4310-4315 ...
DMA #7= 4370-4375
Symbols: size: B=byte long 2B=put 2 bytes W=word long
R=read only W=write only
Screen Details
~~~~~~~~~~~~~~
Famicom Tile format is simple. Each Tile is 4 planes and 8x8 bits.
32 bytes are used per Tile .
PLANES 1 & 2 PLANES 3 & 4
byte0 byte1 byte 16 byte 17
byte2 byte3 byte 18 byte 19
byte4 byte5 byte 20 byte 21
..... .......
byte14 byte15 byte 30 byte 31
Screen Map
~~~~~~~~~~
Famicom can use only Tiles $0-$3ff, max 1024 chars.
16 bits: YX?c ccNN NNNN NNNN
fedc ba98 7654 3210
Y = mirror y X = mirror x ?=unknown
ccc = palette nr (8 palettes) NN.. = character number
Screen Resolution is normally 32x32 chars but only the first 30 y blocks are
visible (until scrolled) - 64 bytes / line
Screen VRAM Location
~~~~~~~~~~~~~~~~~~~~
Screen Width 32x32 offset for x,y 0,0 = 0
Screen Width 64x32 offset for x,y 0,0 = 0
33,0 = $400
Screen Width 32x64 offset for x,y 0,0 = 0
0,33 = $400
Screen Width 64x64 offset for x,y 0,0 = 0
33,0 = $400
0,33 = $800
33,33 = $c00
As can be seen if a wider mode is selected the extra height/width follow
after the main screen in memory.
=============================================================================

45
files/docs/snes/fastrom.txt Normal file
View File

@ -0,0 +1,45 @@
From: LAY@uk.tele.nokia.fi
To: "Super Famicom Development Group" <FAMIDEV@BUSOP.CIT.WAYNE.EDU>
Subject: The need for speed revisited...
Date: Wed, 16 Feb 1994 11:00:49 GMT
I unsubscribed from this mailing list after my suggestion that
maybe the processor would run faster when executing from RAM
brought responses such as "if you want something to run that
fast you should use a PC" which quickly turned into a whole
barrage of "my Amiga is faster than your PC" mails. Just the
sort of comments I was hoping to get from this mailing
list... )-: However I'm changing jobs and I don't know whether
I'll have internet access at my new job, so I'd better make
the most of it...
So, for anyone like myself who wants to get the most out
of their SNES I thought I'd let you know that I've managed to
run the program in FASTROM which has resulted in a 33% speed
improvement - the 65816 runs at 3.58Mhz rather than 2.68Mhz.
This is possible because the ROMs have a faster access time
- hence the reason I thought it may be possible with RAM which
typically has faster access times than ROM.
So how's it done?
The SNES lets you access ROM through bank $00 onwards and bank
$80 onwards such that locations $008000 and $808000, $008001 and
$808001, $008002 and $808002 etc... all access the same locations.
When accessing bank $00 onwards the 65816 runs at 2.68Mhz. However,
when accessing bank $80 onwards the 65816 can run at 2.68Mhz or
3.58Mhz depending on how you set bit 0 of $420D.
So all you have to do is assemble your program so that it
starts at $808000, make sure you set the programming and
data banks to $80 (K and D) and set bit 0 of $420D. You'll
also need to mask off the bank part of the run/reset vector
and vertical blank interrupt locations.
Paul.
PS. I also see that the source code for an early version of my
GIF2SNES program has made it onto the ftp site by a somewhat
indirect route (UK->NZ->AUS->USA). If someone wanted
this source code let me know and I'll post the latest fully
optimising version.

156
files/docs/snes/how2code.txt Normal file
View File

@ -0,0 +1,156 @@
BASELINE 2091 Presents The First Guide To Coding The SNES
Guide and Source Code by -Pan-
Released on 4/20/93
Welcome to the first installment of "How to code SNES"
This first volume will show you how to make a simple text intro. It uses
mode 0 graphics with no DMAs (Horizontal or General) and is the simplest
type of intro you can make. We're starting small so you can easily understand
what to do. Other future volumes will contain other graphic modes,
Horizontal DMA (HDMA, the SNES version of an amiga copperlist), General DMA,
Interrupts, and a brief section on Sound. Originally we were going to release
the full Super Famicom Programmer's Manual but believe it or not, this manual
a pile of garbage. Contrary to the popular belief that we always had the
manual, this is NOT true. The White Knight happened to meet a very cool
guy at the CEBIT in Germany and has gotten the manual 2 weeks ago!
Yes! What you have seen from us before was true coding. We started out
by hacking and working our way to the top. We didn't wait until we bought
a manual. In fact, the manual was sent to us for FREE! This book isn't
worth paying for!
Let's clear up a few misunderstandings about that SNES manual!
1) This book does NOT teach you assembly language!!
It would help if you knew a little before trying to code this machine!
2) This book was not written such as other reference guides you can find in
a store, like Mapping the Amiga, or even Mapping the C64.
It tells you barely and confusingly what the registers do. Period.
3) This book is about 148 pages long and that includes the Sound Section.
Some have said it was the size of a phone book. Unless live in
Mud Hole, Kentucky this is NOT the case!
So much for the introduction. I personally feel that experience is better
than a reference guide. Reading a text file does not give you the feel of the
machine. In the included source file, you will notice that almost every line
has a description of what it is doing. This is better than telling you the
registers and letting you fiddle around. You know what it will do, and you
can see it in action in the assembled output (also included). I suggest
you examine the source code right after reading this brief introduction on
how the SNES system operates.
The SNES runs on a 65816 processor. This is similar to the 6502, but many
new instructions are available. You will use the most popular commands
like LDA, LDX, STA, PHA, PLA, RTS, JMP.. etc etc. There are some new
ones but we will get into that subject in the next volume as it is not
very important right now.
The 65816 is a 16 bit processor that does 24 bit addressing.
You can load and store 16 bit numbers, as well as 8 bit. The addressing is
is different than the 6502 in that it includes a bank. If you have coded on
the C64 you know that the addressing on the C64 was from $0000-$FFFF.
That is 16 bit addressing. 24 bit includes 1 extra byte. This one byte
is the BANK number. The SNES memory is broken down into fragments of
32k blocks each. They are addressed from $8000-$FFFF and are stored into
banks sequentially. If you wanted to access the first ROM byte in memory,
the address would be $008000. The first $00 is the bank number, the first
bank you can access. The $8000 is the 16 bit address. All banks (unless in
high rom 64k bank memory) start at $8000!
Remember that you can not write ROM. If you have coded on a C64 you have
written a routine that looked like this:
lda #$00
sta $c000
You cannot do this! $c000 is ROM and you can not write to ROM!
To write to ram, simply write to any address between $0000-$1fff.
If you need more memory you will find plenty at bank $7e and $7f
These 2 banks contain memory from $0000-$ffff. These 2 banks each contain
64k ofram totalling 128k for your own use!
If you need to write to these directly, just use the LONG STA command
example:
sta $7ec000
This will write to bank $7e at address $c000!
Fair enough. This was only a brief lecture on how the memory works.
The SNES hardware registers and how the work:
You will notice when looking at the source code something very strange.
Some registers are written to twice in a row! This because some registers
need more than one 8 bit info, such as the scroll X registers. In these
registers you can enter any number between $0-$07ff, but they are written
as two 8 bit numbers, one right after another.
example:
lda #$07
sta $210d
lda #$00
sta $210d
This writes #$0007 to $210d, plane 0 scroll x register.
Using 16 bit data storage will not work for this type of register!
example:
lda #$0007
sta $210d
This will not work because it will write #$07 to $210d, then a #$00 to $210e.
Another strange register is the self-incrementing register such as the VRAM
address registers $2116 and $2117.
After writing to $2119 (or $2118 in another setting) the VRAM address in
$2116 and $2117 will be increased. You do not have to do it yourself.
This can be seen in the Character set (font set) transfer routine in the
source code.
Introduction to Video RAM (VRAM)
The Super NES system has it own graphics processor. This requires its own
ram to read/write graphics data. This ram can only be accessed through
certain registers such as $2118 + $2119. To access Video Ram you MUST
turn off the video or you must be in screen blank (horizontal or vertical).
This is one of the downsides of the SNES.
Video Ram allows the storage of map planes and tile graphics.
VRAM is only 64k long and can not be used as regular ram. You can not
program in it, it is a separate unit!
In this volume we show you how to make a text screen in Mode 0. There are
8 graphic modes numbered from Mode 0 to Mode 7. Mode 0 is the most
simplistic. It allows only 4 colors per tile, but allows all four
planes to be used.
A normal video screen on the SNES is 32*32 tiles, which comes out to an
even 1024 tiles. You can widen the screen but you still may only have
1024 tiles. There are 2 parts to displaying a graphic on the screen.
There is the tile graphic data which gives the tile its picture. Then there
is the Map data. These are individually placed tiles placed on the screen
to produce an image.
example:
BBBBB SSSSS LL
BB BB SS LL
BBBBB SSSS LL
BB BB SS LL
BBBBB SSSSS LLLLLLL
Notice that all the small B's are the same. These woulds be drawn as
Tile Graphics. They all form together to create the large B image.
These B's together would be the Map data. The same would go for the S and L.
This is enough info to understand the basics of this 2 color intro.
This next installment on "How to code SNES" will feature more interesting
subjects as:
- How the color works
- 16 color graphic mode
- the entire 65816 instruction set with op-codes
- more info on the joypad

129
files/docs/snes/memmap.txt Normal file
View File

@ -0,0 +1,129 @@
+=-=-=-=-=-=-=-=-=-=-=+
| SNES Memory Mapping |
| By: ]SiMKiN[ |
| v2.0 |
+=-=-=-=-=-=-=-=-=-=-=+
• FastROM's can execute at 3.58Mhz
• SlowROM's can only execute 2.68Mhz
• The SNES lets you access ROM through bank $00 onwards and bank
$80 onwards such that locations $00:8000 and $80:8000 are congruent,
(they access the same locations.)
• When accessing bank $00 onwards the 65816 runs at 2.68Mhz. However,
when accessing bank $80 onwards the 65816 can run at 2.68Mhz or
3.58Mhz depending on how you set bit 0 of $420D.
• This Document Contains Information Regarding ROM's upto 32mbit.
If you have any information regarding ROM's above 32mbit please send
E-Mail to 'simkin@innocent.com'
+======================================================================+
| Mode 20: LoROM Memory Model (32k Banks) |
| --------------------------------------- |
| • $80-$ef : $8000-$ffff |
| Mirrored to $00-6f |
| • $f0-$ff : $8000-$ffff |
+=========+=============+====================================+=========+
| Bank | Offset | Definition | Shadow |
+=========+=============+====================================+=========+
| $00-$2f | $0000-$1fff | LowRAM, shadowed from $7e | $7e |
| | $2000-$2fff | PPU1, APU | $00-$3f |
| | $3000-$3fff | SFX, DSP, etc. | $00-$3f |
| | $4000-$41ff | Controller | $00-$3f |
| | $4200-$5fff | PPU2, DMA, etc. | $00-$3f |
| | $6000-$7fff | RESERVED | $00-$3f |
| | $8000-$ffff | (Mode 20 ROM) | ------- |
+---------+-------------+------------------------------------+---------+
| $30-$3f | $0000-$1fff | LowRAM, shadowed from $7e | $7e |
| | $2000-$2fff | PPU1, APU | $00-$3f |
| | $3000-$3fff | SFX, DSP, etc. | $00-$3f |
| | $4000-$41ff | Controller | $00-$3f |
| | $4200-$5fff | PPU2, DMA, etc. | $00-$3f |
| | $6000-$7fff | RESERVED | ------- |
| | $8000-$ffff | (Mode 20 ROM) | $80-$bf |
+---------+-------------+------------------------------------+---------+
| $40-$6f | $0000-$7fff | RESERVED | ------- |
| | $8000-$ffff | (Mode 20 ROM) | $C0-$EF |
+---------+-------------+------------------------------------+---------+
| $70-$77 | $0000-$ffff | (Mode 20 SRAM) 256KBytes | ------- |
+---------+-------------+------------------------------------+---------+
| $78-$7d | $0000-$ffff | RESERVED | ------- |
+---------+-------------+------------------------------------+---------+
| $7e | $0000-$1fff | LowRAM | $00-$3f |
| | $2000-$7fff | HighRAM | ------- |
| | $8000-$ffff | Expanded RAM | ------- |
+---------+-------------+------------------------------------+---------+
| $7f | $0000-$ffff | Expanded RAM | ------- |
+---------+-------------+------------------------------------+---------+
| $80-$ef | $0000-$ffff | Mirror of $00-$6f | $00-$6f |
+---------+-------------+------------------------------------+---------+
| $f0-$ff | $0000-$7fff | RESERVED | ------- |
| | $8000-$ffff | (Mode 20 ROM) | ------- |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
+======================================================================+
| Mode 21: HiROM Memory Model (64k Banks) |
| --------------------------------------- |
| • $C0-$ff : $0000-$ffff |
| High Parts ONLY '($8000-$ffff)' are Shadowed to $00-3f |
+=========+=============+====================================+=========+
| Bank | Offset | Definition | Shadow |
+=========+=============+====================================+=========+
| $00-$2f | $0000-$1fff | LowRAM, shadowed from $7e | $7e |
| | $2000-$2fff | PPU1, APU | $00-$3f |
| | $3000-$3fff | SFX, DSP, etc. | $00-$3f |
| | $4000-$41ff | Controller | $00-$3f |
| | $4200-$5fff | PPU2, DMA, etc. | $00-$3f |
| | $6000-$7fff | RESERVED | $00-$3f |
| | $8000-$ffff | (Mode 21 ROM) from $C0-$EF | $C0-$EF |
+---------+-------------+------------------------------------+---------+
| $30-$3f | $0000-$1fff | LowRAM, shadowed from $7e | $7e |
| | $2000-$2fff | PPU1, APU | $00-$3f |
| | $3000-$3fff | SFX, DSP, etc. | $00-$3f |
| | $4000-$41ff | Controller | $00-$3f |
| | $4200-$5fff | PPU2, DMA, etc. | $00-$3f |
| | $6000-$7fff | (Mode 21 SRAM) 256KBytes | ------- |
| | $8000-$ffff | (Mode 21 ROM) from $C0-$EF | $C0-$EF |
+---------+-------------+------------------------------------+---------+
| $40-$6f | $0000-$7fff | (Mode 21 ROM) from $C0-$EF | $C0-$EF |
+---------+-------------+------------------------------------+---------+
| $70-$77 | $0000-$ffff | (Mode 20 SRAM) 256KBytes | ------- |
+---------+-------------+------------------------------------+---------+
| $78-$7d | $0000-$ffff | RESERVED | ------- |
+---------+-------------+------------------------------------+---------+
| $7e | $0000-$1fff | LowRAM | $00-$3f |
| | $2000-$7fff | HighRAM | ------- |
| | $8000-$ffff | Expanded RAM | ------- |
+---------+-------------+------------------------------------+---------+
| $7f | $0000-$ffff | Expanded RAM | ------- |
+---------+-------------+------------------------------------+---------+
| $80-$bf | $0000-$ffff | Mirror of $00-$3f | $00-$3f |
+---------+-------------+------------------------------------+---------+
| $c0-$ff | $0000-$ffff | (Mode 21 ROM) | ------- |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
• ROM: The SNES ROM Image
• RAM: The SNES Work Memory (WRAM)
LowRAM, HighRAM, & Expanded RAM
All together = 128 Kilo-Bytes
• SRAM: Save RAM (Extra RAM added by Cart)
The SNES only utilizes 256 Kilo-bits
However 256 Kilo-Bytes are provided.
• APU: Audio Processing Unit
SPC700, Inside which has a DSP
• PPU: Picture Processing Unit
PPU1: 5c77-01
PPU2: 5c78-03
• SFX: Super FX Cart Chip, by Nintendo
• DSP: Digital Signal Processing Cart Chip
a.k.a. 'NEC mUPD77C25'
• Shadow: "Congruent Bank". Same meaning as Mirror.
_____________________________________________________
.o(_Thanx to: zsKnight, Lord Esnes, Y0SHi, and MintaBoo_)o.

151
files/docs/snes/memory_mapping_and_io.txt Normal file
View File

@ -0,0 +1,151 @@
Version 1.1
Corrected an error in screen sizes and removed a quesry on sound registers.
Corsair + Kari presents the first dox of Fami hardware register
locations and brief explanation of them..
If you would like to add any info found in this list please leave
a mail message to Corsair or RamRaider on GRAVEYARD BBS +44-91-5160560
or anything to do with the FAMICON/SNES..
We have an INTERNET address if ya want it leave true e-mail!
Or better still if ya can get the Programmers handbook (Both) please call
and leave mail :) , or even the 100,000 quid SCSI SNASM board for FAMICON
development :)
Also if you want more info contact us the same way..
We are esp looking for contacts to help get to grips with this new platform
everybody welcome!
Special greetings to Starr/QUARTEX and any other True Console Dude!
coming soon is some sound chip info........
Memory Map
~~~~~~~~~~
Bank Address
~~~~ ~~~~~~~
00- 0000-1fff Lo RAM (same as at $7e0000-$7e1fff)
7d 2100-2142(?) Videochip Registers
4300-437f DMA Registers
8000-ffff ROM:This contains 32k block of game ROM.
So, the games are divided to 32k chunks
which locate always at address $8000-$ffff,
but in different banks. This means that the first
32k of game is at $008000-$00ffff and next 32k
is at $018000-$01ffff etc.
7e 0000-1fff Lo RAM (same as always at $0000-$1fff) \
2000-ffff RAM \ I'm not sure about } 128k RAM??
7f 0000-ffff RAM / this RAM /
7f-ff all Not used???
$ffec($fffc) contains reset vector and $ffea($fffa) is NMI vector. The NMI is
actually vertical blank interrupt.
Video Chip
~~~~~~~~~~
size loc.
~~~~ ~~~~
B 2100 Screen fade x000bbbb x=screen on/off b=brightness(0-f)
B 2106 Screen Pixelation xxxxbbbb x=pixel size b=planes to expand
B 2107 Plane 0 location in vram xxxxxxab x=address ab=32/64 width xy
B 2108 Plane 1 location in vram xxxxxxab as above
B 2109 Plane 2 location in vram xxxxxxab as above
B 210a Plane 3 location in vram xxxxxxab as above
B 210b Tile VRAM address aaaabbbb a=Playfield 0 b=Playfield 1
B 210c Tile VRAM address ccccdddd c=Playfield 2 d=Playfield 3
2B 210d Plane 0 scroll x 8+3 bits (0-7ff) put first 8 bits and then
2B 210e Plane 0 scroll y 8+3 bits (0-7ff) 3 highest bits
2B 210f Plane 1 scroll x as above
2B 2110 Plane 1 scroll y as above
2B 2111 Plane 2 scroll x as above
2B 2112 Plane 2 scroll y as above
2B 2113 Plane 3 scroll x as above
2B 2114 Plane 3 scroll y as above
B 2115 Video port control
W 2116 Video port address (lo-hi)
W 2118 Video port data (lo-hi) (address is incremented by 2)
B 2121 Palette color nr
B 2122 Palette color data
B 212C Playfield Enable xxxxabcd a-d = playfield number..
B 2133 Screen mode 0000ab0c a=Interlace Y b=Overscan c=Interlace X??
2140-2142 Audio Registers
I/O
~~~
W B 420b Start dma (enable bits) bits: 76543210 = dma nr (8 DMA's)
R B 4212 Pad ready to be read
R W 4218 Pad 0 data 76543210 = A-B-Select-Start-U-D-L-R
4219 76543210 = X-Y-Top Left-Top Right-0000
R W 421a Pad 1 data as above
R W 421c Pad 2 data as above
R W 421e Pad 3 data as above
DMA registers ($4300-$437f)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
B 43X0 DMA control reg??(not sure!)
B 43X1 DMA destination (Access only to some of the video chip
registers ($2100-$21ff)
$18=video port $22=color palette
W 43X2 Source address lo-hi 16 lowest bits
B 43X4 Source Bank addr. 8 highest bits
W 43X5 Transfer size lo-hi
X=dma number (0-7) DMA #0= 4300-4305
DMA #1= 4310-4315 ...
DMA #7= 4370-4375
Symbols: size: B=byte long 2B=put 2 bytes W=word long
R=read only W=write only
Screen Details
~~~~~~~~~~~~~~
Famicom Tile format is simple. Each Tile is 4 planes and 8x8 bits.
32 bytes are used per Tile .
PLANES 1 & 2 PLANES 3 & 4
byte0 byte1 byte 16 byte 17
byte2 byte3 byte 18 byte 19
byte4 byte5 byte 20 byte 21
..... .......
byte14 byte15 byte 30 byte 31
Screen Map
~~~~~~~~~~
Famicom can use only Tiles $0-$3ff, max 1024 chars.
16 bits: YX?c ccNN NNNN NNNN
fedc ba98 7654 3210
Y = mirror y X = mirror x ?=unknown
ccc = palette nr (8 palettes) NN.. = character number
Screen Resolution is normally 32x32 chars but only the first 30 y blocks are
visible (until scrolled) - 64 bytes / line
Screen VRAM Location
~~~~~~~~~~~~~~~~~~~~
Screen Width 32x32 offset for x,y 0,0 = 0
Screen Width 64x32 offset for x,y 0,0 = 0
33,0 = $400
Screen Width 32x64 offset for x,y 0,0 = 0
0,33 = $400
Screen Width 64x64 offset for x,y 0,0 = 0
33,0 = $400
0,33 = $800
33,33 = $c00
As can be seen if a wider mode is selected the extra height/width follow
after the main screen in memory.
=============================================================================

139
files/docs/snes/memory_mapping_overview.txt Normal file
View File

@ -0,0 +1,139 @@
SNES Memory Mapping
by
Duncanthrax of ShadowCraft
Version: 1.0
Date: August 28, 1997
Introduction:
This is a little document I'm throwing together as I go. It probably has a few innacuracies, but it's certainly better than nothing. I became frustrated with the lack of solid knowledge and documentation regarding memory in the SNES, all the other maps were very incomplete. So, since I'm building an emulator at the moment, I figured I'd write all this down for posterity.
If you find anything in here that is wrong, or if you have an additions or questions, or suggestions... or if you want to help with the emulator, mail me at:
odin@ccs.neu.edu
Or check out ShadowCraft's web page at:
http://shadowguild.home.ml.org
Have fun, and I hope this is helpful.
*---------------------------------------------------*
SNES Memory Map in LoROM Mode (Mode 0x20):
Bank: Address: Purpose:
----- -------- --------
00-3F 0000-1FFF Shadow RAM
2000-5FFF Hardware Registers
6000-7FFF Expansion RAM
8000-FFFF 32k ROM Chunk
40-7C 0000-7FFF 32k ROM Chunk
8000-FFFF 32k ROM Chunk
7D 0000-FFFF SRAM
7E 0000-1FFF Shadow RAM
2000-FFFF System RAM
7F 0000-FFFF System RAM
80-BF 0000-1FFF Shadow RAM
2000-5FFF Hardware Registers
6000-7FFF Expansion RAM
8000-FFFF 32k ROM Chunk
C0-FC 0000-7FFF 32k ROM Chunk
8000-FFFF 32k ROM Chunk
FD 0000-FFFF SRAM
FE 0000-1FFF Shadow RAM
2000-FFFF System RAM
FF 0000-FFxx System RAM
FFxx-FFFF Reset and NMI Vectors
SNES Memory Map in HiROM Mode (Mode 0x21):
Bank: Address: Purpose:
----- -------- --------
00-3F 0000-1FFF Shadow RAM
2000-5FFF Hardware Registers
6000-7FFF SRAM
8000-FFFF 32k ROM Chunk
40-7D 0000-FFFF 64k ROM Chunk
7E 0000-1FFF Shadow RAM
2000-FFFF System RAM
7F 0000-FFFF System RAM
80-BF 0000-1FFF Shadow RAM
2000-5FFF Hardware Registers
6000-7FFF SRAM
8000-FFFF 32k ROM Chunk
C0-FE 0000-FFFF 64k ROM Chunk
FF 0000-FFxx 64k ROM Chunk
FFxx-FFFF Reset and NMI Vectors
*--------------------------------------------*
Now that I've given you the overview of the memory layout, perhaps a little explanation would be in order. We'll start at 00.0000 and work our way up... in LoROM first, then HiROM - to avoid confusion.
00-3F 0000-1FFF Shadow RAM
What's going on here? Well, this is RAM that is the same in every bank up to and including 7E. It's the first 8k of System RAM. So, if you write 0x42 to 00.1001, you'll read a 0x42 from 7E.1001. Simple, huh?
00-3F 2000-5FFF Hardware Registers
This is where you do graphics hardware calls, BIOS calls, DMA calls, and all that stuff. There are lots and lots of documents on this, all of them confusing. I may write one later on that clarifies a bunch of stuff, but for now I won't go into greater detail, as this is pretty straightforward... read and write values that interact with hardware.
00-3F 6000-7FFF Expansion RAM
This is one of those areas in which I draw a blank. I'm not certain where this RAM is supposed to map, whether it is part of system RAM or what. Anybody who wants to clarify the purpose of this area of RAM can feel free. I've seen at least two cartridges that access this area...
00-3F 8000-FFFF 32k ROM Chunk
40-7C 0000-7FFF 32k ROM Chunk
8000-FFFF 32k ROM Chunk
This bears a little explanation. When the LoROM is loaded into memory, this is where it is mapped (in a real SNES it isn't "loaded" at all - just mapped). The first 64 32k chunks are loaded into the upper half of banks 00-3F. Then, you continue at 40, mapping two (2!) 32k chunks in each bank from 40-7C. This should take care of an entire LoROM. I know that theoretically a LoROM could be slightly bigger than this, but I've never seen one that is...
7D 0000-FFFF SRAM
OK, this is pretty obvious. This is where the battery-backed SRAM on cartridges is mapped. Very simple. Most have 64kb. DOOM, I've heard, has 256kb. Copiers have 256kb. Simple.
7E 0000-1FFF Shadow RAM
2000-FFFF System RAM
7F 0000-FFFF System RAM
Also very simple. This is the SNES's 128k of RAM. There, that was easy, right?
80-FF 0000-FFFF MIRROR!
The upper area of the SNES's addressing space is for "Fast ROM". Games will use this area instead of the lower area (they're mapped exactly the same) when they want to run faster. The SNES gains 1Mhz of speed this way.
The only thing that is different about the upper area is that the vectors for reset and NMI get stored in the FF.FFxx last 32 bytes...
*-------------------------------------------*
LoROM vs. HiROM!
OK, this is the most interesting part of SNES mapping, and also the part where I'm most likely to get something wrong. As always, if this is incorrect or confusing, let me know!
00-3F 0000-5FFF Same as LoROM
00-3F 6000-7FFF 8k SRAM Chunk
00-3F 8000-FFFF 32k ROM Chunk
40-7D 0000-FFFF 64k ROM Chunk
Ok, this is not too hard, with one caveat... the first 64 32k chunks of the HiROM cartridge get loaded into 00-3F, and then it REPEATS FROM THE BEGINNING starting at 40.0000, this time going in 64k chunks until the end of the file. Now, people are about to start yelling about how this doesn't leave room for the last 2 64k chunks of a 32mb ROM. Yes, I know... keep reading.
7E-7F 0000-FFFF Same as LoROM
Note 7D is no longer the SRAM, which is now in the expansion ram area.
80-FD 0000-FFFF Same as LoROM
FE-FF 0000-FFFF 64k ROM Chunk
Aha! Here it is... the last two chunks of a 32mb ROM (i.e. Chrono Trigger, etc.) get loaded here. Remember as always that the last 16 bytes are for vectors, and you're all set!
*--------------------------------------------*
Ok kiddies! That was a quick tour through the SNES memory map. Tune in next time for "Dr. Duncanthrax teaches CPU!" - same Bat Time, same Bat Channel!
Fin

129
files/docs/snes/memory_mapping_table.txt Normal file
View File

@ -0,0 +1,129 @@
+=-=-=-=-=-=-=-=-=-=-=+
| SNES Memory Mapping |
| By: ]SiMKiN[ |
| v2.0 |
+=-=-=-=-=-=-=-=-=-=-=+
• FastROM's can execute at 3.58Mhz
• SlowROM's can only execute 2.68Mhz
• The SNES lets you access ROM through bank $00 onwards and bank
$80 onwards such that locations $00:8000 and $80:8000 are congruent,
(they access the same locations.)
• When accessing bank $00 onwards the 65816 runs at 2.68Mhz. However,
when accessing bank $80 onwards the 65816 can run at 2.68Mhz or
3.58Mhz depending on how you set bit 0 of $420D.
• This Document Contains Information Regarding ROM's upto 32mbit.
If you have any information regarding ROM's above 32mbit please send
E-Mail to 'simkin@innocent.com'
+======================================================================+
| Mode 20: LoROM Memory Model (32k Banks) |
| --------------------------------------- |
| • $80-$ef : $8000-$ffff |
| Mirrored to $00-6f |
| • $f0-$ff : $8000-$ffff |
+=========+=============+====================================+=========+
| Bank | Offset | Definition | Shadow |
+=========+=============+====================================+=========+
| $00-$2f | $0000-$1fff | LowRAM, shadowed from $7e | $7e |
| | $2000-$2fff | PPU1, APU | $00-$3f |
| | $3000-$3fff | SFX, DSP, etc. | $00-$3f |
| | $4000-$41ff | Controller | $00-$3f |
| | $4200-$5fff | PPU2, DMA, etc. | $00-$3f |
| | $6000-$7fff | RESERVED | $00-$3f |
| | $8000-$ffff | (Mode 20 ROM) | ------- |
+---------+-------------+------------------------------------+---------+
| $30-$3f | $0000-$1fff | LowRAM, shadowed from $7e | $7e |
| | $2000-$2fff | PPU1, APU | $00-$3f |
| | $3000-$3fff | SFX, DSP, etc. | $00-$3f |
| | $4000-$41ff | Controller | $00-$3f |
| | $4200-$5fff | PPU2, DMA, etc. | $00-$3f |
| | $6000-$7fff | RESERVED | ------- |
| | $8000-$ffff | (Mode 20 ROM) | $80-$bf |
+---------+-------------+------------------------------------+---------+
| $40-$6f | $0000-$7fff | RESERVED | ------- |
| | $8000-$ffff | (Mode 20 ROM) | $C0-$EF |
+---------+-------------+------------------------------------+---------+
| $70-$77 | $0000-$ffff | (Mode 20 SRAM) 256KBytes | ------- |
+---------+-------------+------------------------------------+---------+
| $78-$7d | $0000-$ffff | RESERVED | ------- |
+---------+-------------+------------------------------------+---------+
| $7e | $0000-$1fff | LowRAM | $00-$3f |
| | $2000-$7fff | HighRAM | ------- |
| | $8000-$ffff | Expanded RAM | ------- |
+---------+-------------+------------------------------------+---------+
| $7f | $0000-$ffff | Expanded RAM | ------- |
+---------+-------------+------------------------------------+---------+
| $80-$ef | $0000-$ffff | Mirror of $00-$6f | $00-$6f |
+---------+-------------+------------------------------------+---------+
| $f0-$ff | $0000-$7fff | RESERVED | ------- |
| | $8000-$ffff | (Mode 20 ROM) | ------- |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
+======================================================================+
| Mode 21: HiROM Memory Model (64k Banks) |
| --------------------------------------- |
| • $C0-$ff : $0000-$ffff |
| High Parts ONLY '($8000-$ffff)' are Shadowed to $00-3f |
+=========+=============+====================================+=========+
| Bank | Offset | Definition | Shadow |
+=========+=============+====================================+=========+
| $00-$2f | $0000-$1fff | LowRAM, shadowed from $7e | $7e |
| | $2000-$2fff | PPU1, APU | $00-$3f |
| | $3000-$3fff | SFX, DSP, etc. | $00-$3f |
| | $4000-$41ff | Controller | $00-$3f |
| | $4200-$5fff | PPU2, DMA, etc. | $00-$3f |
| | $6000-$7fff | RESERVED | $00-$3f |
| | $8000-$ffff | (Mode 21 ROM) from $C0-$EF | $C0-$EF |
+---------+-------------+------------------------------------+---------+
| $30-$3f | $0000-$1fff | LowRAM, shadowed from $7e | $7e |
| | $2000-$2fff | PPU1, APU | $00-$3f |
| | $3000-$3fff | SFX, DSP, etc. | $00-$3f |
| | $4000-$41ff | Controller | $00-$3f |
| | $4200-$5fff | PPU2, DMA, etc. | $00-$3f |
| | $6000-$7fff | (Mode 21 SRAM) 256KBytes | ------- |
| | $8000-$ffff | (Mode 21 ROM) from $C0-$EF | $C0-$EF |
+---------+-------------+------------------------------------+---------+
| $40-$6f | $0000-$7fff | (Mode 21 ROM) from $C0-$EF | $C0-$EF |
+---------+-------------+------------------------------------+---------+
| $70-$77 | $0000-$ffff | (Mode 20 SRAM) 256KBytes | ------- |
+---------+-------------+------------------------------------+---------+
| $78-$7d | $0000-$ffff | RESERVED | ------- |
+---------+-------------+------------------------------------+---------+
| $7e | $0000-$1fff | LowRAM | $00-$3f |
| | $2000-$7fff | HighRAM | ------- |
| | $8000-$ffff | Expanded RAM | ------- |
+---------+-------------+------------------------------------+---------+
| $7f | $0000-$ffff | Expanded RAM | ------- |
+---------+-------------+------------------------------------+---------+
| $80-$bf | $0000-$ffff | Mirror of $00-$3f | $00-$3f |
+---------+-------------+------------------------------------+---------+
| $c0-$ff | $0000-$ffff | (Mode 21 ROM) | ------- |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
• ROM: The SNES ROM Image
• RAM: The SNES Work Memory (WRAM)
LowRAM, HighRAM, & Expanded RAM
All together = 128 Kilo-Bytes
• SRAM: Save RAM (Extra RAM added by Cart)
The SNES only utilizes 256 Kilo-bits
However 256 Kilo-Bytes are provided.
• APU: Audio Processing Unit
SPC700, Inside which has a DSP
• PPU: Picture Processing Unit
PPU1: 5c77-01
PPU2: 5c78-03
• SFX: Super FX Cart Chip, by Nintendo
• DSP: Digital Signal Processing Cart Chip
a.k.a. 'NEC mUPD77C25'
• Shadow: "Congruent Bank". Same meaning as Mirror.
_____________________________________________________
.o(_Thanx to: zsKnight, Lord Esnes, Y0SHi, and MintaBoo_)o.

1385
files/docs/snes/mmio.txt Normal file
View File

File diff suppressed because it is too large Load Diff

74
files/docs/snes/oam_flags.txt Normal file
View File

@ -0,0 +1,74 @@
From: vic@physci.psu.edu (Vic Ricker)
To: "Super Famicom Development Group" <famidev@busop.cit.wayne.edu>
Subject: Re: some programming questions
Date: Tue, 9 Nov 93 20:20:35 EST
>Hi Folks.
>I need help with a few SNES programming questions...
>(1) Can anyone tell me how to make noises come out of my SNES?
Insert your favorite cart, power up the TV, switch the snes power to
ON.. :-)
>(3) Is the sprite position table held in RAM or VRAM? And how
> do the 5 address bits in $2101 relate to this location?
The sprite images are stored in VRAM. The palettes for the sprites
are stored in CGRAM. The coordinates and char attributes are stored
in OAM.
The format of each OBJ is:
OBJ H position: 8 bits
OBJ V position: 8 bits
V flip: 1 bit
H flip: 1 bit
OBJ priority: 2 bits
color palette: 3 bits
character name: 9 bits
there are 128 of these in sequence making 512 bytes then 32 bytes
follow in the format:
size: 1 bit
x msb: 1 bit
there are 128 of these (one for every OBJ) making 32 more bytes.
$2101 is OBJSEL
it chooses the size of sprites to use and also sets the address of the
images in VRAM. the top 3 bits chose the size:
000 means 8x8 and 16x16 sprites
001 8x8 and 32x32
010 8x8 and 64x64
011 16x16 and 32x32
100 16x16 and 64x64
101 32x32 and 64x64
the other bits are the address in vram of the sprite images.
$2102-$2103 is OAMADDL/H
the lower 9 bits are the address for accessing the OAM. (like $2116
for VRAM)
the high bit (15) enables priority rotation (causes OBJ's to change
priority as to keep them from disappearing totally when time out and range
over occur.)
$2104 is OAMDATA
it is the write register for the OAM. (like $2118-$2119 for VRAM)
$2138 is *OAMDATA
it is the read register for the OAM.
Hope this gives you enough to play with. Most is from memory, I hope
its all correct. :-)
Lemme know if you have questions.

BIN
files/docs/snes/pilotwings.pdf Normal file
View File

Binary file not shown.

343
files/docs/snes/romformat_overview.txt Normal file
View File

@ -0,0 +1,343 @@
______ _____ _____ _______ ___ ___
/ __/ /. _ \ ___/ __/ |____ \___ /. \/ \
\___ .\// |. \ / . \__ .\ |. _/ \// .\
/. \\ |: .\ __/ \\ || | .\ ! \ \/. \
\______ /___|____/____\____ / |__| \\___/____||: \
By Mind Rape \___/ |______/
v1.5 (C) Damaged Cybernetics 1994-95
This document main goal is show where one can find the SNES ROM
information. Most of this information was collected thru hacking
the rom to death and help from Norm/Yoshi/chp.
License codes are taken from SU and probably incorrect.
Source? None here, if you are going to screw with the bin,
you probably know what you are doing (HOPEFULLY).
If you have any questions, comments,corrections, additional information,
you can either find me on IRC as (MindRape) or you can send me email
(much prefered) mind@primenet.com. Also if you write anything
interesting then send it to me!
You may distribute this document freely, but you may not change
the information here and redistribute. If you use this information
please credit me. You steal this information and say you did it,
you know it's a LIE and there you are.
=[SNES ROM Makeup]===========================================================
ROM Title : 21 Bytes
* Titles are all in upper case
* Japanese titles are in high ascii values
good rule of thumb if you can't read the title and
it's country code is Japan and your American,
you probably can't play it. :>
Rom Makeup : 7654 3210
0000-0000
|__| |__|
| |
| |___Bank Size 0001 = HiROM (64K Banks Mode 21)
| 0000 = Low Rom (32K Banks Mode 20)
|
|________ROM Speed 0111 = Fast Rom
0000 = Slow Rom
* Could someone give the correct
* speeds of the ROMs? I got
* conflicting answers.
ROM Type : 1 Byte
Hex ROM Type
---------------------
00 ROM
01 ROM/RAM
02 ROM/SRAM
03 ROM/DSP1
04 ROM/DSP1/RAM
05 ROM/DSP1/SRAM
06 FX
* SRAM = Save Ram
* DSP1 = Nintendo's 1st generation of DSP (Math coprocessor)
* FX = RISC based math coprocessor
Only a couple of games support the FX Chip, Star Fox
is the most well known one.
ROM Size : 1 BYTE
Hex Size
--------------
08 2 Mbit
09 4 Mbit
0A 8 Mbit
0B 16 Mbit
0C 32 Mbit
* As of this documentation 32MBit ROMs are the largest that
Nintendo currently uses. Rumors of a 40+ kart are around,
but cannot be verified.
* 8MBit ROMs are the most common in the entire library of
SNES karts
* ROMs are always multiples 2, thus 2MBit ROMs are the smallest
Space Invaders (c) Taito is a 2MBit ROM (Japan only)
* Easy way to calc rom size without a lookup table
1 << (ROM_SIZE - 7) MBits
ie. 8Mbit ROMs = 0Ah = 10d
1 << (0A-7) = 8 Mbit
SRAM Size : 1 BYTE
Hex Size
--------------
00 No SRAM
01 16 Kbit
02 32 Kbit
03 64 Kbit
* 64Kbit is the largest SRAM size that Nintendo currently uses.
* 256Kbit is standard for most copiers.
* Easy way to calc SRAM Size without a lookup table
1 << (3+SRAM_BYTE) Kbits
ie. 16Kbit = 01
1 << (3+1) = 16
COUNTRY CODE : 1 BYTE
Hex Country Video Mode
------------------------------------------
00 Japan (NTSC)
01 USA (NTSC)
02 Europe, Oceania, Asia (PAL)
03 Sweden (PAL)
04 Finland (PAL)
05 Denmark (PAL)
06 France (PAL)
07 Holland (PAL)
08 Spain (PAL)
09 Germany, Austria, Switz (PAL)
10 Italy (PAL)
11 Hong Kong, China (PAL)
12 Indonesia (PAL)
13 Korea (PAL)
* Country Codes are from SU.INI, could someone verify these?
LICENSE : 1 BYTE
0 <Invalid License Code>
1 Nintendo
5 Zamuse
8 Capcom
9 HOT B
10 Jaleco
11 STORM (Sales Curve) (1)
15 Mebio Software
18 Gremlin Graphics
21 COBRA Team
22 Human/Field
24 Hudson Soft
26 Yanoman
28 Tecmo (1)
30 Forum
31 Park Place Productions / VIRGIN
33 Tokai Engeneering (SUNSOFT?)
34 POW
35 Loriciel / Micro World
38 Enix
40 Kemco (1)
41 Seta Co.,Ltd.
45 Visit Co.,Ltd.
53 HECT
61 Loriciel
64 Seika Corp.
65 UBI Soft
71 Spectrum Holobyte
73 Irem
75 Raya Systems/Sculptured Software
76 Renovation Pruducts
77 Malibu Games (T*HQ Inc.) / Black Pearl
79 U.S. Gold
80 Absolute Entertainment
81 Acclaim
82 Activision
83 American Sammy
84 GameTek
85 Hi Tech
86 LJN Toys
90 Mindscape
93 Technos Japan Corp. (Tradewest)
95 American Softworks Corp.
96 Titus
97 Virgin Games
98 Maxis
103 Ocean
105 Electronic Arts
107 Laser Beam
110 Elite
111 Electro Brain
112 Infogrames
113 Interplay
114 LucasArts
115 Sculptured Soft
117 STORM (Sales Curve) (2)
120 THQ Software
121 Accolade Inc.
122 Triffix Entertainment
124 Microprose
127 Kemco (2)
130 Namcot/Namco Ltd. (1)
132 Koei/Koei! (second license?)
134 Tokuma Shoten Intermedia
136 DATAM-Polystar
139 Bullet-Proof Software
140 Vic Tokai
143 I'Max
145 CHUN Soft
146 Video System Co., Ltd.
147 BEC
151 Kaneco
153 Pack in Video
154 Nichibutsu
155 TECMO (2)
156 Imagineer Co.
160 Wolf Team
164 Konami
165 K.Amusement
167 Takara
169 Technos Jap. ????
170 JVC
172 Toei Animation
173 Toho
175 Namcot/Namco Ltd. (2)
177 ASCII Co. Activison
178 BanDai America
180 Enix
182 Halken
186 Culture Brain
187 Sunsoft
188 Toshiba EMI/System Vision
189 Sony (Japan) / Imagesoft
191 Sammy
192 Taito
194 Kemco (3) ????
195 Square
196 NHK
197 Data East
198 Tonkin House
200 KOEI
202 Konami USA
205 Meldac/KAZe
206 PONY CANYON
207 Sotsu Agency
209 Sofel
210 Quest Corp.
211 Sigma
214 Naxat
216 Capcom Co., Ltd. (2)
217 Banpresto
219 Hiro
221 NCS
222 Human Entertainment
223 Ringler Studios
224 K.K. DCE / Jaleco
226 Sotsu Agency
228 T&ESoft
229 EPOCH Co.,Ltd.
231 Athena
232 Asmik
233 Natsume
234 King/A Wave
235 Atlus
236 Sony Music
238 Psygnosis / igs
243 Beam Software
244 Tec Magik
255 Hudson Soft
* License Codes are from SU.INI, could someone verify these?
* I believe the # of licenses is low. Is it possible that
License and Country codes are used in conjuction to produce
that many more licenses?
VERSION - 1 byte
* The Version is interpeted this way.
1.?? - (thanks to yoshi for the correction)
CHECKSUM COMPLEMENT - 2 bytes the complement of the checksum :>
The bits are reversed of the CHECKSUM
CHECKSUM - 2 bytes Checksum of the bin
* Anyone know how the checksum is calculated for the ROM?
NMI/VBL Vector - 2 bytes - OFFSET 81FAh (lowrom)
OFFSET 101FAh (hirom)
RESET Vector - 2 bytes where to start our code at - OFFSET 81FCh (lowrom)
- OFFSET 101FAh (hirom)
* 8000h is common for Low Roms
=[READING THE CORRECT BIN INFORMATION]==================================
The bin information can be found in 2 possible places,
a) End of the 1st 32K bank (Low ROM) (81c0h/w 512 byte header)
b) End of the 1st 64K bank (HiROM) (101c0h/w 512 byte header)
You could use UCON's method (author chp).
The method is as followed:
UCON's method is to OR the Checksum and the Complement. If the
resulting value is FFFFh, then we found the correct location of
to extract rest of the data out. HOWEVER! This fails on several
karts, such as Castle Wolfenstien 3D and Super Tetris 3 for example.
Reason being is that not all developers put the correct complement
or bother even to implement it. I would suspect! That this maybe
a ploy to keep other developers out of the bin, for if they can't
find the reset vector, disassembling becomes a bit difficult.
=[Other Information on SNES?]================================================
Famicom Development FTP Site
busop.cit.wayne.edu - pub/famidev
Yoshi's SNES Documentation 2.3
This is considered the BEST source of SNES hardware information,
and the most complete!
busop.cit.wayne.edu - pub/famidev/incoming/sndoc230.lzh
=[w0rd!]=====================================================================
w0rd to all following console dudes
GoosE_,yoshi,sir jinx,chp,SHORYUKEN,_bubsy,felon,archimede
rugalz,SinZ,dragonz,procyon,royce,hoodlem,bri_acid,kamikitty,
norm,ZillionZ Members,grayarea,Victor,drunkfux(h0h0h0h0),dmessiah,
piratendo
<insert your favorite group(s) greet here> (heh)
Later Mind Rape

1128
files/docs/snes/romhacking.txt Normal file
View File

File diff suppressed because it is too large Load Diff

335
files/docs/snes/snes_cart1.txt Normal file
View File

@ -0,0 +1,335 @@
------------------------------------- - - - -
SNES CART HACKING INFO #1 BY SIUDYM
---------------------------------------- - - - - -
01. Cartridge Connector LoROM Pinout
02. Cartridge Connector HiROM Pinout
03. Mask ROM Pinout
04. SRAM (2KB) 6216 Pinout
05. SRAM (8KB) 6264 Pinout
06. Address Decoder MAD-1 Pinout (ILLUSION OF TIME 2MB HiROM)
07. Address Decoder MAD-1 Pinout (NBA LIVE 95 1,5MB LoROM)
08. Address Decoder 74LS00 Pinout (SOCCER SHOOTOUT 1,5MB LoROM)
09. Address Decoder 74LS00 Pinout (JUSTICE LEAGUE TASK FORCE 3MB LoROM)
10. Address Decoder 74LS00 Pinout (EARTHWORM JIM 2 - PIRATE 3MB HiROM)
11. Address Decoder 74LS139 Pinout (SUPER MARIO WORLD 0,5MB LoROM)
12. Address Decoder 74LS139 Pinout (MORTAL KOMBAT 2 - PIRATE 3MB HiROM (FIRST 2MB FOR MK2, LAST 1MB FOR KILLER INSTINCT DEMO)
13. Address Decoder 74LS00 Spec.
14. Address Decoder 74LS139 Spec.
-----------------------------------------------------------------------
01. Cartridge Connector LoROM:
---+---
GND |05 | 36| GND
A11 |06 | 37| A12
A10 |07 | 38| A13
A9 |08 | 39| A14
A8 |09 | 40| NC
A7 |10 | 41| A15
A6 |11 | 42| A16
A5 |12 | 43| A17
A4 |13 | 44| A18
A3 |14 | 45| A19
A2 |15 | 46| A20
A1 |16 | 47| A21
A0 |17 | 48| A22
/IRQ |18 | 49| /OE
D0 |19 | 50| D4
D1 |20 | 51| D5
D2 |21 | 52| D6
D3 |22 | 53| D7
/CE |23 | 54| /WE
Pin 1 D413 |24 | 55| Pin 2 D413
Pin 7 D413 |25 | 56| Pin 6 D413
RAM /E |26 | 57| NC
VCC |27 | 58| VCC
---+---
Pin #23 -> ROM /CE and RAM /OE (connected together)
Pin #49 -> ROM /OE
Pin #54 -> RAM /WE
-----------------------------------------------------------------------
02. Cartridge Connector HiROM:
---+---
GND |05 | 36| GND
A11 |06 | 37| A12
A10 |07 | 38| A13
A9 |08 | 39| A14
A8 |09 | 40| A15
A7 |10 | 41| A16
A6 |11 | 42| A17
A5 |12 | 43| A18
A4 |13 | 44| A19
A3 |14 | 45| A20
A2 |15 | 46| A21
A1 |16 | 47| A22
A0 |17 | 48| A23
/IRQ |18 | 49| /OE
D0 |19 | 50| D4
D1 |20 | 51| D5
D2 |21 | 52| D6
D3 |22 | 53| D7
/CE |23 | 54| /WE
Pin 1 D413 |24 | 55| Pin 2 D413
Pin 7 D413 |25 | 56| Pin 6 D413
RAM /E |26 | 57| NC
VCC |27 | 58| VCC
---+---
Pin #23 -> ROM /CE and RAM /OE (connected together)
Pin #49 -> ROM /OE
Pin #54 -> RAM /WE
-----------------------------------------------------------------------
03. Mask ROM Pinout:
__ __
A20 | \/ | +5V
A21 |__ __| A22
A17 |01\/32| +5V
A18 |02 31| /OE
A15 |03 30| A19
A12 |04 29| A14
A7 |05 28| A13
A6 |06 27| A8
A5 |07 26| A9
A4 |08 25| A11
A3 |09 24| A16
A2 |10 23| A10
A1 |11 22| /CE
A0 |12 21| D7
D0 |13 20| D6
D1 |14 19| D5
D2 |15 18| D4
GND |16 17| D3
------
/CE connected to SNES pin #23
/OE connected to SNES pin #49 or Address Decoder
-----------------------------------------------------------------------
04. SRAM (2KB) 6216 Pinout:
__ __
A7 |01\/24| +5V
A6 |02 23| A8
A5 |03 22| A9
A4 |04 21| /WE
A3 |05 20| /OE
A2 |06 19| A10
A1 |07 18| /CE
A0 |08 17| D7
D0 |09 16| D6
D1 |10 15| D5
D2 |11 14| D4
GND |12 13| D3
------
/CE connected to Address Decoder
/OE connected to /CE in ROM
/WE connected to SNES pin #54
-----------------------------------------------------------------------
05. SRAM (8KB) 6264 Pinout:
__ __
+5V |01\/28| +5V
A12 |02 27| /WE
A7 |03 26| NC
A6 |04 25| A8
A5 |05 24| A9
A4 |06 23| A11
A3 |07 22| /OE
A2 |08 21| A10
A1 |09 20| /CE
A0 |10 19| D7
D0 |11 18| D6
D1 |12 17| D5
D2 |13 16| D4
GND |14 15| D3
------
/CE connected to Address Decoder
/OE connected to /CE in ROM
/WE connected to SNES pin #54
#26 connected to SNES pin #26 (RESET)
-----------------------------------------------------------------------
06. Address Decoder MAD-1 Pinout (ILLUSION OF TIME)
__ __
NC |01\/16| NC
RAM /CE |02 15| A13
NC |03 14| A14
ROM /OE |04 13| A21
+5V |05 12| A22
+5V |06 11| SNES #49
+5V |07 10| GND
GND |08 09| SNES #26 and RAM #26 (only in 6264)
------
-----------------------------------------------------------------------
07. Address Decoder MAD-1 Pinout (NBA LIVE 95)
__ __
ROM2 /OE |01\/16| ROM1 /OE
RAM /CE |02 15| SNES #40
NC |03 14| A19
NC |04 13| A20
+5V |05 12| A21
+5V |06 11| SNES #49
+5V |07 10| GND
GND |08 09| SNES #26 and RAM #26 (only in 6264)
------
-----------------------------------------------------------------------
08. Address Decoder 74LS00 Pinout (SOCCER SHOOTOUT)
__ __
+5V |01\/14| +5V
SNES #49 |02 13| A20
NC |03 12| +5V
NC |04 11| NC
A20 |05 10| NC
ROM2 /OE |06 09| NC
GND |07 08| ROM1 /OE
------
Pins #03, #04, #09 connected together (NC)
Pins #05, #13 connected together (A20)
Pins #11, #10 connected together (NC)
-----------------------------------------------------------------------
09. Address Decoder 74LS00 Pinout (JUSTICE LEAGUE TASK FORCE)
__ __
+5V |01\/14| +5V
SNES #49 |02 13| A21
NC |03 12| NC
+5V |04 11| ROM2 /OE
A21 |05 10| NC
NC |06 09| NC
GND |07 08| ROM1 /OE
------
Pins #03, #12, #10 connected together (NC)
Pins #05, #13 connected together (A21)
Pins #06, #09 connected together (NC)
-----------------------------------------------------------------------
10. Address Decoder 74LS00 Pinout (EARTHWORM JIM 2 - PIRATE)
__ __
SNES #49 |01\/14| +5V
SNES #49 |02 13| A21
NC |03 12| NC
A21 |04 11| ROM2 /OE
A21 |05 10| NC
NC |06 09| NC
GND |07 08| ROM1 /OE
------
Pins #03, #12, #10 connected together (NC)
Pins #04, #05, #12 connected together (A21)
Pins #06, #09 connected together (NC)
Pins #01, #02 connected together (#49)
-----------------------------------------------------------------------
11. Address Decoder 74LS139 Pinout (SUPER MARIO WORLD)
__ __
SNES #49 |01\/16| +5V
A21 |02 15| NC
A20 |03 14| A19
ROM /OE |04 13| NC
NC |05 12| NC
NC |06 11| NC
NC |07 10| NC
GND |08 09| RAM /CE
------
Pins #07, #15 connected together (NC)
-----------------------------------------------------------------------
12. Address Decoder 74LS139 Pinout (MORTAL KOMBAT 2 - PIRATE 3MB VERSION)
__ __
SNES #23 |01\/16| +5V
A21 |02 15| NC
GND |03 14| NC
ROM1 /OE or /CE |04 13| NC
ROM2 /OE or /CE |05 12| NC
NC |06 11| NC
NC |07 10| NC
GND |08 09| NC
------
-----------------------------------------------------------------------
13. Address Decoder 74LS00 Spec.
__ __
1A |01\/14| +5V
1B |02 13| 4B
1Y |03 12| 4A
2A |04 11| 4Y
2B |05 10| 3B
2Y |06 09| 3A
GND |07 08| 3Y
------
-----------------------------------------------------------------------
14. Address Decoder 74LS139 Spec.
__ __
1E |01\/16| +5V
1A0 |02 15| 2E
1A1 |03 14| 2A0
1Y0 |04 13| 2A1
1Y1 |05 12| 2Y0
1Y2 |06 11| 2Y1
1Y3 |07 10| 2Y2
GND |08 09| 2Y3
------
-----------------------------------------------------------------------
2001 siudym@pf.pl

1385
files/docs/snes/snesmap.txt Normal file
View File

File diff suppressed because it is too large Load Diff

850
files/docs/snes/snestech.txt Normal file
View File

@ -0,0 +1,850 @@
SNES hardware notes
by Charles MacDonald
WWW: http://cgfm2.emuviews.com
Unpublished work Copyright 2003 Charles MacDonald
This document is in a very preliminary state and is subject to change.
Most everything within has been tested and verified on a SNES but
please be aware that my testing methods or interpretations of results
could be flawed. I can't guarantee that everything is 100% accurate.
Last updated 09/17/03
[09/17/03]
- Added the cartridge information section.
- Added some details on the screen layout.
[08/27/03]
- Fixed some typos
- Added CGRAM information
- Added notes about valid times to access OAM
[08/25/03]
- Added some sprite information
[08/22/03]
- Added mouse information
- Added multitap information
- Changed joypad section
[08/20/03]
- Initial release
Table of contents
1. Various notes
2. CGRAM
3. Sprites
3. Hardware version registers
4. I/O hardware
5. Register reference
6. Cartridge information
7. Assistance needed
8. Credits and acknowledgements
9. Disclaimer
----------------------------------------------------------------------------
Various notes
----------------------------------------------------------------------------
V-Blank occurance flag
- Bit 7 of $4212 is set at line $00E1 and cleared at line $0000 in 224-line
mode.
- Bit 7 of $4212 is set at line $00F0 and cleared at line $0000 in 239-line
mode.
Joypad automatic scanning flag
- Bit 0 of $4212 is set at line $00E1 and cleared at line $00E4 in 224-line
mode.
- Bit 0 of $4212 is set at line $00F0 and cleared at line $00F3 in 239-line
mode.
Non-maskable interrupts
According to the 65816 manual, the NMI signal is an edge-sensitive input,
so that only a high to low transition on the NMI pin will cause an interrupt
to occur. Leaving it high, low, or having a low to high transition has no
effect. I'm going to assume the PPU normally holds NMI high and brings it
low to trigger an interrupt.
The PPU will pull NMI low at line $00E8 in 224-line mode or line $00F7 in
239-line mode. It will remain low until either $4210 is read, or a new
frame starts, at which point the PPU will bring NMI high again.
The inverted state of the NMI signal from the PPU can be read through bit 7
of $4210, where 0= no NMI has been requested, 1= an NMI is pending. After
reading this register, the PPU resets the NMI signal by pulling it high.
Bit 7 of $4200 doesn't affect how the PPU manages NMIs at all, it is just
a gate between the NMI output of the PPU and the NMI input of the CPU.
When set, NMIs can be generated. When cleared, the CPU ignores the state of
the NMI pin.
Here are some details of specific situations:
When there is a pending NMI, toggling bit 7 of $4200 does not create any
additional interrupts.
Bit 7 of $4210 will be set in the NMI routine when it executes.
After the NMI routine finishes, bit 7 will remain set (assuming $4210 wasn't
read) until the start of the next frame. This will not cause more NMIs to
occur as they are only triggered by high-to-low transitions, having the NMI
pin remain low does not do anything.
Bit 7 of $4210 reflects the NMI status independantly of bit 7 of $4200.
Interlaced display
When bit 0 of $2133 is set, the screen becomes interlaced regardless of
the BG mode setting. When the screen is interlaced, the following applies:
- For BG modes 0,1,2,3,4,7 each line of the background is repeated in the
even and odd frames for single-density interlace. (224 or 239 lines shown)
- For BG modes 5,6 each line of the background is unique for the even and
odd frames for double-density interlace. (448 or 478 lines shown)
Screen layout
For an NTSC non-interlaced display, each frame consists of 262 lines.
Depending on the screen height, these lines are divided into the following
groups:
Section 224-line mode 239-line mode
Active display 224 239
Bottom blanking 12 15
Vertical sync 3 3
Top blanking 23 5
Total 262 262
Active display is the portion of the screen where graphics are displayed.
Bottom blanking is the bottom border after the active display shown at the
very bottom of the display. Lines are filled with black.
Vertical sync is the period between the bottom and top borders which is
off-screen. Lines are filled with a darker black color than in the blanking
areas.
Top blanking is the border after the vertical sync period shown at the very
top of the display. Lines are filled with black.
----------------------------------------------------------------------------
CGRAM
----------------------------------------------------------------------------
Overview
The PPU has 512 bytes of on-chip RAM called CGRAM which holds palette data.
CGRAM is divided into 256 2-byte entries that define a single color.
Each entry has the following format:
MSB LSB
-bbbbbgggggrrrrr
b = Blue component (0=black, 31=bright)
g = Green component (0=black, 31=bright)
r = Red component (0=black, 31=bright)
- = Unused bit.
The background can use the first 128 colors in BG modes 0,1,2,5,6, and all
256 colors in BG modes 3,4,7 when not in direct color mode. Sprites always
use the latter 128 colors. Specific details about palette use and selection
for each mode will be described later.
The PPU provides several registers for using CGRAM:
$2121 - CGRAM address
$2122 - CGRAM data port (write)
$213B - CGRAM data port (read)
CGRAM access
The PPU has a 9-bit address register which gives a byte offset into CGRAM.
Writing to $2121 loads the CPU data into bits 8-1 of the address register
and clears bit 0, forcing an even address to be set.
Each time $213B is read, the byte at the current offset pointed to by the
address register is returned to the CPU, and the address register is
incremented by one.
Each time $2122 is written to the address register is incremented by one.
If the address register is even during a write, the CPU data is stored in
a latch. If the address register is odd, the latched data becomes the LSB
and the new data written becomes the MSB of a 16-bit word. This word is
written to the current address, with bit 0 of the address register ignored.
The address register will wrap from $01FF to $0000 due to reading $213B or
writing to $2122. You can mix reads and writes freely.
Valid access times
When the screen is forcibly blanked or in the V-Blank period, CGRAM can be
read and written. I haven't tested access during H-Blank yet.
Here are my observations about CGRAM access during the active display
period:
- Writing to CGRAM always results in the last word written to the data port
being written to address 0,1 regardless of the address register setting.
You could think of address bits 8-1 as always being fixed to zero during
this time.
- Reading from CGRAM returns a random mix of bytes from CGRAM and data that
wasn't stored in CGRAM. The address register has no effect on where the
data comes from.
- When the screen is turned on, the previously set value in the address
register not changed. Following reads or writes with the screen off
affect the address originally selected.
CGRAM access examples
Here are some examples of unexpected behavior. Assume CGRAM contains the
bytes $AA, $BB, $CC, $DD at address $0000 for each test:
- Set address to $0000
- Write $45
CGRAM is not updated, and the LSB latch contains $45
- Set address to $0000
- Read $2138
- Write #$45
The bytes $CC, $45 are written to address $0000. $CC was the last value
in the LSB latch, and a single byte write triggers a write to CGRAM as the
previous read made the address register odd.
----------------------------------------------------------------------------
Sprites
----------------------------------------------------------------------------
The PPU can manage up to 128 sprites. Sprites use 16-color 8x8 tiles, the
same as used by the backgrounds. The sprite size can range from 1x1 tiles
up to 8x8 tiles, with several variations in between.
The attributes for each sprite are stored in 544 bytes of on-chip RAM called
OAM or "Object Attribute Memory". The OAM can be thought of having two
sections, a 512-byte table that has 128 x 4-byte entries, and a 32-byte
table used as 128 x 2-bit entries.
The PPU provides several registers for sprite control:
$2101 - OAM control
$2102 - OAM address LSB
$2103 - OAM address MSB
$2104 - OAM data port (write)
$2138 - OAM data port (read)
The OAM control register defines various aspects about the sprites:
D7 : Sprite size, bit 2
D6 : Sprite size, bit 1
D5 : Sprite size, bit 0
D4 : Sprite name offset, bit 1
D3 : Sprite name offset, bit 0
D2 : Sprite pattern table base, bit 2
D1 : Sprite pattern table base, bit 1
D0 : Sprite pattern table base, bit 0
The sprite pattern table is where the tile data for sprites is fetched from.
The table is 16K in size and can be positioned on 16K boundaries. Bits 2-0
of this register correspond to bits 16-14 of the VRAM address.
As there is only 64K of VRAM, bit 2 has no effect. Pattern data read from
$10000-$1FFFF is instead read from $00000-$0FFFF due to mirroring.
When a sprite has bit 8 of it's name field set so that it reads patterns
out of the upper 8K of the 16K table (tiles 256-511), bits 4, 3 of this
register are added to bits 14 and 13 of the VRAM address.
If the resulting address is bigger than $10000 then data is read from
$00000 onwards due to mirroring. The same holds true if the address is
bigger than $20000, due to wrapping.
The sprite sizes are as follows:
D7 D6 D5 Small Large
0 0 0 8x8 16x16
0 0 1 8x8 32x32
0 1 0 8x8 64x64
0 1 1 16x16 32x32
1 0 0 16x16 64x64
1 0 1 32x32 64x64
1 1 0 16x32 32x64
1 1 1 16x32 32x32
The last two settings are undocumented but appear to function normally.
Overview
The CPU interface to the OAM appears as a 1024-byte array. Here's a memory
map:
$0000-$01FF : 512 bytes, used as 128 x 4-byte entries
$0200-$03FF : 32 bytes, mirrored every 32 bytes (so mirrored 16 times)
Reading and writing from the mirrored areas are valid.
OAM access
The PPU has a 10-bit address register which gives a byte offset into OAM.
Writing to $2102 will load the CPU data into bits 8-1 of the address
register. Writing to $2103 will load bit 0 of the CPU data into bit 9 of
the address register. Writing to $2102 or $2103 will clear bit 0 of the
address register so an even address is always selected. You can write to
$2102 and $2103 in any order, or write to just one or the other to update
part or all of the address.
Each time $2138 is read, the byte at the current offset pointed to by the
address register is returned to the CPU, and the address register is
incremented by one.
Each time $2104 is written to the address register is incremented by one.
If the address register is even during a write, the CPU data is stored in
a latch. If the address register is odd, the latched data becomes the LSB
and the new data written becomes the MSB of a 16-bit word. This word is
written to the current address, with bit 0 of the address register ignored.
This only affects writing to offsets $0000-$01FF. The 32 byte table at
$0200-$03FF will be updated for a write to even or odd addresses. Writes
to even addresses still update the LSB latch, however.
The address register will wrap from $03FF to $0000 due to reading $2138 or
writing to $2104. You can mix reads and writes freely.
Valid access times
When the screen is forcibly blanked or in the V-Blank period, OAM can be
read and written. I haven't tested access during H-Blank yet.
It would seem that the address register is used for some internal operation
during the active display period, which involves incrementing it. Here are
my observations:
- Writing to OAM during this time results in the data being written to
consecutively larger addresses, starting at a random offset and with
a random amount of skipped bytes between the data. The address register
has no effect on where the data goes.
- Reading from OAM returns data from consecutively larger addresses,
starting at a random offset and with a random amount of skipped bytes
between the data. The address register has no effect on where the data
goes.
- Setting the address register to a known value and waiting a few scanlines
with the screen turned on results in data being read or written to a
larger address than the one originally set.
- Writing to the address register on the same scanline where a sprite is
being displayed has no effect on the sprite. I would assume during the
active display period, the address register can't be updated by the CPU
as it is being used by the PPU exclusively.
OAM access examples
Here are some examples of unexpected behavior. Assume OAM contains the
bytes $AA, $BB, $CC, $DD at address $0000 for each test:
- Set address to $0000
- Write $45
OAM is not updated, and the LSB latch contains $45
- Set address to $0000
- Read $2138
- Write #$45
The bytes $CC, $45 are written to address $0000. $CC was the last value
in the LSB latch, and a single byte write triggers a write to OAM as the
previous read made the address register odd.
- Set address to $0000
- Write #$12
- Write #$00 to $2103
- Write #$34
OAM is not updated. The second write only loads the LSB latch as the
write to $2103 cleared bit 0 of the address register.
----------------------------------------------------------------------------
Hardware version registers
----------------------------------------------------------------------------
Here are the version register return values and chip markings for my
original model NTSC SNES:
Register Value Chip
$4210 $01 Nintendo S-CPU 5A22-01
$213E $01 Nintendo S-PPU1 5C77-01
$213F $01 Nintendo S-PPU2 5C78-01
----------------------------------------------------------------------------
I/O hardware
----------------------------------------------------------------------------
The SNES has two 7-pin joypad ports. Here's a diagram of the faceplate of
the SNES to show the pin configuration:
1P port 2P port
(Power light) ( o o o | o o o o ] [ o o o o | o o o )
7 6 5 4 3 2 1 1 2 3 4 5 6 7
Pin # Description S-CPU pin (1P) S-CPU pin (2P)
Pin 1 +5V n/a n/a
Pin 2 Output strobe 35 36
Pin 3 Output 37 37 (common between both ports)
Pin 4 Serial input 1 32 28
Pin 5 Serial input 2 33 27
Pin 6 Bidirectional 25 26
Pin 7 Ground n/a n/a
Each pin is accessible through the various hardware registers as follows:
1P port
- Read $4016 to pulse pin 2.
- Writing to bit 0 of $4016 controls pin 3.
- Reading bit 0 of $4016 returns data from pin 4.
- Reading bit 1 of $4016 returns data from pin 5.
- Pin 6 is connected to bit 6 of $4201 (WRIO) and $4213 (RDIO).
2P port
- Read $4017 to pulse pin 2.
- Writing to bit 0 of $4016 controls pin 3.
- Reading bit 0 of $4017 returns data from pin 4.
- Reading bit 1 of $4017 returns data from pin 5.
- Pin 6 is connected to bit 7 of $4201 (WRIO) and $4213 (RDIO).
2P pin 6 is also connected to S-PPU2 pin 29. This is most likely the
external input signal that can be used to latch the H/V counter. A lightgun
such as the Super Scope or Konami Justifier would use pulse pin 6 of the 2P
port to make the PPU2 latch the H/V counter when it detects the raster beam.
The second serial input from pin 5 and bidirectional pin 6 are unused by
the joypad and mouse. The Hudson Super Multitap may be the only peripheral
to use them, see the multitap section for more details.
The standard way most peripherals work is to write 1 then 0 to bit 0 of
$4016 to reset the devices in the 1P and 2P ports. You can then read bit 0
of $4016 and $4017 multiple times to return data serially, starting with
the MSB down to the LSB.
I/O port
The SNES is described as having an 8-bit bidirectional I/O port. I don't
know if this physically corresponds to the expansion port on the bottom of
the control deck, or if the CPU just has an I/O port built in and some or
all of the port pins are used.
Writing to $4201 (WRIO) sets the data to be output through the I/O port.
Any bit that is also set to 1 will allow the corresponding pin to act
as an input, and data from that pin can be read through $4213 (RDIO).
The only uses I know of for the I/O port are as follows:
- Any value written to $4201 can be read back through $4213.
- As bit 7 of $4201 controls pin 6 of the 2P port, which is also shared with
the external signal input of the PPU to latch the H/V counter, writing 1
then 0 to bit 7 of $4201 will latch the H/V counter.
While bit 7 is set to 0, the latch will always hold the same value and
reading $2137 will not change the latched value. If you want to poll
the H/V counter using $2137, set bit 7 back to 1 for it to work properly.
- Pin 6 of the 1P or 2P port is used as an output to control the Hudson
Super Multitap. See the multitap section for more details.
----------------------------------------------------------------------------
Automatic reading
----------------------------------------------------------------------------
The SNES has a feature to automatically read the four serial input pins
and store them into a set of registers during V-Blank. This can be done
without the CPU having to manually write and read $4016 / $4017, saving
time for other tasks.
When bit 0 of $4200 is set, at the start of V-Blank (depending on the screen
height) the SNES will automatically do the following steps:
- Write 1 then 0 to bit 0 of $4016.
- Read $4016 and $4017 sixteen times, storing the return values from bits
0 and 1 into eight registers like so:
- 16 bits from bit 0 of $4016 are stored in $4218 (LSB) and $4219 (MSB)
- 16 bits from bit 1 of $4016 are stored in $421C (LSB) and $421D (MSB)
- 16 bits from bit 0 of $4017 are stored in $421A (LSB) and $421B (MSB)
- 16 bits from bit 1 of $4017 are stored in $421E (LSB) and $421F (MSB)
This process takes three scanlines to complete. Bit 0 of $4212 shows the
scanning status, where 1= the SNES is still reading data, 0= the SNES has
finished or automatic scanning was not enabled.
The use I've seen in games and demos is to wait for this bit to be set, and
then cleared in the NMI handler.
----------------------------------------------------------------------------
Hudson Super Multitap
----------------------------------------------------------------------------
The multitap plugs into the 1P or 2P port. It has four connectors to plug
additional joypads into, and has a switch for selecting a multiplayer or
compatability mode.
In compatability mode (switch = 2P) the joypad plugged in to connector #1
works like a standard pad. All remaining connectors are ignored, pin 6
is ignored in terms of selecting which set of joypad data to return, and
no extra data is returned in the second serial input.
In multiplayer mode (switch = 3P-5P) the first serial input returns data
from the joypad in connector #1 or #3, and the second serial input returns
data from the joypad in connector #2 or #4. Pin 6 of the 1P or 2P port
is used to select connectors #1 and #3 when set to 1, or #2 and #4 when
set to 0.
----------------------------------------------------------------------------
SNES joypad
----------------------------------------------------------------------------
The SNES joypad uses two 4021 ICs, which are 8-stage static shift registers.
They are cascaded together to form a 16-bit shift register that stores the
state of the directional pad and buttons, allowing the SNES to read out
the state of the joypad serially.
The button states will be loaded into the shift register when bit 0 of
$4016 is set to 1 and then 0. This happens to both control pads as they
share a common pin. Each time $4016 or $4017 is read, the shift register
for the 1P or 2P pad advances by one, outputting a bit which can be read
in bit 0 of $4016 or $4017 respectively.
The tail end of the shift register is filled with a one on each shift. After
the sixteenth time $4016 or $4017 has been read, all consecutive reads will
return one due to the shift register being completely filled with ones.
This will go on forever until the shift register is loaded again by writing
1 then 0 to $4016.
If at any time $4016 is left at 1, reading either joypad will always return
the state of the first input, which is the 'B' button. This won't stop until
$4016 is set to zero again.
Here is the order of button states read out through $4016 or $4017:
Read 1 - Button B Read 9 - Button A
Read 2 - Button Y Read 10 - Button X
Read 3 - Button Select Read 11 - Button L
Read 4 - Button Start Read 12 - Button R
Read 5 - Up Read 13 - '0'
Read 6 - Down Read 14 - '0'
Read 7 - Left Read 15 - '0'
Read 8 - Right Read 16 - '0'
All reads after read 16 will return 1.
All buttons are 1= pressed, 0= released.
If no joypad is plugged in, then zero is always read from $4016 or $4017.
A game can check if a joypad is connected by seeing if any reads beyond
the 16th one return '1', otherwise there is no joypad.
As far as I can tell, the joypad does not return any data through pin 5
(which always returns zero) and any setting of pin 6 will not affect the
joypad operation.
----------------------------------------------------------------------------
SNES mouse
----------------------------------------------------------------------------
The SNES mouse works in a similar fashion to the joypad. It has a custom
18-pin chip called the "SFM1" which returns data about the mouse status
serially to the SNES.
Writing 1, then 0 to bit 0 of $4016 will reset the SFM1 and subsequent reads
from $4016 or $4017 (depending on which port the mouse is plugged into) will
return the mouse state data. Leaving bit 0 of $4016 set to 1 will result
in zero always being read back.
The mouse data is as follows:
Read 1 - '0' Read 17 - Y sign
Read 2 - '0' Read 18 - Y movement bit 6 (?)
Read 3 - '0' Read 19 - Y movement bit 5
Read 4 - '0' Read 20 - Y movement bit 4
Read 5 - '0' Read 21 - Y movement bit 3
Read 6 - '0' Read 22 - Y movement bit 2
Read 7 - '0' Read 23 - Y movement bit 1
Read 8 - '0' Read 24 - Y movement bit 0
Read 9 - Right button Read 25 - X sign
Read 10 - Left button Read 26 - X movement bit 6 (?)
Read 11 - '0' Read 27 - X movement bit 5
Read 12 - '0' Read 28 - X movement bit 4
Read 13 - '0' Read 29 - X movement bit 3
Read 14 - '0' Read 30 - X movement bit 2
Read 15 - '0' Read 31 - X movement bit 1
Read 16 - '1' Read 32 - X movement bit 0
All reads after read 32 will return 1.
The left/right buttons are 1= pressed, 0= released.
The Y and X sign are 1= up/left movement, 0= down/right movement. The sign
bits do not change until the mouse is moved in a opposite direction. So
moving the mouse up, and leaving it stationary would keep the Y sign bit
set to 1.
The Y and X movement fields indicate how rapidly the mouse was moved in a
particular direction. This is usually $00-$1F, but extremely rapid movements
can yield higher values. I haven't been able to get values large enough
to indicate there is a seventh movement bit, but there may likely be one.
Both fields are zero when there is no movement.
As far as I can tell, the mouse does not return any data through pin 5
(which always returns zero) and any setting of pin 6 will not affect the
mouse operation.
----------------------------------------------------------------------------
Register reference
----------------------------------------------------------------------------
$2180 - WRAM data port
$2181 - WRAM offset (bits 7-0 are offset bits 7-0)
$2182 - WRAM offset (bits 7-0 are bits 15-8)
$2183 - WRAM offset (bit 0 is offset bit 16, bits 7-1 are unused)
Registers $2181-$2183 define a 17-bit offset in WRAM. Reading or writing
$2180 will return a byte from or write a byte to WRAM, and automatically
increment the WRAM offset by one. The offset wraps from $01FFFF to $000000.
Reading $2180, $2181, or $2183 returns the last value on the data bus,
which is usually the last byte of the opcode fetched. For example, this
value would be $21 for 'lda $2181', or $00 for 'lda [$00]' when the pointer
at $00 is $2181.
----------------------------------------------------------------------------
Cartridge information
----------------------------------------------------------------------------
Cartridge pinout
Solder side Component side
MCK - 01 32 - /RAMSEL
EXPAND - 02 33 - REFRESH
PA6 - 03 34 - PA7
/PARD - 04 35 - /PAWR
<key>
GND - 05 36 - GND
A11 - 06 37 - A12
A10 - 07 38 - A13
A9 - 08 39 - A14
A8 - 09 40 - A15
A7 - 10 41 - A16
A6 - 11 42 - A17
A5 - 12 43 - A18
A4 - 13 44 - A19
A3 - 14 45 - A20
A2 - 15 46 - A21
A1 - 16 47 - A22
A0 - 17 48 - A23
/IRQ - 18 49 - /ROMSEL
D0 - 19 50 - D4
D1 - 20 51 - D5
D2 - 21 52 - D6
D3 - 22 53 - D7
/RD - 23 54 - /WR
CIC0 - 24 55 - CIC1
CIC2 - 25 56 - CIC3
/RESET - 26 57 - SYSCK
+5V - 27 58 - +5V
<key>
PA0 - 28 59 - PA1
PA2 - 29 60 - PA3
PA4 - 30 61 - PA5
SOUND-L - 31 62 - SOUND-R
Pin assignments
A23-0 - CPU address bus
D7-0 - CPU data bus
/WR - CPU write strobe
/RD - CPU read strobe
/IRQ - CPU IRQ input. Allows on-cart hardware to interrupt the CPU.
/RESET - When the system is reset (power-up or hard reset) this goes low.
Could be used to reset additional on-cart hardware.
/RAMSEL - Goes low on accesses to WRAM at the following addresses:
00-3F:0000-1FFF
80-BF:0000-1FFF
7E-7F:0000-FFFF
/ROMSEL - Goes low on access to cartridge ROM at the following addresses:
00-3F:8000-FFFF
40-7D:0000-FFFF
80-BF:8000-FFFF
C0-FF:0000-FFFF
PA7-0 - Address bus for $2100-$21FF range in banks $00-$3F/$80-$BF (B-Bus)
/PAWR - Write strobe for B-Bus
/PARD - Read strobe for B-Bus
MCK - 21.47727 MHz master clock
SYSCK - Unknown, is an output from the CPU.
SOUND-L - Audio input to be mixed with left channel output
SOUND-R - Audio input to be mixed with right channel output
THROUGH - Connected to pin 24 of the expansion port.
REFRESH - Unknown, is an output from the CPU also connected to WRAM.
This is most likely to manage DRAM refresh.
CIC3-0 - To CIC chip on cartridge
Details
For more information about the CIC chip, please see the following:
- U.S. Patent no. 4,799,635 (NES specific)
- http://home.freeuk.com/markk/Consoles/SNES_Lockout.txt
The only hardware I know of which uses the two sound input pins is the
Super Gameboy and Super Gameboy 2.
The SNES has two address busses, the A-Bus which is used by the CPU, ROM,
WRAM, etc. and the B-Bus which is used by the PPU1, PPU2, APU I/O ports,
and WRAM. When the SNES does DMA, it can transfer data from the A-Bus to
the B-Bus or vice-versa, but not to the same bus. This holds true even
for WRAM, which is connected to both the A-Bus and B-Bus.
I would guess the B-Bus signals are brought out to the cartridge connector
so any on-cart hardware could map it's own registers within that region,
allowing for DMA from the A-Bus to it. Exactly what range of B-Bus addresses
are open for expansion purposes is unknown.
Cartridge information
Here's some information about several cartridges I've examined:
Name: Lagoon
Board: SHVC-1A3B-12
Type: LoROM / 16 megabits / 8K SRAM
This cartridge has a 74LS139 for address decoding and a 8K SRAM chip.
00-1F:8000-FFFF : Program ROM
20-3F:8000-FFFF : Unmapped
40-6F:0000-FFFF : Unmapped
70-7D:0000-FFFF : SRAM
7E-7F:0000-FFFF : Work RAM
80-9F:8000-FFFF : Program ROM
A0-BF:8000-FFFF : Unmapped
C0-EF:0000-FFFF : Unmapped
F0-FF:0000-FFFF : SRAM
- A23 and A15 are ignored, so banks $80-FF are a mirror of $00-7F.
- SRAM is mirrored repeatedly in the areas it's assigned to.
- When accessing an unmapped region, neither the ROM or SRAM are enabled.
Name: Pilotwings
Board: SHVC-1BON-02
Type: LoROM / 8 megabits / DSP-1
This cartridge has a 74LS139 for address decoding and a NEC uPD77C25 DSP
which Nintendo labels as the "DSP-1" custom chip. It also has a oscillator
and 74HCU04 to provide a clock signal, but I don't know what speed the DSP
actually runs at.
00-1F:8000-FFFF : Program ROM
20-2F:8000-FFFF : Unmapped
30-3F:8000-BFFF : DSP data register (r/w)
30-3F:C000-FFFF : DSP status register (r/o)
40-7D:0000-FFFF : Unmapped
7E-7F:0000-FFFF : Work RAM
80-9F:8000-FFFF : Program ROM
A0-AF:8000-FFFF : Unmapped
80-BF:8000-BFFF : DSP data register (r/w)
80-BF:C000-FFFF : DSP status register (r/o)
C0-FF:0000-FFFF : Unmapped
- A23 and A15 are ignored, so banks $80-FF are a mirror of $00-7F.
- DSP pins INT, SCK, /SIEN, /SOEN are all tied to +5V and are unused.
- When accessing an unmapped region, neither the ROM or DSP are enabled.
Name: Killer Instinct
Board: SHVC-1JON-20
Type: HiROM / 32 megabits
The mask ROM socket on the PCB has the following pin assignments:
+---\/---+
A20 -|01 36|- +5V
A21 -|02 35|- A23
A17 -|03 34|- +5V
A18 -|04 33|- /ROMSEL (ROM /CS)
A15 -|05 32|- A19
A12 -|06 31|- A14
A7 -|07 30|- A13
A6 -|08 29|- A8
A5 -|09 28|- A9
A4 -|10 27|- A11
A3 -|11 26|- A16
A2 -|12 25|- A10
A1 -|13 24|- /RD (ROM /OE)
A0 -|14 23|- D7
D0 -|15 22|- D6
D1 -|16 21|- D5
D2 -|17 20|- D4
GND -|18 19|- D3
+--------+
- A22 is unconnected.
- This game uses a MX23C3201 4096Kx8 mask ROM. I can't find a datasheet for
this chip, so I'm not sure what pin 35 (A23) is used for. It could be
an inverted chip select so the ROM is only mapped to banks $40-$7E and
$C0-$FF, but that's just a guess.
----------------------------------------------------------------------------
Assistance needed
----------------------------------------------------------------------------
If any games have a legitimate use of writing to OAM or reading OAM or CGRAM
during the active display period, I'd like to hear about the details of how
the data is used. So far it's been confirmed that Uniracers writes to OAM
this way, maybe there are others.
----------------------------------------------------------------------------
Credits and acknowlegements
----------------------------------------------------------------------------
- ToToTek Multimedia for the Game Doctor SF7. (www.tototek.com)
- neviksti for the SNES starter kit. (available at nesdev.parodius.com)
- John Weidman, CaitSith2, neviksti, for the SNES schematic scans.
- Gilligan for the SNES documentation.
- Qwertie for the SNES documentation.
- anomie for the post about SNES peripherals at the SNES9X development forum,
pointing out errors, and suggesting tests.
- Overload for clarifying some details about the mouse.
- Chris MacDonald for testing and support.
----------------------------------------------------------------------------
Disclaimer
----------------------------------------------------------------------------
If you use any information from this document, please credit me
(Charles MacDonald) and optionally provide a link to my webpage
(http://cgfm2.emuviews.com/) so interested parties can access it.
The credit text should be present in the accompanying documentation of
whatever project which used the information, or even in the program
itself (e.g. an about box).
Regarding distribution, you cannot put this document on another
website, nor link directly to it.

175
files/docs/snes/tile_format.txt Normal file
View File

@ -0,0 +1,175 @@
----------------------------
By DAX on 28/2/93
This is a short text file on how the data for the gfx on the SNES are
set up..
Everything is based around an 8x8 pixel 'Tile' and thinking in terms of
tiles makes the whole thing a lot easier.
4 Colour mode - 2 Bitplanes
---------------------------
If you split the screen into 8x8 pixel tiles, the order of the graphics data
is tile 0,1,2,3,4 etc.(with tile 0 being the first, and 1 being the one on
the right of it.)
Then for each tile, the data is stored as shown below.
00 01 02 03 04 05 06 07
10 11 12 13 14 15 16 17 Each number representing one pixel in
20 21 22 23 24 25 26 27 the 8x8 tile.
30 31 32 33 34 35 36 37
40 41 42 43 44 45 46 47
50 51 52 53 54 55 56 57
60 61 62 63 64 65 66 67
70 71 72 73 74 75 76 77
The data is stored in the SNES binary in the following format.
Bitplane 0 .. Line 00-07 (One Byte)
Line 10-17
Line 20-27
Line 30-37
Line 40-47
Line 50-57
Line 60-67
Line 70-77
then Bitplane 1 .. Line 00-07
Line 10-17
Line 20-27
Line 30-37
Line 40-47
Line 50-57
Line 60-67
Line 70-77
then comes the data for the next tile (the one on the right).etc.
16 Colour - 4 Bitplanes
-----------------------
The data for this mode is stored in the same format, with one main change.
The data is stored in the format
Bitplane 0 .. Line 00-07
|
Line 70-77
Bitplane 1 .. Line 00-07
|
Line 70-77
Bitplane 2 .. Line 00-07
|
Line 70-77
Bitplane 3 .. Line 00-07
|
Line 70-77
then the data for the next tile.
256 Colour - 8 Bitplanes
------------------------
This is simply an expansion of the 4 and 16 colour modes.
Bitplane 0 .. Line 00-07
|
Line 70-77
Bitplane 1 .. Line 00-07
|
Line 70-77
Bitplane 2 .. Line 00-07
|
Line 70-77
Bitplane 3 .. Line 00-07
|
Line 70-77
Bitplane 4 .. Line 00-07
|
Line 70-77
Bitplane 5 .. Line 00-07
|
Line 70-77
Bitplane 6 .. Line 00-07
|
Line 70-77
Bitplane 7 .. Line 00-07
|
Line 70-77
then the data for the next tile.
256 Colours - Mode 7 format
---------------------------
This has some very major differences to the other graphics data formats
there are two mode7 modes, normal and EXTBG, the data is stored in the
same way in both, apart from in EXTBG the Bitplane 7 value will be a
priority bit for the pixel, which cuts the colours down to 128.
Each byte of 'graphics data' is actually the colour value for that pixel
on the screen, so if the value is 64, then the colour of that pixel will
be the contents of colour register 64.
The data is stored in VRAM differently to the other modes, with the tile
numbers, and the graphics data 'interleaved', starting at $0000 in VRAM,
with alternate bytes containing one byte of tile, one byte of gfx - this
is shown below.
Word of VRAM. HI LO
Bit 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
content |------------------------------||------------------------------|
Graphics data(CHAR DATA) Tile number(NAME)
Because of the storing of 16 bit data in reverse format (LO-HI) this means
that if you set the VRAM addr to $0.the first byte written should be the
tile name for that position on screen and the second byte should be the first
byte of the Mode7 graphics data.if the VRAM addr is set to $1 the first byte
written will be the tile name for that position on scr, and the second byte
should be the second byte of the mode7 graphics data.
ETC
In mode7 you can only have a maximum of 256 tiles, because of the fact that
the mode7 data only takes up the first half of VRAM(32k) you can only have 16k
of graphics data which is 256 tiles of 8x8 with 256 colours.
This is quite a limitation, but can be used quite effectively.
The tile numbers are stored in a format according to a 128x128 tile screen
so tile 128($80) would be the tile below 0($0) on the screen, and so on.
so VRAM addr $0 is the top left tile, and $1 is the one on the right of it
$80 is the one on the left side, one row down.
the graphics data is stored based on an 8x8 tile again.
but slightly different.
Each byte(pixel) is stored so...
Bit number Contents
0 Bitplane 0 pixel value
1 Bitplane 1 pixel value
2 Bitplane 2 pixel value
3 Bitplane 3 pixel value
4 Bitplane 4 pixel value
5 Bitplane 5 pixel value
6 Bitplane 6 pixel value
7 Bitplane 7 pixel value /
(EXTBG mode - Priority value)
The data is then stored in the sequence
00,01,02,03,04,05,06,07
10,11,12,13,14,15,16,16 (Look at diagram at start of file
| | | for explanation)
70,71,72,73,74,75,76,77
with one byte for each position(pixel), according to the 8x8 tile format,
with one tile after another.
---------------------------------------------------------------------------
I hope this text file helps those of you having trouble converting graphics
for use on the SNES, I have been asked a few times recently for this info
so I decided to type up this short text file on it.
Hopefully it should explain it!
If you have any further questions contact :-
Dax or Corsair

188
files/docs/snes/tiles.txt Normal file
View File

@ -0,0 +1,188 @@
[Image]
SNES Screen Format
[Image]
SNES GRAPHICS INFO FILE V1.0
----------------------------
By DAX on 28/2/93
This is a short text file on how the data for the gfx on the SNES are
set up..
Everything is based around an 8x8 pixel 'Tile' and thinking in terms of
tiles makes the whole thing a lot easier.
4 Colour mode - 2 Bitplanes
---------------------------
If you split the screen into 8x8 pixel tiles, the order of the graphics data
is tile 0,1,2,3,4 etc.(with tile 0 being the first, and 1 being the one on
the right of it.)
Then for each tile, the data is stored as shown below.
00 01 02 03 04 05 06 07
10 11 12 13 14 15 16 17 Each number representing one pixel in
20 21 22 23 24 25 26 27 the 8x8 tile.
30 31 32 33 34 35 36 37
40 41 42 43 44 45 46 47
50 51 52 53 54 55 56 57
60 61 62 63 64 65 66 67
70 71 72 73 74 75 76 77
The data is stored in the SNES binary in the following format.
Bitplane 0 .. Line 00-07 (One Byte)
Line 10-17
Line 20-27
Line 30-37
Line 40-47
Line 50-57
Line 60-67
Line 70-77
then Bitplane 1 .. Line 00-07
Line 10-17
Line 20-27
Line 30-37
Line 40-47
Line 50-57
Line 60-67
Line 70-77
then comes the data for the next tile (the one on the right).etc.
16 Colour - 4 Bitplanes
-----------------------
The data for this mode is stored in the same format, with one main change.
The data is stored in the format
Bitplane 0 .. Line 00-07
|
Line 70-77
Bitplane 1 .. Line 00-07
|
Line 70-77
Bitplane 2 .. Line 00-07
|
Line 70-77
Bitplane 3 .. Line 00-07
|
Line 70-77
then the data for the next tile.
256 Colour - 8 Bitplanes
------------------------
This is simply an expansion of the 4 and 16 colour modes.
Bitplane 0 .. Line 00-07
|
Line 70-77
Bitplane 1 .. Line 00-07
|
Line 70-77
Bitplane 2 .. Line 00-07
|
Line 70-77
Bitplane 3 .. Line 00-07
|
Line 70-77
Bitplane 4 .. Line 00-07
|
Line 70-77
Bitplane 5 .. Line 00-07
|
Line 70-77
Bitplane 6 .. Line 00-07
|
Line 70-77
Bitplane 7 .. Line 00-07
|
Line 70-77
then the data for the next tile.
256 Colours - Mode 7 format
---------------------------
This has some very major differences to the other graphics data formats
there are two mode7 modes, normal and EXTBG, the data is stored in the
same way in both, apart from in EXTBG the Bitplane 7 value will be a
priority bit for the pixel, which cuts the colours down to 128.
Each byte of 'graphics data' is actually the colour value for that pixel
on the screen, so if the value is 64, then the colour of that pixel will
be the contents of colour register 64.
The data is stored in VRAM differently to the other modes, with the tile
numbers, and the graphics data 'interleaved', starting at $0000 in VRAM,
with alternate bytes containing one byte of tile, one byte of gfx - this
is shown below.
Word of VRAM. HI LO
Bit 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
content |------------------------------||------------------------------|
Graphics data(CHAR DATA) Tile number(NAME)
Because of the storing of 16 bit data in reverse format (LO-HI) this means
that if you set the VRAM addr to $0.the first byte written should be the
tile name for that position on screen and the second byte should be the first
byte of the Mode7 graphics data.if the VRAM addr is set to $1 the first byte
written will be the tile name for that position on scr, and the second byte
should be the second byte of the mode7 graphics data.
ETC
In mode7 you can only have a maximum of 256 tiles, because of the fact that
the mode7 data only takes up the first half of VRAM(32k) you can only have 16k
of graphics data which is 256 tiles of 8x8 with 256 colours.
This is quite a limitation, but can be used quite effectively.
The tile numbers are stored in a format according to a 128x128 tile screen
so tile 128($80) would be the tile below 0($0) on the screen, and so on.
so VRAM addr $0 is the top left tile, and $1 is the one on the right of it
$80 is the one on the left side, one row down.
the graphics data is stored based on an 8x8 tile again.
but slightly different.
Each byte(pixel) is stored so...
Bit number Contents
0 Bitplane 0 pixel value
1 Bitplane 1 pixel value
2 Bitplane 2 pixel value
3 Bitplane 3 pixel value
4 Bitplane 4 pixel value
5 Bitplane 5 pixel value
6 Bitplane 6 pixel value
7 Bitplane 7 pixel value /
(EXTBG mode - Priority value)
The data is then stored in the sequence
00,01,02,03,04,05,06,07
10,11,12,13,14,15,16,16 (Look at diagram at start of file
| | | for explanation)
70,71,72,73,74,75,76,77
with one byte for each position(pixel), according to the 8x8 tile format,
with one tile after another.
---------------------------------------------------------------------------
I hope this text file helps those of you having trouble converting graphics
for use on the SNES, I have been asked a few times recently for this info
so I decided to type up this short text file on it.
Hopefully it should explain it!
[Image]
© 1996 Damaged Cybernetics
[Image]

74
files/docs/snes/vram.txt Normal file
View File

@ -0,0 +1,74 @@
From: vic@physci.psu.edu (Vic Ricker)
To: "Super Famicom Development Group" <famidev@busop.cit.wayne.edu>
Subject: Re: some programming questions
Date: Tue, 9 Nov 93 20:20:35 EST
>Hi Folks.
>I need help with a few SNES programming questions...
>(1) Can anyone tell me how to make noises come out of my SNES?
Insert your favorite cart, power up the TV, switch the snes power to
ON.. :-)
>(3) Is the sprite position table held in RAM or VRAM? And how
> do the 5 address bits in $2101 relate to this location?
The sprite images are stored in VRAM. The palettes for the sprites
are stored in CGRAM. The coordinates and char attributes are stored
in OAM.
The format of each OBJ is:
OBJ H position: 8 bits
OBJ V position: 8 bits
V flip: 1 bit
H flip: 1 bit
OBJ priority: 2 bits
color palette: 3 bits
character name: 9 bits
there are 128 of these in sequence making 512 bytes then 32 bytes
follow in the format:
size: 1 bit
x msb: 1 bit
there are 128 of these (one for every OBJ) making 32 more bytes.
$2101 is OBJSEL
it chooses the size of sprites to use and also sets the address of the
images in VRAM. the top 3 bits chose the size:
000 means 8x8 and 16x16 sprites
001 8x8 and 32x32
010 8x8 and 64x64
011 16x16 and 32x32
100 16x16 and 64x64
101 32x32 and 64x64
the other bits are the address in vram of the sprite images.
$2102-$2103 is OAMADDL/H
the lower 9 bits are the address for accessing the OAM. (like $2116
for VRAM)
the high bit (15) enables priority rotation (causes OBJ's to change
priority as to keep them from disappearing totally when time out and range
over occur.)
$2104 is OAMDATA
it is the write register for the OAM. (like $2118-$2119 for VRAM)
$2138 is *OAMDATA
it is the read register for the OAM.
Hope this gives you enough to play with. Most is from memory, I hope
its all correct. :-)
Lemme know if you have questions.

BIN
files/docs/snes/w65c816s.pdf Normal file
View File

Binary file not shown.

3354
files/docs/snes/wla_doc.txt Normal file
View File

File diff suppressed because it is too large Load Diff

27
files/docs/snes/yoshi/READ.ME Normal file
View File

@ -0,0 +1,27 @@
*****************************************************************************
SNES Documentation v2.30: Written by Yoshi
*****************************************************************************
Previous version: v2.21
The follow files are included (or should be!) in this archive:
[* = Updated since previous version]
* snes.0.............Introduction
* snes.1.............SNES Register section
* snes.2.............SNES Colour section
* snes.3.............SNES Graphics section
* snes.4.............SNES Screen-mode section
* snes.5.............SNES OAM/Sprite section
* snes.6.............Super Magicomm disk registers
-=NEW=- snes.7.............SNES Memory map
-=NEW=- snes.8.............Those boring credits/thank-yous/hellos! :-)
sound.doc..........SPC-700 (sound) documentation by Antitrack
sprite.doc.........OBJ/OAM documentation
-=NEW=- test.lzh...........Mini "demo" by yours-truly. Comes with source,
music, graphics, and the SMC file.
-=NEW=- sid-spc.src........C64 sound emulator documentation/code by Antitrack
*****************************************************************************
All sections are formatted using whitespaces vs. actual tab characters. This
is due to the fact that some people have their tabs set to 4 or 5 spaces
rather than the vi-standard of 8.
'sound.doc', 'sprite.doc', and 'sid-spc.src' are not formatted this way.

1072
files/docs/snes/yoshi/SID-SPC.SRC Normal file
View File

File diff suppressed because it is too large Load Diff

70
files/docs/snes/yoshi/SNES.0 Normal file
View File

@ -0,0 +1,70 @@
_________________ _________________ _________________ _________________
| || || || |
| || || || |
| __________|| || _________|| ___________|
| | | || / |
| || | || / | |
__________ || | || ___/_____ ___________ |
| || | || || |
| || | || || |
|_________________||________|________||_________________||_________________|
****************************************************************************
SNES Documentation v2.30: Written by Yoshi
****************************************************************************
Well, seems like you're interested in the SNES programming world.
First off, learn 65c816 assembly. This document will probably be
WAY over your head if you don't even understand basic opcodes. I
don't plan on adding a "how.to.code.in.65c816" section to this
document, *EVER*. Learn it yourself. I can help you with it, but
you need to learn the basics yourself. It's worth it in the long-
run, trust me.
This document currently covers more than ANY other document i've
ever seen: No, i'm not bragging. I'm stating a fact. I'm proud to be
the one to release this information, too. I feel everyone has the
right to know about all of this, especially if they're interested in
getting a career in the SNES-world.
If you have any information to send me, such as typo comments, or
information which is "wrong" or *NEW* information, do so! I'm always
updating this thing: the more the better. It's looking great so
far, and I plan on keeping the rate-of-progress steady.
For more information about moi, read on! :-)
****************************************************************************
I'm 17 years old; brown hair, blue/grey eyes. 5 foot 10 inches
tall (175cm), 145 pounds (62.25kg). I am currently in my 5th
year of high school (I failed my senior year), attending Corvallis
High School in Corvallis, Oregon.
I'm currently without a job, but i'd love to do development work
in a CS-related job, ESPECIALLY SNES-related. I'm available! :-)
In my spare time, I enjoy writing stories (books, if you must know.
I love writing, so...), SNES documentation (ha ha ha), programming
(in just about anything and everything), biking, sleeping, sketch-
ing, and IRCing. You can *ALWAYS* find me on IRC at just about ANY
time of the day. Leave me a /MSG -info note (which is sent to me
via EMail, FYI), and i'll get it when I log in to check my mail.
As of January 24th, 1995, I will be 18 years old. I'm not employed
(vs. unemployed, where you've actually HAD a job). Dunno what'll
happen to me. Maybe i'll die. Who knows. I hope to move in with
a good friend of mine, but i'm too chicken to ask. I'd rather be
out on the street w/out foot than be told "No you can't" - it's a
huge flaw in my philosophy... Sorry.
You can reach via the following ways:
InterNET: yoshi@CSOS.ORST.EDU (fast, and is preferred)
yoshi@drift.winternet.com
IRC: Yoshi
Phone: 1+ 503-753-2431
SnailMail: Jeremy Chadwick
33811 Twin Maple Lane
Corvallis, OR 97333
USA
****************************************************************************
December 28th, 1994
- Yoshi

606
files/docs/snes/yoshi/SNES.1 Normal file
View File

@ -0,0 +1,606 @@
----------------------------------------------------------------------------
|rwd2?|Address|Title & Explanation |
||||||-----------------------------------------------------------------------|
|||||| |
||||||__ ?: Don't know what the statistics on this register are |
|||||____ 2: 2 byte (1 word) length register |
||||_____ d: Double-byte write required when writing to this register |
|||______ w: Writable register |
||_______ r: Readable register |
| |
|Words in brackets ( [] ) are the official "names" of the registers |
|Words in braces ( {} ) are different from the "real" SNES manual |
|Bits define 1 as "ON/ENABLE" and 0 as "OFF/DISABLE," unless otherwise stated|
|Registers without any bits/defined-data can be assumed to be 8 bits in size |
|and should only be read once. |
|----------------------------------------------------------------------------|
|NOTE! I have renamed all occurances of "Plane {x}" to "BG{x+1}." This means |
|stuff like "Plane 2" is now referred to as "BG3" - This is how it is done |
|(so i'm told) in the official SNES documentation, so for compatibility and |
|comprehension, i've renamed everything. |
| |
|I have also renamed "Sprites" to "OBJ", "objects," or "OAM" for the same |
|reason that I renamed "Plane" to "BG." |
|----------------------------------------------------------------------------|
|rwd2?|Address|Title & Explanation |
|----------------------------------------------------------------------------|
| w |$2100 |Screen display register [INIDISP] |
| | |x000bbbb x: 0 = Screen on. |
| | | 1 = Screen off. |
| | | bbbb: Brightness ($0-$F). |
| | | |
| | | |
| w |$2101 |OAM size register [OBSEL] |
| | |sssnnbbb s: 000 = 8x8 or 16x16. |
| | | 001 = 8x8 or 32x32. |
| | | 010 = 8x8 or 64x64. |
| | | 011 = 16x16 or 32x32. |
| | | 100 = 16x16 or 64x64. |
| | | 101 = 32x32 or 64x64. |
| | | n: Name selection (upper 4k word addr). |
| | | b: Base selection (8k word seg. addr). |
| | | |
| | | |
| w 2 |$2102 |OAM address register [OAMADDL/OAMADDH] |
| | |aaaaaaaa r000000m a: OAM address. |
| | | r: OAM priority rotation. |
| | | m: OAM address MSB. |
| | | |
| | | |
| wd |$2104 |OAM data register [OAMDATA] |
| | |???????? ???????? |
| | | |
| | | |
| w |$2105 |Screen mode register [BGMODE] |
| | |abcdefff a: BG4 tile size (0=8x8, 1=16x16). |
| | | b: BG3 tile size (0=8x8, 1=16x16). |
| | | c: BG2 tile size (0=8x8, 1=16x16). |
| | | d: BG1 tile size (0=8x8, 1=16x16). |
| | | e: Highest priority for BG3 in MODE 1. |
| | | f: MODE definition. |
| | | |
| | | |
| w |$2106 |Screen pixelation register [MOSAIC] |
| | |xxxxabcd x: Pixel size (0=Smallest, $F=Largest). |
| | | a: Affect BG4. |
| | | b: Affect BG3. |
| | | c: Affect BG2. |
| | | d: Affect BG1. |
| | | |
| | | |
| w |$2107 |BG1 VRAM location register [BG1SC] |
| | |xxxxxxab x: Base address |
| | | ab: SC size |
| | | |
| | | |
| w |$2108 |BG2 VRAM location register [BG2SC] -| |
| w |$2109 |BG3 VRAM location register [BG3SC] |- Same as $2107. |
| w |$210A |BG4 VRAM location register [BG4SC] -| |
| | | |
| | | |
| w |$210B |BG1 & BG2 VRAM location register [BG12NBA] |
| | |aaaabbbb a: Base address for BG2. |
| | | b: Base address for BG1. |
| | | |
| | | |
| w |$210C |BG3 & BG4 VRAM location register [BG34NBA] |
| | |aaaabbbb a: Base address for BG4. |
| | | b: Base address for BG3. |
| | | |
| | | |
| wd |$210D |BG1 horizontal scroll register [BG1HOFS] |
| | |mmmmmaaa aaaaaaaa a: Horizontal offset. |
| | | m: Only set with MODE 7. |
| | | |
| | |This is an intruiging register. Like the types define, it has |
| | |to be written to twice: The first byte holds the first 8 bits,|
| | |and the second byte holds the last 3 bits. This makes a total |
| | |of 11 bits for information. This only proves true for MODes |
| | |0 to 6. MODE 7 uses 13 bits instead of 11. As long as you're |
| | |not in MODE 7, you can store $00 in the 2nd byte for a smooth |
| | |scrolling background. |
| | | |
| | | |
| wd |$210E |BG1 vertical scroll register [BG1VOFS] -| |
| wd |$210F |BG2 horizontal scroll register [BG2HOFS] | |
| wd |$2110 |BG3 vertical scroll register [BG2VOFS] | |
| wd |$2111 |BG3 horizontal scroll register [BG3HOFS] |- Same as $210D. |
| wd |$2112 |BG3 vertical scroll register [BG3VOFS] | |
| wd |$2113 |BG4 horizontal scroll register [BG4HOFS] | |
| wd |$2114 |BG4 vertical scroll register [BG4VOFS] -| |
| | | |
| | | |
| w |$2115 |Video port control [VMAIN] |
| | |i000abcd i: 0 = Addr-inc after writing to $2118 |
| | | or reading from $2139. |
| | | 1 = Addr-inc after writing to $2119 |
| | | or reading from $213A. |
| | | ab: Full graphic (see table below). |
| | | cd: SC increment (see table below). |
| | |abcd|Result |
| | |----|---------------------------------------------------------|
| | |0100|Increment by 8 for 32 times (2-bit formation). |
| | |1000|Increment by 8 for 64 times (4-bit formation). |
| | |1100|Increment by 8 for 128 times (8-bit formation). |
| | |0000|Address increments 1x1. |
| | |0001|Address increments 32x32. |
| | |0010|Address increments 64x64. |
| | |0011|Address increments 128x128. |
| | |----|---------------------------------------------------------|
| | | |
| | | |
| w 2 |$2116 |Video port address [VMADDL/VMADDH] |
| | |???????? ???????? |
| | | |
| | | |
| w 2 |$2118 |Video port data [VMDATAL/VMDATAH] |
| | |???????? ???????? |
| | | |
| | |According to bit 7 of $2115, the data can be stored as: |
| | | |
| | |Bit 7|Register |Result |
| | |-----|---------------------------|----------------------------|
| | | 0 |Write to $2118 only. |Lower 8-bits written then |
| | | | |address is increased. |
| | | 0 |Write to $2119 then $2118. |Address increased when both |
| | | | |are written to (in order). |
| | | 1 |Write to $2119 only. |Upper 8-bits written, then |
| | | | |address is increased. |
| | | 1 |Write to $2118 then $2119. |Address increased when both |
| | | | |are written to (in order). |
| | |-----|---------------------------|----------------------------|
| | | |
| | | |
| w |$211A |MODE7 settings register [M7SEL] |
| | |ab0000yx ab: (see table below). |
| | | y: Vertical screen flip (1=flip). |
| | | x: Horizontal screen flip (1=flip). |
| | | |
| | |ab|Result |
| | |--|-----------------------------------------------------------|
| | |00|Screen repetition if outside of screen area. |
| | |10|Character 0x00 repetition if outside of screen area. |
| | |11|Outside of screen area is back-drop screen in 1 colour. |
| | |--|-----------------------------------------------------------|
| | | |
| | | |
| w |$211B |COS (COSINE) rotate angle / X Expansion [M7A] |
| w |$211C |SIN (SIN) rotate angle / X Expansion [M7B] |
| w |$211D |SIN (SIN) rotate angle / Y Expansion [M7C] |
| w |$211E |COS (COSINE) rotate angle / Y Expansion [M7D] |
| wd |$211F |Center position X (13-bit data only) [M7X] |
| wd |$2120 |Center position Y (13-bit data only) [M7Y] |
| | | |
| | |MODE 7 formulae for rotation/enlargement/reduction: |
| | | |
| | |X2 = AB * X1-X0 + X0 |
| | |Y2 = CD * Y1-Y0 + Y0 |
| | | |
| | |A = COS(GAMMA)*(1/ALPHA) B = SIN(GAMMA)*(1/ALPHA) |
| | |C = SIN(GAMMA)*(1/BETA) D = COS(GAMMA)*(1/BETA) |
| | | |
| | | GAMMA: Rotation angle. |
| | | ALPHA: Reduction rates for X (horizontal). |
| | | BETA: Reduction rates for Y (vertical). |
| | |X0 & Y0: Center coordinate. |
| | |X1 & Y1: Display coordinate. |
| | |X2 & Y2: Coordinate before calculation. |
| | | |
| | | |
| w |$2121 |Colour # (or pallete) selection register [CGADD] |
| | |xxxxxxxx x: Address (color #). |
| | | |
| | | |
| wd |$2122 |Colour data register [CGDATA] |
| | |xxxxxxxx x: Value of colour. |
| | | |
| | |SNES colour is 15 bit; 5 bits for red, green, and blue. The |
| | |order isn't RGB though: It's BGR (RGB reversed!). |
| | | |
| | | |
| w |$2123 |Window mask settings register [W12SEL] |
| | |abcdefgh a: Disable/enable BG2 Window 2. |
| | | b: BG2 Window 2 I/O (0=IN). |
| | | c: Disable/enable BG2 Window 1. |
| | | d: BG2 Window 1 I/O (0=IN). |
| | | e: Disable/enable BG1 Window 2. |
| | | f: BG1 Window 2 I/O (0=IN). |
| | | g: Disable/enable BG1 Window 1. |
| | | h: BG1 Window 1 I/O (0=IN). |
| | | |
| | | |
| w |$2124 |Window mask settings register [W34SEL] |
| | |abcdefgh a: Disable/enable BG4 Window 2. |
| | | b: BG4 Window 2 I/O (0=IN). |
| | | c: Disable/enable BG4 Window 1. |
| | | d: BG4 Window 1 I/O (0=IN). |
| | | e: Disable/enable BG3 Window 2. |
| | | f: BG3 Window 2 I/O (0=IN). |
| | | g: Disable/enable BG3 Window 1. |
| | | h: BG3 Window 1 I/O (0=IN). |
| | | |
| | | |
| w |$2125 |Window mask settings register [WOBJSEL] |
| | |abcdefgh a: Disable/enable colour Window 2. |
| | | b: Colour Window 2 I/O (0=IN). |
| | | c: Disable/enable colour Window 1. |
| | | d: Colour Window 1 I/O (0=IN). |
| | | e: Disable/enable OBJ Window 2. |
| | | f: OBJ Window 2 I/O (0=IN). |
| | | g: Disable/enable OBJ Window 1. |
| | | h: OBJ Window 1 I/O (0=IN). |
| | | |
| | | |
| w |$2126 |Window 1 left position register [WH0] |
| | |aaaaaaaa a: Position. |
| | | |
| | | |
| w |$2127 |Window 1 right position register [WH1] -| |
| w |$2128 |Window 2 left position register [WH2] |- Same as $2126. |
| w |$2129 |Window 2 right position register [WH3] -| |
| | | |
| | |I may have the Window numbers reversed; as in, $2126 may be |
| | |for Window 2, not Window 1; $2127 may be for Window 2, not |
| | |Window 1... and so on... |
| | | |
| | | |
| w |$212A |Mask logic settings for Window 1 & 2 per screen [WBGLOG] |
| | |aabbccdd a: BG4 parms -| |
| | | b: BG3 parms |- See table in $212B. |
| | | c: BG2 parms | |
| | | d: BG1 parms -| |
| | | |
| | | |
| w |$212B |Mask logic settings for Colour Windows & OBJ Windows [WOBJLOG]|
| | |0000aabb a: Colour Window parms (see table below)|
| | | b: OBJ Window parms (see table below). |
| | | |
| | |Hi-bit|Lo-bit|Logic |
| | |------|------|------------------------------------------------|
| | | 0 | 0 |OR |
| | | 0 | 1 |AND |
| | | 1 | 0 |XOR |
| | | 1 | 1 |XNOR |
| | |------|------|------------------------------------------------|
| | | |
| | | |
| w |$212C |Main screen designation [TM] |
| | |000abcde a: OBJ/OAM disable/enable. |
| | | b: Disable/enable BG4. |
| | | c: Disable/enable BG3. |
| | | d: Disable/enable BG2. |
| | | e: Disable/enable BG1. |
| | | |
| | | |
| w |$212D |Sub-screen designation [TD] |
| | |*** Same as $212C, but for the sub-screens, not the main. |
| | | |
| | |Remember: When screen addition/subtraction is enabled, the |
| | |sub screen is added/subtracted against the main screen. |
| | | |
| | | |
| w |$212E |Window mask main screen designation register [TMW] |
| | |*** Same as $212C, but for window-masks. |
| | | |
| w |$212F |Window mask sub screen designation register [TSW] |
| | |*** Same as $212E, but for the sub screen. |
| | | |
| | | |
| w |$2130 |Fixed color addition or screen addition register [CGWSEL] |
| | |abcd00ef ab: Main (see table below). |
| | | cd: Sub (see table below). |
| | | e: 0 = Enable +/- for fixed colour. |
| | | 1 = Enable +/- for sub screen. |
| | | f: Colour & char-data = direct color |
| | | data (MODE 3, 4 & 7 only). |
| | | |
| | |ab|Result |
| | |--|-----------------------------------------------------------|
| | |00|All the time. |
| | |01|Inside window only. |
| | |10|Outside window only. |
| | |11|All the time. |
| | |--|-----------------------------------------------------------|
| | | |
| w |$2131 |Addition/subtraction for screens, BGs, & OBJs [CGADSUB] |
| | |mrgsabcd m: 0 = Enable + colour-data mode. |
| | | 1 = Enable - colour-data mode. |
| | | r: See below for more info. |
| | | g: Affect back-area. |
| | | s: Affect OBJs. |
| | | a: Affect BG4. |
| | | b: Affect BG3. |
| | | c: Affect BG2. |
| | | d: Affect BG1. |
| | | |
| | |*** 'r' is some sort-of "1/2 of colour data" on/off bit. When |
| | | the colour constant +/- or screen +/- is performed, desig-|
| | | nate whether the RGB result in the +/- area should be 1/2 |
| | | or not; the back-area is not affected. |
| | | |
| | | |
| w |$2132 |Fixed colour data for fixed colour +/- [COLDATA] |
| | |bgrdddddd b: Set to change blue. |
| | | g: Set to change green. |
| | | r: Set to change red. |
| | | d: Set colour constant data for +/-. |
| | | |
| | | |
| w |$2133 |Screen mode/video select register [SETINI] |
| | |sn00pvshi |
| | | s: Super-impose SFX graphics over ex- |
| | | ternal video (usually 0). |
| | | n: External mode (screen expand). When |
| | | sing MODE 7, enable. |
| | | p: 0 = 256 resolution. |
| | | 1 = 512 sub screen resolution. |
| | | v: 0 = 224 vertical resolution. |
| | | 1 = 239 vertical resolution. |
| | | s: See below for more info. |
| | | i: 0 = No interlace. |
| | | 1 = Interlaced display. |
| | | |
| | |*** When in interlace mode, select either the 1-dot per line |
| | | mode or the 1-dot repeated every 2-lines mode. If '1' is |
| | | set in this bit, the OBJ seems to be reduced vertically |
| | | by 1/2. |
| | | |
| | |*** Interlaced mode is used in the SNES test cartridge. It |
| | | does flicker, but it gives a FULL 480 vertical resolution.|
| | | |
| | | |
|r |$2134 |Multiplication result register (low) [MPYL] |
|r |$2135 |Multiplication result register (middle) [MPYM] |
|r |$2136 |Multiplication result register (high) [MPYH] |
| | |*** Result is 8 bits long for $2134, $2135, and $2136. |
| | | |
| | | |
|r |$2137 |Software latch for horizontal/vertical counter [SLHV] |
| | |aaaaaaaa a: Result. |
| | | |
| | |The counter value at the point when $2137 is read can be |
| | |latched. Data read is meaningless. |
| | | |
| | | |
|r |$2138 |Read data from OAM {OAMDATAREAD} |
|r 2 |$2139 |Read data from VRAM {VMDATALREAD/VMDATAHREAD} |
|r |$213B |Read data from CG-RAM (colour) {CGDATAREAD} |
|r d |$213C |Horizontal scanline location [OPHCT] |
|r d |$213D |Vertical scanline location [OPVCT] |
| | |*** Registers $213C and $213D are 9-bits in length. |
| | | |
| | | |
|r |$213E |PPU status flag & version number [STAT77] |
| | |trm0vvvv t: Time over (see below). |
| | | r: Range over (see below). |
| | | m: Master/slave mode select. Usually 0. |
| | | v: Version # ($5C77 (???)). |
| | | |
| | |*** Range: When the quantity of the OBJ (size is non-relevant)|
| | | becomes 33 pieces or more, '1' is set. |
| | | Time: When the quantity of the OBJ which is converted to |
| | | 8x8 is 35 pieces or more, '1' will be set. |
| | | |
| | | |
|r |$213F |PPU status flag & version number [STAT78] |
| | |fl0mvvvv f: Field # scanned in int. mode (0=1st).|
| | | l: Set if external signal (light pen, |
| | | etc.) is installed/applied. |
| | | m: NTSC/PAL mode (0=NTSC, 1=PAL). |
| | | v: Version # ($5C78 (???)). |
| | | |
| | | |
|rw |$2140 |[APUI00] -| |
|rw |$2141 |[APUI01] |- Audio registers. See sound.doc and sid-spc.src. |
|rw |$2142 |[APUI02] | |
|rw |$2143 |[APUI03] -| |
| | | |
| | | |
|rw |$2180 |Read/write WRAM register [WMDATA] |
|rw |$2181 |WRAM data register (low byte) [WMADDL] |
|rw |$2182 |WRAM data register (middle byte) [WMADDM] |
|rw |$2183 |WRAM data register (high byte) [WMADDH] |
| | | |
| | | |
| w |$4200 |Counter enable [NMITIMEN] |
| | |a0yx000b a: NMI/VBlank interrupt. |
| | | y: Vertical counter. |
| | | x: Horizontal counter. |
| | | b: Joypad read-enable. |
| | | |
| | | |
| w |$4201 |Programmable I/O port (out-port) [WRIO] |
| | | |
| | | |
| w |$4202 |Multiplicand 'A' [WRMPYA] |
| w |$4203 |Multiplier 'B' [WRMPYB] |
| | |*** Absolute multiplication used when using the two above reg-|
| | | isters. Formulae is: 'A (8-bit) * B (8-bit) = C (16-bit)'.|
| | | Result can be read from $4216. |
| | | |
| | | |
| w 2 |$4204 |Dividend C [WRDIVL/WRDIVH] |
| w |$4205 |Divisor B [WRDIVB] |
| | |*** Absolute division used when using the two above registers.|
| | | Formulae is 'C (16-bit) / B (8-bit) = A (16-bit)'. |
| | | Result can be read from $4214, and the remainder read from|
| | | $4216. |
| | |*** Operation will start when $4205 is set, and will be com- |
| | | pleted after 16 machine cycles. |
| | | |
| | | |
| w 2 |$4207 |Video horizontal IRQ beam position/pointer [HTIMEL/HTIMEH] |
| | |0000000x xxxxxxxx x: Beam position. |
| | | |
| | |Valid values for x range from 0 to 339, due to overscan. The |
| | |timer is reset every scanline, so unless it's disabled, you'll|
| | |receive an interrupt every time the beam hits the value given.|
| | | |
| | | |
| w 2 |$4209 |Video vertical IRQ beam position/pointer [VTIMEL/VTIMEH] |
| | |0000000y yyyyyyyy y: Beam position. |
| | | |
| | |Same as $4207, but valid values for y are 0 to 261 (based from|
| | |overscan at the top of the screen). |
| | | |
| | | |
| w |$420B |DMA enable register [MDMAEN] |
| | |abcdefgh a: DMA channel #7. |
| | | b: DMA channel #6. |
| | | c: DMA channel #5. |
| | | d: DMA channel #4. |
| | | e: DMA channel #3. |
| | | f: DMA channel #2. |
| | | g: DMA channel #1. |
| | | h: DMA channel #0. |
| | | |
| | | |
| w |$420C |HDMA enable register. |
| | |*** Same as $420B, virtually. |
| | | |
| | | |
| w |$420D |Cycle speed register [MEMSEL] |
| | |0000000x x: 0 = Normal (2.68MHz). |
| | | 1 = Fast (3.58MHz). |
| | | |
| | |Note that using the fast mode requires 120ns or faster EPROMs.|
| | | |
| | | |
|r |$4210 |NMI register [RDNMI] |
| | |x000vvvv x: Disable/enable NMI. |
| | | v: Version # ($5A22 (???)) |
| | | |
| | |Bit 7 can be reset to 0 by reading this register. |
| | | |
| | | |
|rw |$4211 |Video IRQ register [TIMEUP] |
| | |i0000000 i: 0 = IRQ is not enabled. |
| | | 1 = IRQ is enabled. |
| | | |
| | |This location MUST be read to clear a horizontal or vertical |
| | |raster interrupt. It's all relative to $4200. If the horiz- |
| | |ontal timer interrupt (bit 4, $4200) is set then the interrupt|
| | |will be generated according to the position in $4207. Same |
| | |thing is for vertical timing (bit 5, $4200) but the position |
| | |will be read from $4209, not $4207. |
| | | |
| | | |
|rw |$4212 |Status register [HVBJOY] |
| | |xy00000a x: 0 = Not in VBlank state. |
| | | 1 = In VBlank state. |
| | | y: 0 = Not in HBlank state. |
| | | 1 = In HBlank state. |
| | | a: 0 = Joypad not ready. |
| | | 1 = Joypad ready. |
| | | |
| | | |
|r |$4213 |Programmable I/O port (in-port) [RDIO] |
| | | |
| | | |
|r 2 |$4214 |Quotient of divide result [RDDIVL/RDDIVH] |
| | | |
| | | |
|r 2 |$4216 |Multiplication or divide result [RDMPYL/RDMPYH] |
| | | |
| | | |
|r |$4218 |Joypad #1 status register [JOY1L] |
| | |abcd0000 a: A button (1=pressed). |
| | | b: X button (1=pressed). |
| | | c: Top-Left (1=pressed). |
| | | d: Top-Rght (1=pressed). |
| | | |
|r |$4219 |Joypad #1 status register [JOY1H] |
| | |abcdefgh a: B button (1=pressed). |
| | | b: Y button (1=pressed). |
| | | c: Select (1=pressed). |
| | | d: Start (1=pressed). |
| | | e: Up (1=pressed). |
| | | f: Down (1=pressed). |
| | | g: Left (1=pressed). |
| | | h: Right (1=pressed). |
| | | |
|r |$421A |Joypad #2 status register [JOY2L] -| |
|r |$421B |Joypad #2 status register [JOY2H] | |
|r |$421C |Joypad #3 status register [JOY3L] |- Same as $4218 & $4219. |
|r |$421D |Joypad #3 status register [JOY3H] | |
|r |$421E |Joypad #4 status register [JOY4L] | |
|r |$421F |Joypad #4 status register [JOY4H] -| |
| | |*** Joypad registers can be read w/ a 16-bit accum/X/Y and |
| | | both the high and low bytes will received valid data. |
| | | |
| | | |
|----------------------------------------------------------------------------|
|The following data is for DMA-transfers. 'x' represents the DMA channel #, |
|which ranges from 0 to 7. So, the following would represent each section: |
|DMA #0: $4300-$4305. |
|DMA #1: $4310-$4315. |
|.................... |
|DMA #7: $4370-$4375. |
|----------------------------------------------------------------------------|
| w |$43x0 |DMA Control register [DMAPX] |
| | |vh0cbaaa v: 0 = CPU memory -> PPU. |
| | | 1 = PPU -> CPU memory. |
| | | h: For HDMA only: |
| | | 0 = Absolute addressing. |
| | | 1 = Indirect addressing. |
| | | c: 0 = Auto address inc/decrement. |
| | | 1 = Fixed address (for VRAM, etc.). |
| | | b: 0 = Automatic increment. |
| | | 1 = Automatic decrement. |
| | | a: Transfer type:
| | | 000 = 1 address write twice: LH. |
| | | 001 = 2 addresses: LH. |
| | | 010 = 1 address write once. |
| | | 011 = 2 addresses write twice: LLHH |
| | | 100 = 4 addresses: LHLH |
| | | |
| | | |
| w |$43x1 |DMA Destination register [BBADX] |
| | |xxxxxxxx x: Low-byte address. |
| | | |
| | |*** The upper-byte address is assumed to be $21, making your |
| | | access addresses $2100 to $21FF. |
| | | |
| | | |
| w 2 |$43x2 |Source address [A1TXL/A1TXH] |
| w |$43x4 |Source bank address [A1BX] |
| w 2 |$43x5 |DMA transfer size & HDMA address register [DASXL/DASXH] |
| | |*** When using DMA, $43x5 defines the # of bytes to be trans- |
| | | ferred via DMA itself. When using HDMA, $43x5 defines the |
| | | data address ($43x5 = low byte, $43x6 = hi byte). |
| | | |
| | | |
| w |$43xA |Number of lines for HDMA transfer [NTRLX] |
| | |cxxxxxxx c: Continue (0=yes, 1=no (???)). |
| | | x: # of lines to transfer. |
|----------------------------------------------------------------------------|
|Additional information follows. |
|Most of the following information is for SMC files, and where the header |
|info is kept in memory, etc. etc. etc... |
|----------------------------------------------------------------------------|
|rw |$FEED |UNDOCUMENTED REGISTER: Felon's banana register [FBNANACNT] |
| | |rcnnnnnn r: Ripe bit (0=ripe, 1=rotten). |
| | | c: Colour bit (0=yellow, 1=green). |
| | | n: Number of bananas. |
| | | |
| | |*** This register counts the number of bananas Felon currently|
| | | has in his possession... (Who the hell is Felon?!). |
| | | |
| | |*** According to numerous sources, this register can be used |
| | | to calculate pi to the 5-billionth digit in 20 clock |
| | | cycles. The number of cycles corresponds to Felon's age, |
| | | increasing by 1 every 365 days (1 year). It is increased |
| | | by 2 every leap year. |
| | | |
| | | |
|rw |$FFC0 |Cartridge title. |
|rw |$FFD6 |ROM/RAM information on cart. |
|rw |$FFD7 |ROM size. |
|rw |$FFD8 |RAM size. |
|rw |$FFD9 |Developer ID code. |
|rw |$FFDB |Version number. |
|rw |$FFDC |Checksum complement. |
|rw |$FFDE |Checksum. |
|rw |$FFEA |NMI vector/VBL interrupt. |
|rw |$FFEC |Reset vector. |
----------------------------------------------------------------------------

21
files/docs/snes/yoshi/SNES.2 Normal file
View File

@ -0,0 +1,21 @@
----------------------------------------------------------------------------
|The SNES has some interesting colour characteristics. The colour, theoret- |
|ically is 15 bit; each RGB value (Red, Green, and Blue) has 5 bits for each |
|colour. |
| |
|When it comes to putting the colour data into $2122, the format (in binary) |
|is the following: |
| b: Blue ?bbbbbgg gggrrrrr |
| g: Green |
| r: Red |
| ?: The infamous bit-of-confusion. :-) |
| |
|A quick colour chart could be the following: |
| $7FFF [0111 1111 1111 1111]: White. |
| $001F [0000 0000 0001 1111]: Red. |
| $03E0 [0000 0011 1110 0000]: Green. |
| $7C00 [0111 1100 0000 0000]: Blue. |
| $7C1F [0111 1100 0001 1111]: Purple. |
| $7FE0 [0111 1111 1110 0000]: Aqua. |
| $03FF [0000 0011 1111 1111]: Yellow. |
----------------------------------------------------------------------------

89
files/docs/snes/yoshi/SNES.3 Normal file
View File

@ -0,0 +1,89 @@
----------------------------------------------------------------------------
|For those of you who don't know how the SNES does do it's graphics, it |
|uses tiles (surprise surprise!). |
| |
|There are different MODEs on the SNES; the most famous being MODE 7. |
|Most people think that $2106 (Screen Pixelation: Look in SNES.1 for an ex- |
|planation on this register) is MODE 7. *** THIS IS NOT MODE 7!!! ***. |
|So, the next time the pixels get really "big" (almost making them look like |
|look like IBM-clone 320x200x256 MODE 13h graphics), and your friend says |
|"WOW! MODE 7 is really awesome," punch him/her in the nose for me. Just |
|joking. :-) |
| |
|I'll be explaining MODE 1. I know how MODE 7 works, but since i've never |
|used it, don't plan on me explaining it in the near future. Sorry to those |
|who were looking for a MODE 7 document. Look elsewhere... |
| |
|MODE # of BGs MaxColour/Tile Palettes Colours |
|----------------------------------------------------------------------------|
|0 4 4 8 32 |
|1 3 16/16/4 8 128 |
| |
|MODE 0 is good for geometric shapes (if you were going to rotate a wire- |
|frame cube, or something like that), basic star scrolls, or a very 'bland' |
|text scroller... it's pretty cool and doesn't take up much space. |
| |
|I'm going to explain MODE 1, since MODE 0 is the same thing but with less |
|bitplanes. :-) |
| |
|MODE 1 is really best for things; detailed star scrolls, text scrollers, |
|geometric shapes, and filled objects. It's the most common used MODE in the |
|the professional SNES programming world. |
| |
|You need to "setup the plane" to tell it what tile goes where. If you want |
|demo-code, check out 'test.asm' in 'test.lzh'. |
|----------------------------------------------------------------------------|
|So, lets assume we have a character (a 8x8 tile) which we want to work with |
|to figure out the SNES's colour scheme: |
| |
|TestCHR1 dcb $00,$00,$00,$00,$00,$00,$00,$00 ; '@' |
|TestCHR2 dcb $00,$3C,$4E,$5E,$5E,$40,$3C,$00 ; '@' |
| |
|You're probably wondering how the two lines above turn into actual graphic |
|data on your monitor or television set. Very simple. Consider each byte |
|(each new $xx statement) a new pixel line. Tile size is 8x8. |
| |
| %00000000 = $00 |
| %00000000 = $00 This is TestCHR1 |
| %00000000 = $00 |
| %00000000 = $00 |
| %00000000 = $00 |
| %00000000 = $00 |
| %00000000 = $00 |
| %00000000 = $00 |
| |
| %00000000 = $00 |
| %00111100 = $3C This is TestCHR2 |
| %01001110 = $4E |
| %01011110 = $5E |
| %01011110 = $5E |
| %01000000 = $40 |
| %00111100 = $3C |
| %00000000 = $00 |
| |
|The at-symbol ('@') is visible in TestCHR2. Now you're probably wondering |
|"Well, that tells me how to define a pixel on and off; what about the colour|
|itself!" Once again, very simple, but a tad more complex: |
| |
|If you have a 0 for bitplane 0, a 0 for bitplane 1, a 0 for bitplane 2, |
|and a 0 for bitplane 3, you get color #0; eg.: |
| 0000 = Color #0 |
| ||||___________Bitplane 0 |
| |||__________Bitplane 1 |
| ||_________Bitplane 2 |
| |________Bitplane 3 |
| |
|So, now, think about a 0 for bitplane 0, a 1 for bitplane 1 and 2, and a 0 |
|for bitplane 3: |
| 0110 = Color #6 |
| ||||___________Bitplane 0 |
| |||__________Bitplane 1 |
| |_________Bitplane 2 |
| |________Bitplane 3 |
| |
|Keep in mind, this is the best explanation i've ever seen done about SNES |
|pixel color definition. Until I see better, I'd have to say this is the |
|best it's gonna get. |
|The result above gives you the color # per pixel; it's interesting. It's an |
|"overlay" method, so-to-speak, not to confuse this w/ main and sub-screens. |
----------------------------------------------------------------------------

23
files/docs/snes/yoshi/SNES.4 Normal file
View File

@ -0,0 +1,23 @@
----------------------------------------------------------------------------
|MODE # of BGs MaxColour/Tile Palettes Colours |
|----------------------------------------------------------------------------|
|0 4 4 8 32 |
|1 3 16/16/4 8 128 |
|2 ? ??? ? ??? |
|3 2 256 & 16 1 & 8 256 & 32 |
|4 2 256 & 4 1 & 8 256 & 32 |
|5 ? ??? ? ??? |
|6 ? 16 8 128 (Interlaced mode) |
|7 ? 256 1 256 |
|----------------------------------------------------------------------------|
|Parms which have question marks ("?") mean that I don't know their stats. |
|Any information would be greatly appreciated! I have personally tested some |
|of the MODEs (MODE 0, 1, and 3), but none of the rest. |
|----------------------------------------------------------------------------|
|MODE 1's "16/16/4" means you can have 16 colours per tile on BG1 and BG2, |
|but on BG3 you can only have 4. |
|----------------------------------------------------------------------------|
|MODE 3 can have 256 colours on the first plane, but only 16 on the second. |
|MODE 4 isn't the exact same as MODE 3 (as v2.20 of my document stated), but |
|i'm waiting for someone to tell me the differences... |
----------------------------------------------------------------------------

48
files/docs/snes/yoshi/SNES.5 Normal file
View File

@ -0,0 +1,48 @@
----------------------------------------------------------------------------
|The OBJs use a lookup table that contains info on their X and Y position on |
|the screen, their size, if they're flipped vertically or horizontally, their|
|colour, and the actual data. |
| |
|The format you need to make the table is as follows: |
| |
| |
|Spr. # Size Offset Explanation |
|----------------------------------------------------------------------------|
| 0 Byte 0 xxxxxxxx x: X-location. |
| Byte 1 yyyyyyyy y: Y-location. |
| Byte 2 abcdeeeC a: Vertical flip. |
| b: Horizontal flip. |
| c: Playfield priority. |
| d: Playfield priority. |
| e: Pallete #. |
| Byte 3 CCCCCCCC C: Character data. |
| |
| 1 Byte 4 xxxxxxxx x: X-location. |
| Byte 5 yyyyyyyy y: Y-location. |
| Byte 6 abcdeeeC a: Vertical flip. |
| b: Horizontal flip. |
| c: Playfield priority. |
| d: Playfield priority. |
| e: Pallete #. |
| Byte 7 CCCCCCCC C: Character data. |
|...and so on... |
|----------------------------------------------------------------------------|
|Continue this table all the way down to OBJ #127 (out of 128). Don't think |
|you're finished quite yet: There is one more table of data required. |
| |
|2 bits are defined for each OBJ (eg. byte #0 holds the info for OBJ 0, 1, 2,|
|and 3; byte #1 holds the info for OBJ 4, 5, 6, and 7). Therefore, 128/4 is |
|32 bytes of data for the following table: |
| ab |
| ||____Size toggle bit. |
| |_____MSB of X-position bit. |
| |
|So, the 4 bytes/sprites + the block are put into the OAM table by consec- |
|utive writes to the OAM data register. You first should set the OAM address |
|to $0000, then shove your data into it. |
| |
|If you don't set the block after the OAM as well, the results are bad. All |
|the data for the MSB stuff wouldn't be defined correctly, which would result|
|in your entire OBJ table being wacko. Have atleast some 0's there or a table|
|which you really want to use in the long run. |
----------------------------------------------------------------------------

19
files/docs/snes/yoshi/SNES.6 Normal file
View File

@ -0,0 +1,19 @@
----------------------------------------------------------------------------
|I have never used an actual Super MagiComm before, and I would strongly re- |
|commend not using these unless you know what each one does for sure. If you |
|decide to write any sort-of operating system for the SNES, please do get in |
|touch with me. |
| |
|The below registers i've never tested, or had tested. If you end up killing |
|your console unit because of this, I TAKE NO RESPONSIBILITY. |
| |
|Location Value returned when read Value input when written |
|----------------------------------------------------------------------------|
|$C000: Input Register |
|$C002: Digital Output Register |
|$C004: Main Status Register |
|$C005: Data Register Data Register |
|$C007: Digital Input Register Disk Control Register |
|$C008: Parallel Data Parallel Data |
|$C009: Parallel Status |
----------------------------------------------------------------------------

15
files/docs/snes/yoshi/SNES.7 Normal file
View File

@ -0,0 +1,15 @@
----------------------------------------------------------------------------
|Here's a really basic memory map of the SNES's memory. Thanks to Geggin of |
|Censor for supplying this. Reminder: this is a memory map in MODE 20. |
|----------------------------------------------------------------------------|
|Bank |Address |Description |
|-------|--------------|-----------------------------------------------------|
|$00-$3F|$0000-$1FFF |Scratchpad RAM. Set D-reg here if you'd like (I do) |
| |$2000-$5FFF |Reserved (PPU, DMA) |
| |$6000-$7FFF |Expand (???) |
| |$8000-$FFFF |ROM (for code, graphics, etc.) |
|$70 |$0000-$7FFF |SRAM (BRAM) - Battery RAM |
|$7E |$0000-$1FFF |Scratchpad RAM (same as bank $00 to $3F) |
| |$2000-$FFFF |RAM (for music, or whatever) |
|$7F |$0000-$FFFF |RAM (for whatever) |
----------------------------------------------------------------------------

22
files/docs/snes/yoshi/SNES.8 Normal file
View File

@ -0,0 +1,22 @@
I'd like to thank the following people:
Jeremy Gordon: Thanks for supplying me your sprite documentation. I
don't think this doc. would be complete without it!
Also for 65816 v2.0! Excellent assembler.
AntiTrack: Thanks for the source! Next time, i'll ask! (grin)
Toshi: I know you can't say much due to your job, but I
really appreciate all the moral support you've given
me. I wish I could show you how much it means to me.
minus: Work on TRASM some more! Fix' dem bugs! :-)
Jehu: Keep in touch. Get back to me about the job!
Clay C.: Without you, who knows where i'd be.
Troy_: I appreciate the logos!
Geggin of Censor: Thanks for the memory map!
D. Messiah of PiR: ...for all the EMail, long talks, 'n all that jazz.
You're like a brother to me.
Hellos and "HEY! You're important too!"s go out to:
III_Demon, JackRippr, Amos, Norm, Hardware, Skywalkr, KingPhish,
felon, AntiTrack, IRSMan, sendog, SHORYUKEN, _grazzt, RuGalz, and
all the rest of the #SNES and famidev-gang.

450
files/docs/snes/yoshi/SOUND.DOC Normal file
View File

@ -0,0 +1,450 @@
From PARADIS@htu.tu-graz.ac.at Fri Mar 25 08:41:08 1994
The Bloody SPC-700
------------------
A try to stumble into the inner secret of a nasty chip.
By Antitrack exclusively for the FAMIDEV development group.
Chapter 1:
----------
FACTS
* The SPC 700 is a very stupid sound chip with about the worst
handling
that you have seen in your lifetime.
* This chip is a co processor. He has a quite large instruction set
(contrary to the Amiga's COPPER, who has a very small one) and 64KB
RAM
memory, of which you can use atleast 32KB. (or so)
* All program and data that is supposed to be run by this chip must
be'
moved to the SPC's own ram with a small loop that pokes each byte of
your SPC assembler program and (e.g. sample-)data into four memory
locations : $2140 - $2143. They are your only chance to communicate
with
the SPC.
* These four memory locations have different meanings for read and
write;
if you read (LDA) $2140, you get the data from memory loc. 00f4 (or
so)
of the sound chip.
* On power-on, the SPC 700 jumps (much like the main processor) to a
very
small ROM area that resides from $ffc0 to $ffff inside the SPC.
(This chip REALLY follows the black box principle, eh...) This
program
at $ffc0 is waiting to get the data in the right format on his
input ports
at $00f4/5/6/7 , which are $2140/1/2/3 from the 65c816's (e.g.
your's )
point of view.
* Your main program will therefore have to follow the SPC's
conditions and
poke all the program and data for the SPC into 2140/1/2/3 in a
special
order.
* When transmission is completed, you will also have transmitted the
start
address of your SPC code, and the SPC will start to execute your
program
there.
--------------------QUESTIONS.
Q: How do I move my program and data to the SPC then, what format do
I have
to use?
A: First, your SPC data/code has to be moved from ROM to the extra
RAM at
e.g. $7f0000 . Dont ask me why it has to be in RAM, probably it doesnt
but all the existing routines that send data to the SPC do something
like
that.
Your data/code has to be in groups which I will call "chunks". A
valid chunk
looks like that:
first word: number of bytes to transmit to SPC -+
sec. word : start address where to move data to the SPC | one chunk
byte 4-???? : your data/code -+
You can have as many chunks as you want to , but the last chunk must
be like
that:
first word : $0000
second word: Start address of your code.
Q: So if you are right, this means: After I transmitted all my code
and
data, and my own SPC code takes over the control, I might encounter
problems
if my SPC program has to communicate with the outer world (the
65c816).
What if the main program wants to change sounds? What if a background
melody
shall always play on two voices, and extra two voices will be used for
sound effects whenever the player sprite e.g. picks up an object?
A: That is sure a point. Your own code will have to look at memory
locations
$00f4/00f5/00f6/00f7 , because they are the only accessible from
outside
at $2140/1/2/3. The easiest way would be: As soon as any of $f4-$f7
change,
jump into the Boot ROM at $ffc0 (?) so the SPC is executing his
receive
routine again. Then you *probably* can send another SPC chunk with new
sound and code to the SPC....
Q: This only helps if a complete new tune is to be played, this
doesnt help
if a melody using two voices shall still remain....
A: Thats true. The best approach is to send own command bytes to the
SPC and
your SPC code has to check out $f4-$f7 constantly and react to it.....
A command byte like $00 could mean: sound off,
$01 : play tune 1
.
.
.
$0f : play tune $0f
$10 : play jingle (fx) 01
.
.
.
$ff : jump to $ffc0 (??) the receive
ROM routine
Q: is there another approach?
A: Yes there is. As you probably know, all important addresses of the
SPC 700 reside inside its own RAM's zeropage:
Address / register / usage
0000 Volume left
0001 Volume right
0002 Pitch low
0003 Pitch high (The total 14 bits of pitch
height)
0004 SRCN Designates source number from 0-
255
0005 ADSR 1
0006 ADSR 2
0007 GAIN Envelope can be freely designated by
your code
0008 ENVX Present val of envelope with DSP
rewrites
0009 VALX Present wave height val
(and so on...)
Your approach would be to move only sample data there, and/or (lots
of) very
small chunks of data with a target address in the zeropage, and a
starting
address of e.g. $ffc0. The small chunks would access zeropage
addresses e.g.
for the volume etc and thus result in tones; if this is done every
frame
you might end up with a music player quite similar to the C64 styled
ones.
Q: So anyway, in what format exactly do I have to move data to the
SPC?
A: I have the following source code for you, but let me explain it a
bit
BEFORE you start to dig into it.
I've already mentioned the general "chunk" format. The loop does the
following:
- move ram destination address to $2142/3 (akku: 16 bit)
- move either #$00 or #$01 into 2141, this depends if you have more
than $0100
bytes of data for the SPC;
- first time (first chunk you transmit): move constant #$cc into 2140
- loop: poke each byte that you want to be transmitted into 2140
(word)
the higher 7-15 bits of your accu-word contain the number of bytes
already
moved (e.g. 00 on the start)
- cmp $2140 with this number of bytes already moved (lower 8 bits of
this
number only!) and wait if its not equal.
- until the loop is over.
- for the next chunk header this is repeated, but not #$cc is moved
into
2140 but "nn" (lobyte of number of bytes moved) +3 or +6 if it was
00 when
+3 was used.
EXAMPLE:
move #$0400 to 2142 /word access
move #$01 to 2141
move #$cc to 2140
move "gg00" to 2140 where "gg" is the first real code/data
byte for
the SPC
wait till 2140 is #$00
move hh01 to 2140 where "hh" is the second byte of code or
data for SPC
wait till 2140 is #$01
move ii02 to 2140 where "ii" is the 3rd byte of data for the
SPC....
wait till 2140 is #$02
lets say "ii" was the last byte. Now we add #$04 (3+carry) to
#$02
(#$02 being the number-1 of how many bytes we moved to the
SPC), we
will push it onto the stack), now :
fetch the next header , poke target RAM address into $2142
(word)
poke 00 or 01 into 2141 depending of how many bytes to send,
poke #$06 into 2140 (06 : number of bytes sent from last chunk-
1 + 3 )
I think I got this scheme pretty much right this time. Now, is PLEASE
someone
going to donate their home-brewed SPC dis/assemblers to me? Oh pretty
please,
I hate silent SNES's ! :)
Source code follows, reassembled from a PAN/Baseline demo "xmas wish
92/93":
----------------------------------------------------------------------
------
; entry to the code starts here
SEP #$30 ; x y a set to 8 bit length
LDA #$FF ; ff into audio0w (write)
STA $2140
REP #$10 ; x,y: 16 bit length
LDX #$7FFF
l0DB5B LDA $018000,X ; move rom music data to ram at $7f0000
STA $7F0000,X
LDA $028000,X ; move rom music data to ram at $7f0000
STA $7F8000,X
DEX
BPL l0DB5B
LDA #$80 ; screen on , probably not important at all
STA $2100
LDA #$00 ; 00fd/00fe/00ff point to the data that is
now
STA $00FD ; in ram at $7f0000
LDA #$00
STA $00FE
LDA #$7F
STA $00FF
STZ $4200 ; disable nmi and timer h/v count
SEI ; disable irq
JSR l0DBCD ; unknown sub routine, labeled "RESTART"
by PAN/ATX
SEP #$30 ; all regs 8 bit
l0DB8B LDA $2140 ; wait for reply from sound chip ?
BNE l0DB8B
LDA #$E0 ; audio3w ?
STA $2143
LDA #$FF ; send data to sound chip ?
STA $2142 ; $ffe0 this could be an address within the
; sound chip ROM between $ffc0 and $ffff
in the
; ROM mask.......
LDA #$01 ; send data to sound chip ?
STA $2141
LDA #$01 ; send data to sound chip ?
STA $2140
l0DBA4 LDA $2140 ; wait for reply from sound chip ?
CMP #$01 ; what a fuck of a protocol .... :(
BNE l0DBA4
l0DBAB LDA $2140 ; wait again for reply from soundchip ?
CMP #$55
BNE l0DBAB
LDA $0207 ; aha ... move $0207 to sound chip ?
STA $2141 ; probably sound number selector
LDA #$07
STA $2140 ; send data to sound chip
l0DBBD LDA $2140 ; wait until sound chip accepted data?
CMP #$07
BNE l0DBBD
l0DBC4 LDA $2140 ; wait for reply ?
CMP #$55
BNE l0DBC4
CLI
RTS
l0DBCD PHP ; labeled "RESTART" by pan/ATX
JSR l0DBD8 ;
PLP
LDA #$00 ; 00 into audio0w
STA $2140
RTS
l0DBD8 PHP
REP #$30 ; a,x,y 16 bit regs
LDY #$0000 ; needed first time at lda [$fd],y :
pointer to ram
LDA #$BBAA
l0DBE1 CMP $2140 ; wait for sound chip $2140/2141 ?
BNE l0DBE1
SEP #$20 ; akku 8 bit
LDA #$CC
BRA l0DC12 ; oh well, another mystery :-)
; jump here if overflow is set e.g. if more than $0100 data to move
l0DBEC LDA [$FD],Y ; get data from ram pointer
INY ; the accumulator is about to get "xx00"
where
XBA ; /"xx" is the byte from [fd],y (first
data byte)
LDA #$00 ; /and resides into bit 15-7 of accu,
and 00 is
BRA l0DBFF ; /#$00 (8bit number of bytes already
sent)
l0DBF4 XBA ; accu is now "nn??" ?? is old data from
last loop
LDA [$FD],Y ; accu is now "nnxx" with xx the newest
data byte
INY ; /for
the SPC!
XBA ; accu is now "xxnn"
l0DBF9 CMP $2140 ; wait for sound chip to reply with "nn" !!
BNE l0DBF9
INC A ; increment number of bytes that were
sent...
; accu is now "xxnn" with newest val for
nn:=nn+1
l0DBFF REP #$20 ; akku 16 bit
STA $2140 ; poke "xxnn" to soundchip. xx is actual
data,
SEP #$20 ; akku 8 bit ! nn is the 8-bit cutted
number of bytes
DEX ! which were already sent!!
BNE l0DBF4 ; as many times as xreg says...
l0DC09 CMP $2140 ; byte "nn" will be replied from the SPC if
data
BNE l0DC09 ; received correctly!
l0DC0E ADC #$03 ; compare accu with #$fb ADC WILL ADD #$04
COZ
; CARRY IS ALWAYS SET AFTER THE CMP!!!
ATTENTION!
BEQ l0DC0E ; if accu was $fb then accu := $03 . (what
for?)
l0DC12 PHA ; push value accu+$04 to stack (or
beginning: #$cc)
REP #$20 ; accu = 16 bit
LDA [$FD],Y ; get ram data 2 bytes
INY ; point to next word
INY
TAX ; x:=a : number of bytes to transmit
LDA [$FD],Y ; get ram data
INY
INY
STA $2142 ; audio2w : possibly the dest. area in the
spc700
SEP #$20 ; accu 8 bit
CPX #$0100 ; set carry if first ram data was >= 0100
lda #$00 ;
ROL ;
STA $2141 ; if ram data >= 0100, poke "1" into reg 1
otherw 0
ADC #$7F ; SET OVERFLOW FLAG IF X>=$0100 !!!! (nice
trick!)
PLA
STA $2140 ; $cc in the first case , nn+4 on all later
cases
l0DC32 CMP $2140 ; wait for snd chip reply
BNE l0DC32
BVS l0DBEC ; if there were more than $0100 data for the
spc's RAM
; move them where they R supposed to belong
to!
PLP
RTS
PLA
STA $2140 ; same shit, never been jumped into
l0DC3F CMP $2140
BNE l0DC3F
BVS l0DBF9
PLP
RTS
; also lets look at 7f0000: the first few bytes at 7f0000 are:
7f0000: b7 0e 00 04 20 cd cf bd e8 00 5d af c8 f0 d0 fb 5d d5 00 01
d5 00 02
b7 0e should be number of bytes to transmit, 0400 the destination
inside the
spc....
at this point I really need an SPC dis/assembler..... :(((
Okay well my first source was incompetent, sure thing. But I think I
could
solve a lot of questions meanwhile.

201
files/docs/snes/yoshi/SPRITE.DOC Normal file
View File

@ -0,0 +1,201 @@
SPRITE DOC
------------------------------------------------------------
if you haven't already obtained "yoshi doc", get it and read it before you
read this doc....
Part I - the bitplane representation of a 16 color 8x8 pixel tile
-----------------------------------------------------------------
sprites are made of tiles, in particular 4-bitplane tiles, 4-bitplane
tiles, means that the tiles are made of 4-bit color values, so this means
that the tiles can have a maximum of 16 colors.
in many graphics formats, this type of data would be stored as follows
(assuming a 8 pixel by 8 pixel tile)
$1 $0 $2 $8 $2 $4 $5
$2 $0 $6 $1 $f $e $1
$a $2 $2 $2 $6 $7 $0
$1 $0 $2 $8 $2 $4 $5
$1 $0 $2 $8 $2 $4 $5
$1 $0 $2 $8 $2 $4 $5
$1 $0 $2 $8 $2 $4 $5
$1 $0 $2 $8 $2 $4 $5
where each hex number represents a color, so pixel (0,0) would be color
number "1", and pixel (4,2) would be color "6"....this is <not> the case
on the super nintendo....for reasons having to do with the implementation
of the graphics engine, the super nintendo represents its image data in
the "bitplane" format, assuming and 8 pixel by 8 pixel tile with 16
colors, this data would have four bitplanes (0-3) of monochrome, binary
image data:
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 1
0 0 0 0 0 0 0 0 1 2
0 0 0 0 0 0 0 0 1 2 3
0 0 0 0 0 0 0 0 1 2 3
0 0 0 0 0 0 0 0 1 2 3
0 0 0 0 0 0 0 0 1 2 3
0 0 0 0 0 0 0 0 1 2 3
1 1 1 1 1 1 1 1 2 3
2 2 2 2 2 2 2 2 3
3 3 3 3 3 3 3 3
four monochrome 8x8 pixel images stacked on top of each other. if you
wanted pixel (4,2) to have the color "6" you would have to put a "1" in
bitplane one, and a "1" in bitplane two, with the bitplane zero and three
having "0"'s. this is because the binary representation of "6" is "0110".
ok, so it is obviously possible to store each monochrome bitplane in 8
bytes, each byte representing a row in the bitplane. so a single tile
takes up 32 bytes (8 bytes per row * 8 rows * 4 bitplanes) of memory.
Part II - the way tiles are stored in vram for sprite data
---------------------------------------------------------
in vram you store a tile 16 bits at a time as follows:
<-------2 bytes at a time------>
<--1 byte wide-><--1 byte wide->
[plane 0, row 0][plane 1, row 0]
[plane 0, row 1][plane 1, row 1]
[plane 0, row 2][plane 1, row 2]
..
..
..
[plane 0, row 7][plane 1, row 7]
[plane 2, row 0][plane 2, row 0]
[plane 2, row 1][plane 2, row 1]
[plane 2, row 2][plane 2, row 2]
..
..
..
[plane 2, row 7][plane 2, row 7]
the super nintendo can have two different sizes of sprite on the screen
at one time, you can choose from the following combinations:
[value] [sprite size 0][sprite size 1]
000 8x8 pixel 16x16 pixel
001 8x8 pixel 32x32 pixel
010 8x8 pixel 64x64 pixel
011 16x16 pixel 32x32 pixel
100 16x16 pixel 64x64 pixel
101 32x32 pixel 64x64 pixel
it is set in the upper three bits of address $2101....so to use 8x8 pixel
sprites, and 32x32 pixel sprites, you would load $2101 with the value
"001xxxxx" (where x is don't care)
the lower five bits of address $2101 are also very important, these bits
tell the super nintendo where in vram your sprites are located. the
lowest three bits are the "name base", and the fourth and fifth bits are the
"name". the "name" bits specify the upper 4k word of the sprite address,
and the "name base" specfies the offset. so if put you tile data in vram
$0000 you would set these bits all to zero.
suppose you want to have four 32 pixel by 32 pixel sprites; each would be
composed of 16 tiles, each tile is numbered, tiles $0-$3f
[sprite 0]
0 1 2 3
4 5 6 7
8 9 a b
c d e f
..
..
[sprite 3]
30 31 32 33
34 35 36 37
38 39 3a 3b
3c 3d 3e 3f
in vram, these tiles, $0 through tile $3f would be store in an interlaced
fashion as follows:
$0 $1 $2 $3 $10 $11 $12 $13 $20 $21 $22 $23 $30 $31 $32 $33
$4 $5 $6 $7 $14 $15 $16 $17 $24 $25 $26 $27 $34 $35 $36 $37
do you see the pattern? you must store the first row (four tiles) of each
sprite, and then the second row, then the third, etc....
if you were dealing with 8x8 sprites, you would have to store the first
row of 16 sprites, then the second row of the 16 sprites, etc....
if you were dealing with 16x16 sprites, you have to store the first row
of 8 sprites, then the second, then the third, etc...
with 64x64, yep, you guessed it, the first row of two sprites, then the
second row, etc....
Part III - setting up the OAM table for your sprites
-----------------------------------------------------
for each sprite in the sprite table (maximum of 128 sprites, numbered 0-127)
you must have four bytes of information, the first byte is the low 8 bits of
the horizontal position of the sprite, the second byte is the vertical
position of the sprite, the third byte is the "address" of the sprite...
it is not the actual vram address, it is the tile number, that is to say,
the physical vram address of the sprite can be obtained by the following:
multiply the sprite "address" by 32 (because each tile is 32 bytes) and add it
to the starting vram address that you set in the $2101 register.
this tile number points to the first tile in the sprite...the snes expects the
rest of tiles to follow in the order described in the previous section...
the next byte containes the 9th bit of the tile "address" and a few attributes
bit 0 = 9th bit
bit 1-3 = palette number
bit 4,5 = playfield priority
bit 6 = horizontal flip
bit 7 = horizonal flip
the palette number is not a 4 bit number, so obviously, you can only choose
between 8 of the 16 palettes....if you set these bits to all 0, you will be
selecting the eigth palette (palette 7), if you set them to "001" it is the
ninth palette etc...it was trial and error, and some <serious> frustration
before i figured this one out :)
to set these bytes in the OAM table, you must first setup the OAM "address"
on the 16 bit register $2102 (and $2103). again this is not a real address,
you use the 7 lowest bits of this address to select which sprite you
would like to set the data for (sprite 0 to sprite 127)
then you can write the four bytes discussed above to the register $2104, its
like the color register, auto incrementing...
so....what are all the other bits for??? (the remaining 9) well, i know about
only two others, the highest bit (bit 15) is a sprite priority bit, it is
basically the bit you set to "turn on" the sprite, and keep it being redrawn
on the screen...its a little more than this, but thats all i know about its
behavior. so when you setup your table, (and periodically throughout the
sprites' display lifecycle) you must set this bit high....(for any sprite being
displayed)
there is another small table (32 bytes) that you must load into the OAM, these
consist of two bits for every sprite, one of the bits being the 9th horizontal
position bit, and the other is the size select bit (remember we can pick from
two different size sprites on the screen at once) the first bit is the
most significant horizontal location, and the second is the size toggle
bit...
to write this table the OAM, you must set the 9th bit of the "address" in $2103
to one....then write the bytes, again it is an auto incrementing register
make sure that you have enabled the sprites to be on a particular plane (see
the yoshi doc, on $212C....and make sure that you have set your palette
correctly (remember sprite palette 0 is the 8th palette!!!)
good luck....

BIN
files/docs/ttl/7400_DS.pdf Normal file
View File

Binary file not shown.

BIN
files/docs/ttl/74HC645.pdf Normal file
View File

Binary file not shown.

BIN
files/docs/ttl/74HC_HCT245_3.pdf Normal file
View File

Binary file not shown.

BIN
files/docs/ttl/74LCX245.pdf Normal file
View File

Binary file not shown.

BIN
files/docs/usb/usb-in-a-nutshell.pdf Normal file
View File

Binary file not shown.

Some files were not shown because too many files have changed in this diff Show More