mirror of
https://github.com/ekeeke/Genesis-Plus-GX.git
synced 2024-11-04 18:05:06 +01:00
This commit is contained in:
parent
3b94e20507
commit
82924b00b1
@ -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 <sigh>
|
||||
- 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" <sigh>
|
||||
|
||||
|
||||
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!
|
@ -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.
|
||||
|
@ -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.
|
||||
|
@ -1,235 +0,0 @@
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>GameGenie patches</TITLE>
|
||||
</HEAD>
|
||||
<BODY TEXT="#000000" BGCOLOR="#FEFEF4">
|
||||
<BASEFONT FACE="MS Sans Serif" SIZE="-1">
|
||||
|
||||
<BR>
|
||||
<CENTER><H1>GameGenie Patching</H1></CENTER>
|
||||
<BR>
|
||||
<P> 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!</P>
|
||||
<P> 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.</P>
|
||||
<P> 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.</P>
|
||||
|
||||
<TABLE WIDTH="70%" BORDER="0" ALIGN="CENTER">
|
||||
<TR>
|
||||
<TD>
|
||||
<TABLE BORDER="1" ALIGN="CENTER">
|
||||
<TR>
|
||||
<TH>Char</TH>
|
||||
<TH>Value</TH>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">A</TD><TD>00000</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">B</TD><TD>00001</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">C</TD><TD>00010</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">D</TD><TD>00011</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">E</TD><TD>00100</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">F</TD><TD>00101</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">G</TD><TD>00110</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">H</TD><TD>00111</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">J</TD><TD>01000</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">K</TD><TD>01001</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">L</TD><TD>01010</TD>
|
||||
</TR>
|
||||
</TABLE>
|
||||
</TD>
|
||||
<TD VALIGN="TOP">
|
||||
<TABLE BORDER="1" ALIGN="CENTER">
|
||||
<TR>
|
||||
<TH>Char</TH>
|
||||
<TH>Value</TH>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">M</TD><TD>01011</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">N</TD><TD>01100</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">P</TD><TD>01101</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">R</TD><TD>01110</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">S</TD><TD>01111</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">T</TD><TD>10000</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">V</TD><TD>10001</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">W</TD><TD>10010</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">X</TD><TD>10011</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">Y</TD><TD>10100</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">Z</TD><TD>10101</TD>
|
||||
</TR>
|
||||
</TABLE>
|
||||
</TD>
|
||||
<TD VALIGN="TOP">
|
||||
<TABLE BORDER="1" ALIGN="CENTER">
|
||||
<TR>
|
||||
<TH>Char</TH>
|
||||
<TH>Value</TH>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">0</TD><TD>10110</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">1</TD><TD>10111</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">2</TD><TD>11000</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">3</TD><TD>11001</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">4</TD><TD>11010</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">5</TD><TD>11011</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">6</TD><TD>11100</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">7</TD><TD>11101</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">8</TD><TD>11110</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD ALIGN="CENTER">9</TD><TD>11111</TD>
|
||||
</TR>
|
||||
</TABLE>
|
||||
</TD>
|
||||
</TR>
|
||||
</TABLE>
|
||||
<BR>
|
||||
<P> 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:</P>
|
||||
<FONT FACE="Courier">
|
||||
<TABLE BORDER="0" ALIGN="CENTER">
|
||||
<TR>
|
||||
<TD>
|
||||
<TABLE BORDER="0" ALIGN="CENTER">
|
||||
<TR><TD ALIGN="RIGHT" VALIGN="MIDDLE">Code:</TD></TR>
|
||||
<TR><TD ALIGN="RIGHT" VALIGN="MIDDLE">Bits:</TD></TR>
|
||||
<TR><TD ALIGN="RIGHT" VALIGN="MIDDLE">Id:</TD></TR>
|
||||
</TABLE>
|
||||
</TD>
|
||||
<TD>
|
||||
<TABLE BORDER="1" ALIGN="CENTER">
|
||||
<TR ALIGN="CENTER">
|
||||
<TD>S</TD><TD>C</TD><TD>R</TD><TD>A</TD>
|
||||
</TR>
|
||||
<TR ALIGN="CENTER">
|
||||
<TD>01111</TD><TD>00010</TD><TD>01110</TD><TD>00000</TD>
|
||||
</TR>
|
||||
<TR ALIGN="CENTER">
|
||||
<TD>ijklm</TD><TD>nopIJ</TD><TD>KLMNO</TD><TD>PABCD</TD>
|
||||
</TR>
|
||||
</TABLE>
|
||||
</TD>
|
||||
<TD>
|
||||
<TABLE BORDER="0" ALIGN="CENTER">
|
||||
<TR><TD ALIGN="RIGHT" VALIGN="MIDDLE">-</TD></TR>
|
||||
<TR><TD ALIGN="RIGHT" VALIGN="MIDDLE">-</TD></TR>
|
||||
<TR><TD ALIGN="RIGHT" VALIGN="MIDDLE">-</TD></TR>
|
||||
</TABLE>
|
||||
</TD>
|
||||
<TD>
|
||||
<TABLE BORDER="1" ALIGN="CENTER">
|
||||
<TR ALIGN="CENTER"><TD>B</TD><TD>J</TD><TD>X</TD><TD>0</TD></TR>
|
||||
<TR ALIGN="CENTER"><TD>00001</TD><TD>01000</TD><TD>10011</TD><TD>10110</TD></TR>
|
||||
<TR ALIGN="CENTER"><TD>EFGHd</TD><TD>efgha</TD><TD>bcQRS</TD><TD>TUVWX</TD></TR>
|
||||
</TABLE>
|
||||
</TD>
|
||||
</TR>
|
||||
</TABLE>
|
||||
</FONT>
|
||||
<P> Then rearrange (using the id) as...</P>
|
||||
<FONT FACE="Courier">
|
||||
<TABLE BORDER="0" ALIGN="CENTER">
|
||||
<TR>
|
||||
<TD>
|
||||
<TABLE BORDER="0" ALIGN="CENTER">
|
||||
<TR><TD ALIGN="RIGHT" VALIGN="MIDDLE">Bits:</TD></TR>
|
||||
<TR><TD ALIGN="RIGHT" VALIGN="MIDDLE">Id:</TD></TR>
|
||||
</TABLE>
|
||||
</TD>
|
||||
<TD>
|
||||
<TABLE BORDER="1" ALIGN="CENTER">
|
||||
<TR>
|
||||
<TD>00000000</TD><TD>10011100</TD><TD>01110110</TD>
|
||||
</TR>
|
||||
<TR ALIGN="CENTER">
|
||||
<TD>ABCDEFGH</TD><TD>IJKLMNOP</TD><TD>QRSTUVWX</TD>
|
||||
</TR>
|
||||
</TABLE>
|
||||
</TD>
|
||||
<TD>
|
||||
<TABLE BORDER="0" ALIGN="CENTER">
|
||||
<TR><TD ALIGN="RIGHT" VALIGN="MIDDLE">:</TD></TR>
|
||||
<TR><TD ALIGN="RIGHT" VALIGN="MIDDLE">:</TD></TR>
|
||||
</TABLE>
|
||||
</TD>
|
||||
<TD>
|
||||
<TABLE BORDER="1">
|
||||
<TR ALIGN="CENTER"><TD>01010100</TD> <TD>01111000</TD></TR>
|
||||
<TR ALIGN="CENTER"><TD>abcdefgh</TD><TD>ijklmnop</TD></TR>
|
||||
</TABLE>
|
||||
</TD>
|
||||
</TR>
|
||||
</TABLE>
|
||||
</FONT>
|
||||
<BR>
|
||||
<P> Which give us, in hexa, <B>009C76:5478</B>. This means that
|
||||
<B>H5478</B> will be written at <B>H009C76</B> memory offset.</P>
|
||||
</BODY>
|
||||
</HTML>
|
@ -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.
|
||||
|
Binary file not shown.
@ -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.
|
||||
|
||||
|
Binary file not shown.
@ -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.
|
File diff suppressed because it is too large
Load Diff
@ -1,933 +0,0 @@
|
||||
<html><head><title>Sega Genesis I/O Chip and Peripherals</title></head><body>
|
||||
|
||||
<h2>Sega Genesis I/O Chip and Peripherals</h2>
|
||||
By Charles MacDonald<br>
|
||||
<a href="http://cgfm2.emuviews.com/">http://cgfm2.emuviews.com</a>
|
||||
<hr>
|
||||
|
||||
<h4>Contents</h4>
|
||||
<ul>
|
||||
<li><a href="#ovr">Overview</a>
|
||||
</li><li><a href="#con">Connector details</a>
|
||||
</li><li><a href="#cpu">CPU interface</a>
|
||||
</li><li><a href="#reg">Register list</a>
|
||||
</li><li><a href="#ver">Version register</a>
|
||||
</li><li><a href="#dat">Data register</a>
|
||||
</li><li><a href="#dir">Control register</a>
|
||||
</li><li><a href="#scr">Serial control register</a>
|
||||
</li><li><a href="#txd">TxData register</a>
|
||||
</li><li><a href="#rxd">RxData register</a>
|
||||
</li><li><a href="#ser">Using serial communication</a>
|
||||
</li><li><a href="#per">Peripheral devices</a>
|
||||
<ul>
|
||||
<li><a href="#md2">2-button Mark-III gamepad</a>
|
||||
</li><li><a href="#md3">3-button standard gamepad</a>
|
||||
</li><li><a href="#md6">Fighting Pad 6B</a><i>(incomplete)</i>
|
||||
</li><li><a href="#gun">Lightguns (Sega Menacer, Konami Justifier)</a><i>(incomplete)</i>
|
||||
</li><li><a href="#eat">EA 4-Way Play</a>
|
||||
</li><li><a href="#mul">Sega Team Player</a><i>(incomplete)</i>
|
||||
</li><li><a href="#mmo">Sega Mega Mouse</a>
|
||||
</li></ul>
|
||||
</li><li><a href="#msc">Miscellaneous</a>
|
||||
</li><li><a href="#dis">Disclaimer</a>
|
||||
</li></ul>
|
||||
|
||||
<a name="ovr">
|
||||
</a><h4><a name="ovr">Overview</a></h4>
|
||||
<p>
|
||||
<a name="ovr"> 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.
|
||||
</a></p>
|
||||
|
||||
<a name="con">
|
||||
</a><h4><a name="con">Connector details</a></h4>
|
||||
<p>
|
||||
<a name="con"> 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:
|
||||
</a></p>
|
||||
|
||||
<pre><a name="con"> 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
|
||||
</a></pre>
|
||||
|
||||
<a name="cpu">
|
||||
</a><h4><a name="cpu">CPU interface</a></h4>
|
||||
|
||||
<p>
|
||||
<a name="cpu"> 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.
|
||||
<br><br>
|
||||
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:
|
||||
</a></p><pre><a name="cpu"> ; 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
|
||||
</a></pre>
|
||||
<p></p>
|
||||
|
||||
<a name="reg">
|
||||
</a><h4><a name="reg">Register list</a></h4>
|
||||
|
||||
<table bgcolor="#f0f0f0" border="0" cellpadding="4">
|
||||
<tbody><tr bgcolor="#cccccc">
|
||||
<td>Address</td>
|
||||
<td>Description</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$A10001</td>
|
||||
<td>Version</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$A10003</td>
|
||||
<td>Port A data</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$A10005</td>
|
||||
<td>Port B data</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$A10007</td>
|
||||
<td>Port C data</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$A10009</td>
|
||||
<td>Port A control</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$A1000B</td>
|
||||
<td>Port B control</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$A1000D</td>
|
||||
<td>Port C control</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$A1000F</td>
|
||||
<td>Port A TxData</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$A10011</td>
|
||||
<td>Port A RxData</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$A10013</td>
|
||||
<td>Port A serial control</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$A10015</td>
|
||||
<td>Port B TxData</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$A10017</td>
|
||||
<td>Port B RxData</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$A10019</td>
|
||||
<td>Port B serial control</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$A1001B</td>
|
||||
<td>Port C TxData</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$A1001D</td>
|
||||
<td>Port C RxData</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$A1001F</td>
|
||||
<td>Port C serial control</td>
|
||||
</tr>
|
||||
|
||||
</tbody></table>
|
||||
|
||||
<a name="ver">
|
||||
</a><h4><a name="ver">Version register</a></h4>
|
||||
<p>
|
||||
<a name="ver"> 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. </a></p><pre><a name="ver"> 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
|
||||
</a></pre>
|
||||
|
||||
<a name="ver"> Bit 5 is used by the Sega CD, returning '0' when it is attached and '1' when it is not.
|
||||
|
||||
<br><br>
|
||||
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.
|
||||
|
||||
<br><br>
|
||||
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:
|
||||
</a><p></p>
|
||||
|
||||
<table bgcolor="#f0f0f0" border="0" cellpadding="4">
|
||||
<tbody><tr bgcolor="#cccccc">
|
||||
<td>Bit 7</td>
|
||||
<td>Bit 6</td>
|
||||
<td>TV type</td>
|
||||
<td>Region</td>
|
||||
<td>Comments</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>0</td>
|
||||
<td>0</td>
|
||||
<td>NTSC</td>
|
||||
<td>Japan, Korea, Taiwan</td>
|
||||
<td>262 lines, 60 FPS</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>0</td>
|
||||
<td>1</td>
|
||||
<td>PAL</td>
|
||||
<td>Japan</td>
|
||||
<td>No hardware actually uses this setting</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>1</td>
|
||||
<td>0</td>
|
||||
<td>NTSC</td>
|
||||
<td>USA, Canada</td>
|
||||
<td>262 lines, 60 FPS</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>1</td>
|
||||
<td>0</td>
|
||||
<td>PAL-M</td>
|
||||
<td>Brazil</td>
|
||||
<td>262 lines, 60 FPS</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>1</td>
|
||||
<td>1</td>
|
||||
<td>PAL</td>
|
||||
<td>Europe, Hong Kong</td>
|
||||
<td>313 lines, 50 FPS</td>
|
||||
</tr>
|
||||
</tbody></table>
|
||||
|
||||
<p>
|
||||
<a name="ver"> 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. <br><br>
|
||||
Later games have a slightly more complex code.
|
||||
Here's the table Sega uses to determine valid codes to use:
|
||||
</a></p>
|
||||
|
||||
<table bgcolor="#f0f0f0" border="0" cellpadding="4">
|
||||
<tbody><tr bgcolor="#cccccc">
|
||||
<td colspan="2">$A10001</td>
|
||||
<td> </td>
|
||||
<td rowspan="2">Main Sales Territories</td>
|
||||
<td colspan="16">Hardware Enable Code (numbers from 0 to F below)</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#cccccc">
|
||||
<td>Bit 7</td>
|
||||
<td>Bit 6</td>
|
||||
<td>Hardware Type</td>
|
||||
<td>0</td>
|
||||
<td>1</td>
|
||||
<td>2</td>
|
||||
<td>3</td>
|
||||
<td>4</td>
|
||||
<td>5</td>
|
||||
<td>6</td>
|
||||
<td>7</td>
|
||||
<td>8</td>
|
||||
<td>9</td>
|
||||
<td>A</td>
|
||||
<td>B</td>
|
||||
<td>C</td>
|
||||
<td>D</td>
|
||||
<td>E</td>
|
||||
<td>F</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>0</td>
|
||||
<td>0</td>
|
||||
<td>Japan, NTSC</td>
|
||||
<td>Japan, S. Korea, Taiwan</td>
|
||||
<td>X</td>
|
||||
<td>O</td>
|
||||
<td>X</td>
|
||||
<td>O</td>
|
||||
<td>X</td>
|
||||
<td>O</td>
|
||||
<td>X</td>
|
||||
<td>O</td>
|
||||
<td>X</td>
|
||||
<td>O</td>
|
||||
<td>X</td>
|
||||
<td>O</td>
|
||||
<td>X</td>
|
||||
<td>O</td>
|
||||
<td>X</td>
|
||||
<td>O</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>0</td>
|
||||
<td>1</td>
|
||||
<td>Japan, PAL</td>
|
||||
<td> </td>
|
||||
<td>X</td>
|
||||
<td>X</td>
|
||||
<td>O</td>
|
||||
<td>O</td>
|
||||
<td>X</td>
|
||||
<td>X</td>
|
||||
<td>O</td>
|
||||
<td>O</td>
|
||||
<td>X</td>
|
||||
<td>X</td>
|
||||
<td>O</td>
|
||||
<td>O</td>
|
||||
<td>X</td>
|
||||
<td>X</td>
|
||||
<td>O</td>
|
||||
<td>O</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>1</td>
|
||||
<td>0</td>
|
||||
<td>Overseas, NTSC</td>
|
||||
<td>N. America, Brazil</td>
|
||||
<td>X</td>
|
||||
<td>X</td>
|
||||
<td>X</td>
|
||||
<td>X</td>
|
||||
<td>O</td>
|
||||
<td>O</td>
|
||||
<td>O</td>
|
||||
<td>O</td>
|
||||
<td>X</td>
|
||||
<td>X</td>
|
||||
<td>X</td>
|
||||
<td>X</td>
|
||||
<td>O</td>
|
||||
<td>O</td>
|
||||
<td>O</td>
|
||||
<td>O</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>1</td>
|
||||
<td>1</td>
|
||||
<td>Overseas, PAL</td>
|
||||
<td>Europe, Hong Kong</td>
|
||||
<td>X</td>
|
||||
<td>X</td>
|
||||
<td>X</td>
|
||||
<td>X</td>
|
||||
<td>X</td>
|
||||
<td>X</td>
|
||||
<td>X</td>
|
||||
<td>X</td>
|
||||
<td>O</td>
|
||||
<td>O</td>
|
||||
<td>O</td>
|
||||
<td>O</td>
|
||||
<td>O</td>
|
||||
<td>O</td>
|
||||
<td>O</td>
|
||||
<td>O</td>
|
||||
</tr>
|
||||
</tbody></table>
|
||||
|
||||
<p>
|
||||
<a name="ver"> Common uses of the new code type are ASCII values '4' for N.America, 'A' for UK, and 'B' for UK and Japan.
|
||||
</a></p>
|
||||
|
||||
|
||||
<a name="dat">
|
||||
</a><h4><a name="dat">Data register</a></h4>
|
||||
<p>
|
||||
<a name="dat"> 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.
|
||||
</a></p><pre><a name="dat"> 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
|
||||
</a></pre>
|
||||
|
||||
<a name="dat"> 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.
|
||||
<br><br>
|
||||
If a pin is configured as an output, reading it returns the last value written to this register.
|
||||
</a><p></p>
|
||||
|
||||
<a name="dir">
|
||||
</a><h4><a name="dir">Control register</a></h4>
|
||||
<p>
|
||||
<a name="dir"> The control register determines which pins are inputs and outputs.
|
||||
|
||||
</a></p><pre><a name="dir"> 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
|
||||
</a></pre>
|
||||
|
||||
<a name="dir"> 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.
|
||||
</a><p></p>
|
||||
|
||||
<a name="scr">
|
||||
</a><h4><a name="scr">Serial control register</a></h4>
|
||||
<p>
|
||||
<a name="scr"> 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.
|
||||
|
||||
</a></p><pre><a name="scr"> 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
|
||||
</a></pre>
|
||||
|
||||
<a name="scr"> The available baud rates are:
|
||||
</a><p></p>
|
||||
|
||||
<table bgcolor="#f0f0f0" border="0" cellpadding="4">
|
||||
<tbody><tr bgcolor="#cccccc">
|
||||
<td>D7</td>
|
||||
<td>D6</td>
|
||||
<td>Baud rate</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>0</td>
|
||||
<td>0</td>
|
||||
<td>4800 bps</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>0</td>
|
||||
<td>1</td>
|
||||
<td>2400 bps</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>1</td>
|
||||
<td>0</td>
|
||||
<td>1200 bps</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>1</td>
|
||||
<td>1</td>
|
||||
<td>300 bps</td>
|
||||
</tr>
|
||||
</tbody></table>
|
||||
|
||||
<p>
|
||||
<a name="scr"> 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.
|
||||
|
||||
<br><br> 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.
|
||||
<br><br>
|
||||
Bits 2-0 are read-only status flags, the rest of the bits in this register can be read and written.
|
||||
</a></p>
|
||||
|
||||
|
||||
<a name="txd">
|
||||
</a><h4><a name="txd">TxData register</a></h4>
|
||||
<p>
|
||||
<a name="txd"> 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.
|
||||
</a></p>
|
||||
|
||||
<a name="rxd">
|
||||
</a><h4><a name="rxd">RxData register</a></h4>
|
||||
<p>
|
||||
<a name="rxd"> 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).
|
||||
</a></p>
|
||||
|
||||
<a name="ser">
|
||||
</a><h4><a name="ser">Using serial communication</a></h4>
|
||||
<p>
|
||||
<a name="ser"> 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.
|
||||
<br><br> 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.
|
||||
</a></p>
|
||||
|
||||
<a name="per">
|
||||
</a><h2><a name="per">Peripheral devices</a><hr></h2>
|
||||
|
||||
<ul>
|
||||
<li><a href="#md2">2-button Mark-III gamepad</a>
|
||||
</li><li><a href="#md3">3-button standard gamepad</a>
|
||||
</li><li><a href="#md6">Fighting Pad 6B</a>
|
||||
</li><li><a href="#gun">Lightguns (Sega Menacer, Konami Justifier)</a>
|
||||
</li><li><a href="#eat">EA 4-Way Play</a>
|
||||
</li><li><a href="#mul">Sega Team Player</a>
|
||||
</li><li><a href="#mmo">Sega Mega Mouse</a>
|
||||
</li></ul>
|
||||
|
||||
<a name="md2">
|
||||
</a><h4><a name="md2">2-button Mark-III gamepad</a></h4>
|
||||
<p>
|
||||
<a name="md2"> 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:
|
||||
|
||||
</a></p><pre><a name="md2"> 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
|
||||
</a></pre>
|
||||
|
||||
<a name="md2"> All buttons are active-low logic, so they return '0' when pressed and '1' when released.
|
||||
</a><p></p>
|
||||
|
||||
<a name="md3">
|
||||
</a><h4><a name="md3">3-button standard gamepad</a></h4>
|
||||
<p>
|
||||
<a name="md3"> 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.
|
||||
|
||||
<br><br>
|
||||
Here's a description of how the controller interfaces with an I/O port:
|
||||
|
||||
</a></p><pre><a name="md3"> 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
|
||||
</a></pre>
|
||||
|
||||
<a name="md3"> All buttons are active-low logic, so they return '0' when pressed and '1' when released.
|
||||
|
||||
<br><br> 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.
|
||||
<br><br>
|
||||
Here's some example code to read a 3-button gamepad:
|
||||
</a><p></p>
|
||||
|
||||
<table bgcolor="#e0e0e0" width="70%"><tbody><tr><td><pre>; 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
|
||||
</pre></td></tr></tbody></table>
|
||||
|
||||
<a name="md6">
|
||||
</a><h4><a name="md6">Fighting Pad 6B</a></h4>
|
||||
<p>
|
||||
<a name="md6"> Information coming soon.
|
||||
</a></p>
|
||||
|
||||
<a name="gun">
|
||||
</a><h4><a name="gun">Lightguns (Sega Menacer, Konami Justifier)</a></h4>
|
||||
<p>
|
||||
<a name="gun"> Information coming soon.
|
||||
</a></p>
|
||||
|
||||
<a name="eat">
|
||||
</a><h4><a name="eat">EA 4-Way Play</a></h4>
|
||||
<p>
|
||||
<a name="eat"> The EA 4-Way Play plugs into ports A and B, and allows up to four standard Genesis controllers to be connected at once.
|
||||
|
||||
<br><br> 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.
|
||||
<br><br> 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.
|
||||
<br><br>
|
||||
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.
|
||||
|
||||
<br><br>
|
||||
Here's some example code to use the EA 4-Way Play:
|
||||
</a></p>
|
||||
|
||||
<table bgcolor="#e0e0e0" width="70%"><tbody><tr><td><pre>; 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
|
||||
</pre></td></tr></tbody></table>
|
||||
|
||||
|
||||
<a name="mul">
|
||||
</a><h4><a name="mul">Sega Team Player</a></h4>
|
||||
<p>
|
||||
<a name="mul"> 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:
|
||||
</a></p><pre><a name="mul"> 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.
|
||||
</a></pre>
|
||||
<a name="mul"> 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.
|
||||
<br><br>
|
||||
I don't have any programming information for this device.
|
||||
</a><p></p>
|
||||
|
||||
<a name="mmo">
|
||||
</a><h4><a name="mmo">Sega Mega Mouse</a></h4>
|
||||
<p>
|
||||
<a name="mmo"> 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.
|
||||
|
||||
<br><br>
|
||||
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 <b>different</b> product with 2 buttons and unique physical appearance.
|
||||
|
||||
<br><br>
|
||||
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:
|
||||
</a></p>
|
||||
<table bgcolor="#f0f0f0" border="0" cellpadding="4">
|
||||
<tbody><tr bgcolor="#cccccc">
|
||||
<td>Write</td>
|
||||
<td>TH</td>
|
||||
<td>TR</td>
|
||||
<td>TL</td>
|
||||
<td>D3</td>
|
||||
<td>D2</td>
|
||||
<td>D1</td>
|
||||
<td>D0</td>
|
||||
<td>Description</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$60</td>
|
||||
<td bgcolor="#bbbbbb">1</td>
|
||||
<td bgcolor="#bbbbbb">1</td>
|
||||
<td>1</td>
|
||||
<td>0</td>
|
||||
<td>0</td>
|
||||
<td>0</td>
|
||||
<td>0</td>
|
||||
<td>Request data</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$20</td>
|
||||
<td bgcolor="#bbbbbb">0</td>
|
||||
<td bgcolor="#bbbbbb">1</td>
|
||||
<td>1</td>
|
||||
<td>0</td>
|
||||
<td>0</td>
|
||||
<td>0</td>
|
||||
<td>0</td>
|
||||
<td>ID #0 ($0)</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$00</td>
|
||||
<td bgcolor="#bbbbbb">0</td>
|
||||
<td bgcolor="#bbbbbb">0</td>
|
||||
<td>1</td>
|
||||
<td>1</td>
|
||||
<td>0</td>
|
||||
<td>1</td>
|
||||
<td>1</td>
|
||||
<td>ID #1 ($B)</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$20</td>
|
||||
<td bgcolor="#bbbbbb">0</td>
|
||||
<td bgcolor="#bbbbbb">1</td>
|
||||
<td>0</td>
|
||||
<td>1</td>
|
||||
<td>1</td>
|
||||
<td>1</td>
|
||||
<td>1</td>
|
||||
<td>ID #2 ($F)</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$00</td>
|
||||
<td bgcolor="#bbbbbb">0</td>
|
||||
<td bgcolor="#bbbbbb">0</td>
|
||||
<td>1</td>
|
||||
<td>1</td>
|
||||
<td>1</td>
|
||||
<td>1</td>
|
||||
<td>1</td>
|
||||
<td>ID #3 ($F)</td>
|
||||
</tr>
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$20</td>
|
||||
<td bgcolor="#bbbbbb">0</td>
|
||||
<td bgcolor="#bbbbbb">1</td>
|
||||
<td>0</td>
|
||||
<td>Y Over</td>
|
||||
<td>X Over</td>
|
||||
<td>Y Sign</td>
|
||||
<td>X Sign</td>
|
||||
<td>Axis sign and overflow</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$00</td>
|
||||
<td bgcolor="#bbbbbb">0</td>
|
||||
<td bgcolor="#bbbbbb">0</td>
|
||||
<td>1</td>
|
||||
<td>Start</td>
|
||||
<td>Middle</td>
|
||||
<td>Right</td>
|
||||
<td>Left</td>
|
||||
<td>Button state</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$20</td>
|
||||
<td bgcolor="#bbbbbb">0</td>
|
||||
<td bgcolor="#bbbbbb">1</td>
|
||||
<td>0</td>
|
||||
<td>X7</td>
|
||||
<td>X6</td>
|
||||
<td>X5</td>
|
||||
<td>X4</td>
|
||||
<td>X axis MSN</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$00</td>
|
||||
<td bgcolor="#bbbbbb">0</td>
|
||||
<td bgcolor="#bbbbbb">0</td>
|
||||
<td>1</td>
|
||||
<td>X3</td>
|
||||
<td>X2</td>
|
||||
<td>X1</td>
|
||||
<td>X0</td>
|
||||
<td>X axis LSN</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$20</td>
|
||||
<td bgcolor="#bbbbbb">0</td>
|
||||
<td bgcolor="#bbbbbb">1</td>
|
||||
<td>0</td>
|
||||
<td>Y7</td>
|
||||
<td>Y6</td>
|
||||
<td>Y5</td>
|
||||
<td>Y4</td>
|
||||
<td>Y axis MSN</td>
|
||||
</tr>
|
||||
|
||||
<tr bgcolor="#dddddd">
|
||||
<td>$00</td>
|
||||
<td bgcolor="#bbbbbb">0</td>
|
||||
<td bgcolor="#bbbbbb">0</td>
|
||||
<td>1</td>
|
||||
<td>Y3</td>
|
||||
<td>Y2</td>
|
||||
<td>Y1</td>
|
||||
<td>Y0</td>
|
||||
<td>Y axis LSN</td>
|
||||
</tr>
|
||||
</tbody></table>
|
||||
|
||||
<p>
|
||||
<a name="mmo"> 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.
|
||||
<br><br>
|
||||
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.
|
||||
|
||||
|
||||
<br><br> 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.
|
||||
<br><br>
|
||||
All buttons (start, left, middle, right) are active-high logic, so they return '1' when pressed and '0' when released.
|
||||
</a></p>
|
||||
|
||||
<a name="msc">
|
||||
</a><h4><a name="msc">Miscellaneous</a></h4>
|
||||
<p>
|
||||
<a name="msc"> After power-up, the default state of the I/O chip are as follows:
|
||||
</a></p><pre><a name="msc"> $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
|
||||
</a></pre>
|
||||
<p></p>
|
||||
|
||||
<a name="dis">
|
||||
</a><h4><a name="dis">Disclaimer</a></h4>
|
||||
<pre><a name="dis"> 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.
|
||||
</a></pre>
|
||||
|
||||
<hr>
|
||||
|
||||
</body></html>
|
@ -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.
|
||||
|
||||
<one line to give the program's name and a brief idea of what it does.>
|
||||
Copyright (C) 19yy <name of author>
|
||||
|
||||
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.
|
||||
|
||||
<signature of Ty Coon>, 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.
|
@ -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.
|
||||
|
@ -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.
|
||||
|
@ -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.
|
@ -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 <x> <y> set the display resolution.
|
||||
-vdriver <n> specify video driver.
|
||||
-depth <n> 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 <n> specify sound rate. (8000, 11025, 22050, 44100)
|
||||
-sndcard <n> specify sound card. (0-7)
|
||||
-swap swap left and right stereo output.
|
||||
-joy <s> 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)
|
||||
|
@ -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.
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
|
@ -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.
|
Loading…
Reference in New Issue
Block a user