SizeCoding - User contributions [en]

Christmas Star

2022-12-28T20:41:48Z

Logiker: Christmas Star from the Vintage Computing Christmas Challenger 2022

[[Category:Case Study]]
==The challenge==
During the [https://demozoo.org/parties/4578/ Vintage Computing Christmas Challenge 2022] the goal was to create the shape of a given Christmas star with as few bytes as possible. All platforms and languages were allowed.
The star should look exactly like shown below.
<code>
* *
** **
*** ***
**** ****
*****************
***************
*************
***********
*********
***********
*************
***************
*****************
**** ****
*** ***
** **
* *
</code>
There were mainly two kinds of approaches:
* draw character by character
* mirror triangles
* etc
==Winning Entries==

File format

2022-01-17T09:23:25Z

Logiker: Sorted descencding by bit, added Amiga template

=File formats=

File formats describe the content of a file.

This page is not about:
* File systems which organize files on a partition
* Disk images which save a (disk) file system within one file
* Tape file formats, as they have a higher overhead usually

==IBM PC==

===COM===
System: MS-DOS

Header: 0 bytes see [https://en.wikipedia.org/wiki/COM_file here]

Native size unit: Bytes

Loads to: 0100h

Starts at:

File extension: .com

===EXE===
System: Windows

Header: 200+

Native size unit: Bytes

Loads to:

Starts at:

File extension: .exe

===Linux===
System: Linux

Header: ca. 100

Native size unit: Bytes

Loads to:

Starts at:

File extension: none

==Atari ST==
===TOS===
System: Atari ST

Header: 32 Bytes

Native size unit: ???

Loads to:

Starts at:

File extension:

==Amiga==
===...===
System: Amiga

Header:

Native size unit: ???

Loads to:

Starts at:

File extension:

==Commodore 64==
===PRG===
System: CBM-DOS (Commodore, e.g. C64)

Header: 2 bytes (= start address)

Native size unit: Blocks (256 bytes including 2 bytes linking to next block)

Loads to: given address in header

Starts at: given address in header

File extension: .prg

===P00===
System: CBM-DOS / PC64 Emulator

Header: extended 26 bytes; also includes the name; see [http://unusedino.de/ec64/technical/formats/pc64.html here]

Native size unit: Blocks

Loads to: given address in header

Starts at: given address in header

File extension: .p00

==Atari 8bit==
===XEX, EXE, COM===
System: Atari

Header: 6 bytes or more (FF FF <start address> <end address>); see also [https://www.atarimax.com/jindroush.atari.org/afmtexe.html here]

Native size unit: ???

Loads to: given start address in header

Starts at: given end address in header

File extension: .exe .com .xex (any ending possible)

==Amstrad==
===BIN===
System: AMSDOS (Amstrad CPC)

Header: 128 bytes (includes filename, start address, end address, etc.; 95 unused bytes; see also [https://www.cpcwiki.eu/index.php/AMSDOS_Header AMSDOS-Header]

Native size unit: kb

Loads to: given start address in header

Starts at: given end address in header

File extension: .bin (on PC)

==Spectrum==
===Binary===
System: ZX Spectrum

Header: none

Native size unit: ???

Loads to: special loader required; usually a BASIC program

Starts at: see above

File extension: ??? usually delivered within a disk image (.trd)

File format

2022-01-17T09:16:18Z

Logiker: added Linux

=File formats=

File formats describe the content of a file.

This page is not about:
* File systems which organize files on a partition
* Disk images which save a (disk) file system within one file
* Tape file formats, as they have a higher overhead usually

==IBM PC==

===COM===
System: MS-DOS

Header: 0 bytes see [https://en.wikipedia.org/wiki/COM_file here]

Native size unit: Bytes

Loads to: 0100h

Starts at:

File extension: .com

===EXE===
System: Windows

Header: 200+

Native size unit: Bytes

Loads to:

Starts at:

File extension: .exe

===Linux===
System: Linux

Header: ca. 100

Native size unit: Bytes

Loads to:

Starts at:

File extension: none

==Commodore==
===PRG===
System: CBM-DOS (Commodore, e.g. C64)

Header: 2 bytes (= start address)

Native size unit: Blocks (256 bytes including 2 bytes linking to next block)

Loads to: given address in header

Starts at: given address in header

File extension: .prg

===P00===
System: CBM-DOS / PC64 Emulator

Header: extended 26 bytes; also includes the name; see [http://unusedino.de/ec64/technical/formats/pc64.html here]

Native size unit: Blocks

Loads to: given address in header

Starts at: given address in header

File extension: .p00

==Atari 8bit==
===XEX, EXE, COM===
System: Atari

Header: 6 bytes or more (FF FF <start address> <end address>); see also [https://www.atarimax.com/jindroush.atari.org/afmtexe.html here]

Native size unit: ???

Loads to: given start address in header

Starts at: given end address in header

File extension: .exe .com .xex (any ending possible)

==Atari ST==
===TOS===
System: Atari ST

Header: 32 Bytes

Native size unit: ???

Loads to:

Starts at:

File extension:

==Amstrad==
===BIN===
System: AMSDOS (Amstrad CPC)

Header: 128 bytes (includes filename, start address, end address, etc.; 95 unused bytes; see also [https://www.cpcwiki.eu/index.php/AMSDOS_Header AMSDOS-Header]

Native size unit: kb

Loads to: given start address in header

Starts at: given end address in header

File extension: .bin (on PC)

==Spectrum==
===Binary===
System: ZX Spectrum

Header: none

Native size unit: ???

Loads to: special loader required; usually a BASIC program

Starts at: see above

File extension: ??? usually delivered within a disk image (.trd)

File format

2022-01-17T09:11:14Z

Logiker: Added Windows and Atari ST format (template)

=File formats=

File formats describe the content of a file.

This page is not about:
* File systems which organize files on a partition
* Disk images which save a (disk) file system within one file
* Tape file formats, as they have a higher overhead usually

==MS-DOS==
===COM===
System: MS-DOS

Header: 0 bytes see [https://en.wikipedia.org/wiki/COM_file here]

Native size unit: Bytes

Loads to: 0100h

Starts at:

File extension: .com

==Windows==
===EXE===
System: Windows

Header: 200+

Native size unit: Bytes

Loads to:

Starts at:

File extension: .exe

==Commodore==
===PRG===
System: CBM-DOS (Commodore, e.g. C64)

Header: 2 bytes (= start address)

Native size unit: Blocks (256 bytes including 2 bytes linking to next block)

Loads to: given address in header

Starts at: given address in header

File extension: .prg

===P00===
System: CBM-DOS / PC64 Emulator

Header: extended 26 bytes; also includes the name; see [http://unusedino.de/ec64/technical/formats/pc64.html here]

Native size unit: Blocks

Loads to: given address in header

Starts at: given address in header

File extension: .p00

==Atari 8bit==
===XEX, EXE, COM===
System: Atari

Header: 6 bytes or more (FF FF <start address> <end address>); see also [https://www.atarimax.com/jindroush.atari.org/afmtexe.html here]

Native size unit: ???

Loads to: given start address in header

Starts at: given end address in header

File extension: .exe .com .xex (any ending possible)

==Atari ST==
===TOS===
System: Atari ST

Header: 32 Bytes

Native size unit: ???

Loads to:

Starts at:

File extension:

==Amstrad==
===BIN===
System: AMSDOS (Amstrad CPC)

Header: 128 bytes (includes filename, start address, end address, etc.; 95 unused bytes; see also [https://www.cpcwiki.eu/index.php/AMSDOS_Header AMSDOS-Header]

Native size unit: kb

Loads to: given start address in header

Starts at: given end address in header

File extension: .bin (on PC)

==Spectrum==
===Binary===
System: ZX Spectrum

Header: none

Native size unit: ???

Loads to: special loader required; usually a BASIC program

Starts at: see above

File extension: ??? usually delivered within a disk image (.trd)

File format

2021-12-29T10:43:51Z

Logiker: initial version of file formats

=File formats=

File formats describe the content of a file.

This page is not about:
* File systems which organize files on a partition
* Disk images which save a (disk) file system within one file
* Tape file formats, as they have a higher overhead usually

==MS-DOS==
===COM===
System: MS-DOS

Header: 0 bytes see [https://en.wikipedia.org/wiki/COM_file here]

Native size unit: Bytes

Loads to: 0100h

Starts at:

File extension: .com

==Commodore==
===PRG===
System: CBM-DOS (Commodore, e.g. C64)

Header: 2 bytes (= start address)

Native size unit: Blocks (256 bytes including 2 bytes linking to next block)

Loads to: given address in header

Starts at: given address in header

File extension: .prg

===P00===
System: CBM-DOS / PC64 Emulator

Header: extended 26 bytes; also includes the name; see [http://unusedino.de/ec64/technical/formats/pc64.html here]

Native size unit: Blocks

Loads to: given address in header

Starts at: given address in header

File extension: .p00

==Atari==
===XEX, EXE, COM===
System: Atari

Header: 6 bytes or more (FF FF <start address> <end address>); see also [https://www.atarimax.com/jindroush.atari.org/afmtexe.html here]

Native size unit: ???

Loads to: given start address in header

Starts at: given end address in header

File extension: .exe .com .xex (any ending possible)

==Amstrad==
===BIN===
System: AMSDOS (Amstrad CPC)

Header: 128 bytes (includes filename, start address, end address, etc.; 95 unused bytes; see also [https://www.cpcwiki.eu/index.php/AMSDOS_Header AMSDOS-Header]

Native size unit: kb

Loads to: given start address in header

Starts at: given end address in header

File extension: .bin (on PC)

==Spectrum==
===Binary===
System: ZX Spectrum

Header: none

Native size unit: ???

Loads to: special loader required; usually a BASIC program

Starts at: see above

File extension: ??? usually delivered within a disk image (.trd)

Z80

2021-12-28T08:40:12Z

Logiker: cpc emus added

== Introduction ==
Wanting to start sizecoding on a Z80 platform in this day and age can be tough.

So here is a bit of help to get you started:

=== Registers ===
The Z80 can be seen as the little 8-bit brother of X86 chipsets, with many similarities.
If you are coming from a X86 background, this might help you get a bit more grip on the Z80.
These are the register pairs of the Z80, as seen from a X86 programmers perspective.

* AF = AL + Flags
* HL = Can be seen as BX (H=BH,L=BL) or SI in a (HL) setting, like BX also used for addressing.
* BC = Can be seen as CX (B=CH,C=CL), often used for loops
* DE = Can be seen as DX (D=DH,E=DL) or DI in a (DE) setting
* IX = 16 bit Index Register X, can also be accessed with IXH,IXL
* IY = 16 bit Index Register Y, can also be accessed with IYH,IYL

For each of the main registers there also exists a shadow register. These cannot be accessed directly, but must be swapped in and out with the main register set. The shadow registers are usually denoted by the ' symbol. They can be swapped with the following commands:
* EX AF,AF' = Swaps AF with AF'
* EXX = Swaps BC, DE and HL with BC', DE' and HL'
There are no shadow registers for the index registers.

Note: For a lot of operations, you can only use the A(8bit) and HL(16bit) registers.
The Sjasmplus assembler doesn't really do proper syntax checking for this so beware.

=== Instructions ===
Here is a rough translation for some of the Z80 instructions:

* BIT = TEST
* CP = CMP (although the Z80 has many other handy compare functionality)
* DJNZ = LOOP (decreases B and checks not zero)
* EXE = Exchange all registers with Shadow registers, can be used a bit like PUSHA/POPA
* EX = XCHG
* HALT = HLT
* JP = JMP
* JR = JMP NEAR (Jump Relative)
* LD = MOV
* LDI = MOVSB (tmp=(HL),(DE)=tmp, DE++, HL++)
* LDIR = REP MOVSB (tmp=(HL),(DE)=tmp, DE++, HL++, BC--)

=== Learning Z80 Assembler ===
There are many Z80 tutorials available online, but one i found very simple and clear is at this 1996 styled webpage ;-)

* http://www.z80.info/lesson1.htm
* http://www.z80.info/lesson2.htm
* http://www.z80.info/lesson3.htm
* http://www.z80.info/lesson4.htm
* http://www.z80.info/lesson5.htm

There is no proper index-page for this, which is why i linked all the lessons above, but you can continue to the next lesson by clicking at the next lesson at the bottom of the page.

Also, here is a compact 'cheat sheet' with some basics for various Z80 systems:
https://www.chibiakumas.com/z80/CheatSheet.pdf

== ZX Spectrum ==
The ZX Spectrum consists of a Z80A @ 3.5 MHz CPU with either 16k, 48k or 128K of RAM. Most demos are targeted at the Spectrum 128 because it includes more memory, a shadow screen buffer and an AY soundchip. The different models have slightly different timings - this will cause issues if you are doing cycle-exact effects like multi-color.

=== Setting up ===
Setting up your development platform for the ZX Spectrum is quite easy, first get the following tools:

* Assembler: SJASMPLUS -This assembler has nice macros for creating Binaries and SNA snapshot files out of the box. You can download it at https://sourceforge.net/projects/sjasmplus/
* Pasmo - for the .TAP create. Available at : http://pasmo.speccy.org
* Emulator(s): I Found [https://www.zophar.net/sinclair/zx-spin.html ZX Sping], [https://sourceforge.net/projects/fuse-emulator/ FUSE], [https://sourceforge.net/projects/unrealspeccyp/ UnrealSpeccy] and [https://www.aptanet.org/eightyone/ EightyOne] to work best for my usecase. Most emulators can read TAP, SNA and TRD files out of the box.

=== Start values ===
Upon startup (when called from basic), the following values can assumed:

* The alternate HL register is set to 0x2758
* BC = start address
* A = C

=== Video display ===
Video display on the ZX Spectrum is mostly CPU based with little hardware features. No hardware sprites, no specific text or video modes, only a 256x192 byte screenbuffer with 1bit pixeldata located at $4000 in memory.
It is ordened a bit strange in 3 sections of 256x64 pixels, then character rows, then subrows.

Address = 010RRLLL RRRCCCCC

* where RRRRR is the row number (0..23)
* CCCCC is the column number (0..31)
* LLL is the line number within the cell (0..7)

Calculating a screen address from XY coordinates is complicated due to the weird screen layout. In a larger demo you would generate a lookup table - it's usually best to avoid such calculations in small demos, but it can be done in under 30 bytes, eg: http://www.breakintoprogram.co.uk/computers/zx-spectrum/screen-memory-layout

==== Adding Color ====
The ZX Spectrum has a 32x24 colormap located at $5800 where you can write color information for each 8x8 tile.
It has has 8 colors (INK and PAPER) with 2 brightness settings that can be set like this.

color = brightness(64) | (PAPER<<3) | INK

Because updating pixel memory can be slow, especially when you are grasping for bytes, some of the tiny intros on the zx spectrum prefer to use the colorram for the effect, sometimes in combination with an overlaying pattern.

==== Border Color ====
You can set the border color to any of the 8 colors with:

<syntaxhighlight lang="z80">
ld a,0 ; bottom three bits of a contain the color
out (254),a
</syntaxhighlight>

=== Memory Configuration ===
128K separated to 8 pages (16384 bytes size)
Default configuration is:

: page 5: $4000-$7fff
: page 2: $8000-$Bfff
: page 0: $C000-$Ffff

There are two screens - page 7 and page 5.
port $7FFD allow to control memory and screens:
: bits 0-2 - page number mapped to memory at $C0000
: bit 3 - Select page 5(0) or page 7(1) to be displayed.
: bit 4 - ROM Select. 0-128K,1-48K

Example of use
<syntaxhighlight lang="z80">
loop: ei
halt
pg: ld a,$17
ld bc,$7ffd
out (c),a
xor $0A
ld (pg+1),a
... do something with $C000-$DB00
jp loop
</syntaxhighlight>

$17 is use 48K, map page 7
After xor $0A we'll get value $1D(use 48K ROM, display screen at page 7 and map page5 at $C000).This is so-called "double buffering".
See also : https://worldofspectrum.org/faq/reference/128kreference.htm

==== Getting something on screen ====
Now to get something on screen, lets fill our colorram with a simple AND pattern, like so:
<syntaxhighlight lang="z80">
ld de,5800h
ld b,24
yloop:
ld c,32
xloop:
ld a,c
and b
and 7 ; make sure range is 0..7
ld (de),a
inc de
dec c
jr nz,xloop
djnz yloop
</syntaxhighlight>

==== Using a Backbuffer ====
While the above code will run fine, you might want to consider using a backbuffer for more complex stuff. You can then simply write to another adress define by BACKBUFFER (for example A000) and copy the buffer to colorram like so:

<syntaxhighlight lang="z80">
halt ; synchronize
ld hl,BACKBUFFER
ld de,5800h
ld bc,768
ldir
</syntaxhighlight>

Another alternative method is to use the 128's memory paging, which provides a second screen buffer. This buffer is located at a different memeory location, but otherwise it is the same:
<syntaxhighlight lang="z80">
; main loop starts here
ld a,00010111b ; set up memory banks and screen here
mainloop
halt ; sync
xor 00001010b ; flip screens
out ($fd),a
push af

; render code goes here
; screen buffer is location at 0xC000 instead of 0x4000

pop af
jr mainloop
</syntaxhighlight>

==== Overlaying simple graphics ====
If you don't want to use a solid color/tile for.
You could copy a single tile across the screen at startup for some flair.
<syntaxhighlight lang="z80">
ld a,0x55 ; 01010101 pattern
ld bc,0x1800
copyloop:
ld (de),a
inc de
dec c
jr nz,copyloop
djnz copyloop
</syntaxhighlight>

Alternatively you could generate a pattern using logic operations or random noise/data.
==== Useful routines ====

<syntaxhighlight lang="z80">
;calculate address of next line,HL=address
down_hl:
INC h
LD A,h
AND 7
RET NZ
LD A,L
ADD A,#20
LD L,A
RET C
LD A,H
SUB 8
LD H,A
RET
</syntaxhighlight>

<syntaxhighlight lang="z80">
;move up at screen, HL=address
up_hl
LD A,H
DEC H
AND 7
ret nz
LD A,L
SUB 32
LD L,A
ret c
LD A,H
ADD A,8
LD H,A
ret
</syntaxhighlight>

<syntaxhighlight lang="z80">
;write pixel
CALL 8933 ; C=X(0..255),B=Y(0..175),5C7D=COORDS
</syntaxhighlight>

<syntaxhighlight lang="z80">
;Calculate vertical line screen Address, IN : A=Y coordinate, OUT : HL=address
py2saddr:
ld l,a
; ld a,l
and $07
ld h,a
ld a,l
and $c0
rra
inc a
rrca
rrca
or h
ld h,a
ld a,l
add a
add a
and $e0
ld l,a
</syntaxhighlight>

<syntaxhighlight lang="z80">
;Calculate Attribute address, IB: reg D=Y,reg E=X, OUT: HL=address, destroys DE
ld l,d
add hl,hl
add hl,hl
ld h,$11
add hl,hl
add hl,hl
add hl,hl
ld d,0
add hl,de
</syntaxhighlight>

or alter version
<syntaxhighlight lang="z80">
;H=Y coordinate,L=X coordinate
ld a,h
rrca
rrca
rrca
push af
and 3
add a,$58
ld h,a
pop af
and %11100000
add a,l
ld l,a
</syntaxhighlight>

calculate Pixel coordinate
<syntaxhighlight lang="z80">
;IN: A=X coordinate,C=L=Y coordinate
;OUT: HL=screen address,A=bit value
call #22B0
</syntaxhighlight>

=== Sound ===
The original Spectrum has only a 1 bit sound capability (BEEP) through its internal speaker.
Later models included the AY-3-8910 Soundchip which provides 3 channels of PSG sound.

==== Make some noise - Beeper ====
Setting/toggling bit 4 of port 254 will enable the beeper speaker.

<syntaxhighlight lang="z80">
ld a,$10 ;Bit 4 set
beeploop: xor $10 ;toggle Bit 4
out (254),a
ld b,90 ;wait
djnz $
jp beeploop
</syntaxhighlight>
Note that the bottom three bits of port 254 also set the border color (see above).

==== Make some noise - AY ====
You can access the AY soundchip by outputting to the following ports:

<syntaxhighlight lang="z80">
ld bc,0xfffd
ld a, ay register number
out (c),a
ld b,0xbf
ld a, data byte
out (c),a
</syntaxhighlight>

For more information about the soundchip, check out:
https://www.atarimagazines.com/v4n7/stsound.html

=== Small demos with documented source code ===
* Ceci N'est Pas Un Cube by Ate Bit https://www.pouet.net/prod.php?which=29691
* Zxwister by Ate Bit https://www.pouet.net/prod.php?which=44123
* Muse by Ate Bit https://www.pouet.net/prod.php?which=62880
* Starlet Guitarlet by HOOY-PROGRAM https://www.pouet.net/prod.php?which=52553
* Clangers On The Dancefloor by HOOY-PROGRAM https://www.pouet.net/prod.php?which=29696
* Chessington World Of Adventure by HOOY-PROGRAM https://www.pouet.net/prod.php?which=76074
* Roll Me Gently by Joker https://www.pouet.net/prod.php?which=86338

=== Additional Resources ===
I found resources on ZX Spectrum sizecoding to be sparse.
* All kinds of Z80 Information http://www.z80.info/index.htm
* Another source for good Z80 Information http://z80-heaven.wikidot.com
* Assembler subforum on world of spectrum https://worldofspectrum.org/forums/categories/assembler
* Development subforum on Spectrum Computing https://spectrumcomputing.co.uk/forums/viewforum.php?f=6
* Blogpost on ZX Spectrum coding from a X86 coder's perspective on superogue's sizecdoing blog http://marquee.revival-studios.com/blog/blog_fluxus.html
* 128byte/256 byte zx spectrum productions by goblinish https://www.pouet.net/groups.php?which=11696&order=type
* 128byte/256 byte zx spectrum productions by gasman https://www.pouet.net/groups.php?which=1218&order=type
* Easy to read list of all Z80 instructions (including undocumented ones) with size and timing information https://clrhome.org/table/
* Detailed information on the screen layout http://www.overtakenbyevents.com/lets-talk-about-the-zx-specrum-screen-layout/ http://www.overtakenbyevents.com/lets-talk-about-the-zx-specrum-screen-layout-part-two/ and http://www.overtakenbyevents.com/lets-talk-about-the-zx-specrum-screen-layout-part-three/

== Amstrad CPC ==
The Amstrad consists of a Z80A @ 3.5 MHz CPU

=== Setting up ===
Setting up:

* Assembler: -
** The emulator [http://www.winape.net/ Winape] has an integrated [http://www.winape.net/help/assembler.html assembler]

* Emulator(s):
** [http://www.winape.net/ Winape] is very accurate and includes an assembler / debugger
** [https://www.cpc-power.com/cpcarchives/index.php?page=articles&num=445 Caprice] gets very regular updates
** [http://cngsoft.no-ip.org/cpcec.htm CPCEC] is very fast
** [https://sourceforge.net/projects/javacpc/ JavaCPC] offers many features
** [https://www.retrovirtualmachine.org/ Retro Virtual Machine] is visually very impressiv

=== Video Display ===
No information yet

=== Sound ===
No information yet

=== Additional Resources ===
* 64 NOPs Amstrad CPC Tech Blog - https://64nops.wordpress.com/

Christmas Tree

2021-12-28T07:47:27Z

Logiker:

[[Category:Case Study]]
==The challenge==
During the [https://demozoo.org/parties/4398/ Vintage Computing Christmas Challenge 2021] the goal was to create the shape of a given Christmas tree with as few bytes as possible. All platforms and languages were allowed.
The tree should be centered and look exactly like shown bellow.
<code>
*
***
*****
*******
***
*******
***********
***************
*****
***********
*****************
***********************
***
***
</code>
There were mainly two kinds of approaches:
* calculate stars using a formula
* save amount of stars within data
Do to the trunk of the tree, the second type was more efficient.
==Winning Entries==
=== Shortest DOS version ===
The shortest DOS version with 44 bytes came from Hellmood:
<syntaxhighlight lang=nasm>
org 100h ; define start of code for data access
db 80 ; screen width, located at [SI], also "push ax"
mov bx,d ; pointer to data for XLAT
mov cx,1120 ; 14 lines with 80 chars each
X: mov ax,cx ; get current sequence position
div byte [si] ; transform to [X,Y] in AL, AH
xlat ; get tree width for current line number
sub ah,40 ; center tree in the middle
jnc F ; -
neg ah ; -
F: sub ah,al ; inside or outside tree?
salc ; set AL depending on carry flag
imul ax,byte -42 ; transform into STAR or nothing
int 29h ; write current char to screen
loop X ; repeat unil all chars are plotter
ret ; return to prompt (JMP to former AX=0x0000)
d:db 2,2,12,9,6,3,8,6,4,2,4,3,2,1
</syntaxhighlight>
=== Winning entry for C64 ===
The shortest entry overall was for the C64 and was submitted by Serato with only 37 bytes:
<syntaxhighlight lang="6502">
!cpu 6510 ; enable unintended opcodes in ACME assembler

chrout = $FFD2
crlf = $AAD7
pntr = $D3
width = 40

;; BASIC header
*= $0801
!word +, 10
!byte $9e
!text "2092"
!byte 0
+ !word 0
table
!byte -1
!byte -3
!byte -5
!byte -7
!byte -3
!byte -7
!byte -11
!byte -15
!byte -5
!byte -11
!byte -17
!byte -23
!byte -3
!byte -3
code
-- lsr
sbc #(128-width/2)
sta pntr
lda #'*'
- jsr chrout
inx
bne -
jsr crlf
iny
entry
lax table,y
bmi --
rts
end
</syntaxhighlight>
Serato's entry was provided with the following comments:
<nowiki>This entry to the Christmas Tree challenge saves space in six ways:

1. Using the c64 kernal routines to output individual characters and carriage return/linefeed. These routines save/restore X/Y allowing the registers to be used as loop counters.

2. Writing to the PNTR kernal variable to indent each row.

3. Using the unintended LAX opcode to simultaneously load A and X with the table values.

4. Storing the row widths as 2's complement negative values, to simplify the indent calculation to divide by two (LSR) and subtract (SBC). The inner loop simply counts back up to zero for rendering the correct width.

5. BASIC loads the Y register from address $30d. This defaults to 0 on startup, so Y does not need to be initialised.

6. Placing the table before the code in memory, the MSB of the table entries do not match the MSB of the first opcode (LSR), allowing the outer loop exit condition to be set implicitly in the Negative flag as the table values are read.

These optimisations result in 37 bytes of machine code and data. Two further optimisations are possible each of which save 1 byte, but break the rules of this challenge:

a - LSR and SBC can be replaced with the unintended opcode ARR, if you are willing to "centre" the tree on a virtual screen width of 32 chars.

b - The BASIC interpreter leaves the line number in the zero page word at $39, so by setting the line number in the basic header to the address of the table, "LAX ($39),y" can be used for the table access.</nowiki>

==Optimized post-deadline versions==
===36 bytes version for C64===
The C64 version was shortened by altering the calculation so the default register values on start cause the first line to be drawn, shortening the table by one entry.
<syntaxhighlight lang="6502">
!cpu 6510 ; enable unintended opcodes in ACME assembler

chrout = $FFD2
crlf = $AAD7
pntr = $D3
width = 40

;; BASIC header
*= $0801
!word +, 10
!byte $9e
!text "2074"
!byte 0
+ !word 0
table
; !byte -1
!byte -3
!byte -5
!byte -7
!byte -3
!byte -7
!byte -11
!byte -15
!byte -5
!byte -11
!byte -17
!byte -23
!byte -3
!byte -3
code
-- adc #width-1
lsr
sta pntr
lda #'*'
- jsr chrout
inx
bmi -
jsr crlf
iny
lax table-1,y
bmi --
rts
end
</syntaxhighlight>

===32 bytes version for ZX Spectrum===
After the deadline following entry for the ZX Spectrum with only 35 bytes was submitted by reddie and optimized by char to 32 bytes:
<syntaxhighlight lang="z80">
# Christmas Tree post-event build, ZX Spectrum version
# tnx to Manwe for info about event, better late than never =)
# first version - 35 bytes - (c) reddie, 2021.12.25
# optimized to 32 bytes by char, 2021.12.26 - huge thanks from me!
# full final object len = 32 bytes (from label "data" to label "end")
# data array len = 14 bytes; code len = 18 bytes, 13 Z80 instructions
# execute from Basic only! entry point = 61455, or just run TRD image
# and then run "ctree32b" Basic-program, it will load & start the code
# TRD file also contains source text in ALASM format

data org -16*256+1
defb -5,-5,-25,-19,-13,-7,-17,-13,-9,-5,-9,-7,-5,-3

start dec c
jr z,$ ;stop when finished
ld a,23 ;set coords via ROM procedure
rst 16
ld a,(bc) ;line len in negative format
ld e,a
rra
sub b ;centering
print rst 16
ld a,"*"
inc e
jr nz,print
jr start
end
</syntaxhighlight>

Christmas Tree

2021-12-27T07:39:12Z

Logiker: /* 32 bytes version for ZX Spectrum */

[[Category:Case Study]]
During the [https://demozoo.org/parties/4398/ Vintage Computing Christmas Challenge 2021] the goal was to create the shape of a given Christmas tree with as few bytes as possible. All platforms and languages were allowed.
The tree should be centered and look exactly like shown bellow.
<code>
*
***
*****
*******
***
*******
***********
***************
*****
***********
*****************
***********************
***
***
</code>
There were mainly two kinds of approaches:
* calculate stars using a formula
* save amount of stars within data
Do to the trunk of the tree, the second type was more efficient.
=== Shortest DOS version ===
The shortest DOS version with 44 bytes came from Hellmood:
<syntaxhighlight lang=nasm>
org 100h ; define start of code for data access
db 80 ; screen width, located at [SI], also "push ax"
mov bx,d ; pointer to data for XLAT
mov cx,1120 ; 14 lines with 80 chars each
X: mov ax,cx ; get current sequence position
div byte [si] ; transform to [X,Y] in AL, AH
xlat ; get tree width for current line number
sub ah,40 ; center tree in the middle
jnc F ; -
neg ah ; -
F: sub ah,al ; inside or outside tree?
salc ; set AL depending on carry flag
imul ax,byte -42 ; transform into STAR or nothing
int 29h ; write current char to screen
loop X ; repeat unil all chars are plotter
ret ; return to prompt (JMP to former AX=0x0000)
d:db 2,2,12,9,6,3,8,6,4,2,4,3,2,1
</syntaxhighlight>
=== Winning entry for C64 ===
The shortest entry overall was for the C64 and was submitted by Serato with only 37 bytes:
<syntaxhighlight lang="6502">
!cpu 6510 ; enable unintended opcodes in ACME assembler

chrout = $FFD2
crlf = $AAD7
pntr = $D3
width = 40

;; BASIC header
*= $0801
!word +, 10
!byte $9e
!text "2092"
!byte 0
+ !word 0
table
!byte -1
!byte -3
!byte -5
!byte -7
!byte -3
!byte -7
!byte -11
!byte -15
!byte -5
!byte -11
!byte -17
!byte -23
!byte -3
!byte -3
code
-- lsr
sbc #(128-width/2)
sta pntr
lda #'*'
- jsr chrout
inx
bne -
jsr crlf
iny
entry
lax table,y
bmi --
rts
end
</syntaxhighlight>
Serato's entry was provided with the following comments:
<nowiki>This entry to the Christmas Tree challenge saves space in six ways:

1. Using the c64 kernal routines to output individual characters and carriage return/linefeed. These routines save/restore X/Y allowing the registers to be used as loop counters.

2. Writing to the PNTR kernal variable to indent each row.

3. Using the unintended LAX opcode to simultaneously load A and X with the table values.

4. Storing the row widths as 2's complement negative values, to simplify the indent calculation to divide by two (LSR) and subtract (SBC). The inner loop simply counts back up to zero for rendering the correct width.

5. BASIC loads the Y register from address $30d. This defaults to 0 on startup, so Y does not need to be initialised.

6. Placing the table before the code in memory, the MSB of the table entries do not match the MSB of the first opcode (LSR), allowing the outer loop exit condition to be set implicitly in the Negative flag as the table values are read.

These optimisations result in 37 bytes of machine code and data. Two further optimisations are possible each of which save 1 byte, but break the rules of this challenge:

a - LSR and SBC can be replaced with the unintended opcode ARR, if you are willing to "centre" the tree on a virtual screen width of 32 chars.

b - The BASIC interpreter leaves the line number in the zero page word at $39, so by setting the line number in the basic header to the address of the table, "LAX ($39),y" can be used for the table access.</nowiki>

===32 bytes version for ZX Spectrum===
After the deadline following entry for the ZX Spectrum with only 35 bytes was submitted by reddie and optimized by char to 32 bytes:
<syntaxhighlight lang="z80">
# Christmas Tree post-event build, ZX Spectrum version
# tnx to Manwe for info about event, better late than never =)
# first version - 35 bytes - (c) reddie, 2021.12.25
# optimized to 32 bytes by char, 2021.12.26 - huge thanks from me!
# full final object len = 32 bytes (from label "data" to label "end")
# data array len = 14 bytes; code len = 18 bytes, 13 Z80 instructions
# execute from Basic only! entry point = 61455, or just run TRD image
# and then run "ctree32b" Basic-program, it will load & start the code
# TRD file also contains source text in ALASM format

data org -16*256+1
defb -5,-5,-25,-19,-13,-7,-17,-13,-9,-5,-9,-7,-5,-3

start dec c
jr z,$ ;stop when finished
ld a,23 ;set coords via ROM procedure
rst 16
ld a,(bc) ;line len in negative format
ld e,a
rra
sub b ;centering
print rst 16
ld a,"*"
inc e
jr nz,print
jr start
end
</syntaxhighlight>

Christmas Tree

2021-12-27T07:37:10Z

Logiker: /* 35 bytes version for ZX Spectrum */

[[Category:Case Study]]
During the [https://demozoo.org/parties/4398/ Vintage Computing Christmas Challenge 2021] the goal was to create the shape of a given Christmas tree with as few bytes as possible. All platforms and languages were allowed.
The tree should be centered and look exactly like shown bellow.
<code>
*
***
*****
*******
***
*******
***********
***************
*****
***********
*****************
***********************
***
***
</code>
There were mainly two kinds of approaches:
* calculate stars using a formula
* save amount of stars within data
Do to the trunk of the tree, the second type was more efficient.
=== Shortest DOS version ===
The shortest DOS version with 44 bytes came from Hellmood:
<syntaxhighlight lang=nasm>
org 100h ; define start of code for data access
db 80 ; screen width, located at [SI], also "push ax"
mov bx,d ; pointer to data for XLAT
mov cx,1120 ; 14 lines with 80 chars each
X: mov ax,cx ; get current sequence position
div byte [si] ; transform to [X,Y] in AL, AH
xlat ; get tree width for current line number
sub ah,40 ; center tree in the middle
jnc F ; -
neg ah ; -
F: sub ah,al ; inside or outside tree?
salc ; set AL depending on carry flag
imul ax,byte -42 ; transform into STAR or nothing
int 29h ; write current char to screen
loop X ; repeat unil all chars are plotter
ret ; return to prompt (JMP to former AX=0x0000)
d:db 2,2,12,9,6,3,8,6,4,2,4,3,2,1
</syntaxhighlight>
=== Winning entry for C64 ===
The shortest entry overall was for the C64 and was submitted by Serato with only 37 bytes:
<syntaxhighlight lang="6502">
!cpu 6510 ; enable unintended opcodes in ACME assembler

chrout = $FFD2
crlf = $AAD7
pntr = $D3
width = 40

;; BASIC header
*= $0801
!word +, 10
!byte $9e
!text "2092"
!byte 0
+ !word 0
table
!byte -1
!byte -3
!byte -5
!byte -7
!byte -3
!byte -7
!byte -11
!byte -15
!byte -5
!byte -11
!byte -17
!byte -23
!byte -3
!byte -3
code
-- lsr
sbc #(128-width/2)
sta pntr
lda #'*'
- jsr chrout
inx
bne -
jsr crlf
iny
entry
lax table,y
bmi --
rts
end
</syntaxhighlight>
Serato's entry was provided with the following comments:
<nowiki>This entry to the Christmas Tree challenge saves space in six ways:

1. Using the c64 kernal routines to output individual characters and carriage return/linefeed. These routines save/restore X/Y allowing the registers to be used as loop counters.

2. Writing to the PNTR kernal variable to indent each row.

3. Using the unintended LAX opcode to simultaneously load A and X with the table values.

4. Storing the row widths as 2's complement negative values, to simplify the indent calculation to divide by two (LSR) and subtract (SBC). The inner loop simply counts back up to zero for rendering the correct width.

5. BASIC loads the Y register from address $30d. This defaults to 0 on startup, so Y does not need to be initialised.

6. Placing the table before the code in memory, the MSB of the table entries do not match the MSB of the first opcode (LSR), allowing the outer loop exit condition to be set implicitly in the Negative flag as the table values are read.

These optimisations result in 37 bytes of machine code and data. Two further optimisations are possible each of which save 1 byte, but break the rules of this challenge:

a - LSR and SBC can be replaced with the unintended opcode ARR, if you are willing to "centre" the tree on a virtual screen width of 32 chars.

b - The BASIC interpreter leaves the line number in the zero page word at $39, so by setting the line number in the basic header to the address of the table, "LAX ($39),y" can be used for the table access.</nowiki>

===32 bytes version for ZX Spectrum===
After the deadline following entry for the ZX Spectrum with only 35 bytes was submitted by reddie and improved by char:
<syntaxhighlight lang="z80">
# Christmas Tree post-event build, ZX Spectrum version
# tnx to Manwe for info about event, better late than never =)
# first version - 35 bytes - (c) reddie, 2021.12.25
# optimized to 32 bytes by char, 2021.12.26 - huge thanks from me!
# full final object len = 32 bytes (from label "data" to label "end")
# data array len = 14 bytes; code len = 18 bytes, 13 Z80 instructions
# execute from Basic only! entry point = 61455, or just run TRD image
# and then run "ctree32b" Basic-program, it will load & start the code
# TRD file also contains source text in ALASM format

data org -16*256+1
defb -5,-5,-25,-19,-13,-7,-17,-13,-9,-5,-9,-7,-5,-3

start dec c
jr z,$ ;stop when finished
ld a,23 ;set coords via ROM procedure
rst 16
ld a,(bc) ;line len in negative format
ld e,a
rra
sub b ;centering
print rst 16
ld a,"*"
inc e
jr nz,print
jr start
end
</syntaxhighlight>

Christmas Tree

2021-12-26T21:03:02Z

Logiker: /* 35 bytes version for ZX Spectrum */

[[Category:Case Study]]
During the [https://demozoo.org/parties/4398/ Vintage Computing Christmas Challenge 2021] the goal was to create the shape of a given Christmas tree with as few bytes as possible. All platforms and languages were allowed.
The tree should be centered and look exactly like shown bellow.
<code>
*
***
*****
*******
***
*******
***********
***************
*****
***********
*****************
***********************
***
***
</code>
There were mainly two kinds of approaches:
* calculate stars using a formula
* save amount of stars within data
Do to the trunk of the tree, the second type was more efficient.
=== Shortest DOS version ===
The shortest DOS version with 44 bytes came from Hellmood:
<syntaxhighlight lang=nasm>
org 100h ; define start of code for data access
db 80 ; screen width, located at [SI], also "push ax"
mov bx,d ; pointer to data for XLAT
mov cx,1120 ; 14 lines with 80 chars each
X: mov ax,cx ; get current sequence position
div byte [si] ; transform to [X,Y] in AL, AH
xlat ; get tree width for current line number
sub ah,40 ; center tree in the middle
jnc F ; -
neg ah ; -
F: sub ah,al ; inside or outside tree?
salc ; set AL depending on carry flag
imul ax,byte -42 ; transform into STAR or nothing
int 29h ; write current char to screen
loop X ; repeat unil all chars are plotter
ret ; return to prompt (JMP to former AX=0x0000)
d:db 2,2,12,9,6,3,8,6,4,2,4,3,2,1
</syntaxhighlight>
=== Winning entry for C64 ===
The shortest entry overall was for the C64 and was submitted by Serato with only 37 bytes:
<syntaxhighlight lang="6502">
!cpu 6510 ; enable unintended opcodes in ACME assembler

chrout = $FFD2
crlf = $AAD7
pntr = $D3
width = 40

;; BASIC header
*= $0801
!word +, 10
!byte $9e
!text "2092"
!byte 0
+ !word 0
table
!byte -1
!byte -3
!byte -5
!byte -7
!byte -3
!byte -7
!byte -11
!byte -15
!byte -5
!byte -11
!byte -17
!byte -23
!byte -3
!byte -3
code
-- lsr
sbc #(128-width/2)
sta pntr
lda #'*'
- jsr chrout
inx
bne -
jsr crlf
iny
entry
lax table,y
bmi --
rts
end
</syntaxhighlight>
Serato's entry was provided with the following comments:
<nowiki>This entry to the Christmas Tree challenge saves space in six ways:

1. Using the c64 kernal routines to output individual characters and carriage return/linefeed. These routines save/restore X/Y allowing the registers to be used as loop counters.

2. Writing to the PNTR kernal variable to indent each row.

3. Using the unintended LAX opcode to simultaneously load A and X with the table values.

4. Storing the row widths as 2's complement negative values, to simplify the indent calculation to divide by two (LSR) and subtract (SBC). The inner loop simply counts back up to zero for rendering the correct width.

5. BASIC loads the Y register from address $30d. This defaults to 0 on startup, so Y does not need to be initialised.

6. Placing the table before the code in memory, the MSB of the table entries do not match the MSB of the first opcode (LSR), allowing the outer loop exit condition to be set implicitly in the Negative flag as the table values are read.

These optimisations result in 37 bytes of machine code and data. Two further optimisations are possible each of which save 1 byte, but break the rules of this challenge:

a - LSR and SBC can be replaced with the unintended opcode ARR, if you are willing to "centre" the tree on a virtual screen width of 32 chars.

b - The BASIC interpreter leaves the line number in the zero page word at $39, so by setting the line number in the basic header to the address of the table, "LAX ($39),y" can be used for the table access.</nowiki>

===35 bytes version for ZX Spectrum===
After the deadline following entry for the ZX Spectrum with only 35 bytes was submitted by reddie:
<syntaxhighlight lang="z80">
# Christmas Tree post-event build (c) reddie, 2021.12.25, ZX Spectrum version
# tnx to Manwe for info about event, better late than never =)
# full object len = 35 bytes (end-data)
# data array len = 14 bytes; code len = 21 bytes, 15 Z80 instructions
# execute from Basic only! entry point = 61455, or just run TRD image
# TRD file also contains source text in ALASM format

data org -16*256+1
defb -3,-3,-23,-17,-11,-5,-15,-11,-7,-3,-7,-5,-3,-1

start dec c
jr z,$ ;stop when finished
ld a,23 ;set coords via ROM procedure
rst 16
ld a,(bc) ;line len in negative format
ld e,a
sra a
sub b ;centering
rst 16
rst 16
print ld a,"*"
rst 16
inc e
jr nz,print
jr start
end
</syntaxhighlight>

Christmas Tree

2021-12-26T21:00:21Z

Logiker: Added ZX Spectrum version

[[Category:Case Study]]
During the [https://demozoo.org/parties/4398/ Vintage Computing Christmas Challenge 2021] the goal was to create the shape of a given Christmas tree with as few bytes as possible. All platforms and languages were allowed.
The tree should be centered and look exactly like shown bellow.
<code>
*
***
*****
*******
***
*******
***********
***************
*****
***********
*****************
***********************
***
***
</code>
There were mainly two kinds of approaches:
* calculate stars using a formula
* save amount of stars within data
Do to the trunk of the tree, the second type was more efficient.
=== Shortest DOS version ===
The shortest DOS version with 44 bytes came from Hellmood:
<syntaxhighlight lang=nasm>
org 100h ; define start of code for data access
db 80 ; screen width, located at [SI], also "push ax"
mov bx,d ; pointer to data for XLAT
mov cx,1120 ; 14 lines with 80 chars each
X: mov ax,cx ; get current sequence position
div byte [si] ; transform to [X,Y] in AL, AH
xlat ; get tree width for current line number
sub ah,40 ; center tree in the middle
jnc F ; -
neg ah ; -
F: sub ah,al ; inside or outside tree?
salc ; set AL depending on carry flag
imul ax,byte -42 ; transform into STAR or nothing
int 29h ; write current char to screen
loop X ; repeat unil all chars are plotter
ret ; return to prompt (JMP to former AX=0x0000)
d:db 2,2,12,9,6,3,8,6,4,2,4,3,2,1
</syntaxhighlight>
=== Winning entry for C64 ===
The shortest entry overall was for the C64 and was submitted by Serato with only 37 bytes:
<syntaxhighlight lang="6502">
!cpu 6510 ; enable unintended opcodes in ACME assembler

chrout = $FFD2
crlf = $AAD7
pntr = $D3
width = 40

;; BASIC header
*= $0801
!word +, 10
!byte $9e
!text "2092"
!byte 0
+ !word 0
table
!byte -1
!byte -3
!byte -5
!byte -7
!byte -3
!byte -7
!byte -11
!byte -15
!byte -5
!byte -11
!byte -17
!byte -23
!byte -3
!byte -3
code
-- lsr
sbc #(128-width/2)
sta pntr
lda #'*'
- jsr chrout
inx
bne -
jsr crlf
iny
entry
lax table,y
bmi --
rts
end
</syntaxhighlight>
Serato's entry was provided with the following comments:
<nowiki>This entry to the Christmas Tree challenge saves space in six ways:

1. Using the c64 kernal routines to output individual characters and carriage return/linefeed. These routines save/restore X/Y allowing the registers to be used as loop counters.

2. Writing to the PNTR kernal variable to indent each row.

3. Using the unintended LAX opcode to simultaneously load A and X with the table values.

4. Storing the row widths as 2's complement negative values, to simplify the indent calculation to divide by two (LSR) and subtract (SBC). The inner loop simply counts back up to zero for rendering the correct width.

5. BASIC loads the Y register from address $30d. This defaults to 0 on startup, so Y does not need to be initialised.

6. Placing the table before the code in memory, the MSB of the table entries do not match the MSB of the first opcode (LSR), allowing the outer loop exit condition to be set implicitly in the Negative flag as the table values are read.

These optimisations result in 37 bytes of machine code and data. Two further optimisations are possible each of which save 1 byte, but break the rules of this challenge:

a - LSR and SBC can be replaced with the unintended opcode ARR, if you are willing to "centre" the tree on a virtual screen width of 32 chars.

b - The BASIC interpreter leaves the line number in the zero page word at $39, so by setting the line number in the basic header to the address of the table, "LAX ($39),y" can be used for the table access.</nowiki>

===35 bytes version for ZX Spectrum===
After the deadline following entry for the ZX Spectrum with only 35 bytes was submitted by reddie:
<syntaxhighlight lang="z80">
; Christmas Tree post-event build (c) reddie, 2021.12.25, ZX Spectrum version
; tnx to Manwe for info about event, better late than never =)
; full object len = 35 bytes (end-data)
; data array len = 14 bytes; code len = 21 bytes, 15 Z80 instructions
; execute from Basic only! entry point = 61455, or just run TRD image
; TRD file also contains source text in ALASM format

data org -16*256+1
defb -3,-3,-23,-17,-11,-5,-15,-11,-7,-3,-7,-5,-3,-1

start dec c
jr z,$ ;stop when finished
ld a,23 ;set coords via ROM procedure
rst 16
ld a,(bc) ;line len in negative format
ld e,a
sra a
sub b ;centering
rst 16
rst 16
print ld a,"*"
rst 16
inc e
jr nz,print
jr start
end
</syntaxhighlight>

Christmas Tree

2021-12-25T18:42:02Z

Logiker: Initial version of Christmas Tree case study

[[Category:Case Study]]
During the [https://demozoo.org/parties/4398/ Vintage Computing Christmas Challenge 2021] the goad was to create the shape of a given Christmas tree with as few bytes as possible. All platforms and languages were allowed.
The tree should be centered and look exactly like shown bellow.
<code>
*
***
*****
*******
***
*******
***********
***************
*****
***********
*****************
***********************
***
***
</code>
There were mainly two kinds of approaches:
* calculate stars using a formula
* save amount of stars within data
Do to the trunk of the tree, the second type was more efficient.
=== Shortest DOS version ===
The shortest DOS version with 44 bytes came from Hellmood:
<syntaxhighlight lang=nasm>
org 100h ; define start of code for data access
db 80 ; screen width, located at [SI], also "push ax"
mov bx,d ; pointer to data for XLAT
mov cx,1120 ; 14 lines with 80 chars each
X: mov ax,cx ; get current sequence position
div byte [si] ; transform to [X,Y] in AL, AH
xlat ; get tree width for current line number
sub ah,40 ; center tree in the middle
jnc F ; -
neg ah ; -
F: sub ah,al ; inside or outside tree?
salc ; set AL depending on carry flag
imul ax,byte -42 ; transform into STAR or nothing
int 29h ; write current char to screen
loop X ; repeat unil all chars are plotter
ret ; return to prompt (JMP to former AX=0x0000)
d:db 2,2,12,9,6,3,8,6,4,2,4,3,2,1
</syntaxhighlight>
=== Winning entry for C64 ===
The shortest entry overall was for the C64 and was submitted by Serato with only 37 bytes:
<syntaxhighlight lang="6502">
!cpu 6510 ; enable unintended opcodes in ACME assembler

chrout = $FFD2
crlf = $AAD7
pntr = $D3
width = 40

*=$304-39
table
!byte width-1
!byte width-3
!byte width-5
!byte width-7
!byte width-3
!byte width-7
!byte width-11
!byte width-15
!byte width-5
!byte width-11
!byte width-17
!byte width-23
!byte width-3
!byte width-3
entry
lax table-1,y
bmi *
lsr
sta pntr
lda #'*'
- jsr chrout
inx
cpx #width
bne -
jsr crlf
iny
jmp entry
end
</syntaxhighlight>

Case Studies

2021-12-25T18:39:11Z

Logiker: Added Christmas Tree case study link

Sometimes it can be helpful to examine a tinyprog in detail, seeing what choices were made and why:

:[[MELT.COM]]: We take a cute program from the 1980s and see how far we can crunch it down

:[[m8trix 8b]]: An "Enter The Matrix" screen display in only 8 bytes

:[[4is256]]: Řrřola's Tetris is a full tetris clone with scoring

:[[paint16b]]: Hellmood's paint program in 16 bytes (really)

:[[Indian Spirit]]: An American Indian tapestry with music in 32 bytes

:[[Essence]]: Fakery of path tracing and lighting, with audio, in 64 bytes

:[[Memories]]: Detailed writeup on [https://www.pouet.net/prod.php?which=85227 "Memories" (256 bytes)]

:[[Game of Life 32b]]; Writeup for game of life in 32 bytes

:[[Christmas Tree]]: Implementation of a Christmas Tree on several platforms

== External Case Studies ==

[https://en.wikipedia.org/wiki/Brainfuck Brainfuck] is a very tiny language, having only 8 commands and an instruction pointer. Several compilers and interpreters have been made; Gynvael archived [http://gynvael.coldwind.pl/bf125/ many different versions along with their source code], the smallest of which was 125 bytes. qkumba took that as inspiration and created his own [http://pferrie.epizy.com/misc/tiny/brainfck.htm brainfuck compiler in 100 bytes] (104 for one that is fully compliant). (Note: The term "compiler" is used mistakenly a lot in these descriptions; the majority of brainfuck programs are actually interpreters that load brainfuck programs and execute native code token by token. This one is an exception in that it really does compile the code entirely into native instructions first.)

[https://revival-studios.com/marquee/blog/blog_homogenic.html Small Beginnings: The development of Homogenic] Development Write up on [https://www.pouet.net/prod.php?which=84537 Homogenic, by: Marquee Design (256 bytes)]

[https://revival-studios.com/marquee/blog/blog_nanorail.html Moving on: The development of Nanorail] Development Write up on [https://www.pouet.net/prod.php?which=84624 Nanorail, by: Marquee Design (256 bytes)]

[https://revival-studios.com/marquee/blog/blog_enigma.html Full Circle: The development of Enigma] Development Write up on [https://www.pouet.net/prod.php?which=85232 Enigma, by: Marquee Design (256 bytes)]

[https://revival-studios.com/marquee/blog/blog_microdose.html Crunching content: The development of Microdose] Development Write up on [https://www.pouet.net/prod.php?which=85677 Microdose, by: Marquee Design (128 bytes)]

[https://abaddon.hu/crevenge/history.html The long journey to 1k real-time ray-tracing] Detailed technical writeup on [https://www.pouet.net/prod.php?which=87078 Chrome Revenge by Abaddon (1024 bytes)]

[http://canonical.org/~kragen/demo/fr-016.html Disassembly of Farbrausch's "fr-016: bytes"]

[http://canonical.org/~kragen/demo/klappquadrat.html A disassembly of the 64-byte version of Klappquadrat]

[https://trixter.oldskool.org/2012/12/17/maze-generation-in-thirteen-bytes/ Maze generation in 10 bytes]