Denise C64 mode problems!

[PiCiJi]

Originally Posted by amilo3438

chessmaster_2100_s1[software_toolworks_1988](patched) ... It already exists, if we can assume that the patched version was manually edited in the same way! (tested to work in denise)

Improbable. Copy protections with variable bit cell density on same track should simply not be used with a G64 or, in the case of the Amiga, ext. ADF. For this purpose, a flow change format should be taken. If not, it's technically a hack to handle the copy protection, similar to a D64 or ADF.

Originally Posted by amilo3438

But not everything is so simple! We learned something from all this, and that is that there are situations when we suspect that the g64 is faulty, but it just needs some specificity in the settings, eg a different version of the disk drive, or in the start command (":*" instead of "*" ), or it needs to be started by entering the file name because it is not at the beginning of the disk, or TV standard (PAL or NTSC), that could have an effect on making it work.

The problem is, you don't know if a G64 is okay just because it works with 1541, but not with 1541-II.
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.

Originally Posted by amilo3438

In fact, the focus now seems to be on finding something that would work on one of the other emulators and not on denise! (to make collection of examples)

yes that would help to draw some conclusions.

Originally Posted by amilo3438

Any idea if Denise is having trouble with any of the more complex protections?

VMAX should be working.
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).

[r.cade]

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.

[PiCiJi]

Originally Posted by r.cade

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.

That's right, that's what the specification provides. I haven't thought about that for years. At that time I could not find a G64 that provides data for this. Are there any ?

The effort to emulate this information with a G64 is quite large.
The P64 is much better suited for this.

[PiCiJi]

"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

[r.cade]

Originally Posted by PiCiJi

"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

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.

[amilo3438]

Your experiences with NIBTools? --> https://www.lemon64.com/forum/viewtopic.php?t=66621

Originally Posted by LordCrass@lemon64

There's only 3 main protections I've seen nibtools stuggle with, and for 2 of them, it's because of how the 1541 works. Vorpal 2, V-Max, and fat tracks.

Vorpal 2 working g64 --> https://www.lemon64.com/forum/viewtopic.php?t=82930

Originally Posted by LordCrass@lemon64

As I mentioned, I used a 1541 with a Super-Card in it and the Super-Card GCR nibbler program to copy the original disk with the destination being a g64 image in a pi1541.

Vorpal2 protected, or "vorpal - newer" if you search for in c64pp database, properly imaged and converted to g64! It is tested to work on denise in ntsc mode without problem!

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)

[r.cade]

Originally Posted by amilo3438

Your experiences with NIBTools? --> https://www.lemon64.com/forum/viewtopic.php?t=66621



Vorpal working g64 --> https://www.lemon64.com/forum/viewtopic.php?t=82930



Vorpal2 protected, or "vorpal - newer" if you search for in c64pp database, properly imaged and converted to g64!
It is tested to work on denise ntsc mode without problem!

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)

They need extra processing that I never built into nibtools. There is another program that does this now for V-MAX and Vorpal and others.

[amilo3438]

Originally Posted by r.cade

They need extra processing that I never built into nibtools. There is another program that does this now for V-MAX and Vorpal and others.

Thanks, then can we agree that they are technically defective!? (in the current state both... nbz and g64) EDIT: Oops, sorry, I got it wrong, they need another tool for extra processing!

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

Originally Posted by LordCrass@lemon64

If you decide to edit G64 files, you might want to check out g64conv which can convert the file to a text format where you can more easily edit it as sectors are shown, sync marks separated from data, etc. After modifications, convert it back.

Is it a good tool or is there something else but with a graphical interface!? EDIT: Yes, another one good and with GUI = CBM Flux Studio! --> https://luigidifraia.wordpress.com/2...lds-available/ (in the alpha phase)

----------

@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.)

[amilo3438]

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

[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)

It is evident from the above that it had no effect on micro64 and x64sc, while denise managed to run two examples and hoxs64 none! (Note: In denise with 1541-C, same drive as in hoxs64, worked tests C298,299 & 300!)

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...

[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

Micro64 and x64sc seems immune to many changes in nibtool/nibconv options, and hoxs64 is only one that didn't manage in any of tests!
In Denise, the test called "d* = denise + unchecked motor deceleration!" seems the most compatible! (only 2 tests failed)