GideonZ
G64 created with U2+ only works on Vice (Bushido - Firebird)
C64c PAL, U2+, FW3.10j Turbo Nibbler 4 software (default config) Create copy original Bushido game disk to G64
Created G64 only works on Vice, crashes when launched from Ultimate (copy protection action)
The game loads in Vice only with Drive 8 on IEC, otherwise it hangs.
bushido.zip
Interesting... So in other words, the G64 itself is correct, but the drive emulation using this file is not?
I created the G64 using real 1541-II and U2+. TurboNibbler4 program. G64 works on Vice and pi1541, not on U2+ (protection triggers crashing game while loading)
Interesting... So in other words, the G64 itself is correct, but the drive emulation using this file is not?
I don't know if it's correct, Turbo Nibbler 4 was the only one that allowed me to create a working (in Vice/pi1541) G64. I would have to try other variants, e.g. with pi1541,.
Unfortunately, pi1541 can't copy with the same method. Hangs when trying to write first sector to g64. I am unable to compare then.
Can you recommend a reliable copying program that I should test with U2+?
BTW As far as I know, there is no G64 from this game is available for download.
I was able to copy the original onto another real floppy using the 1541-II With the same program, TurboNibbler4 The copy on real floppy disk works fine. So the choice of the program to be copied is rather correct. It's quite possible that my G64 is also OK. Whether these protections can be transferred from the G64 back to a real floppy, I have no idea.
Well, you can of course try to use this copy program to copy from U2 or from Pi1541 to a real floppy...
Z64K produces the same result as U64, that is, a crash with vertical stripes on the screen.
This is a copy protection check failure. The game first loads using kernal routines, then on track 5 the check fails and then jumps to code which clears memory and jumps to Kernal reset routine.
The interesting part of the code seems to begin at $1000. The execution eventually leads to resetting the machine as described above.
Well, you can of course try to use this copy program to copy from U2 or from Pi1541 to a real floppy...
I tried: u2+, g64 to g64, failed u2+, g64 to real floppy, failed pi1541, g64 to real floppy, failed pi1541, real floppy to g64, failed Vice, g64 to g64, failed
those wild copy protection needs some improvement in emulation on all platforms I guess ;)
When program execution reaches
$1092 JMP $0330
then VICE has the following code
and continues loading, but Z64K (and apparently U64 goes with Z64K) has the following, the check having failed.
So Gideon's initial assessment seems correct, it seems that the disk is not failing, but the emulation is.
This part of the code translates the code to $0330. Only Kernal I/O appears to be used until that point.
I saw a load from $DE00... Isn't this a "should have read a VIC byte" problem?
I saw a load from $DE00... Isn't this a "should have read a VIC byte" problem?
It does not seem to. The reset routine is already placed at $0330- at that point. The code seems to be loaded from different place on success/failure.
This may be important information: I've also downgraded U2+ to FW3.10a to compare the g64 copy. On an older FW, the g64 created fails the copy protect test, and always crashes the same way.
I also tested Turbo Nibbler 4, Maverick and FastHackem on FW 3.10a and FW3.10j Not once have I been able to create a g64 that passes the copy protect test.
Only version 3.10j + TurboNibbler4 managed to do this in Vice/pi1541
I saw a load from $DE00... Isn't this a "should have read a VIC byte" problem?
The code opens two files, number 2 and 3, for writing and then reads the code from file 3. Pass and failure seem to give different loaded code.
The code opens two files, number 2 and 3, for writing and then reads the code from file 3. Pass and failure seem to give different loaded code.
"write" is to floppy disk? Is this "write" to prevent attempts to unprotect and modify the code directly on the floppy?
The code opens two files, number 2 and 3, for writing and then reads the code from file 3. Pass and failure seem to give different loaded code.
"write" is to floppy disk? Is this "write" to prevent attempts to unprotect and modify the code directly on the floppy?
I cannot give a definite answer, it seems to have something to do with the physical disk surface. Vice reads the code from track 2, Z64K from track 5.
Does it change anything if the floppy is write-protected, or when g64 is write protected?
What if the stepper motor is pulsed very fast; so fast that real hardware will not follow it, but most emulators do? The head will end up on another track.
Message ID: @.***>
This is what it looks like on real hardware: Movement of the drive head while loading the game. Link to video 135MB mp4 https://mega.nz/file/uU5RyAQB#9hdah7JUTHHntZMReQZttOYPqNu6ywsrbi_x4eUlfNE
A copy directly from the original floppy to a real floppy (backup no.1) works. Single 1541 drive. But TurboNibbler4 doesn't manage to copy from it a second time. (from backup no.1 real floppy to-> backup no.2 real floppy). He has trouble reading tracks 18, 21, 24 that he created himself earlier.
So, all G64 -> real floppy or G64 -> G64 copying problems are confirmed on real hardware This is normal behavior.
Conclusion: TurboNibbler4 does not make a perfect 1:1 copy of the original. Despite this, such a first copy from the original game itself works fine on the real 1541-II disk drive (and the first G64 works in Vice and on pi1541)
I made g64 working with Ultimate. I used g64 from the first post, copied it in Vice with Burstnibbler1.9 (Single 1541 Drive copy, emulating connected parallel UserPort and 10KB extra drive RAM in disk drive) The resulting g64 works in U2+
I have experimented with many many copy programs.
This is the third original protected game I copy with Ultimate. And every time I had to do it the same way (first g64 copy again on Vice to g64 using some copy program - otherwise it won't work with ultimate)
At the moment my friend to whom the original belongs is testing whether it is possible to go through the entire game on this g64 on U2+
Conclusion: One of the problems is already in the g64 modification stage when copying a real floppy with u2+ to g64 U2+ Creates G64 That Goes Beyond 'Specs' Unfortunately, this is just my speculation. I've attached the link to the g64 that works this time https://mega.nz/file/6VITlDKS#wUEtsEaJePexSBLJhBzzHAMIaq1Nz_fayBeXlq3SSKM
This new .g64 file fails on U64 and on Z64K, but Hoxs64 runs it.
It must be some kind of devilish magic ;(
I tested more and often the game appears to load, especially if mounted from the RAM disk. Not only 1541 but also 1571 seems to work. So the "VIC byte problem" can be ruled out.
Other times it fails, executing the reset code above.
I've noticed that sometimes even the original has some problems. The real C64 and 1541-II must be reset before LOAD (using the Power Switch). This ensures that the game will always start.
-- I have similar symptoms in Vice. If I do some disk operations then the game won't load. A Hard Reset is required in Vice.