| |
Hermit
Registered: May 2008
Posts: 208 |
Why releasing small stuff in a whole D64 image?
I'm curious why many of very small (even several kilobytes) of releases are made on .d64 image?
I'm a minimalist (usually with limited internet connection) and if I see a music or one-file demo etc. on ~170kbyte D64 I sometimes don't download it, just because I don't like the 5..10x waste of space and bandwidth in general. (And maybe the pollution it generates in big amounts, a problem nowadays I think, yet not the biggest source of pollution is IT.)
Sorry if my thinking is weird or uncommon (really hope it isn't), but I'm still curious why many people release things on .d64 instead of .prg (or .sid or .tap) if they could fit.
Is it easier to save or load D64 format on their systems or cartridges?
In any way, if you like to release small stuff in .d64, I'd thank you if you at least compress (zip) it or release a .prg beside the .d64, as seen many times, and so they won't distract people like me, and your release will be downloaded and evaluated a bit more times... |
|
... 40 posts hidden. Click here to view all posts....
|
| |
bugjam
Registered: Apr 2003
Posts: 2476 |
There used to be also a problem with .prgs as download, IIRC - in certain instances the endbytes are cut off because they are misinterpreted by the OS, or something. Ninja told me that many years ago, not sure if that problem is still relevant. |
| |
Stryyker
Registered: Dec 2001
Posts: 465 |
Possibly the increased use of 1541 Ultimate may influence it too. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
Quote: There used to be also a problem with .prgs as download, IIRC - in certain instances the endbytes are cut off because they are misinterpreted by the OS, or something. Ninja told me that many years ago, not sure if that problem is still relevant.
More likely, the tool that extracted the prg from the t64 or d64, is bugged and doesn't extract the correct amount number of bytes. Loading a correctly sized prg directly or from a d64 doesn't change anything. |
| |
Dano
Registered: Jul 2004
Posts: 226 |
As for myself i tend to have problems with WinVice breaking the drag'n'drop of files onto it (going back to default settings fixes it though). I'm just a lazy Windows guy, and i guess there's no option to load a prg from the menu?
So d64 always works flawlessly and that makes the point for me. So yes, i am all in for having everything as d64.
Rambling over some 170kb plus or minus just doesn't cut it for me.
In the end there will always be two sides. And people who use vice from the shell won't care about formats anyway i guess.. ^^ |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: Mainly to preserve the filename I guess, and perhaps because you want to include some kind of dir-art.
I used to gzip d64s because then you didn't have to unpack them before attaching in Vice.
+1
I also prefer gzipped .d64's although not all tools handle them transparently. Coming to think of it, there should be one that extracts .d64.gz with a single file in them. Shouldn't be too hard to write.
The only other "popular" container that supports original filenames is T64 and that is really badly standardized. Even fewer tools handle that transparently.
I guess that if PETSCII was a part of unicode (perhaps it is?) you could have files with the original name directly in the filesystem, but I wouldn't want to rely on that. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
PC64 files (ie *.p00, *.s00, etc) support PETSCII filenames. These are basically .prg files with a 26-byte header prepended to them, so they're small but keep the original filename intact.
Many emulators support this file type. (At least the prg, seq and usr files, not sure about relative files) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
It's mostly about preserving the filename and maybe having some directory PETSCII graphics. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
dano: "i guess there's no option to load a prg from the menu?"
file/autostart accepts all supported filetypes including prgs of course |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quoting tlr+1
I also prefer gzipped .d64's although not all tools handle them transparently. Coming to think of it, there should be one that extracts .d64.gz with a single file in them. Shouldn't be too hard to write.
c1541 image.d64.gz -read '*'
That should read the first file in the d64 and write it to the host filesystem using the PETSCII filename converted to the host encoding as the filename. |
| |
CommFor
Registered: Mar 2017
Posts: 19 |
I posted more than 80 tape games missing in CSDB collection in last ten days in PRG format and few moderators contacted me reminding me of 7.4 CSDB rule that all games must be posted here in D64 format.
Heres my opinion about this:
1. Everyone in C64 heydays - especially in Europe where datassette was very popular - making his own game collections on tapes in turbo format, and most people put game names like THEY want it.
2. Datassette and tapes were much cheaper these days than floppy and disks, and probably 80% of C64 owners in Europe had only datassettes.
So, there were HUGE numbers of collections everywhere from 2nd/3d/4th/5th/6th hand etc., and original crack game names on these tapes are NOT there, because people changed it. A LOT.
3. For instance, collection I converted (66 tapes, each has 36 games in turbo format) mostly has names like these:
" *<<<ZYRON>>> * "
"<<3D-SKRAMBLE>> "
Not to mention these files were "inverted" (blue letters on white screen).
Obviously, owner of this collection changed all game names.
It will be funny and ridiculous if I "preserve" these file names and upload it on CSDB like these.
Of course I changed game names obeying 16-letters limit, using only text and and keep them understandable for everyone.
4. I also don't have PRG extensions in my files on my PC because C64, SD2IEC and WinVICE recognize these files without any problem, and it's easier just to drag & drop them in D64 format using Style's DirMaster, not having "shortcuts" of these made by C64 or SD2IEC of - now 20-letter - game names.
Not to mention SD2IEC convert them from tape without PRG extension, this is a bonus ;)
5.. I TOTALLY agree cracked disk-games should be updated that way in D64 to preserve original game-names, because almost no-one of typical users dare to change file-names on disks containing games.
Not to mention some of them have hidden files, files with wrong block-sizes intentionally etc.
6. When I see PRG file in CSDB database, I immediately know this is tape game.
When we have games uploaded in D64 format (like CSDB asks for users), I don't know immediately if particular game is disk or tape game, and I need to check Gamebase 64.
7. When you have game uploaded in ZIP format, I also don't know if this game is disk or tape game, and I need to check Gamebase 64.
8. Of course it's pointless now to change rules having more than 20.000 uploads in your database, but from Day 1 CSDB should have rule to upload cracked disk-games in D64 format ONLY, cracked games with multiple disk-images in ZIP format, and tape games in PRG or TAP format ONLY.
But rules are rules (CSDB rule 7.4) , and just like in real life - most of them are good, but some of them are bad.
Like this one. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next |
