The Vintage Computing Christmas Challenge 2024

[arnolde]

Yes, I agree! What I like about this year's callenge is that even if you find the best and most optimized algorithm for the main shape, it's not worth anything if you can't use its routines for drawing the bow in the first line – that's what I am struggling the most with at the monent... 

But I made an interesting discovery which might give our Z80 with its 16 bit arithmetics a little advantage... 

[lightforce6128]

I wonder if anyone has tried chatGPT.

When I tried this last time, it was not quite good in Z80 assembly, but always stumbled towards 6510 assembly. It seems the training data did not contain enough information about Z80 programming. Maybe this has changed now, or maybe it is possible to provide it with the additional needed information (e.g. as part of the question or as attachment). Somewhere I saw specialized ChatGPTs with Z80 knowledge. I guess, for Locomotive BASIC it is not much different.

But size coding is very different from normal software development. Because the training data probably contained much normal source code and only a bit of size coding, this would also need additional information. To get a good answer, you would have to ask a really long and elaborated question, containing all the information that guides ChatGPT to a good answer.

But once you have this prompt, it maybe can be reused for the next challenge ...

[lightforce6128]

For a BASIC program, how do you measure the size? As far as I can see, there are several possibilities:

• Edit the source code with an editor / on an OS where the size in bytes is printed out.
• Store it on disc and look into the header.
• Use FRE(0) before and after writing the program.
• Use this: ?PEEK(&AE66)+256*PEEK(&AE67)-PEEK(&AE64)-256*PEEK(&AE65)
• Something that is simpler to use and that I do not know.

All these approaches will show small differences, but every byte counts.

[lightforce6128]

Yes, I agree! What I like about this year's callenge is that even if you find the best and most optimized algorithm for the main shape, it's not worth anything if you can't use its routines for drawing the bow in the first line – that's what I am struggling the most with at the monent... 

But I made an interesting discovery which might give our Z80 with its 16 bit arithmetics a little advantage... 

Currently I have given up on this and spent a lot of bytes to draw the bow separately (and to reserve the empty row for it). It would be nice if this could somehow be combined with the main drawing routine ...

I also were thinking about to use 16 bit arithmetics, but I urgently need the 8 bit registers at another location. And I need more registers ...

[BSC]

I am really looking forward to the other solutions this time. Much more than last year. 

[Mark_wllms]

All characters can be replaced with another character if this does NOT influence the code.

Has anyone tried searching for any of these character sequences in the Amstrad ROM?

[prevtenet]

I wonder if anyone has tried chatGPT.

When I tried this last time, it was not quite good in Z80 assembly, but always stumbled towards 6510 assembly.

I've had the best luck with Claude 3.5 Sonnet, at least for having a good mixture of technical knowledge and generating (mostly) correct Z80 assembly. It's not yet good enough to just cut-and-paste and expect it to work, but it does come up with useful ideas I would have missed.

[arnolde]

Has anyone tried searching for any of these character sequences in the Amstrad ROM?

Of course! But without luck...

[ZorrO]

@lightforce6128 

After reset on 6128 type:
?fre(0)  give 42249
load"basic
again ?fre(0)  give something
?something-42249  get size Basic

After RUN probably some variables took some space, you can try add first line
1 END
run
1  - to delete this line, and try ?fre(0)  again, but to be sure better save it, reset and measure after load. 

[Longshot]

5 days left...

Happy holidays

[Prodatron]

5 days left...

And probably 10 days left until the results...
I am very excited!!

[arnolde]

OK, i just submitted a Loco Basic and an Assembler entry.
I feel a bit silly this year, like I have the imression that both my approaches were not really the most clever ones and also I didn't find a lot of optimizations , but we'll see...

I am anyway very very curious to see what you guys did!

Until then, Merry Christmas!!!

[Overflow]

Entry submitted !

Much to discuss here in a few days. I'm eager to see others' approaches - on other computers too. To loop or not to loop - that is the question !   

[arnolde]

To loop or not to loop - that is the question !   

Yes, and if so, how 

I'm also very much looking forward.

[Prodatron]

The presentation of the entries is finished and will be shown today, at 7 pm CET.

[Prodatron]

Crazy, Logon System will be one of the best again W.T.F.

[Prodatron]

Congratulation again to Longshot and Overflow, but also to Lightforce, you are all crazy cool!!

[arnolde]

Incredible achievement by all the winners! I can't wait to study all this sources in detail – and I hope you guys are here for us if we need some details explained 

[Prodatron]

It's the first time that a CPC entry (Longshot) was #1 (together with a 6502 entry) for all ASM entries. Soooooo cool!
Funny, this time it seemed to be too complex for Spectrum guys haha (just kidding!).

Yes, I have to study the other CPC entries soon (currently the video is too bad to see the Logon System sources)

[Longshot]

Congratulations to all participants, this year again, the codes are varied and appetizing.
I will look at some sources.

The Lightforce6128 code is amazing , especially in the way it displays the object. Congratulations!!
The ribbon is "executed" and it found the display routine in high rom: more interesting than the routine in low rom that I use. (To remember for next time).

The code from Overflow is a Z80A cathedral.

currently the video is too bad to see the Logon System sources

Code Select Expand

;;=======================================================================
;; Vintage Computing Christmas Challenge 2024 (VC3 2024)
;; Amstrad CPC 6128 / Longshot (Logon System)
;; December 2024
;; 41 bytes.
;; Christmas strings in the box
;; run from basic : memory &2d00:mode 0:load "vcc2024.bin":call #2d2b
;; or type : run "STUB" with the same content
;; For 464 or 664 model, update _firm_disprom equ.
;;=======================================================================
_firm_disprom_464  equ #6eb
_firm_disprom_664  equ #6ec
_firm_disprom_6128 equ #6fc

_firm_disprom    equ _firm_disprom_6128

size_code     equ end_code-start_code
org_code    equ #7f00-5

        org org_code
start_code
                    ; on run (de=#2d2b, hl=#004x, a=0 bc=#20ff)
                    ; #2d2b >> 1st charset "-+"
exec_code
        ld hl,#8000+200        ; End of christmas_buffer+1 >> #8000+(20 bytes x 10 lines)
fill_10lines                ; ========================
        ld bc,#14dc        ; b=19+1 loop / c=200-1+21 (for lddr)
        ld a,h            ; a=%10000000 (selector for 2nd char of charset) 8 bits+Carry
fill_oneline                ; ------------------------
        dec l            ; ptrbuf-- ZF=1 if l==0
        rla            ; rotate selector 9 bits
        ld (hl),d        ; "-" or " "
        jr nc,select_2ndchar    ; CF=0 first char
        ld (hl),e        ; "+" or "!"
select_2ndchar
        djnz fill_oneline    ; complete line
                    ; ------------------------
        ld de,#2021        ; New current charset " !"
        ld (hl),d        ; + 1 space
        jr nz,fill_10lines    ; new line until hl=ptrbuf=#8000 (l=0 ZF=1)
                    ; ========================
        ld d,h            ; d=msb ptrbuf
        dec hl            ;
        ld e,200-1        ; Duplicate (9+1) lines to (1+9+1) lines
        ex de,hl
        lddr
        ld l,christmas_string    ; h is ok. l on lsb string buffer
        rst #28            ; Display string & go back to Basic
        dw _firm_disprom     ;

christmas_string
        db #1f,10,#7f        ; locate x=10 y=scroll down
        db #cd,"O",#cc,13,10    ; gift bow "\","O","/"
christmas_buffer            ; Buffer to build   
end_code

[ZorrO]

This year I was too lazy to send, but I enjoyed watching someone's works, especially in the wild category. Like last year, I also didn't understand most of it.

Just like last year, I was most interested in BASIC CPC. The best result was Azicuetano at 19:23, only 86 bytes.

But it seems to me that Logiker made a mistake in counting sources and omitted spaces that are part of the program. After entering it in the emulator and of course removing unnecessary spaces after PRINT, and before TO and before THEN, it comes out to 98 bytes. Which gives it third place in CPC BASIC, not first.

I would fix two things there, I would remove the semicolon from the first PRINT, that's 1 byte of savings. And instead of "<" in the second PRINT I would add the Ctrl+H arrow symbol at the end of both versions of o$. We subtract 3 bytes and add 2, which gives a total savings of two bytes. But still 3rd place.

And I would have fourth in CPC, if I sent it. 

[dodogildo]

Congrats to everybody who participated and to the Logon Systems in particular.

[lightforce6128]

Congratulation to @Overflow and @Longshot for reaching 42 and even 41 bytes. This will be interesting literature.

Until now I tried 4 approaches in BASIC and 3 in assembly.

When I wrote this, it came into my mind that this could be misunderstood as a (forbidden) hint to a size of 43 bytes. This was not really a problem, because at this time I was far from this, and others, too. So I let this ambiguous meaning uncommented. Maybe it would encourage others to reach this ridiculous low number ...

Then, slowly, I reached exactly this number by myself. With a strict understanding of the rules now this would be a problem. So I tried everything to somehow reach at least 42 bytes, but without success.

This is a true story! I'm innocent! Luckily the rules are not applied so strictly.

[lightforce6128]

This year I was too lazy to send, ... And I would have fourth in CPC, if I sent it. 

When we talked about this earlier, you already had a quite good result, 10 bytes smaller than my best approach. You should have sent in your work.

But I fully understand this. For me it was the same last year. I had already a good approach, but hesitated to sent it in on time.

[Overflow]

Wow! was a blast for CPC reaching thé higher places.

Double kudos for lightforce6128 : nice catch for the high rom call, and a fantastic way to draw thru poking locate coordinates

 I'll have a look at other entries later. Here's mine.

Code Select Expand

org #2100 -#22; call #0901=de
loop_Y  ld h,#21   
loop_knot   ld a,(hl)
            call #BB5A
            dec l
            jr nz,loop_knot
        dec (hl); (#2100) counts Y
        ret z
        ld l,h; hl=#2121="! "+1
        dec e
        jr nz,jr_Y
            ld e,d; =9
            ld hl,#2B2D; "+-"
jr_Y equ $ -1; #2B == dec hl           
        ld bc,#100 +19; b counts X
loop_X      ld a,l
            djnz jr_X
                ld b,d; =9
                ld a,h
jr_X        call #BB5A
            dec c
            jr nz,loop_X
        db #C3; jp #0Dxx=loop_Y
    db 19 +1; counts Y at org #2100
    db #0D,#CC,"o",#CD,0,9,#1F