Cotton Sound

[arcadez2003]

Well i cant get the newer rewritten upd7759 to play nice in the ole system16.c driver the music and sfx is fine but anything via the upd is silent, the update is pretty simple for all of the drivers connected to that soundcore but as things tend to go the changes in segas16b are more complex.

When i did this update on the xbox it wasn't a problem as i had the segas16b driver to begin with and i simply created a seperate standalone version of the newer upd7759 which i use for sgeas16b and i kept the original soundcore for all the other drivers.

Why did i do that.?? well beacuse im lazy and couldn't be bothered to test 100's of games afterwards :) but i got the result i was looking for namely Cotton playable with full sound basically.

Anyway as it stands the sound problems will remain for Cotton we have several options i suppose.......

A) update the upd7759 and hopefully suss how to hook it up correctly to all the drivers affected and in time test all the games connected to this to make sure there is no breakage.

B) create a sound banking hack which will hopefully fix the sound in Cotton

Alien Syndrome has one for use with the older version of the upd7759 without it the sound is busted, currently we have Cotton using it and the sound and music work to an extent before cutting out maybe with the correct banking address calls that will sort it.??

C) if all else fails we could always just do what i did create a standalone version of the newer upd7759 and use it for just Cotton.

There are always multiple paths to the same destination :)

Here is link to MAME92 on the git which makes it easy to track all the changes with regards to the soundcore and the drivers and src files affected https://github.com/mamedev/historic-mame/commit/1cd2b6280ac28fbcdc4ee590a8c0c909a06a851c#diff-c2c7e1250cec50a00f8907735f750aa4040f2493e5721a693ce1051fedfa6193

[arcadez2003]

Here is option C the lazy option :)

As things stand music and sfx work if you coin up and start but leave it to cycle the attract mode then no sound once you coin it, equally do an ingame reset and no sound, no UPD7759 sounds whatsoever as yet check the banking upd7759b_control_w in segas16b

i've likely made a mistake adding the code to the ole driver although it looks correct to me FUI UPD7759 sounds in this game that i know about are.....

Coin Scream when killed Similar sound to above when unleashing the powerups hold A for that

upd7759b for Cotton.zip

All the files you need to hook this up are in the zip i used @MistyDreams latest WIP driver and only cotton uses this.

Topical point some of the bricks dropped when you kill an enemy can be shot to make em cycle through powerups and or experience try it but shot em too much and you can miss the powerup your after personally i like the blue ones :)

[MistyDreams]

To be honest I havent played this game before it does play nice though! ill give the ole sounds a spin. I had planned to do some more coding than I done today but the ole ball in chain had other ideas. Great work on doing the sound wasnt expecting anything for a while to be honest. I wondering if it would be worth adding the original afighers cause i cant be arsed doning the analog controls haha

[MistyDreams]

still getting them unmapped memory writes (8000- F7FF ) no extra sounds maybe its just me that missed something i did add it to my branch

[MistyDreams]

even without this fix and with it the only music i get is on the title screen the its all stops everything once i coin upand start the game

[arcadez2003]

Daft question you did add the upd7759b calls to your system16.c driver.?? as i dont see em in this commit.... https://github.com/MistyDreams/mame2003-plus-libretro/commit/cc5bc7558cb21a66c863affbca8d6b29a4286b48

The driver i sent last night included the extra hookups for the new soundcore only Cotton uses em

[MistyDreams]

ill re check thought i added it all had a moaning woman wanting to go to garden center yesterday and what did she get nothing! you right sound indeed is working sorry about that.

[MistyDreams]

looks like bullet might need this fix as well. I done the inputs for bullet and fixed the dip switch reading order was returning the wrong order in the standard io r. Will sort cottons inputs next going to watch some tv for a bit.

[arcadez2003]

This still needs some work there are no UPD7759 sounds in Cotton and likely any other games you hookup will be the same it's prob something i missed in segas16b but as yet cant spot what it is.

As for Cotton inputs and dips i have those done and confirmed to be working you can pull em from this if you want......

static MEMORY_READ16_START( cotton_readmem )

{ 0x601002, 0x601003, input_port_0_word_r }, // player1
{ 0x601004, 0x601005, MRA16_NOP },
{ 0x601006, 0x601007, input_port_1_word_r }, // player2
{ 0x601000, 0x601001, input_port_2_word_r }, // service
{ 0x602002, 0x602003, input_port_3_word_r }, // dip1
{ 0x602000, 0x602001, input_port_4_word_r }, // dip2
{ 0xffc000, 0xffffff, SYS16_MRA16_WORKINGRAM },

INPUT_PORTS_START( cotton ) SYS16_JOY1 SYS16_JOY2 SYS16_SERVICE SYS16_COINAGE

PORT_START / DSW1 / PORT_DIPNAME( 0x01, 0x00, DEF_STR( Demo_Sounds ) ) PORT_DIPSETTING( 0x01, DEF_STR( Off ) ) PORT_DIPSETTING( 0x00, DEF_STR( On ) ) PORT_DIPNAME( 0x02, 0x02, DEF_STR( Unknown ) ) PORT_DIPSETTING( 0x02, DEF_STR( Off ) ) PORT_DIPSETTING( 0x00, DEF_STR( On ) ) PORT_DIPNAME( 0x04, 0x04, DEF_STR( Unknown ) ) PORT_DIPSETTING( 0x04, DEF_STR( Off ) ) PORT_DIPSETTING( 0x00, DEF_STR( On ) ) PORT_DIPNAME( 0x06, 0x06, DEF_STR( Lives ) ) PORT_DIPSETTING( 0x04, "2" ) PORT_DIPSETTING( 0x06, "3" ) PORT_DIPSETTING( 0x02, "4" ) PORT_DIPSETTING( 0x00, "5" ) PORT_DIPNAME( 0x08, 0x08, DEF_STR( Unknown ) ) PORT_DIPSETTING( 0x08, DEF_STR( Off ) ) PORT_DIPSETTING( 0x00, DEF_STR( On ) ) PORT_DIPNAME( 0x10, 0x10, DEF_STR( Unknown ) ) PORT_DIPSETTING( 0x10, DEF_STR( Off ) ) PORT_DIPSETTING( 0x00, DEF_STR( On ) ) PORT_DIPNAME( 0x18, 0x18, DEF_STR( Difficulty ) ) PORT_DIPSETTING( 0x10, "Easy" ) PORT_DIPSETTING( 0x18, "Normal" ) PORT_DIPSETTING( 0x08, "Hard" ) PORT_DIPSETTING( 0x00, "Hardest" ) PORT_DIPNAME( 0x20, 0x20, DEF_STR( Unknown ) ) PORT_DIPSETTING( 0x20, DEF_STR( Off ) ) PORT_DIPSETTING( 0x00, DEF_STR( On ) ) PORT_DIPNAME( 0x40, 0x40, DEF_STR( Unknown ) ) PORT_DIPSETTING( 0x40, DEF_STR( Off ) ) PORT_DIPSETTING( 0x00, DEF_STR( On ) ) PORT_DIPNAME( 0x80, 0x80, DEF_STR( Unknown ) ) PORT_DIPSETTING( 0x80, DEF_STR( Off ) ) PORT_DIPSETTING( 0x00, DEF_STR( On ) ) INPUT_PORTS_END

[arcadez2003]

Notice the romboard types the banking is different for certain ones at the moment we're using a stripped down version just for Cotton it wont be correct for Bullet...........

static WRITE8_HANDLER( upd7759b_control_w ) { int size = memory_region_length(REGION_CPU2) - 0x10000; if (size > 0) { int bankoffs = 0;

    /* it is important to write in this order: if the /START line goes low
       at the same time /RESET goes low, no sample should be started */
    upd7759b_start_w(0, data & 0x80);
    upd7759b_reset_w(0, data & 0x40);

    /* banking depends on the ROM board */
    switch (rom_board)
    {
        case ROM_BOARD_171_5358:
        case ROM_BOARD_171_5358_SMALL: // Bullet Alien Syndrome etc etc
            /*
                D5 : /CS for ROM at A11
                D4 : /CS for ROM at A10
                D3 : /CS for ROM at A9
                D2 : /CS for ROM at A8
                D1 : A15 for all ROMs (Or ignored for 27256's)
                D0 : A14 for all ROMs
            */
            if (!(data & 0x04)) bankoffs = 0x00000;
            if (!(data & 0x08)) bankoffs = 0x10000;
            if (!(data & 0x10)) bankoffs = 0x20000;
            if (!(data & 0x20)) bankoffs = 0x30000;
            bankoffs += (data & 0x03) * 0x4000;
            break;

        case ROM_BOARD_171_5521:
        case ROM_BOARD_171_5704_EXTRA_RAM:  // Cotton Fantasy Zone II etc etc
            /*
                D5 : Unused
                D4 : Unused
                D3 : ROM select 0=A11, 1=A12
                D2 : A16 for all ROMs
                D1 : A15 for all ROMs
                D0 : A14 for all ROMs
            */
            bankoffs = ((data & 0x08) >> 3) * 0x20000;
            bankoffs += (data & 0x07) * 0x4000;
            break;

        case ROM_BOARD_171_5797:
            /*
                D5 : Unused
                D4 : A17 for all ROMs
                D3 : ROM select 0=A11, 1=A12
                D2 : A16 for all ROMs
                D1 : A15 for all ROMs
                D0 : A14 for all ROMs
            */
            bankoffs = ((data & 0x08) >> 3) * 0x40000;
            bankoffs += ((data & 0x10) >> 4) * 0x20000;
            bankoffs += (data & 0x07) * 0x04000;
            break;
    }
    cpu_setbank(1, memory_region(REGION_CPU2) + 0x10000 + (bankoffs % size));
}

}

I thought this would be enough but maybe not.?? search for rom_board in your segas16b driver and you'll see there is alotta code connected to the UPD7759 banking calls i had to leave out as i simply did not know how to implement it in our ole driver.

static WRITE_HANDLER( upd7759b_control_w ) { int size = memory_region_length(REGION_CPU2) - 0x10000; if (size > 0) { int bankoffs; / it is important to write in this order: if the /START line goes low at the same time /RESET goes low, no sample should be started / upd7759b_start_w(0, data & 0x80); upd7759b_reset_w(0, data & 0x40);

// cotton banking correct.?? bankoffs = ((data & 0x08) >> 3) 0x20000; bankoffs += (data & 0x07) 0x4000;

    cpu_setbank(1, memory_region(REGION_CPU2) + 0x10000 + (bankoffs % size));
}

}

[MistyDreams]

will need looked into but looks like the alienfix should work for bullet! At saying that at least there is sound now

[arcadez2003]

Aye i used that for Bullet and the game seems fine soundwise

[MistyDreams]

yea the sound seems fine getting unmapped memory reads though . Never mind me like a true idiot bullet is fine is added the wrong driver machine init so edited this post.

@arcadez2003 you said you had cotton working on you mame084 port can you confirm the sound readmem and writemem are the same as ours on the new core you made.

will stick to cotton cause bullet is fine

the sound rom load we have is

    ROM_REGION( 0x50000, REGION_CPU2, 0 ) // sound CPU
    ROM_LOAD( "epr-13892.a10", 0x00000, 0x08000, CRC(fdfbe6ad) SHA1(9ebb94889c0e96e6af9cdced084804ca98612d61) )
    ROM_LOAD( "opr-13893.a11", 0x10000, 0x20000, CRC(384233df) SHA1(dfdf94697587a5ee45e97700f3741be54b90742b) ) 

[libretro DEBUG] (logerror) upd7759b_control_w 00010000
[libretro DEBUG] (logerror) upd7759b_control_w 00020000
[libretro DEBUG] (logerror) upd7759b_control_w 00024000

[arcadez2003]

Yip that is the sound rom loading i have, i noticed this right enough......

define ROM_BOARD_171_5521 (2) / 171-5521 /

define ROM_BOARD_171_5704 (2) / 171-5704 - don't know any diff between this and 171-5521 /

Cotton uses this generic_5704 driver init call but there is no hookup for that in the upd7759b_control_w

        case ROM_BOARD_171_5521:
        case ROM_BOARD_171_5704_EXTRA_RAM:
            /*
                D5 : Unused
                D4 : Unused
                D3 : ROM select 0=A11, 1=A12
                D2 : A16 for all ROMs
                D1 : A15 for all ROMs
                D0 : A14 for all ROMs
            */
            bankoffs = ((data & 0x08) >> 3) * 0x20000;
            bankoffs += (data & 0x07) * 0x4000;
            break;

Although i assume since these calls share the same case values in this instance (2) the banking above is correct for Cotton.?? and are being hookedup via 171_5521

define ROM_BOARD_171_5521 (2)

define ROM_BOARD_171_5704 (2)

[MistyDreams]

is your port on github?

[arcadez2003]

is your port on github?

Nah the xbox MAME ports were created long before github was even heard of, however if you want a copy of my Src you need only ask.

[MistyDreams]

just the system16 sources thats all i need to look at machine drives and video its just to match the memory maps

[arcadez2003]

It's easier to just send the full shebang.......

https://www.sendspace.com/file/y5trtl

[MistyDreams]

thanks for that. Once the sound is fixed cottons good to go as well its a lot better than it was though. bullets running fine too. i might just do afighter if its not protected cba doing the analog stuff but the game does work.

[MistyDreams]

ps only reaction i got was was 82 in the sound test think it was. which means the rest of then aint even triggering

retroarch: symbol lookup error: /home/misty/Source/mame2003-plus-libretro/mame2003_plus_libretro.so: undefined symbol: update_adpcm

[MistyDreams]

had a look seems like slave mode is causing the sound loss which your core is set too. if you put memory region in its fine but you loose the samples like you have it. the porting looks ok to me only changes that are needed is in the interface ill. Honestly am at a loss with this one the aliensyn works at least plays the right samples but messes up on game over sound has to be something simple we are missing suppose live without samples for now.

[MistyDreams]

static data16_t unmapped_memory_r(void)
{
    static int recurse = 0;
    data16_t result;

    /* Unmapped memory returns the last word on the data bus, which is almost always the opcode */
    /* of the next instruction due to prefetch; however, since we may be encrypted, we actually */
    /* need to return the encrypted opcode, not the last decrypted data. */

    /* Believe it or not, this is actually important for Cotton, which has the following evil */
    /* code: btst #0,$7038f7, which tests the low bit of an unmapped address, which thus should */
    /* return the prefetched value. */

    /* prevent recursion */
    if (recurse)
        return 0xffff;

    /* read original encrypted memory at that address */
    recurse = 1;
    result = program_read_word_16be(activecpu_get_pc());
    recurse = 0;
    return result;
}

thats probable the issue!

[libretro DEBUG] [MAME 2003+] cpu #0 (PC=0001E6EC): unmapped memory word read from 007038F6 & 00FF

[arcadez2003]

Is that not for the FD1094 encryption.?? as you've seen there is alotta memory mapping tied into the rom region boardtype tables at the top of the driver which i think are used in part to handle the UPD7759 sound banking for the different games it looks kinda difficult to untangle all that for use in our driver.

The sound comes via the second CPU but i noticed they dont hook directly to it for the Sega games like they used to with regards to the earlier version of the UPD7759 soundcore.......

static struct upd7759b_interface upd7759b_interface = { 1, { UPD7759b_STANDARD_CLOCK }, { 48 }, { 0 }, / memory region 3 contains the sample data / { upd7759b_generate_nmi }, };

struct UPD7759_interface sys16_upd7759_interface = { 1, / 1 chip / { 60 }, / volumes / { REGION_CPU2 }, / memory region 3 contains the sample data / UPD7759_SLAVE_MODE, { sound_cause_nmi }, };

I guess the memory address mappers handle this now in segas16b.?? it might be worth adding the CPU call back in to see if that helps in any way.

static struct upd7759b_interface upd7759b_interface = { 1, { UPD7759b_STANDARD_CLOCK }, { 48 }, { REGION_CPU2 }, / memory region 3 contains the sample data / { upd7759b_generate_nmi }, };

Anyway dont knock yourself out over this we'll keep all the Sega games barring Cotton using the older version of the UP7759 and we'll just use the newer one for Cotton as the game does have sound and music using it which seems to be working well enough sure we'd like it 100% but we may just have to settle for 98% :)

[arcadez2003]

Maybe i should tried a couple more things to try and get cotton to play with our original UPD7759 before going down this path. @MistyDreams here is a copy of your latest WIP driver with the original soundcore hookup with a few extra diffs would you like to give it a quick whirl..?? it will be the last role of the dice more or less......

I would myself but since you've more or less got this wrapped up i deleted all my WIP cores and fired up LEGO Star Wars once again as i need a break from all this coding and testing ole age disnae come alone :) try this.zip

[MistyDreams]

ive tried different combos with the newcore. Not with the old though as it has a different user interface. Slave is set differently.

the code as is doesnt compile like you am done with it will put the old alien3 fix back in that plays the wrong samples as well! and call it sample free

[arcadez2003]

Yeah small mistake in that read it should have been

static READ_HANDLER( sys16_upd7759_status_r ) { return UPD7759_busy_r(0) << 7; }

I tried out the changes same as before with the ole soundcore the music and sfx cut out, like you im done now so i guess we'll use the UPD7759 for every game in system16.c and only use the UPD7759b for Cotton and mark the game as imperfect sound.

[MistyDreams]

well its up to @mahoneyt944 to deal with both games bullet and cotton are working apart from the sample glitches. either silent or garbled. its up to him how the libretro port deals with it

[mahoneyt944]

Can't see any harm in using UPD7759b /UPD7759 as separate designations. Ideally this reduces issues and having to test many games. Also the ability to cross test games in the future maybe useful.

[mahoneyt944]

PR these games and I'll get these merged into master.

[MistyDreams]

cant pr branches are too diverged would need done from scratch @arcadez2003 i think the issue is the lack of shared memory in this core

[MistyDreams]

very few games need the 7559 testing and converting should be simple enough

src/includes/system16.h:359:extern struct UPD7759_interface sys16_upd7759_interface;
src/includes/system16.h:360:extern struct UPD7759_interface aliensyn_upd7759_interface;
src/drivers/twin16.c:945:static struct UPD7759_interface upd7759_interface =
src/drivers/bladestl.c:430:static struct UPD7759_interface upd7759_interface =
src/drivers/mainevt.c:701:static struct UPD7759_interface upd7759_interface =
src/drivers/combatsc.c:656:static struct UPD7759_interface upd7759_interface =
src/drivers/tmnt.c:2437:static struct UPD7759_interface upd7759_interface =
src/drivers/segac2.c:4300:static struct UPD7759_interface upd7759_intf =
src/drivers/88games.c:284:static struct UPD7759_interface upd7759_interface =
src/drivers/prehisle.c:229:static struct UPD7759_interface upd7759_interface =
src/drivers/rpunch.c:608:static struct UPD7759_interface upd7759_interface =
src/drivers/snk68.c:802:static struct UPD7759_interface upd7759_interface =
src/sound/upd7759.c:118:    const struct UPD7759_interface *intf;
src/sound/upd7759.c:284:    const struct UPD7759_interface *intf = msound->sound_interface;
src/sound/upd7759.h:14:struct UPD7759_interface
src/machine/system16_machine.c:2205:struct UPD7759_interface sys16_upd7759_interface =

[mahoneyt944]

I'm not against converting but I also don't have time for testing right now. Typically that's where using it as "plug and play" for the games that need it is ideal but if either of you want to test every game that used the old sound and verify that the new sound is a good replacement, that's fine too. I have no idea how many of those games may or may not have "hacks" or volume adjustments to suit the old sound. TMNT is a game that I know did have tweaks, because there were user reported issues with volume levels for certain sounds throughout the game. So stuff like that would need sorted and a full playthrough to test for these areas.

As far as branches being too different from master, this is unavoidable...but I would recommend doing small incremental changes, PR them, and consistently sync with master before starting the next change. This is also ideal for testing purposes later when things get accidentally broken. We can back track the commit responsible.

[MistyDreams]

hmmm ill add the games at some point the sound hookup you can deal with that up to you how to deal with it.

[MistyDreams]

@arcadez2003 put a pr and closed it feel there is too much nit picking pitty cotton is a decent game wasted enough time on this . I defo would be interested in helping with your core if you have issues .

[MistyDreams]

@MistyDreams It is a pitty..... You created a PR which moved around initialized variables, which in turn, effects every game in the driver without testing the effect this might have on those games. Your PR created two machine drivers for cotton, one which was imported into the other, which makes no sense. You failed to deliberate about the PR in an open manor and ignored all feedback given. Expecting me or anyone else to finish the work done to a PR you've created is outrageous.

i did test moving the proc to init has no side effects in know the order of whats happening proof?

The sound is your choice as maintainer thats why i left the double framework for you so its quicker to implement arcaze2003 done something similar.

i closed the pr easier than expanding explanations to you.

[mahoneyt944]

Then why bother even moving it. All the other games are framed a certain way, why not follow that? That way there can be a future commit to just eliminate the machine inits or whatever else.... Make incremental changes that we can check against later if something breaks.

Make one commit to add the games, another to remove machine inits, another to test game by game going to the new drawing system etc etc. Incremental changes.....

[MistyDreams]

I never removed any machine inits what are you talking about what game is broken ill compile and test

[mahoneyt944]

Reference every other driver_init in the driver...the code you placed in your driver_inits, is typically in the machine_init for the other games. Which is why you had to move those initialized variables.

My point is to add the games in the format that's currently being used by the driver. Just the games, nothing else.

Then if you want to change the format, do it in another PR. Just the format, nothing else.

If you want to change a game to draw with the new format or something, do it in another PR. Etc etc.

Incremental changes. Which can be tested for faults easily.

[MistyDreams]

there are no faults it simple machine init comes before video init all video init does is wipe out the proc setting if you set it machine init no side effects to anything already setup. Your making little sense nothings broke ive tested this on my branch. Again point me all thees things that are supposed to be broke ill take a look ive compiled the pr. I seriously hope you not winding me up here.

[mahoneyt944]

I don't really care if we use machine_init or driver_init to initialize these, I'm just suggesting that we do all the games the same way so that there is consistency in the driver. I'm not indicating that doing it that way is wrong or breaking things, just that I think these should be in separate PRs. one to add the games and one to switch all the games to use driver init instead of machine init.

If it would be an easier solution, I can update all the games to use driver init then you can re-PR your branch.

[MistyDreams]

I dont see how that makes a difference nothing will be changed itll be the same. The other drivers are not effected anyway. I wont be submitting another pr to deal with non issues again sorry.

[arcadez2003]

Right for me less work is always more that's my whole lazy way of looking at things my advice with that in mind is.......

The Sega video code affects multiple drivers and a very high number of games, there has been some lovely work done backporting newer routines from Segas16B for use here in this core, but surely this video code can only be considered Wip and experimental at the moment.??

As a result IMO it's best to isolate it just now and only use it for the games that really require it, if im not mistaken that list is quite short eg Action Fighter, Bullet, Cotton, Fantasy Zone II, Tough Turf and Wrestle War, in time we can test more of the sys 16 games in depth to see if they benefit from using it and if so shift them across.

With regards to the UPD7759 sound core my advice is to leave the original sound core intact and hooked up to every driver that uses it, then either we can fix Cotton so it'll work with it or look at the alternative updated soundcore i created for my Xbox core just for use in Cotton and no other games unless we're willing to test everyone of them end to end back to front.

@MistyDreams did you say you got Cotton to work with the original sound core.??

These games are real classics and the goto's for alotta users of this core we cant have any breakage whatsoever thats my two cents on this hence my thought's around isolating the changes for now with a view to making them more permanent after a prope testing phase down the road.

[MistyDreams]

yea @arcadez2003 all your need to do is change the interupt line to if (chip) in machine/system16.c in the cause interrupt code but the old code not sure if that breaks any other game though runs out of sync with RA with the old core though

[mahoneyt944]

These games are real classics and the goto's for alotta users of this core we cant have any breakage whatsoever thats my two cents on this

Agreed, that's all I'm suggesting. Small changes so we can monitor for any issues.

[MistyDreams]

Agreed, that's all I'm suggesting. Small changes so we can monitor for any issues.

there are no big changes your making stuff up saying things are broke I move a set variable to zero to machine init where it should be.

[mahoneyt944]

I never said anything was broke. I said if things break later we can track it easier.

[mahoneyt944]

It's just good housekeeping

[MistyDreams]

@arcadez here is the pr he is moaning about https://github.com/libretro/mame2003-plus-libretro/pull/1376

[arcadez2003]

yea @arcadez2003 all your need to do is change the interupt line to if (chip) in machine/system16.c in the cause interrupt code but the old code not sure if that breaks any other game though runs out of sync with RA with the old core though

Then i'd isolate it just for Cotton until every game in System 16 has been tested with that change and if we cant be bothered testing them all just now "i know i cant my health has taken a turn for the worse again" then it's no problem really as every system 16 game will be fine in the sound dept in the mean time.

Dont think im nitpicking here or not trusting your changes that's my default position with my own code dont trust it until fully tested i know it's glass half full kinda thinking but hey what can i say it's just my life experiences playin out here :)

[MistyDreams]

oh did isolate cotton he complained about two inits left the path for him to update the audio see for yourself in the pr above honestly nothing breaking there I left it to him to sort the sound out left the foundation in so he could edit it as well. The fact is audio synchronizes ra and the old core messs up game speed bad unless your turn audio sync off that's why im leaving it to him.

[arcadez2003]

Right well i've stated my opinons rightly or wrongly depending on your viewpoint i suppose TBH it's something you'll both have to work out for yourselves TBH as im not really too well today so dont feel like trying to a middle man peacemaker :)