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.
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).
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".
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
Quote from: l12n on 19:08, 12 October 24In 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
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 :picard:
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?"
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. ;) :)
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
#AE66 only works with 664/6128 you must use #AE83 on a CPC464
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.
Quote from: Prodatron on 10:02, 25 October 24I 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. :P
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.
Quote from: Nich on 17:30, 02 November 24As 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 ;-)
Quote from: norecess464 on 16:05, 02 November 24I 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.