128 bytes demos and file headers on various systems
category: code [glöplog]
ATARI ST: 128+32 = 160 bytes
Thread closed.
Quote:
ATARI ST: 128+32 = 160 bytes
160 bytes != 128 bytes (valid for all platforms out there), thread closed.
Tradition != Tradition
Discuss.
Discuss.
Quote:
More seriously, 32 bytes for absolutely nothing on Atari ST is very much! 128 bytes on CPC for absolutely nothing is even more...
It's not really "nothing", it contains information like if the program should be loaded in ST/TT ram, the size of the DATA and BSS section, offset of the relocation information.
That being said, when I write a 4k game on the Oric or the Atari, I consider 4096 bytes size file as my objective. Not 4096 plus headers.
The only way I can see of putting the headers out of the equation, is to have a kind of demo loader that contains some "incbin 'demo.bin'", each included bloc being assembled at a specific address and having to be exactly 128 bytes long.
Sure you need such a loader for each platform, but at least it's fair: You are measuring what people can do with a particular number of bytes on a particular target machine.
But yeah, that's not individual programs you can run directly on the machine, I know :p
I think it's 2011, and Atari ST's fucked idea of 128b should be fixed, just like all the other systems. CPC has no 128b scene, but they could have a cool 256b scene, and people would be equally impressed. At least those who know enough to judge it properly, anyways ;) .
...and they DO seem to have a 256b scene. Imagine that ;)
Atari had and still has (I hope :) a 128+32 scene..
Hey Ferris, didn't this thread already end for you like 3 pages ago?
Yeah, but I don't argue enough with people in my daily life. This is the daily dose of ignorance to get me through my day. LOLOLOLOL
Oh, I thought you lived in America!
Nope. Recently moved to Norway. Explains it all, huh?
Wellllll... :)
"the Atari-Scene rules don't count the header. f.e. a 128-bytetro can be max. 160 bytes."
128 bytes=128 bytes. Period.
128 bytes=128 bytes. Period.
Plus header. Period.
:P
:P
If anything, people must take the extra header space into account when voting. 128 bytes is 128 bytes whether any or all of those bytes are used for a machine specific header or not.
In a joint platform competition, the header sizes should be the least of concerns, given that the platforms usually differ in more significant ways otherwise.
In a joint platform competition, the header sizes should be the least of concerns, given that the platforms usually differ in more significant ways otherwise.
Just come late to this thread, but it seems the only people arguing for headers to be counted in the byte count are MSDOS 128-byters.
I'd previously heard of the stub loaders on the Spectrum, and was under the impression that the 128 bytes was the size of the executable, not the size of the disk structure.
For instance, going back to the CPC again - where as explained above, the disk header is 128 bytes, which makes it impossible to even enter the competition if headers are included, yet a lot of good effects could be achieved in 128 bytes of executable, which is surely the actual thing we're trying to compare here.
But just to contemplate it further. If I didn't use a disk file on the CPC, but a tape file, then what? The OS would return the executable length as the file size (actually, it'd just say 1 block as it counts file size in multiples of 2KB and rounds up). So, if I handed you the same 128-byte executable on a physical tape, it'd be easy to argue that it IS actually 128 bytes long. However, giving you a file you can run on an emulator would add at least 576 bytes to that due to the tape headers the system adds and even the way pilot tones are described in the emulator file, etc. The actual content is still 128 bytes long. Whether you loaded the disk image or tape image, only 128 bytes of data gets transferred into memory to a known location.
Interestingly, this is more relevant for the 4KB demos on the CPC - 4KB of executable code will happily exist in 2 2KB blocks on tape, yet the OS will report 5KB on disk because it always adds this extra 128 byte header.
The problem is that a file is never just a plain file - there's always context required for the OS to know what to do with that. If you're going down the header counts to size route, you should really consider that the MSDOS .COM demo has a 32-byte directory entry, because checking this is the way that the OS determines whether to execute the file or not.
I'd previously heard of the stub loaders on the Spectrum, and was under the impression that the 128 bytes was the size of the executable, not the size of the disk structure.
For instance, going back to the CPC again - where as explained above, the disk header is 128 bytes, which makes it impossible to even enter the competition if headers are included, yet a lot of good effects could be achieved in 128 bytes of executable, which is surely the actual thing we're trying to compare here.
But just to contemplate it further. If I didn't use a disk file on the CPC, but a tape file, then what? The OS would return the executable length as the file size (actually, it'd just say 1 block as it counts file size in multiples of 2KB and rounds up). So, if I handed you the same 128-byte executable on a physical tape, it'd be easy to argue that it IS actually 128 bytes long. However, giving you a file you can run on an emulator would add at least 576 bytes to that due to the tape headers the system adds and even the way pilot tones are described in the emulator file, etc. The actual content is still 128 bytes long. Whether you loaded the disk image or tape image, only 128 bytes of data gets transferred into memory to a known location.
Interestingly, this is more relevant for the 4KB demos on the CPC - 4KB of executable code will happily exist in 2 2KB blocks on tape, yet the OS will report 5KB on disk because it always adds this extra 128 byte header.
The problem is that a file is never just a plain file - there's always context required for the OS to know what to do with that. If you're going down the header counts to size route, you should really consider that the MSDOS .COM demo has a 32-byte directory entry, because checking this is the way that the OS determines whether to execute the file or not.
guys, you are so funny))
if ST's intros doesn't count to 128, write one on the other platform.
so, 128bytros just dead concerning assholes who stay on 160 bytes.
if ST's intros doesn't count to 128, write one on the other platform.
so, 128bytros just dead concerning assholes who stay on 160 bytes.
doz is right. You write a code file that is 128 bytes long. There is no ZX Spectrum tape or disk format (TAP, TRD, SCL, hobeta...) that does not add headers or something. But on actial ZX Spectrum it's a 128 bytes file.
@Alone, you can run ZX piece of code from Perfect Commander.
some limitation just ridiculous.
some limitation just ridiculous.
quote from wikipedia:
Quote:
The COM format is the original binary executable format used in CP/M and MS-DOS. It is very simple; it has no header (with the exception of CP/M 3 files), and contains no metadata, only code and data. This simplicity exacts a price: the binary has a maximum size of 65,280 (FF00h) bytes (256 bytes short of 64 KiB) and stores all its code and data in one segment.
Since it lacks relocation information, it is loaded by the operating system at a pre-set address, at offset 0100h immediately following the PSP, where it is executed (hence the limitation of the executable's size). This was not an issue on early 8-bit machines because of how the segmentation model works, but it is the main reason why the format fell into disuse soon after the introduction of 16- and then 32-bit processors with their much larger, segmented memory.
