Closed vaguerant closed 2 years ago
Like wise this is probably
{ 0xfe0006, 0xfe0007, sound_command_w },
{ 0xfe0006, 0xfe0007, ww_io_service_r },
Yeah just giving my opinon is all :)
Let's hope the issue is confined to the driver as if we have to start looking at the different sprite calls this could become a nightmare Wrestle War uses Shinobi sprites there are other routines though for some of the different games they can be found in vidhrdw/sys16spr.c
Yeah hopefully not, what do you think about ww_io_service_r
in the reads. This function returns inputport2 | workingram. Seems odd to me. All the other io's use high values not at the sound address? (0xfe0006, 0xfe0007)
@arcadez2003 this should work without the wrestlewar init. None of the ports are confirmed (apart from input ) and banking needs looked at. I did mention all the ports need tested and checked as well as the video code. It not my maps its mame maps. The usual suspects mirroring and input ports and incompatible video code!
@MistyDreams we refer to "your maps" as the maps you shared with the group here. It's just a reference to which maps, not ownership.
@MistyDreams I'm a little confused as to what this read is doing. It references the service port (port 2)
{ 0xfe0006, 0xfe0007, ww_io_service_r }
But we are reading the service port here and this is confirmed to work without the above read
{ 0xc41000, 0xc41001, input_port_2_word_r }, // service
@arcadez2003 this should work without the wrestlewar init. None of the ports are confirmed (apart from input ) and banking needs looked at. I did mention all the ports need tested and checked as well as the video code. It not my maps its mame maps. The usual suspects mirroring and input ports and incompatible video code!
If your just posting up WIP and want to be left alone to work on this in your own time then that's all you have to say afterall too many cooks spoil the broth :) i was always solo when it came to my xbox projects apart from asking the FBN boys for the odd bit advice here and there.
I dont mind just dont commit to master till its done anyone can do anything in a branch no harm done else things get confusing its already done so knock yourselves out. I need to get up to speed on this driver anyhow its day and night compared to what im using atm
there is some ram not being read in the upper section will youll need to look into that as well
@mahoneyt944 I think your taking the meaning of input ports meaning for controls only
I know what ya mean in my xbox project i split the Sega code into two parts a best of both worlds kinda deal i kept the games that were fine grahically in system16.c and i created a new segas16b.c driver to support games that were either broken or were not supported in MAME84 as that is the MAME version we use..
So technically i have two Sega cores the one we use and another from MAME94 i run them side by side but alas we cannot do that here due to code inbalances, so yeah it's better to drop games into the drivers they were created for rather than attempt to shoehorn them into an older version.
But sometimes that is where the fun is ;)
Very true will look some avenues on my branch in time will tie in with you when i get some results. Need to look into sound latches ect as well codes full of workarounds confusing but fun
@MistyDreams
@mahoneyt944 I think your taking the meaning of input ports meaning for controls only
I'm not sure what you're replying to here. My comments about { 0xfe0006, 0xfe0007, ww_io_service_r }
? I was trying to see what this is actually doing since I can comment it out without any noticable differences while testing. So if it's actually doing something, I was curious as to what? Just making sure this line is doing what it's intended to.
@mahoneyt944 you can drop it isint needed & arcadez think i found the issue its the tile banking
Ah i was starting to wonder if it was the tile layer that handled that rather than the sprites well it's good your onto the issue
Ok. I'm stepping away for a bit. Bbl
@arcadez2003
{ 0xc40000, 0xc40001, sys16_coinctrl_w },
need to find out what this is out putting and fix it per what happens here to our equiv think thats our issue after looking about
Sure i can look into it no problem but maybe not until the weekend got a lot on this week
This game might have two tile banks where as Wrestlewar only has one if you do this certainly the bug @mahoneyt944 was talking about during the attract mode is gone but we're still missing the shop options on the left side of the screen
//set_tile_bank( sys16_extraram[1] );
sys16_tile_bank0 = sys16_extraram[0]&0xf;
sys16_tile_bank1 = sys16_extraram[1]&0xf;
I hooked it off toryumon DRIVER and MACHINE init's that's to say it's video code the game seems to work with it same deal as above though we're still missing some of the shop options
I did add some notes on my findings let me get the link. I need to make notes or i forget what ive done lol
https://github.com/MistyDreams/mame2003-plus-libretro/blob/88a41ea5b2dfff2fc2bd1e39a150f904cdf0ac51/src/drivers/system16.c#L6847-L6863and like a real pro i copied the wrong initi for the notes haha will fix.
****fixed
@MistyDreams @arcadez2003 I was playing with the inits last night. Probably need to look through what we actually need. This seemed to be more or less the same as what we get using wrestwar inits. Could probably make a fantzn2_update_proc
with the correct banking too
static MACHINE_INIT( fantzn2x )
{
sys16_update_proc = wrestwar_update_proc;
sys16_wwfix = 1;
}
static DRIVER_INIT( fantzn2x )
{
machine_init_sys16_onetime();
}
Could probably make a
fantzn2_update_proc
with the correct banking too
where are you going to get this information ? how did you get it for wrestle wars?
@arcadez2003 its fine refreshable is updated in the coin read the notes above say where the problem happens
I was just testing different inits out and then started stripping back wrestwar to see what changes occured. I tested out some different proc's from our driver and found that most use a similar formula but with slight tweaks for each game. set_tile_bank( sys16_extraram[1] )
is important for our code to work, but as arcadez mentioned might need modified some. sys16_extraram[1]
seems to be the title screen sprites that are bugged out. sys16_extraram[0]
seems to be the background in game
@mahoneyt944 we know what wrestle wars is doing you need to keep in mind ww is system16b_i8751 and fz2 is system16c can try blind that does work sometimes
@arcadez2003 its fine refreshable is updated in the coin read the notes above say where the problem happens
Yeah i was looking at the link you sent last night im my ole segasb it would be
if (!disable_screen_blanking) system16b_set_draw_enable(data & 0x20);
here as you said
sys16_refreshenable = coinctrl & 0x20;
Since i didn't have much time today i thought i'd look at the tiles :) anyway seems like your on top of things.
I noticed something there the text ram is extended in wrestlewars lemme try something. Well its fixes the segfault extending it but doesnt help the issue need to find the proper values for our video code.
@mahoneyt944 this is the map for ww
080000-0BFFFF ROM
100000-10FFFF RAM(tileram)
110000-110FFF RAM(textram)
200000-2007FF RAM(sprites)
300000-300FFF paletteram_w
400000-40FFFF rom_5704_bank_w
C40000-C43FFF standard_io
FF0000-FF3FFF RAM(workram)
edit change the last one to FF0000-FFFFFF I went and done teh decrypted rom version
there are also glitches in wrestle fest at times think the video code needs updates and youll need to keep the textram size else youll get a segfault from the same code that causes it on fantnz2x from the code going too far in the array
I've been testing this https://github.com/libretro/mame2003-plus-libretro/compare/T2
Seems like everything is working except the missing sprites on the upgrade parts screen. Though I haven't looked for overflows.
seesh your patient.
did you go through all the options here?
sys16_textram:
type1 type0 function
---------------------------------------
0x74f 0x740 sys16_fg_page
0x74e 0x741 sys16_bg_page
0x742 sys16_fg2_page
0x743 sys16_bg2_page
0x792 0x748 sys16_fg_scrolly
0x793 0x749 sys16_bg_scrolly
0x74a sys16_fg2_scrolly
0x74b sys16_bg2_scrolly
0x7fc 0x74c sys16_fg_scrollx
0x7fd 0x74d sys16_bg_scrollx
0x74e sys16_fg2_scrollx
0x74f sys16_bg2_scrollx
0x7c0..0x7df sys18_splittab_fg_x
0x7e0..0x7ff sys18_splittab_bg_x
No I did not test other options yet.
In regards to your demeanor, you asked that other developers not push to master and work on things in separate branches until a group consensus was made. I shared my branch with the group, which is working better than the current master is, though with some issues to sort still.
I'm going to remind you that LibRetro will not stand for inappropriate behavior towards other developers.
I'm going to remind you that LibRetro will not stand for inappropriate behavior towards other developers.
what ?
Now kiss
Lol we're just gonna be a couple of Fonzies around here 😂
@arcadez2003 ill update you on the megaplay thing with an @ from my github if i find anything.
@mahoneyt944
set_fg_page( sys16_textram[0x740] );
set_bg_page( sys16_textram[0x741] );
//set_fg_page1( sys16_textram[0x742] );
//set_bg_page1( sys16_textram[0x743] );
sys16_fg_scrolly= sys16_textram[0x748];
sys16_bg_scrolly= sys16_textram[0x749];
sys16_fg2_scrolly= sys16_textram[0x74a];
sys16_bg2_scrolly= sys16_textram[0x74b];
sys16_fg_scrollx= sys16_textram[0x74c];
sys16_bg_scrollx= sys16_textram[0x74d];
sys16_fg2_scrollx= sys16_textram[0x74e];
sys16_bg2_scrollx= sys16_textram[0x74f];
sys18_splittab_fg_x= &sys16_textram[0x7c0];
sys18_splittab_bg_x= &sys16_textram[0x7e0];
//set_tile_bank( sys16_extraram[1] );
sys16_tile_bank0 = sys16_extraram[0]&0xf;
sys16_tile_bank1 = sys16_extraram[1]&0xf;
will get your closer.
@m4xw not sure what ive actually done for that comment but ill refrain from participating here have enough drama in my life with the wife lol.
Ok clean slate here,
The T2 branch isolates the machine and driver init as well as creates a fantzn2x_update_proc that has modified tile banking. This seems to fix all the graphic issues that were happening on the demo screens but does not fix the missing sprites on the parts upgrade screen.
I think isolating this game in this manor is a good idea though
set_fg_page( sys16_textram[0x740] ); set_bg_page( sys16_textram[0x741] ); //set_fg_page1( sys16_textram[0x742] ); //set_bg_page1( sys16_textram[0x743] ); sys16_fg_scrolly= sys16_textram[0x748]; sys16_bg_scrolly= sys16_textram[0x749]; sys16_fg2_scrolly= sys16_textram[0x74a]; sys16_bg2_scrolly= sys16_textram[0x74b]; sys16_fg_scrollx= sys16_textram[0x74c]; sys16_bg_scrollx= sys16_textram[0x74d]; sys16_fg2_scrollx= sys16_textram[0x74e]; sys16_bg2_scrollx= sys16_textram[0x74f]; sys18_splittab_fg_x= &sys16_textram[0x7c0]; sys18_splittab_bg_x= &sys16_textram[0x7e0]; //set_tile_bank( sys16_extraram[1] ); sys16_tile_bank0 = sys16_extraram[0]&0xf; sys16_tile_bank1 = sys16_extraram[1]&0xf;
@MistyDreams this seems to do weird things to the image
Merged https://github.com/libretro/mame2003-plus-libretro/commit/f481abe0b07b1c628b4339b70a4a2e4816a89159 since this seems to be the best version we have so far. Hopefully we can solve the last missing sprite in a future commit.
I think I see what's going on here. On the left side of the screen the sprites get cut off before going off the screen, so there's a dead zone. The sprites should travel to the last pixel of the sprite not just disappear. This issue does not occur on the right side of the screen. I'm guessing that the upgrade parts screen is missing the left 2 sprites because they are in this dead zone.
See FBN for reference on the red guys
Our red guy sprite splits just before it disappears. Most just disappear before the edge of the screen. But he is a little wider up top lol
If you drop the cpu clock scale in core options to 25%, the game runs at snail speed. Go to the top of the screen and face to the right. You'll be able to see the dead zone on the left side pretty easily.
I started to look at some of the sprite offsets last night as certain games in the driver use em ,quite a few of these right enough but this one is the most common
sys16_sprxoffset = -0xbc;
Then there's this only two values are used 0x8000 or the one below sys16_spritelist_end=0xc000;
I've not tried any of these out yet though but any one of them could solve the problem.??
I don't believe it's the sprxoffset, tested this already, our sprite offset is in sync with FBN so I feel pretty good about that. Though I guess if it's combined with other configurations then maybe.
Also tried altering the fgxoffset without any luck, but you may want to experiment with this still.
I did not test sys16_spritelist_end. I'm not sure what this is tbh, though I think the sprites are fine just getting cut off too early. If we had a sprite that was missing features id think otherwise.
I also believe the mem maps addresses to be correct as well.
So I'm out of ideas but I feel this is probably one of those one liner fixes. Just can't seem to get it. :(
Maybe a fg priority and/or priority mode?
Sprite wrapping is the issue im told we'll likely need to look beyond the driver into the system16 video or sys16spr.c :(
should we be using the system18 video though? We are using the system16 one atm looking at the code video code
should we be using the system18 video though? We are using the system16 one atm looking at the code video code
Worth testing out if you can get it to display right in this mode. When I tried, I was getting squished / stretched graphics. I believe system18 is using fg2 and bg2, which I don't think we need for this game but not sure.
Sprite wrapping is the issue im told we'll likely need to look beyond the driver into the system16 video or sys16spr.c :(
I don't have much experience fixing such things. I'm assuming wrapping occurs when you fill up a region? If so maybe we can hack-ily extend the region?
ok tested results are good is on my branch if you want to cherry pick bits the background moments there as well ill look at wrestle fest next.
Dont know if we need to set the second page will look at the code when i have more time as the code for setting pages looks like its being tailed for certain games so will need to make sure i look at it propperly
Ok I grabbed the system18 bits into the fant branch here to test. It seems to behave in the same manor though with the deadzone present. Is this the case for your branch as well?
well if you want to update the video code your your in for a lot of testing seems someones been hard at work to getting things working in the past. Unless you want to update the code mark it as imperfect gfx. Problem is there is so much testing to do if you touch this !
@arcadez2003 is assume you came up with that fix for wrestle fest ?
The original Fantasy Zone was released for Sega System 16 and is emulated in MAME 2003 Plus. The sequel, Fantasy Zone II, was originally a Sega Master System exclusive, but in 2008 Sega contracted M2 to port the game to System 16 hardware.
The new Fantasy Zone II runs on a slightly modified System 16 board, with more RAM than the original boards. It was added to MAME in mid-2012, well beyond MAME 2003/0.78, but I'm hoping the changes needed are small enough that the 2003 version of the driver could have System 16C/Fantasy Zone II support added without the need to backport too much.
Here's the commit which added Fantasy Zone II to MAME. mamedev/mame@bac858b0a3f73860847e7430ba97b9c8657ddccb MAME was still using the old non-commercial license at this point, so even if it isn't directly usable, it should be fine to reference its code.