OSDK feature request - add OSDKMACHINE env variable to set target machine for execution

Questions, bug reports, features requests, ... about the Oric Software Development Kit. Please indicate clearly in the title the related element (OSDK for generic questions, PictConv, FilePack, XA, Euphoric, etc...) to make it easy to locate messages.

Post Reply
User avatar
retroric
Pilot Officer
Posts: 77
Joined: Sun Nov 22, 2009 4:33 pm
Location: Paris, France

OSDK feature request - add OSDKMACHINE env variable to set target machine for execution

Post by retroric » Fri Feb 01, 2019 3:39 pm

Hi,

When launching a program made with OSDK on Oricutron, the emulator is launched in default (e.g. Atmos) mode.

Strangely, the OSDK\Oricutron\osdk_oricutron.bat file does mention the possibility of "ROM choice / Machine choice", but is currently not implemented (by the way, the comment mentions Euphoric, must be a left-over from a copy & paste...):

Code: Select all

::
:: Then we create the correct Euphoric command line call
:: depending of parameters we have:
:: - Rom choice
:: - Machine choice
::
SET OSDKORICUTRON=oricutron.exe
However, I found that by just adding this single line after the SET OSDKORICUTRON=oricutron.exe line, you could very easily allow for specifying the target machine for execution:

Code: Select all

IF NOT "%OSDKMACHINE%"=="" SET OSDKORICUTRON=%OSDKORICUTRON% -m %OSDKMACHINE%
With this small modification, you can then define for instance "SET OSDKMACHINE=oric1" in your OSDK project's osdk_config.bat file, so the osdk_execute.bat file will run the program in Oricutron's Oric 1 mode.

Of course, a similar modification must be done if using Euphoric as the target emulator (I haven't had a look at this to be honest).

Finally, to be really useful, there needs to be real Oric 1 compatibility in the OSDK, which is unfortunately not the case currently (as far as the standard libs are concerned, apparently even printf() doesn't work, it crashes Oricutron...)

However, I am currently looking at a way to quite easily add Oric1/Atmos compatibility for some of the libraries calling ROM routines, I'll be telling you more very soon, I already have a working "proof of concept", as they say !! :D

Cheers,
Laurent
Last edited by retroric on Fri Feb 01, 2019 8:27 pm, edited 1 time in total.
flag_fr RetrOric, aka laurentd75 flag_uk
            GitHub - RetrOric

User avatar
Dbug
Site Admin
Posts: 2900
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: OSDK feature request - add OSDKMACHINE env variable to set target machine for execution

Post by Dbug » Fri Feb 01, 2019 5:47 pm

I added issues #30 and #31 on the OSDK page:
http://www.osdk.org/index.php?page=issues

It's a well known issue, been discussed with Jede when he was working on his Orix Telestrat project.

Basically, there are multiple approaches, they all take time, and they all have drawbacks:

- Compile time selection of the targets: Your program will be able to compile for Oric ATMOS, or for Oric 1, or for Telestrat, but you will not be able to have the same executable working on all platforms (there will be one executable for each platform). Easy for ROM 1.0 and 1.1, Telestrat ROM is vastly different...

- Run time selection: When we run the program we check if we have an Oric 1 or Oric Atmos ROM, and based on that we use some jump table or patched vectors to use the right set of addresses. The main issue there is that it adds some code and data you would not normally need, but technically it's probably possible to patch the code and then use the patching data as normal memory - not easy to do -

- Reimplement all the functions natively: This way we are sure it runs the same on all the platforms, but it also means that we don't benefit in having a ROM, so we lose potentially a lot of memory.

- Other suggestion: ----

Discuss :)

User avatar
retroric
Pilot Officer
Posts: 77
Joined: Sun Nov 22, 2009 4:33 pm
Location: Paris, France

Re: OSDK feature request - add OSDKMACHINE env variable to set target machine for execution

Post by retroric » Fri Feb 01, 2019 8:24 pm

Thanks for creating the issues on the issue tracking system DBug.

Regarding the second issue (Oric 1 compatibility of OSDK C libraries), I'm taking the "Run time selection" route. I'll create a new topic as soon as I have something working for some of the libraries (I have an easy and hopefully small-sized implementation solution that should cater for most functions calling ROM routines, such as those in <sys/graphics.h> implemented in graphics.s, grsimple.s, and ggeneral.s, I now need to have a look at <stdio.h> and <stdlib.h> function implementations).

PS - I am only considering Oric1/Atmos compatibility. As you said, the Telestrat ROM is vastly different so I think it would be easier to have a completely different set of libraries for the Telestrat... And to be honest I can't be bothered, I don't have a Telestrat and never was too keen on this machine anyway... I'd rather spend some time hacking with the NES/65816-based Super Oric!! :D
flag_fr RetrOric, aka laurentd75 flag_uk
            GitHub - RetrOric

Post Reply