Author Topic: Clock Signal: for the Mac and Linux  (Read 2183 times)

0 Members and 1 Guest are viewing this topic.

Offline ThomH

  • CPC464
  • **
  • Posts: 47
  • Country: us
  • Liked: 37
Re: Clock Signal: for the Mac and Linux
« Reply #25 on: 19:20, 13 June 18 »
A very minor progress update on this: you can now create and configure new machines without a piece of turnkey media, at least on the Mac. There's not that much to the Amstrad options: 464, 664 or 6128 is pretty much it. But it's another way to check out the non-Amstrad machines in case you were curious — just to see how they boot up, what the BASICs are like, etc.

Meanwhile the non-Amstrad machines have grown in number. Also I found a reasonable Z80 cycle counting test for one of the other platforms and scored 100% perfection; that doesn't necessarily translate to the CPC because it's still possible I'm triggering or sampling WAIT incorrectly but it's promising as to eliminating a potential source of inaccuracy. The other machine does use WAIT but normally only in combination with NMI so all it strongly establishes there is that I'm properly WAITing while entering an NMI handler.

If anybody is aware of a CPC-specific instruction length tester that I could try, that'd be fantastic.

Downloads in the usual place.

Related technical chatter: the emulator works by breaking each instruction into its component machine cycles, and each machine cycle into the periods between every time it will sample the bus. The CPU runs atomically (as far as an observer can tell) for those periods, then samples the bus, then continues. Precision for time is half a cycle.

So unlike some traditional emulators there's no master list of instructions to cycle lengths, or anything else that's trivial to verify, because if there were then errors would actually be quite a bit more likely once you factor in the information those tables should convey to be complete: cycle length plus the offsets of all bus accesses within those periods, which is a variable quantity. A lot of olden-times emulators just effectively time warp to the end of the instruction and do all the accesses then. It's inaccurate but it couples well with lookup tables for lengths.

It is for this reason that the rating from another platform is at all relevant for a CPC. I guess you'd otherwise hack it and just use a different table for the Amstrad, with WAIT times built in (and presumably some sort of special case for interrupts, because even with the completely-regular implementation of WAIT on a CPC, its effect on an instruction is properly a function of both that instruction and the one before it, with the segue into an interrupt handler causing a discontinuity).
« Last Edit: 19:23, 13 June 18 by ThomH »

Offline reidrac

  • Supporter
  • 6128 Plus
  • *
  • Posts: 564
  • Country: gb
  • Trying to gamedev!
    • index.php?action=treasury
    • usebox.net
  • Liked: 925
Re: Clock Signal: for the Mac and Linux
« Reply #26 on: 09:19, 14 June 18 »
I don't know how I missed this, but I just checked the emulator on Linux and I'm very impressed.

I submitted some bug reports, thanks for replying to them so quickly! (one of them was trivial, but I didn't want to make a PR for the CLI option because it sounds a bit against your main "single-click" idea behind the app).

One thing I've found weird compared to other emulators is that it looks "blurry" when things move on the screen (?). Is it because you blend frames? Is there any way to optionally disable that?

Edit: I spent some time reading the code and I live it. Very nicely done, and open source. Thanks!
« Last Edit: 11:26, 14 June 18 by reidrac »
Released The Return of Traxtor, Golden Tail and Magica for the CPC.

Offline ThomH

  • CPC464
  • **
  • Posts: 47
  • Country: us
  • Liked: 37
Re: Clock Signal: for the Mac and Linux
« Reply #27 on: 16:36, 14 June 18 »
One thing I've found weird compared to other emulators is that it looks "blurry" when things move on the screen (?). Is it because you blend frames? Is there any way to optionally disable that?
Things are blurred but it's not necessarily whole frames. The philosophy behind it is a camera-pointed-at-screen metaphor, but the point is to decouple output frame rate from machine frame rate. So whatever frame rate your monitor is, you're seeing that many different frames a second, regardless of however many frames a second your CPC is producing (i.e. very close to 50, but depending on the program).

The primary objective is to avoid motion aliasing — that stutter you see if 50 fps is adapted to 60 fps by only changing the output on vsync, which effectively means just repeating every fifth frame.

That being said, I've probably softened it a little too far.

Luckily (?!), the whole CRT side of things is heavily invested in OpenGL right now, and OpenGL will be deprecated in the next macOS. So a severe revisiting is necessary, and that'll should inherently put me in a position cleanly to make more intelligent decisions.

I dare imagine I'll aim to end up at something like:
  • output frequencies that are divisors or exact integer multiples will just get whole frames;
  • output frequencies that are very close to that will be permitted to shift the machine speed a couple of percent this way or that;
  • output frequencies that are not integer multiples of the input but are substantially higher (e.g. a 120Hz or 144Hz gaming monitor) will probably blend whole frames, as you're still going to get a decent number of completely solid depiction of every individual CPC frame between the blendings; and
  • non-integer multiples that are frustratingly close to the input but not close enough for a machine speed change to be acceptable (such as 60 versus 50) will probably continue to do line-on-demand blending, but less overtly.
All subject to latency considerations, of course.

My mental schedule is to polish off the current machine, and joystick input, and actually show disk activity information on screen (a mechanism is in place for propagation, but neither the SDL nor Mac ports actually show it to the user), give the SDL port the long-waiting ability to launch a machine without a piece of media as the Mac already has (I was kind of forced into it on the Mac side by virtue of the built-in framework for this sort of application making objectively sensible assumptions), then do a CRT work attack. While still knocking off issues arising and/or anything else that distracts me along the way. Some more time on Thacker's acid tests definitely wouldn't hurt, even if it's just an occasional fix here, an occasional fix there.

Offline reidrac

  • Supporter
  • 6128 Plus
  • *
  • Posts: 564
  • Country: gb
  • Trying to gamedev!
    • index.php?action=treasury
    • usebox.net
  • Liked: 925
Re: Clock Signal: for the Mac and Linux
« Reply #28 on: 20:57, 14 June 18 »
Things are blurred but it's not necessarily whole frames. The philosophy behind it is a camera-pointed-at-screen metaphor, but the point is to decouple output frame rate from machine frame rate. So whatever frame rate your monitor is, you're seeing that many different frames a second, regardless of however many frames a second your CPC is producing (i.e. very close to 50, but depending on the program).

The primary objective is to avoid motion aliasing — that stutter you see if 50 fps is adapted to 60 fps by only changing the output on vsync, which effectively means just repeating every fifth frame.

That being said, I've probably softened it a little too far.

Luckily (?!), the whole CRT side of things is heavily invested in OpenGL right now, and OpenGL will be deprecated in the next macOS. So a severe revisiting is necessary, and that'll should inherently put me in a position cleanly to make more intelligent decisions.

I dare imagine I'll aim to end up at something like:
  • output frequencies that are divisors or exact integer multiples will just get whole frames;
  • output frequencies that are very close to that will be permitted to shift the machine speed a couple of percent this way or that;
  • output frequencies that are not integer multiples of the input but are substantially higher (e.g. a 120Hz or 144Hz gaming monitor) will probably blend whole frames, as you're still going to get a decent number of completely solid depiction of every individual CPC frame between the blendings; and
  • non-integer multiples that are frustratingly close to the input but not close enough for a machine speed change to be acceptable (such as 60 versus 50) will probably continue to do line-on-demand blending, but less overtly.
All subject to latency considerations, of course.

My mental schedule is to polish off the current machine, and joystick input, and actually show disk activity information on screen (a mechanism is in place for propagation, but neither the SDL nor Mac ports actually show it to the user), give the SDL port the long-waiting ability to launch a machine without a piece of media as the Mac already has (I was kind of forced into it on the Mac side by virtue of the built-in framework for this sort of application making objectively sensible assumptions), then do a CRT work attack. While still knocking off issues arising and/or anything else that distracts me along the way. Some more time on Thacker's acid tests definitely wouldn't hurt, even if it's just an occasional fix here, an occasional fix there.

Deprecated doesn't mean is going away any time soon.

My screen refresh is 60Hz and currently the effect is too strong, fullscreen I don't think I can use this emulator with my current project that updates a 25Hz.

I can look at the code and see how I can soften the effect a bit, perhaps; because other than the few minor bugs I've reported, it looks like a very solid emulator running natively on Linux.
Released The Return of Traxtor, Golden Tail and Magica for the CPC.

Offline ThomH

  • CPC464
  • **
  • Posts: 47
  • Country: us
  • Liked: 37
Re: Clock Signal: for the Mac and Linux
« Reply #29 on: 00:54, 15 June 18 »
Deprecated doesn't mean is going away any time soon.
Technically it's not even deprecated yet, I just know when it will be deprecated. But I wanted to work on it anyway and on macOS use of OpenGL is probably a performance pitfall as Apple's been generally uninterested for almost a decade.

My screen refresh is 60Hz and currently the effect is too strong, fullscreen I don't think I can use this emulator with my current project that updates a 25Hz.

I can look at the code and see how I can soften the effect a bit, perhaps; because other than the few minor bugs I've reported, it looks like a very solid emulator running natively on Linux.

No, I think you're entirely correct. I've significantly reduced it. But perhaps more interesting, see pull request 467. The constant in regular C++ in CRTOpenGL.cpp is the multiplier applied to the previous pixel, that in the GLSL in OutputShader.cpp is that applied to the new. Then they're added. Or you could change or remove the glBlendFunc and not mix the two at all.

Online roudoudou

  • 464 Plus
  • *****
  • Posts: 476
  • Country: fr
    • urban exploration
  • Liked: 524
Re: Clock Signal: for the Mac and Linux
« Reply #30 on: 01:16, 15 June 18 »
clksignal does not find my roms (Linux)
i create the /usr/local/share/CLK/ directoryonly missing 664 roms, are they mandatory?
EDIT: ok, all roms were needed
« Last Edit: 01:21, 15 June 18 by roudoudou »
use RASM, the best assembler ever made :p

I will survive

Offline ThomH

  • CPC464
  • **
  • Posts: 47
  • Country: us
  • Liked: 37
Re: Clock Signal: for the Mac and Linux
« Reply #31 on: 01:32, 15 June 18 »
clksignal does not find my roms (Linux)
i create the /usr/local/share/CLK/ directoryonly missing 664 roms, are they mandatory?
EDIT: ok, all roms were needed
Yeah, that's currently an issue. I've filed it so it will be fixed. It's a decision that dates back to the original thinking that the emulator would launch only if media is presented; in that case it owns the decision on which machine to launch so may ask for any ROM at any time. It's an easy-enough fix so I'll get to it.

EDIT: oh, and I've tweaked the video again because I'd forgotten to test interlaced video machines, which are a whole additional consideration beyond motion aliasing. It's still a lot weaker than it was though; I already like it more. And the pull request as above is still a reasonable way to find the constants involved for your own play.
« Last Edit: 01:35, 15 June 18 by ThomH »

Online roudoudou

  • 464 Plus
  • *****
  • Posts: 476
  • Country: fr
    • urban exploration
  • Liked: 524
Re: Clock Signal: for the Mac and Linux
« Reply #32 on: 01:38, 15 June 18 »
About the screen emulationI run the emulator (with an empty floppy)I do this in basic
ink 0,0
ink 1,0
border 0
Then i continue to see the text in a very dark color, some letters are blurry, some are notThis won't go the pure black
About CRTC emulation, CRTC tests does not seems to work (may check what is the problem)
use RASM, the best assembler ever made :p

I will survive

Online roudoudou

  • 464 Plus
  • *****
  • Posts: 476
  • Country: fr
    • urban exploration
  • Liked: 524
Re: Clock Signal: for the Mac and Linux
« Reply #33 on: 01:40, 15 June 18 »
here is what i see (i enhanced contrast with Gimp retinex)
use RASM, the best assembler ever made :p

I will survive

Offline ThomH

  • CPC464
  • **
  • Posts: 47
  • Country: us
  • Liked: 37
Re: Clock Signal: for the Mac and Linux
« Reply #34 on: 02:40, 15 June 18 »
About the screen emulationI run the emulator (with an empty floppy)I do this in basic
ink 0,0
ink 1,0
border 0
Then i continue to see the text in a very dark color, some letters are blurry, some are notThis won't go the pure black
About CRTC emulation, CRTC tests does not seems to work (may check what is the problem)

Unable immediately to reproduce, but clearly an OpenGL usage error. Screenshot for those same commands on my machine is attached (and the same result was encountered in Linux). I'm willing to guess that I'm assuming too much of OpenGL's rounding in hoping that the final fragments of old frames will go away. Not a problem, I can fix it. And will do.

Re: CRTC tests, I've tried to be very open that the emulation is presently imperfect by a frightening degree, but 90% of games work, including many with CRTC trickery. If you're referring to Thacker's test suite though, I do immediately see what you mean.

I guess you're live testing it now, so I'm going to come back and transcribe all of these issues into tickets for the permanent record later on. Besides anything else, I'm on US time so I need to leave right now to cook.

I'm extremely grateful for the testing, by the way, and bug reports are a really good thing right now. Endless thanks!
« Last Edit: 02:43, 15 June 18 by ThomH »

Offline ThomH

  • CPC464
  • **
  • Posts: 47
  • Country: us
  • Liked: 37
Re: Clock Signal: for the Mac and Linux
« Reply #35 on: 02:42, 15 June 18 »
An attempted fix the above error has now been submitted to the repository; I'll look at the other issue re: CRTC access from Thacker's tests later this evening if time allows.
« Last Edit: 03:46, 15 June 18 by ThomH »

Offline reidrac

  • Supporter
  • 6128 Plus
  • *
  • Posts: 564
  • Country: gb
  • Trying to gamedev!
    • index.php?action=treasury
    • usebox.net
  • Liked: 925
Re: Clock Signal: for the Mac and Linux
« Reply #36 on: 09:20, 15 June 18 »
Technically it's not even deprecated yet, I just know when it will be deprecated. But I wanted to work on it anyway and on macOS use of OpenGL is probably a performance pitfall as Apple's been generally uninterested for almost a decade.

No, I think you're entirely correct. I've significantly reduced it. But perhaps more interesting, see pull request 467. The constant in regular C++ in CRTOpenGL.cpp is the multiplier applied to the previous pixel, that in the GLSL in OutputShader.cpp is that applied to the new. Then they're added. Or you could change or remove the glBlendFunc and not mix the two at all.


I tried it and is fine. I still see some blur, but it is OK. I guess I'm not used to it because other emulators skip frames to emulate 50Hz on 60Hz.

Thanks, it is a good change :+1:!
Released The Return of Traxtor, Golden Tail and Magica for the CPC.

Online roudoudou

  • 464 Plus
  • *****
  • Posts: 476
  • Country: fr
    • urban exploration
  • Liked: 524
Re: Clock Signal: for the Mac and Linux
« Reply #37 on: 09:45, 15 June 18 »
Tomh, i tried the RTS demo from Jack because it's mostly a software demo but the screen get wrong until the end, probably only with a non standard configuration (but not reprogramming CRTC on the fly)http://www.cpc-power.com/index.php?page=detail&num=7406
use RASM, the best assembler ever made :p

I will survive

Offline ThomH

  • CPC464
  • **
  • Posts: 47
  • Country: us
  • Liked: 37
Re: Clock Signal: for the Mac and Linux
« Reply #38 on: 20:37, 15 June 18 »
Tomh, i tried the RTS demo from Jack because it's mostly a software demo but the screen get wrong until the end, probably only with a non standard configuration (but not reprogramming CRTC on the fly)http://www.cpc-power.com/index.php?page=detail&num=7406
I'll look at it this weekend. As you'd hope, the only difference between a standard and non-standard CRTC configuration is that the former has been much more thoroughly tested.

Offline reidrac

  • Supporter
  • 6128 Plus
  • *
  • Posts: 564
  • Country: gb
  • Trying to gamedev!
    • index.php?action=treasury
    • usebox.net
  • Liked: 925
Re: Clock Signal: for the Mac and Linux
« Reply #39 on: 11:51, 16 June 18 »
@ThomH quick question: I have a new screen that can do 50Hz, will clk benefit from that? I can't tell if there's any difference compared with 60Hz.

Perhaps that blur effect isn't necessary if the refresh is exactly 50Hz.
Released The Return of Traxtor, Golden Tail and Magica for the CPC.

Offline mahlemiut

  • CPC6128
  • ****
  • Posts: 243
  • Country: nz
  • Liked: 108
Re: Clock Signal: for the Mac and Linux
« Reply #40 on: 16:01, 16 June 18 »
Tried this out today, builds and runs fine on Arch Linux.

Would be nice if there was some level of configuration, though.  A config file at the least.
Being able to map joystick controls to keyboard would be good, too.  I'm often too lazy to plug in a joystick :)

That being said, looking forward to further progress.
- Barry Rodewald
Amstrad CPC, Sharp X68000, Neo Geo Pocket, and Neo Geo AES system leader at HARP
http://www.homeactionreplay.org/

Offline reidrac

  • Supporter
  • 6128 Plus
  • *
  • Posts: 564
  • Country: gb
  • Trying to gamedev!
    • index.php?action=treasury
    • usebox.net
  • Liked: 925
Re: Clock Signal: for the Mac and Linux
« Reply #41 on: 16:47, 16 June 18 »
Tried this out today, builds and runs fine on Arch Linux.

Would be nice if there was some level of configuration, though.  A config file at the least.
Being able to map joystick controls to keyboard would be good, too.  I'm often too lazy to plug in a joystick :)

That being said, looking forward to further progress.

+1 to a simple configuration file.

I have a WIP build of RMV2 and is very fancy, but unfortunately uses quite a lot of resources. CLK is fast and lightweight, so for development is aces. The other native emulators I've tried on Linux didn't get to the same level of these two.
Released The Return of Traxtor, Golden Tail and Magica for the CPC.

Offline ThomH

  • CPC464
  • **
  • Posts: 47
  • Country: us
  • Liked: 37
Re: Clock Signal: for the Mac and Linux
« Reply #42 on: 21:34, 17 June 18 »

Tomh, i tried the RTS demo from Jack because it's mostly a software demo but the screen get wrong until the end, probably only with a non standard configuration (but not reprogramming CRTC on the fly)http://www.cpc-power.com/index.php?page=detail&num=7406
Based on the most cursory inspection, whatever line period it's setting doesn't seem to agree with the CRT's requirements for sync. I'll have a closer look to figure out whether the tolerances I apply are too strict.


@ThomH quick question: I have a new screen that can do 50Hz, will clk benefit from that? I can't tell if there's any difference compared with 60Hz.


Perhaps that blur effect isn't necessary if the refresh is exactly 50Hz.
Alas, the emulator is presently too stupid to spot when the two rates align. It just deals in the worst case that they probably won't. But on a 50Hz display most, if not all CPC software should fall within the rule of plus or minus 2%, so the CPC itself could have its processing rate nudged to get exactly 50Hz output. Obviously with a CRTC every program is allowed to be different so there'd need to be some active monitoring but there would be anyway.


Would be nice if there was some level of configuration, though.  A config file at the least.
Being able to map joystick controls to keyboard would be good, too.  I'm often too lazy to plug in a joystick


That being said, looking forward to further progress.
+1 to a simple configuration file.
Sure, I'll get onto it. To be explicit, this SDL version isn't supposed to be "the Linux port" for the simple reason that there is no "the Linux". It's supposed to be a 'kiosk mode', i.e. a no-UI way just to run the emulation, anywhere there's SDL. Which is entirely consistent with a configuration file — I've sort of promised one elsewhere because if the configuration file includes the piece of media to load then the SDL target of the emulator becomes a nice way to package new titles for use on modern computers. I have a desire at some point to produce a Qt or GTK port, for a GUI presentation. That is definitely something I would do rather than hatching my own UI.



I have a WIP build of RMV2 and is very fancy, but unfortunately uses quite a lot of resources. CLK is fast and lightweight, so for development is aces. The other native emulators I've tried on Linux didn't get to the same level of these two.
Thanks! I'm still allowing myself to believe that because I think the structure is solid, I'm probably just a few hundred lines off being a cycle accurate emulator — I'm not gaining speed by doing anything incorrectly, indeed I'm kind of annoyed it doesn't go faster, I'm just not there yet.