nfg.forums

would you be able to send me the link in a PM?

I tried After Burner II with MIDI sound, but there is no sound.

Fortunately Space Harrier with MIDI sound works perfectly.

For those who don't know, the MIDI sound support for these two games was done amateurishly.

Tests performed with X68000 XVI 16MHz, with Etarikashikoshi 8MB RAM+MIDI, connected to Roland MT-32 and SC-55.

Did you try in 10mhz mode? Runs fine on my pro in 10mhz but if I try to play in 14mhz overclock the game crashes. I may need to add a note to the batch file.

Starting After Burner II in MIDI mode, both 15kHz and 31kHz, you only hear the sound effects.

Setting the CPU to both 10 MHz and 16 MHz, nothing changes.

I tried moving the folder to the C: partition but nothing changed.

The good thing is that almost all games with MIDI support, with Etarikashikoshi 8 MB RAM + MIDI, work.

I think the problem is due to the different emulation offered by Henkan Bancho PRO.

However, Space Harrier also has amateur MIDI support, but it works perfectly.

Too bad they didn't make a version of After Burner II that supports Joycard / Joystick with MIDI sound simultaneously.

Thanks for the info and testing. I recently picked up a henkan bancho and plan to test it out. Hopefully we can find a workaround.

I want to confirm this image works perfectly fine on Sharp X68000 first model on BlueSCSIv2 centronics 50 version. I saw a lot of people complaining BlueSCSI is not detected on SASI machines at first and it needs to be reset/power cycled and after that it gets detected. Surprisingly I've never encountered this issue even once and my BlueSCSI always boots up right away, albeit I'm using the newest PCB 2024.03a. Maybe my hardware is just lucky?

There is 1 caveat however- I started getting this dreaded warning in the log file:

QuoteWARNING: Host used command 0x1A which is affected by drive geometry. Current settings are 63 sectors x 255 heads = 16065 but image size of 6146048 sectors is not divisible. This can cause error messages in diagnostics tools.

Well, maybe I'm misremembering and this warning had been appearing before but I don't remember? Whatever, I was doing a ton of tests and tweaks so maybe my memory is mixing up. Apparently this warning appears when the image is not perfectly aligned with memory blocks but ultimately it's safe apparently. I also tried another older image "X68000V4" from this website and I never get this warning at all. It's probably not a big deal but if it can get fixed then people won't need to worry about anything

Aha there is 2 more things I want to mention for BlueSCSI users- despite what the manual says the image file needs to be named "HD10_512.HDA" because ID0 is the SASI controller. You also need to create and place bluescsi.ini file with this content:

Quote[SCSI]
System=X68000
EnableParity=0 ; Off

Before doing any of that you need to install SXSI driver of course. After doing all of that you are good to go.

I'm very intrigued by the functionality and the fact that SASI can only address 40MB max as far as I know but this hack breaks the limit into whopping 3GB of space and everything works perfectly fine so far. How does this black magic even work?

Quote from: BlackVega on October 10, 2024, 09:04:21 PMI want to confirm this image works perfectly fine on Sharp X68000 first model on BlueSCSIv2 centronics 50 version. I saw a lot of people complaining BlueSCSI is not detected on SASI machines at first and it needs to be reset/power cycled and after that it gets detected. Surprisingly I've never encountered this issue even once and my BlueSCSI always boots up right away, albeit I'm using the newest PCB 2024.03a. Maybe my hardware is just lucky?

I found that I needed to set the "unit startup time" to a minimum of 2 when running BOOTSET, otherwise the BlueScsi would not have enough time to come up before the system tries to access it. Initially I set it to 1 for no reason other than who likes hanging around more than they need to?

So if people were having problems then check you didn't set it to 1.

Made a new version of SLEEP.X. Now instead of using the real time clock to know when to resume execution, it instead counts VBlank periods.

Knew there had to be a better way, turns out it is simple.

Quote from: rezb1t on October 12, 2024, 08:37:35 AMMade a new version of SLEEP.X. Now instead of using the real time clock to know when to resume execution, it instead counts VBlank periods.

Knew there had to be a better way, turns out it is simple.

Awesome, thank you! I'll go through and update this in my new image.

Quick question- is this possible to edit this image directly on modern PC at all? Because editdisk doesn't recognize it at all

It is possible - check Post #275. Also word of warning that editdisk is known to corrupt files so use with caution.

Not sure if these glitches were reported but I noticed some games suffer from performance issues like slowdown or screen glitches even though they should work fine. Garou Densetsu 1 and Detana Twinbee run janky but they run perfectly fine using the older 1GB image posted by someone else. I run them on X68000 first model using BlueSCSIv2. If anything I would repair anything that is glitching or not working in the next version first before adding anything more

Thanks for the heads up, I was aware of the detana twin bee but not garou so I'll look into that for sure. My apologies for the noted issues in 2.20 as it looks like some of these are new to this version, but I think I understand the possible root cause for some of it and plan to have them resolved in the next release.

Just to give some sort of progress report... I have the new version running on multiple partitions and am almost through testing on emulators, going to proceed with real hardware next - have already begun some testing there. I have the issues noted in these threads and plan to address before adding any new games. Some have been fixed like the reported issue with akumajou crashing, and I have aquales running from hdd but I still need to work through the others. Sorry for the delay but this release is going to be a little bit more complex due to the way it's set up. Will be easier to install with modern scsi emulators but I want to keep scsi2sd support so I need to make sure that's working fully before pushing an update. There will be plenty of space in the D,E,F volumes to add content. Plan on using an 8GB SD card for this one.

UPDATE 27Oct - All paths corrected and all games finished testing on emulation - All reported problems addressed. My plan is to now install on Henkan Bancho and see if I can troubleshoot those issues next.

Testing new image on Henkan Bancho with SASI X68000 ACE. Here is my current status related to reported issues:

NOTE: Part of the fix was I needed to reformat my CF card as FAT32 with 64k clusters (classicpc.org suggests largest possible for faster data seek). ExFAT is also faster but the v4 released after 2021 is required for exFAT support, from what I could gather. I'm sticking with FAT32 for compatibility testing with all models.

1. Super Hang On is working - game loads at about the 23 second remaining mark on a 10mhz machine with the bancho. Also to note that I had no crashes while playing Europe with Winning Run soundtrack. I'm marking this as resolved until future issues reported on it.

2. Die Bahnwelt appears to work fine - I couldn't replicate the issue myself but will test more when I do a full hdd test of games.

3. Akumajou Dracula errors and crashes fixed when booting from floppy. Not sure if data corruption caused the issue but appears to be fixed (did a reinstall of the RA960 folder)

3. Star Trader loaded past the noted screen and I was able to start a game and play normally.

4. Garou Densetsu and Detana Twinbee issues fixed from what I can tell. Reinstalled games and I think some of the slowdown was related to PCM8 drivers being loaded for those games.

5. Knight Arms no freezing occurring for me - this was in 10mhz with the Henkan Bancho. Will check again on a full HDD test at 10 and 16mHz. (Game runs really choppy at 10mHz)

6. As noted by spectreman in a previous post, Neural Gear is configured for a mouse. Game loaded fine although takes a little bit to get there.

7. Bonanza Bros. still doesn't boot from SASI/SxSI. Similar to the other SCSI unbootable games like New Zealand Story and Downtown Nekketsu Monogatari. No fix for these yet.
UPDATE: I have Bonanza Bros. Booting fine from SxSI with BlueSCSI. I will continue to troubleshoot Henkan Bancho.

8. SLEEP.X has been updated to rezb1t's current version - should hopefully take care of the system hanging people were experiencing.

9. Aquales can now be played from HDD with saving but requires some extra steps which isn't difficult but people may prefer playing from floppy disk. Not sure if there are any differences with the BEEP rerelease as I don't have that version available to me.

10. Music and video folders fixed to playback correctly.
 

NOTE to Etarikashikoshi RAM/MIDI board users - set both jumpers to the 2-3 positions on your board to avoid crashes and bus errors with MMDSP and some games. I actually suspect a lot of reported bus errors with games like  Daimakaimura and Mahou Daisakusen are related to the odd default IRQ setting of the Etarikashikoshi. If you experience issues with midi and games, try that first. 

EDIT: Tested and can confirm the Etarikashikoshi is not compatible with After Burner's MIDI patched modes.


I think that covers all of the issues reported so far... I still have a full test on actual hardware to perform  and then I can add more content. Let me know if there's anything you'd like me to add as I'm at that point where I can take requests. One last thing, someone asked about X68030 support - I may start to work on this depending on interest. Plan would be to incorporate into existing image I'm working on but with settings for 030 systems when needed. Maybe an mputype check in the .BAT or something.

Wow. Just WOW.

I needed a new HD image because I kept getting weird corruption errors in the (very) old version I had in my SD. To my surprise there was a new version from 2023. That made my day!! Working as a charm is with lots of new games!! I decided to come to say THANK YOU but... to my surprise there is another version in the making! I have no words to describe your dedication Incrediblehark. I'd love to know if there's anything I can do to help like testing or anything.

One silly question, I read in your last post that The NewZealand Story is not bootable but I was playing from that old hard disk image. Do you mean that it is not working properly? It had indeed some error when moving into certain areas but the was was bootable and worked mostly fine (tested on a X68000 Pro).

Thank you for the feedback and I'm glad you are enjoying the image! To answer your question, certain games like New Zealand story do not boot from HDD on a SCSI machine. I believe your pro is SASI so the game should work fine with the SxSI drivers installed. Try Bonanza bros and see if it will play for you. That one seems to only boot from a SCSI device opposite of the NZS issue.

EDIT: Disregard - I now have Bonanza Bros. Booting on SxSI with BlueSCSI. Will keep troubleshooting Henkan Bancho.

River City Ransom is also a game that won´t boot on scsi machines.
Would be nice to find a fix.
On my OG 68000 both (NZS / RCR) work fine, on my XVI not.

Looks like the compatibility is very inconsistent and everything is all over the place. I remember a few games didn't boot up. I remember Shufflepuck didn't work for me and Barusa no fukushuu had glitched enemies. Again, I use X68000 first model 8MB RAM total and BlueSCSIv2. Should I report every single little thing that goes wrong?

Yes, please report all issues so that I can work on fixing them for my next release. But also, make sure you are booting the games by navigating to the folder containing the !Start.Bat and pressing Q then Q again to quit LHES. Almost all games should be started this way unless specifically noted. I tested Barusa no Fukushuu and Shufflepuck Cafe, and they worked well for me unless I started the game within LHES. Then I got similar errors as you reported.

I checked some recently reported games.

Garou Densetsu 1: it was indeed buggy, so I replaced the version with the one released by Eidis V4.

Detana!! TwinBee: it works perfectly for me.

About Henkan Bancho PRO only supports FAT32.

FAT32 does not support 64k clusters, only with exFAT is it possible to do so, supported only on the V4 revision released in March 2024.

If you use CF cards no larger than 4GB, the maximum capacity is 32KB, and only if you use very large memories you can get to a maximum of 64KB.
But it's a stretch, they often gave me problems of compatibility.
Clusters smaller than 32KB make reading extremely slow, just move between folders to notice this.

The problem with Henkan Bancho PRO is due to the type of emulation very faithful to a real HDD, which recognizes the Games folder in the C: partition as primary, so it is sufficient to move those games that are acting up in this partition creating the Games folder, as in previous HDD images.

Die Bahnwelt freezes as soon as you enter the military base (about 10 minutes of gameplay).
I solved it by replacing the game with the one contained in the Eidis V4 HDD image.

FZ Senki Axis compatible with Roland MT-32 and CM-64 crashes after selecting MIDI mode, I had to replace it with the version contained in the MiniV2 HDD image.

For those who don't know, to start MIDI mode in games developed by WOLFTEAM, you have to hold down the button called Tōroku ( recording ) which is located to the left of the help button on the keyboard.

New Zealand Story and Downtown Nekketsu Monogatari ( River City Ransom ), I believe they were taken from an HDD image optimized for X68030, like the one released by Shoometsu.
Actually, not even the XM6 TypeG emulator can start them from the HDD image, using settings other than X68030 mode.

I have to wonder what the issue is with those non-booting on SCSI games is. My PRO has a SCSI card and I don't use SxSI and I don't have that problem at all.

Quote from: neko68k on November 03, 2024, 06:49:13 AMI have to wonder what the issue is with those non-booting on SCSI games is. My PRO has a SCSI card and I don't use SxSI and I don't have that problem at all.

I assume you're referring to New Zealand Story and Downtown Nekketsu Monogatari (River City Ransom), but the problem also appears in the XM6 TypeG v.3.36 emulator, even using previously released HDD images including the one from Eidis.
They only work fine from floppy.

Do you have images of these different games?
What kind of emulator device do you use?

Quote from: spectreman on November 03, 2024, 11:53:44 AM

Quote from: neko68k on November 03, 2024, 06:49:13 AMI have to wonder what the issue is with those non-booting on SCSI games is. My PRO has a SCSI card and I don't use SxSI and I don't have that problem at all.

I assume you're referring to New Zealand Story and Downtown Nekketsu Monogatari (River City Ransom), but the problem also appears in the XM6 TypeG v.3.36 emulator, even using previously released HDD images including the one from Eidis.
They only work fine from floppy.

Do you have images of these different games?
What kind of emulator device do you use?

I'm using the old Eidis HDD with a fresh copy of the TNZS files from floppy because a couple files are corrupt on that one (graphics issues) but otherwise nothing special there.

I have the SACOM SCSI card and use an iomega Jaz drive (two of them actually).

I have 10MB ram, the internal 1MB card plus two IO slot memory cards.

Technos Football does the same. I've played them all with no issue. I wonder if there's a bug in the sharp SCSI IPL. The SACOM SCSI IPL is completely different. I wonder if running SUSIE for SCSI access fixes it? I might give it a shot. I'm also tempted to just run the games in a debugger and see what happens.

River City Ransom:

Technos Football:

[edit]
Oh, I'm overclocked at 15mhz (doesn't matter here) and use ch30_omake as a bootloader but I don't think that does anything special for SCSI except giving me a nice way to select which HDD to boot from and a has a fancy boot animation that I swiped from some game. I added a floppy boot sector virus scanner also but that's got nothing to do with it either.

Fancy boot animation:

[edit 2]
OK So I tested it in xm6 with in EXPERT mode with the fake XM6 SCSI internal ROM and a dump of my SACOM external ROM and RCR boots just fine. It also works in XVI mode with the XM6 internal SCSI ROM. Again, this is the old Eidis v4 disk. I have a copy of the real Sharp SCSI ROM somewhere but I can't find it. So that's all I got. Don't know what's going on but it works just fine for me.

I forgot that i also use the system sacom scsi in my OG and both games work there while they don´t work on X68030 internal scsi. Using same V4 image.

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

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.

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.

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.

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

Cool, thanks. I'll take a look!

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

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.

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.

Quote from: neko68k on November 04, 2024, 05:21:45 PMOk 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.

Just tested your fix and it works perfectly on my XVI Compact! Nice work.

Quote from: neko68k on November 04, 2024, 03:41:07 PMOKOK so that's all nonsense lol. So eventually river city ransom (probably others are similar) gets to

Code Select Expand

        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.

I checked New Zealand Story with dis.x and found the exact same code referenced here in that game too. Replacing the bne instruction with nop instructions makes it work perfectly via internal SCSI on my XVI Compact as well.

Attached is the New Zealand Story executable with the fix. All credit goes to neko68k

This is awesome! Thank you @neko68k  These will be added to the image I am working on. Thank you again for taking the time to look into this for us, and thanks @rezb1t for the New Zealand story fix as well. This is really exciting!

There are 2 other games I know of that exhibit the same behavior - Nekketsu Soccer and US Championship V'Ball. Would either of you be willing to make fixed executables for these as well? Thank you again for solving this problem, I really appreciate the help!

Here is vball and soccer. Glad to be of service

Thank you!

Congratulations neko68k, great job.

I tried all the games with the fixes on the XVI at 10MHz and 16MHz and they all launch.

Starting the game V'Ball, with the fix on the HDD image of Eidis the game is normal, but when I copy the game into the HDD image of incrediblehark, it gets corrupted showing abnormal colors and graphic defects.

The other games that have received a fix work without problems, after the transfer.

I use editd169e, which previously always worked well.