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.

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.

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.

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.

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...

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.

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.

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.

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.

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.

* 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.

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 ) 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.

* 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.

[ emulation (for both - Apple][ and 8DOS).
It helped me already to rescue (partially, because of really bad floppy disks ) 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.

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.

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).

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.

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.