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 Entries > Event id #2687 : Nordlicht 2018
2018-04-18 16:09
wysiwtf

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

Hello,

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
chatGPZ

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

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
chatGPZ

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

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
chatGPZ

Registered: Dec 2001
Posts: 11088
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
wysiwtf

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
spider-j

Registered: Oct 2004
Posts: 443
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
ChristopherJam

Registered: Aug 2004
Posts: 1359
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
Krill

Registered: Apr 2002
Posts: 2804
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
wysiwtf

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
Advanced
Users Online
CopAss/Leader
t0m3000/ibex-crew
zscs
Freeze/Blazon
mutetus/Ald ^ Ons
Guests online: 298
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 No Bounds  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 Party Elk 2  (9.7)
2 Cubic Dream  (9.6)
3 Copper Booze  (9.5)
4 Rainbow Connection  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Onscreen 5k  (9.5)
7 Dawnfall V1.1  (9.5)
8 Quadrants  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Nostalgia  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Crackers
1 Mr. Z  (9.9)
2 S!R  (9.9)
3 Mr Zero Page  (9.8)
4 Antitrack  (9.8)
5 OTD  (9.8)

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