pouët.net

Hi there,

I've found an interesting topic at a Czech Spectrum message board which is worth to discuss in my opinion.

It's about 1K intros, but it can affect generally any executable demo prod which is about to fit to specific memory size.

On the Spectrum, it's very clear. In the party compo rules is usually written something like: "1K intro - 1024 bytes of code". Which means you have to make your code 1024 bytes big or less. On the Spectrum there are basic loaders and TAP files common. The size of the TAP container is not equal to size of the code. There is a header on the beginning and one must also count the BASIC loader which runs the following code block itself. All in all, size of such a 1K intro packed in a TAP file with loader can override 1024 bytes. Naturally.

OK, but! Look at the C64 scene. The distribution happens in PRG files. Whis is nothing more than a pure executable C64 file. But to be able to run it, it must have a short BASIC program on its beginning with SYSxxxx. On the C64 this program is counted into the final length of the intro... To be more exact, if your intro = 1024 bytes of your assembly code, you must cut it to make space for that BASIC runner.

So generally, C64 scene has never had a full 1024 (or 4096 etc) intro!
This also relates PC, Amiga, and other platforms which use one file programs... or? :)

Well, as far as the c64 part of your argument goes: You don't need a "BASIC runner" at all. It's just an added convenience for the end user. Not to mention that you can fake an autostart. Also, there's the actual RPG file that has a 2 bytes micro-header (the loading address) etc;


COM files on PC (CP/M, DOS) don't have headers at all.

<quote>You don't need a "BASIC runner" at all. It's just an added convenience for the end user. Not to mention that you can fake an autostart. Also, there's the actual RPG file that has a 2 bytes micro-header (the loading address) etc</quote>

How is that done?

Atari:
.XEX or .COM file:

header is $FF,$FF
dw start_adress
dw end_address

about .TAP on ZX i think real code block is a matter of size.

Naturally. But on the other platforms there must be some runner which is included in the one file program. And that gives non ZX (or CPC) advantage because your code can be 1024 bytes exactly without loose bytes for starting it.

xorry I mean advantage to ZX (or CPC)

Factor6: The fake auto-start? Here's an example where I used the $7c trick. Might not work on the real thing. Look at the code review for one of the 4mat tinytros, also on my gist page for some more info on that one.

@tomaes: thank you!

on CPC header of codeblock takes 68 bytes:
http://cpcwiki.eu/index.php/AMSDOS_Header

but if you use winAPE64 you can check size of file.

@Factor6: autostart is done by loading over jump vectors of the running c64 OS. fex. you overwrite the vector of the print routine, then when finished loading, instead of displaying ready it will jump to your code. note that this is a hypothetical and not actual example.

We have some discussion about this here

Also it seems only(?) dos is without that headache, the platform of the zero bytes demo :)

Oswald: Well, the example above is an actual example. (which actually relies on a property/default setting of VICE to work, hence it won't do on CCS64 and the like, where you *do* get a "ready" and a "load error" message before that).

We had the same discussion some years ago here: http://www.pouet.net/topic.php?which=8111&page=1
So it seems both atari and spectrum people are wussies that need the full 128/1024/whatever bytes of payload :P

(and said property is that VICE auto-adds "RUN" + return; it also works with just return, so that the relevant interpreter code gets called and your code starts)

isn't saying the basic upstart should be included on c64 a bit silly? Do you not have to run a DOS program from the command line explicitly? Isn't that exactly the same thing?

Speaking of c64 the other trick is to use the BSOUT vector like this:



Which gives you a bigger area to work in without having to do funky things with the $7c trick. I saw this in one of the Tiny Sid entries.

On Thomson the format of binary files uses chunks like this:



And a footer with:



This is interesting because you can "load" data into the hardware registers and make things happen without writing any code. In that case it seems logical to take the header size into account.

On CPC with the huge and relatively useless header, I'd say it makes sense to not count it. But it seems most people do now (so you can see "4K" in the disc catalog, and not "5K", for a 4K intro).

I think TAP files for spectrum are a bit different, they are more a storage medium than a file format.

I have noticed that compo rules for C64/oldskool compos often prohibit autostart (at least Breakpoint and Revision have done this). How come?

Just a hunch but I guess because it's harder to start recording that way?

The no-autostart rule was mostly about compatibility with different fastload cartridges, etc. Stuff breaks in wubtle ways there.

(Now that everyone's using Retro Replay anyway one could rethink that rule - but at least in the case of the C64 it's very hard to code a working autostart that's actually shorter than "2014 SYS2059" (2bytes line number, 1 byte sys token, 4 bytes 2059, 3 bytes line end and program end markers => 10 bytes).

Also, I accidentally some dubstep joke in there.

This discussion reminded me of this thread.

Psycho beat you to it, Baudsurfer. :P

Correct ;) Good Eye Starchaser.

that can be shortened by at least 1 byte =)