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.

Re: OSDK 1.19

Posted: Tue Apr 19, 2022 9:08 am
by jbperin
I don't know if it worths mentioning but in OSDK documentation, at page https://osdk.org/index.php?page=documen ... ng_project, there's a section describing possible environment variables of interest
The OSDK also support some other variables, here they are for exaustivity:
And there's no mention of the variable

Code: Select all

OSDKCPPFLAGS
which was introduced in the 1.19 release.

Re: OSDK 1.19

Posted: Tue Apr 19, 2022 4:21 pm
by Dbug
Good catch, it's fixed.

Re: OSDK 1.19

Posted: Tue Aug 16, 2022 7:21 am
by Symoon
Ok this is my first try of the OSDK, wanted to report a few (old or recent) problems:
- the old version 1.9 (1.09 it should have been :wink: ) I had installed long ago doesn't like spaces in the path - it was installed on my desk, so in "Documents and settings" folder.
- So I switched to the latest 1.19, under Windows XP, installed it elsewhere, changed the PATH, and got:
osdk_error.png
Reading this:
Dbug wrote: Wed Aug 11, 2021 5:36 pm - 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
I wonder if this couldn't explain that?
Or has (now old) XP support been dropped?
Thanks!

Re: OSDK 1.19

Posted: Tue Aug 16, 2022 9:45 am
by Dbug
Crap, the XP issue was not done on purpose :-/

https://docs.microsoft.com/en-us/cpp/bu ... w=msvc-170

Apparently the last version of Visual Studio to support XP is VS2017, but fortunately it's possible to install the SDK for it and use it from VS2019.

Regarding the version numbers, I've stopped using plenty of zeroes everywhere, so 1.9 is before 1.10 which is before 1.19
Regarding spaces, I should probably mention it in the documentation, but basically spaces in folders causes way too many problems and life is too short to spend time fixing that. Sorry :)

Re: OSDK 1.19

Posted: Tue Aug 16, 2022 11:49 am
by xahmol
Am I again the one to point out that running Windows XP in 2022 is really not a good idea, unless you completely isolate it from anything on the rest of your network (and even then)?

If your PC is really that old that it does not run Windows 10 (must be old then, because even my 2011 PC is running Windows 10 fine), run Linux. Elsewhere in this forum is a thread on how to use OSDK under Linux.

There is a reason Microsoft dropped support on XP…..

Re: OSDK 1.19

Posted: Tue Aug 16, 2022 1:04 pm
by Dbug
The main reason for keeping a Windows 9x/XP was to get a machine able to run WriteDSK to generate physical floppies, but that was before Cumulus, Cumana Reborn, HxC or Greaseweazle.

Re: OSDK 1.19

Posted: Tue Aug 16, 2022 2:12 pm
by Symoon
xahmol wrote: Tue Aug 16, 2022 11:49 am Am I again the one to point out that running Windows XP in 2022 is really not a good idea, unless you completely isolate it from anything on the rest of your network (and even then)?
The way I see computing, is that tools are here to serve us, we're not here to serve tools. In this regard, until there is no other solution, I won't spend hours or weekends setting up tools in order to... Do the same (or less) things I'm doing now.

My XP computer is a small Asus Eeepc laptop I've been using for retro things since about 2010. Most importantly, it's also my Oric "tape" (wav) player since it has jacks input/output, which modern small laptops don't have anymore (probably for marketing/design matters). As a bonus, it still runs Euphoric natively => double-clic a TAP or DSK file, it runs with the emultaor. Love it!
Would modern laptops allow this, I would probably have changed since then. They don't. Although painful, I could live with Euphoric under DosBox, but not with extra hardware monopolizing an USB port and extra room, to have audio jacks which I'm constantly using.

I understand at some point XP support will be dropped (since we're not here to serve tools, coders included), but I really have no need/time for Linux right now. Maybe if I was retired, but so far I have other goals in life and need to sleep at night ;)

Re: OSDK 1.19

Posted: Tue Aug 16, 2022 4:01 pm
by xahmol
You do not need to do it for me, but an XP is that vulnerable that it can literally infect everything connected to the same network in seconds. Hence the ‘only use if isolated’ part. And you honestly can not blame Microsoft for not securing such an old OS to all new modern threats.
Things were much simpler in the 8 bits days…. No security to worry about.
(And will stop now. Sorry, telling people they really should not use Windows XP, or also Windows 8 for that matter, is my daytime job)