Bomb Jack Extra Sugar hangs on loading - ULIFAC

[Mamejay]

Hi Team,
I am totally new to Amstrad and recently got a 464 and a ULIFAC device.
I have managed to limp my way around the system and load games.
One I really wanted to play was the new Bomb Jack port.
It starts to load, and I see the large character sprite running and at about 80% of the progress bar it crashes.
Even hitting the reset on the ULIFAC brings up garbled graphics.

Anyone managed to get this working with the same setup and if so how?

Thanks!

[ZorrO]

Do you have 128K RAM?

[vasilisk]

He mentions 464. So No. But has ulifac, so Yes. And more than 128

[Anthony Flack]

I don't have a ULIFAC to test on. I assume you have the latest version? I did a bug fix for 464 owners but I don't have a 464 to test on, either. 

[Takis Kalatzis]

Hello,

Try to use the expanded version (with all the files) and not the .dsk file.

I remember I had loading issues with the .dsk file but it worked when I switched to the expanded version.

Best,

Takis

[Mamejay]

Hello,

Try to use the expanded version (with all the files) and not the .dsk file.

I remember I had loading issues with the .dsk file but it worked when I switched to the expanded version.

Best,

Takis

You are a superstar!!  Works perfectly first try.

[vasilisk]

Expanded version works. Why dsk version hangs on loading screen though.
@ikonsgr 

[ikonsgr]

Well, this must be the weirdest problem i ever encountered regarding dsk image access... 
The game has a Basic loader that loads multiple files in the extra 64k ram of cpc, but for some unknow reason, loading of a specific file (PROGD.ZX0) causes a severe hang-up error of the usb host module that even hardware reset can't fix! 
Of course as already noted, using the "direct file" form of the game, not only works perfect, but loading, is ~3-4 times faster than using the dsk image! Btw, this should be a "lesson" to all CPC users (especially CPC 464 ones):
STOP using ALL THE TIME the bulky and slow dsk images, but whenever is available, USE "DIRECT FILES" (or "mass storage" form)!
Anyway, i tried to resolve this problem, and in the end i manage to make game load from a dsk image!
First, i transfer the dsk image to a real floppy disk  (using a CPC 6128 of course), and loading from it worked perfect, that confirmed that this is some a kind of weird "bug" of the usb host module. Unfortunately creating a dsk image from the floppy disk, still didn' work.
So then, i tried a more "extreme" approach: I formatted a floppy disk, and using |COPY i transfered all files from "Direct file" form of the game to the floppy disk. Then using |DISK command i created a dsk image of the newly created disk of the game, and guess what, this time worked perfect! 
You can find the modified/working dsk image of the game here: https://www.dropbox.com/scl/fi/zhxcr9vbpe2owyayyzfcd/BOMB2.DSK?rlkey=4rqc827ku86f0bkf5soj9936p&dl=0
Still, i wonder, how exactly the developers created the dsk image, as it seems that something in their method, is the real "root" of the problem...   

[vasilisk]

Only one developer. 
@Anthony Flack

I think

[ikonsgr]

Only one developer. 

   

[Anthony Flack]

Well I don't know that I did anything unusual! Certainly wasn't trying to be tricky. Compiled files with WinApe. Compressed with ZX0. Used ManageDSK for file transfer.

Just a magical ability to make a cursed file I suppose. 

[arnoldemu]

With Anthony's DSK all looks normal. PROGD has a valid amsdos header and it ends part way through track 39. The disk also looks standard 40 track AMSDOS based disc.

With ikonsgr's dsk the files are arranged differently due to formatting and copying and data goes up to track 23.

So the only difference I believe is where on the dsk PROGD ends in this case.

[vasilisk]

Apparently, ulifac handles the dsk in a different way compared to gotek. Since the same dsk loads without problem in the gotek 

[ikonsgr]

Apparently, ulifac handles the dsk in a different way compared to gotek. Since the same dsk loads without problem in the gotek

Indeed, you see:
- Flash floppy firmware of a Gotek Drive only emulates disk drive functions, and in case of CPC, requires the presence of 765 Floppy Disk Controller.

- ULIfAC/USIfAC II Emulates the 765 Floppy Disk Controller ITSELF, in order to access dsk images (that's why using USIfAC II/ULIfAC you can access dsk images even on a CPC 464, buy you can connect a gotek drive only to a CPC 664/6128).

For the most part, both approaches work the same way, except for two differences:
1) 765 FDC emulation in ULIfAC/USIfAC II, works "as fast as it gets" e.g. without keeping the various delays of a real disk drive (like setup times, moving head to track, or wait dozens of us for response), as gotek drive does. Thus image access using USIfAC II/ULIfAC is practically ~10-20% faster compared to a disk/gotek drive.
2) 765 FDC emulation in ULIfAC/USIfAC II implements the 765 FDC functions that are needed for normal disk drive operation, where flash floppy, implements ALL disk drive functions that are needed even for..."abnormal" operations. That's why gotek drive can load some "original"/ copy protected dsk images but ULIfAC/USIfAC II can't. The current 765 FDC emulation was a hell of time consuming and difficult task to achieve, but since all copy protected game images are "thing from the past", and also, all of these copy protected games can be found nowadays in cracked/"normal" dsk image versions, i don't think it matters anymore   (btw, 765 FDC emulation can handle many "abnormalities" in a dsk image, like having different number/type/size of sectors on each track, but it can't read data from GAP#3 a typical copy protection method of the time)

In any case, the specific problem we discuss here, has nothing to do with the handling of the dsk image from ULIfAC's 765 FDC emulation, but it's a "hiccup" of the CH376 USB host module itself.