Gigatron Hackers

(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.

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

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?

You have to be careful when specifying rules and then saying all tricks allowed.
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

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:
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.

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.

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

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

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.

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!