Need some help with a driver im working on...

[arcadez2003]

@MistyDreams @mahoneyt944 Can any of ya's compile a MAME90 build.??

Im converting hvyunit.c for use in my own core and i'll likely look into porting across to AdvanceMAME unfortunately i've run into a little issue with the game in question, it wont work in this core as we lack the I8051 CPU core.

However since the game had a small prot sim before the mermaid mcu was dumped it should be possible for me to create a MAME78 version of the driver for testing and hopefully one of ya's might be able to run a debug to pindown what is causing the problem as after three weeks of trying this and that im kinda outta ideas here.

Regards.

[MistyDreams]

I can compile but but the assembly tilemap and blitting (same video code as 078) crashes. Im not sure what version of mingw crt is needed or nasm. I know the current mingw is win8+ only.

[arcadez2003]

Ok no worries after reading this i've went and created a MAME78 version of the driver which im compiling now for testing, the game wont be playable with the prot sim right enough but the attract mode should function correctly which means you can see the issue im having.

I think it's connected to the banking or the sharedram however it could something else gfx related which i've not spotted yet i'll send the driver your way shortly i need to make sure the game actually boots up firstly.

And thanks for taking an interest :)

[arcadez2003]

hvyunit.zip

Black screen on load hang on until the simulation of the attract mode kicks in you'll notice the issue soon after the sprites stick on screen and there are no enemies when there should be.

i've never seen the game running in MAME with the prot sim but from reading the notes it should be exactly the same as you see it in current MAME or FBN, if you can compile FBN do this and you'll get more or less the same issues.......

static void __fastcall hvyunit_main_write_port(UINT16 port, UINT8 data) { switch (port & 0xff) { case 0x00: // case 0x01: master_bankswitch(data);

Which makes me think this is a banking issue which is wiping out the masterbank on 0x01

[MistyDreams]

Ill have a look when I get the chance too take a proper look. If your looking to see if it worked in mame090 mame hosts the old binaries and source. https://sourceforge.net/projects/mame/files/mame/0.90/mame090b.zip/download

[arcadez2003]

Well more a case of as i dont have the tools required to build a pc version of MAME i was wondering if you guys did or not, MAME90 has no significance other than it was the first build to support the I8051 CPU core so i knew my driver would compile.

I wouldn't expect the game to work in that version either in it's current emulation state.

[arcadez2003]

I've convinced myself it's the banking let's look at it

unsigned char ROM = memory_region(REGION_CPU1); int bank = data & 7; ROM = &ROM[0x4000 bank]; //memory_set_bankptr(1, ROM); // try cpu_setbank cpu_setbank(1, ROM);

Maybe it's fine for MAME78 and the core understands what is being asked of it however i've noticed most banking calls are way more data heavy and dont resemble the above whatsoever

The closest i've found in MAME78 is the banking hookup for another Kaneko game Sand Scorpian...

unsigned char *RAM = memory_region(REGION_CPU1);
int bank = data & 0x07;

if ( bank != data ) logerror("CPU #1 - PC %04X: Bank %02X\n",activecpu_get_pc(),data);

if (bank < 3)   RAM = &RAM[0x4000 * bank];
else            RAM = &RAM[0x4000 * (bank-3) + 0x10000];

cpu_setbank(1, RAM);

Ill have a look when I get the chance too take a proper look. If your looking to see if it worked in mame090 mame hosts the old binaries and source. https://sourceforge.net/projects/mame/files/mame/0.90/mame090b.zip/download

Thanks for taking a look i was honestly gonna dump the driver and move on as im thinking if i was gonna suss it out i would have by now it's been three weeks, i've been over everything with a fine toothcomb and guesswork will only get me so far.

It's either gonna be something daft i've missed or something more complex and above my level eitherway someone like yourself with an equal amount of knowledge as me and likely far more besides who can debug will have a better chance of sortin this.

But dont knock yourself out here as this might be the big ole rabbit hole none of us wants to jump down ;)

[arcadez2003]

Oh i forgot to mention bank 1 handles sprites while bank 2 pipes data for the bg tiles + scrolling and palette colours.

[MistyDreams]

Just compiled it as is so its ready to take a look at;. It does boot it you dont touch anything the sprites show abit in demo mode and the music works.

[MistyDreams]

Had a quick look fixed the inputs, shared memory and the banks. The demo mode gets further Im thinking mcu or gfx. The title screen should come between the demo modes that not happening. I hvyunit.zip

[arcadez2003]

Yeah with my driver im using in MAME84 with the I8051 and the mcu hooked up all the gfx seem correct i have the title screen the highscores are there i can start a game and it looks ok but part way through level one the game will lock up the bg's keep scrolling the music still plays but the sprites either are stuck on screen or disappear totally and you see the ram ok message once again as per the bootup cycle which makes me think it's random reset due to incorrect banking.

It's gotta be banking eh.?? as i assume the game shifts those around during the attract mode and when in game and since the banking is likely off for what these older cores expect that's why we're getting the issues.??, certainly after plugging in your sharedram changes level 3-1 attract is now correct the previously missing bullets and enemies are now there and the behavior is correct now.

We cycle on to the 2-3 attract level and the robot enemy on the far right of the screen is missing shortly after the sprites lock up and the game cycles on through to what i assume to be the end of the level before stopping the attract mode doesn't resume you can start a game but the sprites are still stuck on from before and the sprite layer is missing by looks.

[arcadez2003]

Sprites stuck on attract

Still stuck after starting a game

Start a game before the attract mode fails and it'll play as normal until around this point or shortly after on level 1

[arcadez2003]

How did you come up with this...

static data8_t sharedram[0x2000];

It's certainly made a difference we're close here i feel

[MistyDreams]

you could easily just write MwA_RAM, &sharedram done it so the reads and writes are in the same place for both cpus. . It could be 64 bit issues for me but the game doesn't start at all(with gfx). Does you 089 port work properly the simulation code?

[arcadez2003]

The simulation was pretty basic it runs the attract mode with gfx and nothing else, if you attempt to actually start the game then nothing really happens, i suppose they might have worked more on the prot and got the game to a playable state should the mcu not have been dumped for it shortly after they started on the driver.

ideally i would have liked to have sent you my MAME84 driver with the mcu hooked up but i thought a MAME78 style driver using the prot sim might have been enough for you to run a debug on the banks or the sharedram to see if one or the two are to blame here.

[arcadez2003]

Hmm i see what you mean i get the exact same results with......

//static data8_t sharedram[0x2000]; static UINT8 *sharedram;

static READ8_HANDLER( sharedram_r ) { return sharedram[offset]; }

static WRITE8_HANDLER( sharedram_w ) { sharedram[offset] = data; } then on both maps AM_RANGE(0xe000, 0xffff) AM_READ(sharedram_r) AM_RANGE(0xe000, 0xffff) AM_WRITE(sharedram_w) AM_BASE(&sharedram)

That's rare that is i see only maybe three or four other drivers which AM_BASE(&sharedram) on the second CPU usually they only AM_BASE on the first one

[MistyDreams]

Ill need to see how this core is handling banking as its not working as expected. Ill check the 142u2 code on mame2010 to see if it runs are you having issues on mame089 with the banking as well?

we certainly should be mapping 0x10000 ( above the normal memory range 0 - 0xffff) on this core if the banks above the banked mapped range

[arcadez2003]

Yeah i've been over the banking certainly using the older style i would think this one is close

static WRITE8_HANDLER( hardhead_bankswitch_w ) { data8_t *RAM = memory_region(REGION_CPU1); int bank = data & 0x0f;

if (data & ~0xef)   logerror("CPU #0 - PC %04X: unknown bank bits: %02X\n",activecpu_get_pc(),data);

RAM = &RAM[0x4000 * bank + 0x10000];
cpu_setbank(1, RAM);

}

Maybe with some modding this would work.??

static WRITE8_HANDLER( hardhead_bankswitch_w ) { data8_t *RAM = memory_region(REGION_CPU1); int bank = data & 7;

RAM = &RAM[0x4000 * bank + 0x10000];
cpu_setbank(1, RAM);

}

AM_RANGE(0x8000, 0xbfff) AM_READ(MRA8_BANK1             )   // Banked ROM
AM_RANGE(0x8000, 0xbfff) AM_WRITE(MWA8_ROM              )   // Banked ROM

[arcadez2003]

Ok so.......

static WRITE8_HANDLER( master_bankswitch_w ) { // unsigned char ROM = memory_region(REGION_CPU1); // int bank = data & 7; //ROM = &ROM[0x4000 bank]; //memory_set_bankptr(1, ROM);

unsigned char *RAM = memory_region(REGION_CPU1);
int bank = data & 7;

if (bank & ~7)  logerror("CPU#0 PC %06X - ROM bank unknown bits: %02X\n", activecpu_get_pc(), data);

RAM = &RAM[0x4000 * bank + 0x10000];
cpu_setbank(1, RAM);

}

static WRITE8_HANDLER( slave_bankswitch_w ) { // unsigned char ROM = memory_region(REGION_CPU2); // int bank = (data & 0x03); // port0_data = data; // ROM = &ROM[0x4000 bank]; // memory_set_bankptr(2, ROM);

unsigned char *RAM = memory_region(REGION_CPU2);
int bank = data & 0x03;
port0_data = data;

if (bank & ~0x03)   logerror("CPU#1 PC %06X - ROM bank unknown bits: %02X\n", activecpu_get_pc(), data);

RAM = &RAM[0x4000 * bank + 0x10000];
cpu_setbank(2, RAM);

}

static WRITE8_HANDLER( sound_bankswitch_w ) { //unsigned char ROM = memory_region(REGION_CPU3); //int bank = data & 0x3; //ROM = &ROM[0x4000 bank]; //memory_set_bankptr(3, ROM);

unsigned char *RAM = memory_region(REGION_CPU3); int bank = data & 0x03;

if (bank & ~0x03)   logerror("CPU#2 PC %06X - ROM bank unknown bits: %02X\n", activecpu_get_pc(), data);

RAM = &RAM[0x4000 * bank + 0x10000];
cpu_setbank(3, RAM);

}

And then on the master slave and sound port maps AM_RANGE(0x8000, 0xbfff) AM_READ(MRA8_BANK1) AM_RANGE(0x8000, 0xbfff) AM_WRITE(MWA8_ROM)

This would be correct in the older banking style i would think

[arcadez2003]

Im compling now it this doesn't work i can add back in the pandora sprites once again to see if using the proper drawing rather than a hack created for dJ Boy will work better.

[arcadez2003]

well it doesn't like the + 0x10000 but the game will boot with RAM = &RAM[0x4000 * bank]; but same deal right im gonna add in the pandora sprites and see where we are

[MistyDreams]

youll need increase the cpu memory regions in the rom definitions for that 0xffff + the banksize required

[arcadez2003]

Ok with the pandora sprite drawing things are looking far better the attract mode cycled one full turn all the levels looked correct but on the second run through on that same level 2-3 the sprites disappeared and the locked up so near it seems

[arcadez2003]

youll need increase the cpu memory regions in the rom definitions for that 0xffff + the banksize required

Ah right

[arcadez2003]

Here's a 78 driver with the pandora drawing im sorry but im too tired to paste in the diffs into that driver you sent me earlier oh and i had to use the older inputs as the game was locking into service on boot.

https://pastebin.com/eS5Ab7Hw

[arcadez2003]

Just like on my 84 driver there is a crash on level 2-3 on the second run through of the attract cycle

Some kinda address error by looks and those numbers remind me of.....

READ_HANDLER( pandora_spriteram_r ) { // it's either hooked up oddly on this, or ont the 16-bit games // either way, we swap the address lines so that the spriteram is in the same format offset = BITSWAP16(offset, 15,14,13,12, 11, 7,6,5,4,3,2,1,0, 10,9,8 );

After i took a pic due to the gamepad combo to do that the game coined and started you could see some gfx but that message you get if the flip screen is on Kaneko all rights reserved etc etc popped up which is strange as im telling the game not to flip as per the video drawing.....

flip_screen = 0; //hvyunit_vidreg & 0x10;

[mahoneyt944]

Sorry been outside all day cutting trees down. Looks like you're making progress though.

[arcadez2003]

Sorry been outside all day cutting trees down. Looks like you're making progress though.

Aye we're getting there i feel although maybe i'd have been better getting some fresh air today lopping a few tree's down than sitting testing Heavy unit all day :)

[arcadez2003]

Right i've noticed the vblank settings change the attract mode behaviors here are the values in the driver from MAME141 and their corresponding values in 78/84.....

MDRV_SCREEN_VBLANK_TIME(ATTOSECONDS_IN_USEC(0))

usually you'll find drivers with the above are either.....

MDRV_VBLANK_DURATION(DEFAULT_REAL_60HZ_VBLANK_DURATION) MDRV_VBLANK_DURATION(DEFAULT_60HZ_VBLANK_DURATION)

Although i've seen these used on occasion

MDRV_VBLANK_DURATION(TIME_IN_USEC(0)) MDRV_VBLANK_DURATION(0)

MDRV_QUANTUM_TIME(HZ(6000))

would be

MDRV_INTERLEAVE(100)

certainly MDRV_VBLANK_DURATION(DEFAULT_REAL_60HZ_VBLANK_DURATION) MDRV_INTERLEAVE(100) seems to make the game perform better well with the above it doesn't crash on that level until the second cycle

[arcadez2003]

Ill need to see how this core is handling banking as its not working as expected. Ill check the 142u2 code on mame2010 to see if it runs are you having issues on mame089 with the banking as well?

we certainly should be mapping 0x10000 ( above the normal memory range 0 - 0xffff) on this core if the banks above the banked mapped range

Yeah looking at most of the banking it's way more involved than later MAME some other kaneko games may offer a clue or two certainly Air Buster and Sand Scorpian are real close to Heavy Unit but not close enough otherwise the banks for those games would have worked here.

searching for &ROM or &RAM in the drivers will bring up plenty of results with regards to 78/84 banks and how they're handled i've tried a few today but with no joy as yet.

[MistyDreams]

the gfx drawing is big improvement. mame2010 libretro (mame 0139) draws properly its probably a good idea to test your video code there to see if its that or something else

[arcadez2003]

Ok been comparing the attract mode for the game using FBN vs what we have every level seems fine the enemies are present and correct and the behavior is spot on that's to say there is variation in firstly the duration of the levels and at what point the ship get's hit by a bullet or bumps into an enemy.

Level 3-2 seems the only one that's incorrect on first run a robot should shoot down the ship pretty early on while on the second run through the ship should beat that robot and carry on until the levels boss before being shot down.

in my driver that robot is always missing and the attract carrys on until the ship hit's a bubble later on on first run and the game crashes in that spot on the second cycle just before the boss. so im thinking is this a gfx issue or banking.??

I can certainly look at my code again to make sure i made no mistakes when porting across the pandora gfx from MAME117.u1 i dont think i did plus i've checked it previously, i also looked into the pandora drawing when the game was first made playable and checked every commit going backwards i dont see anything extra or anything fixed between 117 and 141 sure they made it a device and that changed how they handle it in the driver but that should not affect anything with regards to our driver.

I still think the weird stuff going on is banking related

[arcadez2003]

the gfx drawing is big improvement. mame2010 libretro (mame 0139) draws properly its probably a good idea to test your video code there to see if its that or something else

All i can test is on the xbox hence i asked ya's for help as you guys have access to and can compile more cores, not ideal i know but together thanks to your advice around the ram sharing the game is nearly there maybe with the correct banking it'll be good to go.

Of course maybe it's got nothing to do with the banking i'll certainly look at the gfx code again

[arcadez2003]

Strange things happening im still messing about with the code changing up the sharing a little.....

AM_RANGE(0xe000, 0xffff) AM_READ(sharedram_r)
AM_RANGE(0xe000, 0xffff) AM_WRITE(sharedram_w) AM_BASE(&sharedram)

AM_RANGE(0xe000, 0xffff) AM_READ(MRA8_RAM)
AM_RANGE(0xe000, 0xffff) AM_WRITE(MWA8_RAM) AM_BASE(&sharedram)

MRA rams doesn't work on the first so i tried it on the second and i get this now.......

so i added flip_screen = 0; to the video update call and still it happens crazy shit :) this is due to the lack of a cocktail mode in the driver if you turn on flip screen in the dips the game will bootup with that message and not start at all but why is it doin it in game if i change up the sharing.?? and on that level as well the mind boggles.

[arcadez2003]

Still dabbling not really getting anywhere but still you learn stuff like some banks are happy with just a read while others want a write be it RAM ROM or the same bank address like BANK1

for this game AM_RANGE(0x8000, 0xbfff) AM_WRITE(MWA8_ROM) or RAM or BANK1/2/3 the attract is like i explained beforehand but remove those writes on the bank address and bingo that flip screen message pops up.

Useless here but knowing this might come in handy for another time another driver :)

[MistyDreams]

havent had time to completely look at this banking is strange. Ive simplified the code.

static WRITE_HANDLER( master_bankswitch_w )
{
    int bank = data & 7;

    cpu_setbank( 1, memory_region(REGION_CPU1) + (bank * 0x4000) );
}
works

static WRITE_HANDLER( master_bankswitch_w )
{
    int bank = data & 7;

    cpu_setbank( 1, memory_region(REGION_CPU1) + 0x10000 + (bank * 0x4000) );
}
doesnt (at least not on the first demo  screen parts are missing)

there must be something else going on with the banks because mra_bank1 is remaped with setbank

flip_screen in this core should be renamed to flippy_screen or something as flip_screen is a global pointer for mame internal rotation. I found this out when working on radarscp

try below as i dont trust the mcu sim. set the rom region to 40000

cpu_setbank( 1, memory_region(REGION_CPU1) + 0x10000 + (bank * 0x4000) );

can you paste your 84 driver so i can test it on mame0139

[arcadez2003]

https://pastebin.com/abav5HxN

[arcadez2003]

MAME84 has a hybrid style of banking handling you can still use the older hookups with some newer ones unavailable to this one, let's look at Air Buster the driver was updated around MAME90 and they switched to the newer banking........

MAME78

this bank is copied three times and loaded via READ MRA_BANK1/2/3 with no writes

if ((data & 7) <  3)    RAM = &RAM[0x4000 * (data & 7)];
else                    RAM = &RAM[0x10000 + 0x4000 * ((data & 7)-3)];

cpu_setbank(1,RAM);

MAME90 they switched to newer style

one bank and the others copy it with extra code for gfx etc etc if required

static void airbustr_bankswitch(int cpunum, int data) { UINT8 *ROM = memory_region(REGION_CPU1 + cpunum);

if ((data & 0x07) <  3)
    ROM = &ROM[0x4000 * (data & 0x07)];
else
    ROM = &ROM[0x10000 + 0x4000 * ((data & 0x07) - 3)];

cpu_setbank(cpunum + 1, ROM);

}

static WRITE8_HANDLER( master_bankswitch_w ) { airbustr_bankswitch(0, data); }

static WRITE8_HANDLER( slave_bankswitch_w ) { airbustr_bankswitch(1, data);

flip_screen_set(data & 0x10);

}

static WRITE8_HANDLER( sound_bankswitch_w ) { airbustr_bankswitch(2, data); }

loaded via AM_RANGE(0x8000, 0xbfff) AM_ROMBANK(1) /2/3

With this in the MACHINE_INIT

master_bankswitch_w(0, 0x02); slave_bankswitch_w(0, 0x02); sound_bankswitch_w(0, 0x02);

[arcadez2003]

Well this works in the sense it's as we were that robot is still missing on 3-2

static void hvyunit_bankswitch(int cpunum, int data) { UINT8 *ROM = memory_region(REGION_CPU1 + cpunum);

if ((data & 0x07) <  4)
ROM = &ROM[0x4000 * (data & 0x07)];
else
ROM = &ROM[0x10000 + 0x4000 * ((data & 0x07) - 4)];

cpu_setbank(cpunum + 1, ROM);

}

static WRITE8_HANDLER( master_bankswitch_w ) { hvyunit_bankswitch(0, data); }

static void hvyunit_bankswitch2(int cpunum, int data) { UINT8 *ROM = memory_region(REGION_CPU1 + cpunum);

if ((data & 0x03) <  3)
ROM = &ROM[0x4000 * (data & 0x03)];
else
ROM = &ROM[0x10000 + 0x4000 * ((data & 0x03) - 3)];

cpu_setbank(cpunum + 1, ROM);

}

static WRITE8_HANDLER( slave_bankswitch_w ) { hvyunit_bankswitch2(1, data);

port0_data = data; flipscreen = data & 0x10; // probably.. tilemap_set_flip(ALL_TILEMAPS,flipscreen ? (TILEMAP_FLIPY | TILEMAP_FLIPX) : 0);

}

static WRITE8_HANDLER( sound_bankswitch_w ) { hvyunit_bankswitch2(2, data); }

And i got to near the end of level 2-1 before it locked up so progress or not depends on how you look at it :)

[MistyDreams]

ok here is the fix for this core. I hacked the mcu to play the attract a little longer(its fails at the same point with and without the mcu changes just better attract viewing enjoyment).

hvyunit.zip

bank3 is causing the issues 0xc000 + 0x3fff (0xffff) so i had to remap anything that read from that base.

I cant really help with 084 unless I seethe driver setup

[arcadez2003]

Ok thanks i'll try it now if the issues are sorted and indeed were caused by banking troubles the code should easily port across to my MAME driver without too much hastle fingers crossed

[arcadez2003]

Ok that robot enemy is now there i'll port across your banking changes to MAME84 and we'll see how it looks i suspect the problems might well be sorted now

[MistyDreams]

I think its worth mentioning I changed the vblank from what you had so we get 240 scan lines. The other way gave us 224 scan lines in the core. Pretty sure this should do the trick for these ole cores. Im surprised there is no set pointer in mame084. Im assuming havent checked.

[arcadez2003]

Ok everything seems fine now well with the attract mode at any rate the behaviors are correct and the game no longer crashes, great job you did on this im not shy to say i'd never have sussed this on my own, all that remains is to give it a playthrough all the way to the end but im confident that there will be no problems.

This is the driver i plan to port across to AdvanceMAME sometime down the road as it would be a shame to keep this only for own build to use it here we'd need the I8051 cpu core. hvyunit.zip

[MistyDreams]

Well always happy to help with other ports as well. Sorry it took a minute had a few things needing done hope the testing goes well.

[arcadez2003]

Well always happy to help with other ports as well. Sorry it took a minute had a few things needing done hope the testing goes well.

Yeah everything seems fine i've got further than before level 4-1 and didn't bump into any issues it's rock hard though and with these types games there is no bomb your way outta trouble with more practice and an easier version of the game maybe i'll complete it.

[arcadez2003]

@MistyDreams https://github.com/alessioscand/advancemame/pull/9/commits/33060734aafd074c38d9c9006786bd752a4a73d5

[MistyDreams]

youll need to add +1 to all the arrays added just notice each ones a byte short. I need to remember to count from zero! 0 - 7ff is actually 800 ect

[arcadez2003]

Can you explain further bigman my heids tired :)

[MistyDreams]

basically just add +1 to them. Thanks for the creds was no need you done the work on it i just changed the banking. Job well done!

char master_ram[0xfff+1];
char sl_ram[0xd7ff - 0xd200+1];
char sl_ram2[0xdfff - 0xda00 +1];
char snd_ram[0x7ff +1];

[arcadez2003]

Right bigman will do and as for credits without your input the game would still be broken to me that is something more than worth a credit or two :)