News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Clock Signal: for the Mac and Linux

Started by ThomH, 03:23, 28 August 17

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ThomH

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

reidrac

#26
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!
Released The Return of Traxtor, Golden Tail, Magica, The Dawn of Kernel, Kitsune`s Curse, Brick Rick and Hyperdrive for the CPC.

If you like my games and want to show some appreciation, you can always buy me a coffee.

ThomH

Quote from: reidrac on 07:19, 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.

reidrac

Quote from: ThomH on 14:36, 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, Magica, The Dawn of Kernel, Kitsune`s Curse, Brick Rick and Hyperdrive for the CPC.

If you like my games and want to show some appreciation, you can always buy me a coffee.

ThomH

Quote from: reidrac on 18:57, 14 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.

Quote from: reidrac on 18:57, 14 June 18My 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.

roudoudou

#30
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
My pronouns are RASM and ACE

ThomH

#31
Quote from: roudoudou on 23:16, 14 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.

roudoudou

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)
My pronouns are RASM and ACE

roudoudou

here is what i see (i enhanced contrast with Gimp retinex)
My pronouns are RASM and ACE

ThomH

#34
Quote from: roudoudou on 23:38, 14 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!

ThomH

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

reidrac

Quote from: ThomH on 22:54, 14 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, Magica, The Dawn of Kernel, Kitsune`s Curse, Brick Rick and Hyperdrive for the CPC.

If you like my games and want to show some appreciation, you can always buy me a coffee.

roudoudou

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
My pronouns are RASM and ACE

ThomH

Quote from: roudoudou on 07: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
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.

reidrac

@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, Magica, The Dawn of Kernel, Kitsune`s Curse, Brick Rick and Hyperdrive for the CPC.

If you like my games and want to show some appreciation, you can always buy me a coffee.

mahlemiut

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

reidrac

Quote from: mahlemiut on 14: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.

+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, Magica, The Dawn of Kernel, Kitsune`s Curse, Brick Rick and Hyperdrive for the CPC.

If you like my games and want to show some appreciation, you can always buy me a coffee.

ThomH


Quote from: roudoudou on 07: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
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.


Quote from: reidrac on 09: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.
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.


Quote from: mahlemiut on 14:01, 16 June 18
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.
Quote from: reidrac on 14:47, 16 June 18
+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.


Quote from: reidrac on 14:47, 16 June 18
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.

reidrac

The more I look at the code, the more I like this project.

I can't stop with my current project, but I definitely need to reserve some time to dive into this. Lots to learn!

Thanks @ThomH for CLK!
Released The Return of Traxtor, Golden Tail, Magica, The Dawn of Kernel, Kitsune`s Curse, Brick Rick and Hyperdrive for the CPC.

If you like my games and want to show some appreciation, you can always buy me a coffee.

ThomH

#44
I'll be prouder of it when(/if?) it's cycle accurate.
Developments for those grabbing the source directly:

       
  • the acceptable horizontal sync timing window has been slightly increased, fixing the RTS demo which previously failed to achieve synchronisation;
  • I discovered the WinAPE timing tests, which revealed that I was slightly off with INC/DEC (HL). My forced wait t-cycle in the middle m-cycle was prior to any that occur as a result of the WAIT line, which it shouldn't be. That contrasts with things like stack activity where the write m-cycle takes four t-cycles because there's address work before the actual write can happen; I'd conflated the two. Anyway, that being fixed, I get a complete pass on those.
I'm gearing up for a new release, which in practical terms means a new binary for Mac users, I just want to finish off a fix to the left border that'll also enable composite video output for the CPC.

ThomH

#45
Although a bunch of issues are still inflight that's probably a perpetual truth so I've published a new release based on the premise that it's a decent improvement on the prior. As per usual, Mac binaries and source bundles are available.

Primary improvements:

       
  • properly models the Gate Array's handling of the CRTC's HSYNC period to include blank and a colour burst;
  • thereby adds optional support for composite video output;
  • adds joystick emulation;
  • tweaks the Z80 very slightly to pass the WinAPE Z80 timing tests;
  • becomes more tolerant of not-quite-standard line periods;
  • in the SDL version you can use real joysticks as input to emulated machines;
  • in the SDL version you can now also specify the path to your ROMs so that they don't have to be in /spare;
  • in the Mac version you'll now see activity indicators, in particular a drive LED; and
  • on both places, reduces the amount of inter-frame blending.
I realise I've not really mentioned it here before, for obvious reasons, but the emulator implements composite video by producing the actual composite signal, then decoding it. It's not the standard fetishised post-processing. A screenshot of the Renegade title screen is attached along with a close crop on just the named contributors to allow for easier inspection:


Powered by SMFPacks Menu Editor Mod