The Vintage Computing Christmas Challenge 2023

[lmimmfn]

I spent some time analysing this in Java today just to get a quick analysis of the problem in a few mins.

It's fascinating and a brilliant problem at the same time.

After analysing the problem I just let my subconscious do its thing(sounds a bit mad but that's how I do most programming, let my subconscious do the heavy lifting and let my conscious know when there's a result, which in this case was Christmas shopping today lol).

Anyways for sure I have the concepts required to have the most effecent code to generate this, the intriguing thing is code wise it has huge optimization possibilities.

Sub 30 byte code is easily possible with potential to hit 20 bytes, that MSX guys 22 bytes should be achievable.

I'll give it a try tomorrow if I have time, otherwise after tomorrow the first person to PM me I will send the solution concept.

I can't imagine doing this in 30 bytes (or even 40), and certainly not 20!!!
And I've been staring at this pattern for days!
I'm not very good at obscure z80 tricks though, so that's a problem. 

i will eat humble pie, lol, while the routine i created is small i hadn't realised that the firmware calls and register corruption(all 4 with printing the cursor at a location) add about 10-12 bytes to the execution size.
Hats off to Prodatron and lightforce6128, i cant imagine on the CPC that it can be reduced further.
Without any optimization on the Z80 front i got 64 bytes(code in actual routine is very small vs overall size) but i'm quite happy with that

[arnolde]

37 now. Still 5 Bytes too Lame 

I'm at 37 as well now – with a ridiculously simple approach (maybe the same as you?). I don't see yet where I could spare more bytes, but let's sleep over it ;-)

[Prodatron]

@arnolde: You were one of the best last year anyway, and now it's funny that we are three with the same code size (you, @lightforce6128, me). I still think that I didn't use the same approach like my MSX friend from Finland, as he told me very strange crazy things (typical for him).
I agree with you, let's sleep over it

[arnolde]

funny that we are three with the same code size

And 37 is also the same size as I had last year 
Gute Nacht!

[ervin]

I can't wait to find out what approaches you all took.
I'm very interested in your algorithms. My approach is probably very naive compared with yours.

[ervin]

I spent some time analysing this in Java today just to get a quick analysis of the problem in a few mins.

It's fascinating and a brilliant problem at the same time.

After analysing the problem I just let my subconscious do its thing(sounds a bit mad but that's how I do most programming, let my subconscious do the heavy lifting and let my conscious know when there's a result, which in this case was Christmas shopping today lol).

Anyways for sure I have the concepts required to have the most effecent code to generate this, the intriguing thing is code wise it has huge optimization possibilities.

Sub 30 byte code is easily possible with potential to hit 20 bytes, that MSX guys 22 bytes should be achievable.

I'll give it a try tomorrow if I have time, otherwise after tomorrow the first person to PM me I will send the solution concept.

I can't imagine doing this in 30 bytes (or even 40), and certainly not 20!!!
And I've been staring at this pattern for days!
I'm not very good at obscure z80 tricks though, so that's a problem. 

i will eat humble pie, lol, while the routine i created is small i hadn't realised that the firmware calls and register corruption(all 4 with printing the cursor at a location) add about 10-12 bytes to the execution size.
Hats off to Prodatron and lightforce6128, i cant imagine on the CPC that it can be reduced further.
Without any optimization on the Z80 front i got 64 bytes(code in actual routine is very small vs overall size) but i'm quite happy with that

Yes, a few CALLs significantly increase the binary size 

[lightforce6128]

I was happy to find firmware routines that at least save all registers, so that I do not have to spent byte after byte for PUSH and POP commands.

I also considered to set up one RST to shorten the calls. But setting this up requires so many bytes, that it does not pay off for such a short program - at least not in my case.

[lightforce6128]

To get the program this small, I had to make use of these rules (and maybe even bend them a bit  ):

• No need to clear the screen.
• The object can be anywhere on the screen.
• You may write spaces.
• Prompt like READY may appear. No additional characters, which are not from the operating system itself
• The program may wait for key.

The usage of the last two rules is the scary part.

After @arnolde wrote something about a "ridiculously simple approach", I'm a bit uncertain, if it is possible to reach the 37 bytes without this balancing act of interpreting rules. And if so, then maybe I could use this simpler approach AND apply the scary optimizations to press out even more bytes ...

[lmimmfn]

I was happy to find firmware routines that at least save all registers, so that I do not have to spent byte after byte for PUSH and POP commands.

I also considered to set up one RST to shorten the calls. But setting this up requires so many bytes, that it does not pay off for such a short program - at least not in my case.

Great tip 👍 
On the rules, I was more struggling with "The program may loop" and whether an infinite loop was OK lol

[Typhon]

37 bytes? Heh

I was just pleased I've just managed to break 100 so far. It's very fun nonetheless

[arnolde]

I'm stuck at 34, but in a not very beautiful version without cls.

Some tips:
If you are working with text coordinates, take a look at the Amstrad escape codes (ascii<32): sometimes it takes less bytes to output a newline character than a syscall for setting the cursor.
If you have free registers, store values that you use more than twice. So far, that's common sense, but if you play around with things like coordinate offsets of using counters the other way round you might find more possible constants.
Don't forget that if you have the negative of a value you need somewhere, you can sub instead of add and vice versa
Also, if you have a value that is 1 apart from the one you need, consider the possibillity of using adc or sbc in a place where carry is set.
Sometimes you get lucky and you find a value you can use in some register after a syscall.
And of course, always assign 16-bit values whenever possible (ld bc,&xxyy instead of ld b,&xx:ld c,&yy)

[SpDizzy]

Had tried different approaches this days, all of them aligned to @arnolde tips, but still way bigger...42 bytes best of them (with CLS) Need to try that ridiculously simple approach!! Let's see if I can find it...

[lmimmfn]

really thinking outside the box here, but maybe cheating with a small screen height of 7 chars duplicated 3 times, but with 1 line for last 4th one might be an approach?

[arnolde]

Every year at this time, I'm cursing Locomotive Software. They did a terrific job, but WHY ARE THE TEXT COORDS OF THE TOP LEFT CORNER NOT 0,0 ?  

[GUNHED]

Well, I would like to see the quickest way to perform the task too. 

[Prodatron]

Well, I would like to see the quickest way to perform the task too. 

Why? That would be VERY boring and stupid and not a good cross-platform comparison at all.
On the CPC you mainly just copy a stupid bitmap,
and on most of the other 8bit platforms you just copy prepared patterns/texts (CPC will loose anyway in this case).

[lightforce6128]

really thinking outside the box here, but maybe cheating with a small screen height of 7 chars duplicated 3 times, but with 1 line for last 4th one might be an approach?

I was also thinking about this. Changing the "screen height" and "duplicated 3 times" sounds like a hardware effect. The main problem here would be to make the duplication stop after three screens. But changing the screen width should be less problematic and maybe helps to avoid newline handling at the end of a line. This can be done via hardware or with system text windows. The latter one can be influenced with the TXT pack (TXT WIN ENABLE, &BB66), with the BASIC command "WINDOW" or even with a control sequence (character 26).

[lightforce6128]

Every year at this time, I'm cursing Locomotive Software. They did a terrific job, but WHY ARE THE TEXT COORDS OF THE TOP LEFT CORNER NOT 0,0 ?  

I think it is like this in most BASIC variants.

[lightforce6128]

Well, I would like to see the quickest way to perform the task too. 

Why? That would be VERY boring and stupid and not a good cross-platform comparison at all.
On the CPC you mainly just copy a stupid bitmap,
and on most of the other 8bit platforms you just copy prepared patterns/texts (CPC will loose anyway in this case).

Optimizing for size requires compromises that really hurt if you are used to optimize for speed. With some of the approaches I tried you can easily see how slow the graphics build up, although it is an assembler program (that makes heavy use of system routines and does some tasks multiple times). So besides smallest size (which heavily depends also on the available OS routines on the target platform), for one target platform (CPC) I would also like to see if there is a small solution that is also fast.

But this just out of curiosity, the challenge is clearly about optimizing size (and optimizing beauty in the side challenge).

[arnolde]

Ooopsie, I just noticed: The rules state that we are not allowed to publish the size of our code, so we should stop bragging about who has the smallest   (Size, as we all know, doesn't matter anyway, it's about what you are doing with it   ) 

So, just for the record: The size I mentioned earlier in this forum is NOT the size of my final submission.

[SpDizzy]

So, just for the record: The size I mentioned earlier in this forum is NOT the size of my final submission.

So, in line with the anatomical analogy provided, if you allow me, you can now state to have a micro penis? Amazing! I wish I could had too. Surgery please!

[GUNHED]

Well, I would like to see the quickest way to perform the task too. 

Why? That would be VERY boring and stupid and not a good cross-platform comparison at all.
On the CPC you mainly just copy a stupid bitmap,
and on most of the other 8bit platforms you just copy prepared patterns/texts (CPC will loose anyway in this case).

So, Programming quick is ' VERY boring and stupid' in your opinion?

[andycadley]

So, Programming quick is ' VERY boring and stupid' in your opinion?

I think it's more that, in this specific case, the quickest solution is probably not interesting because you can just throw RAM at it. Probably just setting a few registers and then a big chain of PUSH instructions.

Now, doing it in some other clever way might be more intriguing. What's the least amount of screen RAM you can use (by repeating blocks) etc might lead to more ingenious thinking.

[GUNHED]

Well, the shortest solution depends pretty much on the OS (which PRINT functions are there? How much registers do need to be set? Which registers are saved?) and if there is a way of dealing with stings.

F.e.: In some environments you have control codes which are capable to 'repeat' short 'repeats' of characters. (Can characters be zoomed? - Yes, helpful here btw.)

Eventually your OS decides how small your program can get. Basically size depends mostly on which kind of computer you're using.

Speccy won last year btw. 

[arnolde]

Of course, all the computers with direct text support by the hardware (Speccy, C64) have an advantage in this kind of competition. Two years ago, i tried to go the hard & honest way by not even using system routines for drawing the stars. My program was of course not the winner.