| |
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... |
|
| |
Frantic
Registered: Mar 2003
Posts: 1646 |
I like to have all my stuff in a single format rather than several different ones, and d64 works for all purposes. While I respect different points of view, I would guess that the average internet user in these video streaming days considers ~170kb to be "nothing". Just my view. |
| |
Zyron
Registered: Jan 2002
Posts: 2381 |
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. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
I used to find .d64 releases annoying for single filers because it was easier for me to transfer a prg via codenet to my real 64 than to extract the file.
But my c64 is currently broken, and even if it wasn't I could probably script something to pull the prg out if I got my shit together.
I vaguely recall gzipped .d64s being disallowed here at some point? It does seem like a good compromise aside from that. |
| |
bugjam
Registered: Apr 2003
Posts: 2581 |
@Hermit: I think it is good that you brought that topic up, because indeed most people (including myself) would assume that nowadays, everyone has sufficient bandwith to not bother about a few KB. So it is important to remind folks about it.
Preservation of the original file name is the essential point here; I guess needs are different for different people - personally, I prefer .d64 also for ease of use, but needs are different, as ChristopherJam pointed out.
I never bothered to zip images before uploading, but henceforth I will! |
| |
lft
Registered: Jul 2007
Posts: 369 |
Also keep in mind that newer modems support compression. Highly regular data, such as a large stretch of null-bytes, will actually be compressed by a factor of 1:4 during transfer, if you are using a V.42bis modem to connect to your ISP. That is the reason they are marketed as e.g. 38400 bps instead of the actual 9600.
It's not as good as using compressed files as suggested, but at least the overhead is on the order of 40 kB rather than 171 kB. In fact, this technology will allow you to transfer an almost-blank .d64 image in less than a minute.
Mind, at these increased transfer rates, the interrupt latency of your machine might become a bottleneck. For instance, if you are using the Amiga's built-in serial port, rates above 9600 are unreliable because the software layer needs to respond in time to grab each incoming byte from the hardware before the next one arrives. |
| |
bugjam
Registered: Apr 2003
Posts: 2581 |
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: 468 |
Possibly the increased use of 1541 Ultimate may influence it too. |
| |
iAN CooG
Registered: May 2002
Posts: 3187 |
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: 231 |
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: 1787 |
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: 3187 |
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. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quoting CommFor
6. When I see PRG file in CSDB database, I immediately know this is tape game.
No you don't. Could be a crack from a disk, could be a one-filed multi-load disk/tape crack.
Quote:
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.
I'm not really familiar with GB64, but do they really keep track of all cracks of games and whether they where cracked from tape or disk? |
| |
Mason
Registered: Dec 2001
Posts: 461 |
Simply... We should keep the database as accurate as possible
To do that we also need to keep the original filename if it's possible. The original filename can't be kept in original form using a prg |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
"tape" vs "disk" game doesnt really matter at all for cracks - its either a onefiler (which happens to work on tape - but isnt necessarily a tape crack) or a multiloader (which may even be a bad crack from tape version, yet no more work from tape). |
| |
hedning
Registered: Mar 2009
Posts: 4723 |
D64 is a mirrored 1541 disk and in my view the normal way to hold C64-programs. This is a C64 database (not an emulator database per se) and as such should contain files "ready" to be loaded on a C64. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Quoting Compyx
I'm not really familiar with GB64, but do they really keep track of all cracks of games and whether they where cracked from tape or disk?
GB64 just selects 1 version of a game. They do not keep track of different cracks or anything else. |
| |
CommFor
Registered: Mar 2017
Posts: 19 |
Quoting CommFor
6. When I see PRG file in CSDB database, I immediately know this is tape game.
Quoting Compyx:
No you don't. Could be a crack from a disk, could be a one-filed multi-load disk/tape crack.
Compyx, you really don't want to go there, believe me :)
Or you want me to put more than 1.000 disk cracks and one filed multi-load disks/tape cracks in CSDB?
Totally pointless to fill CSDB with this kind of crap!
Imagine - for example - to have 11 disk-rip levels from Turrican II as separate 11 PRG files when we have proper disk-release from where they are ripped.
When you finish level, C64 trying to read another level and game just crash.
Quoting Compyx:
I'm not really familiar with GB64, but do they really keep track of all cracks of games and whether they where cracked from tape or disk?
No, GB64 unfortunately doesn't exactly specify if game is tape or disk crack (it will be perfect if we can filter game there for tape or disk games and number of disks too), but in 98% you can conclude by yourself, because they put how much blocks game have, and we all know limit for tape game is 202 blocks.
It can be more than 202 blocks if they put picture and documentation.
GB64 doesn't track all cracks, they just keep best one for each game (according to stability, number of trainers etc.) in database - of course, this is GB64 subject judgement, but it's excellent if you want to have all games without "duplicates".
For tracking all cracks of games we have this excellent CSDB :)
These two sites plus excellent www.forum64.de and www.lemon64.com satisfy all C64 nerds :) |
| |
CommFor
Registered: Mar 2017
Posts: 19 |
Hedning,
What about hardcore C64 users or C64 users without ability/will to buy something like 1541U, SD2IEC or 1541 floppy and having only datassette, how they will load D64 files?
Of course, they will find friend(s) to make them tapes with games in turbo :)
Unfortunately, in my country I can't even find some C64 enthusiast, so nobody will ask, unfortunately.
Speaking of this, we have really fantastic program called Spectacular Copy for transferring tapes to floppy/SD2IEC/1541U.
But, we really don't have any modern C64 program to put PRG files back on tape in turbo format!
I used Copy 235 for this (if my memory serves me well), ancient program from 1985., and - of course - needs to do that manually for each game. |
| |
ptoing
Registered: Sep 2005
Posts: 271 |
@CommFor You can also use DirMaster V3.1.1 to get .prg files out of .d64 images. Very handy program. |
| |
CommFor
Registered: Mar 2017
Posts: 19 |
Mason,
Saving original game name from original tape is totally OK, but saving original game name from tape crack is - in my opinion - not important at all.
For example, if original tape crack is called " R.Dang. 2 +3/HTL", would you rather have name "Rick Dangerous 2" instead on your PRG file or real tape? |
| |
CommFor
Registered: Mar 2017
Posts: 19 |
Ptoing,
I know, using this fab program very intensively ;)
Thanks for advice anyway. |
| |
bugjam
Registered: Apr 2003
Posts: 2581 |
Quoting CommFor
For example, if original tape crack is called " R.Dang. 2 +3/HTL", would you rather have name "Rick Dangerous 2" instead on your PRG file or real tape?
No. |
| |
ptoing
Registered: Sep 2005
Posts: 271 |
I can understand the original name thing. I don't care about the original names when I play stuff and sometimes rename things when I put them on an SD for use with my 1541U.
This is very easy to do and everyone can do that themselves. So I think preserving original filenames for old releases and such is the way to go. I doubt I will be releasing standalone pictures on d64 images though. |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
The original post seems more about present day development, rather than discussing preservation of older stuff.
For many modern single file releases which have been cross-developed, the .prg might preserve the original released filename better than .d64, when the original filename was ASCII with no 16-char limit. |
| |
ZeHa
Registered: Apr 2009
Posts: 6 |
Quote: 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.. ^^
as for drag'n'drop, i have noticed that VICE has a problem when the filename (AND path!) contains spaces, no matter if it's a PRG or D64 file. because then he interprets it as two separate parameters. but in general, it is possible to drag PRG files to it, i do it very often. when it's not working, it's because there's a space somewhere in the path.
at least that's the case under linux, but i assume it might be similar under windows. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
cant reproduce this problem in linux at all :) sure it isnt the desktop environment that screws it up? =) |
| |
ZeHa
Registered: Apr 2009
Posts: 6 |
of course that is also possible ;)
but even on the shell, you have to use quotes or properly escape the spaces to successfully start a PRG or D64 with x64. which kinda makes sense of course. ;)
but i can reproduce this behavior both in MATE and XFCE... |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
What port are you using? I just tried this with prg's, d64's and p00's using the Gtk2 UI, and stuff (including filenames with spaces) works fine.
I'm also running MATE, on Debian stretch. |
| |
Mason
Registered: Dec 2001
Posts: 461 |
Quote: Mason,
Saving original game name from original tape is totally OK, but saving original game name from tape crack is - in my opinion - not important at all.
For example, if original tape crack is called " R.Dang. 2 +3/HTL", would you rather have name "Rick Dangerous 2" instead on your PRG file or real tape?
I would like the "R. Dang. 2 +3/HTL" filename as that's the way Hotline released it on the disk.
To keep the release accurate |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
i'd even go a step further - i'd want the original spread disk, unaltered. ie including whatever else was on it. |
| |
ZeHa
Registered: Apr 2009
Posts: 6 |
Quote: What port are you using? I just tried this with prg's, d64's and p00's using the Gtk2 UI, and stuff (including filenames with spaces) works fine.
I'm also running MATE, on Debian stretch.
what do you mean with port? VICE version?
i am using Xubuntu 14.04 (XFCE) at home and Fedora 20 with MATE at work, both use (as far as i remember) the VICE versions from the repo. |
| |
Fred
Registered: Feb 2003
Posts: 285 |
@Hermit: I used to make T64 files for files that don't need a disk drive to preserve the filename. Then I found out that T64 files are not indexed by:
https://cbm8bit.com/8bit/commodore/search
while D64 files on CSDb are indexed so I decided to upload everything as D64 file. Since there is only one file in the D64 file, it will be highly compressed by the web server using GZIP compression when you download it so it will not cause that much extra bandwidth.
@Bugjam: please don't zip D64 files. There is really no need for it. It will not solve the bandwidth problem because that is already solved by gzip2 in the web server. It is very annoying to have C64 files in zip file format for emulators/environments that don't support it. |
| |
Fred
Registered: Feb 2003
Posts: 285 |
Quote: i'd even go a step further - i'd want the original spread disk, unaltered. ie including whatever else was on it.
Really? We need a new release type for this: spread disk
Spread disks can be found here so I don't see any reason to dump disks on CSDb: http://scenebase.org/
But if people keep uploading full disks, we really need this release type, sight... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
no release type needed really... its just a misconception that files added to entries should be d64s that ONLY contain said release. nothing wrong with just linking the full disk to it (as has been done with tones of entries already, of course) |
| |
Fred
Registered: Feb 2003
Posts: 285 |
Quote: no release type needed really... its just a misconception that files added to entries should be d64s that ONLY contain said release. nothing wrong with just linking the full disk to it (as has been done with tones of entries already, of course)
I think it is the other way around. It is a misconception that just full D64 files should be uploaded to entries. It doesn't make sense to me. The entry should only contain files about the release.
I think you will not like that your own entries are replaced with full disks with your release that were spread at that time, or have multiple spread disks with your demos uploaded to the same CSDb entry, do you? Just to make my point that it doesn't make sense to have full disks uploaded that contain releases not related to the entry.
How annoying it is when you want to see the release and you have to find out which file to start. You can say that it is not a big deal but for scanning tools it is.
I think that some people just upload full disks to old releases because they don't want to spend time to make a proper disk for it or they think that CSDb is about preserving disks. |
| |
bugjam
Registered: Apr 2003
Posts: 2581 |
I agree with Groepaz here: if a release is found on a contemporary spread disk, then it is just fine and even useful to just upload the whole disk - it may contain information on the release outside of the actual file, e.g. in the dir, or through the context of other programs that it was released together with.
Very simple, very recent example: Greets to... - the release year 1988 can only be confirmed by the disk header containing the year, and the context that the group mentioned in the release was founded in 1988.
Of course there is no problem if someone wants to add a "clean" image or prg additionally. |
| |
Fred
Registered: Feb 2003
Posts: 285 |
@Bugjam: I think you just created the solution here. If a full spread disk is uploaded because of the few cases you mentioned and the uploader also uploads a clean disk with the release only then everybody is happy.
And to come back to where this whole thread is about, this will also solves Hermit's issue of low bandwidth since D64 files with only a few files in it will cause lower bandwidth since the web server can better gzip it. So better mark the spread disk so people know what they download. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
Quote:I think you will not like that your own entries are replaced with full disks with your release that were spread at that time, or have multiple spread disks with your demos uploaded to the same CSDb entry, do you?
yes, thats exactly what i would like to see. and i seriously hate it when ppl rip apart the disk of some crack just to create an empty d64 with one file in it and "COOLHACKERJOE" in the header. (even better: they do that using some bugged gui shit and screw up the prg even. and of course noone tests the resulting d64 either.) fucking lamers. |
| |
Fred
Registered: Feb 2003
Posts: 285 |
Would be nice to have a separate field for a release where you can specify the scene base disk id or multiple ids so people don't have to upload spread disks. And also the ability to download the disks from the entry which means someone needs to host the files. This is a much cleaner way than uploading spread disks on CSdb. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
how is linking to a 3rd party "cleaner"?
i am not going to support all-i-want-to-do-is-doubleclick-lamers for that matter. fuckthatshit. |
| |
Fred
Registered: Feb 2003
Posts: 285 |
Because people are now uploading releases to entries that don't belong there (I know that you totally disagree with this).
Anyway, if we keep uploading full disks, then we can better separate them from "clean" releases and then reference to it. Or separate the release downloads from spread disks downloads on the entry page so that people know what they download.
And an ability to view D64 and T64 files on CSDb would also be welcome. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
"clean releases" dont exist for lots of those entries, thats the whole point. most onefile cracks for example were spread with other onefile cracks on the same disk - by the one who cracked them. |
| |
hedning
Registered: Mar 2009
Posts: 4723 |
Quote: "clean releases" dont exist for lots of those entries, thats the whole point. most onefile cracks for example were spread with other onefile cracks on the same disk - by the one who cracked them.
That info is important, but there are fields to fill in with that info. In my world every entry has a d64 with only the release in question on it. Argument? Because this is an archive of releases for the C64, not a disk collection database. There are other places that host full collections with untouched disks.
This matter will not be solved here either. We moderators will have to discuss, after the input in this thread, and then be more clear in the guidelines. Then end this discussion.
We do understand that we can't please every user here, but on the other hand that is not the goal with this database. The integrity of the database itself is the main matter. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
as if anything will come out of this discussion :=) |
| |
hedning
Registered: Mar 2009
Posts: 4723 |
Quote: as if anything will come out of this discussion :=)
<3 |
| |
CommFor
Registered: Mar 2017
Posts: 19 |
Just removed my recently posted 86 games in PRG format and changed them with D64 files.
Each D64 file contains one game in PRG format.
Done with Style's DirMaster.
Rules are rules :) |
