Category confusion confusion
category: code [glöplog]
The TI-8x line of calculators have memory managers built-in. I've got a nano entry for a demoparty, but the package that would be used in an emulator or sent to a real calculator is 470 bytes and the calculator itself reports total size of all the parts is 230 bytes. Which do I go with for determining category?
So what's in the 240 bytes? Executable header? Startup code?
It sounds to me like the 470-byte package is a container format including metadata as well as the actual executable file - basically, the equivalent of a disk/tape image on other 8-bit machines - and normally you wouldn't count all of that, so I'd go for the 230 bytes figure.
It slightly depends on what "total size of all the parts" means, though - if the calculator has a (notional) filesystem on it that reports a single 230-byte file, then that's definitely fine. If there are multiple files, then things get a bit more blurry and less standardised across platforms - for example, the Spectrum and C64 scenes are not really consistent about whether you include a BASIC launcher in the byte count. (For Revision's oldschool 4K rules, you do have to include it; for a >=512b compo, I'd probably leave it out and just count actual bytes of code... especially since in a competition like that you're going to be mainly up against DOS entries that don't have that problem.)
It slightly depends on what "total size of all the parts" means, though - if the calculator has a (notional) filesystem on it that reports a single 230-byte file, then that's definitely fine. If there are multiple files, then things get a bit more blurry and less standardised across platforms - for example, the Spectrum and C64 scenes are not really consistent about whether you include a BASIC launcher in the byte count. (For Revision's oldschool 4K rules, you do have to include it; for a >=512b compo, I'd probably leave it out and just count actual bytes of code... especially since in a competition like that you're going to be mainly up against DOS entries that don't have that problem.)
I made a tool to generate ti-8x executables: http://franck.charlet.pagesperso-orange.fr/bin28xp.7z
Generated files work on my ti-83.fr (which really is a t84 second edition) and on TilEm, your mileage may vary.
The header is 74 bytes + a 2 bytes checksum at the end of the file (and you need to add a "db $BB,$6D" at the start of your code (i don't remember why).
Generated files work on my ti-83.fr (which really is a t84 second edition) and on TilEm, your mileage may vary.
The header is 74 bytes + a 2 bytes checksum at the end of the file (and you need to add a "db $BB,$6D" at the start of your code (i don't remember why).
FWIW for my GBA 256b intros I made a <=256b version that stores code where the Nintendo logo should be (as it is required by the real hardware to run, but it's 156b long...), and a "safe" version that does include the logo but exceeds the 256b filesize limit. It was accepted in the Deadline 256b compo. (See also the NFO.)
For Grey Twister With No Music I managed to cram the code into a small enough place so that the 8XP file is <=256b. However, the 8XP headers are quite bloated (42-byte comment field that isn't ever mapped into memory, THANKS TI), so I wouldn't want to force people to include that into the file size.
But party orgas usually have the final say, so it's probably not a bad idea to ask them beforehand.
For Grey Twister With No Music I managed to cram the code into a small enough place so that the 8XP file is <=256b. However, the 8XP headers are quite bloated (42-byte comment field that isn't ever mapped into memory, THANKS TI), so I wouldn't want to force people to include that into the file size.
But party orgas usually have the final say, so it's probably not a bad idea to ask them beforehand.
It also depends how the headers can be (ab)used. For example, Amstrad CPC has a rather large header but a lot of fields can be used to hide code in them. This means the files are listed with a size of 1K by the OS.
As a result, it is counted in 1K intros and they can use such tricks. But usually for 256bytes and less, it is not counted and we trust developers to not cheat by hiding things there (usually for such small size intros the sourcecode is provided so you can check the actual size anyway). The OS still shows a size of 1K because it doesn't make blocks smaller than that on disk anyway.
As a result, it is counted in 1K intros and they can use such tricks. But usually for 256bytes and less, it is not counted and we trust developers to not cheat by hiding things there (usually for such small size intros the sourcecode is provided so you can check the actual size anyway). The OS still shows a size of 1K because it doesn't make blocks smaller than that on disk anyway.
Should a standard executable header be excluded from the intro executable size? It seems header hacks, however interesting, just makes intros incompatible as new header standards are introduced.
Preacher: it's a packed deal, multi-file checksumming and headers and such.
gasman: The calculator has a memory manager built-in, and name changes and such affect total size, so I'm assuming it's pretty accurate. As I'm using a TI-BASIC program and one small Assembly snippet, it's 2 files in total.
hitchhikr: I'll have to check that out!
porocyon: That's pretty clever, but don't compos require the entry to work on hardware usually?
Also, an entirely unused chunk THAT LARGE is ridiculous!
PulkoMandy: Most of the extra 200-some bytes is for the sake of the transfer application, from what I gather. Almost all of that extra space is never seen by the actual calculator.
rloaderro: I wouldn't agree, as depending on the system the header type isn't gonna change any time soon, and if you can squeeze out some extra space, I personally say go for it, but that does break standards...
gasman: The calculator has a memory manager built-in, and name changes and such affect total size, so I'm assuming it's pretty accurate. As I'm using a TI-BASIC program and one small Assembly snippet, it's 2 files in total.
hitchhikr: I'll have to check that out!
porocyon: That's pretty clever, but don't compos require the entry to work on hardware usually?
Also, an entirely unused chunk THAT LARGE is ridiculous!
PulkoMandy: Most of the extra 200-some bytes is for the sake of the transfer application, from what I gather. Almost all of that extra space is never seen by the actual calculator.
rloaderro: I wouldn't agree, as depending on the system the header type isn't gonna change any time soon, and if you can squeeze out some extra space, I personally say go for it, but that does break standards...
Parzival: indeed, that's why I asked the compo orgas about it, and that's why you probably should as well, as they're the ones who have the final say in everything.