Page 1 of 1

OSDK 1.19

Posted: Wed Aug 11, 2021 5:36 pm
by Dbug
This version 1.19 is mostly for testing for regressions and go forward in the future:

- All the binaries are now compiled with Visual Studio 2019 instead of 2010. This should make it easier to update in the future, but this may also have uncovered some bugs and behavior change, so beware and signal any regression

- Added a new environment variable, OSDKCPPFLAGS, which can be used to pass additional data to the C preprocessor (like additional defines)

- Upgraded Oricutron to the version 1.2.4

As usual, the OSDK is available on the download page at http://www.osdk.org/index.php?page=download but you can now also get it from OSDN.net at https://osdn.net/projects/oricsdk/

Re: OSDK 1.19

Posted: Wed Aug 11, 2021 6:51 pm
by jbperin
Dbug wrote:
Wed Aug 11, 2021 5:36 pm
This version 1.19 is mostly for testing for regressions and go forward in the future:

- Added a new environment variable, OSDKCPPFLAGS, which can be used to pass additional data to the C preprocessor (like additional defines)
Thank you for this new version :D

Re: OSDK 1.19

Posted: Thu Aug 12, 2021 5:34 pm
by coco.oric
Thanks for updating these tools

Re: OSDK 1.19

Posted: Thu Aug 12, 2021 7:08 pm
by ibisum
Thanks for the hard work on these tools, they keep getting better and better - and having an impact on Oric life, in significant ways ..

Re: OSDK 1.19

Posted: Fri Aug 13, 2021 7:44 am
by iss
Thanks @Dbug!

Some very minor details which I noticed:
- "back to the future" :) It's obvious bad date conversion 08.11 vs. 11.08 :
Screenshot_20210813_092215.jpg
- the 4x size of the bloated executables (compared to the previous OSDK 1.18) is probably related to statically linked MS VCR library which is grows with every new VC++ version. We have to live with that - the size does matter only for Oric :).

- for users who prefer to work with OSDK under Linux (@xahmol): TapTool and tap2cd are using the 'security' version of gets i.e. gets_s which is not available for GCC. The easy fix is to edit the .C/.CPP source adding somewhere at the top following work around:

Code: Select all

#define gets_s(x,y) gets(x)
I'm eager to see more developers for Oric with many new releases :).

Re: OSDK 1.19

Posted: Fri Aug 13, 2021 7:55 am
by Dbug
Good catch, fixed the time stamp.

Regarding gets_s, it's supposed to be C11 standard, but maybe I should have seen this part:
As with all bounds-checked functions, gets_s is only guaranteed to be available if __STDC_LIB_EXT1__ is defined by the implementation and if the user defines __STDC_WANT_LIB_EXT1__ to the integer constant 1 before including stdio.h.

Re: OSDK 1.19

Posted: Fri Aug 13, 2021 8:14 am
by iss
Dbug wrote:
Fri Aug 13, 2021 7:55 am
Regarding gets_s, it's supposed to be C11 standard...
It's supposed but it's actually not :(.

Code: Select all

#define __STDC_WANT_LIB_EXT1__ 1

#include <stdio.h>

static char buf[256];

int main(int argc, char* argv[])
{
  gets_s(buf, sizeof(buf));
  return 0;
}
Result:

Code: Select all

$ gcc -std=c11 -o test test.c
test.c: In function ‘main’:
test.c:10:3: warning: implicit declaration of function ‘gets_s’ [-Wimplicit-function-declaration]
   10 |   gets_s(buf, sizeof(buf));
      |   ^~~~~~
/usr/bin/ld: /tmp/ccBVAnL7.o: in function `main':
test.c:(.text+0x1f): undefined reference to `gets_s'
collect2: error: ld returned 1 exit status
To be correct It's more matter of implementation in glibc than GCC incompatibility. There is lot written about this (and other '_s' functions).
Anyway, what I've posted is just a simple workaround ;)...

Re: OSDK 1.19

Posted: Fri Aug 13, 2021 9:02 am
by Dbug
Is "gets" the only issue you found?

I guess an easy fix would to do like what I did for the rest of problematic functions: Wrap that in the "Common" library so we can easily have different implementations without having to touch the actual code of the tool.

Talking about libraries, since we are talking about Audio these days, so far the most interesting candidate I've found to support the loading of multiple audio format is http://sol.gfxile.net/soloud/index.html, mostly because it built out of the box, it does not have any complicated nonsense setup, it's not coming with any string attached, and the API is relatively clean and easy to use, and it can also replay sound (not just load).

So the idea would be to
- Add SoLoud in the shared libraries alongside FreeImage
- Rename SampleTweaker into "SoundConv" (or "AudioConv"?) to match "PictConv"
- Replace the hardcoded loading of raw file by SoLoud calls so we can load Wav, Ogg, MP3 or whatever else it supports
- Implement the existing algorithms as proper methods that can be selected by command line switches

and then add a few Samples with code matching the few encoding methods validated to work:
- 8 bit sample (the old "Welcome")
- 4 bit sample ("Nyan Cat" and "Oric Tech")
- 2 bit sample ("Rambo" from Tivoli Pirat)

Then from there we can extend if we find things that work fine.

Re: OSDK 1.19

Posted: Fri Aug 13, 2021 9:34 am
by iss
Dbug wrote:
Fri Aug 13, 2021 9:02 am
Is "gets" the only issue you found?
Yes, 'gets' is the only issue.

About soloud: It looks cool and useful. It compiles under Linux nicely: Let's Get "So"-Loud ... :D

Re: OSDK 1.19

Posted: Tue Aug 17, 2021 8:46 am
by jbperin
Dbug wrote:
Wed Aug 11, 2021 5:36 pm
- Upgraded Oricutron to the version 1.2.4
In this new oricutron, I can't find a way to type the symbol "_" (underscore) which is terribly frustrating when coming to debug with monitor.
I use a french (azerty) keyboard. It seems well recognized by Oricutron because when I press a "A" it's a "A" that is typed (and not a "Q")
But when I press the key "8", i get the "8" typed instead of "_" as it used to do in the oricutron of OSDK 1.16.

Did I miss something ?

Re: OSDK 1.19

Posted: Tue Aug 17, 2021 9:53 am
by Dbug
Probably worth signaling on the Oricutron thread.