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