Are any of you going to be trying this one? It could start as early as Friday 1st December 2023, though the start date hasn’t actually been revealed yet, as far as I know.
Vintage Computing Christmas Challenge 2023 (VC³ 2023)
I’m planning to give it a go. I don’t know which vintage machine I’ll use yet. Maybe more than one!
I’ll give it a go, as usual.
I presume they’ll release the actual images on the 1st though, rather than the fuzzy ones there right now…
Language? well my own TinyBasic on a 6502, of-course 
-Gordon
The competition went live this afternoon. Finish date is Christmas day!
The official announcement video:
Please, everyone, respect the rules of this competition, whether or not you intend to enter - do not discuss any code or ideas or report any code size, until after the deadline.
So I’ve written, tested, run and submitted my entry…
Obviously not publishing it yet, however, here is a picture of the computer I ran it on:
It’s quite retro - a 6507 with 4K ROM and 4K RAM running my own Tiny BASIC…
Cheers,
-Gordon
I missed 2022, and I was late for 2021, but I’m going to see if I can successfully navigate the submission process for this year. I don’t think I’m giving too much away with just a screen shot of the output, am I? I was far too pleased with myself when my hand-assembled WOZMON code executed perfectly on the first try!!
Well done @Michael_Barry! Did anyone else have a go this year? There are (as previously) interesting post-deadline discussions going on over on stardot and on 6502.org.
I had a go on my own designed retro system (see photo above) and posted over on 6502.org, but for the benefit of others, I did it in my own TinyBasic and rather than work out some clever algorithm I just observed that there were only 4 unique lines, so made a pattern for each line - which was nothing more than a sequence of then number of spaces expressed as a single digit - each set of spaces is followed by an implicit star, then a separate “order” table of the order to print each of the 4 lines in.
REM ********************************************************************
REM * Gordon Henderson in GIBL - Gordons Interactive Basic Language *
REM * Runs on home designed 6507 Retro Computer with 4K ROM and 4K RAM *
REM * ... Nothing clever, just simple lookup operations *
REM ********************************************************************
REM Data
100 A=TOP : $A = "355"
110 B=A+8 : $B = "213131"
120 C=B+8 : $C = "131313"
130 D=C+8 : $D = "0555"
140 O=D+8 : $O = "ABCDCBABCDCBABCDCBA"
REM Loop over the "Orders" list...
150 P = O
160 X = ?P : IF X = 13 PR "" : END
170 Q = (X - 65) * 8 + A
180 GOSUB 300
190 P = P + 1
199 GOTO 160
REM Print the "Order" line
300 J = ?Q : IF J = 13 PR "" : RETURN
320 J = J - 48 : IF J = 0 GOTO 340
330 FOR K = 1 TO J : PR " "; : NEXT K
340 PR "*";
345 Q = Q + 1
350 GOTO 300
And while I didn’t exactly design the hardware and TinyBasic just for this, it was fun to run it all on a minimal retro style system.
-Gordon
I submitted an entry for the Commodore 64. Nothing fancy: just a BASIC program that pokes to the screen memory. I was intending to translate my program to 6502 assembler, but my round tuit didn’t arrive on time.
I’m looking forward to inspecting other people’s programs, especially the other C64 entries; marvelling at how small they are, and trying to understand how they work!
dmsc beat me like a rented mule on executable size, and I’m going to confess that I still don’t understand how the 8-bit Atari version works its magic, even with seemingly generous comments. The C64 version is alleged to be several bytes smaller, believe it or not.
Very nice!
I wonder if they (had to or want to) built up your computer to test the code?
I was hoping that my entry (Commodore 64 BASIC V2), 104 bytes, wouldn’t be more than twice the size of the smallest entry in the same language on the same hardware. Alas, Serato’s C64 BASIC V2 entry was only 51 bytes.
Smallest BASIC program I’ve seen, so far, is by hoglet on stardot.org.uk for the BBC Model B (and I guess other systems that run BBC BASIC). Worked out after the competition by examining programs by others. 40 bytes, or just 38 if you do CLS:RUN to execute it, and can therefore omit the CLS: from the program.
1CLS:REPEATVDU9EORABS(VPOS^2-POS^2)MOD6=3ANDPOS<19AND35:UNTILVPOS>18
The credit for this really goes to David Payne, whose official entry was 41 bytes:
1CLS:REPEATVDU32ORABS(VPOS^2-POS^2)MOD6=3ANDPOS<19AND10:UNTILVPOS>18
I just spotted a way to save one more byte in the tokenized code.