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!
Do you have 128K RAM?
He mentions 464. So No. But has ulifac, so Yes. And more than 128
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.
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
Quote from: Takis Kalatzis on 09:30, 28 April 25Hello,
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.
Expanded version works. Why dsk version hangs on loading screen though.
@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... ::)
Only one developer. :D
@Anthony Flack I think
Quote from: vasilisk on 12:45, 12 May 25Only one developer. :D
:laugh: :laugh: :laugh:
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.
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.
Apparently, ulifac handles the dsk in a different way compared to gotek. Since the same dsk loads without problem in the gotek
Quote from: vasilisk on 15:15, 12 May 25Apparently, 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.
Quote from: arnoldemu on 14:57, 12 May 25With 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.
The phrase in bold, reminded me of something: After 765 Floppy Disk Controller (https://cpctech.cpcwiki.de/docs/upd765a/necfdc.htm) (for the brave and bold... see Table 6.), finishes reading a sector, Sector Number stored in R (each sector is determined by 4 sector id bytes, C-Track, H-head, R-Sector, N=sector size), is incremented by one (e.g. placed to next sector), BUT,
in case of reading the last sector of current track, the C-Track s incremented instead, and R-Sector placed to the 1st sector of the next track! Of course, this how i implemented the FDC emulation code...
But, WAIT, what if
we read the LAST sector of the LAST track? Did I provide a provision in the code for this case? ::)
Well, it proved that i DIDN'T, and because of that, if the LAST sector of the LAST track of a dsk image is accessed, C-track was increased to a non-existent track, and next read/write operation would seek a non existent point in dsk image file, resulting in PIC MCU code execution to fall into an endless loop as it waited for ever a proper respond from usb host module, that never came=fatal hang up!
Now, some of you might wonder: Why after so many years, this bug was never found?
Well, because the only way to discover and fix this nasty bug (or more accurately, an oversight in the code...), was if the LAST sector of the LAST track is requested from a program/game in a dsk image! And as it seems, this happens VERY RARE (most probable because almost no dsk image is fully written with data), apart from "Bomb Jack Extra Sugar" image, the only other case i encountered having exactly same behavior (fatal hang up upon reading dsk image with no obvious reason), was the "Little Computer People" dsk image!
As soon as i fix the bug (simply by adding a code that, in case of last sector of last track is accessed, "next" track will reset to Track '0'), both games loaded without problem from the dsk images!
I uploaded firmware updates (4a), for updating using serial cable (https://www.dropbox.com/scl/fi/bsvohs5bd4pfnth5psfqx/ULIFAC_4a.zip?rlkey=m24418wjvk3cp4s185l1u9tqp&dl=0) or PICKIT programmer (https://www.dropbox.com/scl/fi/cpvz3cj3b5ytqxlm0n1yk/ULIFAC_4a_bootloader.zip?rlkey=2k4ecqtu4d4wghyfznrgmtii5&dl=0) for anyone wanted to play Littl Computer People on CPC 464.
Thanks again to
@arnoldemu that his remark, was the trigger to make ULIfAC board a little better, at least "Little Computer People" better! :D
Btw, if anyone encountered this fatal hang up, upon accessing a dsk image, it would be very nice to tell us about it and see if problem is fixed.