Closed 8bitkick closed 3 years ago
It seems quite a jump to raise the limit from 382 bytes to 600K (that's 1608 times as large!) and I wonder if it's just too big a change in the rules of the game. It's a whole different scale compared to going from 280 to 382 (or to enabling the tokeniser code which allowed omitting line numbers and fully-tokenised programs). Perhaps it's just me that finds the size constraint much more interesting than the time constraint though.
It's a fair point keeping it true to the code golf. Perhaps we need a way to limit it to a tweet (or 256 bytes) of 6502 machine code rather than a whole floppy. Possible in base2048 but better in an image as we can have full annotated source asm on it too?
I agree, I think 256 or 280 bytes would be perfect.
You can actually smuggle more in as a BASIC program with:
<token for CALL><token for rvalue PAGE>+9:<machine code>
<more machine code>
You need to work around a 4 byte gap between the two blocks of machine code (though typically you can just arrange to have the gap before a subroutine), and also avoid byte value 13 (and I think 10 if inside base2048), but for a non-base2048 tweet that allows up to 274 bytes of machine code, and for a base2048 tweet up to 376 bytes.
With this you also get A, X, Y all set to zero and the carry flag cleared on entry (because BASIC variables A%, X%, Y% and C% will all be zero), which may save a few instructions.
But 256 seems a sensible size limit (and an apt number for an 8-bit computer).
That's a very cool code golf trick for sure - but in such a compact form the source code isn't viewable and its pretty hard for anyone to learn from or iterate on. This is why having the source embedded and an editor is something I'm really keen on
I totally agree. It would be amazing if clicking on the image in twitter took you to editable source.
That's a very cool code golf trick for sure - but in such a compact form the source code isn't viewable and its pretty hard for anyone to learn from or iterate on. This is why having the source embedded and an editor is something I'm really keen on
Sure - I was just looking at what size one can achieve already. If the new way is a lot more limiting people may not want to use it, while if it's a lot more generous it significantly changes the nature of the game.
I totally agree. It would be amazing if clicking on the image in twitter took you to editable source.
I'm not sure we can link from the image/video itself as clicking on that in the twitter UI already does something (fullscreen for an image, turning on sound for a video), but we could include a link. Could we do that anyway? Or is that likely to get flagged as spam?
Maybe I'm being paranoid about spam we could try in the test account...
I wonder if this idea has effectively been eclipsed now?
The bot now includes a link to view the source in owlet, which addresses that part nicely (more nicely than showing the source listing in an image, which would be hard to remix from.)
Also owlet now provides easy support for tokenising in addition to base2048 encoding, which makes it easier to cram a little extra in (and the automatic detection of base2048 allows a couple of extra bytes to fit in too).
Yeah we can park it for now. Might be interesting sometime.
Using stenographic techniques it's possible to encode a whole BBC Micro disk image in a 900x900 PNG (see background).
This PR gives the bot the ability to autoboot disk images posted to it as PNGs. A demo of it loading elite.ssd encoded in a PNG on JSbeeb and posting the results is shown here.
One major advantage over base2048 is we can display source in clear text (in the PNG), as well as encode up to 600KB of data. This should not impact any other behavior of the bot, but opens the possibility of binary demos and more being submitted by 'tweetdisk'.
For tooling, in parallel @mattgodbolt is taking a look at BeebIDE being able to output ssd images which can be PNG encoded for the bot to consume.
UPDATE 1: Here's a basic tool for encoding/decoding tweetdisks for the bot
UPDATE 2: Proposal is to limit encoded data to 256 bytes of executable, plus annotated source