Forums

I own or have dumped a total of 9 of those, all different.

There 1 mapper register at 0xFFFF
The register maps 32 KB of ROM to 0x0000-0x7FFF
Writing value N to (0xFFFF) maps ROM N*0x8000..N*0x8000+0x7FFF.

In my test 0x8000-0xBFFF always read as ROM 0x0000-0x3FFF but I haven't verified on all cartridges (and only have access to 5 now).

I have now added support in MEKA. May release them as soon as later today. Would be nice if other emulators caught up.

I'll publish the other CRC as soon as I have them. I am not sure how to name those dumps so may give them an arbitrary ordered identifier "Hi-Com 3-in-1 Best Game Collection A" "Hi-Com 3-in-1 Best Game Collection B". etc.

The 8-in-1 variation are squeezing the menu in whatever game doesn't use 32 KB and jump to the non-zero address for some games. Interestingly, the code check for the presence of 8 banks, if only 4 banks are present the menu display 4 games, if 8 banks are present the menu code display 8 games.

Hi Bock,

thanks for sharing!
Emulicious is ready as well. :)
Do you want me to wait for the release or should I just silently provide the update and you will then mention it in your release post when its time? :)

You can release your emulator, doesn't have to be a silent release :)

Here's the list of CRC and how I have named them.

SMS 98af0236 Hi-Com 3-in-1 The Best Game Collection A (KR)
SMS 6ebfe1c3 Hi-Com 3-in-1 The Best Game Collection B (KR)
SMS 81a36a4f Hi-Com 3-in-1 The Best Game Collection C (KR)
SMS 8d2d695d Hi-Com 3-in-1 The Best Game Collection D (KR)
SMS 82c09b57 Hi-Com 3-in-1 The Best Game Collection E (KR)
SMS 4088eeb4 Hi-Com 3-in-1 The Best Game Collection F (KR)
SMS fba94148 Hi-Com 8-in-1 The Best Game Collection A (KR)
SMS 8333c86e Hi-Com 8-in-1 The Best Game Collection B (KR)
SMS 00e9809f Hi-Com 8-in-1 The Best Game Collection C (KR)

The files are ready. I am unsure how to put them on the site, considering making an exception and creating 1 page for all games.

The "A/B/C/D/E" labelling is arbitrary. The boxes appears to what was intended as unique product number but boxes are typically mixed up and patched with stickers added to change game titles (on both boxes and cartridges) making the product number rather unreliable AND realistically we may never find out the correct numbers. So I had to enforce arbitrary naming.

Roms are released here
http://www.smspower.org/forums/viewtopic.php?t=15157

Bock wrote

The 8-in-1 variation are squeezing the menu in whatever game doesn't use 32 KB and jump to the non-zero address for some games. Interestingly, the code check for the presence of 8 banks, if only 4 banks are present the menu display 4 games, if 8 banks are present the menu code display 8 games.

Interesting. Just out of curiosity, how does it go about checking the number of banks? Does the mapper have a way to tell the ROM how it's configured, or is it just a value stored in the ROM that can be changed?

I guess it checks if the data at 128KB is the same as at 256KB.

What Maxim said.

OK, so, here's my confusion (maybe it's simple though):

This is how I'd imagine such a check:
- Write X into 0xFFFF
- Copy N bytes into system RAM
- Write X+4 into 0xFFF
- Compare N bytes with what I copied into system RAM
- Continue executing menu...

I guess my question is, where does the menu code reside while it's mapping stuff into 0x0000-0x7FFF space, given...

Bock wrote

In my test 0x8000-0xBFFF always read as ROM 0x0000-0x3FFF but I haven't verified on all cartridges (and only have access to 5 now).

Does it copy some operations into RAM and then jump to that?

Yes, code in RAM is the only way to do that, similar to how the BIOS works.

OK, makes sense. I was just curious how these multicarts work their magic. ;)

ishiyakazuo wrote

OK, so, here's my confusion (maybe it's simple though):

This is how I'd imagine such a check:
- Write X into 0xFFFF
- Copy N bytes into system RAM
- Write X+4 into 0xFFF
- Compare N bytes with what I copied into system RAM
- Continue executing menu...

I guess my question is, where does the menu code reside while it's mapping stuff into 0x0000-0x7FFF space, given...

Bock wrote

In my test 0x8000-0xBFFF always read as ROM 0x0000-0x3FFF but I haven't verified on all cartridges (and only have access to 5 now).

Does it copy some operations into RAM and then jump to that?

Yes, it does the following:
- Copy short piece of code into RAM
- Call it
Now the copied code follows:
- Set bank to 4
- Check if ($0000) is $c3 and if ($3fff) is 3 (these are the values you will find in bank 0 at the given locations)
- If that's not the case expect more than 4 banks
- Otherwise set bank back to 0
- Continue with menu

Edit: Oh Maxim was faster to reply ^^

Ah, but this is interesting info too, and makes a lot of sense! I was thinking "it'd have to copy two chunks of memory from somewhere in the ROM and verify that all bytes differ, but where would it do that from?" But if it's comparing to menu code, then maybe that makes sense.
"Otherwise set bank back to 0 " doesn't make a lot of sense to me though -- shouldn't it always set bank back to 0? Or does the menu code also reside in bank 4?

You can try to step into it with the MEKA or Emulicious debugger, or use breakpoints to see the write to (FFFF) as well.

ishiyakazuo wrote

Ah, but this is interesting info too, and makes a lot of sense! I was thinking "it'd have to copy two chunks of memory from somewhere in the ROM and verify that all bytes differ, but where would it do that from?" But if it's comparing to menu code, then maybe that makes sense.
"Otherwise set bank back to 0 " doesn't make a lot of sense to me though -- shouldn't it always set bank back to 0? Or does the menu code also reside in bank 4?

It executes some code in bank 4 that also loads some code into RAM which it then executes as well. This code sets bank back to 0 and continues with menu.

Interesting. So the menu code is split (or duplicated?) between banks 0 and 4? I wonder if banks 4-7 are split out into their own ROM, if they'll execute as a 4-in-1 cart as well. (Maybe they actually have two ROMs on the PCB for the 8-in-1, and can choose to just populate a single one, and either one works?)

ishiyakazuo wrote

Interesting. So the menu code is split (or duplicated?) between banks 0 and 4?

No, the code in bank 4 only does the following:
- load some values from ROM into RAM
- load code that doesn't do anything else than setting bank back to 0 and jumping back to menu code
- execute the code that has just been loaded into RAM
(I didn't expect you to want to know it in so much detail :P)

Isn't that what a dev forum is for? Document ALL THE THINGS. ;)

Here's pictures of the board.

hi-com 8-in-1 board front.JPG (588.41 KB)

hi-com 8-in-1 board back.JPG (751.16 KB)

ishiyakazuo wrote

Isn't that what a dev forum is for? Document ALL THE THINGS. ;)

Sure, but if you want to know

Quote

ALL THE THINGS

you might want to follow Bock's advice and try stepping through the code. Because I might have missed something out :)

Edit: After seeing Bock's pics you could have also asked Bock for pics in your case :D

The menus are duplicated. BOTH halves can function as standalone roms. Try cutting them in half and see. They can each display a 4-in-1 menu.

If I wasn't in the office, I would definitely do some looking into those things ;) But people might look at me funny loading and playing with SMS ROMs at work.
Plus, if someone's already done the work to reverse engineer the code to make it work in emulators, why not ask the questions to get the info out there? Reinventing the wheel just because you can doesn't seem all that sensible to me.

ishiyakazuo wrote

But people might look at me funny loading and playing with SMS ROMs at work.

Actually they always seem a lot interested ;)

To be fair, I've never tried it, so I'm only speculating at the response I'll get...

ishiyakazuo wrote

Reinventing the wheel just because you can doesn't seem all that sensible to me.

Agreed... information needs to be shared.

ishiyakazuo wrote

If I wasn't in the office, I would definitely do some looking into those things ;) But people might look at me funny loading and playing with SMS ROMs at work.
Plus, if someone's already done the work to reverse engineer the code to make it work in emulators, why not ask the questions to get the info out there? Reinventing the wheel just because you can doesn't seem all that sensible to me.

Doesn't the debugger look technical enough to please your co-workers? :)

I didn't have anything reverse engineered. I just took a quick look to answer your questions. Then you asked more detailed questions so I took another, this time closer, look. All I knew before was that bank is being set to 0 then to 4 then back to 0 and that before I emulated the mapper I only saw 4 games, when I emulated I saw 8 games.
So everything I know about it is contained in this topic already. :)

I appreciate your detective work on my behalf then :)
I just figured that to have it emulated, it probably needed some initial detective work, so asking the questions was the most straightforward route. I didn't really expect anyone to look into it for me. Sorry if that was unclear.

As pointed by concept92 (in an e-mail), the ROM chips are saying

9003H
S0019
9017

and

9003H
S0011
9016

Would be worth comparing to the other cartridges see if we can draw patterns and references. 9016/9017 probably stands for the standard "16/17th week of 1990"

is it possible (and simple) to extract (and patch if needed) all the games individually from these cartridge roms? i only extracted Monkey Academy and Exerion from a bash script like this: http://pastebin.com/d8aGECqh

nitrofurano wrote

is it possible (and simple) to extract (and patch if needed) all the games individually from these cartridge roms? i only extracted Monkey Academy and Exerion from a bash script like this: http://pastebin.com/d8aGECqh

(Reviving this ancient thread since I've been looking into patching some of the entries to work on the Game Gear.)

It is possible, but not entirely easy in some cases — games typically have the first three bytes overwritten with a jump. Extraction with dd in 32KB blocks works pretty well. In many cases overwriting the first three or four bytes with NUL (0x00) bytes results in a working game.

Games originally developed for MSX typically have a modified MSX BIOS for use on SMS prefixed to the game, and that BIOS has its first three bytes overwritten (in most cases it also has a menu patched into some unused space inside the BIOS area.)

There are several MSX games in the 8-in-1 collections, all of which appear to be Hi-Com modifications of Konami originals: Athletic Land, Circus Charlie, Hyper Sports 2, King's Valley 1, Magical Tree, Monkey Academy, and Yie Ar Kung-Fu 1. Visible references to Konami have been removed or replaced by Hi-Com, but the string KONAMI remains in some places.

The rest of the games in the 8-in-1 collections appear to mostly be SG-1000 and SMS My Card/Sega Card releases (unsurprising, given the size constraints of the mapper) and many of them are unmodified other than the first three bytes. The following entries are modified, however: Astro Flash, Exerion, Hyper Sports 1, Safari Race, and Star Force.

Due to the smaller 16KB ROM being duplicated prior to the overwriting of the first bytes with a jump instruction, there is also an unmodified copy of the 16KB version of Sega Galaga inside Hi-Com 8-in-1 The Best Game Collection B (KR).sms

edit: also the Exerion in Hi-Com 8-in-1 The Best Game Collection C (KR).sms appears to only have the first 16KB, duplicated (but with the first three bytes overwritten in the first copy, thanks to the menu jump)

Author	Message
Bock Site Admin Joined: 08 Jul 2001 Posts: 8648 Location: Paris, France	Korean Hi-Com 3 in 1 / 8 in 1 cartridges Posted: Sun Dec 14, 2014 3:09 pm Last edited by Bock on Mon Dec 15, 2014 10:07 pm; edited 2 times in total
	I own or have dumped a total of 9 of those, all different. There 1 mapper register at 0xFFFF The register maps 32 KB of ROM to 0x0000-0x7FFF Writing value N to (0xFFFF) maps ROM N0x8000..N0x8000+0x7FFF. In my test 0x8000-0xBFFF always read as ROM 0x0000-0x3FFF but I haven't verified on all cartridges (and only have access to 5 now). I have now added support in MEKA. May release them as soon as later today. Would be nice if other emulators caught up. I'll publish the other CRC as soon as I have them. I am not sure how to name those dumps so may give them an arbitrary ordered identifier "Hi-Com 3-in-1 Best Game Collection A" "Hi-Com 3-in-1 Best Game Collection B". etc. The 8-in-1 variation are squeezing the menu in whatever game doesn't use 32 KB and jump to the non-zero address for some games. Interestingly, the code check for the presence of 8 banks, if only 4 banks are present the menu display 4 games, if 8 banks are present the menu code display 8 games.

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Sun Dec 14, 2014 5:09 pm
Calindro Joined: 14 Apr 2013 Posts: 624	Hi Bock, thanks for sharing! Emulicious is ready as well. :) Do you want me to wait for the release or should I just silently provide the update and you will then mention it in your release post when its time? :)

Bock Site Admin Joined: 08 Jul 2001 Posts: 8648 Location: Paris, France	Posted: Sun Dec 14, 2014 5:15 pm
	You can release your emulator, doesn't have to be a silent release :) Here's the list of CRC and how I have named them. SMS 98af0236 Hi-Com 3-in-1 The Best Game Collection A (KR) SMS 6ebfe1c3 Hi-Com 3-in-1 The Best Game Collection B (KR) SMS 81a36a4f Hi-Com 3-in-1 The Best Game Collection C (KR) SMS 8d2d695d Hi-Com 3-in-1 The Best Game Collection D (KR) SMS 82c09b57 Hi-Com 3-in-1 The Best Game Collection E (KR) SMS 4088eeb4 Hi-Com 3-in-1 The Best Game Collection F (KR) SMS fba94148 Hi-Com 8-in-1 The Best Game Collection A (KR) SMS 8333c86e Hi-Com 8-in-1 The Best Game Collection B (KR) SMS 00e9809f Hi-Com 8-in-1 The Best Game Collection C (KR)

Bock Site Admin Joined: 08 Jul 2001 Posts: 8648 Location: Paris, France	Posted: Sun Dec 14, 2014 5:20 pm
	The files are ready. I am unsure how to put them on the site, considering making an exception and creating 1 page for all games. The "A/B/C/D/E" labelling is arbitrary. The boxes appears to what was intended as unique product number but boxes are typically mixed up and patched with stickers added to change game titles (on both boxes and cartridges) making the product number rather unreliable AND realistically we may never find out the correct numbers. So I had to enforce arbitrary naming.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8648 Location: Paris, France	Posted: Mon Dec 15, 2014 10:07 pm
	Roms are released here http://www.smspower.org/forums/viewtopic.php?t=15157

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Tue Dec 16, 2014 2:08 am
	Bock wrote The 8-in-1 variation are squeezing the menu in whatever game doesn't use 32 KB and jump to the non-zero address for some games. Interestingly, the code check for the presence of 8 banks, if only 4 banks are present the menu display 4 games, if 8 banks are present the menu code display 8 games. Interesting. Just out of curiosity, how does it go about checking the number of banks? Does the mapper have a way to tell the ROM how it's configured, or is it just a value stored in the ROM that can be changed?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14726 Location: London	Posted: Tue Dec 16, 2014 8:43 am
	I guess it checks if the data at 128KB is the same as at 256KB.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8648 Location: Paris, France	Posted: Tue Dec 16, 2014 10:26 am
	What Maxim said.

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Tue Dec 16, 2014 12:29 pm
	OK, so, here's my confusion (maybe it's simple though): This is how I'd imagine such a check: - Write X into 0xFFFF - Copy N bytes into system RAM - Write X+4 into 0xFFF - Compare N bytes with what I copied into system RAM - Continue executing menu... I guess my question is, where does the menu code reside while it's mapping stuff into 0x0000-0x7FFF space, given... Bock wrote In my test 0x8000-0xBFFF always read as ROM 0x0000-0x3FFF but I haven't verified on all cartridges (and only have access to 5 now). Does it copy some operations into RAM and then jump to that?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14726 Location: London	Posted: Tue Dec 16, 2014 12:42 pm
	Yes, code in RAM is the only way to do that, similar to how the BIOS works.

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Tue Dec 16, 2014 12:44 pm
	OK, makes sense. I was just curious how these multicarts work their magic. ;)

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Tue Dec 16, 2014 12:49 pm Last edited by Calindro on Tue Dec 16, 2014 2:42 pm; edited 2 times in total
Calindro Joined: 14 Apr 2013 Posts: 624	ishiyakazuo wrote OK, so, here's my confusion (maybe it's simple though): This is how I'd imagine such a check: - Write X into 0xFFFF - Copy N bytes into system RAM - Write X+4 into 0xFFF - Compare N bytes with what I copied into system RAM - Continue executing menu... I guess my question is, where does the menu code reside while it's mapping stuff into 0x0000-0x7FFF space, given... Bock wrote In my test 0x8000-0xBFFF always read as ROM 0x0000-0x3FFF but I haven't verified on all cartridges (and only have access to 5 now). Does it copy some operations into RAM and then jump to that? Yes, it does the following: - Copy short piece of code into RAM - Call it Now the copied code follows: - Set bank to 4 - Check if ($0000) is $c3 and if ($3fff) is 3 (these are the values you will find in bank 0 at the given locations) - If that's not the case expect more than 4 banks - Otherwise set bank back to 0 - Continue with menu Edit: Oh Maxim was faster to reply ^^

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Tue Dec 16, 2014 12:56 pm
	Ah, but this is interesting info too, and makes a lot of sense! I was thinking "it'd have to copy two chunks of memory from somewhere in the ROM and verify that all bytes differ, but where would it do that from?" But if it's comparing to menu code, then maybe that makes sense. "Otherwise set bank back to 0 " doesn't make a lot of sense to me though -- shouldn't it always set bank back to 0? Or does the menu code also reside in bank 4?

Bock Site Admin Joined: 08 Jul 2001 Posts: 8648 Location: Paris, France	Posted: Tue Dec 16, 2014 1:27 pm
	You can try to step into it with the MEKA or Emulicious debugger, or use breakpoints to see the write to (FFFF) as well.

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Tue Dec 16, 2014 2:48 pm
Calindro Joined: 14 Apr 2013 Posts: 624	ishiyakazuo wrote Ah, but this is interesting info too, and makes a lot of sense! I was thinking "it'd have to copy two chunks of memory from somewhere in the ROM and verify that all bytes differ, but where would it do that from?" But if it's comparing to menu code, then maybe that makes sense. "Otherwise set bank back to 0 " doesn't make a lot of sense to me though -- shouldn't it always set bank back to 0? Or does the menu code also reside in bank 4? It executes some code in bank 4 that also loads some code into RAM which it then executes as well. This code sets bank back to 0 and continues with menu.

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Tue Dec 16, 2014 2:52 pm
	Interesting. So the menu code is split (or duplicated?) between banks 0 and 4? I wonder if banks 4-7 are split out into their own ROM, if they'll execute as a 4-in-1 cart as well. (Maybe they actually have two ROMs on the PCB for the 8-in-1, and can choose to just populate a single one, and either one works?)

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Tue Dec 16, 2014 2:57 pm
Calindro Joined: 14 Apr 2013 Posts: 624	ishiyakazuo wrote Interesting. So the menu code is split (or duplicated?) between banks 0 and 4? No, the code in bank 4 only does the following: - load some values from ROM into RAM - load code that doesn't do anything else than setting bank back to 0 and jumping back to menu code - execute the code that has just been loaded into RAM (I didn't expect you to want to know it in so much detail :P)

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Tue Dec 16, 2014 3:00 pm
	Isn't that what a dev forum is for? Document ALL THE THINGS. ;)

Bock Site Admin Joined: 08 Jul 2001 Posts: 8648 Location: Paris, France	Posted: Tue Dec 16, 2014 3:03 pm
	Here's pictures of the board. hi-com 8-in-1 board front.JPG (588.41 KB) hi-com 8-in-1 board back.JPG (751.16 KB)

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Tue Dec 16, 2014 3:04 pm Last edited by Calindro on Tue Dec 16, 2014 3:07 pm; edited 2 times in total
Calindro Joined: 14 Apr 2013 Posts: 624	ishiyakazuo wrote Isn't that what a dev forum is for? Document ALL THE THINGS. ;) Sure, but if you want to know Quote ALL THE THINGS you might want to follow Bock's advice and try stepping through the code. Because I might have missed something out :) Edit: After seeing Bock's pics you could have also asked Bock for pics in your case :D

Bock Site Admin Joined: 08 Jul 2001 Posts: 8648 Location: Paris, France	Posted: Tue Dec 16, 2014 3:05 pm
	The menus are duplicated. BOTH halves can function as standalone roms. Try cutting them in half and see. They can each display a 4-in-1 menu.

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Tue Dec 16, 2014 4:19 pm
	If I wasn't in the office, I would definitely do some looking into those things ;) But people might look at me funny loading and playing with SMS ROMs at work. Plus, if someone's already done the work to reverse engineer the code to make it work in emulators, why not ask the questions to get the info out there? Reinventing the wheel just because you can doesn't seem all that sensible to me.

sverx Joined: 05 Sep 2013 Posts: 3794 Location: Stockholm, Sweden	Posted: Tue Dec 16, 2014 4:22 pm
	ishiyakazuo wrote But people might look at me funny loading and playing with SMS ROMs at work. Actually they always seem a lot interested ;)

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Tue Dec 16, 2014 4:23 pm
	To be fair, I've never tried it, so I'm only speculating at the response I'll get...

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Tue Dec 16, 2014 5:37 pm
	ishiyakazuo wrote Reinventing the wheel just because you can doesn't seem all that sensible to me. Agreed... information needs to be shared.

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Tue Dec 16, 2014 7:04 pm
Calindro Joined: 14 Apr 2013 Posts: 624	ishiyakazuo wrote If I wasn't in the office, I would definitely do some looking into those things ;) But people might look at me funny loading and playing with SMS ROMs at work. Plus, if someone's already done the work to reverse engineer the code to make it work in emulators, why not ask the questions to get the info out there? Reinventing the wheel just because you can doesn't seem all that sensible to me. Doesn't the debugger look technical enough to please your co-workers? :) I didn't have anything reverse engineered. I just took a quick look to answer your questions. Then you asked more detailed questions so I took another, this time closer, look. All I knew before was that bank is being set to 0 then to 4 then back to 0 and that before I emulated the mapper I only saw 4 games, when I emulated I saw 8 games. So everything I know about it is contained in this topic already. :)

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Tue Dec 16, 2014 7:31 pm
	I appreciate your detective work on my behalf then :) I just figured that to have it emulated, it probably needed some initial detective work, so asking the questions was the most straightforward route. I didn't really expect anyone to look into it for me. Sorry if that was unclear.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8648 Location: Paris, France	Posted: Sun Dec 21, 2014 10:28 am
	As pointed by concept92 (in an e-mail), the ROM chips are saying 9003H S0019 9017 and 9003H S0011 9016 Would be worth comparing to the other cartridges see if we can draw patterns and references. 9016/9017 probably stands for the standard "16/17th week of 1990"

nitrofurano Joined: 01 Aug 2012 Posts: 322 Location: Porto, Portugal	Posted: Tue Aug 16, 2016 7:52 pm
	is it possible (and simple) to extract (and patch if needed) all the games individually from these cartridge roms? i only extracted Monkey Academy and Exerion from a bash script like this: http://pastebin.com/d8aGECqh

bsittler Joined: 22 Apr 2018 Posts: 530	Posted: Sat Mar 21, 2020 2:09 am
bsittler Joined: 22 Apr 2018 Posts: 530	nitrofurano wrote is it possible (and simple) to extract (and patch if needed) all the games individually from these cartridge roms? i only extracted Monkey Academy and Exerion from a bash script like this: http://pastebin.com/d8aGECqh (Reviving this ancient thread since I've been looking into patching some of the entries to work on the Game Gear.) It is possible, but not entirely easy in some cases — games typically have the first three bytes overwritten with a jump. Extraction with dd in 32KB blocks works pretty well. In many cases overwriting the first three or four bytes with NUL (0x00) bytes results in a working game. Games originally developed for MSX typically have a modified MSX BIOS for use on SMS prefixed to the game, and that BIOS has its first three bytes overwritten (in most cases it also has a menu patched into some unused space inside the BIOS area.) There are several MSX games in the 8-in-1 collections, all of which appear to be Hi-Com modifications of Konami originals: Athletic Land, Circus Charlie, Hyper Sports 2, King's Valley 1, Magical Tree, Monkey Academy, and Yie Ar Kung-Fu 1. Visible references to Konami have been removed or replaced by Hi-Com, but the string KONAMI remains in some places. The rest of the games in the 8-in-1 collections appear to mostly be SG-1000 and SMS My Card/Sega Card releases (unsurprising, given the size constraints of the mapper) and many of them are unmodified other than the first three bytes. The following entries are modified, however: Astro Flash, Exerion, Hyper Sports 1, Safari Race, and Star Force. Due to the smaller 16KB ROM being duplicated prior to the overwriting of the first bytes with a jump instruction, there is also an unmodified copy of the 16KB version of Sega Galaga inside Hi-Com 8-in-1 The Best Game Collection B (KR).sms edit: also the Exerion in Hi-Com 8-in-1 The Best Game Collection C (KR).sms appears to only have the first 16KB, duplicated (but with the first three bytes overwritten in the first copy, thanks to the menu jump)

Forums

View topic - Korean Hi-Com 3 in 1 / 8 in 1 cartridges