Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Issues to dump some Game Gear games

Reply to topic
Author Message
  • Joined: 02 Aug 2022
  • Posts: 3
Reply with quote
Issues to dump some Game Gear games
Post Posted: Wed Aug 03, 2022 8:53 pm
Hi folks,

I'm opening this thread to get a little help, or tips, about an issue I'm facing to. We are trying to improve the Open Source Cartridge Reader project with Game Gear dumping. As a new user I can't post the github url here, but you'll find it easily. Source code handling SMS/GG/SG1000 dumping is contained into "SMS.ino" file.

I would say that around 95% of the GG games tested so far can be dumped just fine. The results match the current known roms, with strictly the same crc32, all good.

Exept a few titles. Of course all Codemasters games wich are using their own mappers, but let's keep them for later.
I'm more interested by other carts, which were manufactured by sega, and seem to react differently. Among them : Wimbledon, Super Monaco GP, G-LOC, Popils, Super Off Road (all were european cartridges, but maybe other regions are doing the same.)

Normal behavior
Use the slot 2 (0xFFFF) to address 16kb of rom data, read that slot, write binaries to file, bank after bank, up to the full rom size.
Exept for 32kb games wich don't use mappers.

The current behavior, with the titles listed previously
Slots 0-1-2 don't seem to be usable the same way to address rom banks.
The first 32kb of data (bank 0 and 1) can be read, without mapping slot 2, by looking at 0xFFFD and 0xFFFE.
But using slot 2 to address banks doesn't seem to work as for other titles.
Whatever bank is pushed to 0xFFFF, once read, that slot will only contain the very last bank.
For exemple, for a 128kb rom, the 7th bank is always the one readable at slot 2. Even if you try to map another bank to slot 2.

Few more random info :
Popils got embedded sram onto its PCB. All other titles don't, and don't seem to have a any other special chip neither.
I tested different copies of "G-LOC", to confirm that's not related to a faulty cart. But no, they are all acting same.

If someone is able to figure out what is happening here... any help would be welcome.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Thu Aug 04, 2022 9:24 am
The paging registers at 0xfffd-f are write only. Games take advantage of mirroring of RAM to read them back. Any logic you have to read them back is faulty.

As far as I know, the Sega mappers will all happily map any bank to slot 2. Availability of slots 0 and 1 is less guaranteed. However, it’s possible there may be implementations that don’t support mapping the first two banks there as games would likely never do that - but it would be extra complexity for the mapper so easier to not restrict.

You will need to implement ROM size detection as the header does not give a reliable size. There are two things you need to do: one is to find at what ROM size you start to see mirrored data, and one is to truncate oversized ROMs. Some 256KB games were shipped as 512KB with zero padding.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 596
  • Location: London, UK
Reply with quote
Post Posted: Thu Aug 04, 2022 10:27 am
Seems reasonable to assume that some mappers wouldn't support switching to all slots, especially on GG carts where logic is relatively more expensive to provide, although perhaps others have done much more extensive auditing of GG mappers.

Pragmatically, can you not just use slot 1 to page the data instead of slot 2 for those games?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Thu Aug 04, 2022 11:36 am
Practically, Sega mappers support either slot 2 only, or slots 1 and 2 only, or slots 0-3. Support for RAM could be orthogonal to these. However the capabilities of a mapper embedded with the ROM can be impossible to test except using hardware to drive the cartridge, since you can’t change the game code.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Aug 04, 2022 12:16 pm
I would assume nothing beforehand and first of all write to all 4 mappers registers $FFFC-$FFFF so that they map bank 0 in slot 0, bank 1 in slot 1 and bank 2 in slot 2 (and disable RAM, etc...)
then I would dump 48 KB straight from $0000 to $BFFF
then you enter a cycle where you set bank 3 to MAX (could even be 255 if you want but likely you don't need this...) to slot 2 and read 16 KB from $8000, repeat until every bank has been read.
than you have a dump that's either filled with trailing zeros/$FF or/and mirrored data, but that just needs some trimming to get to a perfect dump
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Thu Aug 04, 2022 1:08 pm
I don't think OP problem has anything to do with mapping at a high-level (register address) but maybe try to initialize $FFFC as well.

Or maybe the write signals send by your dumper on each pin doesn't conform precisely what the board and chip expects.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3762
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Aug 04, 2022 7:56 pm
what I meant to say that it's easier to do not assume that there's this or that specific version of SEGA mapper, or even to assume that it is present or not for each individual game - I was suggesting a single simple way to dump any cartridge that either had any kind of SEGA mapper or no mapper at all, and look at the dumped data later to infer ROM size.

For other mappers, I'm not going to give instructions as I don't know enough.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Aug 2000
  • Posts: 740
  • Location: Adelaide, Australia
Reply with quote
Issues to dump some Game Gear games
Post Posted: Fri Aug 05, 2022 8:36 am
You really should be initializing the mapper by writing $00,$00,$01,$02 to $FFFC-$FFFF. This is safe to do for carts with and without mappers.

The way you apply power to the cart and slot lines also matters. You haven’t gone into that detail but I assume you’re being concise in your post and that it’s not an afterthought… :)

The dumper hardware and design, which you haven’t gone into detail of either, is significant. You could just be seeing timing issues as said above.

Hope that helps,
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 596
  • Location: London, UK
Reply with quote
Post Posted: Fri Aug 05, 2022 9:43 am
PsyKo wrote
As a new user I can't post the github url here

Out of interest, how many posts do you need to make to be able to post links?

Was just taking a gander in an idle moment, here for convenience (pertinent starting points permalinked):

https://github.com/sanni/cartreader/blob/master/Cart_Reader/SMS.ino#L214

https://github.com/sanni/cartreader/blob/master/Cart_Reader/SMS.ino#L355
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Fri Aug 05, 2022 10:49 am
The second line above is using the cart header to get the ROM size; but this is unreliable on systems that don’t do checksums (Game Gear, Japanese SMS, SG-1000) and sometimes deliberately checksums only part of the ROM.

The rules on how to be allowed to post links are deliberately opaque so spammers don’t know how to bypass them.
  View user's profile Send private message Visit poster's website
  • Joined: 02 Aug 2022
  • Posts: 3
Reply with quote
Post Posted: Sat Aug 06, 2022 4:59 pm
Hi everybody, and thanks to all of you for the first feedbacks.
I'll try to answer the best i can to each.

@maxim
for these problematic cartridges, I also tried to map banks to slot 0 and 1, but it was more a desperate test and it didn't worked better.
As you said and as I read somewhere else, sega mappers "would" normally map any bank to slot 2 so I mainly focused on that.
About the sourcecode which is online at the moment on github, in fact it's clearly not accurate, and the correct romsize can't be guessed by trusting the header. Not for every game at least. I used this source as base, but developed my own. The process you describe is exactly the one I'm trying to reproduce here. Dumping blindly a large amount of data (512k or 1M should be enough) and truncate mirrored ones.

@sverx and @asynchronous
that's in fact what is done in the setup_SMS() function. For every cart.
writeByte_SMS(0xFFFC, 0);
writeByte_SMS(0xFFFD, 0);
writeByte_SMS(0xFFFE, 1);
writeByte_SMS(0xFFFF, 2);
Dumping the first 32KB (data from bank 0 and 1) is working fine. For every games tested so far. But the next 16KB is not. Not for the cartridges I listed in initial post. For all other games yeah it's working fine, and bank 2 is readable at 0x8000. But not for these little lot of cartridges. 0x8000 is actually giving me the very last bank data. Whatever I try to write to register 0xFFFF

@Bock
Could be. But if $FFFC would be incorrectly initialized, should I still be able to read 0x0000 to 0x7FFF ?
About timers, I also tried to add and remove some delay and "nop" at various points in code but no better results. These problematic cartridges are not looking so different from all others I already dumped with success. Same PCB model, probably similar chips, all manufactured by sega, so I assume if my timers and voltages worked for the large majority of GG carts, why not on these ones ? :(

@asynchronous
It probably won't help you much, but my dumper is the OSCR hardware v3 (if you want to have a look at their wiki for more precise info) and I'm using 5V for GG carts.

@willbritton
thanks for posting the links.
data read/write is starting at SMS.ino#L592
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 596
  • Location: London, UK
Reply with quote
Post Posted: Sat Aug 06, 2022 9:52 pm
Quote
0x8000 is actually giving me the very last bank data.


Out of interest, how do you know it's the last bank of data you're getting?

You mentioned a 128KB cart before, is it only 128KB carts that you see this problem for? If not, what other cart sizes do you see this behaviour for?

Just a thought looking at the code - seems like ~CE (I'm assuming what is pin 13 on the SMS cart) is being asserted just before the data is written to set the slot 2 mapping inside writeByte_SMS, and deasserted afterwards, but I wonder if this is different from what the GG would actually do. Would it not have ~CE (pin 24 of the GG cart) continuously asserted so long as the unit is powered up, rather than cycling it around every write to what is essentially system RAM at $ffff?
  View user's profile Send private message Visit poster's website
  • Joined: 02 Aug 2022
  • Posts: 3
Reply with quote
Post Posted: Sat Aug 06, 2022 11:29 pm
I hex compared my dump results side to side with the current public roms. That's how I confirmed that there was no problem for the first two banks, and then that every following 16KB block I read is always the last bank (last 16kb of the public rom).

In fact, all the annoying ones seem to be 128KB : Wimbledon, G-LOC, Super Monaco GP, Super Off Road, Popils.
I had no problem to correctly dump a lot of other 128KB games, only these ones are acting differently.

For your last point, I let the community experts confirm how it should be to best mimic the console behavior for GG carts.

I think you figured out already, but just to be sure that people are reading the correct lines (designed for GG, and not other systems) conditions must be "retrode_mode = true" and "retrode_mode_sms = false".
  View user's profile Send private message
  • Joined: 04 Jul 2010
  • Posts: 539
  • Location: Angers, France
Reply with quote
Post Posted: Sun Aug 07, 2022 6:18 am
I've also made a reader (and writer) years ago, which i'm always using nowadays (but nearly only for writing, supporting various flash manufacturers)

Take your time checking precisely what pins are used on various PCB ;)
(to be short you'll need A0-A15, /CE, /OE(known as /RD), /M07 and /WR, to write into registers and read)

Sega are fairly easy to dump, more exotic pcb (like Codemasters, 4-1 ozisoft) are a little bit more tricky. They use some other pins (/CLK, /MREQ (also needed for Mark III)...)

As many have already said, never trust headers (only use them for checksum purpose)

You don't need to pre init all slots/registers, just init them when you're going into their address range (0-3FFF for SLOT1, 4000-7FFF for SLOT1, 8000-BFFF for SLOT2, then update only SLOT2 reg)
You can also read/dump directly 0-7FFF and only init/change SLOT 2

Init/use FFFC only if you need to dump/write SRAM content (more or less never as only few games use this)

Sega GG carts act exactly as Master System does (i don't have exotic GG carts, so can't say for them)

Good luck !

PS. i've used a cheap "2$ bluepill" STM32 (and 2x 74xx273)
  View user's profile Send private message
Reply to topic



Back to the top of this page

Back to SMS Power!