SDCC and header files or constant values | MSX Resource Center (Страница 2/2)

By aoineko

Paladin (1004)

05-11-2022, 09:36

Perhaps because you don't have the right slot set in page 0 at this moment?

By jepmsx

Master (254)

05-11-2022, 09:50

Oh! I haven't thought about that.
Is there a way to set an interruption in openmsx to check if it changes?
Or is there a way to make sdcc to place a function to a fixed addres? I know that it can be done with variables but is it possible with functions?

By jepmsx

Master (254)

05-11-2022, 12:00

I've checked the version that works, and it has the same mistery as the one that doesn't work. The function called in the interrupthandler has the values in .lst and .map that don't match the ones in memory. So it must be something else.

The only difference between the code that works and the one that doesn't is a call to a new function that was never used in the program that works. I've tried this new function in a short example with a short interrupthandler function and it works without problem.

I'm totally lost.

I've checked the ihx file for the bytecodes indicated in the lst file for the code of the interrupt handler and they appear. I've also checked the .com file and they are also there. How does MSXDOS load a .com file? Is there a way that I could map the position of the .com file into memory?

By aoineko

Paladin (1004)

05-11-2022, 12:37

Your .com file will be loaded at 0100h so a position in your binary will be in RAM at this position + 0100h.
The address in your .map already have this offset so they are the final address in RAM.
When your program start all the memory page point to the same RAM slot.

Sorry but it's hard to help you more; the problem seems to come from your code and/or Fusion-C.

By jepmsx

Master (254)

05-11-2022, 13:21

Your help is very welcome. I always learn new things with the answers.

But don't worry, I think that after a few more trials and errors I won't use the new function. It is a function to flip RAM into a sprite, I will keep the flipped sprite in RAM as I did before.

Anyway, if I break the program just after it is loaded, putting a WaitKey() as the first task in the main() function should leave the memory RAM untouched, isn't it?

By aoineko

Paladin (1004)

05-11-2022, 14:50

It depends on the startup code you use (crt0). It usually has some initializations before the assembly code gives the main() function a go.

For example, in MSXgl the startup code of an MSX-DOS program (https://github.com/aoineko-fr/MSXgl/blob/main/engine/src/crt...) will initialize the values of the global variables in memory before calling main().
Check what the Fusion-C crt0 code does.

By jepmsx

Master (254)

08-11-2022, 22:23

I've finally successfully compiled it and working. The problem was that I was calling the function WaitForKey() in place of the one that appears in Fusion-C WaitKey(). I've searched in the library and WaitForKey is a defined of WaitKey (#define WaitForKey WaitKey)

I still don't know why replacing the define for the WaitKey has solved the problem. I assume that maybe are problems with the linker.

But I'm happy that it works

By jepmsx

Master (254)

14-11-2022, 14:07

Finally!

After observing the same behaviour again after adding a new call to a function that was already in the system, I've seen a warning about printf.rel. I've checked the version of sdcc and it was 4.2. It had been udpated!

So I've gone back to 4.1, which is the version that Fusion-C is compiled with, and everything is back to normal. I've also blocked the upgrading of sdcc to avoid more scares.

By pizzapower

Master (166)

09-12-2022, 15:16

Just avoid SDCC 4.1.0 as it generates broken code (at least on Linux) that is hard to track down. Took me I while to find out.