Batocera now includes Oric emulation

[ThomH]

Batocera is "a retro-gaming focused OS, first and foremost"; specifically it is a Linux distribution that boots to EmulationStation, a media-centre-style big-screen interface for browsing and playing all manner of retro-gaming systems, for which Batocera includes suitable preconfigured emulators and is optimised for installation on a USB stick or SD card.

So e.g. it sees a lot of plug-and-play use with nano computers, Steam Decks and the like, though you can use it with any PC.

As per the title it now includes Oric emulation.

I'm in the loop about this because it's my emulator, Clock Signal, underneath, but I did none of the integration work and I don't think the specific emulator has any real ramifications. So I thought it might be of interest as a plug-and-play solution.

[iss]

Batocera ...

Very interesting and worth to try!

@ThomH: off-topic: I wanted to ask you about CLK - do you have any rough data how fast can run CLK Oric emulator?
I mean running without any synchronization with host's refresh rate. Of course it depend on how powerful the host machine is but for something average what can one expect like equvalent of 2 .. 4 .. 8 MHz or more?
I'm asking because after upgrade to latest Linux Fedora 43 (from 41) I noticed incredible performance degradation of my emulator (SDL3 based) - like it was easy 10x speed now it barely reach 1.1x on the same machine and I'm searching what can be the issue...

[Chema]

This is great news!!!

[ThomH]

@ThomH: off-topic: I wanted to ask you about CLK - do you have any rough data how fast can run CLK Oric emulator?
I mean running without any synchronization with host's refresh rate. Of course it depend on how powerful the host machine is but for something average what can one expect like equvalent of 2 .. 4 .. 8 MHz or more?

I apologise that I haven't a clue, but would it expect it be a poor performer compared to other emulators for a bunch of reasons. And a lot of the bottleneck is video and audio output, so it strongly depends on whether you're pumping up the processor while leaving the ULA at its original speed (so as not to add any extra burden for output) or accelerating the whole machine.

Like, comparatively, on my current laptop my emulator occupies about 25% of a core to run an Oric. But if I instead run a BBC Micro with a second processor, so that's a 2Mhz 6502 plus a 3Mhz 65C02, plus all the branch-prediction losses that come from the lower predictability of a CRTC, that goes up to only 37%. And despite what the 25% seems to imply, I had to launch seven separate simultaneous Orics to get to 101% utilisation, i.e. to exceed what could be scheduled on a single core.

My OpenGL stuff is also definitely in need of work. Both as to quality of output and in terms of performance; the Mac-specific Metal stuff looks much better and does a better job of giving the GPU leeway efficiently to schedule. Though only because it's effectively the second version of the OpenGL stuff, having been written later, not for any objective reason. But on a CPU with embedded graphics I wouldn't be surprised if that subtracted from overall system performance.

I've also yet to move to SDL 3 so I can't speak about that at all.

[ThomH]

Bonus: I've found this Youtube video from the Batocera team showing it in action. Just for a brief glance though.

[Dbug]

I see that Encounter is in the list of Oric games.

image_2026-01-07_083305454.png

Are the games distributed with Batocera, or do people need to provide the games? Since the game is commercial that's technically piracy if it's provided with Batocera - except if it's the demo version.

I provided the game for free on Oric.org for the Oric community, but I'd rather not have it added to big projects like that without being asked, and without the description indicating that the game is for sale.

[Chema]

Yeah. The case of Encounter is clear. Regarding my games, I put in the README files that they can be distributed freely provided all the files (including instructions) are included too. Not sure if that is the case, or if they peovide some kind of links in the game descriptions (which seem copied from the websites) but contacting us would've been nice.

[Dbug]

If we look at 1337, we can see the description is copied from the Defence Force website (that's fine).

image_2026-01-07_090218739.png

But I suspect that the three "Unknown" and the US flag mean that there's a lot of metadata that was not filled, like which country the game is from, who is the publisher (technically "Defence Force") who is the author, the release date, etc...

Basically that the thing I was complaining many years ago about one of the big Oric game collection (forgot the name) that was just a huge data dump with missing documentation, incomplete metadata, etc...

I don't think anyone here is against having their games easily available/playable, but the counter-part of that is these games took a long time to be done, so the least that can be done is to have all this data correct and consistent, and it's particularly easy with Oric.org having all the data collected in one easy place in a standard format (not that Oric.org is 100% correct/complete, but you can't be blamed for using data from Oric.org if the source itself is incorrect).

[ThomH]

Are the games distributed with Batocera, or do people need to provide the games? Since the game is commercial that's technically piracy if it's provided with Batocera - except if it's the demo version.

To hit the point again: I'm not a part of the Batocera team, I can't speak for them, etc, etc, I just happen to have found out about this a little earlier than the rest and have heard of the project before. So the following may or may not be accurate...

Batocera doesn't come with commercial software and states directly on its front page that "... you must own the games you play in order to comply with the law". But I do not know whether the other metadata issues discussed in this thread might have led to some titles being misclassified. It's a ~4gb download, at least in the Steam Deck version, so I'm downloading it to poke around the archive but won't be able to comment further on that until after the work day.

On the metadata issue: via its EmulationStation repository all I can find is reference to in the context of Orics is HFS DB scraping but that DB has only 15 titles in it, not including either of those mentioned here.

The only places on the internet that I can find the exact text "1337 is the game you have been waiting for !" are here and on itch.io so that's still a mystery to be solved.

[iss]

@ThomH: off-topic: I wanted to ask you about CLK - do you have any rough data how fast can run CLK Oric emulator?
I mean running without any synchronization with host's refresh rate. Of course it depend on how powerful the host machine is but for something average what can one expect like equvalent of 2 .. 4 .. 8 MHz or more?

I apologise that I haven't a clue, but would it expect it be a poor performer compared to other emulators for a bunch of reasons. And a lot of the bottleneck is video and audio output, so it strongly depends on whether you're pumping up the processor while leaving the ULA at its original speed (so as not to add any extra burden for output) or accelerating the whole machine.

@ThomH: Thanks for the replay .
I found the problem and now everything works fine!
For some unknown reason (probably deep debugging) I've turned compiler optimizations off (i.e. gcc -O0), now back to -O2 and -O3 and have an equivalent of Oric running fine at 16MHz and host is CPU ~90%.
I didn't expect now days to have such big difference in performance related to optimizations flags...
Off-topic closed.

[ibisum]

I don't think anyone here is against having their games easily available/playable, but the counter-part of that is these games took a long time to be done, so the least that can be done is to have all this data correct and consistent, and it's particularly easy with Oric.org having all the data collected in one easy place in a standard format (not that Oric.org is 100% correct/complete, but you can't be blamed for using data from Oric.org if the source itself is incorrect).

Yes, all very agreeable imho.

There is one very simple thing that oric.org can do to make this whole issue rather a bit more tasteful to those of us who wish attribution to be properly represented - and that is, simply add the Oric emulator to the oric.org interface.

This way, people don’t actually need to download Yet Another App™ to get their Oric experience, they can just intrinsically come to oric.org.

I mean, turnabout is fair play - if these Batocera app developers are going to harvest the data from our community tools, we can just turn the tools into apps which make the app developers unnecessary.

Putting oric.games into oric.org should be, imho, kind of the next obvious step. But I don’t know the admins of oric.org and probably should stop making work for people who don’t want it. (Although, think about it guys, having oric.games emulator working in oric.org is a *no-brainer* and worth the effort…)