Oricutron minimal specs

[Xeron]

Thanks for the pull request. ISS accepted it while I was still evaluating it. It's a good idea, but I didn't like the way it disabled F5 if you used it, so I changed it so you could specify what kind of statusbar mode you wanted from commandline or config file, without disabling F5.

[Xeron]

I had not realised that you were you!

Ahh, OK, yes it's me. I remember the very first time it booted to the BASIC prompt was on the train to work, for example

[iss]

I had not realised that you were you!

Ahh, OK, yes it's me. I remember the very first time it booted to the BASIC prompt was on the train to work, for example

So, Oricutron, Clock Signal, emul8D - three emulators for Oric, not bad ...

[Symoon]

So, Oricutron, Clock Signal, emul8D - three emulators for Oric, not bad ...

And of course 20th's century Euphoric, Amoric, and Atoric (not sure how evolved was the later one for Atari ST, it was a bit slow).
There was also GoOric for Android, byt IIRC it doesn't work fine anymore.

[ibisum]

Thanks for the pull request. ISS accepted it while I was still evaluating it. It's a good idea, but I didn't like the way it disabled F5 if you used it, so I changed it so you could specify what kind of statusbar mode you wanted from commandline or config file, without disabling F5.

No worries, was a quick fix to address Dbug's situation so thanks for the proper handling ..

[ThomH]

I had not realised that you were you!

Ahh, OK, yes it's me. I remember the very first time it booted to the BASIC prompt was on the train to work, for example

The very first emulator I ever wrote was of the ZX Spectrum (sorry!), in probably 1997 or 1998, since apparently the other 27,000 ZX Spectrum emulators released that year weren't sufficient for me. But, yes, that first appearance of (c) 1982 Sinclair Research is the same rush I've been chasing ever since.

[Dbug]

SDL(1.2) supports Win95 just fine. Read the Makefile.

If I try to get the SDL 1.2 I go to this page and I get this

SDL version 1.2.15 (historic)
SDL 1.2 has been superceded by SDL 2.0.
SDL 1.2 is no longer supported and no longer works on many modern systems, but the source code is available for historic purposes on GitHub

My objective is not have a version of Oricutron that only runs on old machine but to know how far back a new version of Oricutron build to follow the recommended setup is able to go back.

The current versions of Oricutron, are they built with SDL 1 or SDL2?

If I wanted to build my own version, which one should I get (and if it's SDL1 that means rebuilding SDL from sources since apparently the binaries are not available anymore?)

I'm generally happy to use the already made versions, but sometimes one need to build them if only to check some features, like apparently there was an attempt at implementing screenshots using the PRINT SCREEN key, but it does not work on my machine and I wanted to know why.

Code: Select all

        case SDLK_PRINT:
          sprintf( screencapname, "Capturing to screenshot%02d.bmp", screencapcount );
          screencapcount++;
          do_popup( oric, screencapname );
          SDL_COMPAT_TakeScreenshot( &screencapname[13] );
          break;

I wanted to try making this key possible to remap it to something else like F12 because it's the standard used for Steam games, and then have my launcher check for the presence of these files and then upload them to Steam as in-game screenshots so players can share them later on their profiles if they want

[ibisum]

If you want to build Oricutron in any kind of sane manner, you're going to have a bad time if you don't have the SDL sources locally. Sure, you can shoot for Win98 compatibiliity - but this is an ancient, even *retro* operating system now. You'd be better off putting your energy into getting Oricutron built for WebAssembly, imho ..

The current versions of Oricutron, are they built with SDL 1 or SDL2?

The 'official' releases are built with SDL2, I believe. But its quite possible to do an older build. I used SDL 1.2 for the OpenPandora port, before also getting it working in SDL2, years ago ..

If I wanted to build my own version, which one should I get (and if it's SDL1 that means rebuilding SDL from sources since apparently the binaries are not available anymore?)

Please don't try to build Oricutron for re-distribution without using the SDL sources to do so, no matter which version you try. Its just not worth the 'ease' of using someone elses pre-built libraries when indeed, SDL can be built locally from sources quite easily.

If you need help with this, I'm happy to join you for a live session/workshop.

I'm generally happy to use the already made versions, but sometimes one need to build them if only to check some features, like apparently there was an attempt at implementing screenshots using the PRINT SCREEN key, but it does not work on my machine and I wanted to know why.

I really think you'd be best served by just biting the bullet and building your own Oricutron from sources, and proceeding from that point.

Print-screen on Windows is wraught with issues, because it is also governed by security policies - does your local Windows user have permission to make screenshots? Remember, Windows - these days - has all sorts of granularity over things like this, because it is a security issue.

I wanted to try making this key possible to remap it to something else like F12 because it's the standard used for Steam games, and then have my launcher check for the presence of these files and then upload them to Steam as in-game screenshots so players can share them later on their profiles if they want

First, get Oricutron built locally with whichever SDL version you see fit. Then, try the print-screen thing again. Then, re-map it to F12 for your needs (and submit a PR if you fix print-screen for other Windows users along the way). And then, build for WebAssembly so we can just run Oric programs on the Web, and be done with it ...

[Dbug]

Please don't try to build Oricutron for re-distribution without using the SDL sources to do so, no matter which version you try. Its just not worth the 'ease' of using someone elses pre-built libraries when indeed, SDL can be built locally from sources quite easily.

What is the problem with using a pre-built binary from the official people who make the official version?
https://github.com/libsdl-org/SDL/relea ... ase-2.30.9

Give me a 100% rationale reason about why everything should be built from source code all the time, because as far as I'm concerned, life is getting shorter and shorter, and the fewer time I have to spent doing things that I can avoid to do, the better.

Not sure if you noticed, but I've not been doing much updates of Oriclopedia, or of the OSDK, or even participating on the forum: I don't have time, I'm struggling for time, and each time you tell me to look in the source or rebuild things myself, you are basically asking me to spend time on that instead of spending that time on things that are more important to me.

I spent time on doing LOCI testing because that was a worthy endeavor that benefits the entire community despite me not really having the time to do it.

I really think you'd be best served by just biting the bullet and building your own Oricutron from sources, and proceeding from that point.

Did I not ask which version of SDL to use? Obviously the whole point was that I was planning to rebuild the version.
So yes, it's what I said I wanted to do.

It's not that I can't rebuild Oricutron, I've done it many times (a while ago) when the SDL 2 version was not working on my sound card for example, and I stopped doing it when ISS started to publish regular builds for most of the platforms: If he has done it, why should I not use the work.

Regarding making things easier for developers, one thing I was searching for on the Oricutron github was a quickstart on how to build the project for the various platforms, I did not find one but maybe there is one but it's not linked anywhere?

Print-screen on Windows is wraught with issues, because it is also governed by security policies - does your local Windows user have permission to make screenshots? Remember, Windows - these days - has all sorts of granularity over things like this, because it is a security issue.

I never said I implemented it, I said that apparently there had been an attempt, it's in the actual codebase of Oricutron.

[ibisum]

What is the problem with using a pre-built binary from the official people who make the official version?

Calm down, I was just under the impression you needed to distribute your own version because you had customizations you wanted to do for the Steam store. There is nothing wrong with distributing 'official' binaries - but if you want to change the screenshot feature, for example, you can't do that without modifying the sources.

Unless you were suggesting someone else make this mod, and fix the screenshot issue for you?

And honestly, its about 30 minutes of work to get Oricutron built from sources, including SDL sources, and it just shouldn't take you that much energy or effort. As you have noticed, its a very easy-to-build project.

Regarding making things easier for developers, one thing I was searching for on the Oricutron github was a quickstart on how to build the project for the various platforms, I did not find one but maybe there is one but it's not linked anywhere?

I don't think there is a Quickstart guide for building Oricutron, but its probably a good idea for one of us to write it, or any of us, indeed.

EDIT: There are already Github Actions that can be used to build it! Checking that out now ..

[iss]

Oricutron can be build with both 1.x and 2.x SDL versions.
I'm using Makefile based build.
For SDL 1.x (SDL 1.2.15 is the last version and it's forever):

Code: Select all

make PLATFORM=win32-gcc SDL_LIB=sdl

for SDL 2.x:

Code: Select all

make PLATFORM=win32-gcc SDL_LIB=sdl2

(for 64 bit target change 32->64).

You can check the 'msvc' directory for VS-project and cmd build files.
I don't know if should be there something specific to be changed for '95 or '98 build...

[ibisum]

Okay, seems that @snowflake has kindly set up the Github Action workflows for us already, 3 years ago, which is super nice, but it doesn't have a 'save artifacts' step in the workflow - I assume because these actions are just to verify the build and not produce a real executable (I'm guessing those are done locally?) These Github Actions can be used to produce a working .exe without requiring you to do anything at all, locally!

To make this work I've modified the Github workflow *on my own fork* to see how to save the resulting .exe, so - if you want to try this out yourself, **fork** the pete-gordon repo to your own github account, then run the Action by cloning the repo locally, touching a file (say main.c), pushing that change to your own fork of the repo, and then checking the Action tab .. after a few minutes, you can see the build logs for the Workflows, and at the bottom of a completed (successful) Run, there is a link to 'download Artefacts' - this will contain the binary that Github has built for you, to try out.

You can see an example build run here:

https://github.com/seclorum/oricutron/a ... 2951757507

Click the "Upload Build Artefacts" section, and then follow the log message to get a link to the .zip file containing the build...

Or if you just want to go straight to the .zip file, look for 'build-artefacts' at the end of this link:

https://github.com/seclorum/oricutron/a ... 1826236754

Note - SDL1-Win64 build is also here:

https://github.com/seclorum/oricutron/a ... 1826236756

Note that if you want to do your own builds this way, you must add the following to your own .github/workflows/* files, if you want to keep the results of a Build this way:

Code: Select all

    - name: Upload Build Artifacts
      uses: actions/upload-artifact@v3
      with:
        name: build-artifacts
        path: ${{github.workspace}}/build

.. or you could just fork from my repo, which has these changes already. I'll submit a PR for this to go back to pete-gordon some time soon, after I convert things to a matrix build so that all support platforms are built ..