CSDb help / documentation|
last updated May 11 2021 - in case of problems or suggestions, please
contact the moderators
- General behaviour on CSDb
- These rules pertain to all users and no exceptions will be made.
- Please understand that due to the nature of CSDb there will always be the one or other thing in the rules that
you possibly can not agree 100% with. The broad range of information presented through CSDb will always include
things that by your definition isn't related to the scene. we are aware of it, and you should be too.
- Whining about the rules in public (in the comments, forum etc) is not tolerated and will make us very triggerhappy. If you have a reasonable complaint in constructive manner, please send one message to the admins and your complaint will be discussed, and eventually the rules will be updated. Constant rambling about the rules in the forum, comments and/or messages to the moderators is considered trolling and will not be tolerated and eventually result in a ban. DON'T! This includes, but is not limited to, repeatedly opening forum topics for the sole purpose of getting attention, reposting what has been censored by a moderator, nitpicking on the rules and pasting them into the forum and/or comments. DON'T!
- Think before contacting the admins, give them time to do reasonable decisions and live with them.
- Never contact Perff unless for a very good reason. Contact a moderator first. If in doubt, don't!
- CSDb is a place for facts and factual discussions of scene related issues. It is therefore not permissible
to use CSDb as a medium for any kind of personal attacks/discriminating or foul language (using the forum,
oneliners, comments on CSDb entries, PM's, deliberate downvoting or anything similar), and any such will be
punished with temporarily or permanent exclusion from the site.
We will not scan CSDb for such attacks, therefore we will only react if the person who is attacked informs us directly. In such cases we will look into it and take action as we see fit. We do NOT tolerate retaliations of any kind!
- English only. All text written here must be in english, or at least be accompanied by a translation. Any non-english text will be removed. Of course this rule does not apply for PM's.
- One account per person. It is not permitted to have any kind of "fake" or double accounts of any kind at CSDb. When found, any such accounts will be deleted, and the person behind the accounts will be contacted. In severe cases the person will be banned from CSDb.
- Be a good and friendly scener. :) We do of course not tolerate bad behaviour on CSDb, but also if a person acts badly outside of CSDb, it can lead to that person getting banned from CSDb.
- News & Comments
If you want to announce something that by our definition is not scene related, go to
c64.sk, they might have a different policy than us.
- Please only use this section for serious announcements. this is not the place for chatting or oneliners.
- Anything that doesn't look like news or an announcement to us will be deleted.
- The news are not for promoting releases. create a proper entry for the release(s) in question instead.
- This is the place for chit chat.
- Flooding the oneliners with more than one message in a row is strictly discouraged.
- Personal attacks and flames will be deleted.
- As much as this is anarchy for you, this is anarchy for the mods. complaining about moderation in the oneliners is strictly prohibited and might earn you a ban. FUN!
- Forums and User Comments
- Only write on-topic. Any off-topic text will be removed. This means that the forum is for discussions related to the room the topic is in. User comments should be used for comments on the release in question, and not for telling the world about possible wrong information, discussions, or other off-topic. Such information should be taken to the forum. You can start the thread by clicking on "Discuss this release", Discuss this scener", etc. thread, which all entries have. We will not activly scan csdb for such misuse of the comments, but might silently delete them if we stumble about them, so don't complain if that happens.
- Again: the forum is for serious discussion. if you don't have anything valueable to add to a thread, do not post.
if you still do, your message will be deleted.
- Deliberatly ruining a thread by posting pointless off topic junk is not tolerated, and will make us very
- Constant bitching aka Trolling is not tolerated. Doing so is a good way to earn a ban.
- Managing information on CSDb
- WHY all these silly rules? Can't we just get along?
- It makes life for Moderators much easier. The growing amount of users and opinions has lead to the conclusion
that relying on common sense isn't always the obvious solution. Discussing the same things over and over is simply
too tiresome and boring and too much admin resources were wasted on it
- Everyone has a different background, Demosceners, Crackers, Oldschool, Newschool. This makes relying on "unwritten
rules" and "common sense" a minefield which we try to avoid stepping into.
- Goals of these rules
- CSDb tries to collect as much information about what we call the "productive Scene" as possible. as such we
sometimes need to define what we consider to qualify as such, and what doesn't.
- The information presented through CSDb is generally considered "public" and being able to edit it is a
privilegue, not a right.
- Managing information about yourself
- You are strongly encouraged to link your login account to your scener profile. This will make it much easier
for us incase we have any questions (or if in doubt to contact you). Don't get the impression that you "own" your scener entry. It's supposed to be as objective and informative as possible; it's not the place to promote youself, your work, or use it as your own homepage.
- If you for some reason have some information about you or related to you, that you don't want in CSDb, you should state the reason clearly in the entry (using the trivia field, comments or similar), so that it is not mistaken for poor maintenance.
However keep in mind that you should never remove "public" information (such as releases or groups) unless for a very good reason.
- Managing information about others
- You should only add/edit information that you are 100% sure of, and only add information that have some relation to the C64 scene.
- Most information about the scene is considered public. In general this is information like who was/is a part of the scene, which groups they were/are a part of, their contributions etc. All such information should be added to CSDb and should only be removed with good reason.
- Personal information like real name, address, phone, photo, etc. is however strictly personal, and it is totally up to the individual if this information should be added or removed. (and if in doubt, it should be removed). Do not add personal information of anyone without that persons consent. UPDATE: Due to GDPR and European law, photos of sceners, addresses, real names etc., are nowadays (2018-) removed from CSDb.
- Managing information about Sceners
- ONE profile per actual person. If a person used more than one handle then these should be created and linked from within his "main" profile. CSDb isn't the place to maintain your split personality, it's a database to collect facts about the Scene.
- If a person changes his handle this should be reflected by first creating a new handle using the "add new handle" button in the scener entry and then setting it to the currently used handle. Do not edit the current handle into the new handle, as this will mess up all credits connected to that handle.
- When it come to parties and events it should be clear that if you or the scener you are adding as "attended" didn't actually attend physically (but perhaps only submitted an entry remotely for example) you/they were not there. Only add people to parties/events if they were there physically. That is what attend means. The same goes for online only compos, like the popular "CSDb compos", like Plain PETSCII Graphics Competition 2017. Do not add yourself or anyone else as "attended" there. If you participated in the compo in question you are already credited with your entry.
- Managing information about Releases:
- When adding a Release, please doublecheck if it is not already in the Database (maybe with a slightly different name). Maintaining dupes is a pain.
- The first thing when adding a Release is uploading the file, or providing a download link. nothing is worse than an old lost release entry with all info but no file.
- If you for some reason are unable to upload a file, or provide a download link, you must add a reason why. Releases with no download link and no good reason why there isn't such a link might be removed.
- If possible, use D64 Images when uploading C64 files. please refrain from using plain binaries (.prg files) and use D64 even for single file releases - this is a measure to preserve the original filename(s). Other kinds of emulator images that also preserve the original filenames (like T64 and P00) are ok too, but still consider converting them to D64 - or atleast do not create new ones. By all means avoid zipcode/sixpack/lynx files, they are a pain to deal with.
- If you can, test the file. Broken files suck :(
- You are encouraged to upload a screenshot aswell. Screenshots should be pixel exact without filters (in Vice use the built in ALT+C command). After adding it, check again if you didnt forget to upload
the file. Entries with screenshots but no file make poor kitten cry. :(
- Try to make sure that the information in each entry is as full and correct as possible. if in doubt, leave
the respective fields empty.
- The release date of an entry should reflect the time when the actual files linked in the entry where released
to the scene, not some other time when those files have been created, linked, pixelled...
- Release entries should never be updated with "new" or "fixed" versions of the same release. New versions of a release should get seperate entries which reflect the proper release date and other details. if we spot such silently "updated" releases we will undelete and/or create a seperate release entry for them, so if you choose csdb as your release platform better doublecheck that what you upload is actually what you want to release. in tribute to the "old school" retroactive "unreleasing" will not be tolerated. (this rule does not apply to replacing broken files with working ones, obviously we hope)
- The "Goofs" field and "broken" tag is aimed at the scene release in question. A goof is meant to document bugs in the release; for a crack that means bugs inflicted by the cracking group - not bugs that is in the original game. The "Broken" tag is used for signalling a broken release, again inflicted by the crackers or coders for example. For demos "broken" can be used if a release crashes and a newer version that works exist. Don't confuse the "broken" tag with the corrupted files (a bad copy, where the disk is trashed), that is covered and tagged editing the file in question when uploading.
- Please try to add credits too. Credits should reflect who did what in the release. Credits are due even if the author of the used piece isn't aware his/her creation was used, because it's about acknowledging who did that particular piece of the release - like charset, logos, pics, musics; not authors of whichever tools were used to draw/compose/compile/link/pack - no matter if they were actually involved. The database's credits serve to replace wrong in-release credits, where the releaser could have miscredited the wrong persons, sometimes even willingly.
- Which Releases belong into the Database:
- Scene releases only. By our definition this excludes all commercial productions of any kind - with a few exceptions mentioned below.
- No coverscans of original tapes and disks, no scans of game manuals. Please consider donating such material to
if you want to help preserving it.
- Often individual parts of a release circulated seperated from the others, like demoparts from a larger demo that could still be loaded seperately, or game-picture and -sound rips. This type of files should not get seperate entries - instead consider completing the entry of the full release if needed.
- Private releases such as personal notes etc. are to be considered letters, thus private still. Do not add releases that contains personal info and weren't meant to be publically available.
- To ensure completeness of the database, entries for other platform (PC/Apple etc) 'patchers' for C64 files (examples being PC tools to "crack" your original game, or patchers that fix bugs in some release) should be replaced with the already patched C64 file in question, if available, as the result of the patcher is what is interesting for this database. Patchers made to run on the C64 are regarded as valid C64 tools, of course.
- Anything which does not belong here according to the rules will be deleted without further notice, either by the moderators or by other dedicated csdb users. Don't complain.
- Generally Demos (and also graphics and music entries) by our definition are freely available C64 (and supported
border systems ofcourse) executables.
- Please notice that things like music entries with only a .sid file or graphics entries without an actual runable .prg will make the moderators very triggerhappy.
- We generally discourage adding uninspiring entries like badly converted graphics done with a few clicks in a
- Credits of Demo entries should refer to everyone involved in the production, including creators of ripped music or gfx. If you want to point out further details (for example wether something is ripped) please use the comments/goofs/etc.
- Commercial ("promotional Demos")
- A few commercial Demos have been produced (such as the famous Christmas Demo from Commodore). Since there are so
few of them, and as they often hold quite some historical value, we keep these in the Database.
For cracks released after 1/8-2008 please refer to the CSDb release standards for cracks.
- By our definition a "crack" in the Database is a Program which has been somehow modified (which preferably adds
some value over the Original) and then released to the Scene. Yes we know that doesn't match your definition.
- The credits of such entries should reflect who did what modification to the original program (ie the crack, ntsc fix, trainer etc). Credits that refer to the creators of the crack intro belong into the entry of the crack intro. Credits that refer to the creators of the original Game should not be included.
If you are looking for Freeware Games,
might be a better choice for you.
- Generally Freeware Games released by non Scene Groups (or individuals) fall into a similar cathegory as other "originals".
We'd much prefer a "crack" (by our definition) over a simple dump of the original Game which is available for free
anyway. The same goes for adding game/tool previews or updates from for example coderepositories like GitHub. Don't do that.
- However we are aware of the fact that some people start(ed) making games to release to the "scene" just
like others prefer making demos, which would qualify them as "scene release" by itself.
- Games that have been made with a game-creator of some sort (such as S.E.U.C.K.) are not considered scene releases,
unless they qualify as a "crack" (by our definition).
- Commercial ("Originals")
An original Game by our definition is a Game which is or was sold (be it through a Magazine, a distributor, whatever) and which does not qualify as a crack. Generally entering commercial Games into the Database is prohibited, with the following exceptions:
If you want to help archiving original Disks, go to the
C64 Preservation Project or
The SixtyFour Originals DataBase.
For downloading Games try Gamebase.
- A Group or Individual that has also a scene background produced some Games, and agrees with their commercial releases being available for download. Entries of commercial games which do not have a download link because the creator of the game does not agree with it are subject for deletion.
- Such entries in the Database should (unlike cracks) have the credits pointed out for the actual game, and the download link should point to the original file. If you like you can put additional links to cracks of that game into the comments, but don't put them into the actual entry.
If you want to help archiving original Disks, go to the
C64 Preservation Project or
The SixtyFour Originals DataBase.
Some commercial Diskmags are archived at c64-mags.de.
- Generally no commercial (non cracked) Productions of any other type should be added, unless there is no alternative "cracked" entry in the database and the program is if some historical value (like some old tools).
- Commercial magazines are considered non scene releases, and thus are not included in the database
- What Groups and People belong into the Database:
Generally every individual or Group involved in the Scene has his place in the Database, with the following
- User Groups
- Generally we consider most so called user groups not being part of the scene, we do however know that
the lines are blurred and some border cases might exist. If in doubt, better be backed up by at least one
real scene release in the Database.
- Public Domain Distributors
- Groups (or Individuals) which were never part of the Productive scene, such as some "companies" which sold
disks with "public domain software", are not considered part of the scene. If in doubt they'd better be backed
up by at least one real scene release in the Database. This rule does (obviously we hope) not apply to
swappers which were involved into an otherwise productive scene group.
- Fake Labels
- Fake Labels are part of the scene, and as such have their place in the Database
- You are strongly encouraged to link entries of fake handles to their real scener entry. This will not only
help the accuracy of the Database but also increase your karma :)
- Fake Labels which have not disclosed their true identity yet (by linking their member entries to their real
scener profiles) will be tolerated only as long as they back up themselves by serious non crap releases.
- It is not allowed to add such to CSDb with the only purpose to harass others.
Please notice that when a group (or individual) qualifies for an entry in the Database, not all its productions
automatically qualify too (see above, we only want the scene releases)
- Generally Groups, Companies and People with a pure commercial Background (like many Game coders) are not considered
scene related and thus do not belong into the Database. Exceptions are those who do have a scene Background (like
for example a lot of composers) that can be backed up by at least one scene release in the Database.
- Magazine Staffs of Commercial Magazines are generally not considered part of the scene, unless they are backed
up by at least one other real scene release in the Database.
- What kind of Events belong into the Database:
- Generally all "open" kind of parties and meetings that were somehow C64 scene related, and were not of pure commercial
nature, are subject to be documented.
- Meetings or parties that are not of some kind of historical value (like e.g. some of the early berlin cracker meetings) or can not be backed up by releases do not belong into the Database.
- Locking Entries
- You must only lock entries which are directly related to you. That is your own scener profile, groups you are/were member of, releases you have created and events you have organized.
- If you lock an entry, this entry has become your responsibility. This means that it is up to you to make sure that the information in the entry is correct and as complete as possible. You must also log into CSDb occasionally to check for messages from other users who might have updates to your locked entry. If you do not follow this, we will unlock the entry so that others might complete the information.
- If you find an entry which you think is wrongfully locked, or you want to add/edit information to it, your first move should be to contact the maintainer of that record. If that fails you can contact the CSDb staff/moderators.