Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > CSDb Discussions > Why releasing small stuff in a whole D64 image?
2017-03-27 21:31
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....
 
2017-03-28 10:23
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
2017-03-28 11:45
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.
2017-03-28 14:52
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.

Here’s 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.
2017-03-28 17:30
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?
2017-03-28 17:30
Mason

Registered: Dec 2001
Posts: 459
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
2017-03-28 17:38
chatGPZ

Registered: Dec 2001
Posts: 11107
"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).
2017-03-28 17:53
hedning

Registered: Mar 2009
Posts: 4594
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.
2017-03-28 18:41
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.
2017-03-28 18:47
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 :)
2017-03-28 18:57
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.
Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
mutetus/Ald ^ Ons
zscs
Genius/Xenon
bugjam
Moderators/CSDb Staff
Steffan/BOOM!
WVL/Xenon
Guests online: 86
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 It's More Fun to Com..  (9.8)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 TRSAC, Gabber & Pebe..  (9.5)
7 Onscreen 5k  (9.5)
8 Wafer Demo  (9.5)
9 Dawnfall V1.1  (9.5)
10 Quadrants  (9.5)
Top Groups
1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Graphicians
1 Sulevi  (10)
2 Mirage  (9.8)
3 Lobo  (9.7)
4 Mikael  (9.7)
5 Archmage  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.06 sec.