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 - Sega Game 1000 Mega SGC Thread

Reply to topic
Author Message
  • Joined: 28 Nov 2014
  • Posts: 365
Reply with quote
Sega Game 1000 Mega SGC Thread
Post Posted: Fri Feb 05, 2016 11:10 pm
Not sure how well this will pan out. There are only 84 titles available and not all seem to have music. Most don't have hacks atm, but I am focusing on SG now that GG is largely finished (VGMs) and only a few dozen SMS titles remain.

Here are a few new releases. Some are optimized, some not. Moving forward I will try to package and be clearer with how the package is organized.

I haven't seen any SG games available as SGC, and very few have VGMs, so this is still somewhat unexplored territory.

I'm experimenting with a naming standard that indicates how much remains. At the moment 1.10 means all music/sfx ids have been added. 1.20 would indicate voice as well. That's not likely to be an issue with these packs. 0.01 means it works but no other work has been done.

The text files mirror the vgm texts, but are altered a bit to give more meaningful data, and to be more relevant to an sgc.

I think a final version should be optimized and have a playlist as well. I'm omitting these last two steps for now as they add alot of overhead.

Feedback and advice would be welcome.

Hope you enjoy.

update: Added a few more. These work, but they have not been processed. A minimalist text file is included to explain what remains to be done. (ids, tags, everything but getting it working).

  View user's profile Send private message
  • Joined: 28 Nov 2014
  • Posts: 365
Reply with quote
Post Posted: Sun Feb 07, 2016 4:47 am
Last edited by sherpa on Mon Feb 08, 2016 5:00 am; edited 1 time in total
Moved the non working file to a new post

These all work, but need more work done. Text files give info where necessary.

  View user's profile Send private message
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Sun Feb 07, 2016 1:39 pm
Championship Golf is going to be difficult indeed.
For the SGC you need all bytes from 100h (beginning of the UpdateSound rotuine) to 9F1h.
In order to get a working SGC you'd need to relocate most of the sound code. The fastest and easiest way would probably be to make a disassembly and reassemble it with another base offset.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Nov 2014
  • Posts: 365
Reply with quote
Post Posted: Sun Feb 07, 2016 2:50 pm
Wow. Even worse than I thought! :)

How exactly would I disassemble/reassemble?

It doesn't seem to me to be just a matter of using z80dasm or some other software (emulicious) to export the code and reordering it and changing values in key areas and then reassembling it.

I'm going to focus on the other easier ones for now as I've been doing lately, but It would be great to have what you're talking about in my schema. I remember reading some time ago, a post by a forum member where they mentioned they had developed a good disasembler/assembler that was very close to the byte level accurate. Not sure if it was released. That's a bit more complicated than I'm used to.

Thanks for the feedback. (I was actually hoping you'd step in with some advice :) If you're at all interested in resolving this, feel free. It's probably going to be a while before I attend to it. If you do pursue a creative solution, please share some of the important bits with the rest of us! It's great to have nice info like this available for future reference.

update: Home Mahjong also seems to have the same issue. The bulk of the music engine is in the first 1K (also starts at 100). It's not clear if it accesses higher addresses as Champion Golf seems to.
Zippy Race also has the sound engine start at 100, so it could be all three would have the same solution.

It might be worth it to explore some alternative solutions.
  View user's profile Send private message
  • Joined: 28 Nov 2014
  • Posts: 365
Reply with quote
Post Posted: Mon Feb 08, 2016 5:06 am
Champion Golf has important data in the first 0x400 bytes. It still doesn't work. I took another crack at it but couldn't get it working. Will probably have to start from scratch. help welcomed.

The other non working games do not work despite using the trigger and having the proper update function (likely). In some cases, the sound engine needs to be turned on or behaves differently based on some other variable. In game, these issues are not found, but it's not easy to check what's going on as it is in an emulator.

A few of the easy ones remain. It might be a bit slow going forward, and I may switch gears to something else if it goes too slow.

43 (pretty much half) of the SG-1000 games have a working sgc (even if not completed). I'm happy it went as fast as it did. There weren't any SG games with sgcs available. Just over a dozen have vgm packs, so many more now have music readily accessible. Not sure when I'll finish fleshing them out. I'm prioritizing getting a basic working version done before continuing to flush them out.

Enjoy.
Pachinko (SG-1000) v0.01.zip (2.14 KB)
works

  View user's profile Send private message
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Mon Feb 08, 2016 8:43 pm
sherpa wrote
How exactly would I disassemble/reassemble?

It doesn't seem to me to be just a matter of using z80dasm or some other software (emulicious) to export the code and reordering it and changing values in key areas and then reassembling it.
That's actually (more or less) the process.
You disassemble it, put an "org 4000h" (for example) at the top and reassemble it. (And you hope that it detected all memory offsets properly and didn't just read it as 16-bit numbers.)

You really need to know what you're doing though, so I'm not sure if you're up to the task already.

Also: It makes it hard to check your SGCs if the required data begins at 100h and the SGC begins at ROM offset 400h.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14685
  • Location: London
Reply with quote
Post Posted: Tue Feb 09, 2016 8:38 am
Older disassemblers won't convert jump and call targets to labels, leaving them as relative or absolute addresses. So relocation is hard. Also, disassembled data is in danger of being "relocated" and corrupted. Newer disassemblers try to trace execution but may fail to detect code as runnable.

What do you do about rst opcodes in SGCs?

Can't you "optimise" them automatically by playing all tracks and tracking every byte accessed?
  View user's profile Send private message Visit poster's website
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Tue Feb 09, 2016 7:30 pm
Maxim wrote
What do you do about rst opcodes in SGCs?
The SGC header allows you to specify memory offsets for each of the 8 RST locations, so you can redirect them easily.
(nezplug implements that by putting "JP offset" instructions at offset 0, 8, etc.)

Maxim wrote
Can't you "optimise" them automatically by playing all tracks and tracking every byte accessed?
That should be possible. It also seems to be common practise for the PSF format.
I assume Emulicious supports something like this? (I haven't used it yet, because I use MEKA for playing and MAME/MESS was good enough for debugging so far.)
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!