Sonic delta 40mb romhack

[Lisko]

Hi, I'm not a particular fan of romhacks but I seen this interesting one that is claiming to work on original hardware. On mister the audio is broken, lot of sprites errors, glitches and crashes. I haven't even tried the save feature reportedly broken on everdrive because can't use sram with sega mapper and don't know if applies to mister too. I'm only reporting this in case addressing this could lead to a more accurate core or if someone want take this up.

[ExCyber]

Yeah, the core's "SSF2" mapper doesn't support SRAM switching. That's easy to add (as long as we don't care too much about precisely matching the behavior of the original chip, as I'm not sure anyone ever confirmed whether that chip even has the SRAM control register, let alone exactly how much of the ROM space gets switched to SRAM). I'm not sure where the other problems are coming from. This hack seems to be under active development, so I don't think we can take it for granted that these aren't bugs in the hack itself.

[Brettster]

I tried this on MiSTer and it runs but without sound,
tried it on my Analog Mega SG and it does not run from either my Mega SD or Mega everdrive.
Tried it on my model one Japanese MD with both carts and still no joy, on the Mega SG and Real MD, I just get a blue debug screen from both flashcarts.
So it looks like the MiSTer is actually running it better than the real thing, at least on the current version, if it had fully working sound then perfect

[Neto]

Hi, I am developer o Sonic Delta 40Mb rom hack.

The last releases ( https://www.neto-games.com.br/rom_hack/ ... _40_mb.php ) are running without any issues in real hardware.

The bank switching scheme used in the game follow SEGA standards, as you can see in the page #51 (copy in attachment ) of this doc ( https://segaretro.org/images/2/27/Genes ... letins.pdf ) .

No official games uses this full implementation of SEGA Mapper where RAM and ROM are remapped at same time.
I have developed a hardware ( https://www.neto-games.com.br/hardware/ ... rdware.php ) which allow the game running on real hardware with both types of remapping ( RAM and ROM ).

The main difference of Mapper used in SSF2 is the usage of SRAM register. Writing to $A130F1 ($01) enable and ($00) disable SRAM register at $200000.

For easy implementation in emulators, the game uses a custom serial Number "GM NETO-001-40". As example: The BlastEm developer added support to hack based on serial number.

[Zesty]

Does this romhack work on any flash carts right now?

[Neto]

Does this romhack work on any flash carts right now?

I have asked Krikzz and the new ED-MD Pro will have support.
P.S. I have downloaded a copy of the O.S. of ED-MD Pro and I could see a reference to my hack in the file "megaos.dat".

[ExCyber]

I made a change to enable the SRAM banking and ROM banking at the same time and it seems to work, but I still don't understand what's happening with sound. Oddly, it seems to work fine on the Data Select screen but is broken (sometimes static or distorted sound but usually just silence) elsewhere. I think this isn't due to my SRAM banking change because version 0.41c shows similar behavior in an official Genesis_MiSTer build (it's not possible to run 0.44 in the same official build because it checks for banking support). The only possibilities I can think of right now (and these are just speculation) are:

1) A bad interaction between ROM banking and some other feature/condition that SSF2 and Pier Solar don't hit.

2) ROM mirroring doesn't seem to be handled by the current core (though I might be misunderstanding something here)

3) Something depending on uninitialized memory values (this has been seen with a bunch of SNES games/hacks, and it's even configurable in SNES_MiSTer now)

4) Something depending on unspecified/non-standard 68K/Z80 bus arbitration.

[Neto]

I made a change to enable the SRAM banking and ROM banking at the same time and it seems to work, but I still don't understand what's happening with sound. Oddly, it seems to work fine on the Data Select screen but is broken (sometimes static or distorted sound but usually just silence) elsewhere. I think this isn't due to my SRAM banking change because version 0.41c shows similar behavior in an official Genesis_MiSTer build (it's not possible to run 0.44 in the same official build because it checks for banking support). The only possibilities I can think of right now (and these are just speculation) are:

1) A bad interaction between ROM banking and some other feature/condition that SSF2 and Pier Solar don't hit.

2) ROM mirroring doesn't seem to be handled by the current core (though I might be misunderstanding something here)

3) Something depending on uninitialized memory values (this has been seen with a bunch of SNES games/hacks, and it's even configurable in SNES_MiSTer now)

4) Something depending on unspecified/non-standard 68K/Z80 bus arbitration.

Look likes the z80 RAM is getting corrupted during Sound driver change. To avoid this the game stop interrupts and requests the z80 BUS. For some reason, I think the interrupts is still running during driver code change.
To confirm if it is the issue you can access Sound test by typing Up, Up, Down, Down, Up, Up, Up, Up in the Title Screen to Enable Sound Test.
In the Sound Test, Play the Sound $33 and $34, If you get corruption while toggling between them, the issue is related to interrupt still running while z80 driver is changed.

The game also has a hidden Super Debugger where you can write some values to test hardware response.
After doing Sound Test Code, highlight Sound Test Option and hold A+B+C then Press Start to Launch the Super Debugger.

In Super Debugger Press START to toggle to programmer mode and use "A" to toggle between fields and when Offset is Highlighted use "B" to Increase high byte, "C" to Increase low byte, use d pad to fast decrease and increase values.
To apply the changes press "A" to highlight "A+START" text and then press "C" to write the values or "B" to read.
P.S. The ABCD option is just to see the behaviour in some processors with invalid operations for ABCD operator.

Highlighting the Hexdata you can go to address 0xA00000 and them compare data with an emulator / real hardware to see if the z80 RAM is not corrupted.

[Brettster]

Thanks for Posting Neto, it's great to hear from the developer, and what I've played so far (without sound) looks like a fantastic quality hack
Hopefully there will be a way to play this on the Mister at some point.

[Brettster]

Just tried the new version .44 and now it does not start at all on the MiSTer. Just shows this debug screen

sonic.JPG (423.29 KiB) Viewed 15057 times

[Newsdee]

It says missing SRAM ... maybe the mapper it uses is missing something?

[Neto]

Just tried the new version .44 and now it does not start at all on the MiSTer. Just shows this debug screen

sonic.JPG

The last version test if full SEGA Mapper is available and throws exception $40 if ROM mapping fails or exception $41 if SRAM mapping fails.

If you have an Everdrive of X-Series you can try a modified O.S. ( https://www.neto-games.com.br/rom_hack/ ... Mapper.rar ) which allow the game to run ( with original O.S. you will receive an "Unsupported Game" error message ( X3 / X5 ) ).

[ExCyber]

I guess there's been a spike in interest in this. In case anyone else wants to investigate/play with this while I'm at work, here's the diff to enable SRAM banking with the "SSF2" mapper (against Genesis_MiSTer b1b7d2cf33b3c9a98d8e88885a74586611ad1206) and a .rbf with that change.

[ExCyber]

Highlighting the Hexdata you can go to address 0xA00000 and them compare data with an emulator / real hardware to see if the z80 RAM is not corrupted.

I checked a little bit with your Super Debugger (nice work, by the way), and it does seem like Z80 RAM contents are different, e.g.:

Genesis_MiSTer (0.44 Super Debugger):

Code: Select all

A00000: F3F3 ED56 C385 00F2
A00008: 2A15 0006 0009 087E
A00010: 2366 6F08 C900 0000

MAME (0.41c; MAME Debugger genesis_snd_z80 program space memory, since I can't run v0.44 easily)

Code: Select all

0000: F331 7E1B C31E 0100
0008: 3A00 4087 38FA C900
0010: DDCB 0156 2802 1810

Although I did look at different versions, I don't think this part of the sound driver changed between these versions.

If I'm reading the MAME debugger correctly, it looks like interrupts are masked on the 68K when the sound driver is loaded. I could imagine a problem with disabling interrupts via VDP registers, but in this case I'm not sure what kind of bug in the MiSTer core would prevent interrupts from being disabled. I don't see any indication that anything can ever generate a priority 7 interrupt, and it seems unlikely that the interrupt masking in FX68K is just completely broken, so I'm not sure what to look at.

[Lisko]

I guess there's been a spike in interest in this. In case anyone else wants to investigate/play with this while I'm at work, here's the diff to enable SRAM banking with the "SSF2" mapper (against Genesis_MiSTer b1b7d2cf33b3c9a98d8e88885a74586611ad1206) and a .rbf with that change.

Please don't forget to make a PR for official core. Would be nice to see it in official release, and will make the mapper more accurate!

[Neto]

Genesis_MiSTer (0.44 Super Debugger):

Code: Select all

A00000: F3F3 ED56 C385 00F2
A00008: 2A15 0006 0009 087E
A00010: 2366 6F08 C900 0000

MAME (0.41c; MAME Debugger genesis_snd_z80 program space memory, since I can't run v0.44 easily)

Code: Select all

0000: F331 7E1B C31E 0100
0008: 3A00 4087 38FA C900
0010: DDCB 0156 2802 1810

Both of these z80 RAM content are correct. The difference probably is because you have played any sound above $33 in the M.A.M.E. before loading Super Debugger.

Another thing you can verify is if the data is correctly mapped by looking in to the banks. Going to Offset:
- $100000 you should see the String "M68K Bank 2";
- $180000 -> "M68K Bank 3";
- $200000 -> "M68K Bank 4"; or "N E T O" if you write $0001 to $A130F0 in Super Debugger;
- $280000 -> "M68K Bank 5";
- $300000 -> "M68K Bank 6";
- $380000 -> "M68K Bank 7";
The Hidden data will be available writing $0008 to $0A130FC and $0009 to $0A130FE in Super Debugger and the Strings will be
- $300000 -> "M68K Bank 8";
- $380000 -> "M68K Bank 9";

[ExCyber]

I probably played sound 00 while launching Super Debugger, whereas in MAME it was still playing the title music. I'll take another look at it tonight.

[ExCyber]

So yeah, the memory contents that I posted before do match if I play a sound above 33 before entering the Super Debugger.

I checked the banking and it looked as you described, except that bytes were duplicated in SRAM (so "NNEETTOO" rather than "N E T O"). But this probably has no connection to the banking mechanism and seems to just be a hack in Genesis_MiSTer to simplify SRAM handling.

Perhaps more significantly:

1) Sounds 33 and below seem to work.

2) Repeatedly switching between 33 and 34 eventually causes a tile to be changed in Genesis_MiSTer but not in MAME. So far It's always the same location (just under the "T" in "SOUND TEST") and the same new tile. So far, I've only seen this show up when switching to 34, not when switching to 33.

This all seems to suggest that there's a problem specific to loading the 33+ sound driver.

[Neto]

So yeah, the memory contents that I posted before do match if I play a sound above 33 before entering the Super Debugger.

I checked the banking and it looked as you described, except that bytes were duplicated in SRAM (so "NNEETTOO" rather than "N E T O"). But this probably has no connection to the banking mechanism and seems to just be a hack in Genesis_MiSTer to simplify SRAM handling.

Perhaps more significantly:

1) Sounds 33 and below seem to work.

2) Repeatedly switching between 33 and 34 eventually causes a tile to be changed in Genesis_MiSTer but not in MAME. So far It's always the same location (just under the "T" in "SOUND TEST") and the same new tile. So far, I've only seen this show up when switching to 34, not when switching to 33.

This all seems to suggest that there's a problem specific to loading the 33+ sound driver.

For some odd reason, I think the stop interrupts request is not working as expected by Game.
Before changing the sound driver the game saves SR register, then write #$2700 to SR to stop interrupts and then requests the z80 BUS, wait for z80, change driver code, restart z80 and restore SR register.
The VDP corruption occur if interrupts is enabled during driver change. In my tests, I had this issues if does not write #$2700 to SR.

[ExCyber]

I'm starting to get the hang of SignalTap (Intel/Altera's in-fabric logic analyzer), which is pretty nice apart from some seemingly minor configuration changes requiring a full recompile.

I captured the entire driver load, and the data written is correct. So while I can't rule out the possibility that something about the 68K interrupt control is wrong, I don't think it's interfering with the load process itself.

By accidentally capturing Z80 instruction fetches around an IRQ transition, I found that the driver appears to get into a state where it's in a loop waiting for an interrupt, but interrupts are disabled. I then captured PC on all transitions of IFF1 and IFF2 flags after reset to see if I could track down the place where interrupts ultimately get disabled before entering the loop. I'm not sure what to make of the result. The IFF flags are definitely cleared, but I'm not sure what's doing it. It sort of looks like the flags are cleared to take an interrupt, but then the interrupt isn't actually taken. Maybe a problem with e.g. an interrupt being pending during some bus arbitration operation?

Anyway, I think that's enough investigation for today.

[ExCyber]

The issue appears to be a combination of two things, each of which might be considered a bug in its respective code base:

1) Genesis_MiSTer's T80 core resets IM (interrupt mode) to 0 when the 68K resets the Z80. This is explicitly stated by the (modern, CMOS) Z80 manual as happening on reset, but MAME seems to only reset IM on a "hard" reset. Considering the variety of weird Z80-based hardware supported in MAME, I wouldn't be surprised if the MAME behavior is more representative of Z80 chips of this vintage, but I'm not sure where to find authoritative info on the real behavior. In any case, mode 0 is a backward-compatibility mode for 8080 peripherals that is allegedly almost never used or supported in systems that were originally designed with a Z80, so it's not surprising that it would break things on Genesis.

2) The hanging driver never initializes the IM, apparently relying on an earlier Z80 program having done this. If the statement in the modern Z80 manual is accurate for newer Z80 chips/cores, I suppose this might also cause problems on some clone systems.

I'm not quite sure what the right change is here, if any. This is partly because I'm not sure exactly what the original hardware does and partly because I'm not sure where the distinction between "soft" and "hard" reset even exists in the MiSTer code base (other than bitstream load vs. reset input).

[Neto]

If this help, here is a piece of code used to change the Sound Driver.

Code: Select all

                movem.l A0/A1/D0, -(A7)
                move.w  SR, -(A7) 
                
...  Some code here

                bsr.s   Reset_Z80_Memory
                bsr.s   Load_Z80_Driver
                
...  Some code here

                move.w  (A7)+, SR 
                movem.l (A7)+, A0/A1/D0
                rts
;-------------------------------------------------------------------------------    
Reset_Z80_Memory:                
                move    #$2700, SR                  
                lea     ($00A00000), A1
                move.w  #$0100, (Z80_Bus_Request) ; Z80 bus request - Start  ; $00A11100
                move.w  #$0100, (Z80_Reset)       ; Z80 stop reset           ; $00A11200  
Reset_Z80_Memory_Wait_For_Z80:        
                btst    #$00, (Z80_Bus_Request)                      ; $00A11100
                bne.s   Reset_Z80_Memory_Wait_For_Z80 ; loop until it says it's stopped
                move.w  #$1FFF, D0   
Reset_Z80_Zero_Memory_Loop:       
                clr.b   (A1)+
                dbra    D0, Reset_Z80_Zero_Memory_Loop                        
                rts           
;-------------------------------------------------------------------------------
Load_Z80_Driver:
                move.w  #($13E0), D0
                lea     (Z80_Driver_Code), A0
                lea     ($00A00000), A1
                move.w  #$0100, ($00A11100)     ; Z80 bus request - Start  
                move.w  #$0100, ($00A11200)     ; Z80 stop reset 
Loop_Z80_Not_Stopped:        
                btst    #$00, ($00A11100)
                bne.s   Loop_Z80_Not_Stopped    ; loop until it says it's stopped                  
Loop_Load_Z80_Driver:
                move.b  (A0)+, (A1)+               
                dbra    D0, Loop_Load_Z80_Driver 
                
                lea     ($00A01B40), A0
                moveq   #$007F, D0
Loop_Clear_Z80_Sound_Buffer:                
                move.b  #$00, (A0)+
                dbra    D0, Loop_Clear_Z80_Sound_Buffer
                                                           
                move.w  #$0000, ($00A11200)     ; Z80 start reset
                move.w  #$0000, ($00A11100)     ; Z80 bus request - Stop    
                moveq   #$17, D0
Loop_Z80_Bus_Start_Request:     
                dbra    D0, Loop_Z80_Bus_Start_Request                   
                move.w  #$0100, ($00A11200)     ; Z80 stop reset
                rts                 
                align   $8000       
Z80_Driver_Code:        
                incbin  's2driver\bin\c_driver.bin'
Z80_Driver_Code_End:

[ExCyber]

I spent a little more time looking at this, and I think the answer might be that the Z80 does reset to interrupt mode 0, but mode 0 actually works the same as mode 1 on some consoles because the Z80 data bus is pulled up and Z80 /RD is connected to RAM /OE, so the RAM wouldn't be driving the bus during the interrupt cycle. I haven't checked with SignalTap yet, but from the HDL code I think Genesis_MiSTer will still drive RAM content onto the bus during the interrupt cycle. If all of that is true, then the difference would be that on some consoles the "FF" byte for RST 38 simply comes from the bus instead of being injected internally, whereas Genesis_MiSTer just executes whatever was on the RAM output. But for Sonic Delta 40Mb in particular, I think the best resolution would be to change it to execute an IM 1 early in the driver code (like the working driver does), because I doubt mode 0 works on all consoles.

[Neto]

..... because I doubt mode 0 works on all consoles.

I have various revisions of Genesis / Mega Drive and the game worked without any issue in all of them. Tested in Genesis 1 VA3 (without TMSS), Genesis 1 VA7, Mega Drive 3 (SEGA 315-5960), Genesis CDX, Mega Drive 2017 (Redkid 2500 processor) ( I have other consoles revisions, but I think that is enough ).
On all tested machines, the only issue which I have found In "Sound Test" option in Title Screen is after loading the driver is the need to wait for one M68K VSync interrupt before trying to play any sound above $34. But if you try to play the same or other sound above $34, they will play fine.

[ExCyber]

I'm still not sure whether it's working because mode 0 works like mode 1 due to bus behavior, or because IM is not actually being reset. Maybe I ought to write a test ROM that checks both and see what happens when it's run on various emulators and consoles.

[retrosaur]

I'm still not sure whether it's working because mode 0 works like mode 1 due to bus behavior, or because IM is not actually being reset. Maybe I ought to write a test ROM that checks both and see what happens when it's run on various emulators and consoles.

I wish i could help somehow, since i would love if could get this to work. Is there anything i can do to help? maybe do some testing with that test rom?

[ExCyber]

It should be working in the next release, with the "IM 0 acts like IM 1" behavior. MAME appears to be the outlier here in not resetting IM; everything else I can find suggests that IM is reset and that the Z80 data bus would be pulled to FF during an interrupt cycle on an original console.

[Brettster]

Tried the version released yesterday V047 but still shows an error on startup, Blue Hex Screen

[Neto]

Tried the version released yesterday V047 but still shows an error on startup, Blue Hex Screen

The game require full SEGA Mapper support to work.
Error $40 - "Mapeador não inicializado" - Means SEGA Mapper not supported by device.
Error $41 - "SRAM não inicializado" - Means SEGA Mapper is supported, but without SRAM Support.

[ExCyber]

I guess I wasn't especially clear, but when I said "next release", I meant the next release of Genesis_MiSTer, which hasn't happened yet. Here's a .rbf for those who don't want to wait.