bootloader CPCTelera : load files

[freemac]

I tryed to load files from CPCtelera, it does fail
https://github.com/renaudhelias/RubikCubePaletteCPC/blob/master/JDVPA%235_test/jdvapi_floppy.c
but with SDCC it is OK.

So I tryed to create a bootloader launch.bas

Code Select Expand

10 memory &3FFF
20 REM load"!molusk.akg",&7000
25 load"!fond.scr",&4000
30 REM load"!akg6000.bin",&6000
40 run"!helloren.bin"

On helloren.bin (my main) I have calque4000() that display at &4000 instead of &C000
https://github.com/renaudhelias/RubikCubePaletteCPC/blob/master/JDVPA%235_test/jdvapi_sync.c

Result : my picture is shown but firmware interrupt (that I can stop only after launch of main) does destroy it :
[attach=1]

[Targhan]

Your background is 16kb, from &4000 to &7fff.
You load more data in &6000 and &7000. So obviously, your image is being overwritten by them.

[freemac]

Your background is 16kb, from &4000 to &7fff.
You load more data in &6000 and &7000. So obviously, your image is being overwritten by them.

My loads into &6000 and &7000 are in comments (REM)

[Targhan]

Oh yes sorry, I read too fast. Mmmhh, then what is the load address of  the "helloren.bin"? I don't see any ORG in the source. Are you sure it's not between #4000 and #7fff?
Also, if you DON'T load the music. Are you sure you don't make a call to the player even though it's not there anymore?

The system does not put anything between #4000 and #7fff, and the system interruption does nothing to it either, so it must be data you put by yourself.

[freemac]

Code Select Expand

10 memory &3FFF
15 out &7FC0,&C4
20 REM load"!molusk.akg",&7000
25 load"!fond.scr",&4000
30 REM load"!akg6000.bin",&6000
35 out &7FC0,&C0
40 run"!helloren.bin"

Using bank4_4000() and then bank0123(), fond.src is loaded in bank4 (so I think I can use a function to copy the content after turning off the firmware interrupt, I'll try later)
https://github.com/renaudhelias/RubikCubePaletteCPC/blob/master/JDVPA%235_test/jdvapi_sync.c

&4000 is still busy, even I use the less instructions I can in main().
[attach=1]

[freemac]

I tryed just to switch bank4() in main

bank4_4000();
//cpct_memcpy(0x4000, 0xC000, 0x4000);
bank0123();

but it crash.

I think strange instructions in &4000 area are still in live after removing firmware interrupt.
I think it is STACK of sdcc functions, perhaps a cpct_setStackLocation(a) could save the behavior.
I know that disk loader is using &4000 as garbage (so until I found who is writing this &4000 area)

[ronaldo]

I tryed to load files from CPCtelera, it does fail
https://github.com/renaudhelias/RubikCubePaletteCPC/blob/master/JDVPA%235_test/jdvapi_floppy.c
but with SDCC it is OK.

So I tryed to create a bootloader launch.bas

Code Select Expand

10 memory &3FFF
20 REM load"!molusk.akg",&7000
25 load"!fond.scr",&4000
30 REM load"!akg6000.bin",&6000
40 run"!helloren.bin"

On helloren.bin (my main) I have calque4000() that display at &4000 instead of &C000
https://github.com/renaudhelias/RubikCubePaletteCPC/blob/master/JDVPA%235_test/jdvapi_sync.c

Result : my picture is shown but firmware interrupt (that I can stop only after launch of main) does destroy it :

This is not a CPCtelera issue, nor CPCtelera does anything you haven't told it to do, because it is not a software running in the background, but merely a framework of tools.

The problem here is that you are using old SDCC code that does not work well with current versions of SDCC unless you force SDCC to use its old routines which haven't been maintained for years and are buggy (i.e. --oldralloc). In this case, you use IX (the frame pointer) to access stack parameters. However, newer versions of SDCC do not synchronize IX with the stack frame ever again. So, basically, if you use IX to access stack parameters with newer versions of SDCC, you are calling undefined behaviour (you don't know what data you are getting).

If you want to access stack parameters, prefered method is not using inline assembly, but adding a .s file to your project and using pure assembly. Then, you may use pop to get parameters, and push to restore the return address onto the top of the stack. Finally, in C, you declare your function as __z88dk_callee. This is the prefered method for functions like this. Alternatively, you may just set IX to point to the stack by yourself, at the start of your function and maintain the rest of your code.

[freemac]

indeed I had that special sdcc parameters to make running jdvapi_floppy.c on my old project

sdcc -mz80 -c --std-c99 --opt-code-speed --oldralloc jdvapi_sync.c
sdcc -mz80 -c --std-c99 --opt-code-speed --fno-omit-frame-pointer --oldralloc jdvapi_floppy.c

[freemac]

Btw I found that in cfg/build_config.mk :

Code Select Expand

PROJNAME   := hellorenaud
Z80CODELOC := 0x4000

If I replace with :

Code Select Expand

PROJNAME   := hellorenaud
Z80CODELOC := 0x6000
The offset of code writing over my &4000 image.scr does change :
[attach=1,msg195247]

[freemac]

Code Select Expand

PROJNAME   := hellorenaud
Z80CODELOC := 0x0138

With a light program it does run fine :
[attach=1]

If I launch the full program it does crash (my next step will be activating code line per line.

Code Select Expand

Z80CCLINKARGS := -mz80 --no-std-crt0 -Wl-u \
                 --code-loc $(Z80CODELOC) \
                 --data-loc 0 -l$(CPCT_LIB)
0 for "--data-loc" seems correct, in my old project I've got :

Code Select Expand

sdcc -mz80 [b]--code-loc 0x0138 --data-loc 0[/b] --oldralloc --no-std-crt0 crt0_cpc.rel jdvapi_basic1.rel jdvapi_frame.rel jdvapi_keyb.rel jdvapi_sync.rel jdvapi_floppy.rel combat2.c

[freemac]

Also, if you DON'T load the music. Are you sure you don't make a call to the player even though it's not there anymore?

I use
#ifndef NO_SOUND
// sound part of code
#endif
everywhere

[freemac]

cpct_drawStringM0() does use lowerROM char map so &0000-&3FFF is busy (as explained by CPCtelera doc). That's why CPCtelera does start by default at &4000.
A sort of char tiles, with offset of 1 pixel per 1 pixel.

[ronaldo]

cpct_drawStringM0() does use lowerROM char map so &0000-&3FFF is busy (as explained by CPCtelera doc). That's why CPCtelera does start by default at &4000.A sort of char tiles, with offset of 1 pixel per 1 pixel.

This is not correct. Docs explain that if you use cpct_drawStringM0, you have to take care of how it works (by enabling and reading the ROM). Again, I repeat. CPCtelera is not any kind of resident software, it is not running on your background, it does not do anything unless you directly call library functions. CPCtelera is a framework, which includes a low-level library of functions. These functions are not mandatory, nor they are included into your binary unless you specifically use them. You can code using CPCtelera framework without including a single byte of the low-level library, and the library only includes functions. As such, these functions only work when you call them. If you don't call them, they are not there, they can do nothing.

With respect to --oldralloc, SDCC developers stated more than 6 years ago that it is deprecated and unmaintained. Using it is asking for trouble, as there shall be many bugs in the code generated do to it not being maintained. So, I hugely recommend not using it and changing the way you get parameters from the stack. I took this advice when I started coding the low-level library on 2014. Take it into account.

However, by looking at your latest posts, the problem is exactly what @Targhan was describing. When you load the BIN file, it gets loaded in the place in memory it sais in its AMSDOS header. This place is set when you compile, and Z80CODELOC is exactly the macro that gets passed to SDCC to establish that point in memory. So, if you had Z80CODELOC=0x4000 or Z80CODELOC=0x6000, then your code was simply being loaded in the middle of your image. Once you have changed the place where your binary loads, it does not overwrite your image. As simple as that.

[reidrac]

Well, use the new SDCC behaviour and setup ix yourself.

Code Select Expand


ld ix, #2
add ix, sp
... etc ...


It is slower than using __z88dk_callee convention; but basically you can do whatever you want as long as you understand what are you doing

ronaldo's advice is sound, but I would go further and recommend you to read the docs of the SDCC version you are using. Things change when a new version is released and your code may or may not behave as you expect.