30 July 2024, 22:49 | #41 | ||||
Registered User
Join Date: Sep 2003
Location: germany
Age: 45
Posts: 480
|
Quote:
Quote:
It is more likely that the G64 is not completely clean. Slight deviations, such as different firmware (1541, 1541C, 1541-II) or disk wobble, should not be enough to cause a problem. Quote:
Quote:
oscillation (weak bits) should be working. Honestly, with formats like IPF or P64, nothing special needs to be emulated to handle all copy protections. Unfortunately, no group has set itself the task of mapping C64 originals as P64 (IPF). |
||||
30 July 2024, 22:53 | #42 |
Registered User
Join Date: Aug 2006
Location: Augusta, Georgia, USA
Posts: 558
|
Actually, a G64 track can contain multiple densities. It's just that no emulators (that I know of) support that, and it must be manually constructed anyway.
|
30 July 2024, 23:16 | #43 | |
Registered User
Join Date: Sep 2003
Location: germany
Age: 45
Posts: 480
|
Quote:
The effort to emulate this information with a G64 is quite large. The P64 is much better suited for this. |
|
31 July 2024, 08:59 | #44 |
Registered User
Join Date: Sep 2003
Location: germany
Age: 45
Posts: 480
|
"chessmaster_2100_s1[software_toolworks_1988](multi_density)(!).g64"
checked with nibscan: 0 tracks with non-standard density a quick look with an hex editor shows only standard speedzone entries. The necessary information is missing here to emulate this G64 |
31 July 2024, 14:00 | #45 |
Registered User
Join Date: Aug 2006
Location: Augusta, Georgia, USA
Posts: 558
|
Correct - to my knowledge nobody has constructed a multi-speed zone G64, and no emulator supports it. It would be very hard to detect that it exists via any automated tool, so it would have to be manually created.
|
31 July 2024, 17:38 | #46 | ||
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,597
|
Your experiences with NIBTools? --> https://www.lemon64.com/forum/viewtopic.php?t=66621
Quote:
Quote:
The ones from the testing collection, created by nibtools, don't seem to work , so not sure if they can be declared technically defective! (or they just need some other additional processing in nibtools) |
||
31 July 2024, 17:39 | #47 | |
Registered User
Join Date: Aug 2006
Location: Augusta, Georgia, USA
Posts: 558
|
Quote:
|
|
31 July 2024, 17:47 | #48 | ||
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,597
|
Quote:
Can I assume then that the same applies to most v-max and rapidlok images too!? (from the collection) EDIT: I'll have to check that out first! (and then conclude) EDIT: Found the tool and videos with some explanations! --> https://www.youtube.com/@thechaosengineer/videos (look for "cbm flux studio" videos) Such as this one (among others) --> Comparing G64 generated from NIB and KryoFlux RAW files --> [ Show youtube player ] ---------- Editing G64 --> https://www.lemon64.com/forum/viewtopic.php?t=76624 Quote:
---------- @r.cade Thanks for the information I found on your site! (found under your signature) Edit: The past few days I have enjoyed reading and studying everything I found there. Now a lot of things are clearer to me, especially regarding how 1541 sees and reads tracks & sectors! (and also sync, header, data, gaps etc.) Last edited by amilo3438; 01 August 2024 at 13:11. |
||
01 August 2024, 14:25 | #49 |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,597
|
Comparison among emulators when a g64 is created by using different options:
filename = out_run_s1[us_gold_1988](pal)(!) nibconv [option] filename.nbz filename.g64 Code:
[option] -c = disabled automatic capacity adjustment -C = simulate track capacity: 0RPM -Cxxx = simulate track capacity: xxxRPM Edit: d+1541 = denise + 1541 + checked motor deceleration! d* = denise + unchecked motor deceleration! d*+1541 = denise + 1541 + unchecked motor deceleration! [option] ....... emulator status --------------------------------------------------------------------------------------- -c...... micro64(+), x64sc(+), denise(-), hoxs64(-), Edit: d+1541(+), d*(+), d*+1541(-) -C...... micro64(+), x64sc(+), denise(-), hoxs64(-), Edit: d+1541(+), d*(+), d*+1541(-) -C297... micro64(+), x64sc(+), denise(+), hoxs64(-), Edit: d+1541(-), d*(-), d*+1541(-) -C298... micro64(+), x64sc(+), denise(-), hoxs64(-), Edit: d+1541(-), d*(+), d*+1541(-) -C299... micro64(+), x64sc(+), denise(+), hoxs64(-), Edit: d+1541(-), d*(-), d*+1541(-) -C300... micro64(+), x64sc(+), denise(-), hoxs64(-), Edit: d+1541(+), d*(+), d*+1541(-) --------------------------------------------------------------------------------------- + = loading & working - = not loading Notes: - micro64() uses 1541 + mechanical emulation! - x64sc() uses 1541-II + truedrive emulation! - denise() uses 1541-II + enabled motor deceleration - hoxs64() uses 1541-C + emulated motor deceleration (if I can tell) EDIT: Added in test... d+1541 = denise + 1541 + checked motor deceleration! -> This differs a lot from 1541-II drive test!? (in the test under denise) d* = denise + unchecked motor deceleration! -> If in denise emulated motor deceleration is disabled than works ones that didn't and vice versa! (if 1541-II disk drive is used) d*+1541 = denise +1541 + unchecked motor deceleration = none worked! -------- Also, the original "out_run_s1[us_gold_1988](pal)(!).g64" from the collection (reported in post#1) works fine on 1541 in denise! (while with 1541-II drive it crashes into basic) Hmm, I wonder if it's wrong that I started this whole test with a 1541-II disk drive in denise instead of a 1541!? But then again, x64sc also use 1541-II by default (-deceleration)! (Anyway, I'am confused, although the d* test is very close to vice!) I wonder if the original disk would work on both real disk drives without problems!? -------- Another example: If above test is using other options... Code:
[option] -aa = custom alignment: autogap -r = disabled sync reduction -C300 = simulate track capacity: 300RPM [option] ----------------------------------------------------------------------------------------- -aa -C300 ...... micro64(+), x64sc(+), denise(-), hoxs64(-), d+1541(-), d*(+), d*+1541(-) -aa -r -C300 ... micro64(+), x64sc(+), denise(-), hoxs64(-), d+1541(+), d*(+), d*+1541(-) ----------------------------------------------------------------------------------------- + = loading & working - = not loading In Denise, the test called "d* = denise + unchecked motor deceleration!" seems the most compatible! (only 2 tests failed) Last edited by amilo3438; 01 August 2024 at 18:21. |
02 August 2024, 15:31 | #50 |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,597
|
22) rodland[sales_curve_1989](pal) ... On all emulators it loads and everything seems fine until it shows the game screen where it then freezes with cpu jam!
Wanted to report this as an emulator problem, but manage to run it after conversion from nbz with -aa option! (Seems to be working fine now in all emus!) -------------- After conversion from nbz with -aa -r options it works in denise with wobble enabled! (But it still doesn't work in hoxs64, although it does in Denise with a 1541-C disk drive!) Last edited by amilo3438; 02 August 2024 at 18:12. |
02 August 2024, 20:13 | #51 | |
Registered User
Join Date: Aug 2006
Location: Augusta, Georgia, USA
Posts: 558
|
Quote:
https://github.com/DarylKrans/ReMaster-Utility |
|
02 August 2024, 20:49 | #52 | |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,597
|
Quote:
EDIT: Delighted! Thanks again and to your friend for this perfect tool! ----- PS. For info... Converted all vorpal_newer nbz from the collection with the new remaster-utility and tested in denise emu, but noticed one problematic! "the_games_winter_edition_s1[epyx_1988](ntsc)_ReMaster" ... Remastered with the above ReMaster-Utility! Select one player and all events. After opening it says "Next Event: Luge" and stops at track 16! If in the meantime, at the moment it says "Next Event: Luge", while it's still on track 10, replace the disc with a verified one from the vorpal2 collection (see post #46), the game won't stop on track 16, but it will continue to load! (now, or the nbz file is broken or something went wrong in remastering!?) (Note: Tested several versions created with different options in the utility and nothing helped to solve the problem!) Otherwise, the tool did also a great job with another problem: "out_run_europa_s1[us_gold_1992](pal)(!)" (didn't do anything special... drag and drop, answer yes and export... and it works now) ----- Last edited by amilo3438; 03 August 2024 at 20:41. |
|
03 August 2024, 19:42 | #53 | |
Registered User
Join Date: Sep 2003
Location: germany
Age: 45
Posts: 480
|
Quote:
For testing, Wobble is disabled in both emulators. I'm not sure if that's a bug in Denise. As soon as I'm done with the Metal Driver, I'll take a closer look at it. |
|
03 August 2024, 20:53 | #54 |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,597
|
23) uridium[hewson_1986](pal) ... If re-converted from nbz with nibconv -r option = works! (or with remaster-utility)
24) zynaps[hewson_1987](pal) ... same as above! Note: I notice that the "-r" option in nibconv makes a lot of things work! (wonder why it's not on default) -r = disabled sync reduction Last edited by amilo3438; 03 August 2024 at 21:54. |
03 August 2024, 22:55 | #55 |
Longplayer
|
It's been a long time since i messed with g64 files but if memory serves, the G64 files that were packaged with Gamebase were changed to work around a bug of Vice and g64 support and nibconv -r makes them back into how they should be as the now fixed vice doesnt work with those old modified g64 files. what a mess!
|
04 August 2024, 12:31 | #56 | |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,597
|
Yes we are aware about old g64 files possible problems, after r.cade clarified it nicely...
Quote:
------ Since during testing I had accumulated a number of g64 files that did not want to start, I said let's try to see if I can fix some! I've had a lot of success with reconverting nbz to g64 with nibconv -r, -aa, or both -aa -r options, or with using the remaster-utility (with drag'n'drop and export) if nibconv didn't work or vice versa! (I would say that was 90% successful.) With the 10% what left I'll deal later! (maybe just need some other option in nibconv or are incorrect.) PS. Instead of nbz, I probably could have used an existing g64 and tried to reconvert again, but I wasn't sure how successful it might be! (although I've noticed that sometimes it works too) ------ PS. Not sure why "CBM Flux Studio" complains about "ReMaster-Utility" generated g64 while nibscan or any emu see no problem! Last edited by amilo3438; 04 August 2024 at 13:23. |
|
06 August 2024, 14:36 | #57 | |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,597
|
Finished testing v-max v4!
Tested v-max from the v4 group --> all worked after "running nbz through" the remaster-utility, except: galaxian[thunder_mtn_19xx](vmax4) ... It was necessary to process nbz additionally with nibconv -r and then with remaster-utility! galaxian[thunder_mtn_19xx](vmax4)(alt1) ... Something is wrong with this one! (nothing helped and the utility also complains) Note: Didn't use a single option on remaster-utility, every box was unchecked! Then tested everything on emulators and only micro64 had problems with some! PS. The C64PP database says for galaxian: "uses 6522 timers in drive to calculate keys, not working in current emulators" (but not true anymore, because it works now) EDIT: https://www.cbmstuff.com/forum/showt...pid=326#pid326 Quote:
Last edited by amilo3438; 09 August 2024 at 15:46. |
|
07 August 2024, 14:48 | #58 | ||
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,597
|
Some more examples of comparison...
(1) filename = andy_capp[mirrorsoft_1987)(pal) (2) filename = out_run_s1[us_gold_1988](pal)(!) (3) filename = falcon_patrol[advantage_1983] Code:
nibconv -an -C -r -f filename.nbz filename.g64 -an = custom alignment: raw (no alignment, use NIB start) -C = simulate track capacity: 0RPM -r = disabled sync reduction -f = enabled level 0 'bad' GCR reproduction ---------------------------------------------- (1) micro64(+'),x64sc(+'),denise(-'),hoxs64(+') (2) micro64(+), x64sc(+), denise(+), hoxs64(-') (3) micro64(+), x64sc(+), denise(+'),hoxs64(+) ---------------------------------------------- + = loading & working - = not loading - For test (1): Without the -f option in nibconv, even without using other options, the game won't start at all! Also, converting the nbz with remaster_utility doesn't help here! 'EDIT: Regarding hoxs64, it works after resetting its settings to default in settings/load settings! I noticed that the c1541.rom inside the hoxs64 folder have same CRC as denise's VC1541-II, but in the emu is set as 1541C compatible! Note: The created g64 seems sensitive in other emulators as well, so it is necessary to try it several times until it works! 'EDIT2: Hoxs64 has an option under Disk to save the loaded disk as p64. If that p64 is loaded into denise it will work with the 1541-C drive! - For test (2): If the nbz is converted with remaster utility, denise becomes immune to RPM change inside denise emulator! (from -275 to 325 RPM, all works) 'EDIT: The remaster-utility version is only one that works in hoxs64! - For test (3): In denise works with 1541 or 1541-C drive but not with 1541-II, where in x64sc or micro64 with the 1541-II rom, works fine! EDIT: Hoxs64 seems also use 1541-II rom! 'EDIT3: If remaster-utility version is created from nbz and saved in p64 format in hoxs64, it will work in denise with 1541-II drive! PS. I wanted to do a test with all automatic options turned off in nibconv! (but not sure if maybe I left something out) --------- Other... What I generally noticed is that the g64, which has a longer sync, eg 40, is much more stable in operation, especially in denise! (problematic ones usually have much less bits) The g64 spec is here: http://ist.uwaterloo.ca/~schepers/formats/G64.TXT Here's what the g64 spec says: Quote:
Ok, in nibtools_readme.txt i found this under -r[n] ... Quote:
PS. Just found yet another tool for analysis: DDR64 V0.99 Beta ! --> https://csdb.dk/release/index.php?id=218378 (so let's see and check what it can do) --------- Important: Above comparison tests refers to g64 files created from nbz with nibconv or remaster-utility! If it was created using another method, eg kyroflux or similar, this comparison test does not apply to such files! (because they work without problem, as I was told... unfortunately, such files are not available) So, I'm not sure if it makes sense to continue because it seems like this testing is turning more and more into looking for existing g64 files that works or fixing if it doesn't, rather than actually to testing the emulator! There is very little chance of finding something that would work in other emulators and not in denise, especially after the fix, so this testing doesn't make sense anymore to me! Last edited by amilo3438; 09 August 2024 at 18:26. Reason: Other... Updated! |
||
09 August 2024, 13:31 | #59 | |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,597
|
Found a little something else interesting: --> https://www.cbmstuff.com/forum/showt...pid=302#pid302
Quote:
-------------- But there's also example where it works on denise and hoxs but not on vice and micro64... Code:
filename = star_trekking_ii[ufland_1986] nibconv -an -C -r -f filename.nbz filename.g64 -an = custom alignment: raw (no alignment, use NIB start) -C = simulate track capacity: 0RPM -r = disabled sync reduction -f = enabled level 0 'bad' GCR reproduction ------------------------------------------ micro64(-), x64sc(-), denise(+), hoxs64(+) ------------------------------------------ + = loading & working - = not loading Last edited by amilo3438; 09 August 2024 at 17:42. |
|
10 August 2024, 18:25 | #60 |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,597
|
Found one problem in denise ntsc mode:
--> gauntlet_deeper_dungeons[us_gold_1987](ntsc) --> (It is V-Max v2, according to remaster-utility!) I created also a new g64 from nbz by using remaster-utility (file1) and then with "nibconv -an -C -r -f file1.g64 file2.g64" made another g64 (file2). (in The Zone!) Note: In remaster-utility all boxes has been unchecked before export! Now, if I drag'n'drop any of the newly created files on latest Vice3.8 (x64sc) in NTSC mode, they will work! If drag'n'drop in denise nightly with NTSC VIC-II, they won't work, i.e. they will behave like in Vice3.2 (x64sc) NTSC mode... stops at track 19 and than reset! (didn't check vice versions in between) EDIT: Same happens for 2 more files! (The Zone! updated) --> gauntlet[mindscape_1987](vmax2)(newer) --> harrier_combat_simulator[mindscape_1986](vmax2) EDIT2: Rechecked in older versions of vice in ntsc mode... GTK3VICE-3.7-win64 ... works! GTK3VICE-3.6-win64 ... works! GTK3VICE-3.5-win64 ... works! GTK3VICE-3.4-win64 ... works! WinVICE-3.2-x86 ........ doesn't work! (ie. behaves the same as in denise) Couldn't find working version of Vice3.3 to test! -------------------- Other... some new findings: In the folder "vmax" there's a "non-working" folder with --> superstar_ice_hockey[mindscape_1987](vmax).nbz (+alt1 to alt3)! But if run through remaster-utility (no options) it will work! You just have to make sure that the disk drive write protect is unchecked! (tested to work in denise and vice3.8) PS. Same applies to --> superstar_ice_hockey[mindscape_1987](para-protect)(pal).g64 --> Unprotect the disk! Otherwise it will stop at track 18 with led blinking! Last edited by amilo3438; 11 August 2024 at 13:43. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Blitter line mode problems | deimos | Coders. General | 23 | 10 October 2019 10:10 |
Celtic "Meeting Demo", Timing problems in Cycle Exact Mode | StingRay | support.WinUAE | 5 | 26 January 2018 15:15 |
Mani Pulite sprite problems (A500 mode) | andreas | support.WinUAE | 17 | 22 January 2015 14:41 |
Super72 mode problems | mark_k | support.WinUAE | 8 | 16 March 2014 11:16 |
Problems with Detect Idle CPU mode | bdoe | support.WinUAE | 6 | 27 September 2002 13:44 |
|
|