Competitive mustard eating? This must be the opposite of clickbait, title-wise… But what is it the mustard eating competition? Sounds gross! (Or delicious, depending on your level of mustard appreciation.)
I was amused to see this slide appear from time to time at this year’s Evoke demoparty:
Since I missed last year’s party, I wasn’t sure if Evoke always had this slide in their rotation. Anyway, as I was chatting with a fellow infodesk veteran I was shocked to learn that there are visitors (and organizers!) that take this slide as a joke!
To the sceptic or uninformaed, I say this: The mustard compo is real! It did happen, at Breakpoint 2010! And yes, that is the original announcement slide, and the competition took place at 11. p.m. in the party tent, just as it says! :)
Some other orga veterans assume I was the only contestant. That is a lie as well! There was at least one more competitor, and he managed to scoup down two whole glasses of medium hot mustard before giving up. Also, he couldn’t, well, retain all of it in his stomach, and he very much did not enjoy the process of getting rid of it, as he told me the next day…
If I remember correctly, a little Breakpoint TV delegation even filmed the whole event, but sadly (“sadly”) these recordings seem to be lost.
Even though there haven’t been any new actual mustard eating competitions as far as I know, it still is a funny slide (kindly created and snuck into the rotation by cyraxx in 2010), and I hope to see it at many more parties to come. Maybe next year’s Revision!
The ZX0 unpack routine got shorter again, and there’s savings to be had in my latest 512 byte intro. Best of all: I didn’t do anything myself! :)
This is a follow-up to Optimizations in ZX0 compression.
unzx0_68000.S now 4 bytes shorter
In the last ZX0 post, I wrote about saving two bytes in the ZX0 decompression routine for 68000 processors. We were able to replace the copy-literals loop with a slightly shorter version:
assembler code binary output
------------------ -------------
- subq.l #1,d0 ; 5380
- .copy_lits: move.b (a0)+,(a1)+ ; 12d8
- dbf d0,.copy_lits ; 51c8 fffc
+ .copy_lits: move.b (a0)+,(a1)+ ; 12d8
+ subq.w #1,d0 ; 5340
+ bgt.b .copy_lits ; 6efa
platon42/Desire spotted another optimization, saving two more bytes:
- .do_copy_offs: move.l a1,a2 ; 2449 - add.l d2,a2 ; d5c2 - .copy_match: move.b (a2)+,(a1)+ ; 12da - dbf d0,.copy_match ; 51c8 fffc + .do_copy_offs: + .copy_match: move.b (a1,d2.l),(a1)+ ; 12f1 6800 + dbf d0,.copy_match ; 51c8 fffa
Awesome. Great news for tiny productions! :)
Brute-forcing your way to insanity
This is not about the ZX0 decompressor per se (i. e. a “hard win” that you will always get when using ZX0), but rather some specific byte-mangling to make the compressed data for Temba, seine Arme weit! even smaller.
As mentioned in the write-up, I resorted to brute-forcing certain byte values and execution orders during the last hours before the deadline. This is time-consuming and the results are not always obvious, but I managed to squeeze out some bytes I could use to improve that 512 byte intro (restore the mouse pointer, exit to AmigaDOS cleanly).
phoyd who I told about this stuff at Nordlicht suprisingly wasn’t bored to death (not completely at least), but instead undusted his 68000 coding skills after the party and found some more optimizations. I love how seemingly random these are!
Party release: baseline ----------------------- Executable header ............ 36 ZX0 unpacker ................. 88 ZX0 payload ................. 388 --> 512 bytes in total Optimization 1: target address ------------------------------ - move.l .opc(pc),a4 ; in the unpacker + move.l #$6664e,a4 - UNPACK_TARGET = $5e14e ; in the intro (source) - SINTAB = $58000 + UNPACK_TARGET = $6664e + SINTAB = $64000 Executable header ............ 36 ZX0 unpacker ................. 90 ZX0 payload ................. 384 --> 2 bytes saved despite larger unpacker code! Optimization 2: volume ---------------------- - move.l #$00400000,$dff0a8 ; set AUD0VOL+DAT, vol=64 ($40) + move.l #$00440000,$dff0a8 ; only bit 6 needed for max volume, + ; other bits freely assignable Executable header ............ 36 ZX0 unpacker ................. 90 ZX0 payload ................. 383 --> Another byte saved!
Together with platon’s decompressor enhancement, the intro now fits into 508 bytes! One of which is a padding byte, so there is room for five more compressed bytes.
The drawback: These hyperoptimizations are really brittle. I tried adding some color flashing during the pre-calc time, like this:
+ move.w @v,$dff180 ; 33c5 00df f180 (flash background)
But wherever I try to insert this, whichever register I use, the compressed size suddenly grows by 9 bytes or more, exceeding the 512-byte limit. I guess I would need to brute-force a way to use the extra space that we gained by brute-forcing…
The rotozoom craze continues!
The discussion’s getting heated here and there, and we seem to have exceeded the number of 4-pixel columns you can see on a physical monitor. Blueberry says the maximum number of actually visible lo-res pixels is 376 horizontally, not 384…
I wish the Commodore 1084 I bought off eBay would have lasted longer than two days so I could check this myself. But sadly, it died the line transformer death with a loud “zzzap” noise. As did the Philips CM8833 I bought one week later… Those monitors had nice little knobs where you could adjust the display width, height, and position as you pleased, including making the display area smaller than the screen.
“What’s the use of that?” you may ask. For one, you could maximize your screen real estate on later OS versions (having a Workbench, i. e. desktop of 680×268 instead of 640×256). Most importantly you could use a smaller display area on your monitor to spot lamers who changed the background color too early in their Copper lists! Due to the way the display hardware works on the Amiga, position zero will already be visible – counterintuitively – at the rightmost corner of the screen, making your beautiful Copper gradient look ugly. Lame! You can see this in WinUAE, too:
But I digress. :)
Here are some new zooming and rotating entries:
| Production | Who and when |
|---|---|
 |
Django the Bastard Atari has entered the chat! And with a plain ST, no less: no blitter, no Copper, no overscan – but 80 columns! |
 |
Dead Hackers Society One-upping the Atari (and Amiga) efforts with 100 columns. Atari STe required. |
 |
Desire Maxed out the displayable columns on Amiga, using HAM mode: 96×4 = 384 pixels. With source code! |
The “Darmok” reference in Temba, seine Arme weit!, that is. Well, combined with the additional German “Sinnlos im Weltraum” reference it sure was… cryptic.
As for the general recognition of the specific Star Trek: TNG episode, well, take a look at this recent TEDx talk by Scott Hanselman! :)
Anyway, it’s a great talk, go watch it!
