tiny "red" challenge (msdos)
category: code [glöplog]
Atari ST, bootsector:
8 bytes. That rts might not even be necessary (depending if clean exit is required), so:
6 bytes.
Atari Jaguar
0 bytes. Just power the machine on without a cart and the border will turn red. But this also shows the boot logo. So if one plugs a cart where the CRC fails (a completely empty cart should do the trick) there should only be a red border.
Code:
move.w #$f00,$ffff8240.w
rts
8 bytes. That rts might not even be necessary (depending if clean exit is required), so:
Code:
move.w #$f00,$ffff8240.w
6 bytes.
Atari Jaguar
0 bytes. Just power the machine on without a cart and the border will turn red. But this also shows the boot logo. So if one plugs a cart where the CRC fails (a completely empty cart should do the trick) there should only be a red border.
C64: 8 bytes (2 bytes load address + 6 bytes actual data)
Hex: 73 00 99 1F D0 8C 11 D0
Load as usual (,8,1), then start with RUN or just press Enter.
Code:
* = $73 ; overwrite the start of the CHRGET routine, called to parse BASIC code e.g. when Enter is pressed
; (the only piece of code that resides in RAM)
; first call: A=$F2, X=$FF, Y=$01
; further calls: A=$FF resp. $20, X=$00, Y=$05
STA $D01F, Y ; first call: write $F2 to $D020 (border color register) - makes the border red
; further calls: write whatever to $D024 (background color register 3) - does nothing
STY $D011 ; write $01 resp. $00 to $D011 (control register) - blanks the screen, border color everywhere
Hex: 73 00 99 1F D0 8C 11 D0
Load as usual (,8,1), then start with RUN or just press Enter.
Quote:
Atari Jaguar
0 bytes. Just power the machine on without a cart and the border will turn red. But this also shows the boot logo. So if one plugs a cart where the CRC fails (a completely empty cart should do the trick) there should only be a red border.
Amazing!
Amiga: 0 bytes, just boot with a broken Kickstart ROM
Does erasing things from the kickstart ROM count as negative prod size?
Updated 7-byte C64 version:
Hex: 75 00 AA 9D EE CF 6F
Downside: this is not guaranteed to work. Just like the previous example this turns off the screen and makes it completely red but as a side effect it also turns off ROM. It's at least in theory possible that "code" in uninitialized RAM re-enables ROM and then jumps to the restore vector via BRK which restores the screen to the blue power-on color scheme. (The default initial RAM pattern of VICE actually manages to re-enable ROM but it then resumes executing the BASIC interpreter, invisibly printing a SYNTAX ERROR).
Code:
* = $75 ; overwrite parts of the CHRGET routine
TAX ; use previous value of A...
STA $CFEE, X ; ...as both index and data
.byte $6F ; unofficial RRA opcode
Hex: 75 00 AA 9D EE CF 6F
Downside: this is not guaranteed to work. Just like the previous example this turns off the screen and makes it completely red but as a side effect it also turns off ROM. It's at least in theory possible that "code" in uninitialized RAM re-enables ROM and then jumps to the restore vector via BRK which restores the screen to the blue power-on color scheme. (The default initial RAM pattern of VICE actually manages to re-enable ROM but it then resumes executing the BASIC interpreter, invisibly printing a SYNTAX ERROR).
i love all these versions, keep them coming :)
and i kind of saw it coming that some platform
will just have a red starting screen by default
(ok, not really, but kinda)
@tomcat: i'm indeed a bit interested in codegolfing
but not to the extent you seem to assume
i see myself as constantly enlarging the arsenal of
sizecoding tricks to achieve some kind of "trickle up"
effect. no matter how weird the showcases for a
certain trick are, in the end, the more you have,
the higher the chances are that you can use more
of them in let's say a 256b intro. The "Splitjump"
is admittedly a very tight constraint, but who knows
if it might come in handy in a larger prod eventually =)
and i kind of saw it coming that some platform
will just have a red starting screen by default
(ok, not really, but kinda)
@tomcat: i'm indeed a bit interested in codegolfing
but not to the extent you seem to assume
i see myself as constantly enlarging the arsenal of
sizecoding tricks to achieve some kind of "trickle up"
effect. no matter how weird the showcases for a
certain trick are, in the end, the more you have,
the higher the chances are that you can use more
of them in let's say a 256b intro. The "Splitjump"
is admittedly a very tight constraint, but who knows
if it might come in handy in a larger prod eventually =)
you may learn tricks from the post mortem challenges... usually *yuko* has very-very tiny code solutions...
for 4 byte versions, maybe just bute force try all possible "values" and see if any of them results in a red screen.
Quote:
you may learn tricks from the post mortem challenges... usually *yuko* has very-very tiny code solutions...
I've seen that, too. Albeit these are solutions to predefined tasks - unlike our sizecoding stuff - they still need to use similar tricks.
In a few months we might have a big collection of tricks, which might attract more coders.
Just think about Rrrola's multi bit testing in his 256b Tetris, or HellMood's new screen fading. These could become building blocks.
Speaking about sizecoding: Should we create a metagroup, called "SiCo-4s"? ;)