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.
ThomH
Flying Officer
Posts: 144
Joined: Thu Oct 13, 2016 9:55 pm

Re: Yet Another

Post by ThomH » Fri Nov 24, 2017 1:35 am

iss wrote:
Thu Nov 23, 2017 11:59 pm
Cool! ... and it works! :)
Nice RGB and composite emulation.
All my DSK images are running fine, but I found that original Blake's 7 (v1.1 - English) fails to boot, there is error after each sector was read: CRC error; terminating Maybe the problem is in the image (Chema?).
The error appears to be the image: there's sufficiently many out there with incorrect CRCs that I think Oricutron declines to check them (?). A quick run through my DSK CRC fixer reports 2720 CRCs checked, 952 fixed. A correct DSK image is attached.
iss wrote:
Thu Nov 23, 2017 11:59 pm
One wish from me: I want to have HFE with Oric too ;).
Oh, sure. I didn't realise it was applicable. I'll see what my options are. I like to add things only so as not to increase complexity, so I will need to add some logic to distinguish an Oric image from other kinds of image. I admit that with the Oric DSK being platform specific I've not had to look at that at all really.

The situation is quite different for tapes: the emulator allows CSWs to be mapped to any supported platform by content inspection, and if it's launching an Oric then it decides between BASIC 1.0 and 1.1 through disassembly.
iss wrote:
Thu Nov 23, 2017 11:59 pm
EDIT: for Linux build 'scons' is required too.
Yes, true. Apologies for failure to mention that.
Attachments
B7en-1.1.dsk.zip
(211.76 KiB) Downloaded 68 times

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

Re: Yet Another (EDIT: now also for Linux)

Post by Dbug » Fri Nov 24, 2017 7:37 pm

I guess I forgot to implement the CRC fix in the FloppyBuilder.
I could probably use your tool to validate that the result works :)

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

Re: Yet Another

Post by ThomH » Fri Mar 23, 2018 3:10 am

iss wrote:
Thu Nov 23, 2017 11:59 pm
One wish from me: I want to have HFE with Oric too ;).
Your wish is my command. The newest release attempts to support HFE images of Oric disks. If you have any testing material or any feedback, let me know!

User avatar
iss
Squad Leader
Posts: 620
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

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

Post by iss » Fri Mar 23, 2018 9:23 pm

Thanks for taking my wish so serious :).
I checked the latest release (MacOS High Sierra 10.13.3). It works fine with DSK images.
I like especially 'Options' and the way to quick switch RGB/Composite.
Screen Shot 2018-03-23 at 21.53.44.jpg
But none of my HFE images are working. :( I use the command line tool to convert DSK to HFE.
Can you attach any HFE which works for you to test?
About CLK for Linux - build from current git sources fails with 3 problems:
- I have to add ../../ClockReceiver to include path
- StaticAnalyser.cpp - memcmp wants #include <string.h>
- MultiJoystickMachine.cpp - std::find wants #include <algorithm>
But more important is that when I start ./clksignal it breaks my Window Manager i.e. all open windows lose their title bars, frames, buttons etc.
I follow your work closely, may be I should start reporting on github...

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

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

Post by ThomH » Fri Mar 23, 2018 9:41 pm

iss wrote:
Fri Mar 23, 2018 9:23 pm
Thanks for taking my wish so serious :).
I checked the latest release (MacOS High Sierra 10.13.3). It works fine with DSK images.
...
But none of my HFE images are working. :( I use the command line tool to convert DSK to HFE.
Can you attach any HFE which works for you to test?
I didn't have any Oric HFE files so I cheated and used the Nibble sector editor to inspect a CPC HFE (by drag and drop onto a running Oric). If you can attach a non-working one that could be helpful, otherwise I'll endeavour to do a proper test. This stuff is just supposed to work; I guess I was over-confident.
iss wrote:
Fri Mar 23, 2018 9:23 pm
I like especially 'Options' and the way to quick switch RGB/Composite.
The SDL kiosk mode, which is currently the Linux port, is as much about forcing an extra build target into things so that I don't inadvertently throw portability to the wind as anything else. I also want to do a Qt or GTK wrapper too at some point, to provide proper menus to X11 users. And hopefully a win32 wrapper at some point. Android is the most-requested additional platform though, so I'm looking at transitioning to that via an unreleasable iOS port.
iss wrote:
Fri Mar 23, 2018 9:23 pm
About CLK for Linux - build from current git sources fails with 3 problems:
- I have to add ../../ClockReceiver to include path
- StaticAnalyser.cpp - memcmp wants #include <string.h>
- MultiJoystickMachine.cpp - std::find wants #include <algorithm>
Grrr, I'm an idiot. I've been running Linux through virtualisation to test builds, but that Mac is temporarily unavailable to me. So I attempted to validate manually, but obviously failed.
iss wrote:
Fri Mar 23, 2018 9:23 pm
But more important is that when I start ./clksignal it breaks my Window Manager i.e. all open windows lose their title bars, frames, buttons etc.
It's just a standard SDL+OpenGL program, making no attempt to manage windows itself, so that outcome confuses me greatly. I assume this does not happen with other OpenGL programs? I'm using the Core Profile (i.e. OpenGL 3.2+) supposing that might affect anything.
iss wrote:
Fri Mar 23, 2018 9:23 pm
I follow your work closely, may be I should start reporting on github...
I have definitely hit an inflection point where other bugs are starting to appear on Github, and it definitely helps as to visibility. I'm in a consolidation phase right now as the dynamic analyser* is allowing me to rethink some assumptions, so it's a perfect time for bug reports. I'll transcribe the comments above into bug reports.

There's also a crashing bug currently filed related to Vic-20 disk images, and both build and crashing bugs cross my comfort threshold so expect the building issue to be fixed very promptly. Especially as you've already done the work for me!

* doesn't affect the Oric. But, essentially, nowadays if you insert a piece of media for which the correct machine or hardware configuration cannot be determined a priori, the proper machine and configuration will be found empirically. E.g. if you provide a 16kb file with a .bin extension and the emulator can't figure out whether it's meant to be a ColecoVision or an Atari 2600 game, it'll just simultaneously try both with some light instrumentation and show the user whichever seems to be the more likely outcome until the case is so overwhelming that it can drop the improper guess. Which usually happens really quickly.

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

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

Post by ThomH » Fri Mar 23, 2018 11:50 pm

Quick update! I've uploaded a new release. Of the issues listed it corrects:
  • include paths for the SDL target; and
  • HFE support.
The latter tested with the conversion of 1337 attached.
Attachments
1337.hfe.zip
(113.03 KiB) Downloaded 34 times

User avatar
iss
Squad Leader
Posts: 620
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

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

Post by iss » Sat Mar 24, 2018 12:32 am

Cool! It works with HFE.
I've changed the XRander to OpenGL 3.1 and no more problems with the window manager.

User avatar
Chema
Game master
Posts: 2247
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 » Sat Mar 24, 2018 11:28 am

This is looking better and better! I don't have a Linux box around, but I will try to get a virtual machine working just to try this!

Impressive work! Thanks indeed.

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

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

Post by ThomH » Wed May 16, 2018 2:53 am

I've released a new version to GitHub.

Most interesting features:
  • Pravetz 8DOS support (read-only at present);
  • text pasting is unbroken for the Mac port; and
  • text pasting is faster and more accurate on both the Mac and SDL.
For 8DOS, DSK or WOZ files are supported. NIBs are also implemented but I'm not confident about them yet.



To offer some quick exposition on what's going on at the start of that video: memory is initially filled with random values. In this case, one of those triggers 60Hz mode. My emulated CRT is configured for a 50Hz input. So it fails properly to synchronise to the vertical sync. Hence the image rolling. Once the machine clears its video memory and ensures it is in 50Hz mode you can see that the image stabilises. There's a bit of a bounce because such is the manner of the PLL in use, a flywheel sync.

It's not supposed to be a TV warming up graphical effect or anything, it's just a direct consequence of the manner in which I emulate the components.
Last edited by ThomH on Wed May 16, 2018 4:10 pm, edited 1 time in total.

User avatar
NekoNoNiaow
Pilot Officer
Posts: 108
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

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

Post by NekoNoNiaow » Wed May 16, 2018 5:52 am

ThomH wrote:
Fri Mar 23, 2018 9:41 pm
* doesn't affect the Oric. But, essentially, nowadays if you insert a piece of media for which the correct machine or hardware configuration cannot be determined a priori, the proper machine and configuration will be found empirically. E.g. if you provide a 16kb file with a .bin extension and the emulator can't figure out whether it's meant to be a ColecoVision or an Atari 2600 game, it'll just simultaneously try both with some light instrumentation and show the user whichever seems to be the more likely outcome until the case is so overwhelming that it can drop the improper guess. Which usually happens really quickly.
Interesting, I have been designing a similar idea for an Amiga emulator project of mine.

One of the main annoyances regarding Amiga emulators is that there are so many different configurations that it can be difficult for users to know exactly which game works with which configuration.

My intuition is that it should be feasible to start the emulation with a standard configuration and let it run until it crashes (or reaches a state which can be detected as failure) then branch the emulation into a number of different paths depending on the nature of the failure:
change the CPU if an instruction of another model was encountered, if the CPU crashes while executing ROM code, try switching the ROM version, if the display is not consistent, change the chipset, if memory limits are reached, increase the available memory, etc...

Once the game/program is assessed to be working correctly, the emulator would associate the corresponding media (disk image) with the proper configuration so it can reuse it immediately the next time the game is launched.

User avatar
iss
Squad Leader
Posts: 620
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

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

Post by iss » Wed May 16, 2018 7:45 am

Great work, ThomH!
I'm deeply impressed by your DISK][ emulation (for both - Apple][ and 8DOS).
It helped me already to rescue (partially, because of really bad floppy disks :cry:) some antique software and now I can "close the case" which waited ~15 years :). Thanks!
I'm waiting for some "developer extras" like debugger ;) , but it's not an urgency of course.

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

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

Post by ThomH » Wed May 16, 2018 2:43 pm

NekoNoNiaow wrote:
Wed May 16, 2018 5:52 am
ThomH wrote:
Fri Mar 23, 2018 9:41 pm
* doesn't affect the Oric. But, essentially, nowadays if you insert a piece of media for which the correct machine or hardware configuration cannot be determined a priori, the proper machine and configuration will be found empirically. E.g. if you provide a 16kb file with a .bin extension and the emulator can't figure out whether it's meant to be a ColecoVision or an Atari 2600 game, it'll just simultaneously try both with some light instrumentation and show the user whichever seems to be the more likely outcome until the case is so overwhelming that it can drop the improper guess. Which usually happens really quickly.
Interesting, I have been designing a similar idea for an Amiga emulator project of mine.

One of the main annoyances regarding Amiga emulators is that there are so many different configurations that it can be difficult for users to know exactly which game works with which configuration.

My intuition is that it should be feasible to start the emulation with a standard configuration and let it run until it crashes (or reaches a state which can be detected as failure) then branch the emulation into a number of different paths depending on the nature of the failure:
change the CPU if an instruction of another model was encountered, if the CPU crashes while executing ROM code, try switching the ROM version, if the display is not consistent, change the chipset, if memory limits are reached, increase the available memory, etc...

Once the game/program is assessed to be working correctly, the emulator would associate the corresponding media (disk image) with the proper configuration so it can reuse it immediately the next time the game is launched.
This is nowhere near that advanced. The sole original consumer was the MSX. The issue there is cartridge images. There are a bunch of incompatible ways to implement paging on a cartridge but the method for preserving MSX cartridge is conventionally to make an image of the ROM chips and then leave the user or tool to guess at the paging hardware.

I already have a static disassembler that's used to try to ease some of these issues — e.g. for the Oric a disassembly is used to decide whether to boot as BASIC 1.0 or 1.1 when loading a tape. Try File->Open... on either version of Stormlord, both should just work. But it isn't sufficient for this purpose, primarily because it's also a RAM-based machine. One title, Toobin', is the worst possible case: it was originally a tape title, converted to cartridge. So the full extent of code that is obvious to the disassembler is (i) copy a bunch of data from the first page of the cartridge into RAM; (ii) jump into RAM.

So then I briefly considered a disassembler that performs some dynamic execution but thought I'd just reuse the part of the code that already does the dynamic execution.

So if it thinks there are four potential paging schemes that might be in use, it just spawns four MSXs, one running each option, and switches horse as and when the evidence comes in. It will selectively terminate them if they become very obviously the wrong option.

It's very brute-force, and computation costs in principle grow exponentially with the number of unknown selections — supposing it were four potential paging schemes plus, separately, absence or presence of a disk drive (or something), that'd be eight MSXs to run simultaneously. Etc.

The advantage is that the logic sits almost entirely outside of the emulation core, other than it having to tweak a probability of correctness upon certain events. Embracing dynamic selection at the core, presumably being able to spot potential divergence points, snapshot the machine and then make a guess, and regress if the wrong guess was made, would be a much smarter thing than I am doing.
iss wrote:
Wed May 16, 2018 7:45 am
[ emulation (for both - Apple][ and 8DOS).
It helped me already to rescue (partially, because of really bad floppy disks :cry:) some antique software and now I can "close the case" which waited ~15 years :). Thanks!
I'm waiting for some "developer extras" like debugger ;) , but it's not an urgency of course.
Alas a debugger is not currently on the schedule. Which is probably absurd if you think about the strong intersection between people still using emulators of '80s machines and people producing content for '80s machines but I've yet to think of a good way to do it well. And it'd probably never be in the SDL version. But I still want to add a Qt or GTK back-end for Linux types that want a full real application out of their emulators rather than just a discreet thing that runs a DSK but doesn't otherwise announce itself.

User avatar
NekoNoNiaow
Pilot Officer
Posts: 108
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

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

Post by NekoNoNiaow » Thu May 17, 2018 4:27 am

ThomH wrote:
Wed May 16, 2018 2:43 pm
It's very brute-force, and computation costs in principle grow exponentially with the number of unknown selections — supposing it were four potential paging schemes plus, separately, absence or presence of a disk drive (or something), that'd be eight MSXs to run simultaneously. Etc.

The advantage is that the logic sits almost entirely outside of the emulation core, other than it having to tweak a probability of correctness upon certain events. Embracing dynamic selection at the core, presumably being able to spot potential divergence points, snapshot the machine and then make a guess, and regress if the wrong guess was made, would be a much smarter thing than I am doing.
I think it is a really neat idea, I like it a lot. Moreover on modern CPUs I suppose that this is completely unnoticeable by the user.

As you point out, being able to keep emulation logic and configuration detection logic separated is key to keeping the code maintainable so I think this is a very necessary choice. I would never dare to do otherwise.

For the approach I am considering I planned to take advantage of the possibilities offered by the functional language Haskell where constructions such as Monads allow to mix two separate execution concerns together without requiring them to know about one another. I would be much in pain to detail how that can work because I am still in the process of learning and mastering Monads and still far from being able to design such an architecture but with the little I know I have the intuition that it should be possible. (Yup, that likely means that I am wrong but that will not prevent me from trying. ;))

Monads are often described as "programmable semicolons" in reference to the mandatory semicolons which separate statements in C/C++/C#/Java", an analogy which illustrates well what I would love to do: write the emulation logic on one side then pass it through a monad which can alter the execution flow as failures/successes are encountered.

This might be a complete pipe dream, but this at least bound to be a good Haskell learning experience if I survive it intact. :D
ThomH wrote:
Wed May 16, 2018 2:43 pm
iss wrote:
Wed May 16, 2018 7:45 am
I'm waiting for some "developer extras" like debugger ;) , but it's not an urgency of course.
Alas a debugger is not currently on the schedule. Which is probably absurd if you think about the strong intersection between people still using emulators of '80s machines and people producing content for '80s machines but I've yet to think of a good way to do it well. And it'd probably never be in the SDL version. But I still want to add a Qt or GTK back-end for Linux types that want a full real application out of their emulators rather than just a discreet thing that runs a DSK but doesn't otherwise announce itself.
I would also vote for a debugger for the exact reasons you gave. ;)

Note that if you do not want to invest too much time in providing a debugger feature yourself you could maybe simply provide an API/protocol allowing external debuggers to connect to and remotely control Clock Signal.

A very basic version could simply provide functions to:
  • pause/resume the emulator
  • step the emulated guest CPU by one "PC step" (or any other user-palatable step concept).
  • read the emulated guest context:
    • CPU registers
    • RAM content
    • Some hardware status structures (simplified for external consumption).
The external debugger would then be responsible for providing a proper debugging interface with disassembled code, memory maps, etc.

Visual Studio Code (as well as most IDEs) can be extended to support external debuggers, so an extension could be written by someone else to interface it with the protocol exposed by Clock Signal for external control.

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

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

Post by ThomH » Fri May 25, 2018 3:11 am

I've made a hasty new release to correct a regression in Microdisc support.

Also included: initial write support from 8DOS to DSK and WOZ images. For the time being the whole emulation is a little slower in support of that whenever the 8DOS drive is being accessed, read or write, but I've a fix for that mentally scheduled.

It's downloadable here as always.

User avatar
iss
Squad Leader
Posts: 620
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

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

Post by iss » Fri May 25, 2018 7:45 am

Great! I've tested it and it seams to work (slower than real hardware but it's OK for now :)).
BTW, WOZ format is good thing too, I've downloaded tons of images but I didn't find an actual converter DSK->WOZ, do you have such one? It would be perfect to have sources so I can compile and use it under Linux/Windows/macOS.

Post Reply

Who is online

Users browsing this forum: No registered users and 5 guests