diff --git a/source/docs/Genesis_ROM_Format.txt b/source/docs/Genesis_ROM_Format.txt deleted file mode 100644 index bf81dc6..0000000 --- a/source/docs/Genesis_ROM_Format.txt +++ /dev/null @@ -1,374 +0,0 @@ - - THE COMPLETE DOCUMENTATION ABOUT - GENESIS ROM FORMAT - - Version 1.1 - - - Release history - ^^^^^^^^^^^^^^^ - Version 1.0 (December, 1997) - - Initial Release - - Version 1.1 (January, 1998) - - Splitted rom format explained! - - New company codes - - New errors in copyright interpreting found - - Month interpreting (in copyright) - - - In this document you will find everything you need to know about -the information embedded within a Genesis ROM. You will also find -how to read all this information from the different ROM formats -(BIN, SMD and MD). - The information in this document was hacked by Volker Oth (dOnut) -and by me with help from technical documents found on internet. -The primary document from the internet that we used was gentech.txt. - If you want to change this document to add any important info about -the Genesis ROMs, do it freely but I would like to receive a copy of -the updated document. Then, I'll add your name in it and post it on my -homepage. Don't be a lamer and keep all names mentioned here! - Note that all numbers with a "H" in the left are in hexadecimal, and -the first byte of a file is the ZERO position. All information is -provided based on the BIN file-format because of the nature of this -format(see sections about each rom format). - *This document should be downloaded from my homepage. Any other site -may contain outdated material!* - If you use this information for anything, please give the proper -credits to the all these names listed below! I would thank you if you -include a link to our homepages and emails, too! - -Felipe XnaK: - http://www.classicgaming.com/launchtool - felipe@ComPorts.com -Volker Oth (dOnut): - http://members.aol.com/~volkeroth - volkeroth@aol.com - - - THE BASIC INFORMATION: - ^^^^^^^^^^^^^^^^^^^^^ - -H100: 'SEGA MEGA DRIVE' 1 -H110: '(C)SEGA 1988.JUL' 2 -H120: GAME NAME (DOMESTIC) 3 -H150: GAME NAME (OVERSEAS) 4 -H180: 'XX' 5 -H182: 'XXXXXXX-XX' 6 -H18E: XXXX 7 -H190: 'XXXXXXXXXXXXXXXX' 8 -H1A0: 00000000, XXXXXXXX 9 -H1A8: RAM 10 -H1BC: MODEM DATA 11 -H1C8: MEMO 12 -H1F0: Country in which the product 13 - can be released. - -1: This is just the console name. It can be 'SEGA MEGA DRIVE' or - 'SEGA GENESIS' depending on the console's country of origin. - -2: Copyright notice. There SHOULD be 4 characters for the company -code, a space and then the date in yyyy.mmm format; however, there are -variations. - For a listing of company codes, see "TABLE OF COMPANY CODES". -For a listing of month abbreviations, se "TABLE OF MONTH ABBREVIATIONS". -When the company uses a number as a company code, the copyright has -(in most cases!) this format: '(C)T-XX 1988.JUL', where XX is the -company code. If the company code has three digits, it should use the -space between the code and the date. - Some wrong copyrights i've found: - * The year is written as '199X' or '19XX', or doen't include the - millenium and the century. - * The company name is '00' or 'XX' - * Some companies that use a number for company code overwrite the - hiphen, not the space. - * Some companies doesn't include the '(C)' in the beginning and - others include just their name; some just include the the year - * Some copyrights have the year and month separated by ',','/', '-', - space or null character (H00). I'd found one that hasn't any separator - at all! - -- Good luck! -- - -3: This is the so-called "Domestic game name". Is the name the game has -in its country of origin. This field is 48 bytes long... - -4: ... and this is the so-called "Overseas game name". This is the name -the game has worldwide. 48 bytes long too. - -5: Type of product. This is 2 bytes long. Known values: - GM = Game - Al = Education - -6: Product code and Version number: - * The first 7 characters are the product code - * The 2 characters after the hiphen is the version number. This will - vary depending on the the type of ROM or software version - -7: Check sum, a two-bytes value (see "Calculating the Checksum") - -8: I/0 support: (this is 16 bytes long) - J = Joypad 4 = Team Play - 6 = 6-button Joypad 0 = Joystick for MS - K = Keyboard R = Serial RS232C - P = Printer T = Tablet - B = Control Ball V = Paddle Controller - F = Floppy Disk Drive C = CD-ROM - L = Activator M = Mega Mouse - -9: ROM capacity. Here you will find the start and end address of the rom, -respectively. The start address in most cases is 0 and the end address is -the size of rom in BYTES. Note that these values don't include the headers -that some rom images have (discussed later). Each address is 4-bytes long. - -10: There is a lot of information here that I can't help you with. What -I can say is that you can get the start and end positions of the backup -RAM at offset H1B4. Like in ROM addresses, you first acquire the start, -then the end address. Remember, these addresses are four bytes each. - -11: If the rom has no support for MODEM, fill this with spaces. If it has -support for MODEM, then fill in this format: 'MOxxxxyy.z', where: - xxxx Firm name the same as in 2 - yy MODEM NO. - z Version - -12: I don't know what the heck it is! But by it's name and considering -all roms that I investigated, it seems that you can write whatever you want -in this field... - -13: Countries where the game can be released. What is most interesting -here is that changing this info in some games has different behaviour. -Streets of Rage, for example, automatically changes it's name for Bare -Knuckle if you set the game for Japan. The "official" codes are: - E = Europe - J = Japan - U = USA - I've found some others as well(I do not guarantee this is correct!) - A = Asia - B = Brazil - 4 = Brazil - F = France - 8 = Hong Kong - This field can only contain three countries. This isn't really a -problem because all "unofficial" codes run as Europe! Don't forget to -set spaces to fill the bytes you don't use in this field. - - - TABLE OF COMPANY CODES: - ^^^^^^^^^^^^^^^^^^^^^^ - - This table was compiled by myself by just getting the company code -in the ROM and writing the license that appears on the tittle screen. -In other words, it probably contains errors and is missing a lot of -companies. - When two comp1anies use the same code and are different companies -(at least to my knownledge) the names are separeted by an "or". If the -companies are the same (like Acclain and Flying Edge), they're separated -by a backslash (/). - - CODE COMPANY - - ACLD Ballistic - ASCI Asciiware - RSI Razorsoft - SEGA SEGA - TREC Treco - TmEE Tiido's Micro Electronical Entertainment Company - VRGN Virgin Games - WSTN Westone - 10 Takara - 11 Taito or Accolade - 12 Capcom - 13 Data East - 14 Namco or Tengen - 15 Sunsoft - 16 Bandai - 17 Dempa - 18 Technosoft - 19 Technosoft - 20 Asmik - 22 Micronet - 23 Vic Tokai - 24 American Sammy - 29 Kyugo - 32 Wolfteam - 33 Kaneko - 35 Toaplan - 36 Tecmo - 40 Toaplan - 42 UFL Company Limited - 43 Human - 45 Game Arts - 47 Sage's Creation - 48 Tengen - 49 Renovation or Telenet - 50 Eletronic Arts - 56 Razorsoft - 58 Mentrix - 60 Victor Musical Industries - 69 Arena - 70 Virgin - 73 Soft Vision - 74 Palsoft - 76 Koei - 79 U.S. Gold - 81 Acclaim/Flying Edge - 83 Gametek - 86 Absolute - 93 Sony - 95 Konami - 97 Tradewest - 100 T*HQ Software - 101 Tecmagik - 112 Designer Software - 113 Psygnosis - 119 Accolade - 120 Code Masters - 125 Interplay - 130 Activision - 132 Shiny & Playmates - 144 Atlus - 151 Infogrames - 161 Fox Interactive - 239 Disney Interactive - -- SPECIAL CASES: - - In "Smurfs II" the copyright is just '(C) INFOGRAMES' - In "Baby's day out" rom, the copyright is: '(C) T-SNK 95-FEB', -but the company name is "HI-TECH entertainment" - - - TABLE OF MONTH ABBREVIATIONS: - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -ABBREVIATIONS MONTH - - JAN January - FEB February - MAR March - APR or APL April - MAY May - JUN June - JUL July - AUG or 08 August - SEP or SEPT September - OCT October - NOV November - DEC December - - - CALCULATING THE CHECKSUM: - ^^^^^^^^^^^^^^^^^^^^^^^^ - - Genesis checksum is simple enough... All you need to do is: -1) Checksum starts as zero -2) Skip the first 512 bytes of the ROM -3) Read a byte from the rom and multiply its ascii value by 256, then sum - it to the checksum -4) Read the next byte from the rom and just sum it to the checksum -5) If you're not in the end of file, goto step 3 -6) Get the first 16 bits from the resulting checksum and discard the higher - bits -7) That's your checksum! - - - Super Magic Drive Binary file-format (.BIN): - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - This rom file-format is a simple rom dump. Nothing more to add! - - - Super Magic Drive Interleaved file-format (.SMD): - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - This is a much more complex file-format. It have a 512 bytes header -and is interleaved in 16KB blocks. These blocks have their even bytes -at the beginning and the odd bytes at the end of them. - - WHAT YOU FIND IN THE 512 BYTES HEADER: - -0: Number of blocks 1 -1: H03 * -2: SPLIT? 2 -8: HAA * -9: HBB * -ALL OTHER BYTES: H00 - -1: This first byte should have the number of 16KB blocks the rom has. -The header isn't part of the formula, so this number is: - [size of rom-512]/16386 - If the size is more than 255, the value should be H00. - -2: This byte indicates if the ROM is a part of a splitted rom series. If -the rom is the last part of the series (or isn't a splitted rom at all), -this byte should be H00. In other cases should be H40. See "CREATING -SPLITTED ROMS" for details on this format. - -*: Fixed values - - - THE DE-INTERLEAVING CODE (how to convert a SMD to a BIN): - -1) Skip the 512 bytes header -2) Get 16KB from the ROM (16384 bytes) -3) Decode the block -4) Write the decoded block to the BIN file - - DECODING A SMD BLOCK (stating byte is 0): - -1) Get Middlepoint (8192) -2) Get a byte from the block -3) If the byte position is equal or smaller than middlepoint, put it -in the first unused EVEN position of the decoded buffer -4) If the byte position is greater than middlepoint, put it in the -first unused ODD position of the decoded buffer - - To convert a BIN to a SMD, just create a header (as explained before) and -then do the reverse process! - - - Multi Game Doctor file-format (.MD): - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - The MD file format also doesn't have a header. The interleaving it uses -is equal to the SMD, but without the division in blocks! (Even bytes in -the end of file, odd bytes in the beginning). - - THE DECODING A MD (how to convert a MD to a BIN): - -1) Get middlepoint ([size of rom]/2) -2) Get a byte from the ROM -3) If the byte position is equal or smaller than the middlepoint put the -byte in [byte position]*2 of the destination buffer -4) If the byte position is greater than the middlepoint, put the byte in -([byte position]*2) - [size of rom] -1 - - - CREATING SPLITTED ROMS: - ^^^^^^^^^^^^^^^^^^^^^^^ - - Splitted ROMs are a SMD divided into pieces. Knowing this, you may -guess that you first need to convert your ROM to a SMD! :) - To have a splitted ROM created all you need is divide your SMD in -several pieces, usually all with the same size (with the exception of -the last one). After doing that, you need to add a SMD header to all -these pieces. About these SMD headers: - 1) The number of blocks embedded in them should be relative to the -piece, not to the joined ROM. - 2) As stated before, with the exception of the last piece, all roms -should have their SPLIT byte set. - - - HOW YOU CAN HELP ME WITH THIS DOCUMENT: - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - - Telling me the intricacies of a MGD ROM image. I never found one, but -I do believe it's equal to MD format. - - I'm trying to find out how the sprites are saved in Genesis ROMs. If -you have this info, I would like to have it! - - I never had a rom with modem support. If you have one, please test if -the information about it is correct in this documentation (I got it from -gentech). If you find it's correct, please explain me!!! - - If you have any of this information, send it with your addresses (e-mail, -homepage, etc) so I can add this to the document! \ No newline at end of file diff --git a/source/docs/REALTEC Cart Mapper - description v1.txt b/source/docs/REALTEC Cart Mapper - description v1.txt deleted file mode 100644 index bb9e87f..0000000 --- a/source/docs/REALTEC Cart Mapper - description v1.txt +++ /dev/null @@ -1,74 +0,0 @@ - -REALTEC Cart Mapper - description v1 (2005.03.08) - -by Tasco Deluxe [tascoDLX(AT)hotmail(DOT)com] - -* Thanks to Mask Of Destiny for info about the boot state (from "The Earth Defend") - - -The REALTEC cart mapper is found in unlicensed Genesis/MegaDrive game carts produced by REALTEC. -Game carts known to utilize the mapper include "The Earth Defend", "Whac-A-Critter", and -"Funnyworld/Balloon Boy 2-in-1". They all contain common code used to display the REALTEC logo -and map a portion of the main ROM. - -When the cart is powered on, 8KB of boot code is mapped by default into the cart's ROM area and -is mirrored throughout. This boot code is likely the last 8KB of the main ROM (all known carts -are 4 Mbit [512KB] w/ boot code at $07E000). The boot code, after displaying the REALTEC logo, -has the option to display a menu for game selection. After a selection is made, any neccessary -initializations are performed and a portion of the main ROM is mapped. - -The code used to access the mapping registers is common amongst all known carts. A portion -of code is copied to RAM and executed. This code writes to the mapping registers based on a -selection number. Afterwards, the code clears the first 16 bytes of the I/O area ($A10000 -thru $A1000F) and resets the M68000 manually (stack address is read from $000000, code address -is read from $000004). - -The mapping is performed by writing to 3 mapped-in registers -- $400000, $402000, $404000. -Only one value is written per register. However, the same value is written 256 times in a row. -It is unknown whether this is because the registers explicitly require 256 writes, or because -the hardware is so crappy as to need multiple writes. - -The register descriptions below are listed in the order they are commonly written. -All registers are byte-sized and only known to have write access. - -* $402000 - Size of ROM range to map (in 1Mbit [128KB] blocks) - -[maximum (theoretical) value of 32] - -* $400000 - Bits of the ROM address (lower) - -The bits (as written) are: ? ? ? ? ? c c c - -* $404000 - Bits of the ROM address (upper) - -The bits (as written) are: ? ? ? ? ? m m ! - -'?' is an unknown bit that is clear (in all known cases) -'!' is an unknown bit that is set (in all known cases) - -From the above registers, the resulting ROM address (binary) is: - -00mm ccc0 0000 0000 0000 0000 - -The common code in all REALTEC mapper carts sets the mapper values based on a selection number -(ROM address only -- the ROM size is fixed). The ROM addresses for these selections, numbered -1 thru 8, are: - -1) $000000 [$00,$01] -2) $040000 [$02,$01] -3) $100000 [$00,$03] -4) $180000 [$04,$03] -5) $200000 [$00,$05] -6) $280000 [$04,$05] -7) $300000 [$00,$07] -8) $380000 [$04,$07] - -The only cart known to use a selection other than #1 is "Funnyworld/Balloon Boy 2-in-1" -("Balloon Boy" is #1, "Funnyworld" is #2). It is assumed that the included code is merely a -suggestion and that any valid ROM address can be mapped. - -A ROM range that is mapped, in order to function properly, must include a M68000 vector table -since the cart's entire ROM area is replaced by the mapped range. None of the known carts -attempt to remap a different ROM range after the boot code has executed. It is unknown whether -the mapper allows the boot code to be remapped, although it seems doubtful. - diff --git a/source/docs/changelog b/source/docs/changelog deleted file mode 100644 index 548139f..0000000 --- a/source/docs/changelog +++ /dev/null @@ -1,22 +0,0 @@ - - [04/20/03] - - Modified 68000 emulator to prevent 'tas.b $mem' from writing data back - after a read (fixes Gargoyles). - - Fixed bug in 68000 emulator to swap order of words written for address - register indirect pre-decremented writes (fixes Jim Power graphics). - - Added support for 240-line displays (for Super Skidmarks). - - Rewrote part of the interrupt handling (fixes some raster effects). - - Removed sprite collision detection code (never really worked). - - Optimized sprite rendering inner loop. - - [04/13/03] - - Finished up memory map for VDP DMA V-bus reads. - - Fixed handling of 68000 writes to I/O chip at even addresses. - - Fixed bit 7 handling of control register in I/O chip. - - Finished up Z80 memory map. - - Added code to handle Genesis hardware lock-ups. - - Removed some faulty code from the 68000 memory map handlers. - - [03/22/03] - - Completed implementation of Z80 banked memory handlers. - diff --git a/source/docs/gamegenie.htm b/source/docs/gamegenie.htm deleted file mode 100644 index a18121d..0000000 --- a/source/docs/gamegenie.htm +++ /dev/null @@ -1,235 +0,0 @@ - - - GameGenie patches - - - - -
-

GameGenie Patching

-
-

  GameGenie was a device created by codemasters and galoob that -let you make cheats for games. It was plugged in the console like a normal -cartridge, and in its top the desired cartridge was plugged. These cheats are -possible because what GameGenie do is edit the RAM that stores values used by -the ROMs, setting these values to a constant that can be, for example, the -number of lifes you have!

-

  Genecyst was the first Genesis emulator to have support -for GameGenie then, with Kgen98, Steve Snake started to use this neat feature -in his great emulator. No ROM image of a GameGenie is necessary, as some may -imagine, to use them with console emulators, these programs themselves have a -built-in feature that acts like a GameGenie, writing the codes in the emulated -RAM.

-

  The GameGenie code consists of a eight-bytes long string, and -the valid characters are A, B, C, D, E, F, G, H, J, K, L, M, N, P, R, S, T, V, -W, X, Y, Z, 0, 1, 2, 3, 4, 5, 6, 7, 8 and 9, all in uppercase. Each character -have a binary repressentation, which is 5-bits long.

- - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CharValue
A00000
B00001
C00010
D00011
E00100
F00101
G00110
H00111
J01000
K01001
L01010
-		 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CharValue
M01011
N01100
P01101
R01110
S01111
T10000
V10001
W10010
X10011
Y10100
Z10101
-		 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CharValue
010110
110111
211000
311001
411010
511011
611100
711101
811110
911111
-
-
-

  The cheat code should be firstly converted directly using the -table above, and then the bits should be reordered. For example, the GameGenie -code SCRA-BJX0 is translated to:

- - - - - - - - -
- - - - -
Code:
Bits:
Id:
- 		- - - - - - - - - - -
SCRA
01111000100111000000
ijklmnopIJKLMNOPABCD
- 		- - - - -
-
-
-
- 		- - - - -
BJX0
00001010001001110110
EFGHdefghabcQRSTUVWX
-
- -

  Then rearrange (using the id) as...

- - - - - - - - -
- - - -
Bits:
Id:
- 		- - - - - - - -
000000001001110001110110
ABCDEFGHIJKLMNOPQRSTUVWX
- 		- - - -
:
:
- 		- - - -
01010100 01111000
abcdefghijklmnop
-
- -
-

  Which give us, in hexa, 009C76:5478. This means that -H5478 will be written at H009C76 memory offset.

- - diff --git a/source/docs/gen-hw.txt b/source/docs/gen-hw.txt deleted file mode 100644 index 3fbd63f..0000000 --- a/source/docs/gen-hw.txt +++ /dev/null @@ -1,715 +0,0 @@ - - Sega Genesis hardware notes - Version 0.8 (03/02/01) - - by Charles MacDonald - WWW: http://cgfm2.emuviews.com - - Unpublished work Copyright 2000, 2001 Charles MacDonald - - Here is a compilation of some notes I've written up on the Sega Genesis - hardware. Everything described herein has been checked on the real thing, - though that doesn't necessarily mean my testing methods were flawless. :) - - Version history - --------------- - [0.8] - - Added information on the SVP chip used in Virtua Racing. (section 4.2) - - Added information on EEPROM storage. (section 4.1) - - Changed miscellaneous section around. - [0.7] - - Added more information about access to the Z80 bus. (section 2.2) - - Updated the VDP register information, and removed some things - that were specific to VDP programming. (section 1.1) - - Added some background about the PSG. (section 4) - [0.6] - - Rewrote the 68000 memory map description. (section 1) - - Rewrote the Z80 memory map description. (section 2.1) - - Added memory access section. (section 1.2) - - Added a few miscellaneous topics. (section 4) - [0.5] - - Added more Z80 banking information. - - Added unused VDP address return values from the Z80 side. - - Added example of how to start up the Z80 on power-up. - - Added information on Phantasy Star 4 from Jeff Quinn. - - Added list of consoles that support Mark-III compatibility mode. - - Fixed a few typos. - [0.4] - - Added more details on 68000 and Z80 memory map. - - Added more information on VDP addresses. - - Added some thoughts on Phantasy Star 4. - [0.3] - - Added more information on I/O registers. (section 3) - - Fixed a few typos pointed out by Tim Meekins. - [0.2] - - Added section on I/O port programming and gamepads - [0.1] - - Initial release - - Table of Contents - - 1.) 68000 memory map - 1.1) VDP registers - 1.2) Memory access quirks - 1.3) Clock speeds - 2.) Sound hardware overview - 2.1) Z80 memory map - 2.2) RESET and BUSREQ registers - 2.3) Banking - 2.4) Interrupts - 3.) Input and Output - 3.1) Programming I/O ports - 3.2) Gamepad specifics - 4.) Miscellaneous - 4.1) EEPROM - 4.2) Virtua Racing - 4.3) Phantasy Star 4 - 4.4) Other topics - 5.) Credits - 6.) Disclaimer - - - 1.) 68000 memory map - - 000000-3FFFFFh : ROM - 400000-7FFFFFh : Unused (1) - 800000-9FFFFFh : Unused (2) - A00000-A0FFFFh : Z80 address space (3) - A10000-A1001Fh : I/O - A10020-BFFFFFh : Internal registers and expansion (4) - C00000-DFFFFFh : VDP (5) - E00000-FFFFFFh : RAM (6) - - 1. Reads return the MSB of the next instruction to be fetched, with the - LSB set to zero. Writes do nothing. - - 2. Reading or writing any address will lock up the machine. - This area is used for the 32X adapter. - - 3. Addresses A08000-A0FFFFh mirror A00000-A07FFFh, so the 68000 cannot - access it's own banked memory. All addresses are valid except for - the VDP which is at A07F00-A07FFFh and A0FF00-A0FFFFh, writing or - reading those addresses will lock up the machine. - - 4. Reading some addresses lock up the machine, others return the MSB - of the next instruction to be fetched with the LSB is set to zero. - - The latter applies when reading A11100h (except for bit 0 reflects - the state of the bus request) and A11200h. - - Valid addresses in this area change depending on the peripherals - and cartridges being used; the 32X, Sega CD, and games like Super - Street Fighter II and Phantasy Star 4 use addresses within this range. - - 5. The VDP is mirrored at certain locations from C00000h to DFFFFFh. In - order to explain what addresses are valid, here is a layout of each - address bit: - - MSB LSB - 110n n000 nnnn nnnn 000m mmmm - - '1' - This bit must be 1. - '0' - This bit must be 0. - 'n' - This bit can have any value. - 'm' - VDP addresses (00-1Fh) - - For example, you could read the status port at D8FF04h or C0A508h, - but not D00084h or CF00008h. Accessing invalid addresses will - lock up the machine. - - 6. The RAM is 64K in size and is repeatedly mirrored throughout the entire - range it appears in. Most games only access it at FF0000-FFFFFFh. - - 1.1) VDP registers - - The lower five bits of the address specify what memory mapped VDP register - to access: - - 00h : Data port - 02h : Data port - 04h : Control port (1) - 06h : Control port - 08h : HV counter (2) - 0Ah : HV counter - 0Ch : HV counter - 0Eh : HV counter - 11h : SN76489 PSG (3) - 13h : SN76489 PSG - 15h : SN76489 PSG - 17h : SN76489 PSG - 18h : Unused (4) - 1Ah : Unused - 1Ch : Unused - 1Eh : Unused - - 1. For reads, the upper six bits of the status flags are set to the - value of the next instruction to be fetched. Bit 6 is always zero. - For example: - - move.w $C00004, d0 ; Next word is $4E71 - nop ; d0 = -1-- 11?? ?0?? ???? - - When reading the status flags through the Z80's banked memory area, - the upper six bits are set to one. - - 2. Writing to the HV counter will cause the machine to lock up. - - 3. Reading the PSG addresses will cause the machine to lock up. - - Doing byte-wide writes to even PSG addresses has no effect. - - If you want to write to the PSG via word-wide writes, the data - must be in the LSB. For instance: - - move.b (a4)+, d0 ; PSG data in LSB - move.w d0, $C00010 ; Write to PSG - - 4. Reading the unused addresses returns the next instruction to be fetched. - For example: - - move.w $C00018, d0 ; Next word is $4E71 - nop ; d0 = $4E71 - - When reading these addresses through the Z80's banked memory area, - the value returned is always FFh. - - Writing to C00018h and C0001Ah has no effect. - - Writing to C0001Ch and C0001Eh seem to corrupt the internal state - of the VDP. Here's what each bit does: (assuming word-wide writes) - - 8E9Fh : These bits cause brief flicker in the current 8 pixels - being drawn when the write occurs. - - 5040h : These bits blank the display like bit 6 of register #1 when set. - - 2000h : This bit makes every line show the same random garbage data. - - 0100h : This bit makes random pattern data appear in the upper eight - and lower ten lines of the display, with the normal 224 lines - in the middle untouched. For those of you interested, the - display is built up like so: - - 224 lines for the active display - 10 lines unused (can show pattern data here with above bit) - 3 lines vertical blank (no border color shown) - 3 lines vertical retrace (no picture shown at all) - 13 lines vertical blank (no border color shown) - 8 lines unused (can show pattern data here with above bit) - - I know that comes up to 261 lines and not 262. But that's - all my monitor shows. - - Turning the display off makes the screen roll vertically, - and random pattern data is displayed in all lines when - this bit is set. - - 0020h : This bit causes the name table and pattern data shown to - become corrupt. Not sure if the VRAM is bad or the VDP is - just showing the wrong data. - - 1.2) Memory access quirks - - Byte-wide writes - - Writing to the VDP control or data ports is interpreted as a 16-bit - write, with the LSB duplicated in the MSB. This is regardless of writing - to an even or odd address: - - move.w #$A5, $C00003 ; Same as 'move.w #$A5A5, $C00002' - move.w #$87, $C00004 ; Same as 'move.w #$8787, $C00004' - - Byte-wide reads - - Reading from even VDP addresses returns the MSB of the 16-bit data, - and reading from odd address returns the LSB: - - move.b $C00008, d0 ; D0 = V counter - move.b $C00001, d0 ; D0 = LSB of current VDP data word - move.b $C0001F, d0 ; D0 = $71 - nop - move.b $C00004, d0 ; D0 = MSB of status flags - - Word-wide writes - - When doing word-wide writes to Z80 RAM, only the MSB is written, and - the LSB is ignored: - - 0000: AA BB CC DD ; Z80 memory - move.w #$1234, $A00000 ; do a word-wide write - 0000: 12 BB CC DD ; result - - Word-wide reads - - A word-wide read from Z80 RAM has the LSB of the data duplicated in the MSB. - - 0000: AA BB CC DD ; Z80 memory - move.w $A00000, d0 ; do a word-wide read - d0 = $AAAA ; result - - 1.3) Clock speeds - - These are for an NTSC Sega Genesis console. - - 680000 = 7.67 MHz - YM2612 = 7.67 MHz - Z80 = 3.58 MHz - SN76489 = 3.58 MHz - - If anyone has information about timing for PAL consoles, please let me know. - - 2) Sound hardware overview - - The following components used for sound generation: - - - Zilog Z80 CPU - - 8k static RAM - - Yamaha YM2612 FM sound generator - - SN76489 PSG - - 2.1) Z80 memory map - - 0000-1FFFh : RAM - 2000-3FFFh : RAM (mirror) - 4000-5FFFh : YM2612 (1) - 6000-60FFh : Bank address register (2) - 6100-7EFFh : Unused (3) - 7F00-7FFFh : VDP (4) - 8000-FFFFh : Bank area - - 1. The YM2612 has two address lines, so it is available at 4000-4003h and - is mirrored repeatedly up to 5FFFh. - - 2. Writes go to the bank address register, reads return FFh. - The value returned applies to both the 68000 and Z80. - - 3. Writes are ignored, reads return FFh. - The value returned applies to both the 68000 and Z80. - - 4. Only addresses 7F00-7F1Fh are valid, writes to 7F20-7FFFh will - lock up the machine. - - Z80 access to the VDP has the same results as doing byte-wide reads - and writes as described in section 1.2. So only the HV counter and - PSG can be used effectively. - - All I/O ports return FFh, and writing to them has no effect. The Thunder - Force games read port BFh in the IRQ subroutine, this would appear to be - a misunderstanding on the programmer's behalf. - - The 68000 can write to A06000h to set up the bank address. - - 2.2) RESET and BUSREQ registers - - Bit 0 of A11100h (byte access) or bit 8 of A11100h (word access) controls - the Z80's /BUSREQ line. - - Writing 1 to this bit will request the Z80 bus. You can then release - the bus later on by writing 0. - - Reading this bit will return 0 if the bus can be accessed by the 68000, - or 1 if the Z80 is still busy. - - If the Z80 is reset, or if it is running (meaning the 68000 does not - have the bus) it will also return 1. The only time it will switch from - 1 to 0 is right after the bus is requested, and if the Z80 is still - busy accessing memory or not. - - Bit 0 of A11200h (byte access) or bit 8 of A11200h (word access) controls - the Z80's /RESET line. - - Writing 0 to this bit will start the reset process. The Z80 manual says you - have to assert the /RESET line for three Z80 clock cycles as a reset does - not happen instantly. - - Writing 1 to this bit will stop the reset process. At this point, the Z80 - will start executing from address 0000h onwards. - - The /RESET line is shared with the YM2612. For as long as the Z80 is reset, - the YM2612 cannot be used. - - The Z80 bus can only be accessed by the 68000 when the Z80 is running - and the 68000 has the bus. (as opposed to the Z80 being reset, and/or - having the bus itself) - - Otherwise, reading $A00000-A0FFFF will return the MSB of the next - instruction to be fetched, and the LSB will be set to zero. Writes - are ignored. This even applies to the VDP area that would normally - lock up the machine. - - Interestingly enough, you can still access $A10000-A1001F during this - time, which seems to be contradictory to some documentation which says - you can only access the I/O region when the 68000 has the bus. - - On power-up, the Z80 will be reset and will have the bus. - If you want to load a Z80 program and run it, do the following: - - - Stop the reset process - - Request bus - - Load Z80 program - - Start the reset process - - Release bus - - Stop the reset process - - 2.3) Banking - - The Z80 can access the 68000's address space through a banking mechanism - which maps 32k pages to 8000-FFFFh on the Z80 side. - - Most games do this to get at large data chunks like YM2612 DAC samples. - However, you can access anything else the 68000 can. (I've tried reading - the version register and setting the VDP border color this way with - success - in fact some 32X sample code shows the PWM sound generator - programmed by the Z80 through banking) - - To specify which 32k section you want to access, write the upper nine - bits of the complete 24-bit address into bit 0 of the bank address - register, which is at 6000h (Z80) or A06000h (68000), starting with - bit 15 and ending with bit 23. - - For example: - - ld ix, $6000 ; - xor a ; - ld (ix), a ; Bit 15 = 0 - ld (ix), a ; Bit 16 = 0 - ld (ix), a ; Bit 17 = 0 - ld (ix), a ; Bit 18 = 0 - ld (ix), a ; Bit 19 = 0 - ld (ix), a ; Bit 20 = 0 - ld (ix), a ; Bit 21 = 0 - inc a ; - ld (ix), a ; Bit 22 = 1 - ld (ix), a ; Bit 23 = 1 - - After this routine executes, Z80 addresses 8000-FFFFh now correspond - to 68000 addresses C00000-C07FFFh. - - In my own tests, I've been unable to do the following: - - - Read banked 68000 RAM. (returns FFh) - - Find result of partial writes to the bank address register. - - Have the Z80 read A00000-A0FFFF through the banked memory area. - (locks up the machine) - - Steve Snake informed me that reading 68000 RAM is possible, but is not - a recommended practice by Sega. Perhaps only some models of the Genesis - allow for it. - - 2.4) Interrupts - - The Z80 runs in interrupt mode 1, where an interrupt causes a RST 38h. - However, interrupt mode 0 can be used as well, since FFh will be read - off the bus. - - The Z80 will recieve an IRQ from the VDP on scanline E0h. This happens - once per frame, every frame, regardless of frame interrupts being - disabled by the 68000. - - If the Z80 has interrupts disabled when the frame interrupt is supposed - to occur, it will be missed, rather than made pending. - - There is no way to trigger an NMI unless the Genesis has been switched - into Mark 3 compatability mode, and this only means the NMI line is - mapped to the cartridge port, it's not controllable through software. - - 3.0) Input and Output - - The Genesis has three general purpose I/O ports. Devices like gamepads, - modems, light guns, etc. can be used with them. - - Here's a read-out of the I/O registers in their default state. Each - one can be read at an even address (e.g. A1000Dh == A1000Ch) as well. - - A10001h = A0 Version register - - A10003h = 7F Data register for port A - A10005h = 7F Data register for port B - A10007h = 7F Data register for port C - - A10009h = 00 Ctrl register for port A - A1000Bh = 00 Ctrl register for port B - A1000Dh = 00 Ctrl register for port C - - A1000Fh = FF TxData register for port A - A10011h = 00 RxData register for port A - A10013h = 00 S-Ctrl register for port A - - A10015h = FF TxData register for port B - A10017h = 00 RxData register for port B - A10019h = 00 S-Ctrl register for port B - - A1001Bh = FF TxData register for port C - A1001Dh = 00 RxData register for port C - A1001Fh = 00 S-Ctrl register for port C - - Bit 7 of the Data registers can be read or written. - Any bit that is set as an input will return '1'. - Any bit that is set as an output will return the value last written. - - Bits 7-0 of the Ctrl registers can be read or written. - - Bits 7-0 of the TxData registers can be read or written. - - The RxData register will always return zero. - - Bits 7-4 of the S-Ctrl registers can be read or written. - - 3.1) Programming I/O ports - - In the context of this description, I'll assume the device plugged in is a - gamepad. However, other periperhals like multi-taps, modems, mice, light - guns, etc, exist. - - Here's a pin-out of the connector: - - Pin 1 - UP - Pin 2 - DOWN - Pin 3 - LEFT - Pin 4 - RIGHT - Pin 5 - Vcc - Pin 6 - TL - Pin 7 - TH - Pin 8 - GND - Pin 9 - TR - - Each I/O port has several associated registers. I'll only cover the - data and control registers, as the others are used for serial and - parallel communication. - - The data register corresponds to the I/O port pins like so: - - Bit 7 - (Not connected) - Bit 6 - TH - Bit 5 - TL - Bit 4 - TR - Bit 3 - RIGHT - Bit 2 - LEFT - Bit 1 - DOWN - Bit 0 - UP - - A '0' means a button has been pressed, and '1' means a button has been - released. - - Bit 7 isn't connected to any pin on the I/O port. It will latch a value - written to it, as shown: - - move.b $A10003, d0 ; D0 = $7F - move.b #$80, $A10003 ; Bit 7 = 1 - move.b $A10003, d0 ; D0 = $FF - move.b #$00, $A10003 ; Bit 7 = 0 - move.b $A10003, d0 ; D0 = $7F - - Bits 6-0 of the control register define what bits of the data register - are inputs or outputs. Gamepads use TH as an output and the remaining - pins as input, so a value of $40 would be written to the control register. - - 3.2) Gamepad specifics - - A gamepad maps the directional pad to the pins mentioned earlier - (left, right, up, down), and multiplexes the four buttons (A, B, C, Start) - through the TL and TR pins. - - The TH pin controls which pairs of buttons (either A, Start or C, B) are - output through TL and TR by the multiplexer chip. - - In order to read all the buttons, A program will set TH = 1, read the data - port, set TH = 0, and read the port again. The data returned is as follows: - - TH = 0 : ?0SA00DU - TH = 1 : ?1CBRLDU - - ? = Whatever was last written to bit 7. - S = Start - A = Button A - B = Button B - C = Button C - U = Up - D = Down - L = Left - R = Right - - A 6-button gamepad allows the extra buttons to be read based on how - many times TH is switched from 1 to 0 (and not 0 to 1). Observe the - following sequence: - - TH = 1 : ?1CBRLDU 3-button pad return value - TH = 0 : ?0SA00DU 3-button pad return value - TH = 1 : ?1CBRLDU 3-button pad return value - TH = 0 : ?0SA0000 D3-0 are forced to '0' - TH = 1 : ?1CBMXYZ Extra buttons returned in D3-0 - TH = 0 : ?0SA1111 D3-0 are forced to '1' - - M = Mode - X = Button X - Y = Button Y - Z = Button Z - - From this point on, the standard 3-button pad values will be returned - if any further TH transitions are done. - - If TH isn't modified in about 8192 (probably less than that) 68000 CPU - cycles, a 'time-out' will occur and the sequence to read 6-button values - can be done again. Games usually poll the gamepad once per frame, - which is always enough for the time-out to occur. - - I believe checking if D3-D0 are all set or clear (as shown in the list - above) would be another method to verify if 6-button or 3-button pad data - was being returned. - - Some games may access the gamepad in a way that causes 6-button values - to be returned when 3-button values are expected. To get around this, - the MODE button can be held down when powering-up the console, and - the 6-button gamepad will respond like a 3-button one. - - 4.) Miscellaneous - - The following are miscellaneous topics. - - 4.1) EEPROM - - Some cartridges use a Xicor X24C01 EEPROM chip. The chip is programmed - in a serial fashion (it has only two wires), and has 128 8-bit bytes - of storage. - - Games using EEPROM have the backup data string at offset $1B0 in the - cartridge header area formatted like so: - - 0001B0: 52 41 E8 40 00 20 00 01 00 20 00 01 - - The Sega manual describes how the above data should be interpreted. - In this case, it corresponds to a device mapped to odd memory addresses, - occupying the byte at $200001. - - The only games I know of which use an EEPROM chip are: - - - Wonderboy 3 / Monster World IV - - Rockman Megaworld - - Megaman: The Wily Wars - - 4.2) Virtua Racing - - The Virtua Racing cartridge has 2MB ROM, 128K RAM, and a custom DSP chip - called the 'Sega Virtua Processor' (SVP), which is manufactured by Sega. - To the best of my knowledge, the SVP chip has internal ROM and possibly - internal RAM. - - The main purpose of the SVP is to render polygons as 8x8 patterns, which - the game program transfers to VRAM from the 128K RAM area using DMA. - - The VR cartridge has the following memory map: - - 000000-1FFFFFh : Program ROM (2MB) - 200000-2FFFFFh : Unused - 300000-31FFFFh : On-cart RAM (128K) - 320000-3FFFFFh : (?) - 390000-39FFFFh : (?) - 3A0000-3AFFFFh : (?) - - The SVP chip has registers mapped in the I/O space: - - A15000.w - Can read and write commands - A15005.b - Reading bit 0 acts like a status flag (SVP busy?) - A15006.w - Unknown ($0000, $0001, $000A written) - A15008.w - Unknown ($0000, $0001, $0000 written) - - Commands are two bytes in size, and are read and written to A15000h. - - FFFFh - Command reset (?) (done before any access) - 'SV' - Command init (?) (written before SVP communication) - 'OK' - Command OK (?) (written after 'SV') - 'Tx' - Where 'x' equals the following value based on the command - selected in the test menu: - 0 - "DSP ROM RD" and - "DSP RAM OVER WRITE" - 1 - "DSP DRAM R/W" - 2 - "DSP IRAM R/W" - 4 - "DSP POINTER" - - To emulate the SVP chip, somebody needs to figure out how to dump the - internal ROM (the test menu shows that it has a DSP ROM reading option, - perhaps sending a certain command to the SVP makes it map it's internal - ROM within the $300000-$3FFFFF area) and figure out how the DSP works. - - All of the above information came from physically examining a VR cartridge, - and from disassembling the test menu code. (found at $1B000 for those - of you who are interested) - - 4.3) Phantasy Star 4 - - Phantasy Star 4 is a 24 megabit game with 16k of battery backed RAM - mapped to $200001-$203FFF. (odd addresses used) It has ROM in the same - area where the RAM is. I've observed that the game will always write - $01 to $A130F1 before accessing the RAM, and then write $00 when - done. It could be that bit 0 of $A130F1 controls ROM/RAM banking at - that location. - - Jeff Quinn has tested this and confirmed it to work, and also reported - an area of the game where supporting banked SRAM is important; when - your characters encounter a GEROTLUX below the town of Tyler on Dezolis, - the game will try to access the ROM data that is obscured by SRAM. - - 4.4) Other topics - - - The 68000 RESET instruction has no effect. - - - If the VDP is not accessed often enough, it will (appear) to lock up. - I'm not sure what the cause is, but any control port access is enough - to keep it going. Maybe some of the internal VDP memory is composed - of DRAM cells that lose their data after a while. This happens in - the Mark III compatability mode as well as mode 4 and mode 5. - - - The status of the YM2612 can be read at any of it's four addresses. - Since only address zero is documented as valid, it could be that the - other addresses may return an incorrect result in some situations. - - - The PSG is compatible with the Texas Instruments SN76489. It is actually - on the same physical chip as the VDP, and it's output comes directly - out of the VDP to be mixed with the YM2612. Sega did the same thing - with the System C2 (possibly System 18) and SMS VDPs as well. - - Can anyone contribute some information about the Genesis security - and operating system ROM features? I know of a few: - - - Games must write the text 'SEGA' to A14000h if the lower four - bits of the version register return 01h. - - Writing 01h to A14101h disables the OS ROM and swaps in the cart ROM. - - The OS ROM checks for 'SEGA' or ' SEGA' at offset 100h in the cart ROM. - - Here's a list of consoles that support the Mark III compatability mode. - - - Sega Mega Drive - - Sega Mega Drive 2 - - Sega Genesis - - Sega Genesis 2 - - And ones that do not: - - - Genesis 3 (Majesco) - - If anyone has tested this with the Nomad, CDX, MegaJet, etc., please - let me know. - - 5.) Credits - - I would like to thank the following people for contributing information: - - Bart Trzynadlowski, Christian Schiller, Flavio Morsoletto, Jeff Quinn, - Mike Gordon, Naflign, Omar Cornut, Steve Snake, and Tim Meekins. - - Contributors to the Sega Programming FAQ. - Gringoz for the Genesis schematics. - - 6.) 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. - diff --git a/source/docs/gen_eeprom.doc b/source/docs/gen_eeprom.doc deleted file mode 100644 index 4cafa9e..0000000 Binary files a/source/docs/gen_eeprom.doc and /dev/null differ diff --git a/source/docs/gennotes.txt b/source/docs/gennotes.txt deleted file mode 100644 index 09f7938..0000000 --- a/source/docs/gennotes.txt +++ /dev/null @@ -1,458 +0,0 @@ -****************************************************** -* Sega Genesis Technical Notes by Bart Trzynadlowski * -* and many others! * -****************************************************** - - -Second Edition: February 7, 2000 - - Current - - Made a table of contents - - Added tile information and Scroll layer name table information - - Added info on Genesis security system and "do nots" courtesy of - Flavio. He also found a mistake in the joypad notes. - - Added SMD ROM stuff -First Edition: February 3, 2000 - - Initial release - - -This document is intended to be used as a reference alongside sega2.doc or any -other complete Sega Genesis technical documentation, it is not intended as a -standalone resource for learning about the Sega Genesis game console. - There is also some information here pertaining to specific situations -such as using the Starscream 68000 CPU core in an emulator project. - I wrote this document while working on a Genesis emulator. I felt some -things needed more description than was available. This document is intended -for emulator developers and Genesis programmers. - Feel free to pass this document around freely. If you use any parts of -it that were contributed by people other than me, it would be a good idea to -give them credit. - Any useful feedback is very much appreciated, especially corrections -and new entries. Do not ask about ROMs or anything stupid. trzy@powernet.net -Check my page at: http://www.powernet.net/~trzy as well. - Much thanks to Joe Groff, Steve Snake, nyef, ATani, and Flavio for -the invaluable help. - - --- Table of Contents -- - 0. Control Port Write Modes - 1. Auto-Increment - 2. VRAM Address Decoding (for Writing) - 3. Tiles - 4. Scroll Layer Name Tables - 5. Scroll Layers and Video Resolution - 6. Joypads - 7. Crash Course on the Genesis Security System and Common Don'ts - 8. Emulating RAM and ROM w/ Starscream - 9. SMD ROM Format - - --- 0. Control Port Write Modes -- - -The VDP control port, 0xC00004, has two write modes: "Register Set" (write1) -and "Address Set" (write2). The VDP is able to distinguish between which mode -you want to use by looking at bits 15 and 14 of the word you write to the -control port. - - 10: Write1 Otherwise: Write2 - -For write2, bits 15 and 14 are CD1 and CD0 so the concern of conflict arises. -If you look at the possible access modes which are specified by the 6 CD bits -you will not find any that have 10 in CD1 and CD0. - - --- 1. Auto-Increment -- - -The auto-increment value (in register #15) is apparently set to 2 by default. - - --- 2. VRAM Address Decoding (for Writing) -- - -For words and longwords, the VRAM address decoding process is not as -straightforward as some would have you believe. The A0 address bit is not used -in decoding, what this apparently means is that it is treated as 0 (thus -preventing misaligned word writes). - A0 is used to test wether or not the bytes in a word should be swapped -or not. If A0 = 1, they are swapped, if it is 0, then bytes are not swapped. -A0 is also used when adding the auto-increment value to the VRAM address after -some data is written. - - C example of emulating this: - - if (addr & 1) - data = ByteSwap(data); - *((unsigned short int *) (vram + (addr & 0xfffe))) = data; - addr += auto_inc; - - --- 3. Tiles -- - -The Genesis tile format is quite simple. Each pixel is represented by 4 bits -thus allowing 16 colors per every tile. Tiles are 8x8. The Genesis allows for -up to 64 colors to be displayed: 16 per palette, with 4 palettes. Palettes are -not specified in the tile bitmap, that information is elsewhere and beyond the -scope of this note. - - Example of a bitmap for the letter "A". We use the color 0xa for each - of the pixels. Remember, color 0 is _always_ transparent in any - palette: - - dc.l $00077000 - dc.l $07700770 - dc.l $07700770 - dc.l $07777770 - dc.l $07700770 - dc.l $07700770 - dc.l $00000000 - dc.l $00000000 - - --- 4. Scroll Layer Name Tables -- - -Scroll layers (who's addresses and sizes are specified in VDP registers) are -"name tables" where each entry contains an index to a specific 8x8 tile. These -entries are arranged in a linear fashion. - Each entry is a word in size. Here is the format for an entry: - - 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - |PRI|PL1|PL0|VFP|HFP|I10|I9 |I8 |I7 |I6 |I5 |I4 |I3 |I2 |I1 |I0 | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - PRI Priority (1 = highest, on top; 0 = lowest, on bottom) - PL1-PL0 Palette (0, 1, 2, or 3) - VFP Vertical flipping (1 = true) - HFP Horizontal flipping (1 = true) - I10-I0 Index of 8x8 tile in pattern area (VRAM $0000). - Multiply this by 32 to get offset in VRAM of the tile - bitmap - -The information here applies to both Scroll A and Scroll B, please refer to -more complete documentation for information on how to set Scroll layer -addresses and what-not. - - --- 5. Scroll Layers and Video Resolution -- - -The Genesis supports two video modes: 32x28 cell and 40x28 cell (which in -pixels are 256x224 and 320x224.) The video resolution is how many 8x8 tiles -are displayed on-screen. The vertical portion differs with PAL I believe, but -it that is not relevant. - Scroll A and Scroll B can have a number of different sizes which -obviously often cannot be all shown on-screen: 32x32, 32x64, 32x128, 64x32, -64x64, and 128x32. The Sega Programming FAQ says that 128x128 is possible, but -I don't think it is since that would take up 32KB of VRAM which would not -leave room for the other Scroll layer, the Window, or the patterns. - -Only a portion of the Scroll layer is visible on the screen. How it is -displayed can be represented by the following diagram: - -** Assuming the Scroll size is 64x64 and the screen 40x28, everything is - addressed in cell units (obviously not to scale) ** - - - = Scroll layer - * = Visible portion - - H0 H39 H63 - +****************************************--------------------+ - V0 |* V0 * | - |* * | - |* * | - |* * | - |* * | - |* V27 * | - |**************************************** | - | | - | | - | | - | | - | | - | | - V63 | | - +------------------------------------------------------------+ - -Thus you can see that there are tiles beyond the right limit of the visible -screen, and below as well. This method of having the layer larger than can be -displayed is for scrolling. The above is what would occur if one set the -Scroll size to 64x64 and the resolution to 40x28 without scrolling the screen -or anything. - If you are having problems emulating Scroll layers because everything -is shifted over you are probably forgetting to render the invisible parts of -the Scroll or to skip over them and on to the next visible row. I hope that -made sense. - - --- 6. Joypads -- - -** Begin Email ** -From: Joe Groff -To: Bart Trzynadlowski -Date: Sat, 15 Jan 2000 23:06:49 -0800 (PST) -Subject: Re: DGen/SDL - -> is there any good info anywhere on control pad interfacing? - -As far as I can tell, this is how the controller works. There are two one-byte -data sets: - v & 0x40: always set - v & 0x20: C - v & 0x10: B - v & 0x08: right - v & 0x04: left - v & 0x02: down - v & 0x01: up -and: - v & 0x40: always clear - v & 0x20: START - v & 0x10: A - v & 0x08: right - v & 0x04: left - v & 0x02: down - v & 0x01: up -By reading a word from 0xA10002 (for first controller) or 0xA10004 (for -second), the word will have one of the above bitmasks written to both bytes. -If you write a byte to 0xA10003(for 1st) or 0xA10005(for 2nd) with the 0x40 -bit set, you'll get the first set, otherwise you'll get the second. - -Example: - Player 1 is pressing left and the A and B buttons simultaneously. Player 2 - is pressing B, C, and START. As the game, in order to probe controller 1: - - I send byte 0x00 to 0xA10003 (or word 0x0000 to 0xA10002 :) - - I read a word from 0xA10002, which gives me 0x1414. From the lower table, - I see A and left are being pressed. - - I send byte 0x40 to 0xA10003. - - I read another word from 0xA10002. This time I get 0x5454, which from the - upper table means B and left are being pressed. - Similarly, to probe controller 2: - - I send byte 0x00 to 0xA10005. - - I read from 0xA10004, and get 0x2020. So START is being depressed. - of the controller! - - I send byte 0x40 to 0xA10005. - - I read from 0xA10004 again, get 0x7070, so B and C are being pressed. - -There's also a lot of odd code to handle 6-button controllers in DGen, but -as it's getting a bit late, I can't quite understand it. Hopefully this is -accurate and clear enough to at least get you started. -** End Email ** - -** Begin Email ** -From: ATani -To: Bart Trzynadlowski -Date: Sat, 15 Jan 2000 23:06:43 -0800 -Subject: Re: genesis tech question post - -Ok, Well on the genesis the joysticks are read in by the z80 and passed to -the 68000 chip via memory addresses: A10003 & A10005. - -If bit 6 of the Stored Controller 1 information is set then you return the -following information when reading Address: A10003 (Byte mode): - -Bit: Description: -0 Up -1 Down -2 Left -3 Right -4 B -5 C - -If Bit 6 is not set return the following: -Bit: Description: -4 A -5 Start - -Address A10005 is the same except values returned are for joystick port 2. - -The Stored data are in reference to the byte values written to A10003 and -A10005 (joystick port 1 and joystick port 2) -** End Email ** - -Flavio points out the information from ATani's email may be somewhat faulty: - -"The Z80 has nothing to do with joypad reading. Actually, I believe the Z80 -banker thingy will go wacko, should you attempt such a stunt. Gotta test -that." - - --- 7. Crash Course on the Genesis Security System and Common Don'ts -- - -** The following information is courtesy of Flavio ** - -Crash course in Genesis security: - -1) There must be either 'SEGA' or ' SEGA' in ASCII at offset 0x100 (256 -decimal.) - -2) If the four least significant bits of 0xA10001 are higher than zero, the -poor programmer must write 'SEGA' to 0xA14000. -Example: -MOVE.B $A10001, D0 -ANDI.B #$F, D0 -BEQ.S NO_VDP_LOCK -MOVE.L #'SEGA', $A14000. -NO_VDP_LOCK: -[Yer code here] - -Yes, I know many of you can't read 68K ASM yet, but I don't know how to do -this on Paul Lee's C compiler (or any other for that matter.) :/ - -A list of common Caveat Gennyptor's follows: - -- Be careful not to access forbidden addresses (see SEGA2.DOC), as the Genny -locks up instantly if you dare to touch them. -- Don't read from the VDP data port (C00000) if you have sent a -"VRAM/CRAM/VSRAM write" command (and vice versa.) -- The FM doesn't work if the Z80 is reset (their reset lines are wired -together.) -- Always have the Z80 busreq'ed before reading the joyports. -- Never attempt to read PSG ports. -- DMA transfers should be controlled by code placed at the Genny's work RAM -(0xFF0000-0xFFFFFF.) -- Don't attempt to transfer data to/from the VDP if a DMA is in progress. -- Z80 RAM _must_ be accessed in byte units. -- Don't toggle the joystick's select line more than four times per vertical -refresh, to ensure 6-button joypad compatibility. -- It takes at least 16 68K clock ticks for the joyport readouts to become -really stable, after you have toggled the aforementioned select line. - -Flavio has also pointed out one more important thing not to attempt: - -CLR, ST, and TAS cannot be used to access the C000xx range. (It's a -derivative of the "don't read with the VDP set to write" commandment.) - - --- 8. Emulating RAM and ROM w/ Starscream -- - -Often times, Genesis games do some odd tricks that can be buggers to emulate. -One of these is jumping backwards (which causes the 24-bit address to wrap -around to 0xFFFFFF) into work RAM to execute code. Since Starscream uses -32-bit data to handle addresses, this sort of maneuver would wrap around to -0xFFFFFFFF (32-bit) which is out of the Genesis address space. - Below is part of a Starscream context for emulating the Genesis work -RAM and ROM. I have also included the code for the handlers (Joe Groff helped -with this -- thanks Joe!) The dummy handlers are for regions of the address -space where accesses are ignored (I have removed all references to VDP and I/O -stuff since it would just clutter the example.) In reality, the data items -rom and ram would be dynamically allocated and would have to be added to these -structures during initialization time. They would be seen here as (unsigned) -NULL or (void *) NULL. - -struct STARSCREAM_PROGRAMREGION fetch_instructions[] = -{ - { 0x000000, 0x3fffff, (unsigned) rom }, - { 0xff0000, 0xffffff, (unsigned) ram - 0xff0000 }, - { 0xff000000, 0xff3fffff, (unsigned) ram - 0xff000000 }, - { 0xfff00000, 0xffffffff, (unsigned) ram - 0xfff00000 }, - { -1, -1, NULL } -}; -struct STARSCREAM_DATAREGION read_data_byte[] = -{ - { 0x000000, 0x3fffff, NULL, (void *) rom }, - { 0x400000, 0xffffff, StarscreamReadRAMByte, NULL }, - { -1, -1, NULL, NULL } -}; -struct STARSCREAM_DATAREGION read_data_word[] = -{ - { 0x000000, 0x3fffff, NULL, (void *) rom }, - { 0x400000, 0xdfffff, StarscreamFakeRead, NULL }, - { 0xe00000, 0xffffff, StarscreamReadRAMWord, NULL }, - { -1, -1, NULL, NULL } -}; -struct STARSCREAM_DATAREGION write_data_byte[] = -{ - { 0x000000, 0xdfffff, StarscreamFakeWrite, NULL }, - { 0xe00000, 0xffffff, StarscreamWriteRAMByte, NULL }, - { -1, -1, NULL, NULL } -}; -struct STARSCREAM_DATAREGION write_data_word[] = -{ - { 0x000000, 0xdfffff, StarscreamFakeWrite, NULL }, - { 0xe00000, 0xffffff, StarscreamWriteRAMWord, NULL }, - { -1, -1, NULL, NULL } -}; - -unsigned StarscreamReadRAMByte(unsigned address) -{ - return ram[(address ^ 1) & 0xffff]; -} - -unsigned StarscreamReadRAMWord(unsigned address) -{ - return *((unsigned short *) (ram + (address & 0xfffe))); -} - -void StarscreamWriteRAMByte(unsigned address, unsigned data) -{ - ram[(address ^ 1) & 0xffff] = data; -} - -void StarscreamWriteRAMWord(unsigned address, unsigned data) -{ - *((unsigned short *) (ram + (address & 0xfffe))) = data; -} - -unsigned StarscreamFakeRead(unsigned address) -{ - return 0; -} - -void StarscreamFakeWrite(unsigned address, unsigned data) -{ -} - -RAM is at 0xff0000-0xffffff and is mirrored every 64KB at 0xe00000-0xfeffff. - -Please see the Starscream documentation for information on how the core works. -At the time of this writing, Neill Corlett's page is at: - http://www4.ncsu.edu/~nscorlet/ - - --- 9. SMD ROM Format -- - -The SMD ROM format consists of a 512 byte header and the actual ROM image in -16KB chunks with the odd bytes at the beginning, and the even bytes at the -end. - - Header offsets: - 0x00: Number of 16KB blocks. This number is often incorrect and it - is wise to calculate it manually: (sizeof(file) - 512) / 16384 - 0x02: If 0, the ROM is standalone or the last part of a series. - Otherwise it is part of a split ROM set. - 0x08: 0xaa - 0x09: 0xbb - -Note: Most ROMs have 0xaa and 0xbb at 0x08 and 0x09 but a very small percentage -(about 1.28% by my calculations) do not conform to this. Those offsets are -useful for checking wether a ROM is in SMD format but be aware that they are -not always correct. - - Decoding a 16KB SMD blocke: (thanks to XnaK and Kuwanger) - 1. If the byte offset in the block is less than 8192, copy the byte - from the SMD block to the first unused odd offset in the decode - buffer. - 2. Otherwise, put it in the first unused even offset in the decode - buffer. - - Example block-decoding C function: (from my own GROM v0.75) - - void smd_bin(unsigned char *bin_block, unsigned char *smd_block) - { - int i, o = 1, e = 0; - - /* convert 16KB of SMD to BIN */ - for (i = 0; i < 8192; i++) - { - bin_block[o] = smd_block[i]; - bin_block[e] = smd_block[i + 8192]; - o += 2; - e += 2; - } - } - -Get GROM at: - http://www.powernet.net/~trzy - http://www.zophar.net - http://eidolon.psp.net - http://www.vintagegaming.com - ...or... - If all else fails, email me. - - diff --git a/source/docs/genplus.doc b/source/docs/genplus.doc deleted file mode 100644 index 1c36188..0000000 Binary files a/source/docs/genplus.doc and /dev/null differ diff --git a/source/docs/gensave.txt b/source/docs/gensave.txt deleted file mode 100644 index a6298ab..0000000 --- a/source/docs/gensave.txt +++ /dev/null @@ -1,312 +0,0 @@ - ---------------------------------------------- - SEGA GENESIS EMULATOR SAVE STATE REFERENCE - Third Edition (February 23, 2002) - Bart Trzynadlowski - ---------------------------------------------- - - ---------- - About ---------- - -The aim of this reference is to document the save state and backup RAM formats -of the various Sega Genesis emulators out there. Distribute this document -freely, but please keep it unmodified. If you use any of this information, -give credit to the contributors and me. - -The following people contributed directly and/or indirectly: - - - Charles MacDonald (supplied most of the Genecyst save state information) - - Jeffrey Quinn (found the SSP and USP in Genecyst states) - - Steve Snake (contributed Genecyst and KGen98 information) - - Langoustator (supplied YM2612 register information and some KGen98 data) - -More information on any of the formats, especially the KGen format, would be -appreciated. You can reach me at bart@dynarec.com or visit my web site at -http://www.dynarec.com/~bart. - -A "byte" is considered to be 8 bits, a "word" is 16 bits, and a "double word" -is 32 bits. - - Change History - -------------- - - February 12, 2002: Second Edition - - Added some Genecyst and KGen save state information - supplied by Steve Snake - - Corrected some typos - - April 11, 2001: First Edition - - Initial public release - - ------------------------------- - Genecyst Save State Format ------------------------------- - -The Genecyst save state format (GST) is used by various emulators. The files -use the extensions GS0-GS9 depending on the save slot. The information in this -section has been validated against Genecyst v0.32b. I believe Version X.XX is -very similar, if not the same, but I would appreciate confirmation. - - Offset Range: Description: - ------------- ------------ - 0x00000-0x00002 Signature: "GST" - 0x00006 0xE0, apparently used to validate file integrity - 0x00007 0x40, apparently used to validate file integrity - 0x00080-0x0009F 68K registers D0-D7 - 0x000A0-0x000BF 68K registers A0-A7 - 0x000C8-0x000CB 68K PC - 0x000D0-0x000D1 68K SR - 0x000D2-0x000D5 68K USP - 0x000D6-0x000D9 68K SSP - 0x000FA-0x00112 VDP registers (0-23, 1 byte each) - 0x00112-0x00191 CRAM - 0x00192-0x001E1 VSRAM - 0x001E4-0x003E3 YM2612 registers - 0x00404-0x00437 Z80 registers: AF, BC, DE, HL, IX, IY, PC, SP, AF', - BC', DE', HL', I (stored as a double word each.) R is - not supported and IM is presumed to be 1 - 0x00438 Z80 IFF1 (IFF2 is assumed to be the same) - 0x00439 Z80 status (0 = stopped, 1 = running), probably has - something to do with BUSREQ - 0x0043C-0x0043F Z80 window bank - 0x00474-0x002473 Z80 RAM - 0x02478-0x12477 68K RAM - 0x12478-0x22477 VRAM - - Steve Snake sent me word that 0x00434 (byte) is the Z80 I register and - 0x00437 (byte) is the Z80 interrupt mode. This conflicts with my data - which says 0x00434 is a double word where I is stored. I'm not sure which - is correct. - -All data is in little endian format except for 68K RAM, VSRAM, and VRAM, which -are in big endian format. Areas not mentioned should be kept 0. - -Locations 0x00006 and 0x00007 are not completely understood. Genecyst expects -them to be 0xE0 and 0x40, respectively. This has been observed in Genecyst -v0.20, v0.32b, and vX.XX. Many emulators avoid saving these bytes and Genecyst -refuses to load their states. - -The USP and SSP are tricky. If the supervisor bit in SR is set, only the USP -is saved at 0x000D2, the SSP at 0x000D6 is set to 0. If the supervisor bit is -cleared, both the USP at 0x000D2 and the SSP at 0x000D6 are saved. A7 is also -the current stack pointer (SSP if supervisor mode, USP if user mode.) - -Information on the YM2612 registers was sent to me by Langoustator who says it -is valid for Gens save states and is assumed to be valid for true Genecyst -states as well. None of it has been verified by me, but I'll assume it is -correct: - - - 0x001E4-0x00205: Apparently unused - - 0x00206-0x00213: General registers (not channel specific.) There are - only 9 registers at: 0x206, 0x208, 0x209, 0x20A, - 0x20B, 0x20C, 0x20E, and 0x20F. - - 0x00214-0x002E3: Channel-specific registers for channels 1-3. They are - stored in 4 byte groups with each group layed out like - this: - - First byte = Channel 1 - Second byte = Channel 2 - Third byte = Channel 3 - Fourth byte = Unused (0) - - The registers only appear to end at 0x0029B and the - rest of the area (from 0x0029C-0x002E3) is unused. - - - 0x002E4-0x00313: Apparently unused - - 0x00314-0x003E3: Channel-specific registers for channels 4-6. They are - stored in 4 byte groups like the channel 1-3 registers. - They end at 0x0039B and the rest of the area (from - 0x0039C-0x003E3) is unused. - -More information is needed, especially on (but not limited to) the following: - - - PSG state - - Internal VDP information (control port status, VDP RAM pointer, etc.) - - ------------------------------- - Genecyst Backup RAM Format ------------------------------- - -Genecyst saves backup RAM in files with the GSV extension. They simply contain -the backup RAM in little endian format. The files do not always have an even -number of bytes. - -Even if backup RAM only appears in the odd or even addresses, Genital saves -the unused bytes (which should be 0.) - -Those emulators which keep the 68K address space in little endian format can -support GSV files easily: simply copy the contents of the files unmodified to -the backup RAM area. - -A few emulators, including Genital, use the GSV format. - - ----------- - KGen98 ----------- - -There is no official information on KGen's save state format, so I decided to -take it upon myself to try reverse engineering the format. Due to a lack of -time, I have not been able to learn more than is shown here. It might be -enough to load states, but isn't enough to save them. - -The below information applies to KGen98 v0.4b, I do not know if it applies to -other versions of KGen and KGen98. Any more information is most welcome. - - Offset Range: Description: - ------------- ------------ - 0x00000-0x00002 Signature: "KSS" - 0x00003 Must be 0x1, also part of the signature - 0x00004-0x00005 ROM checksum, word sized - 0x00008-0x00096 Path to ROM (zero terminated), when path is at maximum - length, 0x96 contains the last character of the path - 0x00097 Always 0 - 0x00098-0x02097 Z80 RAM - 0x02098-0x12097 68K RAM - 0x12098-0x22097 VRAM - 0x22098-0x22117 CRAM - 0x22298-0x222E7 VSRAM - 0x2235C-0x2237B 68K registers D0-D7 - 0x2237C-0x2239B 68K registers A0-A7 - 0x2239C-0x2239F 68K SP (if supervisor mode: USP, if user mode: SSP) - 0x223A0-0x223A3 68K PC - 0x223A4-0x223A7 68K SR - 0x223A8-0x223AB Previous SR value (Steve says only the high byte is - necessary), used to detect changes between privilege - levels - 0x223AE-0x223C5 VDP registers (0-23, 1 byte each) - 0x2273E-0x227?? Data written to VDP control port - 0x22742-0x22743 Control port half: if only one word of a 2-word - command was written, it is stored here - 0x22748-0x22749 Current VDP RAM address - -The checksum, 68K RAM, VRAM, CRAM, and VSRAM are stored in big endian format. -Everything else is in little endian format. - -I believe location 0x2273E is a little endian double word. There is plenty of -important internal VDP and FM data kept at the end of the file. I haven't -found the meaning of all of it. Also, the path to the save state's ROM file is -saved near the beginning of the file. - - ------------------ - Genital v1.2+ ------------------ - -Starting with Version 1.2, Genital save state files use a version numbering -system independent from Genital itself. Save states with different major -version numbers are not compatible. The minor version number indicates changes -in the format which do not affect backwards compatibility. - -Version 1.0 of this new GNS format is described below: - - Offset Range: Description: - ------------- ------------ - 0x00000-0x00002 Signature: "GNS" - 0x00003 Format major version - 0x00004 Format minor version - 0x00005-0x00007 Reserved (always keep 0) - 0x00008-0x00057 68K registers and status (from Genital68K context) - 0x00058-0x00077 68K pending interrupts (from Genital68K context) - 0x00078-0x10077 68K RAM - 0x10078-0x20077 VRAM - 0x20078-0x200F7 CRAM - 0x200F8-0x20147 VSRAM - 0x20148-0x201A7 VDP registers (0-23; double word each) - 0x201A8-0x201BF VDP internal status data (taken directly from VDP - context: ctrlport_mode, access_mode, addr, addr_top, - dma_mode, and status_register; double word each) - 0x201C0-0x201C3 VDP horizontal interrupt timer - 0x201C4-0x201C7 Reserved (always keep 0) - 0x201C8-0x201CB Z80 BUSREQ - 0x201CC-0x201EB Z80 registers (word each: AF, BC, DE, HL, IX, IY, PC, SP, - AF', BC', DE', HL', IR, IM, IFF1, IFF2) - 0x201EC-0x221EB Z80 RAM - -Everything is stored in little endian format. - -The 68K registers and status come directly from the Genital68K context, occupy -a double word each, and are ordered: - - D0-D7, A0-A7, SP, SR, PC, status - -The "SP" relies on the privilege mode. If in supervisor mode, this is the USP -(and the SSP is in A7.) If in user mode, this is the SSP (and the USP is in -A7.) Please read the Genital68K (now Turbo68K) documentation for information -on what the "status" is (http://www.dynarec.com/~bart/turbo68k.) - -The first 7 elements pending interrupt array correspond to interrupt levels -1-7. Each element, a double word in size, contains the vector of the interrupt -that is pending. The eighth element is the number of interrupts pending. -Again, see the Genital68K documentation for more information. - -The VDP internal status comes directly from Genital's VDP context. The -"ctrlport_mode" indicates which part of a command the control port expects. If -0, it expects the first part, otherwise the second. The access_mode is just -the VDP's CD bits which indicate VRAM write, CRAM write, VSRAM write, VRAM -read, etc. The VDP RAM current address is stored in the "addr" element. Bits -15 and 14 of the VDP RAM address are stored in bits 1 and 0 of "addr_top." -These are used to emulate a peculiar feature of the VDP. The "dma_mode" stores -the DMA mode bits. The "status_register" is the VDP Status Register. - -The "horizontal interrupt timer" is the count-down timer which triggers -horizontal interrupts. - - ---------------------------- - Genital (v1.0 and v1.1) ---------------------------- - -The Genital save state format (GNS) was introduced in Genital v1.0 and was -completely changed by v1.2. Versions 1.0 and 1.1 used the format described -below. - - Offset Range: Description: - ------------- ------------ - 0x00000-0x0FFFF 68K RAM - 0x10000-0x1FFFF VDP VRAM - 0x20000-0x21FFF Z80 RAM - 0x22000-0x2207F VDP CRAM - 0x22080-0x220CF VDP VSRAM - 0x220D0-0x220EF 68K registers A0-A7 - 0x220F0-0x220F3 68K SP (if supervisor mode: USP, if user: SSP) - 0x220F4-0x22113 68K registers D0-D7 - 0x22114-0x22117 68K SR - 0x22118-0x2211B 68K PC - 0x2211C-0x2214F Z80 registers: AF, BC, DE, HL, IX, IY, PC, SP, AF', - BC', DE', HL', IR (stored as a double word each) - 0x22150-0x22153 Z80 BUSREQ - 0x22154-0x221B3 VDP registers (0-23, double word each) - 0x221B4-0x221B7 VDP control port mode - 0x221B8-0x221BB VDP RAM address pointer - 0x221BC-0x221BF VDP RAM access mode - 0x221C0-0x221C3 VDP DMA mode - 0x221C4-0x221C7 VDP Status Register - 0x221C8-0x221CB VDP HV counter - 0x221CC-0x221CF VDP Horizontal Interrupt timer - 0x221D0-0x221D3 VDP Control Port A15, A14 - 0x221D4-0x221DA Reserved (7 bytes; should be 0) - 0x221DB Major version number of Genital - 0x221DC Minor version number of Genital - 0x221DD-0x221DF Signature: "GNS" - -The 68K RAM, VRAM, CRAM, and VSRAM are stored in big endian format. Everything -else is in little endian format. - -The VDP RAM address pointer is the current VRAM, CRAM, or VSRAM address. The -VDP RAM access mode is just the CD bits in a VDP command which indicate -whether the VDP is in VRAM write mode, VRAM read mode, CRAM write mode, etc. - -The VDP Control Port mode indicates which part of the command the VDP is -expecting. This is the "pending flag" described by Charles MacDonald's VDP -document. The A15, A14 bits are those last written to the control port. When -the first word of an address set command is written, these bits are used to -fill in A15, A14. They are stored in bits 1 and 0 of the GNS double word. - -The major and minor version numbers reflect the version of Genital which -produced the save state. For example, if the state was created with Genital -v1.0, the major version would be 1 and the minor would be 0. The signature -must be "GNS" in ASCII or the save state will be deemed corrupt. diff --git a/source/docs/genvdp.txt b/source/docs/genvdp.txt deleted file mode 100644 index 48f91a3..0000000 --- a/source/docs/genvdp.txt +++ /dev/null @@ -1,1654 +0,0 @@ - - Sega Genesis VDP documentation - Version 1.5f (08/10/00) - - by Charles MacDonald - WWW: http://cgfm2.emuviews.com - - Unpublished work Copyright 2000 Charles MacDonald - - - This document is very preliminary and subject to change. - - - Changes from the last version: - - (v1.5f) - - Minor update on 68k -> VDP DMA transfers. (section 11) - (v1.5e) - - More information on VDP register sets. - - Added preliminary section numbers and table of contents. - - Revised todo list. - (v1.5d) - - Fixed sprite size byte layout. - - Listed a few games that overlap low and high priority sprites. - - Mentioned game problems regarding data port access. - (v1.5c) - - Verified DMA transfer wrapping. - - Fixed MSB/LSB mixup in DMA fill description. - - Added zero length DMA behavior. - - Mentioned results of writing during fills. - - Added VRAM address register wrapping. - (v1.5) - - Added shadow / hilight info. - - Added HV counter information. - - Added notes on odd byte access. - - Expanded register list. - - Rewrote DMA section. - - Did a little work on priority and patterns. - (v1.4) - - Described 8-bit port writes. - - Expanded VDP register programming section. - - Rewrote description of external interrupts. - - Removed 8-bit VRAM fill section. - - Added VDP pinout. - - Changed introduction and overview sections. - - Removed display size list. - - Added interrupts description. - (v1.3) - - Fixed sprite limitation count. - - Added details on blanking flags in status register. - - Added status register section. - - Added notes on VSRAM/CRAM fills. - - Added scrolling section. - - Added description of backdrop color register. - - Added description of mode set #3 register. - (v1.2) - - Completed most of the DMA section. - - Added sprite masking information. - - Verified bits 5-0 of reg 23 have no effect on VRAM fills. - - Fixed CD4 description. - (v1.1) - - Verified CD4 does not affect a 68K->VDP DMA transfer. - - Verified code and address registers retain their state after half of - a command word is written to the control port. - - Added display mode list. - - Added specific VDP RAM type info. - - Added sprite section. - - Verified register writes reset the pending flag. - - Added VDP port map. - - Verified byteswap behavior for VRAM writes. - - Verified no illegal codes allowed for CRAM writes. - - Verified A15-A7 of VSRAM address is ignored. - - Verified A0 of CRAM address is ignored. - - Verified A0 of VSRAM address is ignored. - - Verified writing to 'extra' VSRAM addresses has no effect. - - Verified ignored command word bits. - - Finalized info on palette control bit. - - Started basic control port decoding section. - - Added register #0, #1 descriptions. - - Mentioned plane A clipping in window register descriptions. - (v1.0) - - Initial draft. - - 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) - - ---------------------------------------------------------------------------- - Table of Contents - ---------------------------------------------------------------------------- - - 0.) Introduction - 1.) Overview - 2.) Display Modes - 3.) VDP port map - 4.) Interrupts - 5.) HV Counter - 6.) Status Register - 7.) VDP ports - 8.) VRAM - 9.) CRAM - 10.) VSRAM - 11.) DMA - 12.) Patterns - 13.) Background Layers - 14.) Priority - 15.) Sprites - 16.) Shadow / Hilight mode - 17.) VDP registers - 18.) VDP Pinout - - - ---------------------------------------------------------------------------- - 0.) Introduction - ---------------------------------------------------------------------------- - - This is a compilation of my notes on the Sega Genesis video display - processor. - - I wanted to write this because the existing information on the VDP is - very inadequate. Many of the subtle quirks and bugs are not explained. - - I'd like to thank the following people in alphabetical order for - providing information and being helpful: - - Bart Trzynadlowski - Christian Schiller - Flavio Morsoletto - Omar Cornut - Stephane Dallongeville - - Also thanks to Sardu and Steve Snake for genecyst and KGen98, which - were both used for devloping test programs. - - I am interested in finding somebody who has a Sega Genesis copier and - would be willing to run some test programs and report the results. - - ---------------------------------------------------------------------------- - 1.) Overview - ---------------------------------------------------------------------------- - - The Genesis VDP is derived from the Master System VDP, which in turn - was derived from the Texas Instruments TMS9918. As a result, the VDP is - programmed much like it's earlier counterparts. - - Interestingly enough, none of the Sega produced VDP's are similar to the - later VDP models made by Yamaha, which were also based upon the TMS9918. - - ---------------------------------------------------------------------------- - 2.) Display Modes - ---------------------------------------------------------------------------- - - To clarify naming conventions, here is a list of display modes used by - the various video chips mentioned: - - Mode 0 - TMS9918 specific - Mode 1 - TMS9918 specific - Mode 2 - TMS9918 specific - Mode 3 - TMS9918 specific - Mode 4 - SMS mode - Mode 5 - Genesis mode - - Supported mode list: - - TMS9918 - Modes 0, 1, 2, 3 - SMS - Modes 0, 1, 2, 3, 4 - Genesis - Modes 4, 5 (possibly 0 and others as well) - - If anybody has some information about how the Game Gear would fit into - this list, let me know. I assume it's identical to the SMS, but I don't - know about the TMS9918 compatability. (if any) - - ---------------------------------------------------------------------------- - 3.) VDP port map - ---------------------------------------------------------------------------- - - The VDP occupies addresses C00000h to C0001Fh. - - C00000h - Data port (8=r/w, 16=r/w) - C00002h - Data port (mirror) - C00004h - Control port (8=r/w, 16=r/w) - C00006h - Control port (mirror) - C00008h - HV counter (8/16=r/o) - C0000Ah - HV counter (mirror) - C0000Ch - HV counter (mirror) - C0000Eh - HV counter (mirror) - C00011h - SN76489 PSG (8=w/o) - C00013h - SN76489 PSG (mirror) - C00015h - SN76489 PSG (mirror) - C00017h - SN76489 PSG (mirror) - - ---------------------------------------------------------------------------- - 4.) Interrupts - ---------------------------------------------------------------------------- - - The VDP generates all interrupts for the 68000. The only hardware - interrupts available are 2, 4, and 6. - - Vertical interrupts - ------------------- - - If bit 5 (IE0) of register #1 is set, then a level 6 interrupt will occur - when the V counter is at line E0h, roughly at H counter cycle 08h. At this - point in time, the vertical interrupt occurance flag (bit 7) will be set - in the status register. - - Line interrupts - --------------- - - The VDP has a counter that is decremented on every line. When the counter - has expired, and if bit 4 (IE1) of register #0 is set, then a level 4 - interrupt will occur. - - The counter is loaded with the contents of register #10 in the following - situations: - - - Line zero of the frame. - - When the counter has expired. - - Lines 225 through 261. (note that line 224 is not included) - - The counter is *not* loaded when register #10 is written to. - - Note that line interrupts are processed *before* vertical interrupts - within a scanline. If you trigger a line interrupt to occur on line E0h, - then the level 4 line interrupt will be taken by the 68000, not the - level 6 vertical interrupt. - - External interrupts - ------------------- - - Pin 7 of each of the three I/O ports is called the TH pin. It is connected - to the VDP. When the state of TH is changed, the following events happen: - - - If bit 7 of the control register for the associated I/O port is set, - and bit 3 of register #11 (IE2) is set, then the VDP will generate - a level 2 interrupt. - - - If bit 1 of VDP register #0 is set, the contents of the HV counter will - be latched. - - A common use for these features are in a light gun game. The light gun - can change the state of TH, which will freeze the HV counter, and then - the level 2 interrupt subroutine can read the HV counter and also - communicate with the light gun to get information like what buttons - were pressed. This is pretty much how Sega's 'Menacer' device works. - The Konami 'Justifier' light gun works on similar principles. - - I don't know if the HV counter resumes normal operation after the first - read, or if the HV counter latch bit has to be cleared and set again. - - Some games will enable the HV counter latch and never read the HV counter, - let alone use any special peripherals. (Shadow of the Beast II) - - You cannot force an external interrupt by changing the state of TH - through software. (e.g. in the normal sequence of reading the gamepad, - TH is set and cleared - this does not cause an interrupt if interrupts - are enabled) - - The data direction for TH (which corresponds to bit 6 of the data and - control registers) must be configured as an input for a peripheral - to cause an interrupt. - - ---------------------------------------------------------------------------- - 5.) HV Counter - ---------------------------------------------------------------------------- - - The HV counter returns the vertical and horizontal position of the - television's raster beam. - - Reading the HV counter will return the following data: - - VC7 VC6 VC5 VC4 VC3 VC2 VC1 VC0 (D15-D08) - HC8 HC7 HC6 HC5 HC4 HC3 HC2 HC1 (D07-D00) - - VCx = Vertical position in lines. - HCx = Horizontal position in pixels. - - According to the manual, VC0 is replaced with VC8 when in interlace mode 2. - - For 8-bit reads, the even byte (e.g. C00008h) returns the V counter, and - the odd byte (e.g. C00009h) returns the H counter. - - The V counter counts up from 00h to EAh, then it jumps back to E5h and - continues counting up to FFh. This allows it to cover the entire 262 line - display. - - The H counter counts up from 00h to E9h, then it jumps back to 93h and - continues counting up to FFh. This allows it to cover an entire 342 pixel - line. - - The H counter description is based upon known information about the SMS - VDP's H counter. The SMS has a 256x192 display, and each line consists of - 342 pixels. (that includes blanking, retrace, etc.) The description - *could* be accurate for the Genesis' 32-cell display mode. This is not - the case for the 40-cell display, where I would assume the H counter jumps - back farther at a later point in the count-up. - - In terms of emulation, I have found that turning the elapsed 68000 cycle - count into a pixel offset for the current scan line seems to provide a - reasonable return value for the H counter. However, I am quite positive - a single scanline consists of more pixels than just 256 or 320, and - in addition the 'jump-back' described above is not taken into account. - In all honesty this is a hack, not a solution. - - I would appreciate any additional information on the HV counter. - - ---------------------------------------------------------------------------- - 6.) Status Register - ---------------------------------------------------------------------------- - - Reading the control port returns a 16-bit word that allows you to observe - various states of the VDP and physical display. - - d15 - Always 0 - d14 - Always 0 - d13 - Always 1 - d12 - Always 1 - d11 - Always 0 - d10 - Always 1 - d9 - FIFO Empty - d8 - FIFO Full - d7 - Vertical interrupt pending - d6 - Sprite overflow on current scan line - d5 - Sprite collision - d4 - Odd frame - d3 - Vertical blanking - d2 - Horizontal blanking - d1 - DMA in progress - d0 - PAL mode flag - - Presumably bit 0 is set when the system display is PAL; however this same - information can be read from the version register (part of the I/O - register group - not the VDP), so maybe this bit reflects the state of - having a 240-line display enabled. - - Bit 1 is set for the duration of a DMA operation. This is only useful for - fills and copies, since the 68000 is frozen during 68k -> VDP transfers. - - Bit 2 returns the real-time status of the horizontal blanking signal. - It is set at H counter cycle E4h and cleared at H counter cycle 08h. - - Bit 3 returns the real-time status of the vertical blanking signal. - It is set on line E0h, at H counter cycle AAh, and cleared on line FFh, - at H counter cycle AAh. - - (Note: For both blanking flag descriptions, the H counter values are - very likely different for 32-cell and interlaced displays; they were - taken from a test with a 40-cell screen.) - - Bit 4 is set when the display is interlaced, and in the odd frame, - otherwise it is cleared in the even frame. This applies to both - interlace modes. - - Bit 5 is set when any sprites have non-transparent pixels overlapping one - another. This may hold true for sprites outside of the display area too. - This bit is most likely cleared at the end of the frame. - - Bit 6 is set when too many sprites are on the current scan line, meaning - when the VDP parses the 21st sprite in 40-cell mode or the 17th sprite in - 32-cell mode from the sprite list. - This bit is most likely cleared at the end of the frame. - - Bit 7 is set when a vertical interrupt occurs. This happens at line E0h, - roughly after H counter cycle 08h. I do not know under what conditions - it is cleared, presumably at the end of the frame. Reading the control - port does not clear this bit. (this could be incorrect) - - Bit 8 and 9 (FULL and EMPTY flags, respectively) are related to the FIFO; - here's what Flavio Morsoletto has to say about their use: - - "The FIFO can hold up to four 16-bit words while the VDP's busy - parsing data from VRAM. Once the 68K has written the fourth word, - FULL is raised. If the processor attempts to write one more time, it - will be frozen (/DTACK high) until the FIFO unit manages to deliver - the first stacked word to its rightful owner. EMPTY only goes 1 when - there is nothing on the stack. The intermediate state is signaled by - both of them showing 0." - - This situation only occurs during the active display period, as the - data port can be written to as many times as needed during blanking. - - I've noticed most emulators keep the EMPTY flag set, so it appears as - if the FIFO was always empty instead of being in the neutral state. This - is probably for games that would normally check and find the FIFO in a - neutral state, then write data and expect to poll the FULL flag afterwards. - - ---------------------------------------------------------------------------- - 7.) VDP ports - ---------------------------------------------------------------------------- - - The VDP is programmed entirely through the control and data ports. - Data written to the control port is formatted, so the VDP will know - how to interpret the data it recieves. - - You can divide control port data into two categories; 16-bit register sets - and 32-bit command words. - - Programming VDP registers - ------------------------- - - Any one of the 23 VDP registers can be programmed by writing 16 bits of - data to the control port. The data written has the following format: - - 1 0 ? R04 R03 R02 R01 R00 (D15-D8) - D07 D06 D05 D04 D03 D02 D01 D00 (D7-D0) - - Rxx = VDP register select (00-1F) - Dxx = VDP register data (00-FF) - - Writing to non-existant VDP registers has no effect. - - Bits 15 and 14 must be set to 1 and 0 respectively, otherwise the write - will be treated as the first half of a command word. The state of bit 13 - does not matter. - - Here's an example of programming one register: - - ; Set border color to palette $3, index $F - move.w #$873F, $00C00004 - - Since the 68000 treats 32-bit memory access as two 16-bit operations, - you can program two registers at once: - - ; Set split point bits for both window registers - move.w #$91809280, $00C00004 - - Accessing VDP RAM - ----------------- - - You can access VRAM, CRAM, or VSRAM by writing a 32-bit command word to - the control port. The data written has the following format: - - CD1 CD0 A13 A12 A11 A10 A09 A08 (D31-D24) - A07 A06 A05 A04 A03 A02 A01 A00 (D23-D16) - ? ? ? ? ? ? ? ? (D15-D8) - CD5 CD4 CD3 CD2 ? ? A15 A14 (D7-D0) - - CDx = VDP code (0-3F) - Axx = VDP address (00-FFFF) - - The state of D15 through D8, D3, and D2 are ignored. - - The VDP has an address and code register. They are used in conjunction to - handle data port accesses. The address register provides an offset into - VDP RAM to write or read data from. The code register specifies if - data port accesses will be reads or writes, and the kind of VDP RAM - to perform these operations on. - - In order for the VDP to know if the first or second 16-bit half of the - command word has been written to the control port, it maintains an internal - write-pending flag. This flag is updated when these conditions are met: - - - It is set when the first half of the command word is written. - - It is cleared when the second half of the command word is written. - - It is cleared when the data port is written to or read from. - - It is cleared when the control port is read. - - It is perfectly valid to write the first half of the command word only. - In this case, _only_ A13-A00 and CD1-CD0 are updated to reflect the new - values, while the remaining address and code bits _retain_ their former - value. - - You cannot write to a VDP register if the pending flag is set to one, - since the VDP is expecting the 2nd half of a command word. - - Writing to a VDP register will clear the code register. Games that rely - on this are Golden Axe II (will display missing SEGA logo) and Sonic 3D. - (will show intro movie in wrong colors for a few frames) It is not known - if the address register is cleared as well, but the TMS9918 manual - indicates that this is so, perhaps it applies to the Genesis as well. - - Here is a table of code register settings: - - Bits CD3-CD0 - 0000b : VRAM read - 0001b : VRAM write - 0011b : CRAM write - 0100b : VSRAM read - 0101b : VSRAM write - 1000b : CRAM read - - You cannot write data after setting up a read operation, or read data - after setting up a write operation. The write or read is ignored. - - CD4 is only set for the the VRAM copy DMA mode. - For data port accesses and 68k to VDP DMA, the state of CD4 is ignored. - - Setting CD5 will trigger a DMA operation. - - 8-bit port access - ----------------- - - Doing an 8-bit write to the control or data port is interpreted by - the VDP as a 16-bit word, with the data written used for both halfs - of the word. - - For instance, the following code writes 87h to VDP register #7: - - ; VDP sees data as 8787h - move.b #$87, $00C00004 - - This also applies to the data port. The following code sets CRAM entry - zero to pink: - - ; VDP sees data as 0E0Eh - move.l #$C0000000, $00C00004 - move.b #$0E, $00C00000 - - It's important to realize that a distinction between 8-bit and 16-bit VRAM - fills do not exist. There is only one type of fill, and depending on how - you write to the data port will determine the kind of data used in the fill. - - Odd addresses (e.g. C00007h, C00001h) function identically to even addresses - in the case of 8-bit writes. For instance, writing data to anywhere within - C00004h-C00007h would go to the control port. - - Miscellaneous - ------------- - - I've found that some games will write VDP register data to the data port, - after the code and address registers have been set to zero. I've confirmed - that this is simply a bug on the programmer's behalf, you cannot program - the VDP registers in this way. - - Games that do this include Alien Soldier and Eternal Champions. - - Some games also set up VRAM reads and try to write to VRAM; this is - also pointless as data written after a VRAM read command is issued - is ignored by the VDP. The unlicensed version of Populous does - this, along with Golden Axe II. - - ---------------------------------------------------------------------------- - 8.) VRAM - ---------------------------------------------------------------------------- - - The VDP is connected to 64K of video RAM. It is accessed as 65535 8-bit - bytes or 32768 16-bit words through the data port. - - VRAM is multipurpose; it can store pattern data, horizontal scroll data, - sprite tables, and background name tables. - - When writing 16-bit data to VRAM, having address bit 0 set will swap - the upper and lower bytes of the data written. - - The address register wraps past address FFFFh. - - ---------------------------------------------------------------------------- - 9.) CRAM - ---------------------------------------------------------------------------- - - The VDP has 64x9 bits of on-chip color RAM. It is accessed as 64 16-bit - words through the data port. Each word has the following format: - - ----bbb-ggg-rrr- - - r = Red component (0-7) - g = Green component (0-7) - b = Blue component (0-7) - - This allows for a total of 512 possible colors, with 64 colors stored - in CRAM at any given time. - - When accessing CRAM, only address bits 6 through 1 are valid. The high-order - address bits are ignored. Since CRAM is word-wide, address bit zero has - no effect. - - The address register wraps past address 7Fh. - - ---------------------------------------------------------------------------- - 10.) VSRAM - ---------------------------------------------------------------------------- - - The VDP has 40x10 bits of on-chip vertical scroll RAM. It is accessed as - 40 16-bit words through the data port. Each word has the following format: - - ------yyyyyyyyyy - - y = Vertical scroll factor (0-3FFh) - - When accessing VSRAM, only address bits 6 through 1 are valid. - The high-order address bits are ignored. Since VSRAM is word-wide, address - bit zero has no effect. - - Even though there are 40 words of VSRAM, the address register will wrap - when it passes 7Fh. Writes to the addresses beyond 50h are ignored. - - ---------------------------------------------------------------------------- - 11.) DMA - ---------------------------------------------------------------------------- - - The VDP can be programmed to move data into, copy, and fill sections of - VDP RAM, meaning VRAM, CRAM, and VSRAM. These functions are referred to - as Direct Memory Access. (DMA) - - Overview - -------- - - Bits 7 and 6 of register #23 select the type of DMA operation: - - D7 D6 - 0 ? : 68K -> VDP RAM transfer (D6 is bit 24 of source address) - 1 0 : VRAM fill - 1 1 : VRAM copy - - Bit 4 of register #1 will enable DMA operations when set. - - Some games will attempt to do DMA when it is disabled, including Phelios - and Rocket Knight Adventures. - - When doing 68K -> VDP RAM transfers, the 68000 is frozen. For VRAM fills - and copies, the 68000 runs normally, but you can only read the control - port, HV counter, and write to the PSG register. - - Writing to the control or data port during a VRAM fill seems to corrupt - the VDP registers and VRAM. - - When the length field is set to zero, the length is treated as FFFFh. - - 68000 to VDP RAM - ---------------- - - This is used to transfer data out of the 68000's address space into VRAM, - CRAM, or VSRAM. - - Registers 19, 20, specify how many 16-bit words to transfer: - - #19: L07 L06 L05 L04 L03 L02 L01 L00 - #20: L15 L14 L13 L12 L11 L10 L08 L08 - - Note that a length of 7FFFh equals FFFFh bytes transferred, and a length - of FFFFh = 1FFFF bytes transferred. - - Registers 21, 22, 23 specify the source address on the 68000 side: - - #21: S08 S07 S06 S05 S04 S03 S02 S01 - #22: S16 S15 S14 S13 S12 S11 S10 S09 - #23: 0 S23 S22 S21 S20 S19 S18 S17 - - If the source address goes past FFFFFFh, it wraps to FF0000h. - (Actually, it probably wraps at E00000h, but there's no way to tell as - the two addresses are functionally equivelant) - - When doing a transfer to CRAM, the operation is aborted once the address - register is larger than 7Fh. The only known game that requires this is - Batman & Robin, which will have palette corruption in levels 1 and 3 - otherwise. This rule may possibly apply to VSRAM transfers as well. - - A transfer is started when the following command word is written: - - CD1 CD0 A13 A12 A11 A10 A09 A08 (D31-D24) - A07 A06 A05 A04 A03 A02 A01 A00 (D23-D16) - ? ? ? ? ? ? ? ? (D15-D8) - 1 0 0 CD2 ? ? A15 A14 (D7-D0) - - CD2-CD0 specify the type of VDP RAM to write to: - - 001b - VRAM - 011b - CRAM - 101b - VSRAM - - The following events occur after the command word is written: - - - 68000 is frozen. - - VDP reads a word from source address. - - Source address is incremented by 2. - - VDP writes word to VRAM, CRAM, or VSRAM. - (For VRAM, the data is byteswapped if the address register has bit 0 set) - - Address register is incremented by the value in register #15. - - Repeat until length counter has expired. - - 68000 resumes operation. - - When a transfer is done out of the ROM area ($000000-3FFFFF), the machine - will lock up unless the write that triggers the DMA operation is done - using RAM. - - Usually this means putting the command word or the latter half of the - command word in RAM and moving that into the control port, putting - the command word on the stack and moving that into the control port, - or having the instruction that moves the command word into the control - port execute out of RAM. - - VRAM fill - --------- - - VRAM fills are used to repeatedly write a given data value to multiple - sequential addresses in VRAM. - - Registers 19, 20, specify how many 8-bit bytes to fill: - - #19: L07 L06 L05 L04 L03 L02 L01 L00 - #20: L15 L14 L13 L12 L11 L10 L08 L08 - - The address bits in registers 21, 22, 23 are ignored: - - #21: ? ? ? ? ? ? ? ? - #22: ? ? ? ? ? ? ? ? - #23: 1 0 ? ? ? ? ? ? - - A VRAM fill is started when the following command word is written: - - 0 1 A13 A12 A11 A10 A09 A08 (D31-D24) - A07 A06 A05 A04 A03 A02 A01 A00 (D23-D16) - ? ? ? ? ? ? ? ? (D15-D8) - 1 0 0 0 ? ? A15 A14 (D7-D0) - - Any write to the data port will then start a VRAM fill. The LSB of the - data is written to the address specified, then the MSB is written to - the adjacent address. The address register is incremented by the value - in VDP register 15, and the upper 8 bits are written again to the next - adjacent address, and so on. - - Here is some "C" pseudocode to illustrate a VRAM fill: - - void vram_fill(int data) - { - /* Write lower byte to address specified */ - vram[address] = (data >> 0) & 0xFF; - - do { - /* Write upper byte to adjacent address */ - vram[address ^ 1] = (data >> 8) & 0xFF; - - /* Increment address register */ - address += vdp_reg[15]; - } while(--length) - } - - Games that require accurate VRAM fill emulation include Thunder Force IV, - Contra Hard Corps, Revenge of Shinobi, Taiga Drama, and Sword of Vermillion. - - VRAM copy - --------- - - VRAM copies are used to copy blocks of VRAM data. - - Registers 19, 20, specify how many 8-bit bytes to copy: - - #19: L07 L06 L05 L04 L03 L02 L01 L00 - #20: L15 L14 L13 L12 L11 L10 L08 L08 - - The address bits in register 23 are ignored. - Registers 21, 22 specify the source address in VRAM: - - #21: S07 S06 S05 S04 S03 S02 S01 S00 - #22: S15 S14 S13 S12 S11 S10 S09 S08 - #23: 1 1 ? ? ? ? ? ? - - A VRAM copy is started when the following command word is written: - - 0 0 A13 A12 A11 A10 A09 A08 (D31-D24) - A07 A06 A05 A04 A03 A02 A01 A00 (D23-D16) - ? ? ? ? ? ? ? ? (D15-D8) - 1 1 0 0 ? ? A15 A14 (D7-D0) - - The VDP will read a byte from the source address which is then incremented - by one. The data will then be written to the destination address, which - is incremented by register #15. - - Games that use VRAM copies include Aleste, Bad Omen, and Viewpoint. - - Transfer capacity - ----------------- - - The VDP can access memory a certain number of times on each line of the - display. This is severely limited during the active display period, since - the VDP also needs to update the screen, leaving less memory accesses - left for DMA. - - According to the manual, here's a table that describes the transfer - rates of each of the three DMA types: - - DMA Mode Width Display Transfer Count - ----------------------------------------------------- - 68K > VDP 32-cell Active 16 - Blanking 167 - 40-cell Active 18 - Blanking 205 - VRAM Fill 32-cell Active 15 - Blanking 166 - 40-cell Active 17 - Blanking 204 - VRAM Copy 32-cell Active 8 - Blanking 83 - 40-cell Active 9 - Blanking 102 - - 'Active' is the active display period, 'Blanking' is either the vertical - blanking period or when the display is forcibly blanked via register #1. - - The above transfer counts are all in bytes, unless the destination is - CRAM or VSRAM for a 68K > VDP transfer, in which case it is in words. - - Miscellaneous - ------------- - - I don't know if the source address register and length counter are actually - updated during a DMA operation. I doubt it, but in theory you could have - a sequence like this: - - move.l #$94109300, $00C00004 ; length = 4k words - move.l #$96009500, $00C00004 - move.l #$97708F02, $00C00004 ; src = E00000h, inc = 02h - move.w #$40000003, $00C00004 ; VRAM write to C000h - ; 8k is transferred to VRAM C000h from RAM E00000h - - move.w #$60000003, $00C00004 ; VRAM write to E000h - ; 8k is transferred to VRAM E000h from RAM E02000h - - You can make VRAM fills affect CRAM or VSRAM by changing the CD2-CD0 bits - to the appropriate RAM type, just like how 68K -> VDP transfers work. - Due to the limited way this was tested, I can't say how exactly the fill - data is written; CRAM and VSRAM are word-wide, while VRAM is byte-wide, - to there's bound to be some differences. I'd assume the results are - the same as normal byte-wide data port access, where both the LSB and - MSB of each word are set to the same 8-bit data written. - - In the case of a VRAM fill, the CD2-CD0 bits are set to the same value - required for a VRAM write. In the same vein, VRAM copies have the code - bits set to the same setting as a VRAM read. Maybe changing the code - register would allow copies within CRAM and VSRAM? Or perhaps the code - bits only select the source address? (Not that a CRAM > VRAM copy is - particularly useful, but there you go.) - - ---------------------------------------------------------------------------- - 12.) Patterns - ---------------------------------------------------------------------------- - - All background and sprite graphics are made up of patterns. A pattern is - an 8x8 or 8x16 (interlace mode 2 only) pixel block that is made up of - fifteen colors. - - Patterns are stored in VRAM. Each pixel is represented by four bits, - meaning there are four bytes (4 bits * 8 pixels = 4 bytes) per line of - the pattern, and 32 or 64 bytes per pattern, depending if the pattern - is 8x8 or 8x16. - - Unlike other VRAM data that is stored in a specific table, patterns can - be placed anywhere. Even in the parts of other tables that aren't being - used, like a name table or sprite attribute table. - - A pixel within a pattern that uses value zero isn't shown. It acts as a - transparency indicator. - - ---------------------------------------------------------------------------- - 13.) Background Layers - ---------------------------------------------------------------------------- - - The VDP manages two background layers, called plane A and plane B. - - Name Tables - ----------- - - There are three tables stored in video RAM that define the layout for - planes A, B, and W. - - Each table is a matrix of 16-bit words. Each word has the following format: - - pccvhnnnnnnnnnnn - - p = Priority flag - c = Palette select - v = Vertical flip - h = Horizontal flip - n = Pattern name - - The pattern name is the upper 11 bits of the physical address of pattern - in video RAM. Bit zero of the name is ignored in interlace mode 2. - - The vertical and horizontal flip flags tell the VDP to draw the pattern - flipped in either direction. - - The palette select allows the pattern to be shown in one of four - 16-color palettes. - - The priority flag is described later. - - The name tables for plane A and B share the same dimensions. The name - table size cannot exceed 8192 bytes, so while a 64x64 or 128x32 name - table is allowed, a size of 128x128 or 64x128 is invalid. - - The name table for plane W is 32x32 in 32-cell mode, and 64x32 in 40-cell - mode. This size is fixed and is entirely dependant on the display width. - - Window - ------ - - The window plane operates differently from plane A or B. It can be thought - of a 'replacement' for plane A which is used under certain conditions. - That said, plane A cannot be displayed in any area where plane W is - located, it is impossible for them to overlap. - - Registers 17 and 18 define an area which the window is restricted to. - - In terms of priority and intensity calculation for shadow / hilight mode, - plane W is treated _exactly_ the same as plane A. - - Horizontal Scrolling - -------------------- - - The horizontal scroll table holds the scroll value for every line of - both planes A and B, that can be positioned anywhere within video RAM. - - Each entry of the scroll table is a 16-bit word. It has the following - format: - - ------xxxxxxxxxx - - x = Horizontal scroll value (0-3FFh) - - Bits D15 through D10 are ignored by the VDP. - - The lower three bits of the scroll value provide a pixel offset into each - column comprised of one pattern. The upper seven bits provide an offset - into each column of the name table (0-127). - - When the scroll value is larger than the width of the playfield, the - display wraps horizontally. - - Scroll values for planes A and B are stored in an interleaved fashion. - Entry #0 of the table is for plane A, entry #1 is for plane B, and this - repeats for the entire length of the table. - - The manual says the scroll table is 960 bytes in size, - and this seems like an accurate figure, considering the scroll table - address bits suggest the table can be 1024 bytes. - - However, I do not know what happens in double-resolution interlace - mode. To provide a scroll entry for both planes on every line, a total - of 1920 bytes would be needed. (480 lines x 2 planes x 2 bytes per line) - - Here is some "C" pseudocode to illustrate how the VDP reads the scroll - table depnding on the settings of bits 0 and 1 of register #11: - - void get_scroll(int line, int *scroll_a, int *scroll_b) - { - switch(vdp_reg[11] & 3) - { - case 0x00: /* Full screen */ - *scroll_a = *(word *)vram[hscb + 0]; - *scroll_b = *(word *)vram[hscb + 2]; - break; - - case 0x01: /* First eight lines */ - *scroll_a = *(word *)vram[hscb + ((line & 7) * 2) + 0]; - *scroll_b = *(word *)vram[hscb + ((line & 7) * 2) + 2]; - break; - - case 0x02: /* Every row */ - *scroll_a = *(word *)vram[hscb + ((line & ~7) * 2) + 0]; - *scroll_b = *(word *)vram[hscb + ((line & ~7) * 2) + 2]; - break; - - case 0x03: /* Every line */ - *scroll_a = *(word *)vram[hscb + (line * 2) + 0]; - *scroll_b = *(word *)vram[hscb + (line * 2) + 2]; - break; - } - } - - A scroll mode setting of 01b is not valid; however the unlicensed version - of Populous uses it. This mode is identical to per-line scrolling, however - the VDP will only read the first sixteen entries in the scroll table for - every line of the display. - - ---------------------------------------------------------------------------- - 14.) Priority - ---------------------------------------------------------------------------- - - The VDP manages a fairly complex system of priorities between the two - background layers and sprites. The basic ordering is: - - - (back) (front) - A > B > C > D > E' > F' > G' - - ' = Denotes high priority - A = Backdrop color - B = Low priority plane B - C = Low priority plane A - D = Low priority sprites - E = High priority plane B - F = High priority plane A - G = High priority sprites - - The sprite priority bit does not affect inter-sprite priority, only the - relation between background data. Low priority sprites *can* overlap high - priority sprites. Games that do this to mask other sprites include - Castlevania Bloodlines, Raiden Trad, and Alien Soldier. - - ---------------------------------------------------------------------------- - 15.) Sprites - ---------------------------------------------------------------------------- - - The Genesis can display a total of eighty 32x32 15-color sprites. - There are of course various restrictions on the display capacity, based - on current configuration of the VDP. - - Sprite Attribute Table - ---------------------- - - All sprite data is stored in a region of VRAM called sprite attribute table. - The table is 640 bytes in size. Each 8-byte entry has the following format: - - Index + 0 : ------yy yyyyyyyy - Index + 2 : ----hhvv - Index + 3 : -lllllll - Index + 4 : pccvhnnn nnnnnnnn - Index + 6 : ------xx xxxxxxxx - - y = Vertical coordinate of sprite - h = Horizontal size in cells (00b=1 cell, 11b=4 cells) - v = Vertical size in cells (00b=1 cell, 11b=4 cells) - l = Link field - p = Priority - c = Color palette - v = Vertical flip - h = Horizontal flip - n = Sprite pattern start index - x = Horizontal coordinate of sprite - - Linking - ------- - - The VDP draws sprites in a front-to-back order, starting with sprite zero. - The 7-bit link field in each list entry is an index to the next entry of - the sprite that will be drawn. If the link field is zero, then no more - sprites will be drawn after the current sprite. Here's an example: - - Sprite #00 has a link field of 2 - Sprite #01 has a link field of 7 - Sprite #02 has a link field of 4 - Sprite #03 has a link field of 0 - Sprite #04 has a link field of 3 - Sprite #05 has a link field of 2 - - In this case, sprites #00, #02, #04, #03 will be drawn, in that order. - - Coordinate System - ----------------- - - Sprites are positioned in a virtual 512x512 space. The display starts at - coordinate 128, 128, and takes up a space equal to the size of the physical - display. (usually 256x224 or 320x224) This system is convenient for - programmers; unwanted sprites can easily be hidden off screen, and sprites - can be shown partially at the top and left screen edges. - - Sprite masking, mode 1 - ---------------------- - - If a sprite has an X coordinate of zero, and has a Y coordinate that - is within range of the display, then all sprites of lower priority - will not be displayed on the lines which the sprite takes up. - - The height of the sprite is determined by the vertical size bits in - the sprite attributes; other factors like horizontal size, pattern data - used, priority bit, and color palette have no effect. - - For instance, an 8x32 sprite at coordinates 0, 128, that was sprite #4 - in the list would stop all sprites onwards for lines zero to 31 from - being shown. However, sprites #0 through #3 could still be displayed - in this area. - - Sprite masking, mode 2 - ---------------------- - - If a sprite has an X coordinate of one, the former rule is invalid. Low - priority sprites will only be masked if a sprite with an X coordinate of - zero _also_ has a sprite with an X coordinate of one on the _same_ line. - - This 'mode' is enabled when the VDP first parses a sprite with an X - coordinate of one. It is reset at the end of the frame. - - To my knowledge, the only game which uses this masking mode is Galaxy - Force II. Because of this, I cannot ensure my description is accurate for - other games which may use it. - - Sprite Drawing Limitations - -------------------------- - - The VDP will stop drawing sprites under the following conditions: - - - The 80th sprite has been drawn in 40-cell mode. - - The 64th sprite has been drawn in 32-cell mode. - - Twenty sprites on the same scanline have been drawn in 40 cell mode. - - Sixteen sprites on the same scanline have been drawn in 32 cell mode. - - 320 pixels worth of sprite data has been drawn on the same scanline - in 40 cell mode. - - 256 pixels worth of sprite data has been drawn on the same scanline - in 32 cell mode. - - The currently drawn sprite has a link field of zero. - - Sprites that are outside of the physical display area are still taken - into account. - - Link settings that create an 'infinite loop' or that have self-referencing - will not cause any unforseen problem, these kinds of loops will be broken - out of when the above sprite limitations are eventually reached. - - Because so many sprites can be shown on a single line, some games will - fill the entire display with sprites for a 'fake' third background layer. - Games that do this include 'Red Zone' by Zyrinx. - - ---------------------------------------------------------------------------- - 16.) Shadow / Hilight mode - ---------------------------------------------------------------------------- - - Shadow / hilight mode allows more colors to be displayed on screen. - - These additional colors are selected based upon the priority settings - for a background tile or sprite, and when certain kinds of sprite pixels - overlap background pixels. - - Background - ---------- - - Background tiles are shown at half intensity, or at normal intensity - if their priority bit is set. - - In the latter case, this affects all other graphics elements in the - region (usually 8x8) that the tile takes up, regardless of the tile - containing opaque pixels or not. Meaning that the backdrop color, other - background plane, and sprites will be forcibly shown at normal intensity - in a given area if a background tile has it's priority bit set. - - For instance, Ranger-X has both background layers and all sprites set - to low priority. A column in plane A uses high priority transparent - tiles. The result is that any sprites passing within that column, as - well as the plane B tiles that scroll behind it, are all shown at - normal intensity. - - Sprites - ------- - - Depending on the priority setting, sprites are shown at normal or half - intensity just like background tiles. - - Colors 0Eh, 1Eh, 2Eh, are always shown at normal intensity regardless of - priority. I'd say this a bug rather than a feature. - - Any pixel in a sprite that uses colors 3Eh or 3Fh is treated specially: - - Pixels with color 3Eh are not drawn. Instead, the underlying pixel - (from the backdrop or background) will be shown at half intensity. - - If the pixel to be overwritten is already at half intensity, then - nothing will happen. - - Pixels with color 3Fh are not drawn. Instead, the underlying pixel - (from the backdrop or background) will be shown at double intensity. - - Backdrop - -------- - - The backdrop is shown at half intensity, while the overscan region outside - of the display area is always shown at normal intensity. - - If a background tile has high priority, then the corresponding 8x8 block - of the backdrop color will be shown at normal intensity. It does not matter - if the background tile is fully opaque or not. - - Operator sprites will affect the backdrop color as well. - - Details - ------- - - It isn't known exactly how the colors are generated in shadow / hilight - mode. Currently all emulators make the half and double intensity colors - exactly half and double brightness of the current palette. - - This is not correct. At least the double intensity palette is actually - not much brighter than the normal palette. You can see a good example - of this by running any game using hilight sprites in an emulator - side-by-side to the same game running on a real Genesis. - - However, I haven't been able to figure out the colors exactly. In - particular, the introduction screen for Sonic 3D will only look correct - if the colors are exactly half and double, while this is certainly wrong - for other games. - - I've verified that the contents of CRAM entries 3Eh and 3Fh do not - affect the intensity of shadow and hilight pixels used in sprites. - - Any information on the colors used in shadow / hilight mode would be - appreciated. - - ---------------------------------------------------------------------------- - 17.) VDP registers - ---------------------------------------------------------------------------- - - All the register names are taken from the manual. - - $00 - Mode Set Register No. 1 - ----------------------------- - - d7 - No effect - d6 - No effect - d5 - No effect - d4 - IE1 (Horizontal interrupt enable) - d3 - 1= Invalid display setting - d2 - Palette select - d1 - M3 (HV counter latch enable) - d0 - Display disable - - Bit 4 will enable horizontal interrupts when set. - - When bit 2 is cleared, only bits 1, 5, and 9 are taken into account - when the VDP generates color data from each word of CRAM. (meaning - the LSB of each RGB component is the only bit used) This reduces the - available color palette from 512 to 8 colors. - - Bit 1 will cause the HV counter to be latched when a level 2 interrupt - is generated. The HV counter will resume normal operation when this bit - is cleared. (untested, need more info) - - Setting bit 0 actually turns off all display generation, as opposed to the - screen blanking feature which simply shows the backdrop color. - - $01 - Mode Set Register No. 2 - ----------------------------- - - d7 - TMS9918 / Genesis display select - d6 - DISP (Display Enable) - d5 - IE0 (Vertical Interrupt Enable) - d4 - M1 (DMA Enable) - d3 - M2 (PAL / NTSC) - d2 - SMS / Genesis display select - d1 - 0 (No effect) - d0 - 0 (See notes) - - Bit 7 seemingly puts the display in a TMS9918-like state when set, similar - to one of it's text display modes. Each 8x8 block is filled with a solid - color from the palette, and has no pattern data. The sprites seem to be - active. I couldn't select any of the other TMS9918 modes through the - usual TMS9918 mode bits. It would appear all the colors are actually - affected by CRAM, instead of using a fixed color set. - - Bit 6 will blank the display when cleared. Any line that is blanked is - filled with the backdrop color. During this time, you can freely access - VDP memory with no limitations on the number of writes per line. - - Bit 5 will enable vertical blanking interrupts when set. - - Bit 4 will enable DMA operations when set. Otherwise, nothing will happen - when a DMA command is sent to the VDP. - - Bit 3 will select between a PAL (240) and NTSC (224 lines) display. - - Bit 2 toggles between the Master System (mode 4) and Genesis (mode 5) - display modes. While in mode 4, none of the registers which normally - affect the Genesis work; and the unused registers (8, 9 - can't test 6) now - function. The mode bits which select TMS9918 modes on a real SMS have - no function here. (This is why the SMS game F16 Fighter will not work - with a Power Base Converter, it uses some of the TMS9918 modes in-game) - - The one exception is register $0C. You can set up a 320x192 display, - but the leftmost eight columns read 'garbage' data for the name table - attributes. Enabling interlace makes the display unstable. (and this - is partially true for a 320x192 picture, which shakes slightly) I'd - advise you set $0C to zero to enable a 256x192 display, which is the - normal SMS resolution. The Genesis always generates a 224 line picture; - the 192 lines in SMS mode are centered in the middle of the screen. - - I could not get the top row or right column lock features to work while - in SMS mode. Apart from this bit, the M3 pin on the cartridge connector - also puts the machine into SMS mode, which may fully enable all video - features. - - Bit 0 has an interesting effect; horizontal scrolling is disabled, and - it would almost seem like the horizontal scroll value modifies the - horizontal retrace / blanking / sync start and end positions around; the - middle of the display is blanked out, and will scroll left or right. - (note the blanked area scrolls - not the background) Moving too far in - one direction, so the blanked area is offscreen, totally corrupts the - display. - - Combining bits 7 (TMS9918 mode) and 2 (SMS mode) have no effect. - - $02 - Pattern Name Table Address for Scroll A - --------------------------------------------- - - Bits 5-3 of this register correspond to bits A15-A13 of the name table - address for plane A. - - $03 - Pattern Name Table Address for Window - --------------------------------------------- - - Bits 5-1 of this register correspond to bits A15-A11 of the name table - address for the window. - - In 40-cell mode, A11 is always forced to zero. - - $04 - Pattern Name Table Address for Scroll B - --------------------------------------------- - - Bits 2-0 of this register correspond to bits A15-A11 of the name table - address for plane B. - - $05 - Sprite Attribute Table Base Address - ----------------------------------------- - - Bits 6-0 of this register correspond to bits A15-A09 of the sprite - attribute table. - - In 40-cell mode, A09 is always forced to zero. - - $07 - Backdrop Color - -------------------- - - Bits 5-0 of this register select a palette entry to be used as the - backdrop color. - - The backdrop color is displayed in the following places: - - - The overscan area around the physical display - - Any line where the display enable bit has been cleared - - You can think of the display being filled with the backdrop color, and - then everything else being drawn over it. Any gaps where no pixels were - drawn will show the backdrop color. - - Even though palette entries 00h, 10h, 20h, and 30h cannot be used by - any patterns, these entries can be used for the backdrop color. - - $0A - H Interrupt Register - -------------------------- - - Bits 7-0 specify the value to be loaded in the counter; for complete - details see the "Interrupts" section. - - $0B - Mode Set Register No. 3 - ----------------------------- - - d7 - 0 (No effect) - d6 - 0 (No effect) - d5 - 0 (No effect) - d4 - 0 (No effect) - d3 - IE2 - d2 - VSCR - d1 - HSCR - d0 - LSCR - - Bit 3 will enable external interrupts, caused by the TH pin being set - to input mode and having the TH interrupt enable bit set. (Both of these - are controlled by the Genesis' I/O registers) - - Bit 2 selects between full screen vertical scrolling when clear, and - 2-cell column based vertical scrolling when set. - - Bits 1 and 0 determine how the VDP will parse the horizontal scroll table - when it is rendering display lines: - - HSCR LSCR - 0 0 - Full screen scroll - 0 1 - Line scroll - 1 0 - Cell scroll - 1 1 - Line scroll - - $0C - Mode Set Register No. 4 - ----------------------------- - - d7 - RS0 - d6 - 0 (No effect) - d5 - ? (See notes) - d4 - 0 (No effect) - d3 - S/TE - d2 - LSM1 - d1 - LSM0 - d0 - RS1 - - LSMx table: - 00 : No interlace - 01 : Interlace (Normal resolution) - 10 : No interlace - 11 : Interlace (Double resolution) - - RSx table: - 00 : Display is 32 cells wide - 01 : Display is 40 cells wide - 10 : Invalid display setting - 11 : Display is 40 cells wide - - Changes made to LSM0, LSM1 do not take effect until the display is no - longer in the active scan period. - - All other bits can be modified with changes taking effect immediately at - any point in the display frame. - - You should normally set the RSx bits to 00b or 11b. The unlicensed version - of Populous sets up a 40 cell display with a setting of 01b - technically - valid, but the display is distorted a bit. - - Bit 5 seems to affect the display when used in conjunction with RS0, but - only in the same way as the display appears when using a setting of 01b. - I've tried every combination of bit 6 along with the RSx bits, and the - physical width of the display was never different from 32 or 40 cells. - - $0D - H Scroll Data Table Base Address - -------------------------------------- - - Bits 5-0 of this register correspond to bits A15-A10 of the horizontal - scroll data table address. - - $0F - Auto Increment Data - ------------------------- - - Bits 7-0 specify the value to be added to the VDP's address register - after every read or write to the data port. - - A setting of zero means the address register is not incremented. - - $10 - Scroll Size - ----------------- - - d7 - 0 (No effect) - d6 - 0 (No effect) - d5 - VSZ1 - d4 - VSZ0 - d3 - 0 (No effect) - d2 - 0 (No effect) - d1 - HSZ1 - d0 - HSZ0 - - This register defines the size of the name tables for planes A and B. - Both fields can be set to the following values: - - 0 0 32 cells - 0 1 64 cells - 1 0 Invalid - 1 1 128 cells - - If the HSZ bits are set to 10b (invalid), then the first row of the name - table is shown for every line of the display. - - - $11 - Window H Position - ----------------------- - - d7 - RIGT - d6 - 0 (No effect) - d5 - 0 (No effect) - d4 - WHP5 - d3 - WHP4 - d2 - WHP3 - d1 - WHP2 - d0 - WHP1 - - This register will affect the window shown on the current line, if - the current line does not fall into the vertical range specified by - register $12. - - The WHP field defines the horizontal range of the window, in units - of two cells. (16 pixels) - - Setting the WHP field to zero disables the window. - Any nonzero value indicates how many 2-cell columns wide the window - plane is. (0=no window, 1=2 cells, 2=4 cells, 3=6 cells, etc.) - - When RIGT=0, the window is shown from column zero to the column - specified by the WHP field. - - For instance, if RIGT=0 and WHP=4, the window is displayed on columns - zero up to (and including) column seven. - - When RIGHT=1, the window is shown from the column specified in the WHP - field up to the last column in the display meaning column 31 or 39 - depending on the screen width setting. - - For instance, if RIGT=1 and WHP=4, the window is displayed on columns - eight up to (and including) column 31 or 39. - - Having WHP set to zero and RIGHT=1 is a legal setting; it means the - window is shown from column zero up to the last column in the display, - meaning the entire line is taken up by the window plane. - - There is a bug in the window processing. This occurs when the window is - showing partially on the left side of the screen, specifically when - the VDP is drawing the 2-cell column from plane A that immediately proceeds - the last column the window was drawn on. (i.e. WHP+1) - - If the lower four bits of the horizontal scroll value for the current - scan line are zero, then the name table attribute data for the current - column are fetched correctly. - - If the lower four bits of the horizontal scroll value for the current - scan line are nonzero, the name table attribute data are fetched from - next column. (WHP+2) - - In effect, you'll have N columns of the window plane, 1 column that has - identical patterns as the next column, then the remainder of the display - is drawn correctly. - - Here's a diagram to illustrate this: - w = window tiles - abc = tile columns - - D3-D0 of scroll value == 0 - wwwwwwwwwwwwwwwwaabbccddeeffgghh - - D3-D0 of scroll value != 0 - wwwwwwwwwwwwwwwwbbbbccddeeffgghh - - This register can be modified with changes taking effect immediately at - any point in the display frame. - - Plane A is not shown in any column where plane W is shown; they cannot - overlap. - - $12 - Window V Position - ----------------------- - - d7 - DOWN - d6 - 0 (No effect) - d5 - 0 (No effect) - d4 - WVP4 - d3 - WVP3 - d2 - WVP2 - d1 - WVP1 - d0 - WVP0 - - If the current scanline does not fall within the range specified by - register $12, then register $11 determines where the window is shown - for the remainder of the display. - - The WVP field defines the vertical range of the window, in units - of eight lines. - - Setting the WVP field to zero disables the window. - Any nonzero value indicates a vertical range for the window to appear - in. (0=no window, 1=lines 0-$7, 2= lines 0-$F, 3= lines 0-$17, etc.) - - When DOWN=0, the window is shown from line zero to the line specified - by the WVP field. - - For instance, if DOWN=0 and WVP=4, the window is displayed on lines - zero up to (and including) line $1F. - - When DOWN=1, the window is shown from the line specified in the WVP - field up to the last line in the display. - - For instance, if DOWN=1 and WVP=4, the window is displayed on lines $1F - up to (and including) the last line in the display. - - Having WVP set to zero and DOWN=1 is a legal setting; it means the - window is shown from line zero up to the last line in the display, - meaning the entire screen is taken up by the window plane. - - Plane A is not shown in any line where plane W is shown; they cannot - overlap. - - ---------------------------------------------------------------------------- - 18.) VDP Pinout - ---------------------------------------------------------------------------- - - This is applicable to the 315-5313 chip used in the early versions of - the original Genesis model. - - 1-8 - SD0-SD7 (VRAM data bus) - 10 - SE0 (VRAM) - 11 - SC (VRAM) - 12 - RAS (VRAM) - 13 - CAS (VRAM) - 15 - WE0 (VRAM) - 16 - OE (VRAM) - 17 - GND - 26 - AGC - 27 - R (Red video output) - 28 - G (Green video output) - 29 - B (Blue video output) - 30 - AVC - 31-38 - AD0-AD7 (VRAM address bus) - 39 - YS - 40 - SPA/8 - 41 - VSYNC (Vertical sync) - 42 - C-SYNC (Composite sync) - 43 - HSYNC (Horizontal sync) - 44 - HL (from control port HL pin) - 45 - SEL0 (from M3 on cartridge connector - forces mode 4 graphics) - 46 - PAL (PAL / NTSC select) - 47 - RESET (68000) - 49 - CLK1 (68000) - 48 - SEL1 (?) - 50 - SBCR - 51 - CLK0 - 52 - MCLK (53.64165 MHz) - 53 - EDCLK - 54 - VDD - 54-70 - CD0-CD15 (68000 data bus) - 71-93 - CA0-CA22 (68000 address bus (A23-A1)) - 94 - AVS - 95 - PSG (SN76489 PSG sound output) - 97 - GND - 98 - INT - 99 - BR - 100 - BGAK - 101 - BG - 102 - MRE0 - 103 - INTAK - 104 - IPL1 (68000) - 105 - IPL2 (68000) - 106 - IREQ - 107 - RD (68000) - 108 - WR (68000) - 109 - MI - 110 - AS (68000) - 111 - UDS (68000) - 112 - LDS (68000) - 113 - R/W - 114 - DTAK (68000) - 115 - UWR (68000) - 116 - LWR (68000) - 118 - CAS0 (VRAM) - 117 - OE0 (VRAM) - 119 - RAS0 (VRAM) - 128 - VDD - - ============================================================================ - - To-do test list - - - Last column wrapping (40 cell mode only?) - - Columns being offset by the horizontal scroll value (d3-d0) - - How line scrolling is managed in interlace mode 2 - - How sprite Y positions and VSRAM values are used in interlace mode 2 - - Vertical interrupt supression via line interrupts - - Reverse sprite stage in CV - - Mid frame sprite table changes (can't be done I think; sprite table - changes aren't seen by VDP, though changing the sprite table address - will cause a switch) - - Large sprite pattern overflow - - Result of copy and fill operations overflowing - - Result of copy operations overlapping - - Use of HV counter latch in the 6-in-1 pak. - - Source and length registers being updated during DMA - - Confirm invalid code use - - Default status flag settings - - Sprite collisions and overflows outside of the physical display area - - How many times a sprite collision and overflow can occur (per line/frame?) - - And for timing, based on the HV counter: - - - Vertical counter increment - - Horizontal blanking flag clear and set - - Vertical blank flag clear and set - - Horizontal interrupt occurance - - Vertical interrupt occurance - - Invalid periods for vertical counter - - Invalid periods for horizontal counter (test with 6-in-1 pak) - - Start/stop of physical display (use sprite collision on either edge) diff --git a/source/docs/io.htm b/source/docs/io.htm deleted file mode 100644 index 6b62f3d..0000000 --- a/source/docs/io.htm +++ /dev/null @@ -1,933 +0,0 @@ -Sega Genesis I/O Chip and Peripherals - -

Sega Genesis I/O Chip and Peripherals

-By Charles MacDonald
-http://cgfm2.emuviews.com -
- -

Contents

- - - -

Overview

-

- The I/O chip manages three 7-bit I/O ports. It also -provides an way for the CPU to read the state of several jumpers in the -system. Later versions of the Genesis hardware have the I/O chip -integrated into some of the other custom hardware, but they all -function identically. -

- - -

Connector details

-

- Ports A and B are male DB-9 connectors, while port C is -female. In the Genesis 2 and 3, there is no physical connector for port -C, but it can still be programmed and will respond like any other port. -(as if no gamepad was connected) Here are the pin assignments: -

- -
    Pin 1 : D0
-    Pin 2 : D1
-    Pin 3 : D2
-    Pin 4 : D3
-    Pin 5 : +5V
-    Pin 6 : TL
-    Pin 7 : TH
-    Pin 8 : Ground
-    Pin 9 : TR
-
- - -

CPU interface

- -

- The I/O chip is connected to the 68000 and Z80. When in -Mark-III compatibility mode, the I/O chip has a different set of -registers which mimic those of the SMS, which will not be discussed -here. -

- The I/O chip is mapped to $A10000-$A1001F in the 68000/VDP/Z80 banked address space. - It is normally read and written in byte units at odd addresses. - The chip gets /LWR only, so writing to even addresses has no effect. - - Reading even addresses returns the same data you'd get from an odd address. - If a word-sized write is done, the LSB is sent to the I/O chip and the MSB is ignored. - Here are some examples to illustrate these points: -

    ; Does nothing, byte writes to even addresses are ignored
-    move.b  #$40, $A10002
-
-    ; Returns contents of version register, reading even addresses is the same as reading odd ones
-    move.b $A10000, d0
-
-    ; Same as writing #$40 to $A10007, the MSB is ignored
-    move.w #$C040, $A10006
-
-

- - -

Register list

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
AddressDescription
$A10001Version
$A10003Port A data
$A10005Port B data
$A10007Port C data
$A10009Port A control
$A1000BPort B control
$A1000DPort C control
$A1000FPort A TxData
$A10011Port A RxData
$A10013Port A serial control
$A10015Port B TxData
$A10017Port B RxData
$A10019Port B serial control
$A1001BPort C TxData
$A1001DPort C RxData
$A1001FPort C serial control
- - -

Version register

-

- The version register returns several types of -information, such as a hard-coded version number, settings of the -domestic/export and PAL/NTSC jumpers, and the state of a sense pin -which the Sega CD uses. 

    D7 : Console is 1= Export (USA, Europe, etc.) 0= Domestic (Japan)
-    D6 : Video type is 1= PAL, 0= NTSC
-    D5 : Sega CD unit is 1= not present, 0= connected.
-    D4 : Unused (always returns zero)
-    D3 : Bit 3 of version number
-    D2 : Bit 2 of version number
-    D1 : Bit 1 of version number
-    D0 : Bit 0 of version number
-
- - Bit 5 is used by the Sega CD, returning '0' when it is attached and '1' when it is not. - -

- The version number is zero for the original model Genesis and MegaDrive. - All later versions of the hardware are version 1, and have additional security hardware. - -

- Bits 7,6 are used in country protection checks. Some early games used - them to display English or Japanese text, so the same game program could - be used in both regions. Here's a list of settings: -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Bit 7Bit 6TV typeRegionComments
00NTSCJapan, Korea, Taiwan262 lines, 60 FPS
01PALJapanNo hardware actually uses this setting
10NTSCUSA, Canada262 lines, 60 FPS
10PAL-MBrazil262 lines, 60 FPS
11PALEurope, Hong Kong313 lines, 50 FPS
- -

- Early games stored a region compatibility code in their -header at offset $0001F1. This value could be the ASCII text J, U, or E -for Japan, USA or Europe. During game initialization, bits 7,6 could be -sampled and compared to the region type stored in the header. If there -is a mismatch, many games will fill the screen with a single color lock -up intentionally, or sometimes display an error message.

- Later games have a slightly more complex code. - Here's the table Sega uses to determine valid codes to use: -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
$A10001 Main Sales TerritoriesHardware Enable Code (numbers from 0 to F below)
Bit 7Bit 6Hardware Type0123456789ABCDEF
00Japan, NTSCJapan, S. Korea, TaiwanXOXOXOXOXOXOXOXO
01Japan, PAL XXOOXXOOXXOOXXOO
10Overseas, NTSCN. America, BrazilXXXXOOOOXXXXOOOO
11Overseas, PALEurope, Hong KongXXXXXXXXOOOOOOOO
- -

- Common uses of the new code type are ASCII values '4' for N.America, 'A' for UK, and 'B' for UK and Japan. -

- - - -

Data register

-

- Writing to the data register sets the logic level of -pins configured as outputs (0= 0V, 1= +5V), and does nothing to pins -configured as inputs. Reading from the data register returns the state -of each pin. Here's a list of which bits in the data register -correspond to pins on the I/O port. -

    D7 : Unused. This bit will return any value written to it
-    D6 : TH pin
-    D5 : TR pin
-    D4 : TL pin
-    D3 : D3 pin
-    D2 : D2 pin
-    D1 : D1 pin
-    D0 : D0 pin
-
- - If a pin is configured as an input, reading it returns -the true logic state of whatever the pin is connected to (e.g. 0 for -ground, 1 for +5V). If nothing is connected to it, the pin returns '1', -maybe due to internal pull-up resistors. -

- If a pin is configured as an output, reading it returns the last value written to this register. -

- - -

Control register

-

- The control register determines which pins are inputs and outputs. - -

    D7 : /HL output control (see description)
-    D6 : TH pin is 1=output, 0=input
-    D5 : TR pin is 1=output, 0=input
-    D4 : TL pin is 1=output, 0=input
-    D3 : D3 pin is 1=output, 0=input
-    D2 : D2 pin is 1=output, 0=input
-    D1 : D1 pin is 1=output, 0=input
-    D0 : D0 pin is 1=output, 0=input
-
- - If bit 7 of this register is set, and TH is configured as an input, - then whenever external hardware makes high to low transition on TH - the I/O chip will strobe it's /HL output pin low. This pin connects to - the VDP, which can be set up to latch the HV counter and/or cause a level 2 - interrupt upon /HL going low. -

- - -

Serial control register

-

- The serial control register defines how a port is used for serial - communications and provides status flags to indicate the current state - of sending or receiving data. - -

    D7 : Serial baud rate bit 1
-    D6 : Serial baud rate bit 0
-    D5 : TR pin functions as 1= serial input pin, 0= normal
-    D4 : TL pin functions as 1= serial output pin, 0= normal
-    D3 : 1= Make I/O chip strobe /HL low when a byte has been received, 0= Do nothing
-    D2 : 1= Error receiving current byte, 0= No error
-    D1 : 1= Rxd buffer is ready to read, 0= Rxd buffer isn't ready
-    D0 : 1= Txd buffer is full, 0= Can write to Txd buffer
-
- - The available baud rates are: -

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
D7D6Baud rate
004800 bps
012400 bps
101200 bps
11300 bps
- -

- When doing serial communication, TL and/or TR can be used for sending - and receiving data. During this time the data and control registers - have no effect for whichever pin(s) are in serial mode. The rest of the - pins in the same port function normally. - -

The intended use of bit 3 is to also have the VDP set up to -enable level 2 interrupts when /HL goes low. This way, when the I/O -chip receives a byte through the TR pin, if this bit is set then it -will strobe /HL low and cause an interrupt. So receiving data serially -can either be accomplished through manual polling or be interrupt -driven. -

- Bits 2-0 are read-only status flags, the rest of the bits in this register can be read and written. -

- - - -

TxData register

-

- Writing a byte to this register will make the I/O chip -output the data serially through the TL pin, providing it was -configured for serial mode. You should poll bit 0 of the serial control -register until the bit returns 0 to ensure the previously written byte -has been sent and the TxData buffer is empty. -

- - -

RxData register

-

- Reading from this register returns the last byte -received serially through the TR pin. You should check bits 3,2 of the -serial control register to ensure that the RxData input buffer is full -and that there were no errors in receiving the byte (which would then -be invalid). -

- - -

Using serial communication

-

- When in serial mode, the I/O ports output TTL-level -signals. You need something like a MAX232 line driver to convert these -to RS-232 compatible signals for interfacing with (for example) a PC. -

If you just want to do experiments on the serial ports -themselves, you can use a null modem cable with the TL/TR wires -switched around to connect port A to B. I used this for testing the -serial capabilities while writing this document. Be sure to disconnect -the +5V line as well. -

- - -

Peripheral devices

- - - - -

2-button Mark-III gamepad

-

- This controller has a 4-way direction pad, and two buttons (2 and 1). - Here's a description of how the controller interfaces with an I/O port: - -

    D6 : (TH) Not used
-    D5 : (TR) Button 2
-    D4 : (TL) Button 1
-    D3 : (D3) D-pad Right
-    D2 : (D2) D-pad Left
-    D1 : (D1) D-pad Down
-    D0 : (D0) D-pad Up
-
- - All buttons are active-low logic, so they return '0' when pressed and '1' when released. -

- - -

3-button standard gamepad

-

- This controller has a 4-way direction pad, and four buttons (Start, A, B, C). - It uses a multiplexer that selects 1 of 2 inputs using TH, and routes buttons Start or C to TR, and B or A to TL. - -

- Here's a description of how the controller interfaces with an I/O port: - -

                When TH=0          When TH=1
-    D6 : (TH)   0                  1
-    D5 : (TR)   Start button       Button C
-    D4 : (TL)   Button A           Button B
-    D3 : (D3)   0                  D-pad Right
-    D2 : (D2)   0                  D-pad Left
-    D1 : (D1)   D-pad Down         D-pad Down
-    D0 : (D0)   D-pad Up           D-pad Up
-
- - All buttons are active-low logic, so they return '0' when pressed and '1' when released. - -

You need a small delay between changing TH and reading the -button state back, as the multiplexer takes some time in switching -inputs. I've found about four NOPs provides a reasonable delay. -

- Here's some example code to read a 3-button gamepad: -

- -
; Returns D0 with the button states: 'SACBRLDU'
-_read_joypad:
-                        move.l  d1, -(a7)
-                        move.b  #$40, $A10003
-                        nop
-                        nop
-                        move.b  $A10003, d0
-                        andi.b  #$3F, d0
-                        move.b  #$00, $A10003
-                        nop
-                        nop
-                        move.b  $A10003, d1
-                        lsl.b   #2, d1
-                        andi.b  #$C0, d1
-                        or.b    d1, d0
-                        eori.b  #$FF, d0
-                        move.l  (a7)+, d1
-                        rts
-
- - -

Fighting Pad 6B

-

- Information coming soon. -

- - -

Lightguns (Sega Menacer, Konami Justifier)

-

- Information coming soon. -

- - -

EA 4-Way Play

-

- The EA 4-Way Play plugs into ports A and B, and allows up to four standard Genesis controllers to be connected at once. - -

I've determined how the multitap works by examining the -joystick reading code from NHL '95 and trying the same routine on a -new-style Sega Team Player in 'EXTRA' mode. That said, the actual EA -4-Way Play could have some differences that Sega's compatibility mode -doesn't take care of. -

To detect the multitap, set CTRL1 to 0x40, CTRL2 to 0x7F and -DATA2 to $7C. Reading the lower 2 bits of DATA1 will return zero if the -multitap is present. Usually these bits return 0x03 if there is no tap, -no controller, or the Sega Team Player isn't in EXTRA mode, but this -could be a behavior specific to the Team Player. -

- To read the pads, write 0x0C, 0x1C, 0x2C, or 0x3C to DATA2 to select the controller in port A, B, C, or D. - You can then use DATA1/CTRL1 to read the pad state just like polling a regular 3-button pad in port A. - -

- Here's some example code to use the EA 4-Way Play: -

- -
; Returns D0 == 0 if the multitap is present, or D0 != 0 if it isn't
-_detect_4wayplay:
-                        move.b  #$40, $A10009
-                        nop
-                        move.b  #$7F, $A1000B
-                        nop
-                        move.b  #$7C, $A10005
-                        nop
-                        moveq   #0, d0
-                        move.b  $A10003, d0
-                        andi.b  #$03, d0
-                        rts
-
-; Returns the state of all four 3-button gamepads in D0
-_read_4wayplay:
-                        move.l  d1-d3/a0, -(a7)
-                        lea     $A10000, a0
-                        move.l  #$0C1C2C3C, d2
-                        moveq   #$03, d3
-        poll:           move.b  d2, $05(a0)
-                        nop
-                        nop
-                        move.b  #$40, $03(a0)
-                        nop
-                        nop
-                        move.b  $A10003, d0
-                        andi.b  #$3F, d0
-                        move.b  #$00, $03(a0)
-                        nop
-                        nop
-                        move.b  $03(a0), d1
-                        lsl.b   #2, d1
-                        andi.b  #$C0, d1
-                        or.b    d1, d0
-                        lsl.l   #8, d0
-                        lsr.l   #8, d2
-                        dbra    d3, poll
-                        eori.l  #-1, d0
-                        move.l  (a7)+, d2-d3/a0
-                        rts
-
- - - -

Sega Team Player

-

- The Team Player is a multitap device that allows four peripherals to be connected to the Genesis at one time. - It has a mode select switch with several settings: -

    EXTRA - All four ports are enabled. This is the setting used by
-            EA 4-Way Play compatible games.
-        A - Routes the peripheral in port A to port A of the Genesis.
-        B - Routes the peripheral in port B to port A of the Genesis.
-        C - Routes the peripheral in port C to port A of the Genesis.
-        D - Routes the peripheral in port D to port A of the Genesis.
-    MULTI - All four ports are enabled. This is the setting used by
-            Team Player compatible games.
-
- Sega made two versions of the Team Player. The first one -was not compatible with the EA 4-Way Play and only had one cable to -connect it to port A. The second one added the "EXTRA" setting for EA -4-Way Play compatibility and provides a second cable to connect it to -port B as well. Both seem to function identically with the exception of -EXTRA mode. -

- I don't have any programming information for this device. -

- - -

Sega Mega Mouse

-

- This is a three button mouse (left, middle, right) with an extra button - (Start) located near the thumb position. It uses a PIC16C54 microcontroller - which manages the buttons and position tracking. - -

- The Sega Mega Mouse that is distributed in North America is incompatible with the European version of Populous 2. - The mouse functions normally but has Y axis inverted so up is down and vice-versa. - It may have been designed for the Japanese Mega Drive mouse, which is a different product with 2 buttons and unique physical appearance. - -

- The protocol works as follows: - TH and TR are outputs which tell the microcontroller to stop or start a data transfer, and to acknowledge received data. - TL is an input which returns a busy flag for the microcontroller. - D3-D0 are inputs that return the data. - Here's a table showing the communication process: -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
WriteTHTRTLD3D2D1D0Description
$601110000Request data
$200110000ID #0 ($0)
$000011011ID #1 ($B)
$200101111ID #2 ($F)
$000011111ID #3 ($F)
$20010Y OverX OverY SignX SignAxis sign and overflow
$00001StartMiddleRightLeftButton state
$20010X7X6X5X4X axis MSN
$00001X3X2X1X0X axis LSN
$20010Y7Y6Y5Y4Y axis MSN
$00001Y3Y2Y1Y0Y axis LSN
- -

- Write #$60 when you are done polling to stop the data -transfer. If you continue to poll the mouse after collecting all the -data by writing $20 / $00, the Y axis LSN will always be returned. Sega -advises polling beyond this point will make the mouse behave -abnormally. It's possible that the PIC code in some versions of the -Mega Mouse may have problems if the poll sequence is too long. -

- The X/Y overflow flags are supposed to be set if the mouse is moved over a distance greater than can be measured. - I can't get them to become set, maybe the mouse supports a fairly wide range of movement. - - -

You need a considerable delay between writing new values to -TH/TR. I think the intention is to poll TL until the microcontroller -returns 'not busy', but I can't get this to work reliably. Sega's mouse -reading code also has a timeout when checking TL which would indicate -it may get stuck in a certain state. -

- All buttons (start, left, middle, right) are active-high logic, so they return '1' when pressed and '0' when released. -

- - -

Miscellaneous

-

- After power-up, the default state of the I/O chip are as follows: -

    $A10001 = $80 (Bits 7,6,5 depend on the domestic/export, PAL/NTSC jumpers and having a Sega CD or not)
-    $A10003 = $7F
-    $A10005 = $7F
-    $A10007 = $7F
-    $A10009 = $00
-    $A1000B = $00
-    $A1000D = $00
-    $A1000F = $FF
-    $A10011 = $00
-    $A10013 = $00
-    $A10015 = $FF
-    $A10017 = $00
-    $A10019 = $00
-    $A1001B = $FB
-    $A1001D = $00
-    $A1001F = $00
-
-

- - -

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.
-
- -
- - \ No newline at end of file diff --git a/source/docs/license b/source/docs/license deleted file mode 100644 index 60549be..0000000 --- a/source/docs/license +++ /dev/null @@ -1,340 +0,0 @@ - GNU GENERAL PUBLIC LICENSE - Version 2, June 1991 - - Copyright (C) 1989, 1991 Free Software Foundation, Inc. - 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. - - Preamble - - The licenses for most software are designed to take away your -freedom to share and change it. By contrast, the GNU General Public -License is intended to guarantee your freedom to share and change free -software--to make sure the software is free for all its users. This -General Public License applies to most of the Free Software -Foundation's software and to any other program whose authors commit to -using it. (Some other Free Software Foundation software is covered by -the GNU Library General Public License instead.) You can apply it to -your programs, too. - - When we speak of free software, we are referring to freedom, not -price. Our General Public Licenses are designed to make sure that you -have the freedom to distribute copies of free software (and charge for -this service if you wish), that you receive source code or can get it -if you want it, that you can change the software or use pieces of it -in new free programs; and that you know you can do these things. - - To protect your rights, we need to make restrictions that forbid -anyone to deny you these rights or to ask you to surrender the rights. -These restrictions translate to certain responsibilities for you if you -distribute copies of the software, or if you modify it. - - For example, if you distribute copies of such a program, whether -gratis or for a fee, you must give the recipients all the rights that -you have. You must make sure that they, too, receive or can get the -source code. And you must show them these terms so they know their -rights. - - We protect your rights with two steps: (1) copyright the software, and -(2) offer you this license which gives you legal permission to copy, -distribute and/or modify the software. - - Also, for each author's protection and ours, we want to make certain -that everyone understands that there is no warranty for this free -software. If the software is modified by someone else and passed on, we -want its recipients to know that what they have is not the original, so -that any problems introduced by others will not reflect on the original -authors' reputations. - - Finally, any free program is threatened constantly by software -patents. We wish to avoid the danger that redistributors of a free -program will individually obtain patent licenses, in effect making the -program proprietary. To prevent this, we have made it clear that any -patent must be licensed for everyone's free use or not licensed at all. - - The precise terms and conditions for copying, distribution and -modification follow. - - GNU GENERAL PUBLIC LICENSE - TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION - - 0. This License applies to any program or other work which contains -a notice placed by the copyright holder saying it may be distributed -under the terms of this General Public License. The "Program", below, -refers to any such program or work, and a "work based on the Program" -means either the Program or any derivative work under copyright law: -that is to say, a work containing the Program or a portion of it, -either verbatim or with modifications and/or translated into another -language. (Hereinafter, translation is included without limitation in -the term "modification".) Each licensee is addressed as "you". - -Activities other than copying, distribution and modification are not -covered by this License; they are outside its scope. The act of -running the Program is not restricted, and the output from the Program -is covered only if its contents constitute a work based on the -Program (independent of having been made by running the Program). -Whether that is true depends on what the Program does. - - 1. You may copy and distribute verbatim copies of the Program's -source code as you receive it, in any medium, provided that you -conspicuously and appropriately publish on each copy an appropriate -copyright notice and disclaimer of warranty; keep intact all the -notices that refer to this License and to the absence of any warranty; -and give any other recipients of the Program a copy of this License -along with the Program. - -You may charge a fee for the physical act of transferring a copy, and -you may at your option offer warranty protection in exchange for a fee. - - 2. You may modify your copy or copies of the Program or any portion -of it, thus forming a work based on the Program, and copy and -distribute such modifications or work under the terms of Section 1 -above, provided that you also meet all of these conditions: - - a) You must cause the modified files to carry prominent notices - stating that you changed the files and the date of any change. - - b) You must cause any work that you distribute or publish, that in - whole or in part contains or is derived from the Program or any - part thereof, to be licensed as a whole at no charge to all third - parties under the terms of this License. - - c) If the modified program normally reads commands interactively - when run, you must cause it, when started running for such - interactive use in the most ordinary way, to print or display an - announcement including an appropriate copyright notice and a - notice that there is no warranty (or else, saying that you provide - a warranty) and that users may redistribute the program under - these conditions, and telling the user how to view a copy of this - License. (Exception: if the Program itself is interactive but - does not normally print such an announcement, your work based on - the Program is not required to print an announcement.) - -These requirements apply to the modified work as a whole. If -identifiable sections of that work are not derived from the Program, -and can be reasonably considered independent and separate works in -themselves, then this License, and its terms, do not apply to those -sections when you distribute them as separate works. But when you -distribute the same sections as part of a whole which is a work based -on the Program, the distribution of the whole must be on the terms of -this License, whose permissions for other licensees extend to the -entire whole, and thus to each and every part regardless of who wrote it. - -Thus, it is not the intent of this section to claim rights or contest -your rights to work written entirely by you; rather, the intent is to -exercise the right to control the distribution of derivative or -collective works based on the Program. - -In addition, mere aggregation of another work not based on the Program -with the Program (or with a work based on the Program) on a volume of -a storage or distribution medium does not bring the other work under -the scope of this License. - - 3. You may copy and distribute the Program (or a work based on it, -under Section 2) in object code or executable form under the terms of -Sections 1 and 2 above provided that you also do one of the following: - - a) Accompany it with the complete corresponding machine-readable - source code, which must be distributed under the terms of Sections - 1 and 2 above on a medium customarily used for software interchange; or, - - b) Accompany it with a written offer, valid for at least three - years, to give any third party, for a charge no more than your - cost of physically performing source distribution, a complete - machine-readable copy of the corresponding source code, to be - distributed under the terms of Sections 1 and 2 above on a medium - customarily used for software interchange; or, - - c) Accompany it with the information you received as to the offer - to distribute corresponding source code. (This alternative is - allowed only for noncommercial distribution and only if you - received the program in object code or executable form with such - an offer, in accord with Subsection b above.) - -The source code for a work means the preferred form of the work for -making modifications to it. For an executable work, complete source -code means all the source code for all modules it contains, plus any -associated interface definition files, plus the scripts used to -control compilation and installation of the executable. However, as a -special exception, the source code distributed need not include -anything that is normally distributed (in either source or binary -form) with the major components (compiler, kernel, and so on) of the -operating system on which the executable runs, unless that component -itself accompanies the executable. - -If distribution of executable or object code is made by offering -access to copy from a designated place, then offering equivalent -access to copy the source code from the same place counts as -distribution of the source code, even though third parties are not -compelled to copy the source along with the object code. - - 4. You may not copy, modify, sublicense, or distribute the Program -except as expressly provided under this License. Any attempt -otherwise to copy, modify, sublicense or distribute the Program is -void, and will automatically terminate your rights under this License. -However, parties who have received copies, or rights, from you under -this License will not have their licenses terminated so long as such -parties remain in full compliance. - - 5. You are not required to accept this License, since you have not -signed it. However, nothing else grants you permission to modify or -distribute the Program or its derivative works. These actions are -prohibited by law if you do not accept this License. Therefore, by -modifying or distributing the Program (or any work based on the -Program), you indicate your acceptance of this License to do so, and -all its terms and conditions for copying, distributing or modifying -the Program or works based on it. - - 6. Each time you redistribute the Program (or any work based on the -Program), the recipient automatically receives a license from the -original licensor to copy, distribute or modify the Program subject to -these terms and conditions. You may not impose any further -restrictions on the recipients' exercise of the rights granted herein. -You are not responsible for enforcing compliance by third parties to -this License. - - 7. If, as a consequence of a court judgment or allegation of patent -infringement or for any other reason (not limited to patent issues), -conditions are imposed on you (whether by court order, agreement or -otherwise) that contradict the conditions of this License, they do not -excuse you from the conditions of this License. If you cannot -distribute so as to satisfy simultaneously your obligations under this -License and any other pertinent obligations, then as a consequence you -may not distribute the Program at all. For example, if a patent -license would not permit royalty-free redistribution of the Program by -all those who receive copies directly or indirectly through you, then -the only way you could satisfy both it and this License would be to -refrain entirely from distribution of the Program. - -If any portion of this section is held invalid or unenforceable under -any particular circumstance, the balance of the section is intended to -apply and the section as a whole is intended to apply in other -circumstances. - -It is not the purpose of this section to induce you to infringe any -patents or other property right claims or to contest validity of any -such claims; this section has the sole purpose of protecting the -integrity of the free software distribution system, which is -implemented by public license practices. Many people have made -generous contributions to the wide range of software distributed -through that system in reliance on consistent application of that -system; it is up to the author/donor to decide if he or she is willing -to distribute software through any other system and a licensee cannot -impose that choice. - -This section is intended to make thoroughly clear what is believed to -be a consequence of the rest of this License. - - 8. If the distribution and/or use of the Program is restricted in -certain countries either by patents or by copyrighted interfaces, the -original copyright holder who places the Program under this License -may add an explicit geographical distribution limitation excluding -those countries, so that distribution is permitted only in or among -countries not thus excluded. In such case, this License incorporates -the limitation as if written in the body of this License. - - 9. The Free Software Foundation may publish revised and/or new versions -of the General Public License from time to time. Such new versions will -be similar in spirit to the present version, but may differ in detail to -address new problems or concerns. - -Each version is given a distinguishing version number. If the Program -specifies a version number of this License which applies to it and "any -later version", you have the option of following the terms and conditions -either of that version or of any later version published by the Free -Software Foundation. If the Program does not specify a version number of -this License, you may choose any version ever published by the Free Software -Foundation. - - 10. If you wish to incorporate parts of the Program into other free -programs whose distribution conditions are different, write to the author -to ask for permission. For software which is copyrighted by the Free -Software Foundation, write to the Free Software Foundation; we sometimes -make exceptions for this. Our decision will be guided by the two goals -of preserving the free status of all derivatives of our free software and -of promoting the sharing and reuse of software generally. - - NO WARRANTY - - 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY -FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN -OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES -PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED -OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF -MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS -TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE -PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, -REPAIR OR CORRECTION. - - 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING -WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR -REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, -INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING -OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED -TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY -YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER -PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE -POSSIBILITY OF SUCH DAMAGES. - - END OF TERMS AND CONDITIONS - - How to Apply These Terms to Your New Programs - - If you develop a new program, and you want it to be of the greatest -possible use to the public, the best way to achieve this is to make it -free software which everyone can redistribute and change under these terms. - - To do so, attach the following notices to the program. It is safest -to attach them to the start of each source file to most effectively -convey the exclusion of warranty; and each file should have at least -the "copyright" line and a pointer to where the full notice is found. - - - Copyright (C) 19yy - - This program is free software; you can redistribute it and/or modify - it under the terms of the GNU General Public License as published by - the Free Software Foundation; either version 2 of the License, or - (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - - -Also add information on how to contact you by electronic and paper mail. - -If the program is interactive, make it output a short notice like this -when it starts in an interactive mode: - - Gnomovision version 69, Copyright (C) 19yy name of author - Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. - This is free software, and you are welcome to redistribute it - under certain conditions; type `show c' for details. - -The hypothetical commands `show w' and `show c' should show the appropriate -parts of the General Public License. Of course, the commands you use may -be called something other than `show w' and `show c'; they could even be -mouse-clicks or menu items--whatever suits your program. - -You should also get your employer (if you work as a programmer) or your -school, if any, to sign a "copyright disclaimer" for the program, if -necessary. Here is a sample; alter the names: - - Yoyodyne, Inc., hereby disclaims all copyright interest in the program - `Gnomovision' (which makes passes at compilers) written by James Hacker. - - , 1 April 1989 - Ty Coon, President of Vice - -This General Public License does not permit incorporating your program into -proprietary programs. If your program is a subroutine library, you may -consider it more useful to permit linking proprietary applications with the -library. If this is what you want to do, use the GNU Library General -Public License instead of this License. diff --git a/source/docs/m5hvc.txt b/source/docs/m5hvc.txt deleted file mode 100644 index c9f1b2a..0000000 --- a/source/docs/m5hvc.txt +++ /dev/null @@ -1,40 +0,0 @@ - - VDP timing for an NTSC Genesis in display mode 5. - Version 0.4 (11/29/00) - - by Charles MacDonald - WWW: http://cgfm2.emuviews.com - - Unpublished work Copyright 2000 Charles MacDonald - - Description 32-cell 40-cell - ---------------------------------------------------------------------------- - Range 00-93, E9-FF 00-B6, E4-FF - Display area 00-7F 00-9F - V counter increment 84, 85 A4, A5 - V-blanking in 86, 87 A7, A8 - V-blanking out 86, 87 A7, A8 - H-blanking in 93, E9 B2, E4 - H-blanking out 06, 07 06, 07 - - Comma seperated values show the H counter value before an event occurs, - and then the H counter value immediately after. - - These values shouldn't be considered 100% accurate, they are probably - off by one or two. - - Each H counter unit is equivalent to two pixels. - - The gaps at 93-E9 and B6-E4 are where the H counter 'jumps' ahead. - The H counter will never actually be set to the values 94-E8 or B7-E3. - Perhaps this is the horizontal retrace period. - - Interestingly enough, the timing values for the 32-cell display mode - are identical to that of the SMS. - - It would appear that in 40-cell mode, the horizontal blanking period - is shorter as the active display period takes more time. - - The V-blanking flag can also be forcibly set by disabling the display - through bit 6 of register #1. - diff --git a/source/docs/newreg.txt b/source/docs/newreg.txt deleted file mode 100644 index c8627fc..0000000 --- a/source/docs/newreg.txt +++ /dev/null @@ -1,105 +0,0 @@ - - After some testing, it turns out that the unused VDP address $C0001C - (mirrored at $C0001E) controls how the VDP generates the display. - - Specifically, it allows layers to be turned on and off, it affects how - high priority sprites or tiles are interpreted, and it seems to change - how layers are combined together. - - No games use this register to my knowledge, maybe it was left in for - testing or debugging purposes by the VDP manufacturer. This was all - checked on an original model Genesis, the register may not be present - or behave differently in later versions of the VDP hardware. - - Here's the layout of $C0001C/$C0001E: - - MSB LSB - -gfe ---d cba- ---- - - Notes: - - Unmarked bits have no effect. - Anything pertaining to plane A also applies to the window layer. - Any description about color intensity changes is only valid when - the VDP is in shadow/hilight mode. - - a = Display garbage (bad pattern data) on all background rows - and for the sprites. - - b = Turn display off (background and sprites) - Display is filled with background color. - CRAM data is randomly corrupted as long as this bit is set. - - c = Turn display off (background only) - In shadow/hilight mode, high priority tiles are also invisble - but are drawn in the regular normal intensity backdrop color, - while low priority tiles are drawn in the half intensity - backdrop color. - Transparent pixels in high priority sprites are also filled - with the normal intensity backdrop color, so sprites have - a tile shaped outline around them. - It seems like either underlying pixels from the background - are visible through shadow/hilight pixels in sprites, but - the colors are wrong. (as if they were logically OR'd with - the sprite pixels, as both layers can be seen) - CRAM data is randomly corrupted as long as this bit is set. - - ** When 'c' and 'b' are set, the background layers are invisible, - but sprites are not. All sprites, regardless of priority, - have a tile shaped outline around them that is drawn in some - color other than the backdrop color. (can't exactly tell) - - d = When set, garbage is displayed in the top and bottom border areas. - Plane B is disabled, only plane A is visible. - All sprites are drawn in the regular intensity backdrop color. - High priority plane B tiles are drawn in the regular intensity - background color, low priority plane B tiles are drawn in the - half intensity backdrop color. - - g,f,e = All bits turn off sprites when set. - If bit 'd' is set, bit 'e' changes the garbage data printed - in the border areas. - - Bits b,c,d have effects when combined, as the following table - shows. Some of this information is a rehash of what was explained - above. Bits g,f,e will turn off sprites in all cases. (unless they - are already off to begin with) - - Notes: - RI = regular intensity backdrop color - HI = half intensity backdrop color - A,B,S = Plane A, plane B, sprite layer - - b c d Effect - ----- ------ - 0 0 0 Display shown normally - 0 0 1 B and S off, high priority pixels from B and S drawn in RI - 0 1 0 A and B off, high priority pixels from A and S drawn in RI, sprites - have tile-shaped outline in RI. - 0 1 1 Plane A pixels seem to be OR'd with plane B pixels, and the - output is OR'd with the sprite pixels. - 1 0 0 A, B, and S off - 1 0 1 B and S off, shadow/hilight mode off - 1 1 0 A and B off, sprites have tile shaped outline in unknown color. - 1 1 1 A and S off, shadow/hilight mode off - - In mode 4, the same results apply with the following exceptions: - - - Shadow/hilight processing is always off - - - Anything that enables plane B seems to turn on a second graphics - layer, which is identical to plane A with garbage data. (so the VDP - can't really create two playfields in mode 4, but it does seem - to try to re-use plane A with bad graphics) - The settings which seem to enable plane B are when - bits b,c,d are 1,1,1, and and 0,1,1. - - - The leftmost 8 pixels show a lot of garbage data when some of the - bits are set. (seems unrelated to sprites or background) - Earlier it was discovered that the VDP doesn't draw the background - tile in the left 8 pixels when the lower 3 bits of the horizontal - scroll value are not equal to zero, it shows garbage data that seems - to be based on the sprite positions. Also, this can be seen in the - rightmost 8 columns if you enable 40-cell mode while in mode 4, so - the resulting display is 320x192. - diff --git a/source/docs/porting.txt b/source/docs/porting.txt deleted file mode 100644 index 4a92903..0000000 --- a/source/docs/porting.txt +++ /dev/null @@ -1,89 +0,0 @@ - - Introduction - - Genesis Plus has reasonable speed, and very fast rendering. Here are some - details about porting it to another platform - - Porting rules - - - This program is released under the GPL, so please release the source - code for your derivative ports. Let me know if you need an alternative - to this. - - - Do not change the name of the emulator. Something like 'Genesis Plus / MacOS' - is fine as it keeps the original name. - - - Configure the CPU emulators for little or big-endian CPUs, and use the - ALIGN_LONG option to handle unaligned memory accesses if needed. E.g. if - the emulator crashes when a game scrolls horizontally, you need to enable - it. - - Requirements - - - At this time the 16-bit rendering code has been well tested and should - be used. There is code to support 8 through 32-bit displays, but I - haven't checked if it still works. - - - Audio output, if enabled, uses stereo 16-bit samples. - - Functions to use: - - int load_rom(char *filename); - - Loads a game which can be in BIN, SMD or ZIP formats. It returns zero if - an error has occured. - - void system_init(void); - - Initializes the virtual Genesis console. Call this once during startup. - - void audio_init(int rate); - - Initialize the sound emulation part of the emulator. Pass zero or don't - call the function to disable sound. Call this after running system_init(). - - void system_reset(void); - - Resets the virtual Genesis console. Call this once during setup, and later - as needed. - - int system_frame(int skip); - - Updates the emulation for a frame. Pass 1 to prevent rendering (which can - be used for frame skipping) and 0 to render the current display. - - This function returns 0 if the virtual Genesis console has locked up. - You can do what you'd like with this information, such as notify the user, - reset the machine, etc. - - If audio is enabled, the snd.buffer[] array will hold the current audio - data for this frame. - - void system_shutdown(void); - - Shuts down the emulator. - - Variables: - - The 'bitmap' structure needs to be filled out prior to calling system_init(). - This provides the rendering code with information about the type of bitmap - it is rendering to. I would advise sticking with a 1024x512 16-bit bitmap: - - memset(&bitmap, 0, sizeof(t_bitmap)); - bitmap.width = 1024; - bitmap.height = 512; - bitmap.depth = 16; - bitmap.granularity = 2; /* Bytes per pixel */ - bitmap.pitch = (bitmap.width * bitmap.granularity); - bitmap.data = (unsigned char *)bmp->pixels; /* Pointer to your bitmap */ - bitmap.viewport.w = 256; /* Initial size of display on power-up (do not change) */ - bitmap.viewport.h = 224; - bitmap.viewport.x = 0x20; /* Offset used for rendering (do not change) */ - bitmap.viewport.y = 0x00; - bitmap.remap = 1; - - The variable 'input.pad[0]' holds the button states for the first player - gamepad. Update this prior to calling system_frame(), and use the bitmasks - defined in system.h such as 'INPUT_UP', etc. - - See the Windows/SDL and DOS drivers for examples. diff --git a/source/docs/readme.txt b/source/docs/readme.txt deleted file mode 100644 index 130800d..0000000 --- a/source/docs/readme.txt +++ /dev/null @@ -1,122 +0,0 @@ - ---------------------------------------------------------------------------- - Genesis Plus - ---------------------------------------------------------------------------- - - Version 1.2a - by Charles Mac Donald - WWW: http://cgfm2.emuviews.com - - What's New - ---------- - - [06/22/03] - - Modified rendering code for portability - - Modified memory handling to fix banked PSG access - [05/13/03] - - Initial release - - Usage - ----- - - The Windows version runs windowed in a 16-bit desktop with NO sound or - joystick support. - - The DOS version has most of the functionality from SMS Plus, such - as audio, joysticks, etc. - - Windows/DOS controls: - - Arrow Keys - Directional pad - A,S,D,F - 1P gamepad, buttons A, B, C, Start - Tab - Reset - Esc - Exit program - - DOS only: - - End - Exit program - F1-F4 - Set frameskip level (F1 = no skip ... F4 = skip 3 frames) - F8 - Make PCX screen snapshot - F9 - Toggle VSync - F10 - Toggle speed throttling - F11 - Toggle FPS meter - - DOS details: - - You can only support a second player if you are using a joystick driver - that supports more than one joystick. (e.g. Sidewinder, dual pads, etc.) - - Type 'gen -help' on the command line for a list of useful options. - - -res set the display resolution. - -vdriver specify video driver. - -depth specify color depth. (8, 16) - -scanlines use scanlines effect. - -scale scale display to full resolution. (slow) - -vsync wait for vertical sync before blitting. - -sound enable sound. (force speed throttling) - -sndrate specify sound rate. (8000, 11025, 22050, 44100) - -sndcard specify sound card. (0-7) - -swap swap left and right stereo output. - -joy specify joystick type. - - Here is a list of all the video drivers you can pass as a parameter - to the '-vdriver' option: - - auto, safe, vga, modex, vesa2l, vesa3, vbeaf - - Here is a list of all the joystick drivers you can pass as a parameter - to the '-joy' option: - - auto, none, standard, 2pads, 4button, 6button, 8button, fspro, wingex, - sidewinder, gamepadpro, grip, grip4, sneslpt1, sneslpt2, sneslpt3, - psxlpt1, psxlpt2, psxlpt3, n64lpt1, n64lpt2, n64lpt3, db9lpt1, db9lpt2, - db9lpt3, tglpt1, tglpt2, tglpt3, wingwar, segaisa, segapci, segapci2 - - You can put any commandline option into a plain text file which should - be called "gen.cfg". Put one option per line, please. Command line options - will override anything in the configuration file. - - Currently the zip loading code can manage a zipfile where the game - image is the first thing in it. If you try to open a huge archive of - games, only the first will be played. - - Credits and Acknowlegements - --------------------------- - - I would like to thank Omar Cornut, Christian Schiller, and Chris MacDonald - for their invaluable help and support with this project. - - Richard Bannister for the Macintosh port and all of the code fixes and - suggestions that have made Genesis Plus a better program. - (http://www.bannister.org) - - The Genesis emulator authors: Bart Trzynadlowski, Quintesson, Steve Snake, - James Ponder, Stef, Gerrie, Sardu. - - The regular people and many lurkers at segadev. - - The MAME team for the CPU and sound chip emulators. - - Everyone who has contributed, donated, and submitted information to help - out Genesis Plus and my efforts documenting the Genesis hardware. - - Contact - ------- - - Charles MacDonald - E-mail: cgfm2@hotmail.com - WWW: http://cgfm2.emuviews.com - - Legal - ----- - - Copyright (C) 1999, 2000, 2001, 2002, 2003 Charles MacDonald - - The source code is distributed under the terms of the GNU General Public - License. - - The Z80 CPU emulator, 68K CPU emulator, and the PSG, YM2612 emulation code - are taken from the MAME project, and terms of their use are covered under - the MAME license. - (http://www.mame.net) - diff --git a/source/docs/ssf2tnc.txt b/source/docs/ssf2tnc.txt deleted file mode 100644 index cc1860f..0000000 --- a/source/docs/ssf2tnc.txt +++ /dev/null @@ -1,189 +0,0 @@ - --------------------------------------- - SSFII GENESIS TECHNICAL INFORMATION - Second Edition (July 26, 2000) - Bart Trzynadlowski - --------------------------------------- - - -The purpose of this document is to discuss the workings of the Genesis port of -Capcom's "Super Street Fighter II The New Challengers". Virtually all of this -information was originally found by others' efforts. - Please credit "those who contributed information" rather than me if -you use any of this information. You may pass this document around freely, but -please keep it unaltered. If you see any errors or have more info, contact me. -I can be reached at trzy@powernet.net. - - Second Edition: July 26, 2000 - - Major update with correct information thanks to Tim Meekins - First Edition: July 21, 2000 - - Initial release - - -0. THE SSFII CHALLENGE - -The challenge behind getting "Super Street Fighter II The New Challengers" -(SSFII) to work on a Genesis emulator lies primarily in the fact that the game -is stored on a 40 megabit (5 megabyte) cartridge. - The Sega Genesis maps ROM from 0x000000 to 0x3FFFFF which means that -the CPU can only see 4 megabytes of cartridge ROM. SSFII needed more space for -the backgrounds and thus Capcom opted for a special 5 megabyte cartridge with -bankswitching in order to access the area of ROM outside of normal range. - - -1. THE BANKSWITCHING MECHANISM - -The bankswitching mechanism probably resides on the cartridge. I'm 99% sure of -this. Sega documentation does offer a description of the mechanism, though, -which led me to suspect for a moment that perhaps the mechanism was on the -Genesis itself. - The idea is unlikely though, as that range of registers is used by the -32X for an entirely different purpose. I have been informed that that range -(which is marked as "SEGA RESERVED" in the Genesis developer's manual) can be -used for extra devices which may be present on the cartridge. - -The bankswitching mechanism is very simple. It views the addressable 4 mega- -bytes of ROM as 8 512KB regions. The first area, 0x000000-0x07FFFF is fixed -and cannot be remapped because that is where the vector table resides. - The banking registers on the cartridge work by allocating the 512KB -chunk to a given part of the addressable 4MB ROM space. Below are the -registers and what range they correspond to. The value written to a register -will cause the specified 512KB page to be mapped to that region. A page is -specified with 6 bits (bits 7 and 6 are always 0) thus allowing a possible 64 -pages (SSFII only has 10, though.) - - 0xA130F3: 0x080000 - 0x0FFFFF - 0xA130F5: 0x100000 - 0x17FFFF - 0xA130F7: 0x180000 - 0x1FFFFF - 0xA130F9: 0x200000 - 0x27FFFF - 0xA130FB: 0x280000 - 0x2FFFFF - 0xA130FD: 0x300000 - 0x37FFFF - 0xA130FF: 0x380000 - 0x3FFFFF - -The registers are accessed through byte writes. I haven't seen SSFII try to -read any of the registers, so I don't know if it's possible or not. I don't -emulate anything besides byte writes in my emulator. - There is also a register 0xA130F1. Apparently the regions specified by -0xA130F9-0xA130FF (0x200000-0x3FFFFF) can be either ROM or RAM and can be -write-protected. Here is the layout of the register as far as I know: - - 7 6 5 4 3 2 1 0 - +-----------------------+ - |??|??|??|??|??|??|WP|MD| - +-----------------------+ - - MD: Mode -- 0 = ROM, 1 = RAM - WP: Write protect -- 0 = writable, 1 = not writable - -Emulation of the 0xA130F1 register is not necessary, SSFII initializes it at -start-up by writing 0 I believe, which signifies ROM and no write protection -to the regions at 0x200000-0x3FFFFF (ROM isn't writable anyway, there isn't a -need for protection.) - -Examples: - - If 0x01 is written to register 0xA130FF, 0x080000-0x0FFFFF is visible - at 0x380000-0x3FFFFF. - If 0x08 is written to register 0xA130F9, the first 512KB of the - normally invisible upper 1MB of ROM is now visible at 0x200000- - 0x27FFFF. - -The registers simply represent address ranges in the 4MB ROM area and you can -page in data to these ranges by specifying the bank # -- it's that simple! - - -2. CHECKSUM - -SSFII contains a checksum routine which calculates the checksum of the first -4MB of the ROM; it then pages in the last 1MB of ROM to 0x300000-0x3FFFFF. -It does this by writing to the bank registers. The following code is taken -directly from the US ROM dumped by Genesis Power: - - ... Checksum first 4MB of ROM (0x000000-0x3FFFFF) ... - 0x003BEC: move.b #$08, ($A130FD) - 0x003BF4: move.b #$09, ($A130FF) - 0x003BFC: lea ($300000), a0 - ... Checksum uppper 1MB of ROM now mapped at 0x300000-0x3FFFFF ... - -The bankswitching hardware must be properly emulated before the game starts -working. If it is not, the checksum will fail and the game will hang with a -red screen. - In the Genesis Power US dump, you can jump to 0x003C3C to avoid the -checksum routine, this is where program flow transfers to if the checksum was -found to be valid. The game doesn't do anything important before the checksum -code as far as emulation is concerned. It writes the SEGA message to the -Trademark Security System register and does some joypad init stuff. - - -3. EMULATING SSFII - -SSFII is fairly straightforward to emulate. All you need to do is detect the -game, load up all 5MB, and emulate the banking registers. The easiest way to -do it, in my opinion, is to keep a second copy of the ROM and do memcpy()s -from that second copy to the ROM being emulated. - -For example, here is how Genital does it... I've got genesis.rom which is the -buffer where ROMs are loaded and executed. There is also genesis.rom_ssf2 -which is another 5MB buffer where I load the SSFII ROM to as well. - The bankswitching register emulation is done in my IOWriteByte() -function (which handles byte writes to the 0xA00000-0xBFFFFF range). The -following is the code I use: - -if (addr >= 0xa130f3 && config.ssf2_emu) -{ - switch (addr & 0xf) - { - case 0x3: /* 080000-0FFFFF */ - memcpy((genesis.rom + 0x080000), (genesis.rom_ssf2 + (data * 0x80000)), 0x80000); - break; - case 0x5: /* 100000-17FFFF */ - memcpy((genesis.rom + 0x100000), (genesis.rom_ssf2 + (data * 0x80000)), 0x80000); - break; - case 0x7: /* 180000-1FFFFF */ - memcpy((genesis.rom + 0x180000), (genesis.rom_ssf2 + (data * 0x80000)), 0x80000); - break; - case 0x9: /* 200000-27FFFF */ - memcpy((genesis.rom + 0x200000), (genesis.rom_ssf2 + (data * 0x80000)), 0x80000); - break; - case 0xb: /* 280000-2FFFFF */ - memcpy((genesis.rom + 0x280000), (genesis.rom_ssf2 + (data * 0x80000)), 0x80000); - break; - case 0xd: /* 300000-37FFFF */ - memcpy((genesis.rom + 0x300000), (genesis.rom_ssf2 + (data * 0x80000)), 0x80000); - break; - case 0xf: /* 380000-3FFFFF */ - memcpy((genesis.rom + 0x380000), (genesis.rom_ssf2 + (data * 0x80000)), 0x80000); - break; - default: - break; - } - return; -} - -Pardon the bad formatting, it just wouldn't fit correctly in the 80 columns -that the rest of the document sticks to. - The first line checks whether the address is 0xA130F3 or above (notice -how 0xA130F1 is ignored, SSFII doesn't really use it) and if SSFII emulation -is enabled (in Genital, I have a flag -- config.ssf2_emu -- which is set to 1 -to indicate SSFII emulation should occur.) The remainder of the code is a -switch () statement which handles the register emulation. - Since 0x80000 = 512KB, and the data variable holds the byte written to -the register, data * 0x80000 yields the offset into the ROM that has been -requested to be mapped. - At first glance, memcpy()s may seem inefficient and slow. Although it -is true, this doesn't apply to emulating SSFII since the game doesn't do much -(if any) bankswitching during gameplay. No slowdown due to the memcpy()s is -noticable. - -If you are using an emulator like Starscream which requires the ROMs to be -byteswapped, make certain both ROM images are byteswapped. If you don't use -2 copies of the ROM, you will find the game will still have several glitches -because the memcpy()s will be destroying the data they write over. - - -4. CONCLUSION - -That's all there is to it. This should be sufficient information for anyone -wishing to implement SSFII support in their Sega Genesis emulator. If you have -any questions at all (I'm not great at making things clear) feel free to email -me at trzy@powernet.net. - diff --git a/source/docs/ste.txt b/source/docs/ste.txt deleted file mode 100644 index 267432a..0000000 --- a/source/docs/ste.txt +++ /dev/null @@ -1,152 +0,0 @@ - - Shadow / Hilight description - Version 0.1 (03/06/01) - - by Charles MacDonald - WWW: http://cgfm2.emuviews.com - - Unpublished work Copyright 2001 Charles MacDonald - - - Table of contents - - 1.) Introduction - 2.) Color generation - 3.) Backgrounds - 4.) Sprites - 5.) Overscan / border area - 6.) Miscellaneous - 7.) Games that use shadow / hilight mode - 8.) Disclaimer - - - 1.) Introduction - - The shadow / hilight feature has never been properly documented, so here's - my attempt at doing just that. - - I'd like to thank Flavio Morsoletto for sharing results from his - shadow / hilight tests. - - 2.) Color generation - - As the VDP draws each pixel of the display, it uses the raw pattern data - and palette values to select an entry from CRAM, which is used to - create red, green, and blue values that define the color of the current - pixel being drawn. - - In shadow / hilight mode, the VDP can do two things to the resulting pixel - color, either divide it's intensity (brightness) in half, or double it. - This is based on two factors, the priority level of the pixel, and the - values of the raw pattern and palette data. - - In terms of how the colors are actually generated, imagine that each 3-bit - color value from CRAM is scaled up to fit a 0 to 63 range. Half intensity - colors would would range from 0 to 31, normal intensity colors would - range from 0 to 63, and double intensity colors would range from 32 to 63. - - 3.) Backgrounds - - Low priority background tiles are shown at half intensity, high priority - background tiles are shown at normal intensity. - - When the VDP renders high priority tiles, it does not take transparent - pixels into account. Instead, any underlying pixels (either from the - background, sprites, or backdrop) will be shown at normal intensity. - - For example, if you had a completely transparent tile on plane B that - had it's priority bit set, any pixel from plane A or the sprite layer - that fell within the tile's 8x8 pixel area would be shown at normal - intensity. - - 4.) Sprites - - Low priority sprites are shown at half intensity, high priority sprites - are shown at normal intensity. The priority values do not affect the - intensity of any overlapping sprites. - - Any high-priority background tile will force a low-priority sprite to - be shown at normal intensity. - - I'm going to call any sprite pixel that uses color 3Eh a hilight - operator, and any sprite pixel that uses color 3Fh a shadow operator. - Such pixels are not drawn by the VDP, but instead are treated as - transparent. - - A shadow operator forces the underlying background or backdrop pixel - to be shown at half intensity, regardless of the pixel's priority. - - A hilight operator forces the underlying background or backdrop pixel - to be shown at normal intensity if it is currently at half intensity, - or at double intensity if it is currently at normal intensity. - - Operator pixels do not affect other sprites. In the case of operator - pixels overlapping, the first sprite in the sprite list is the one that - defines how the underlying background / backdrop pixel is modified. - - 5.) Overscan / border area - - The backdrop is the entire display area (usually 256x224 pixels), which is - filled with the color value selected in VDP register #7. The background - layers and sprites are overlaid on top of the backdrop, so that any pixel - where no background or sprite pixels exist will show the backdrop color. - - Overscan is the area outside of the physical display. You can see it if - you adjust the vertical or horizontal hold of a monitor to see past the - top/bottom or left/right edges of the screen. - - When shadow / hilight mode is enabled, the overscan area is always - displayed at half intensity. The backdrop is also shown at half intensity, - but that can be modified by overlaying background tiles or sprites. - (either by priority, or by operator pixels) - - If the display is blanked (bit 6 of VDP register #1) or the leftmost - column is blanked (bit 5 of VDP register #0), the portion of the display - in question has the same properties as the overscan area. (meaning - sprites and background tiles cannot affect it's intensity, it is - always fixed to half intensity) - - 6.) Miscellaneous - - There is a bug in the way sprite pixel colors are processed by the VDP. - Color 0Eh of palettes 00-02h is always displayed at normal intensity, - regardless of the priority level of the sprite. - - The contents of CRAM for colors 3Eh and 3Fh do not affect the shadow or - hilight effect. Though I've noticed many games set one or more of the - RGB values for either entry to maximum, like 0EEEh or 0E0Eh. - - For those of you who want some statistics, the Genesis VDP can display 61 - of 512 colors normally, and 183 of 1536 colors in shadow / hilight mode. - That doesn't include duplicate colors, which may or may not exist. - - 7.) Games that use shadow / hilight mode - - - Adventures of Batman & Robin - - Ecco 2 : The Tides of Time - - Gauntlet IV - - Mega Turrican - - Mortal Kombat - - Shinobi III - - Skeleton Krew - - Sonic 2 - - Sonic 3, Sonic & Knuckles - - Sonic 3D Blast - - Space Harrier II - - Sub Terrania - - Red Zone - - Ranger-X - - 8.) 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. - diff --git a/source/docs/todo.txt b/source/docs/todo.txt deleted file mode 100644 index 624ba22..0000000 --- a/source/docs/todo.txt +++ /dev/null @@ -1,79 +0,0 @@ - - Here are some technical details about things that need to be fixed or - added to Genesis Plus. - - Missing features: - - - Support for 6-button controllers - - SRAM management - - Game Genie / PAR patch codes - - The VDP code could use a lot of cleaning up. - - The rendering code is missing a few bits: - - - Sprite collision - - Window bug - - I think the "C" 68000 emulator either has some bugs or I'm not using it - correctly. Older DOS-only versions used Turbo68K, which had ran games - much better, especially with regards to interrupt handling. - - Things that need to be fixed: - - - Raster garbage on third road in Thunder Blade. - - - Added country codes for Dragon Slayer, but game locks up after - passing country check. - - - No inputs in Samurai Shodown. - (This game doesn't initialize the port direction registers, at least not - directly. Emulation bug or problem with the game?) - - - Palette and raster problems in Mortal Kombat. - - - Bad raster effects and VRAM corruption in Super Skidmarks. - (Needs PAL timing) - - - Palette problems in Sonic 2 title screen. - - - Masked half of Sonic sprite visible on Sonic title screen. - - - Sprite masking doesn't work in Micro Machines subscreen. - - - Music has slow tempo in Batman & Robin. (doesn't seem to be a problem - with the YM2612 timers - Wonderboy 3 is normal) - - - Music has jerky playback in Sonic 2, 3, 3D Blast. If you run the Z80 - emulation for one scanline after requesting an interrupt, it runs fine. - - - DAC and PSG output are too loud, both are divided by two for now - (though the PSG should be a bit quieter and the DAC a bit louder) - - - Undead Line locks after selecting a stage, also the Z80 sound halts - after the first note is played. - - This game single steps the Z80 with the following code: - - MOVEM.L D0,-(A7) ; 009C7C 48 E7 80 00 - ORI #$0200,SR ; 009C80 00 7C 02 00 -; Get control of the Z-bus - MOVE.W #$0100,$00A11100 ; 009C84 33 FC 01 00 00 A1 11 00 - BTST #$00,$00A11100 ; 009C8C 08 39 00 00 00 A1 11 00 - BNE.S *-$08 [00009C8C] ; 009C94 66 F6 -; Check driver status byte. If zero, release bus and exit. - TST.B $00A00008 ; 009C96 4A 39 00 A0 00 08 - BEQ *+$0016 [00009CB2] ; 009C9C 67 00 00 14 -; Release bus and wait for Z80 to resume control. Then restart the loop -; and immediately get the bus back again, assuming the Z80 ran at least -; one instruction in the meantime. - CLR.W $00A11100 ; 009CA0 42 79 00 A1 11 00 - BTST #$00,$00A11100 ; 009CA6 08 39 00 00 00 A1 11 00 - BEQ.S *-$08 [00009CA6] ; 009CAE 67 F6 - BRA.S *-$2C [00009C84] ; 009CB0 60 D2 -; Release bus and exit. - CLR.W $00A11100 ; 009CB2 42 79 00 A1 11 00 - ANDI #$FDFF,SR ; 009CB8 02 7C FD FF - MOVEM.L (A7)+,D0 ; 009CBC 4C DF 00 01 - RTS ; 009CC0 4E 75 - diff --git a/source/docs/ym2612.txt b/source/docs/ym2612.txt deleted file mode 100644 index 3f0442a..0000000 --- a/source/docs/ym2612.txt +++ /dev/null @@ -1,26 +0,0 @@ -Here's the format of the YM2612 test register ($21), as best as I can -tell: - -bit 7 - If bit 6 set, select 0=LSB, 1=MSB of serial data -bit 6 - If set, reading status returns serial data LSB or MSB instead of -status flags -bit 5 - If set, only the attack phase and possibly decay occur, there is -no sustain o release. It sounds like each channel was keyed-on rapidly. -When the bit is cleared, the channels resume their original position -within the envelope so this bit doesn't have any lasting change on -them. -bit 4 - Data sent to DAC is inverted - this is *really* loud, so turn -down the volume before using this bit. ;) -bit 3 - Audio output is muted, (the PSG still works of course) bits 4,5 -will make sound faintly audible when set in conjunction. -bit 2 - Timer A and B run 24 times faster. -bits 1,0 - No effect. - -Bits 7, 6 allow you to read the serial data sent from the YM2612 to the -DAC. (the other chip, YM3012 - not the DAC at $2A/$2B) I'm unsure of the -exact format, it's probably similar to the YM2151. Bit 4 inverts the -data sent to the DAC, but not the data read from the status register. -Compared to the YM2151 test register documented in MAME, the last 3 bits -may have something to do with the LFO. And I'm also not entirely sure -about the MSB/LSB order for bit 6. Other than that the two work in a -mostly identical way.