nfg.forums

Ok here's what I'm gonna do. This is a new reply for clarity. I NOPed the 'bne' shown in the [edit] portion of the above post.

The attached 7z has a file called 'dtwfix.x'. Stick this in the river city ransom directory and change the !start.bat to run 'dtwfix.x' instead of 'dtw.x' and let me know if that works. It works in xm6. If this works for you internal SCSI folks I'll go see about fixing the other games in a similar fashion.

Ok so I'm not sure what to make of this yet but I'm going to write it down so I don't forget later. Maybe someone will have an idea.

Basically all of these crashing with internal scsi games do something like this:

L000000:
    adda.l    #$00000010,a0
    movea.l    #L02e100,a6
    move.l    a7,($38ea,a6)
    movea.l    #L039980,a7
    bsr    L000b80
That does:

• add 0x10 to a0 (can't remember whats in a0, thats set in command.x)
• set the work ram pointer in a6
• store the current stack pointer in work ram
• load the games stack pointer
• then branch to a startup function

Inside the startup function it tries to enter supervisor mode by calling IOCS _B_SUPER like so:

L000b80:
    move.l    a2,($38e6,a6)
    suba.l    a1,a1
    ; IOCS _B_SUPER
    move.l    #$00000081,d0
    trap    #15
When trap #15 is called it dies. All of these games follow roughly the same process. So something is maybe clobbering IOCS jump table or maybe IOCS _B_SUPER gets mangled? The behavior is kind of strange where if I patch that to be

move.b #81, d0

instead, it actually gets past that part but fails on the next IOCS call which is using the move.b instead of move.l already. Makes no sense to me.


[EDIT]


OKOK so that's all nonsense lol. So eventually river city ransom (probably others are similar) gets to

        movea.l #$00000500,a0
move.w #$000f,d0
move.w #$00ff,d1
L000bf0:
and.w (a0),d1
addq.w #4,a0
dbra d0,L000bf0
cmpi.w #$00ff,d1
bne L000ce0
The value here that it ends up checking with that cmpi.w isn't $00ff. If I change the contents of d1 before that comparison the game works fine. I can't find in my docs what lives at $500. I might ask around unless someone knows offhand. Kamada-san almost certainly knows but I hate to bother him.

Anyway, hack-fix is probably easy. Proper fix is maybe not. I'll do some more digging later and if worse comes to worse I'll just release a hack-fix for these and we can all move on with our lives.

Here's a dump of x68k Panic Bomber.

https://www.mediafire.com/file/624ikit52c0pv8u/Panic_Bomber_%25281995%2529.hdm/file

If it helps, these are the original files I normally use.
Everything that starts with these always works with the real system too.

Cool, thanks. I'll take a look!

@neko68k Attached is the one I use in XM6 Type-G for testing.

Quote from: incrediblehark on November 04, 2024, 06:25:36 AMWould there be a way to load the corrected SCSIINROM.DAT or an updated IPL into SRAM to load before the built in hardware? I'm wondering if there's a solution other than a bios replacement.

I have an external bluescsi and xvi I can test with, but I think I'll get the same result of not booting the games in question. I may have a sharp scsi card I can try as well.

Probably, yeah. SxSI works by hooking the SCSICALL stuff and that ought to work. I'm curious to see what the actual difference is. If I can find my Sharp scsiinrom I'll do some snooping around. Or if someone can hook me up with a dump.

Would there be a way to load the corrected SCSIINROM.DAT or an updated IPL into SRAM to load before the built in hardware? I'm wondering if there's a solution other than a bios replacement.

I have an external bluescsi and xvi I can test with, but I think I'll get the same result of not booting the games in question. I may have a sharp scsi card I can try as well.

I have verified the problem with the emulator and the real system, and I confirm what neko68k said.
It is a defect in recognizing the addresses of the internal SCSI units in all X68000 SCSI systems.
The only solution seems to be to use an expansion card such as SACOM SCSI, or to have an external emulator read the HDD images.

At the moment I only have internal units ( Henkan Bancho PRO and BlueSCSI v2 Desktop ).
If anyone has a SCSI system with an external device, I'd be interested to know if New Zealand Story and Downtown Nekketsu Monogatari (River City Ransom), boot correctly from the external SCSI.

Regarding XM6 TypeG emulator, using the real system's SCSIINROM.DAT file the same defect occurs, but creating a new file with the xm6_util_20220608 utility will create a new SCSIINROM.DAT without defects, copying the HUMAN302.XDF file to the same folder as the program and selecting the third command from the menu will allow a correct boot.

For those interested, here is the program:
http://retropc.net/x68000/software/sharp/human302/HUMN302I.LZH
http://retropc.net/pi/xm6/xm6_util_20220608.zip

However using the SCSIINROM.DAT file from real systems, are the best to test the efficiency of HDD images, before mounting them on real X68000.

Quote from: spectreman on November 03, 2024, 01:03:33 AMFAT32 does not support 64k clusters, only with exFAT is it possible to do so, supported only on the V4 revision released in March 2024.

I'm using 32k cluster size on my FAT32-formatted flash media with Henkan, and it works very well. Not slow.

Also, you can format with 64k cluster sizes if you use a tool like this: http://ridgecrop.co.uk/index.htm?guiformat.htm