128 bytes demos and file headers on various systems
category: code [glöplog]
Back to the compilation (even though many don't like the ideas)...
Atari ST:
32 bytes header for .PRG or .TOS programs (Can we hide infos in it?)
32+128=160 bytes
(Don't know if we can hide some infos in the header, but can check)
Commodore 64:
I append the following code to avoid asking for a SYS instruction by user, he can type RUN instead.
13+128=141 bytes
(I get a CPU Jam on Vice when removing the 0s, but it seems some info can be hidden there...)
Amstrad CPC
The header of a single binary file is 128b alone :P
128+128=256 bytes
(Also, in Amsdos every file displays 1k in the catalogue no matter if it's much fewer bytes.)
Atari 8-bit
Atari 8-bit uses 6 bytes executable header ($ff,$ff,startlo,starthi,endlo,endhi) to run from Game Dos menus. An executable which runs from any DOS 2.5 compatble DOS would even required 6 bytes more for the run address specification, i.e. 12 bytes header.
6+128=134 bytes
Commodore Amiga
24 bytes + 12 bytes per section (i.e. minimum 36 bytes). There is no space to put anything interesting into the header, but code can read the size of the section it is in and the pointer to the next section, so sections can effectively be used as a cheap way to allocate memory. In principle you could also put useful data into the section size.
36+128=164 bytes
Archimedes / RiscPC / PC / ?
0+128=128 bytes
Atari ST:
32 bytes header for .PRG or .TOS programs (Can we hide infos in it?)
32+128=160 bytes
(Don't know if we can hide some infos in the header, but can check)
Commodore 64:
I append the following code to avoid asking for a SYS instruction by user, he can type RUN instead.
Code:
org $801-2
.word $0801 ;Load adress (C64)
.word BasicEnd,2011 ;Adress of next line + line number
.byte $9e,$32,$30,$36,$32 ;Basic "SYS 2062" instruction
.byte 0 ;End of basic line
BasicEnd:
.byte 0,0,0 ;End of basic program
start:13+128=141 bytes
(I get a CPU Jam on Vice when removing the 0s, but it seems some info can be hidden there...)
Amstrad CPC
The header of a single binary file is 128b alone :P
128+128=256 bytes
(Also, in Amsdos every file displays 1k in the catalogue no matter if it's much fewer bytes.)
Atari 8-bit
Atari 8-bit uses 6 bytes executable header ($ff,$ff,startlo,starthi,endlo,endhi) to run from Game Dos menus. An executable which runs from any DOS 2.5 compatble DOS would even required 6 bytes more for the run address specification, i.e. 12 bytes header.
6+128=134 bytes
Commodore Amiga
24 bytes + 12 bytes per section (i.e. minimum 36 bytes). There is no space to put anything interesting into the header, but code can read the size of the section it is in and the pointer to the next section, so sections can effectively be used as a cheap way to allocate memory. In principle you could also put useful data into the section size.
36+128=164 bytes
Archimedes / RiscPC / PC / ?
0+128=128 bytes
@Adok: i don't care about Mensa (Captain: i'm not in Mensa! ;p ). As a Math teacher I don't like iq tests. I just like puzzles which is probably another, less pretentious, name for them... (btw Mensa France shows a Sudoku which is the most uninteresting kind of puzzles!)
But feel free to redirect your Mensa mates to my webpage.
But feel free to redirect your Mensa mates to my webpage.
Quote:
Assuming that the people entering such a compo know their systems so well, we can conclude that this compo would only serve to prove which system has the best opcode size/output ratio. Doesn't sound very fun to me since that reduces the compo to a "my system is better than your system" debate, instead of comparing actual coding skill and creativity.
Quote:
HTF can you compare a C64 128b to a PC 128b to an Amiga 128b
We can't, i don't want to, i just want to see them all!... We all know (?) that voting in demoparties/programming compos is completly subjective (except maybe for contests like: write the smallest/fastest program doing xxx on yyy hardware) and so the ranking is stupid and unimportant. Sometimes some feelings can be hurt with the ranking, but that's not only the case in multiplatform compos (see what i mean), but after a while the blood pressure shall go to its normal level if there's no money as the prizes.
So fuck the ranking/comparison between prods, fuck the voting systems. But we need competitions to motivate us releasing prods! And what matters is that we SEE MORE DEMOS, hopefully of decent quality, whatever the computer, whatever the imperfections of the "ranking" system. I thought Heather+128b could help in this...
ZX Spectrum:
For an executable to be loadable with LOAD "", there needs to be a BASIC loader stub. Normally this is kept as a separate file on tape/disk, and traditionally the Spectrum scene doesn't count the loader towards size limits. However, it's possible to embed machine code within a BASIC program file, and cross-platform competitions may sometimes require Spectrum entries to be packaged that way (and counted by the full length of the BASIC file), for consistency / fairness with other platforms. The smallest known BASIC stub adds 11 bytes of overhead in the general case (but it's possible to hide data there with careful hand-tuning):
11+128=139 bytes
(For completeness: all regular files on tape are preceded by a 17-byte header; the header and the data block have two bytes added for a flag byte and checksum; and on an emulator, the container format will add overheads of its own. But all of this is filesystem metadata external to the file - it applies to all files, not just executables - and I'd argue that it makes no sense to count this, any more than you'd count the FAT entry for a PC intro.)
For an executable to be loadable with LOAD "", there needs to be a BASIC loader stub. Normally this is kept as a separate file on tape/disk, and traditionally the Spectrum scene doesn't count the loader towards size limits. However, it's possible to embed machine code within a BASIC program file, and cross-platform competitions may sometimes require Spectrum entries to be packaged that way (and counted by the full length of the BASIC file), for consistency / fairness with other platforms. The smallest known BASIC stub adds 11 bytes of overhead in the general case (but it's possible to hide data there with careful hand-tuning):
Code:
nn, nn - line number (arbitrary)
nn, nn - line length (ignored)
'RANDOMIZE', 'USR' - BASIC command
'0' - fake ASCII representation of start address (ignored by interpreter)
0x0e - marker for floating point value
0x8f, 0x39, 0xac - first three bytes of start address (23766) in floating point form
- code begins here (overlapping last two bytes of floating point value, which will be rounded away)
11+128=139 bytes
(For completeness: all regular files on tape are preceded by a 17-byte header; the header and the data block have two bytes added for a flag byte and checksum; and on an emulator, the container format will add overheads of its own. But all of this is filesystem metadata external to the file - it applies to all files, not just executables - and I'd argue that it makes no sense to count this, any more than you'd count the FAT entry for a PC intro.)
Then again, true hardcore-style VCS intro would be to copy 128 bytes of code from ROM to RAM and then execute. Avoiding the stack from eating your code and self-modifying for effects would make for a truly difficult challenge.
Hmmmmm.... ;)
Hmmmmm.... ;)
visy: only if the hardware vectors count as part of the size, hehe.
Still, I wouldn't consider these 128b intros. But VCS Stack Intro is a nice name.
Still, I wouldn't consider these 128b intros. But VCS Stack Intro is a nice name.
On the Oric, if you write a tape program, the minimum header size that will still allow for loading of the file on a real machine is 14 bytes.
On disk, that's more complex, technically there are no header because everything is in the directory/fat information area.
On disk, that's more complex, technically there are no header because everything is in the directory/fat information area.
an amiga executable is at least 8 longwords of overhead, i.e. 32 bytes. That is for an executable with one section/code hunk. In practice, a 128B executable would probably have a bss hunk as well for storage, which would add another 3 longwords.
Quote:
My original post was (partly) motivated by the following question asked by Blueberry, in outline 2011 thread
Quote:A couple of 128-byte questions:
Is an Amiga bootblock where only the first 128 bytes are used (i.e. the remaining 896 are zero) eligible for the 128-byte compo?
But i think he answered himself to his question just above:
Quote:I agree with iq et al: The size limit of an intro applies to the size of the file.
128 b != 1Kb... ;p
Well... Wether or not the header is counted in the size, and whether the intro can be embedded in a fixed size container (padding with zeros) are two separate issues. Also, the bootblock is strictly speaking not a file. :)
The size of the bootblock is rounded up to a fixed size (1k) in much the same manner as the actual space a file takes up in a file system is always a whole number of blocks (512 bytes on Amiga). We usually don't say that a 128-byte intro takes up 512 bytes even though that is the space it actually uses on disk.
This problem is particularly evident for 4k intros on C64, where file sizes are measured in blocks, rather than bytes, and 4096 bytes is not a whole number of blocks. The convention here is, as far as I understand, that the remaining bytes in the last block (beyond 4096 bytes) must be zero.
i'll give you a nice example on how multiplatform 128b/256b or any similar size compitition doesn't make sense at all.
Here is my recently releases c64 256b (254 actually) cube rotation effect:
http://www.pouet.net/prod.php?which=56981
And here is the Atari 800 XL/XE port:
http://www.akaydin.com/atari/codes/skate/previews/rottoprojo800.zip
Both machines are 6502 based and core code is exactly the same. But because of the c64 and atari sprite structure differences (actually sprites are called players & missiles on Atari platform) Atari version is 384 bytes at the moment. It can be optimized but i don't think i will ever be able to reach 256 bytes. I'll try using graphic modes but i don't think it will help so much.
In short, even if the CPUs are the same, different machines can become a reason of 1.5x size difference. Multiplatform 128b compo would never be fair regardless to include the executable header sizes or not.
one final message: using $007e as startup address doesn't allow more than a few bytes of code to run. you can't even fit 32 bytes there. you are extremely limited. but you can use $0326 as startup address and have very long executables. using $0326 4 bytes of header is ok. but you may fail trying to use kernal routines using that method.
Here is my recently releases c64 256b (254 actually) cube rotation effect:
http://www.pouet.net/prod.php?which=56981
And here is the Atari 800 XL/XE port:
http://www.akaydin.com/atari/codes/skate/previews/rottoprojo800.zip
Both machines are 6502 based and core code is exactly the same. But because of the c64 and atari sprite structure differences (actually sprites are called players & missiles on Atari platform) Atari version is 384 bytes at the moment. It can be optimized but i don't think i will ever be able to reach 256 bytes. I'll try using graphic modes but i don't think it will help so much.
In short, even if the CPUs are the same, different machines can become a reason of 1.5x size difference. Multiplatform 128b compo would never be fair regardless to include the executable header sizes or not.
one final message: using $007e as startup address doesn't allow more than a few bytes of code to run. you can't even fit 32 bytes there. you are extremely limited. but you can use $0326 as startup address and have very long executables. using $0326 4 bytes of header is ok. but you may fail trying to use kernal routines using that method.
Skate: That's like claiming football does not make sense at all because not all players can run equally fast.
@Rowley Birkin: nope, that's a wrong example. it's like claiming football (c64) vs basketball (atari) match doesn't make sense. football (c64) players (sceners) don't have the same speed (knowledge, talent, experience etc.) but can compete in the same match (compo). same applies to basketball league (atari scene). is it clear now?
Combined 128b intro competitions make as much sense as combined ASD, Satori, Razor 1911 and Metalvotze demo competitions.
skate: in a demo compo, the teams don't play against each other in a match. They show their skills off one at a time, then leave the field. There's no problem with a football team showing their skills with the ball, then the basketball team doing the same, and the crowd deciding which was the best to watch.
SKATE 4 PREZ
...because he's right.
...because he's right.
Yes, from now on the demo teams must produce exactly the same demo on identical hardware, and the best one will win!
... or maybe metalvotze will win with a joke prod, while fairlight's technically stunning design masterpiece goes ignored by a crowd of gamers. One of those two options anyway.
... or maybe metalvotze will win with a joke prod, while fairlight's technically stunning design masterpiece goes ignored by a crowd of gamers. One of those two options anyway.
For my pc 128b intros I would like an additional couple of bytes because I have to set the screen to graphics mode. No fair!
TBH I'd just accept what's the norm (within reason) on a given platform. The first 128 byters I've seen on Atari ST were 128+32=160 bytes and that's what I intend to use. If the party disqualifies the entry or does not accept it as a 128 byter, it's another matter.
Oh, and as per baah's original post:
Atari Jaguar: 0 bytes header (can assemble and run to $4000 which is the de facto standard for absolute binaries)
Oh, and as per baah's original post:
Atari Jaguar: 0 bytes header (can assemble and run to $4000 which is the de facto standard for absolute binaries)
@Blueberry: right, but 128b is generally meant to be a file (ok now it's me speaking about unspoken rules)...
@Skate, Ferris and others...
As i already said, i personnaly agree with you, we can't compare demos on different hardware! Nowaday PCs have a Fpu, oldschool computers don't, etc... But i also like psonice's point of view.
If you don't take the compo too seriously, if you accept to have your prod aside one on another hw, then we shall try to hace as much entries as possible. If we concentrate on Atari ST 160b entries, were comparison has a sense, we will have 2 or 3 of them at most! If we say 128b+header, even CPC fans can compete. I want to see their work, that's what matters most to me.
I prefer to say "I LIKED" more than ranking prods...
@Skate, Ferris and others...
As i already said, i personnaly agree with you, we can't compare demos on different hardware! Nowaday PCs have a Fpu, oldschool computers don't, etc... But i also like psonice's point of view.
If you don't take the compo too seriously, if you accept to have your prod aside one on another hw, then we shall try to hace as much entries as possible. If we concentrate on Atari ST 160b entries, were comparison has a sense, we will have 2 or 3 of them at most! If we say 128b+header, even CPC fans can compete. I want to see their work, that's what matters most to me.
I prefer to say "I LIKED" more than ranking prods...
@Skate: Nice Atari port, let's see how low you can go. I see quite a bit of potential in the curently version - but have no spare time this weekend :-(
Also, headers are not hardware dependant but system dependant.
One could code a minimal OS for his machine just to launch his demo, with a zero byte header, and bypass this problem in an inelegant (at least if the OS is not serious) way... Much better to go on for the standard OS and wipe header.
@ile: for your PC intros you have fpu, you're right, that's unfair... More seriously, 32 bytes for absolutely nothing on Atari ST is very much! 128 bytes on CPC for absolutely nothing is even more...
One could code a minimal OS for his machine just to launch his demo, with a zero byte header, and bypass this problem in an inelegant (at least if the OS is not serious) way... Much better to go on for the standard OS and wipe header.
@ile: for your PC intros you have fpu, you're right, that's unfair... More seriously, 32 bytes for absolutely nothing on Atari ST is very much! 128 bytes on CPC for absolutely nothing is even more...
"One could code a minimal OS for his machine just to launch his demo"
You're going too deep dude. Following your point of view, if it's a mixed compo, you can create your own hardware and do the most advanced compo entry in zero byte, right? :)
You're going too deep dude. Following your point of view, if it's a mixed compo, you can create your own hardware and do the most advanced compo entry in zero byte, right? :)
[quot]You're going too deep dude.[/quote]
Probably, sorry then...
And anyway i'm not even sure to compete in 128b @outline...
Probably, sorry then...
And anyway i'm not even sure to compete in 128b @outline...
if you can't make it 128B then make it 256B or 1K or whatever you can, but whining that header size should be excluded is plain lame.
Skate: This is a slippery slope, indeed.
