| |
Krill
Registered: Apr 2002
Posts: 2858 |
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? :) |
|
| |
iAN CooG
Registered: May 2002
Posts: 3142 |
The random dir layout seems not working on d64 but on g64, in other words, only an emulation problem.
Other than that, there is really no other reason.
The d64 images were added and then removed because the graffity guys got their pants twisted when the d64s got added to the entry. |
| |
Krill
Registered: Apr 2002
Posts: 2858 |
Quoting iAN CooGThe random dir layout seems not working on d64 but on g64, in other words, only an emulation problem. Sounds more like a questionable implementation on the demo side to me, relying on a specific sector layout or skew or similar, and breaking randomly when using a different drive, Action Replay or copying from one real disk to another.
Nothing i'd blame on emulation. =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11157 |
Quote:only an emulation problem.
That seems unlikely - nothing the regular DOS does requires a G64 |
| |
Krill
Registered: Apr 2002
Posts: 2858 |
See also: Release id #210333 : Babes |
| |
Krill
Registered: Apr 2002
Posts: 2858 |
Quoting iAN CooGThe random dir layout seems not working on d64 but on g64, in other words, only an emulation problem. Okay, so they have multiple blocks on track 18 that identify as sector 0 or sector 1, such that loading the dir will be randomised.
This works fine in emulation.
It doesn't map to D64, of course, and wouldn't survive regular disk backup. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11157 |
https://pastebin.com/Q8K3rqs3
Yep, indeed :) The "doesn't survive regular disk backup" bit bothers me a bit however - the disk would circulate as "broken" versions in no time, noone would bother doing nibble backups of that demo (as it keeps working fine).
If the demo would rewrite the dir track when it starts... then it could magically fix itself :) |
| |
Krill
Registered: Apr 2002
Posts: 2858 |
Quoting chatGPZIf the demo would rewrite the dir track when it starts... then it could magically fix itself :) Had the same thought. But then it occured to me that people back then would probably have given up already at the backup program choking on errors when reading (missing blocks). =)
So the demo would have needed to come with its own copy program. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11157 |
Not sure... what would eg copying with AR result in? wouldnt it just write out a complete (working) track 18? |
| |
Krill
Registered: Apr 2002
Posts: 2858 |
Quoting chatGPZNot sure... what would eg copying with AR result in? wouldnt it just write out a complete (working) track 18? Seems to work.
Copy program took a little longer to read in track 18, but didn't complain.
Copy has a fixed non-random directory, of course. |
| |
Clarence
Registered: Mar 2004
Posts: 119 |
Cheesion tried hard not go the .g64 way, but iirc with .d64 the demo would not boot on a vanilla c64 (with a fastload cartridge it would, but then it's not a traditional c64 demo anymore).
Side 2 was created as a .g64 only for 1541u users' sake, so the "long press to auto-attach next disk method" works (if side 1 is .g64 and side 2 is .d64 it wouldn't work).
"graffity guys got their pants twisted when the d64s got added to the entry"
If someone comes up with a .d64 that works identical to the .g64 version, it is welcomed, but this was *not* the case.
What people must understand, the randomized directory is the first effect of the demo (a serious 'drive fx' never done before, read the technical note if interested). Wheter people like it or not, it's the official version. If someone disregard it with a simplified .d64 version, and wishes to spread it, then must upload it as a 'crack' in a separate release. |
| |
Krill
Registered: Apr 2002
Posts: 2858 |
Quoting ClarenceWhat people must understand, the randomized directory is the first effect of the demo (a serious 'drive fx' never done before, read the technical note if interested). Wheter people like it or not, it's the official version. If someone disregard it with a simplified .d64 version, and wishes to spread it, then must upload it as a 'crack' in a separate release. Understood*.
However, the point is that it would have most likely spread in a broken version back in the days, without a custom copy program included.
* The "explanation" in the note is rather inaccurate, to put it mildly. =) |
| |
Clarence
Registered: Mar 2004
Posts: 119 |
Turbo nibbler should have worked back then.
Unfortunately I cannot speak for Cheesion, hopefully he will pop up here for clarification of details. |
| |
Krill
Registered: Apr 2002
Posts: 2858 |
Quoting ClarenceTurbo nibbler should have worked back then. Sure would, but who did copy demos as if they were protected games? :) |
| |
bugjam
Registered: Apr 2003
Posts: 2511 |
But back then, you'd include the info of how to copy the demo in the dir (as you would include "kill cartridge" or "don't validate"). :-) |
| |
Krill
Registered: Apr 2002
Posts: 2858 |
Quoting bugjamBut back then, you'd include the info of how to copy the demo in the dir (as you would include "kill cartridge" or "don't validate"). :-) Not sure the swappers would even notice. =) |
| |
Fungus
Registered: Sep 2002
Posts: 631 |
D64 doesn't contain sector headers, so broken disk id is a problem. Also a lot of tools don't really read t/s links on the directory track as noted and some expand to track 19 (like Fast Hack'em did) and so they don't work in d64.
These are known issues are they not?
Back then we used zipcode to transfer whole disks, and such things were preserved. |
| |
Krill
Registered: Apr 2002
Posts: 2858 |
Quoting FungusThese are known issues are they not? Yes, so not quite sure what your point is. :)
(Directory expanding from track 18 to track 19 should work fine with D64, though.) |
| |
Fungus
Registered: Sep 2002
Posts: 631 |
Well some loaders will fail, plenty of cracks are broken because of that, I would assume demos might be broken too depending on what loader they are using and who coded it. They aren't bulletproof as your system is.
Certain things assume the directory track is laid out in a certain way and don't read the links, which would break stuff. There's a few directory editors that are like that.
I'd personally prefer stuff just be on G64 anymore, D64 has issues and is not a very good format, same as T64. |
| |
Krill
Registered: Apr 2002
Posts: 2858 |
Loader shortcomings are a different animal than disk image limitations.
The only thing that D64 seriously lacks is a field for disk ID, everything else is fine for what it does. |
| |
Fungus
Registered: Sep 2002
Posts: 631 |
Not really, the unused bytes at the end of sectors aren't in it either.
Personal preference I guess, just glad I kept all my zipcode files so I have working releases. |
| |
Krill
Registered: Apr 2002
Posts: 2858 |
Quoting FungusNot really, the unused bytes at the end of sectors aren't in it either. Eh, if you need those, you're really better off with G64. If. |
| |
Fungus
Registered: Sep 2002
Posts: 631 |
I 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.
It'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. Not to mention d64 already has support for disk errors, so it's not a stretch by any means.
That makes it a failure of an image format.
Same as G64 doesn't have variable bit length of tracks, it's just a short sighted bug. |
| |
Adam
Registered: Jul 2009
Posts: 321 |
I haven't seen a demo released on g64 images before (not that i can recall). was a great demo! |
| |
Krill
Registered: Apr 2002
Posts: 2858 |
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: 3142 |
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: 453 |
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: 11157 |
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: 2858 |
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: 3142 |
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: 631 |
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: 2858 |
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? |
