[CSDb] - User Forums - Release id #229327 : JustinBlue

You are not logged in - nap

CSDb User Forums

Forums > CSDb Entries > Release id #229327 : JustinBlue

2023-11-05 11:44

Krill

Registered: Apr 2002
Posts: 2940

Release id #229327 : JustinBlue

Wondering about this demo coming on G64 images.

Upon a quick and nowhere near thorough inspection, the demo uses DreamLoad, 35 tracks, standard Commodore GCR and plain 254-payload-bytes-with-T/S-link file format.

So there doesn't seem to be any kind of speed or storage capacity enhancing format involved.

Why not D64? :)

... 30 posts hidden. Click here to view all posts....

2023-11-07 20:01

iAN CooG

Registered: May 2002
Posts: 3177

confirmed working as 40tracks d64s, added to the entry for convenience already converted the g64 to d64 with 64copy from the c64.ch mirror

2023-11-08 02:30

Fungus

Registered: Sep 2002
Posts: 668

The last new bytes in a GCR stream are unused, that's what I mean, these can used. 325 doesn't evenly divide, remember sectors are GCR bytes and not an even number of bytes.

As for G64, having them byte aligned is a bug. Many protections take advantage of tracks not being perfectly byte aligned. It breaks V-Max and Datasoft protections, Pirate Slayer, etc. I'm sure there is others that mess around with stuff in the tail gap, and check tail gap size. If you can think it up, someone did it.

Tons of Talent cracks don't work because of the disk id thing, there a loader that was written on the directory track. I fixed a few of them, Mason did too. Lots of old old cracks don't work either because of it.

2023-11-08 07:33

Krill

Registered: Apr 2002
Posts: 2940

Quoting Fungus

The last new bytes in a GCR stream are unused, that's what I mean, these can used. 325 doesn't evenly divide, remember sectors are GCR bytes and not an even number of bytes.

Ah, you mean the 4 "don't care" bits in a block's final GCR byte.
While these are don't care as far as the DOS is concerned, it always writes out a specific pattern (%0101 i believe, as it's part of a GCR-encoded 0-nibble %01010).
So it's alright for D64 not to store a custom pattern, and for custom loaders to insist on the default %0101.

Quoting Fungus

As for G64, having them byte aligned is a bug. Many protections take advantage of tracks not being perfectly byte aligned. It breaks V-Max and Datasoft protections, Pirate Slayer, etc. I'm sure there is others that mess around with stuff in the tail gap, and check tail gap size. If you can think it up, someone did it.

I was under the impression that not even industrial duplicators could guarantee specific track lenghts (at least without retrying, which slows down the process).
The disks would always be subject to wobble, wow and flutter.
If a protection would measure the length of the tail gap and expect a specific number of bits, i'd assume that "tail gap" to be a decoy and the actual tail gap to be somewhere else on the track, e.g., a variable-size sync mark.

Quoting Fungus

Tons of Talent cracks don't work because of the disk id thing, there a loader that was written on the directory track. I fixed a few of them, Mason did too. Lots of old old cracks don't work either because of it.

We agree on D64 sorely missing a disk ID field.

As D64 is reliant on file size already (35 or 40 tracks, with or without error map), wouldn't having an additional optional 2 bytes for the disk ID still allow for non-ambiguous D64 sub-type determination? :) Surely emulator makers etc. have thought about this?

Previous - 1 | 2 | 3 | 4 - Next

Refresh

Subscribe to this thread: