Clock Signal — an Oric emulator for macOS and Linux

Comments, problems, suggestions about Oric emulators (Euphoric, Mess, Amoric, etc...) it's the right place to ask. And don't hesitate to give your tips and tricks that help using these emulations in the best possible way on your favorite operating system.
User avatar
iss
Wing Commander
Posts: 1127
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by iss »

jbperin wrote:
Wed Jul 29, 2020 6:36 am
... I even tried to setup a microdisc.
It seams Microdisc + DSK is recently broken. Tried the 'standard' Sedoric 3.0 image. If I convert the same DSK to HFE it boots OK. Jasmin+DSK and BD-500+DSK work just fine.

ThomH
Flying Officer
Posts: 222
Joined: Thu Oct 13, 2016 9:55 pm

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by ThomH »

This I was unaware of; I'll stick my nose in tonight. Also, for the record, I switched my desktop to German (the only other language I can read any of) and had no problem running the emulator; I'll keep digging.

Other than the ongoing Qt stuff — I'm currently engaged in the Qt forums re: the audio issue — I've otherwise been looking at some longstanding issues in the video stack preparatory to the addition of Metal and possibly DirectX backends. I finally got a lead on the bug some might have seen where if video output is a bottleneck* then bits of the display can jump up and down vertically, so hopefully that'll be fixed soon, too.

* probably rare for most people, and most obviously a sign that I should write a more efficient GPU pipeline. It's just really hard working on GLSL without any sort of profiling or debugging tools. This is an area where adding platform-specific APIs like Metal in addition to OpenGL might end up being really valuable, for all targets.

EDIT: so it looks like I broke the Microdisc when I attempted to generalise my handling of ROMDIS and the overlay area so that it wasn't Microdisc specific. I'll probably push a fix this weekend, giving it a few days in order to see whether I can get the video output fix in as well.

EDIT2: those changes have been formally released via the two binary channels — Snapcraft for Linux and the GitHub page for macOS.

ThomH
Flying Officer
Posts: 222
Joined: Thu Oct 13, 2016 9:55 pm

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by ThomH »

A minor one to announce: the macOS version of Clock Signal now uses Apple Metal for video output rather than OpenGL. That's because Apple has deprecated OpenGL and therefore at some point it will become available. Apple has announced that it'll still initially be available on Apple Silicon Macs but I didn't spot that before I started the work. So I'm feeling pretty foolish now. But it's nice not to have any deprecated dependencies again.

The Metal version has some quality/speed improvements, which will be ported to OpenGL in the near future.

Otherwise, I've discovered a whole bunch of Vic-20 tests that demonstrate that some of the more obscure parts of my 6522 aren't working correctly — primarily, I've yet to chance upon exactly the proper way to handle PB7 toggling via timer 1 and many of the shift register modes aren't shifting at the correct rate. Clearly the shift register at least partially works since it's used for keyboard input on the Macintosh, but I guess there's work to be done there.

So a future update will likely improve emulation accuracy, albeit that I'm unaware of any titles that will be affected. If anybody knows anything that's currently broken, I'd love to know about it.

So, as always:
  • Mac binaries are at GitHub; and
  • Linux Qt binaries, if you don't want to build for yourself, are available via Snap.
As I've now marked the Snapcraft build as 'stable', you should also be able to find the emulator via the built-in application store on Ubuntu and related distributions. Search for 'Clock Signal' directly, or for e.g. 'Oric emulator' and it's currently the only thing that comes up. If anyone with Oricutron responsibility is reading this and is interested, I could try to assist in getting that listed too though I really only looked into proper YAML structure for qmake-based (i.e. Qt) builds. I'll bet regular make or cmake are even easier though.

ThomH
Flying Officer
Posts: 222
Joined: Thu Oct 13, 2016 9:55 pm

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by ThomH »

Super minor addendum:

The Mac version had some UI issues under Big Sur; these have been fixed. It's also now available as an Intel + Apple Silicon universal binary.

Slightly more technical discussion starts here:

Re: Big Sur, I'd unwittingly made a dodgy assumption with regard to the means by which a window with a sheet on top can be dismissed. Big Sur changes the sheets to look more like iOS modals, and whatever Apple changed in the implementation meant that I no longer got away with doing things incorrectly. So as a specific flaw: if you used File -> New... and then cancelled the new machine, when you came to shut the application you'd suddenly be presented stuck with a weird ghost window in which the buttons do nothing. This is no longer the case.

Naturally this error has no effect in Qt or SDL, so no fixes for those are required.

User avatar
iss
Wing Commander
Posts: 1127
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by iss »

Great! I like Clock Signal for it's unique features and the pro-level of its internals. Thanks!

User avatar
Chema
Game master
Posts: 2723
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by Chema »

I also like this emulator a lot... will there ever be a windows version :D ?

ThomH
Flying Officer
Posts: 222
Joined: Thu Oct 13, 2016 9:55 pm

Re: Clock Signal — an Oric emulator for macOS and Linux

Post by ThomH »

I don't know how pro-level I feel about the internals as I spend yet another day trying to conquer a relatively simple problem to do with the way the Apple IIgs does sort-of-NTSC-to-RGB conversion. Not to mention the continued lack of some relatively simple classic emulator functionality — save states being the most glaring. Albeit that I continue to edge closer on that one, it still being coupled to debugging.

Re: Windows, I have acquired a Windows 10 computer, installed Visual Studio on it, and discovered myself completely lost. I don't know what a modern Windows application looks like and I definitely don't know how the code should look. C++/WinRT seems like the best way in, but after spending the majority of this year on supporting Metal and the on supporting Qt I just couldn't bring myself to head straight into a third API so I chickened out and took the Apple IIgs detour.

That all being said, I expect Windows to be a lot easier than Qt was just because these platform abstractions never really do what you want whereas the actual platforms have a lot more depth to them.

I dare imagine I'm going to end up in the realm of DirectX if I want Mac-equivalent latency, but I don't think that's anything to be scared of. Prior to this year I knew no Metal whatsoever and, fine, it took a month or so but it worked out pretty well — a grand total of 1,802 lines, which is a fair trade to avoid whenever Apple puts up the next obstacle to OpenGL. Assuming DirectX actually ends up being a similar volume of work then it'll pay for itself pretty quickly.

So, anyway, it's on the radar, subject to competence.

Post Reply