Genesis OS Hacking Guide

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

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

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

 

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

 

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.sonicretro.org/index.php?showtopic=12558

 

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

 

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.

 

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

 

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.

 

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

Code (Text):

1. | Standard MegaDrive ROM header at 0x100
2.  
3.         .ascii  "SEGA GENESIS   "
4.         .ascii  "(C)SEGA 2009.MAR"
5.         .ascii  "Wolfenstein 3D S"
6.         .ascii  "hareware 32X   "
7.         .ascii  "               "
8.         .ascii  "Wolfenstein 3D S"
9.         .ascii  "hareware 32X   "
10.         .ascii  "               "
11.         .ascii  "GM MK-0000 -00"
12.         .word   0x0000
13.         .ascii  "J6           "
14.         .long   0x00000000,0x003FFFFF   /* ROM start, end */
15.         .long   0x00FF0000,0x00FFFFFF   /* RAM start, end */
16.         .ascii  "RA"                    /* External RAM */
17.         .byte   0xF8                    /* don't clear + odd bytes */
18.         .byte   0x20                    /* SRAM */
19.         .long   0x00200001,0x0020FFFF   /* SRAM start, end */
20.         .ascii  "   "
21.         .ascii  "               "
22.         .ascii  "               "
23.         .ascii  "               "
24.         .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.

 

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.

 

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.

 

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:

Code (Text):

1. void
2. write_ram_by_byte (int *addr, unsigned char *buf)
3. {
4.   int x, I = *addr & 0x3fff;
5.  
6.   for (x = 0; x < 0x4000; x++, I = (I + 1) & 0x3fff)
7.     {
8.       ttt_write_byte_ram (*addr, buf[I]);
9.       (*addr)++;
10.       // Send the same byte again => SRAM files needn't store redundant data
11.       ttt_write_byte_ram (*addr, buf[I]);
12.       (*addr)++;
13.     }
14. }

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.

 

Maybe there's a setting you can change?

 

What is written on the SRAM chip in MD Pro (only definitive way to make sure if its 8 or 16bit) ?

 

@Sik: Not that I've noticed looking through the ucon64 code or my disassembly of the multi-loader code. I did find where to change the SRAM bank, and how to set the flash bank.

@TmEE: I haven't tried printing out the data. I relied on the checksums in the load/save game code in Wolf32X. Saving then loading from even bytes fails the checksum (and the data is flat wrong if you ignore the checksum failing), while saving then loading from odd bytes passes.

 

I meant what's physically written on the chip (I.e x62x256)...

 

Should have thought of that myself.

XILINK XC95144XL - I think we all know what that is.
Intel E28F640 - 3V StrataFlash 64 Mbit Flash ROM
Hitachi HM628128AL - 1 Mbit SRAM, 128K x 8

It's only an 8 bit chip, so it makes sense now that it only works on one byte lane. Also, it's 128 KB, so four banks of 32 KB is to be expected. Seems to me they need to change the spec list for the product.