Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user ltk_tscc ! (Registered 2018-07-15) You are not logged in 
CSDb User Forums

Forums > CSDb Entries > Event id #2687 : Nordlicht 2018
2018-04-18 16:09

Registered: May 2013
Posts: 13
Event id #2687 : Nordlicht 2018


so we want to launch a "new" compo this year at nordlicht, the 512byte tinysize one. Since its for all platforms and the c64 crowd has always been a huge supporter for us we are interested how this particular compo will be received.

So far we came up with the following rules:

* All platforms allowed

* The entries must consist of a single file with a hard limit of 512b (2 Blocks on the C64). No whining because your Atari OS has a bigger fileheader or other means of wasting bytes.

* Please check our hardware section if we can show your entry "out of the box", also you are free to supply:
- The hardware itself (please contact us beforehand so we can make sure to be able to connect it properly).
- An (hopefully preconfigured) emulator. If your production runs on standard DosBox (0.74) you can also just pack the .config file.
- A videocapture of the hardware running your production (binary must be included).

* If 512 bytes are not your shoesize but you are into even smaller footprints instead, this is still the right compo for you. We will make sure to display the size of every entry on the beamslide.

The point of newschool and oldschool releases being in the same compo has been raised a couple of times now, but knowing history splitting them would just lead to a last-minute merge because one of them doesnt have enough entries, so were starting this thing combined.

So, any feedback on this?
2018-04-18 16:38

Registered: Dec 2001
Posts: 8586
2 blocks are 254+254=508 bytes :)
2018-04-18 17:12

Registered: May 2013
Posts: 13
Yes we are aware of that, but 3 Blocks are way bigger and we dont feel like using a hex editor or anything to check the "real" size, hence I set the limit to 2 blocks.
I don't think its too unfair either as every c64 entry has the same limitations and are only so much comparable with different systems like pc or amiga anyway. At least not to a point where 4 bytes matter, imho.
2018-04-18 17:59

Registered: Dec 2001
Posts: 8586
so noone will notice a faked block count in the directory either? noted :)
2018-04-18 18:48

Registered: May 2013
Posts: 13
Of course we expect nothing but honesty from the competitors and that they know every attempt of cheating will eventually be discovered, even if its after the party.
But maybe copying all the programs to a fresh .d64 image isnt the worst of ideas either, as it makes the disk-juggling process a lot easier during compotimes. Im sure we could also write it back to a real disk if anybody complains about TC/u1541 usage.
2018-04-18 18:53

Registered: Dec 2001
Posts: 8586
why bother, when you have the plain .prgs you can easily run them (with 1541u, or whatever else) and you can even see the filesize directly =D
2018-04-18 19:28

Registered: May 2013
Posts: 13
Good point.

But of course we are also prepared for shady guys who look and smell like they havent seen a bed or shower in a few days (aka sceners) handing us real disks directly at the party place ;P.

In any case, for cheating to happen there have to be entries in the first place!
So, could this category be a thing for you c64 guys? The idea is to allow for more small prods which can be done by less people / one coder in a managable amount of time while not being SO basic the non-coder-elite can still pull some joy from watching them.
2018-04-19 07:42

Registered: Oct 2004
Posts: 167
I don't get it. Is it 512 bytes or 2 blocks now? Imho in size compos "size of the executable in bytes" is less likely to cause confusion.
2018-04-19 09:01

Registered: Aug 2004
Posts: 805
I thought the parenthetical clarification above was pretty clear - for c64 entries the limit is two blocks, so the limit is

- 512 non directory bytes occupied on disk including block links
- 508 bytes for the file, including the load address
- 506 bytes for the executable
2018-04-20 09:21

Registered: Apr 2002
Posts: 953
The canonical standard is limit on plain executable size. That is, .prg no bigger than 512 bytes. Includes the 2-byte load address header. Has been done like that for ages with 4K and other small demos.

Enforcing the rules can be automated with a little script that would extract all files from the final .d64 and check their bytesizes.
2018-04-20 11:01

Registered: May 2013
Posts: 13
Ok than we shall scrap the 2 Block limit and go for 512 bytes .prg size instead. My main issue was indeed that it would be harder to check the real size of the .prg but apparently that is not really the case so imposing an extra limit just for the C64 seems unreasonable.
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
Users Online
Guests online: 23
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 Coma Light 13  (9.6)
4 Comaland 100%  (9.6)
5 The Shores of Reflec..  (9.6)
6 Wonderland XII  (9.6)
7 Lunatico  (9.6)
8 We Come in Peace  (9.5)
9 Incoherent Nightmare  (9.5)
10 Wonderland XIII  (9.5)
Top onefile Demos
1 FMX Music Demo  (9.6)
2 Daah, Those Acid Pil..  (9.5)
3 Pandemoniac Part 2 o..  (9.5)
4 Treu Love [reu]  (9.5)
5 Merry Xmas 2017  (9.4)
6 Dawnfall V1.1  (9.4)
7 Arok 20 Invitation  (9.4)
8 In Memoriam BHF  (9.4)
9 Dawnfall  (9.4)
10 Synthesis  (9.4)
Top Groups
1 Oxyron  (9.4)
2 Booze Design  (9.4)
3 Censor Design  (9.4)
4 Finnish Gold  (9.4)
5 Crest  (9.3)
Top Hardware-Gurus
1 Soci  (9.9)
2 Wiesel  (9.9)
3 Grue  (9.8)
4 Zer0-X  (9.8)
5 Lemming  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2018
Page generated in: 0.058 sec.