Auto-starting an assembly program

[l12n]

In the assembly examples that I found, it loads the executable at address $1200, and then after you load the binary you have to manually call that address.

Is there a way to have the executable automatically start after you load it? This is the case for commercial games.

[andycadley]

You can create a boot sector that can be loaded via |cpm or just use an auto running BASIC program that loads and executes your code (by far the easiest solution).

[pelrun]

You just need to save the binary with a start address (in basic: SAVE "filename",b,load-address,length,start-address) and then simply RUN"filename".

[retro space]

Funny on the CPC commercial games tried this. Philips did not allow it in their code of conduct for human friendly program design. Each program should have a first line of BASIC code to start the assembly with a USR function, line 10, and a standardised tail of 6 lines (65520-65525) with REM comments about version and author. This means every program needs RUN, and every program has to clear up its memory mess on QUIT (yes every game had a quit option). You could off course use RUN "program name" in the code for a boot menu, the system aways runs te first program on a tape on boot, or the one with the name "AUTORUN" if you used a disk drive.
Even though the machine had a reset button, it was not needed often. I never understood the "C64 way" where we were using that power switch all the time. Some programs had a second line of BASIC visible that you could edit, it was to load a menu after quit. Something like 65519 RUN"menu":END

[GUNHED]

In the assembly examples that I found, it loads the executable at address $1200, and then after you load the binary you have to manually call that address.

Is there a way to have the executable automatically start after you load it? This is the case for commercial games.

save"Binary" , b , load-address , length , autostart-address

[Optimus]

It's embarrasing, but somehow I didn't knew you could also provide autostart address, and I would save binary with load and length, then exit the emulator, run managedsk, and add the auto-start address manually 

How the heck. Now I know and I appreciate this extra information. Damn,. I previously would create a basic loader and that's maybe why I didn't know because my basic loader would call at that address anyway. Later I see the tiny intro compos at demoparties, usually in their rules is stated that it's ok if you use a basic loader for tiny 256bytes or something, as they assume it's necessary on CPC. But I know a stand alone was possible, however I was doing the managedsk extra step for some reason.

And also how good the CPC basic OS is. The last time I was trying to do something on C64, unless I am mistaken, I was using an assembler and would do an executable for you. But I was searching if there was an option to assemble and then myself save a binary from memory with load/start address, and I remember I asked a bit on C64 forums and there wasn't a positive answer, like it wasn't a thing or "why do you want to do that?"

[GUNHED]

Using a BASIC loader has advantages: The system stays in the current state (f.e. selected drive, etc, etc.)

Starting a binary will reset most parts of the firmware. It will provide a standardized environment. And you Z80 will need to initialize quite some parts (f.e. the drive you want to use... ).

It's more easy in CP/M, SymbOS and FutureOS. 

[Prodatron]

I prefer the combination of basic and binary in one file:

type...
1 CALL &180

Now assemble/put your machine code program starting at #180.
Write the end address+1 of your program to #AE66.

type...
save"program"

It is now saved as a Basic program, which looks like a 1-liner, but it contains your complete binary as well as a hidden payload.

The advantages are:
- you have everything in only one file, so loading will be faster
- it won't reset the whole system after loading the program, like it does for executable binary files
- so it runs great with any DOS extension as well, if you need to load additional stuff later

[Johnny Olsen]

#AE66 only works with 664/6128 you must use #AE83 on a CPC464

[norecess464]

I wonder if people realize how important the two posts above are. Thank you @Prodatron and @Johnny Olsen for pointing the binary-as-basic program trick.

[Nich]

I prefer the combination of basic and binary in one file:

type...
1 CALL &180

Now assemble/put your machine code program starting at #180.

You can also use CALL &17C and start your machine code program at &17C if you're really desperate for space.

As an aside, typing POKE 370,0 after entering the above line will set the line number to 0 and trick BASIC into hiding it when using the LIST command.

[norecess464]

As an aside, typing POKE 370,0 after entering the above line will set the line number to 0 and trick BASIC into hiding it when using the LIST command.

.... and RENUM to make the line reappear ;-)

[arnoldemu]

I wonder if people realize how important the two posts above are. Thank you @Prodatron and @Johnny Olsen for pointing the binary-as-basic program trick.

100% agree here.

Prodatron and GUNHED outline the important advantages.

I will also add:
* When BASIC is used to load a binary file MEMORY is used to set HIMEM and it is loaded like this (OPENOUT"d" allows HIMEM to go much lower):

10 OPENOUT"d"
20 MEMORY &4000
30 LOAD"file",&4000
40 CALL &4000

but MEMORY can't be set as low as &17C. I think the min is &383.

* If you are concerned about HIMEM being too low and the program will not load 100% with a low HIMEM (where some DOS or ROMS allocate some memory) then do this:

10 CALL &17C,HIMEM

Then you can check this in your code and report an error if it's too low and then the user can choose to disable/unload roms.