| |
Krill
Registered: Apr 2002
Posts: 2870 |
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: 2870 |
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: 2870 |
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: 2515 |
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: 2870 |
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: 632 |
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: 2870 |
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: 632 |
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: 2870 |
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: 632 |
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. |
| Previous - 1 | 2 | 3 | 4 - Next |
