| |
Krill
Registered: Apr 2002
Posts: 3005 |
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....
|
| |
bugjam
Registered: Apr 2003
Posts: 2636 |
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: 3005 |
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: 706 |
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: 3005 |
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: 706 |
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: 3005 |
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: 706 |
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: 3005 |
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: 706 |
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: 323 |
I haven't seen a demo released on g64 images before (not that i can recall). was a great demo! |
| Previous - 1 | 2 | 3 | 4 - Next |
