Page 3 of 12

Re: Yet Another

Posted: Tue Jan 03, 2017 9:02 am
by Dbug
Do you have any plan for releasing Windows and Linux versions of the emulator?

Re: Yet Another

Posted: Sat Jan 28, 2017 4:03 am
by ThomH
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.

Screenshots attached.

Re: Yet Another

Posted: Sat Jan 28, 2017 3:00 pm
by Godzil
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 :)

Re: Yet Another

Posted: Sat Jan 28, 2017 4:20 pm
by ThomH
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.

Re: Yet Another

Posted: Sat Jan 28, 2017 4:41 pm
by Godzil
ThomH wrote:
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 :)

Re: Yet Another

Posted: Mon Jan 30, 2017 1:40 pm
by ThomH
Godzil wrote:
ThomH wrote:
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.

Re: Yet Another

Posted: Mon Jan 30, 2017 9:33 pm
by ibisum
Not seeing any issues with graphical glitches on my MBPro ...

Re: Yet Another

Posted: Tue Jan 31, 2017 8:26 pm
by ThomH
ibisum wrote:Not seeing any issues with graphical glitches on my MBPro ...
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.

Re: Yet Another

Posted: Wed May 17, 2017 2:11 pm
by ThomH
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.
Doggy (Mac Pro).png

Re: Yet Another

Posted: Wed May 17, 2017 3:10 pm
by Chema
Nice! Keep on with the good work, and don't forget us, PC users :wink:

Re: Yet Another

Posted: Thu May 25, 2017 11:46 am
by Iapetus
Chema wrote: Wed May 17, 2017 3:10 pm Nice! Keep on with the good work, and don't forget us, PC users :wink:
Seconded :)

Re: Yet Another

Posted: Fri May 26, 2017 5:28 am
by coco.oric
Nice! Keep on with the good work, and don't forget us, PC users
+1 :)

Re: Yet Another

Posted: Wed Aug 16, 2017 3:53 pm
by ThomH
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.

Re: Yet Another

Posted: Thu Nov 23, 2017 10:38 pm
by ThomH
Quick announcement: I've added a Linux target for my emulator.
Screen Shot 2017-11-23 at 16.30.31.png
Either clone from https://github.com/TomHarte/CLK/ or download the latest source release from https://github.com/TomHarte/CLK/releases and build. You'll need SDL 2, ZLib and OpenGL, plus a GPU that is at least OpenGL 3.2 compatible. You'll need to supply the Oric ROMs, including the colour ROM.

There's no UI, it's all launch from the command line. My expectation is that you'll just associate it as the handler for its supported file types in your favourite filesystem browser, or name it properly when creating shortcuts for your Oric programs. Its purpose still is to be completely invisible if possible: you don't launch the emulator to use the emulator, you launch the Oric program you want to use and the emulator does the behind-the-scenes stuff to allow you to do that.

Try --help for the command-line options but probably the only one you'll care about is --display=composite (as pictured) rather than the default of --display=rgb. Depends what sort of screen you used your Oric with, I imagine.

If you try it, then feedback would be appreciated. Good luck!

Re: Yet Another

Posted: Thu Nov 23, 2017 11:59 pm
by iss
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?).
One wish from me: I want to have HFE with Oric too ;).

EDIT: for Linux build 'scons' is required too.