New size coding contest "ZX Spectrum effect"

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
petersieg
Posts: 114
Joined: 28 Jun 2023, 09:06

New size coding contest "ZX Spectrum effect"

(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.
Attachments
images.png (3.67 KiB) Viewed 7683 times
petersieg
Posts: 114
Joined: 28 Jun 2023, 09:06

Re: New size coding contest "ZX Spectrum effect"

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
``````
Attachments
zxs.zip
Bildschirmfoto 2024-03-13 um 18.10.05.png (61.4 KiB) Viewed 7682 times
Phibrizzo
Posts: 81
Joined: 09 Nov 2022, 22:46

Re: New size coding contest "ZX Spectrum effect"

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
Posts: 652
Joined: 14 May 2018, 08:29

Re: New size coding contest "ZX Spectrum effect"

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

Code: Select all

``````chess           EQU     0x0200

ANDI    1
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
Posts: 81
Joined: 09 Nov 2022, 22:46

Re: New size coding contest "ZX Spectrum effect"

Hello
You have to be careful when specifying rules and then saying all tricks allowed.
Ah, You are right.

This is my example:

Code: Select all

``````_CPU    v5.vcpu

_VAR    FC_Main #\$20A0
_RUN    FC_Main
; -----------------------

_ORG    FC_Main

_LAB #3
LDWI    #\$0800

_LAB #1
ANDI    #1
BEQ     #2
LDI     #63
_LAB #2
XORI    #160
BNE     #1
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
Posts: 81
Joined: 09 Nov 2022, 22:46

Re: New size coding contest "ZX Spectrum effect"

petersieg wrote: 13 Mar 2024, 17:14 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
Posts: 376
Joined: 17 Feb 2021, 23:07

Re: New size coding contest "ZX Spectrum effect"

Just to see how small it can be using only C and without crashing.
Attachments
zxs3.gt1
zxs3.c
Phibrizzo
Posts: 81
Joined: 09 Nov 2022, 22:46

Re: New size coding contest "ZX Spectrum effect"

You and at67 used very smart trick: if color is biger that 63 then is black.
Congratulations!
lb3361
Posts: 376
Joined: 17 Feb 2021, 23:07

Re: New size coding contest "ZX Spectrum effect"

Phibrizzo wrote: 19 Mar 2024, 17:04 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
Posts: 652
Joined: 14 May 2018, 08:29

Re: New size coding contest "ZX Spectrum effect"

Phibrizzo wrote: 19 Mar 2024, 17:04 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!