6502.org

Anyone going to enter?

https://logiker.com/Vintage-Computing-C ... lenge-2023

I've submitted my entry in my GIBL/TinyBasic just for some retro fun.

Anyone rising to the challenge in 6502 assembler?

Cheers,

-Gordon

Just to note the rules, which are in the spirit of not spoiling anyone else's fun:

"Do not reveal the code or even the exact size of the code to anyone. This shall be a personal challenge."

So, please don't share your ideas or your guesses or algorithms or approaches, until after the competition deadline.

Yes.

I have entered in the past, but did not last year because I found the challenge, shall we say, uninspiring.

As usual, I will begin by coding up a solution in 6800 assembly language. Then go to the 6809 to see if that can improve it. Finally create 6502 and 8080 versions for comparison.

I do not like that the judging criteria are:

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)

So I will be submitting both commented and uncommented source code…

I hope this is not out of line, but the preliminary results show the 6502 version is smaller than the 6800 one.

I think it's just a fun thing to do - not particularly difficult so rather than try to squeeze every last byte out of it I've tried to be more "interesting".

And building my own computer, writing my own TinyBasic to run on that computer and using that for the entry is, I think, "interesting"

-Gordon

I never did get into the 6800. No real UK systems using it, so not much interest and the 6502 was ... cheaper. Same for the 6809, but it was a bit late to the game there. I do remember using a 6809 system for some industrial control but by then we were into high level languages (early/mid 80's) and C and BCPL were winning the game over the 6809s Pascal...

It was a funny old time.

-Gordon

I decided to look at the results from last year and have some serious concerns.

https://demozoo.org/parties/4578/

The winning entry claims only 27 bytes of code. Looking more deeply into the entry reveals many many bytes of variables and data that are not counted in that 27. Is the scoring system broken such that the total footprint is not important but only the amount of executable code?

Why is there even any scoring? Isn't it just enough to see the different programming techniques? It is best to leave any scoring results unposted. And if there is any scoring to be done, let it be for the most interesting technique.

Yes, if hand-assembly counts. My WOZMON entry surprised me by working on the first try!

It absolutely counts!

Now.. Apple II. F666G, was it?

(mini assembler)

Cheers,

-Gordon

Hey Mike. Are you not the author of VTLC? I will do one in Forth if you do one in VTLC.

I might try my hand at TurtleLogo as well.

Yeah, I'll take swing at it and see if I can come up with a base hit. VTLC isn't exactly the correct name. The original 6800 and 8080 versions are VTL-2 and my latest NMOS 6502 version is VTL02C. VTLC02 is for the 65c02. Those 65xx interpreters have a few bells and whistles that weren't in the originals, like recognizing the space character as genuine white space, and not a variable name or binary operator. As for TABs ... er ... not a good idea in any version.

I was going to write one in Vintage-Computing-Christmas-Challenge-2023 Language. It would be one byte long.

Instead I wrote it in PLASMA with twinkling stars. Certainly not going to be the smallest.

My VTL-2 version is disappointing in a head-to-head comparison with 6502 machine language, at least when using the same algorithm. Kinda makes sense, though ... LDA #50 is two bytes and two CPU cycles, and 100 A=50 is eight bytes and (mumble) CPU cycles. I am also not pleased with the portability issue associated with my rendering technique ... it uses spaces instead of newline chars, which isn't bad for the original WOZMON, but horrible on a generic terminal connected to a typical VTL-2 host, because not many of those terminals wrap lines at 40 columns like the Apple 1 does.

Here's what I came up with Forth - it compiles to 173 bytes

: S spaces 42 emit ;
: one 3 S 5 S 5 S cr ;
: two 2 S 1 S 3 S 1 S 3 S 1 S cr ;
: thre 1 S 3 S 1 S 3 S 1 S 3 S cr ;
: for 42 EMIT 5 S 5 S 5 S cr ;
: G 3 0 do one two thre for thre two loop one ;

I am sure it could be made smaller.

An applesoft one posted elsewhere is 105 bytes.