[TheMVRules]

Something nice I must post to gain Full Membership...

The result of my TMSS Genesis OS research.

- ROM OFFSETS -


-Filler data- $000 - $0FF
$000 - $0FF 68K Vectors

-HEADER- $100 - $1FF
$100 - $103 The Sega text which TMSS normally is looking for. (But it does not check itself)
$105 - $10F 'GENESIS' text
$110 - $11F © SEGA 1990.MAY
$120 - $14F Domestic name
$150 - $17F Overseas name
$180 - $18D Serial number (OS 00000000-00)
$18E - $18F Checksum (unimportant; the bios does not check it's CS)
$1F0 - $1F2 Region (unimportant; the bios does not region check itself)

-TMSS CHECK ROUTINES- $200 - $2D6
$216 - $219 Sega text (possible part of TMSS check)
$2C7 - $2C9 First part of TMSS check
$2D2 - $2D5 Sega text (possible part of TMSS check)

-ART & PALETTES- $2D6 - $36F
$2D6 - $369 Art (Sega logo, text)
$36A - $36B Palette: BG
$36C - $36D Palette: Text
$36E - $36F Palette: Unused Sega text

-Filler data- $370 - $74F
$370 - $6CF Filler data
$6D0 - $74F Filler data

-TEXT INTERFACE AND TI CODE- $750 - $7B3
$750 - $760 Text line 1: produced by or
$762 - $774 Text line 2: under license from
$776 - $78A Text line 3: sega enterprises ltd.

-Filler data- $7B4 - $7FF
$7B4 - $7FF Filler data

-INFO-

Pallettes: Like normal MD pallettes. Edit them in a hex editor.

ASCII Text: Only use lowercase. Special Chars: FF = Linebreak. 7B = Dot. 7C 7D 7E 7F = Sega font letters.
Between Sega and Enterprises (hex adress $77A), there is an strange 2C (,). What it does
there is unknown (for me).

Tools used: Fusion, Gens Movie, Genesis OS, Knuckles' Chaotix, XVI32, Sik's Genesis OS hack.
Special Thanks to: Sik, Sega, Steve Snake and the makers of Gens Movie, the makers of XVI 32.

This post has been edited by TheMVRules: 14 April 2009 - 11:23 AM

[Sik]

TheMVRules, on Apr 14 2009, 01:04 PM, said:

-Filler data- $000 - $0FF
$000 - $0FF Filler data

Filler data WTF
Those are the 68k vectors, definitely not filler stuff =P

TheMVRules, on Apr 14 2009, 01:04 PM, said:

$2C7 - $2CA Mispelled Sega text (SEGE)

Is there a space behind that? Because it checks for both "SEGA" and " SEGA", and that E at the end most likely is part of a instruction (as it checks first " SEG" and then "A" =P).

TheMVRules, on Apr 14 2009, 01:04 PM, said:

Between Sega and Enterprises (hex adress $77A), there is an strange 2C (,). What it does there is unknown (for me).

Quote

Sega, Enterprises Ltd.

It just turns out the comma doesn't have a character in VRAM, looks like somebody forgotten that or something >_>'

EDIT: some more info:

• The cartridge load program is loaded into RAM at $FFC000. This is because of bank switching.
  
• The BIOS is required to write "SEGA" to $A14000 or the hardware locks up. Right before booting the cartridge, it writes 0 to it, probably to force the program in the cartridge to write it itself.
  
• The LSB at $A14101 bank switches between the BIOS ROM (0) and the cartridge ROM (1).

This post has been edited by Sik: 14 April 2009 - 11:25 AM

[saxman]

You have some fairly interesting things there. There's definitely room for expansion.

This post has been edited by saxman: 14 April 2009 - 11:42 AM

[TmEE]

I must note that I have done total reverse engineering on TMSS, and even released it here... somewhere... comment on nearly every line, bit perfect binary gets assembled with SNASM68K...

EDIT: here's the stuff : http://forums.sonicr...showtopic=12558

This post has been edited by TmEE: 14 April 2009 - 01:18 PM

[GerbilSoft]

Just to clear a few things up:
- "Genesis OS" is a misnomer, since the TMSS ROM is completely removed from the address bus after system startup.
- I need to implement proper TMSS ROM support in Gens/GS sometime. :P (including the !CartCE register, $A14101 bit 0)

[AamirM]

Quote

- I need to implement proper TMSS ROM support in Gens/GS sometime. :P (including the !CartCE register, $A14101 bit 0)

I have implemented that but I never got around to enabling it and using it through the GUI (cause Win32 coding sucks).

[Sik]

GerbilSoft, on Apr 14 2009, 03:30 PM, said:

- "Genesis OS" is a misnomer, since the TMSS ROM is completely removed from the address bus after system startup.

Before any discussion arises (I don't want to start the BIOS vs. firmware discussion again >_>), I think Sega called it merely as the "start up program" in the official docs. Pretty sure it did so for the Master System and I think it also did for the Mega Drive.

[TmEE]

well, it is useless piece of code and dangerous as it inititalizes lot of stuff for you and things might not work on machines without TMSS.... all emulators SHOULD fill all RAMs with garbage on ROM startup to simulate real HW behaviour...
and I have TMSS disabled on all my machines anyway... I want my games run now not after 5 seconds

[saxman]

GerbilSoft, on Apr 14 2009, 02:30 PM, said:

- "Genesis OS" is a misnomer, since the TMSS ROM is completely removed from the address bus after system startup.

I started to say that, but then I edited my post afterwards. It's a technicality. It could "technically" be considered an OS. Heck, the games could be consider OS's. Not in the traditional sense of course. But it's all really how you look at it.

[Chilly Willy]

If you wish to use save ram, you need to use a slightly modified header. From my own project:

| Standard MegaDrive ROM header at 0x100

		.ascii  "SEGA GENESIS	"
		.ascii  "(C)SEGA 2009.MAR"
		.ascii  "Wolfenstein 3D S"
		.ascii  "hareware 32X	"
		.ascii  "				"
		.ascii  "Wolfenstein 3D S"
		.ascii  "hareware 32X	"
		.ascii  "				"
		.ascii  "GM MK-0000 -00"
		.word   0x0000
		.ascii  "J6			  "
		.long   0x00000000,0x003FFFFF   /* ROM start, end */
		.long   0x00FF0000,0x00FFFFFF   /* RAM start, end */
		.ascii  "RA"					/* External RAM */
		.byte   0xF8					/* don't clear + odd bytes */
		.byte   0x20					/* SRAM */
		.long   0x00200001,0x0020FFFF   /* SRAM start, end */
		.ascii  "	"
		.ascii  "				"
		.ascii  "				"
		.ascii  "				"
		.ascii  "JUE			 "

Notice the "RA" and the two bytes following. There is a different code than 0xF8 for even bytes, or both bytes, but even bytes don't work for some reason. Only odds bytes work, and that's all you'll find with carts that have sram in them. Although the sram can technically be anywhere with the start and end address specified as shown, most emulators won't work unless it's at 0x200000. The flash cart I use also only works with the sram at 0x200000.

[Sik]

Even bytes in SRAM don't work merely because of the hardware set up used =P

[Chilly Willy]

Sik, on Apr 15 2009, 06:39 AM, said:

Even bytes in SRAM don't work merely because of the hardware set up used =P

Yes, SRAM is usually a single byte-wide RAM chip. Since the data bus is 16 bits, you can put it on the upper or lower byte lane. However, you never find anyone using the even bytes, only the odd bytes. The flash cart I use (the MD-Pro 64) claims to have 256 KB of SRAM as four banks of 64 KB with both even and odds bytes available so that any cart can be emulated, regardless of even or odd byte usage. However, trying to use the even bytes on the cart fails. Only odd bytes can be used. So either the hardware specs provided to ucon64 are wrong, or there is something in the Genesis that prevents SRAM from working on the even bytes.

[Sik]

The cartridges are given the USB and LSB lines which are used to do byte access by the 68000, so definitely it should be possible to do proper byte access in the cartridge area. And using odd bytes seems to be common practice merely: even in the MD itself it's done. See: all ports between $A10001 and $A10013, and $C00011. They're all byte access. They're all in odd addresses.

[Chilly Willy]

I'm talking about the sram on the MD-Pro. If you look at the code in ucon64 (derived from code given to the author from the maker of the MD-Pro), the code to write the sram is this:

void
write_ram_by_byte (int *addr, unsigned char *buf)
{
  int x, I = *addr & 0x3fff;

  for (x = 0; x < 0x4000; x++, I = (I + 1) & 0x3fff)
	{
	  ttt_write_byte_ram (*addr, buf[I]);
	  (*addr)++;
	  // Send the same byte again => SRAM files needn't store redundant data
	  ttt_write_byte_ram (*addr, buf[I]);
	  (*addr)++;
	}
}

Note that it writes the same byte to both the odd and even addresses. The idea is that the MD-Pro has SRAM at both odd and even addresses, and writing the same byte to both means that regardless of whether a game used odd or even addresses, the MD-Pro works with either. However, in doing my own game on the cart, if you actually try to use the even bytes, the sram on the MD-Pro is not actually written. Only the odd bytes work. So there is perhaps a bug in the MD-Pro, or perhaps they MEANT to give both bytes but ended up not doing so due to cost reasons or something else.

[Sik]

Maybe there's a setting you can change?