forum.defence-force.org

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.

Dbug wrote:Do you have any plan for releasing Windows and Linux versions of the emulator?

I definitely want to. I just don't currently have great access to either type of system; I'm developing on a five-year old MacBook Air which means limited everything, including hard disk space. But I've attempted to keep it easy to port. I need to do more research.

In the meantime, here's the latest Mac-only release. It reduces GPU cost and improves composite decoding, while halving the AY's clock divider per comparison between what I have and what's on Youtube. The data sheet makes inconsistent claims, so maybe it's right now, maybe it's not.

Godzil wrote:I wrote my first emulator on a laptop with something like a Pentium 133 as the main CPU so please don't complain with your highly powered computer...

Good work with the latest release

I suspect I may have had a Pentium 200 in mine but my point was more: I can't just throw on a Linux virtual machine as I haven't the space.

Another potential pivot is to Android, of course, as I think everything I use is in OpenGL ES 3, every Chromebook released this year will be able to run Android apps, and Android development puts no specific requirements on you as to underlying OS. So that might be the smart next thing. I'll read up.

Last edited by ThomH on Sat Jan 28, 2017 4:43 pm, edited 1 time in total.

Godzil wrote:I wrote my first emulator on a laptop with something like a Pentium 133 as the main CPU so please don't complain with your highly powered computer...

Good work with the latest release

I suspect I may have had a Pentium 200 in mine but my point was more: I can't just throw on a Linux virtual machine as I haven't the space.

I know it was a joke

And taken as such, but poorly responded to. Oh well.

Anyway, I've made a quick new release to correct a couple of bugs: a race condition† and a memory movement bug††. Minor things.

As to code, I intended just to factor out and generalise the thing the Atari 2600 is doing as to decide whether it made an error starting up in NTSC mode, so that my emulated Oric could switch back and forth between 50 and 60 Hz with a display that eventually figures out what is going on and stops rolling. But I lack self control so I decided to try to fix a couple of latent errors in my Atari emulation, then once I'd started doing that decided really to go to town as it also has big long-standing performance problems that I want to address. So I'll probably be deep in that for a couple of weeks.

† between the emulation thread and the OpenGL thread, if the emulation is producing output too quickly for the OpenGL thread to consume (i.e. GPU performance at your output size isn't matching CPU performance), and an OpenGL frame ends output while the emulation is partway through the pixel part of a line (which itself may be a long period, e.g. because the pixels began close to the end of the amount of processing that flows from one timer event but didn't end until the processing in the next). I'm always happy to expand on implementation topics if anybody cares!

†† a classic incorrect use of `memcpy` where I want `memmove`, inside the audio filtering, probably making no difference in practice, but definitely incorrect.

EDIT: based on some quick testing, this version and the one immediately before it show quite a lot of graphical glitching on my work Mac Pro; neither has any issue on my work MacBook Pro or my personal MacBook Air. So I'm not going to pull them, but it'd be useful to know whether anybody else sees issues.

I feel like probably there's a piece of state I'm failing properly to initialise, or something like that. Based on trying the various emulated machines, it's seemingly processing data correctly and outputting it to the right place but pulling the input incorrectly. I can justify five minutes of testing at work but I can't really justify developing there so I guess I'll just have to re-read carefully and throw every analysis tool there is at it. Or go in over the weekend. Luckily it's a nice office.

Hi again; quick drop-in to say that the video issues that presented themselves on a Mac Pro are now resolved. I'd made an error in mapping between buffers such that I was unintentionally relying very heavily on floating point rounding going one way rather than another. So it could easily have surfaced on any other machine or version of macOS. It's believed fixed now though.

No progress on cross-platform plans, sadly.

A gratuitous shot of in-motion composite Doggy from my Mac Pro is attached.

Wandering through again. Still no direct progress on a PC port. But, several small bug fixes:

previously it was possible for disks to corrupt themselves in memory in physically-impossible ways (including data mirroring), though you'd probably have needed to reformat a disk image in the emulated machine to trigger that, which is how it slipped under the radar. Corrected.

after comparing the emulator's Barbitoric to that on Youtube, and some non-Oric AY samples, I've decided that, probably, the current state of tone dividers probably isn't affected by frequency changes — if you're part way through a cycle of X Hz audio and you switch to Y Hz then the final pulse of X Hz will complete before the Y Hz begins. That is, the relevant counter is reloaded only when it hits zero. This produces less scratchy audio as the effect of reloading immediately was to introduce a single pulse of something between X and Y. It's all still a guess, but I think it sounds closer now.

glancing back at the PAL spec, I spotted that it has an official gamma of 2.8. Computers are calibrated to be 2.2. So there's a gamma conversion in-place now for composite video users, as the composite video is always PAL.