Wonder Boy System1 to Mega Drive port

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Post Reply
User avatar
ArcadeTV
Interested
Posts: 21
Joined: Sat Jun 03, 2017 8:37 am
Location: DE
Contact:

Wonder Boy System1 to Mega Drive port

Post by ArcadeTV » Sat Dec 15, 2018 1:44 pm

Hey guys,
I'd like to create a project page for something I wanted to do for a long time. After messing around with Monster World 3 and 4 and successfully finished my translation-hacks, I'd like to try and make a complete game for the MD/Genesis.

Image

I'm looking for answers to a bunch of questions that I have and hopefully this may be a kickstart into Genesis development for me.

Ok, let's start with some specs and why I think this port could be made.
The native resolution matches 256x224, which is a good start, though the Clocks are pretty different between SYS1 and MD.
The original System1 board comes with 2 Z80's the second one being the co-processor for anything related to sound.
There are 2 SN76489 PSG chips, the first outputting the BGM, while the second one plays only the SFX.

The MAME driver holds a lot of usseful information, I'll target the romset "wboy2u" because it has non-encrypted opcodes in its main-program.

The order of the roms, their purpose and sizes are layed out like this:

Code: Select all

ROM_START( wboy2u )
	ROM_REGION( 0x10000, "maincpu", 0 )
	ROM_LOAD( "ic129_02.bin",   0x0000, 0x2000, CRC(32c4b709) SHA1(e57b7b6818f12fdd5f1600ed54c0b8a7f538aa71) )
	ROM_LOAD( "ic130_03.bin",   0x2000, 0x2000, CRC(56463ede) SHA1(c58c220aa0d0e194581646e6db2491075fdc37b9) )
	ROM_LOAD( "ic131_04.bin",   0x4000, 0x2000, CRC(775ed392) SHA1(073f8f70685913736eb04be8215a47b5253cb531) )
	ROM_LOAD( "ic132_05.bin",   0x6000, 0x2000, CRC(7b922708) SHA1(c2e1f67b756f558d6904fe82d6f5483cda5f9045) )
	ROM_LOAD( "epr-7591.133",   0x8000, 0x2000, CRC(8379aa23) SHA1(da47e0150b724a00878ef5f953fa6ac80bb27d8d) )
	ROM_LOAD( "epr-7592.134",   0xa000, 0x2000, CRC(c767a5d7) SHA1(a4e8d6a8278ac2227bde8c24d45aa7ab2a273579) )

	ROM_REGION( 0x10000, "soundcpu", 0 )
	ROM_LOAD( "epr7498a.3",     0x0000, 0x2000, CRC(c198205c) SHA1(d2d5cd154ce6a5a3c6a099b4ab2ea7cc045ab0a1) )

	ROM_REGION( 0xc000, "tiles", 0 )
	ROM_LOAD( "epr-7497.62",    0x0000, 0x2000, CRC(08d609ca) SHA1(11799e9ef7e6942b304f132b404bff3ed44d524b) ) /* epr-7497.82 */
	ROM_LOAD( "epr-7496.61",    0x2000, 0x2000, CRC(6f61fdf1) SHA1(21826aebf5835b9f3d9c467c8647809c1bc0d01f) ) /* epr-7496.65 */
	ROM_LOAD( "epr-7495.64",    0x4000, 0x2000, CRC(6a0d2c2d) SHA1(8c21d7f0768e8dda2b7185f3c510cae4229a4a2e) ) /* epr-7495.81 */
	ROM_LOAD( "epr-7494.63",    0x6000, 0x2000, CRC(a8e281c7) SHA1(a88b80a7b94ab1401bbf28d7707fdf28a5505127) ) /* epr-7494.64 */
	ROM_LOAD( "epr-7493.66",    0x8000, 0x2000, CRC(89305df4) SHA1(7a5098624769a31e7512f56831e818bce6a18871) ) /* epr-7493.80 */
	ROM_LOAD( "epr-7492.65",    0xa000, 0x2000, CRC(60f806b1) SHA1(f91e5868a455dff2bce3c2891a7cfd648957cd73) ) /* epr-7492.63 */

	ROM_REGION( 0x10000, "sprites", 0 )
	ROM_LOAD( "epr-7485.117",   0x0000, 0x4000, CRC(c2891722) SHA1(e4e11c0e9bd0dc121c25349493f2b13d2ff8c807) ) /* epr-7485.3 */
	ROM_LOAD( "epr-7487.04",    0x4000, 0x4000, CRC(2d3a421b) SHA1(d70440a8703ccface3212cd9544c950b36263e8c) ) /* epr-7487.1 */
	ROM_LOAD( "epr-7486.110",   0x8000, 0x4000, CRC(8d622c50) SHA1(9a76a50204c618347d3e8eee6cda841becd906eb) ) /* epr-7486.4 */
	ROM_LOAD( "epr-7488.05",    0xc000, 0x4000, CRC(007c2f1b) SHA1(c2f1376144a49d20cb35384648e06d06978474c1) ) /* epr-7488.2 */

	ROM_REGION( 0x0100, "proms", 0 )
	ROM_LOAD( "pr-5317.76",     0x0000, 0x0100, CRC(648350b8) SHA1(c7986aa9127ef5b50b845434cb4e81dff9861cd2) )
																/* pr-5317.106 */
ROM_END
By either concatenating the corresponding roms or dumping a region with MAME's debugger I was able the get 2 files for the main-program and sound-programm for dissection e.g. in IDA pro or MAME's disassembler.


When the game is initializing it checks the roms for a fixed checksum (I presume), so I had to disable this check if I wanted to be able to alter the code and manipulate stuff for research.
MAME's tracer came in handy - I traced the ProgramCounter while the system was booting, both with modified and unmodified roms.
I found an instruction by looking at the DIFF of both trace-files:
At offset $0020 PC jumps to $00E1 if check fails, or jumps to $0023 if check succeeded:
0020: jp nz,$00E1

So I changed "ic129_02.bin" at $0021 from E1 to 23 and the system is not complaining any more, doesn't matter how many roms are changed :D


Ok, so my current goal is to understand what happens in Wonder Boy and make plans how to port all those routines to run on the Genesis.

Here's the memory map of my target romset "wboy2u" which is a bit different from other System1-games because there's an intel PPI on the board:

Code: Select all

/* main memory map */
void system1_state::system1_map(address_map &map)
{
map(0x0000, 0x7fff).rom();
map(0x8000, 0xbfff).bankr("bank1");
map(0xc000, 0xcfff).ram().share("ram");
map(0xd000, 0xd7ff).ram().share("spriteram");
map(0xd800, 0xdfff).ram().w(FUNC(system1_state::system1_paletteram_w)).share("palette");
map(0xe000, 0xefff).rw(FUNC(system1_state::system1_videoram_r), FUNC(system1_state::system1_videoram_w));
map(0xf000, 0xf3ff).rw(FUNC(system1_state::system1_mixer_collision_r), FUNC(system1_state::system1_mixer_collision_w));
map(0xf400, 0xf7ff).w(FUNC(system1_state::system1_mixer_collision_reset_w));
map(0xf800, 0xfbff).rw(FUNC(system1_state::system1_sprite_collision_r), FUNC(system1_state::system1_sprite_collision_w));
map(0xfc00, 0xffff).w(FUNC(system1_state::system1_sprite_collision_reset_w));
}

I'd like to start with a question that came up while analyzing the sound-program and data..
I believe there are 3 sound-related connections on the genesis' cart-port, B1, B2 and B3.
I was wondering if I could save the hassle of dealing with the YM2612 at all by using a second SN76489 on the cart-pcb?


The next big question mark over my head is the logic behind displaying graphics on System1:

Code: Select all

The output of the lookup PROM is a 4-bit value. The lower 2 bits
select sprite data (0), fixed tilemap (1) or scrolling tilemap (2).
9 bits of data from the appropriate source are used as a lookup
into a palette RAM, and the lookup PROM's low 2 bits are used as
the upper 2 bits of the palette RAM address, providing 512
independent colors for each source.

The upper 2 bits of the lookup PROM are used for an additional
mixer collision detection. Bit 2 indicates that a collision
should be recorded, and bit 3 indicates which of two banks of
collision flags should be set. Each bank is 32 entries long, and
the sprite index is used to select which bit within the bank to
set.

/*************************************
*
* Graphics definitions
*
*************************************/

static const gfx_layout charlayout =
{
8,8,
RGN_FRAC(1,3),
3,
{ RGN_FRAC(0,3), RGN_FRAC(1,3), RGN_FRAC(2,3) },
{ STEP8(0,1) },
{ STEP8(0,8) },
8*8
};

static GFXDECODE_START( gfx_system1 )
GFXDECODE_ENTRY( "tiles", 0, charlayout, 0, 256 )
GFXDECODE_END
None of the ususal GFX-ripping tools displays the tiles or sprites correctly since they have to be requested via the lookup-table stored in the PROM and then dissected into different bits, which are responsible for data, palette or collision, at least how I understand this.

I'm confident I could write a script that generates everything I need to port the GFX if I would understand how this works.

Ok, so that might have been a not too well-organized start into this project, but I'm grateful for any info, opinion, pointer or criticism I can get.
Thanks!

cero
Very interested
Posts: 253
Joined: Mon Nov 30, 2015 1:55 pm

Re: Wonder Boy System1 to Mega Drive port

Post by cero » Sat Dec 15, 2018 7:16 pm

An asm line-by-line port is certainly going to be accurate, but also take a very long time. "Just" dumping the art and data like levels, either from the binary or from an emulator, then doing the logic by eye might be faster. If you're willing to accept some inaccuracy, that is.

User avatar
Miquel
Very interested
Posts: 437
Joined: Sat Jul 30, 2016 12:33 am

Re: Wonder Boy System1 to Mega Drive port

Post by Miquel » Sat Dec 22, 2018 7:20 pm

So what you are planning is to develop a tool that translates Z80 code to 68K code, is that correct?
Are you trying to make everything automated?

User avatar
ArcadeTV
Interested
Posts: 21
Joined: Sat Jun 03, 2017 8:37 am
Location: DE
Contact:

Re: Wonder Boy System1 to Mega Drive port

Post by ArcadeTV » Sun Dec 23, 2018 2:21 pm

Miquel wrote:
Sat Dec 22, 2018 7:20 pm
So what you are planning is to develop a tool that translates Z80 code to 68K code, is that correct?
Are you trying to make everything automated?
I'd rather automate all the assets, targeting but not limited to gfx and sound data.
I think the better approach would be to do the code conversion manually to be more flexible when it comes to creating menus and a proper ending which would be a nice addon for a home-system-conversion.

User avatar
Miquel
Very interested
Posts: 437
Joined: Sat Jul 30, 2016 12:33 am

Re: Wonder Boy System1 to Mega Drive port

Post by Miquel » Sun Dec 23, 2018 8:11 pm

The text you posted doesn’t sound at all as a graphics chip, but more as a software definition of characters’ sprites per frame; not really the actual graphics data.
You don’t need to worry, since you’re going to translate the code manually, those matters will be shown in time. It’s not like a chip that can have hidden behavior.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest