| |
Krill
Registered: Apr 2002
Posts: 2844 |
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? :) |
|
... 23 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Quoting FungusI think the format should retain all the user mode data as well as the data that any fast copy would give. That includes sector headers and data at the end of user mode sectors. Which data at the end of user mode (?) sectors are you referring to?
Quoting FungusIt's already established that stuff does make use of it and fails to work if it doesn't have it. It's not any special data or protection or anything, it's just data that's expected to be there that isn't. And which stuff fails there, and why?
Quoting FungusSame as G64 doesn't have variable bit length of tracks, it's just a short sighted bug. Having byte-sized tracks is a limitation, but not a bug.
And the upside is that it forces image creators to properly align track data such that the tail gap is at the ends of the track data, rather than payload data wrapping from tail to head.
When copying, you do write out track data byte-wise, after all. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
adam : Dexion Meeting Demo Disk
obviously not released as g64 but only works with it and needs to be nibbled when copied natively, hopefully 6pack works the same. |
| |
Adam
Registered: Jul 2009
Posts: 321 |
Quote: adam : Dexion Meeting Demo Disk
obviously not released as g64 but only works with it and needs to be nibbled when copied natively, hopefully 6pack works the same.
thanks, ian! I have not seen this one before! was really good. |
| |
spider-j
Registered: Oct 2004
Posts: 445 |
I must admit as I have always been a fan of releases being "filecopy-able" (kudos to the inventor of IFFL \o/) I don't miss anything in our "modern world" where D64 has been kind of the "standard release format" for new releases. And while that random directory feature in this demo here may be interesting on a technical level it's nothing that I'd personally watch more than once anyway.
Of course preserving old disks is another topic. Never tried it myself, but thought using nibtools is a lossless solution in that regard (?). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11116 |
adam: there were a few, some masters designs demo comes to mind (but i dont remember which). Often those were made using vmax (or some variant).
I dont understand what fungus is trying to say either - there is no commonly used "extra data" on a disks besides the already mentioned disk id in headers. Everything else is pretty much only used on protected disks, which will then need g64 for different reasons anyway. |
| |
Clarence
Registered: Mar 2004
Posts: 119 |
Digital World / Samar ended up in my collection as .g64 as well. Don't remember how I've got the files, but the current working download contains 'sixpack zipfile' format only. |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Quoting ClarenceDigital World / Samar ended up in my collection as .g64 as well. Don't remember how I've got the files, but the current working download contains 'sixpack zipfile' format only. That'd be because of 40 tracks. Otherwise it's quite standard, iirc. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
confirmed working as 40tracks d64s, added to the entry for convenience already converted the g64 to d64 with 64copy from the c64.ch mirror |
| |
Fungus
Registered: Sep 2002
Posts: 617 |
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. |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Quoting FungusThe 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 FungusAs 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 FungusTons 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 |
