🞜 Vintage Computing Christmas Challenge 2023 (VC³ 2023) 🞜

A small programming contest that will run from Monday, 4.12.2023 until Monday, 25.12.2023. 

Watch the presentation from Dec 30 here.

You found another way to improve your code after the deadline? Or you just missed the deadline?
Then you can post-submit entries here.

The Main Challenge (Compo)

   

  1. Software:
    1. Create a program that creates the object as seen within the images above, 1:1 
    2. Exactly the same shape
      1. The final screen may not include any additional characters(, which are not from the operating system itself).
        Your program must not draw anything else on screen than the object itself.
      2. Prompt like READY may appear.
    3. No need to clear the screen.  But you can. And you may write spaces.
    4. The object can be anywhere on the screen. e.g. left top, centred, a.s.o. 
    5. Any colour is allowed (but please not the same as background one)
    6. Program termination:
      1. The program can finish normally afterwards (return to prompt)
      2. The program may loop
      3. It may wait for key
      4. It must not obviously crash (e.g. with error message) 
  2. Hardware:
    1. Use any machine you like, preferable vintage computers ;-)
    2. Make the size of the program file (e.g. PRG on C64) as small as possible
    3. Don't manipulate the file (e.g. truncating the last bytes, changing the start address, etc. Mainly valid for "standard files" in BASIC and other languages.)
  3. About languages:
    1. Use any language you like, preferable on vintage computers ;-)
    2. If you use BASIC:
      1. Do not include own assembler code
        1. PEEK and POKE are allowed
        2. Even SYS is allowed (though not preferred)
      2. If possible, provide the basic code as text format
    3. If you use assembler:
      1. Measure the size of the executable (including BASIC starter stub)
      2. If possible, measure the size of the code only
      3. Please provide the source code and tell us which assembler was used
  4. Release
    1. You should not publish the code, or it's exact size, before the deadline. Please respect the personal challenge of others.
    2. Your submitted code will be released to the public (for example on sites like scene.org or demozoo.org)
  5. Target:
    1. Use your old computer / programming language (or new one, if you want)
    2. Try to optimize the program (for minimum size or maximum beauty ;-)
    3. Have fun!

Wild (Compo)

If you got motivated to something different as above, this might be for you...

  • Be wild/creative and do something similar or totally different ;-)
  • It just should be about Christmas, obviously. 
  • No count restrictions in this case.
  • No strict rules.

Notes

  • This is rather a challenge than a competition. So try to have fun.
  • If you want, you can be totally relaxed about the rules and adapt them to your needs. Add some flashing, some animation, some candles, whatever you like. 
  • If you want, you can try another approach. Try to optimize the program size as far as you can go. 
  • It's all up to you.

Submit

Rules

  • Do not reveal the code or even the exact size of the code to anyone. This shall be a personal challenge.
  • Submissions shall be final. I might be able to update your entry at most once, but there is no guarantee for that.

Format

  • Submit following within one zip file:
    • an image (screenshot) of the result (of the object) [e.g. result.png]
    • Runnable file (e.g. compiled assembler code, BASIC file that runs on host, a.s.o.) [e.g. star.prg, star.bin, star.com, ...]
    • Source code:
      • source code as readable text file (e.g. BASIC code, assembler code, etc.) [e.g. source.txt]
      • an image of the source code listed (on the native machine or on the machine coded); can be integrated with the image of the result (optional) [e.g. source.png]
    • file_id.diz:
      • see next chapter below
    • Zip file could be named like this: <username>_<system>_<language>_vc3-2023.zip, e.g. joe_cpc_basic_vc3-2023.zip

Template for file_id.diz (download)

<Name of Release>

Author: <Name of Author or Handle / Group>
Category: <Christmas Challenge or Wild>
System:   <Atari, C64, Spectrum ZX80, ...>
Language: <BASIC, Assembler, (include the version/variant, ...>
Len source code: <# bytes>
Len exe file:    <# bytes>
Len code only:   <# bytes> (net code size; subtract the bytes for header/start address; assembler: also subtract the BASIC stub)
Instructions:
<how to run the code in an emulator>
<e.g. which emulator to use and what to do; could be as simple as: Install vice, drag and drop the prg file into it>
Description:
<how the code works>
Comments:
<anything left to say>

Submission

Submissions for 2023 are over.

Sample Code

 10 print"{clear}"
 20 print""
 30 print""
 40 print""
 50 print"       *     *     *
 60 print"      * *   * *   * *
 70 print"     *   * *   * *   *
 80 print"    *     *     *     *
 90 print"     *   * *   * *   *
100 print"      * *   * *   * *
110 print"       *     *     *
120 print"      * *   * *   * *
130 print"     *   * *   * *   *
140 print"    *     *     *     *
150 print"     *   * *   * *   *
160 print"      * *   * *   * *
170 print"       *     *     *
180 print"      * *   * *   * *
190 print"     *   * *   * *   *
200 print"    *     *     *     *
210 print"     *   * *   * *   *
220 print"      * *   * *   * *
230 print"       *     *     *
333 goto 333

This version is not highly optimized. 

Measurement

The shortest size of the following provided sizes is taken for the  final "ordering/ranking":

  • Source code
  • File size
  • Executed Code (net[to] code size; "real" code)

I am aware that you can't compare language A on system B with language X on system Y. That's why the ranking has a rather informative character. 

Correctness

The correctness of your entries lies in your hands.

Of course, I can't check each entry for its correctness as on one hand it would take much time and on the other hand I am not familiar with each machine and language.

FAQ

I think comparing different machines and languages is not fair.

True. But it is interesting and as said it is not a competition. At least we can avoid unfair voting on the other hand. Oh, that was not a question. ;-)

Is it necessary, that a C64 BASIC program can also be typed in manually on a real C64? Or in other words, does the 80 characters limit apply for this compo?

No. You can use lines longer than 80 characters. The resulting program must be runnable, of course. 

What do you mean by source code?

Source code usually are commands, that a human can read and understand. It will usually be saved as pure text files. The file names may contain some special ending like .bas, .vbs, .js, .py, and so on. The (file) size of this source code is the first kind of measurement. Some source code (e.g. c or assembler) needs to be compiled. Other source code needs to be run using an interpreter.

What do you mean by file size?

This size category is most obvious to compiler languages (assembler, C, Java, ...). There, the source code needs to be compiled to an executable format, which then can be run (mostly) from the command line. But also for some interpreter languages, the size of the saved source code might differ from the source code itself. For example, the C64 will tokenize the commands, it will add some bytes for the line numbers, the start and the end of the file. The Amstrad CPC will add a 128b large header to most files. So the file size might offer advantages or disadvantages, depending on the platform.

What do you mean by executed code?

Again, we have to differentiate between compiled and interpreted code. Most compiled code will have something like a stub to start the main code. Sometimes it's just the start address plus a BASIC stub (C64), sometimes a huge header (Amstrad CPC). Removing this overhead, you get what is meant by "executed code". To make things between interpreters and compilers more fair, you may also subtract the start address or headers from files of system specific files, if they do exist.

Can I use the stub of an assembler program to store data or use side effects of the stub like zero-page or registers variables (e.g. basic line number) set by the stub?

No, you can't. If you do so, you also can't subtract the size of the stub (from the executed code) as a consequence. Exception: start address. Every program needs to start. So, if the starting process sets a register or zero-page address, you can use this side effect.

Can I place my machine code anywhere I want?

Yes. But it would be good, if you provide a standalone running program or a working loader.

Can I use language X or system Y?

Well, use whatever you want. Every system will get vintage one day, won't it?

Can I omit the line number from my BASIC program? It's a one-liner.

Most vintage BASIC dialects require the line number so that it becomes a program. Therefore, it can't be removed on such systems.

The screen of my system has less lines than the size of the object. Can I still take part?

Yes, you are allowed to use scrolling in this case. All other rules apply the same way. 

Can I withdraw my entry after the deadline?

Usually not, because recordings just start after the deadline and small changes can have a huge effect. Sorry.

Prizes

Thanks for sponsoring of following

  • K&A plus, the C64 and Amiga magazine! (Digital version of the magazine for every winner in each category.)

        

(I might find some random prize for some random participant. No guarantee though. Remember, it's all for fun!)

More sponsors are welcome!

It would be great, if someone could sponsor (the winner). Just contact me in that case.

Entries

Results on YouTube.

Statistics

 

All Entries

  • Downloads available at Scene.org
  • Download are also available here: Google Drive (be aware: Windows might not open some files [e.g. from Serato], in that case use 7z or similar)
  • All entries at Demozoo.org
  • Entries on pouet

More

Others

Support

In case you reached until this point, maybe you would like to support the project with some small donation.