New size coding contest "ZX Spectrum effect"

[petersieg]

(I just copied his post into this new thread)

PhiBrizzo proposes a new competition. Very old, from ZX Spectum forum.

Goal: draw black and white 1x1 pixel chessboard on full screen.

Rules:
- must run on ROMv5+
- 32KB+ machines
- no SYS functions
- all tricks allowed

The winner is: shortest gt1 file.

[petersieg]

Here is mine solution (not sure, if screen is correct this way?):

Code: Select all

int main(void)
{
	int x,y;

	for (x=0;x<160;x+=2) {
	  for (y=0;y<120;y+=2) {
	    screenMemory[y-1][x-1] = 0;
	    screenMemory[y][x] = 0xff;
	  }
	}	
}

Code: Select all

-rw-rw-r--@ 1 ich  staff  141 13 Mär 17:53 Makefile
-rw-r--r--@ 1 ich  staff  265 13 Mär 18:09 zxs.c
-rw-r--r--  1 ich  staff  107 13 Mär 18:09 zxs_v5a.gt1

[Phibrizzo]

Hello

In Your code is little error.
In loops you must started from x=1 and y=1. Because you did [x-1][y-1].
And first index = x - 1 = -1. The same for y.

Okay, we have the first player, who next?

[at67]

You have to be careful when specifying rules and then saying all tricks allowed.

Code: Select all

chess           EQU     0x0200


addr            EQU     0x30
addr            DW      0x0800


chess           LD      addr + 1
                ADDW    addr
                ADDI    1
                ANDI    1
                ADDI    0x3F
                POKE    addr
                LDW     addr
                ADDI    1
                STW     addr
                BRA     chess

vCPU Code Size: 20 bytes
GT1 Size: 31 bytes

- Overwrites offscreen memory
- Crashes when it wraps back around to address 0x0000

I wrote a second version in native code that only runs in emulation, (unless you burn a ROM), does not use SYS functions and uses no vCPU instructions and does not produce a GT1 file, hence:
vCPU Code Size: 0 bytes
GT1 Size: 0 bytes

P.S. If you want to see the native version I'll post it here.

*Edit* corrected an error in starting pixel

[Phibrizzo]

Hello

You have to be careful when specifying rules and then saying all tricks allowed.

Ah, You are right.

About Your program, i can only say: You Win!

This is my example:

Code: Select all

_CPU    v5.vcpu

_VAR    FC_Main #$20A0
_RUN    FC_Main
; -----------------------
_VAR    ScrAdr  #129
_VAR    ScrAdrH #130

_ORG    FC_Main

 _LAB #3
        LDWI    #$0800
        STW     ScrAdr

_LAB #1
        LD      ScrAdrH
        XORW    ScrAdr
        ANDI    #1
        BEQ     #2
        LDI     #63
_LAB #2
        POKE    ScrAdr
        INC     ScrAdr
        LD      ScrAdr
        XORI    #160
        BNE     #1
        ST      ScrAdr
        INC     ScrAdrH
        LD      ScrAdrH
        XORI    #128
        BNE     #1
        
        ;HALT	; no SYS function ;)
        BRA #3

40 bytes code, 46 bytes GT1.

P.S. If you want to see the native version I'll post it here.

This is not nessesry. I dont know native language.

[Phibrizzo]

Here is mine solution (not sure, if screen is correct this way?):

Today i check Your program on real Gigatron.
Im sorry, but Your program does not meet its main goal.

[lb3361]

Just to see how small it can be using only C and without crashing.

[Phibrizzo]

I disasembled Your program.
You and at67 used very smart trick: if color is biger that 63 then is black.
Congratulations!

[lb3361]

I disasembled Your program.
You and at67 used very smart trick: if color is biger that 63 then is black.

I saw this in at67's code above in this thread.
My challenge was to make the C compiler produce the optimal code.

Note that a color bigger than 63 is not always black.
The vga output only uses the low 6 bits. The two 2 bits are ignored.

[at67]

I disasembled Your program.
You and at67 used very smart trick: if color is biger that 63 then is black.
Congratulations!

What I did was pretty simple and somewhat sneaky:

1) Only one loop with no comparisons.
2) You can treat screen memory as one complete non-fragmented segment, i.e. write pixels to the 96 byte offscreen/hidden segments.
3) Toggle the pixel colour using a combination of the low byte and high byte of the incrementing address, this gives us the alternate colour pixels in x and y.
4) Alternate between 0x00/black and 0x3F/white for the pixel colour without branching.
5) Let the code run rampant once it's finished all pixels, i.e. no sanity/safety checks.
6) Use static initialisation of variables, (which my assembler supports), rather than wasting LDI/LDWI instructions in code.

For these kinds of competitions you really need to be more explicit in your rules, or people will have a field day, i.e. I wrote a native version that satisfies the current rules and produces a gt1 file of 0 bytes...

A set of potentially less exploitive rules could go as follows:

- Must produce a physical gt1 file.
- Must run 100% vCPU code, (assembled, compiled or interpreted).
- Must not call SYS functions.
- Must run on <= ROMv5a and 32KByte RAM hardware.
- Must visit all 160x120 pixels.
- Must not write to any offscreen memory.
- Must not mess with the video indirection table to make the onscreen video size smaller or allow for pixel duplication.
- Must produce a stable image and not crash.
- Winner is decided by smallest vCPU code size AND smallest .GT1 file size, with priority going to vCPU code size.

Even with these rules I would hope someone would find a loophole, as that's where the fun really is!