Page 1 of 1

OSDK 1.15

Posted: Sat Sep 07, 2019 10:41 am
by Dbug
This version 1.15 is a really minor version update which is somewhat more of a regression than progress.

Basically some of the C Compiler upgrades have been removed because they were causing code generation issues (thanks to Retroric and Goyo for the testing), Fabrice is informed and may provide some new updated code at some point.

And Retroric I hope will be happy to know that "sound.h" should include correctly without generating errors.

Code: Select all

#define NOTE_C        1
#define NOTE_C_SHARP  2
#define NOTE_D        3
#define NOTE_D_SHARP  4
#define NOTE_E        5
#define NOTE_F        6
#define NOTE_F_SHARP  7
#define NOTE_G        8
#define NOTE_G_SHARP  9
#define NOTE_A        10
#define NOTE_A_SHARP  11
#define NOTE_B        12

#define NOTE_DO         1
#define NOTE_DO_DIESE   2
#define NOTE_RE         3
#define NOTE_RE_DIESE   4
#define NOTE_MI         5
#define NOTE_FA         6
#define NOTE_FA_DIESE   7
#define NOTE_SOL        8
#define NOTE_SOL_DIESE  9
#define NOTE_LA         10
#define NOTE_LA_DIESE   11
#define NOTE_SI         12
As usual, the OSDK is available on the download page at

As usual, please report any issue, changing things like the Linker or build script tend to have side effects for people who used different projects setups

Re: OSDK 1.15

Posted: Thu Sep 12, 2019 1:43 am
by retroric
Hi DBug, and thanks for this new OSDK version.

I can confirm my ElectrOric test programme compiles and executes fine in -O2 mode with OSDK 1.15, however there are still runtime bugs if I compile in -O3 mode (as was the case with the 1.14-patched version of the compiler which I believe you just carried over to v1.15).

I also confirm there are no more compile-time warnings with <sys/sound.h>, as all previously syntactically-incorrect #defines were corrected.

Unfortunately, I am unable to provide a small test case to narrow the source of bugs with -O3 mode at this time, I suspect there must be actually a number of issues with "optimized macros" that account for possibly different cases of runtime bugs.

Strangely enough though, I also tested OSDK 1.15 with LadyWasky's Oric Kong remake in C (see and while I expected similar runtime problems with -O3 compilation, the game actually runs flawlessly whether it is compiled in -O2 or -O3 mode.

There must be some difference between these two programmes that accounts for the bug. The only striking difference I see is my game runs in HIRES whereas LadyWasky's game runs in TEXT mode. But both games use functions, arrays, and char and int types, and my game doesn't actually use any HIRES ROM routine for drawing...

Have you (or anyone else for that matter) tested v1.15 with other "sizable" sample programmes and encountered runtime bugs in -O3 mode ?

Re: OSDK 1.15

Posted: Thu Sep 12, 2019 5:56 pm
by Dbug
The only sizable C programs are the ones you people are writing.
(My own programs only use C for the skeleton code, all the rest is in assembler)

The C compiler and the macros are mostly Fabrice work, not much I'm doing except building my windows version for the OSDK.

That being said, with what was discovered recently with Bocco's adventures code size, it would be worth investigating why the CC65 equivalent takes only half the size of whatever the compiler in the OSDK outputs.

When we checked the two compilers years ago, there was no such discrepancy, so either the CC65 guys found some genius optimization, or something has gone terribly wrong in ours compiler.

And yes, 1.15 is just the 1.14 with the patch I provided on the forum. (and the sound.h fix)

Re: OSDK 1.15

Posted: Fri Sep 13, 2019 10:17 am
by Chema
I am failing to help with this... I hardly use C with the Oric, as Dbug said. But I agree with him: it would be vital to understand that size difference before anything else, because it could be hiding something nasty. There is no use in making aggressive -O3 optimizations work if the generated code size is terribly high.

I also seem to recall there was a tiny difference between those compilers.

Re: OSDK 1.15

Posted: Sat Sep 14, 2019 2:17 pm
by retroric
Well, there are two concerns here:
1) there seems to be a bug (or bugs) with optimizing the macros output by the compiler in aggressive -O3 optimization mode, with changes introduced by Fabrice as of OSDK 1.14. This is the most serious issue.
2) More generally, it seems indeed there is room for optimization in the OSDK compiler compared to output generated by cc65 (at least in view of comparisons carried out with the "Bocco" game released recently)

These of course are completely different matters :)

Now, concerning the -O3 bug(s) in OSDK 1.14 and 1.15: I tested it with other little programs I made with the OSDK. Here are the (interesting) results:

- one of them compiles and works fine both in -O2 and in -O3 mode with OSDK 1.15 (

- with the second one (see , I have a compilation error in the generated .s file for the main.c source (*both* in -O2 and in -O3 mode, whereas it compiles fine with OSDK 1.13).

- with the third one (see enclosed ZIP, which is a cut-down version of, I have a crash to Oricutron monitor right at program start with PC=00E5. I tried to insert a "brk" at program start to debug, but it still crashes at PC=00E5 before even trying to run the first instruction in main()

I'm hoping these two cases of errors (compilation error and runtime error) can help identify bug(s) with OSDK 1.15. However it will require someone better skilled than myself, because I was unable to progress on any of these bugs (I even fail to see the syntax error in the generated "main.s" source file for the second sample...)