What's new
That's it! won't work due to some unknown thing like a jumper. If attempting to port to hammering harry pal you would be looking at the h1 roms issue on top of the original issue.After hours of looking at the board could not see anything.
If it was still here you would have a diagram right now, Sadly the H.H ended up going back to his owner a little experimenting.
Ok so that's 2 different problems. I'd try the conversion of R-Type II to HH using HH memory map in MAME first, forcing larger h1/l1 ROM images.
Then has the smaller size of h1/l1 ROMs of HH been proven to be a problem? I mean what happens if we just slightly modify the code to jump to the "theoretically" unmpapped area and just return then to see if code is correctly executed on real hardware? I'm sure you see what I mean, like modifying the start code vector and then calling it from the jump we made outside "normal" ROM area.

Just trying to understand why it doesn't work when other crazier conversions cause no problem (encrypted M84 ported to older unencrypted M72).
 
Just trying to understand why it doesn't work when other crazier conversions cause no problem (encrypted M84 ported to older unencrypted M72).
Yep me too, i could not get cosmic working cosmic cop with kengo's smaller rom mapping either so there's deffo something else going on with the upper roms.
 
That's it! won't work due to some unknown thing like a jumper. If attempting to port to hammering harry pal you would be looking at the h1 roms issue on top of the original issue.After hours of looking at the board could not see anything.
If it was still here you would have a diagram right now, Sadly the H.H ended up going back to his owner a little experimenting.
Ok so that's 2 different problems. I'd try the conversion of R-Type II to HH using HH memory map in MAME first, forcing larger h1/l1 ROM images.Then has the smaller size of h1/l1 ROMs of HH been proven to be a problem? I mean what happens if we just slightly modify the code to jump to the "theoretically" unmpapped area and just return then to see if code is correctly executed on real hardware? I'm sure you see what I mean, like modifying the start code vector and then calling it from the jump we made outside "normal" ROM area.

Just trying to understand why it doesn't work when other crazier conversions cause no problem (encrypted M84 ported to older unencrypted M72).
I just tried transplanting everything but the gfx/tiles from the 'rtype2' MAME set to 'hharryu' (the M84 version) and raising the h1/l1 sizes then recompiling MAME. It fails to boot up unfortunately.
rthharryu.jpg

I think the main problem is probably the different address mapping (specifically the palette ram)?
MAME' said:
void m72_state::rtype2_map(address_map &map)
{
m84_cpu1_common_map(map);
map(0xd0000, 0xd3fff).ram().w(FUNC(m72_state::videoram1_w)).share("videoram1");
map(0xd4000, 0xd7fff).ram().w(FUNC(m72_state::videoram2_w)).share("videoram2");
map(0xc8000, 0xc8bff).rw(FUNC(m72_state::palette1_r), FUNC(m72_state::palette1_w)).share("paletteram");
map(0xd8000, 0xd8bff).rw(FUNC(m72_state::palette2_r), FUNC(m72_state::palette2_w)).share("paletteram2");
}

void m72_state::hharryu_map(address_map &map)
{
m84_cpu1_common_map(map);
map(0xd0000, 0xd3fff).ram().w(FUNC(m72_state::videoram1_w)).share("videoram1");
map(0xd4000, 0xd7fff).ram().w(FUNC(m72_state::videoram2_w)).share("videoram2");
map(0xa0000, 0xa0bff).rw(FUNC(m72_state::palette1_r), FUNC(m72_state::palette1_w)).share("paletteram");
map(0xa8000, 0xa8bff).rw(FUNC(m72_state::palette2_r), FUNC(m72_state::palette2_w)).share("paletteram2");
}
Although of course it's possible I did something wrong. Here is the original ROM start code:
MAME' said:
ROM_START( hharryu )
ROM_REGION( 0x100000, "maincpu", 0 )
ROM_LOAD16_BYTE( "a-ho-u.8d", 0x00001, 0x20000, CRC(ede7f755) SHA1(adcec83d6b936ab1a14d039792b9375e9f803a08) )
ROM_LOAD16_BYTE( "a-lo-u.9d", 0x00000, 0x20000, CRC(df0726ae) SHA1(7ef163d2e8c14a14328d4365705bb31540bdc7cb) )
ROM_LOAD16_BYTE( "a-h1-f.8b", 0x60001, 0x10000, CRC(31b741c5) SHA1(46c1c4cea09477cc4989f3e06e08851d02743e62) )
ROM_RELOAD( 0xe0001, 0x10000 )
ROM_LOAD16_BYTE( "a-l1-f.9b", 0x60000, 0x10000, CRC(b23e966c) SHA1(f506f6d1f4f7874070e91d1df8f141cca031ce29) )
ROM_RELOAD( 0xe0000, 0x10000 )
I modified it as follows to use the larger h1/l1 roms:
MAME' said:
ROM_START( hharryu )
ROM_REGION( 0x120000, "maincpu", 0 )
ROM_LOAD16_BYTE( "a-ho-u.8d", 0x00001, 0x20000, CRC(ede7f755) SHA1(adcec83d6b936ab1a14d039792b9375e9f803a08) )
ROM_LOAD16_BYTE( "a-lo-u.9d", 0x00000, 0x20000, CRC(df0726ae) SHA1(7ef163d2e8c14a14328d4365705bb31540bdc7cb) )
ROM_LOAD16_BYTE( "a-h1-f.8b", 0x60001, 0x20000, CRC(31b741c5) SHA1(46c1c4cea09477cc4989f3e06e08851d02743e62) )
ROM_RELOAD( 0xe0001, 0x20000 )
ROM_LOAD16_BYTE( "a-l1-f.9b", 0x60000, 0x20000, CRC(b23e966c) SHA1(f506f6d1f4f7874070e91d1df8f141cca031ce29) )
ROM_RELOAD( 0xe0000, 0x20000 )
As a reference here's the rom start for rtype2:
MAME' said:
ROM_START( rtype2 )
ROM_REGION( 0x100000, "maincpu", 0 )
ROM_LOAD16_BYTE( "rt2-a-h0-d.54", 0x00001, 0x20000, CRC(d8ece6f4) SHA1(f7bb246fe8b75af24716d419bb3c6e7d9cd0971e) )
ROM_LOAD16_BYTE( "rt2-a-l0-d.60", 0x00000, 0x20000, CRC(32cfb2e4) SHA1(d4b44a40e2933040eddb2b09de7bfe28d76c5f25) )
ROM_LOAD16_BYTE( "rt2-a-h1-d.53", 0x40001, 0x20000, CRC(4f6e9b15) SHA1(ef733c2615951f54691877ad3e84d08107723324) )
ROM_RELOAD( 0xc0001, 0x20000 )
ROM_LOAD16_BYTE( "rt2-a-l1-d.59", 0x40000, 0x20000, CRC(0fd123bf) SHA1(1133163f6716e9a4bbb437b3a471477d0bd97051) )
ROM_RELOAD( 0xc0000, 0x20000 )
Note that without modifying the ROM_REGION size, MAME refused to boot the game because the ROMs exceeded the allotted space. I think raising it from 0x100000 to 0x120000 was probably not the right move, but rather the address locations for the ROMs have to be modified too. Sure, I could copy the values from the rtype2 definition above, but how would this translate on real hardware?

Another note is that there are 8 gfx/tiles chips for rtype2 and only 4 for hharryu but that's probably an easy fix.

Thoughts?

Edit: Also, I tried the ROMs from the Major Title to R-Type 2 conversion archive (rtype2mt.zip) with the same results.
 
Last edited:
Rom region doesn't need to be changed, it's always 0x100000 (512kb).
However areas where ROMs are loaded must be changed then palette RAM offsets too in the code.
 
Rom region doesn't need to be changed, it's always 0x100000 (512kb).
However areas where ROMs are loaded must be changed then palette RAM offsets too in the code.
So the palette RAM issue is likely what prevented it from working when @Hammy tried on real hardware then right?
 
So the palette RAM issue is likely what prevented it from working when @Hammy tried on real hardware then right?
Not in the situation where he moved all ROMs and PALs.
In case of a conversion using HH PALs I'd guess nothing is displayed on screen if palette offsets aren't modified.
 
Rom region doesn't need to be changed, it's always 0x100000 (512kb).
However areas where ROMs are loaded must be changed then palette RAM offsets too in the code.
So the palette RAM issue is likely what prevented it from working when @Hammy tried on real hardware then right?
No i could of ported that if needed but used original parts.
If you modify mame to get it running you are only modding what cannot be modded on the PCB (h1 rom ranges)
 
If you modify mame to get it running you are only modding what cannot be modded on the PCB (h1 rom ranges)
If would rephrase it differently "modding what we don't know how to mod on the PCB yet" ;)
Let stay positive.
 
Kengo decrypted + FFA :)

So if you got a hammerin' harry, you may get this running because it uses a smaller rom space.
Will port to m82 / major hardware soon :)
Hey Hammy, good job!
You should have told me you were interested by the decrypted Kengo. I've ported it to M72 for the multi so obviously had to decrypt it first.
 
Last edited by a moderator:
Cheers! took forever because i don't use scripts /all by eye.

Did ask for it some other time and you said no, don't know why lol
It's ok tho, in this case got the original board so was on the hit list regardless and always learn something!

Funny tho, it works both ways... you did king of dragons again and i'd done that a few years ago lol
The theme of address error and ye old hydra and the bastard at the end ring some bells ;)

If you want to work together, i'm not hiding or anything! Still got those customs etc for ya, happy to help etc..
Time is limited for us all And the line of projects here developing is insane and yours must be the same/longer ;)
 
Did ask for it some other time and you said no, don't know why lol
Really, I don't remember you asking... Anyway sorry about that I must have been in a bad day.
As you can see I now post my work here so everyone can enjoy (The King Of Dragons, Fantasy Zone 1 on S16B, etc.).

Oh and about working together, I thought about it many times, I'm very impressed by the work of some hobbyists here, imagine what we could achieve if we teamed up.
I'm not only talking about video games, but at the larger scale regarding coding, etc.
I've worked myself on image recognition (for instance how to recognise a place at different period of time or weather from a photo, like during a sunny day in summer and a snowy night in winter). There are many, many fields to be improved.
 
You guys are both awesome. Thank you so much for your efforts to preserve these old games and give the rest of us a chance to enjoy them.
 
Back
Top