Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Sun Mar 20, 2016 10:57 pm

!!EDIT!! See the GitHub releases page for the latest version.

If so then today's your lucky day! See attached. It's too work-in-progress yet to justify a formal release anywhere but:
  • it's the only emulator that gets the timing right per Dave/hoglet's ever-more-thorough investigation, e.g. everything at http://www.stardot.org.uk/forums/viewtopic.php?f=3&t=10069;
  • ... which includes producing an interlaced display.
  • it's also an ordinary, document-model native app;
  • ... so you can run as many Electrons as you like simultaneously;
  • ... and normal, properly constrained window resizing rules apply.
  • it endeavours to get the DSP side of things correct;
  • ... so e.g. audio output is formulated as a 125Khz wave that's subjected to a 22Khz lowpass filter. Sampled speech works, no special cases.

The CRT emulation is what causes the somewhat flickery display more than the interlaced drawing. I'm working on it. There's also no disk drive emulation. It's a base model Electron only. With, quelle surprise, UEF being the only implemented file format. Also I've yet to put a fast/slow loading selection into the UI so it's hard-wired to fast mode. Which means that Spy vs Spy won't load. There's a full hardware emulation in there (as evidenced if you load Joe Blade, Northern Star, etc) but I've yet to decide what I want to do from a UI perspective given that it's technically a multi-machine emulator* and therefore the menu bar isn't necessarily the correct thing. I like drawers but need to check the latest human inteface guidelines since I don't think I've seen them around for a while.

Composite video mode is coming but is temporarily disabled as I've had a bit of a thorough reworking of the OpenGL side of things, endeavouring better to stream (at least up to the somewhat artificial ceiling enforced by Apple's lackadaisical attitude towards GL, though that's arguably academic since my GPU supports only 3.3 anyway).

I'm not sure progress is immediately going to be too speedy as I'm going on holiday this Friday.

* Atari 2600, since you ask. But temporarily broken because that's a composite-only machine. Will crash through failure to conform to the current threading model, as I've been ignoring it. Don't try.

Addendum:
It's a clean cross-plaform core that just currently happens only to have a Mac front-end. OpenGL core profile support is really the only required library. I'm going to ensure ES compatibility but it'll be 3.0 (~50% of Androids right now; every iPhone since the 5s and iPad since the Air). I want slightly to simplify the host to emulation interface before I document it — after that it should be fairly trivial to add a Qt front end and/or a Winforms front end and/or an SDL front end, etc. But I'm concentrating on the CRT stuff for the time being, to reduce CPU to GPU bandwidth* further and to bring back composite video.

* each scan currently costs 640 bytes of pixels plus 96 bytes of geometry; scans are literally a record of raster sweeps and don't need a consistent pixel clock so I can easily change that to 160 bytes for Modes 5 and 2 and 320 for 1, 4 and 6, and half again if I fancy putting two pixels in a byte, and through instancing I can drop the per-scan cost at least to 24 bytes. There's some rounding up due to the desire to pack scans as linearly-addressed subsections of a single 2d texture and because frame draw is permitted to interrupt emulation (as window events are timed arbitrarily) but for most Electron games that'd be a reduction from 736 bytes/line to possibly 104 bytes/line, so if bus bandwidth is a bottleneck then that's an 85% reduction there. Or more than 6 and two-thirds frames in the amount of data I'm currently taking to describe one.

On my 2011-vintage machine, ElectrEm occupies 12–13% of a core while running. With some additional optimisations last night, this hangs around the 19–25% range. Which is not unexpected, since it pays for the abstraction that makes it a multi-machine emulator, and well within the range of current mobile and embedded devices. But it'd be nice to get it down a bit, even if just because arbitrarily many simultaneous Electrons means arbitrarily much processing. And who likes it when their fans come on?

(EDITED: updated version attached. Will continue to try to keep the latest version up here unless or until this actually gets uploaded somewhere formal. The name, Clock Signal, is inherited from my ZX80/81 emulator with the intention the two things will fold together, and because I own clocksignal.com. So it has somewhere to go, eventually)

Image
Attachments
Clock Signal 01-10-2016.zip
(2.45 MiB) Downloaded 29 times
Clock Signal 16-06-2016.zip
(1.79 MiB) Downloaded 27 times
Clock Signal 09-05-2016.zip
(1.71 MiB) Downloaded 29 times
Clock Signal 02-05-2016.zip
(1.71 MiB) Downloaded 28 times
Clock Signal 24-04-2016[b].zip
(1.71 MiB) Downloaded 28 times
Clock Signal 24-04-2016.zip
(1.71 MiB) Downloaded 29 times
Screen Shot 2016-04-16 at 22.50.14.png
Clock Signal 14-04-2016.zip
(1.71 MiB) Downloaded 32 times
Clock Signal 21-03-2016.zip
(1.71 MiB) Downloaded 30 times
Clock Signal 20-03-2016.zip
(1.66 MiB) Downloaded 39 times
Last edited by ThomasHarte on Sat Dec 31, 2016 9:35 pm, edited 11 times in total.

User avatar
lurkio
Posts: 1292
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby lurkio » Mon Mar 21, 2016 4:33 pm

Hi, Thomas. The zip file you attached to your post contains an app called "Clock Signal.app", which, when you launch it, doesn't seem to do anything except provide a menu bar -- at least on OS X 10.10.5 Yosemite, which is what I'm running.

How exactly is the app meant to be used?

:?

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Mon Mar 21, 2016 4:57 pm

lurkio wrote:How exactly is the app meant to be used?


It's just a normal desktop app, with the specific ramifications that you could:
  • File->Open... or Command+O to open a UEF or .ROM; or
  • File->New or Command+N to start a new Electron with nothing inserted.
Or drag and drop a file onto the application icon, or double click to launch from the Finder.

With the lack of a machine configuration UI meaning you can't insert an [additional] UEF or ROM. So that's a current limitation.

Being old school, it hadn't occurred to me that this isn't how most apps work nowadays — they either present you with an empty new document or force an 'open' dialogue at you if you launch with nothing to restore. I don't offhand know why this app diverges. It's just using the OS's normal document manager. I wrote zero lines of code to implement all of the things described in this message.

User avatar
lurkio
Posts: 1292
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby lurkio » Mon Mar 21, 2016 5:03 pm

ThomasHarte wrote:File->New or Command+N to start a new Electron with nothing inserted.


File->New is greyed out (disabled).

:!:
Last edited by lurkio on Mon Mar 21, 2016 5:16 pm, edited 1 time in total.

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Mon Mar 21, 2016 5:07 pm

Sadly, that's an immediate cannot reproduce. And this is the .app attached, launched on my work machine, which has never previously seen the project. Does opening files work?

Screen Shot 2016-03-21 at 13.06.27.png

User avatar
lurkio
Posts: 1292
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby lurkio » Mon Mar 21, 2016 5:12 pm

ThomasHarte wrote:Sadly, that's an immediate cannot reproduce. And this is the .app attached, launched on my work machine, which has never previously seen the project.

Here's what I get:

1.jpg
Screenshot


ThomasHarte wrote:Does opening files work?

Yes, I just tried opening a UEF. It worked.

As you said, the screen is rather jittery!

:shock:

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Mon Mar 21, 2016 5:33 pm

lurkio wrote:
ThomasHarte wrote:Sadly, that's an immediate cannot reproduce. And this is the .app attached, launched on my work machine, which has never previously seen the project.

Here's what I get:

1.jpg


It's probably safe to assume I've made a basic metadata error. Declared support as an 'editor' for a file format is how the default document controller decides whether to permit 'New'. Hopefully I've just messed up the imported/exported UTI distinction, or something like that.

lurkio wrote:
ThomasHarte wrote:Does opening files work?

Yes, I just tried opening a UEF. It worked.

As you said, the screen is rather jittery!

:shock:


Sorry, yes, it won't surprise anybody that knows my feelings about emulation but I've decided to do things the hard way. So what you're looking at is a (currently very approximate) simulation of phosphor decay with a terrible camera model. Each virtual phosphor is acquiring its colour when the raster passes by, then decaying according to a formula of the form n*exp(-k*t). But each to-your-screen frame is then an instantaneous capture of that. Which stays on your screen for (probably) 1/60th of a second. So it's like filming a TV with an infinite shutter speed.

My preference is to simulate phosphor decay but to put in a proper camera model. Which will probably just end up being a[nother] lowpass filter on what there currently is.

Why not just transport the pixels direct-to-display like so many emulators hence? Several reasons:
  • that's a poor way to perform deinterlacing;
  • even if I bodged that, it still wouldn't fade like a proper CRT, so your modern computer would still stomp all over your recollection of Henhouse Harry not flickering like that;
  • by taking a proper DSP approach, this avoids the 50-into-60 problem that makes your modern computer imply that a bunch of smooth games were sort of jerky;
  • as a corollary to that, if you have a 120Hz or a 200Hz or whatever crazy gaming monitor, this emulator will actually produce 120 or 200 or whatever distinct frames, so you really, really, will get something that has the same sense of movement as the original; and
  • in any case my CRT emulation is completely decoupled from the emulated architecture, so my emulated Electron is really generating syncs and clocked scans, in order for my pretend CRT properly to support any hypothetical control mechanism without a bunch of artificial assumptions.

So it's about trying to tear down another of the ways in which emulators just aren't accurate representations. But it needs work as at the minute it's doing the opposite thing: introducing an output flaw that previously never existed.

(EDIT: and that's also why I'm so interested in minimising draw costs even though they're already small as a proportion — the cheaper each step is, the better I can resolve this problem while still doing a non-50Hz-bound processing of the raw signal. I have faith that starting off worse is going to result in better.)

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Tue Mar 22, 2016 2:42 am

Attached: a very simple attempt to reduce flicker, via the simplest-possible filter. Zoom in (e.g. by enabling it in the Accessibility part of the System Preferences; I have that on all the time for inspecting things) if you need to persuade yourself that it's still deinterlacing. Which it is.

No other changes.
Attachments
Clock Signal 21-03-2016.zip
(1.71 MiB) Downloaded 32 times

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Fri Apr 15, 2016 2:27 am

Minor update attached. I've:
  • switched from a 4:3 window showing a real TV area to a tight crop on the 11:10 region filled by pixels;
  • upped the internal audio sampling rate to the full 2,000,000 Mhz;
  • significantly reduced CPU to GPU data transfer, which should reduce power usage;
  • resolved a huge bug in which if the frame rate fell below a certain threshold* emulation would cease; and
  • improved parallelisation of screen refreshes generally.
I felt that fourth bullet point justified a fresh upload. I'm still edging slowly towards reinstating composite display and therefore the Atari 2600 emulation, as time permits.

* as far as I can make out, my Intel HD 3000 just can't draw a full display (1366x768) at 60Hz. Even if I reduce my fragment shader to simply returning `vec4(1.0);`. But that's not to say my GL code couldn't be improved. Definitely, definitely not to say that.
Attachments
Clock Signal 14-04-2016.zip
(1.71 MiB) Downloaded 32 times

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Fri Apr 15, 2016 4:27 pm

Update on known bugs:
  • the absence of File->New appears to be reproducible on an OS X v10.10 machine that I tested on. It doesn't occur on the two v10.11 machines I had otherwise tested on. So a negligible sample set but, yes, probably my Info.plist needs greater thought. Honestly, I've been deferring on this as I will need a custom document controller the second there's more than one machine that it makes sense to start without inserting media — I don't think the default 'New' operation knows what to do about applications that support multiple types of document (in the OS' terms);
  • on the Mac Pro here I sometimes see rounding errors in the pixel unpacking that usually result in unexpected vertical columns of pixels. Diagnosis below. I'm working on it.
Diagnosis of pixels: I'm now packing two pixels per byte and unpacking within my shader. Selection of which source pixel to unpack is based on the subpixel address, which is subject to some separate vertex shader computations. Clearly precision is causing one thing to round up before the other. I probably just need to derive both things from the same varying. Something as simple as a two-pixel mask texture will probably do it, in a sufficiently generalised fashion, without loading significant additional work into the fragment shader.

I plan properly to optimise once composite output is back. At that point it probably makes sense to write a quick iOS port, because the OpenGL profiling tools for iOS devices are absolutely fantastic. Snap a frame, step through every GL command with a fully inspectable version of modal state at every point, see the exact µs timings of each thing, including a per-line profiling of any shaders. Along with the tool's advice at optimisation tips.

Or maybe I'll zag and add at least one more computer emulation, so that I don't start off any other ports on the wrong foot. I don't know.

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Fri Apr 22, 2016 2:45 am

Screenshot update only; the super-offensive phosphor emulation is temporarily back but the pipeline for composite video emulation is now finally once again working. Screenshot evidence attached of Mode 0 with a vertical bar drawn every other line seemingly to create a shade of grey.

Colours will be forthcoming soon. It's a very incremental process.

I intend to do something about the poor scaling in 'monitor' mode subsequently.
Attachments
Screen Shot 2016-04-21 at 22.37.20.png
Screen Shot 2016-04-21 at 22.37.14.png

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Fri Apr 22, 2016 11:21 pm

One more, including colour. I've obviously made some really stupid range or clamping error somewhere in the loop to make the signal this poor. It's not my attempt to make it look like a poor CRT, it's a mistake. The green border is also a mistake. But time is out for another day.
Attachments
Screen Shot 2016-04-22 at 19.18.09.png

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Sun Apr 24, 2016 10:25 am

Composite colour mode now seems to work well, and I've switched approaches for handling phosphor decay, at least for now, to something much less ambitious (/interesting). But hopefully also less sickening.

Screenshots and application attached. It's discoverable via the pull-down menus, naturally, but hit command+option+O to bring up the machine options panel for the current machine. In there you can pick between television and monitor emulation (and between hack-the-ROM fast cassette loading versus proper emulate-the-hardware slow cassette loading, e.g. because you want to load something like Spy vs Spy that doesn't currently work with the former).

EDIT: attached is a quick bug fix version that makes absolutely sure that closing things doesn't crash the app. Oh, and it re-enabled Atari 2600 emulation. But with incorrect colours for reasons I'm exploring.
Attachments
Clock Signal 24-04-2016[b].zip
(1.71 MiB) Downloaded 27 times
Screen Shot 2016-04-24 at 06.14.35.png
Screen Shot 2016-04-24 at 06.14.21.png
Screen Shot 2016-04-24 at 06.14.01.png
Clock Signal 24-04-2016.zip
(1.71 MiB) Downloaded 28 times

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Tue Apr 26, 2016 2:40 am

A couple of videos of my attempt at composite video, for those without Macs:

https://www.youtube.com/watch?v=ShqgpomAqxw; Repton 2
https://www.youtube.com/watch?v=HgDwbRubgNI; Starship Command.

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Tue May 03, 2016 1:35 am

Updated: the last of the flickers has been eliminated, albeit at the cost of ambition, drawing costs are down, composite processing (i.e. decoding the composite signal) is better, persistence is improved and monitor mode should alias less.
Attachments
Television.png
Monitor.png
Clock Signal 02-05-2016.zip
(1.71 MiB) Downloaded 24 times

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Tue May 03, 2016 12:33 pm

Attached, hopefully further to explain what's going on here, three screenshots.

One is this emulator in monitor mode, as a reference shot. So that looks a lot like other emulators, except that it uses the machine's real pixel aspect ratio of around 11:10 and diagonal scans, rather than making pixels square and scans horizontal.

One is a real Electron running via a composite connection, which I pilfered from the Internet. One is the emulator pretending to be an Electron running via a composite connection.

So the objective is, amongst other things, to allow those of us that had only a television to experience an accurate emulation (and for it to be accurate because it is accurately reproducing the thing, not because I've post-processed it per my subjective aims).
Attachments
RGB.png
Composite B.png
Composite A.png

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Tue May 10, 2016 1:29 am

Alright, one more quick update that more or less perfects what was already there Acorn-wise; main changes since last week are marginal speed improvements and, hopefully, the complete removal of all possible sources of graphical glitching.

Specifically:
  • I was using a fairly laissez faire approach to circular buffer use which meant that should the emulator drop behind at all then it could overwrite content that hadn't been output yet, causing the wrong thing to make it to the screen. Usual result: a bit of the framebuffer inexplicably appearing at the wrong place on the display;
  • I was also allowing an emulated machine to hold a lock for all periods when it is outputting pixels, which blocked frame draws until the machine next went through a border or sync period. Which led to dropped frames just because of a failure to act during the expected period, as the emulated machine may have completed its processing for the frame without returning the lock. That no longer happens. So you should get a rock steady frame rate at whatever your screen's refresh rate is (60fps for any Mac with a built-in display, I think; and I really mean 60: as discussed, like a real CRT my CRT emulation doesn't artificially bucket frames).
Probably the next thing is to perfect the 2600 and add sound to it. So possibly I'll have no more Acorny updates for a while but you never know.

EDIT: here's a screenshot of the sort of nonsense one can enjoy when one's emulator is just an ordinary norm-compliant app.
Screen Shot 2016-05-10 at 10.20.57.jpg
Attachments
Clock Signal 09-05-2016.zip
(1.71 MiB) Downloaded 35 times

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Fri Jun 17, 2016 2:02 am

Quick update attached. For the Electron improvements are primarily around audio:
  • it should never break up;
  • latency is reduced; and
  • it will adapt to the audio output rate of your Mac, previously having topped out at 44100Hz.
Macs since about 2010 can play up to 96Khz through their built-in speakers and ordinary analogue ports; recent machines can go up to 192Khz with digital outputs. The Electron tops out at 125Khz so this is almost certainly the first emulator that can produce completely unfiltered audio.

There are also some improvements in parallelism that might reduce CPU load but it depends on a bunch of factors.
Attachments
Clock Signal 16-06-2016.zip
(1.79 MiB) Downloaded 35 times

User avatar
sirmorris
Posts: 725
Joined: Wed Feb 11, 2009 12:18 pm
Location: oxfordshire uk
Contact:

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby sirmorris » Fri Jun 17, 2016 5:51 am

:shock: wow =D> Amazing work there.

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Fri Jun 17, 2016 11:50 am

Should also add, since I find it entirely unintuitive: on a Mac open Applications -> Utilities -> Audio MIDI Setup to see a list of your audio devices and to select an output format. If you've never opened the program then probably you're at 44100Hz — as stated above, most semi-modern Macs can be pumped up to 96000Hz without additional hardware.

I can't hear much difference but I've never had the most amazing ears; I can hear a difference from the other fixes I've made. Tricks like the speech in Exile* already worked, now there's also no clicking in Qwak!**. I don't know about anybody else but to me it really feels a lot like the real hardware via TV capture now.

(on the non-Electron side, should you be curious: the Atari 2600 emulation is much improved and the Vic-20 has joined the party)

EDIT: the mentioned improvements in parallelism should also make the cost of running multiple Electrons simultaneously much more intuitive — previously the locking versus waiting for the GPU was too great, and GPU stuff seems generally to serialise. I've just launched 20 simultaneous Electrons on my work Mac Pro without any noticeably dropping in performance, though at that point I was dedicating 170% of a CPU at it, i.e. 1.7 Xeon cores. Which I guess means this machine should top out at 70 simultaneous Electrons. It's still at least 50% slower than ElectrEm was but, as implied, I'm working on the principle that one should spend the increased computing resources of the last twenty years on being more rigorous about signal processing and other things that we previously just sort of had to hand-wave.

* ultrasonic frequency plus switching the timer between audio and tape mode, to create a Spectrum-like 1-bit audio output to play a quick sample as part of the loading process;
** doesn't bother with a special case for stopping the audio, just throws the speaker into an ultrasonic frequency. No doubt so that its audio routines only ever deal with one register, rather than two and/or to avoid having an extra piece of state to track. But that creates a DC offset versus being actually switched off and the occasional output judder in the previous builds meant you'd get very occasional clicks during periods of 'silence'.

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Sat Oct 01, 2016 5:52 pm

Added to the original post: a new build. Changes in Electron world:
  • ADFS and DFS support (albeit read only at present);
  • sufficient analysis to be able to pick a loading command for whatever media you insert; and
  • added support for the final few UEF chunks I was missing.

EDIT: to add the usual prognostications; my immediate next plan is some dull internal rewiring stuff, to do with how the emulators talk to a host OS. During which I also hope to switch audio processing to its own thread and possibly reduce latency again over in Mac world. Following that, I think my main problem with the Vic-20 emulation is a poor 6522. So I'm going to see what else is relatively simple and uses a 6522, then try to extend to that. Some of the dull rewiring is to ensure that porting is even more trivial so I might then finally invest some effort into that.

Plus some implementation nerd stuff because I'm far from the only emulator author here: the disk sectors are assembled into a full, ordinary FM or MFM track, which is scanned to create a list of timed flux points. As elsewhere in the emulator, timing is not bound to any particular clock — it's e.g. next pulse after 1/3 of a rotation, pulse after that is another 1/252 of a rotation, pulse after that is 13/19 more of a rotation, etc. A phase-locked loop receives the pulses and endeavours to reconstruct the stream. Disk speed flutter is yet to add but part of the plan. This is all a massive waste of time for SSD and ADF disk images, but should allow FDI, IPF or whatever trivially to be added as an alternative storage format. And the reason I've gone multi-machine is that it helps to force proper segmentation of concerns and proper interfaces: so in this case I've ended up very close to the real hardware arrangement because I've been pushed there. The only other type of drive the emulator currently supports is the Commodore 1540/1 for its Vic mode, which is GCR but at least has a well-defined low-level format.

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Fri Oct 07, 2016 9:38 pm

Well, I'm out of permitted attachments to the top post but attached here is a new build that switches the way the Mac side of things is implemented, introduces some new async stuff that's so far used only for audio*, and increases accuracy in both ADC decimal** and the ULA status register***.

Why is the window suddenly 4:3 and not a genuine Electron 11:10(-ish)? Because that means that macOS Sierra users who want to 'Merge All Windows' (i.e. switch to tabbed emulation) can do so regardless of the running machine. So it's about trying to play as nicely as possible with the newest version of the OS. Screenshots below as evidence! I don't intend to use tabs, they're completely optional, but you get them for free if your windows are compatibly shaped.

* which amounts to barely 0.3% of processing even on the four-channel Vic with weird shift register square waves (EDIT: but that was a bad test; the Vic has a 1.6Khz analogue lowpass filter, so the initial audio generation is very low resolution; it's around 3.5% of emulation costs for an Electron). So negligible. But it's preparatory to trying to do similar things elsewhere. Two threads at 10%-of-a-core utilisation is much less likely to sound your computer fan than one thread at 20%-of-a-core utilisation.

** as I've added Hoglet's test to the formal test suite and discovered a bug in overflow flag calculation for ADC decimal. The 6502 now passes that test in addition to AllSuiteA, Klaus Dormann's and Wolfgang Lorenz's.

*** specifically as to the top bit being set (duh!) and the tape interrupts sounding during audio output. No known software is affected but I don't know everything.

Screen Shot 2016-10-07 at 17.35.45.png
Screen Shot 2016-10-07 at 17.35.42.png
Screen Shot 2016-10-07 at 17.35.39.png
Attachments
Clock Signal 07-10-2016.zip
(2.58 MiB) Downloaded 36 times

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Sat Dec 31, 2016 9:44 pm

After a bit of a detour, a new Electron-affecting release is available. The main Electron user-visible change should be simply that disk images are now modifiable, rather than being read-only.

Code changes have been reasonably substantial as I had quite a tidy-up of the Electron implementation — particularly to sever everything to do with generating the video stream from the machine proper. That plus the reasonably large additions to the disk infrastructure to model modifiable disks per my usual desire to try to aim high* actually make this quite a different piece of software in code terms.

The emulated WD still doesn't support everything a real chip should, so work remains ongoing. Don't try to format a disk and expect it to work. But it should be very accurately timed and work completely for ordinary loading and saving. It's not much extra work to complete it but as I type it's 16:43 so New Year's is about to usurp all activity.

Happy New Year!

* i.e. not just say "obviously there's a consistent data clock rate and perfect bit-window alignment, so an array of bits containing the [M]FM encoding will do" or, even less ambitiously "I'll just keep an array of sectors and write unencoded bytes directly into it". Also I added emulation support for an additional machine, with a WD1773 rather than one of the more common 1770/2s, which has a bunch of differences as it has a head loading feedback mechanism rather than direct motor control. So that meant adjusting that particular actor.

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Mon Jan 30, 2017 12:42 pm

Quick bump to announce another release. Relevant changes:
  • reduced GPU costs;
  • improved composite decoding (i.e. better composite colours); and
  • an error in the emulator's attempt automatically to start ADFS floppies is fixed†.

† the particular ADFS ROM I'm using appears not to respond to shift+break on initial startup. So the emulator now lets the machine run for a second or so, then performs a shift-break. No major magic, but the difference between double clicking on an ADF doing what you want, and not doing so.

EDIT: based on some quick testing, this version and the one immediately before it (that I failed to announce here, but it's there on GitHub) 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.

User avatar
Rich Talbot-Watkins
Posts: 1121
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby Rich Talbot-Watkins » Tue Apr 11, 2017 8:45 pm

Just read through this thread (I missed it originally, probably subconsciously skipped it because of the Mac reference!). What an astonishing piece of work! =D> I'm a sucker for this kind of clock-level accuracy, and I think it's the only emulator I've seen which takes this approach to all aspects of the emulation - computer, CRT, disk system and audio.

So, I don't own a Mac, and haven't been able to try it. I hope one day you can move to some kind of cross-platform library like GLFW or Allegro, so it can get a wider audience. I'm fascinated, in particular, by the CRT emulation. The video you posted of Starship Command shows exactly the colour fringes I remember seeing on my TV, and the slight jitteriness of the image. How exactly is all this working? The jitter and non-uniform colour fringes most intrigue me - something a bit random seems to be happening there. Would love a thorough explanation of the CRT emulation if you have the time / inclination :D

User avatar
Rich Talbot-Watkins
Posts: 1121
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby Rich Talbot-Watkins » Wed Apr 12, 2017 10:58 am

Here's an example of what I'm talking about:

Image

This just looks spot on from my memory of using my Beeb with a TV set, but what leads to these repeating patterns? I would've expected the timing to be synched consistently at the start of each line following horizontal flyback.

Are you emulating the shadow mask as well? How about the slight diagonal movement during rasterization (I assume there's a constant vertical movement, rather than only during horizontal flyback)? This isn't an area I know that much about, so I have plenty of questions!

SarahWalker
Posts: 1041
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby SarahWalker » Wed Apr 12, 2017 5:09 pm

The repeating patterns are a result of the Beeb's pixel clock (4 MHz in MODE 2) not being synchronised with the PAL colour burst (4.43 MHz). This results in crosstalk between the luminance and chroma signals giving you the wobbly rainbow dot crawl.

B-em also does this when using PAL emulation, though there's obviously something different in how B-em and Electrem are processing the image. Possibly B-em is doing too much comb filtering?
bem_crosstalk.png
(24 KiB) Not downloaded yet

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Wed Apr 12, 2017 6:51 pm

SarahWalker wrote:The repeating patterns are a result of the Beeb's pixel clock (4 MHz in MODE 2) not being synchronised with the PAL colour burst (4.43 MHz). This results in crosstalk between the luminance and chroma signals giving you the wobbly rainbow dot crawl.

B-em also does this when using PAL emulation, though there's obviously something different in how B-em and Electrem are processing the image. Possibly B-em is doing too much comb filtering?
bem_crosstalk.png

To expand on this: the PAL colour frequency ends up implying 283.7516 colour cycles every 64µs, i.e. 283.7516 colour cycles per line if you're on-spec, as Acorn machines are. It's the .7516 that causes a diagonal pattern that repeats approximately every four lines — if it were .75 then the repetition would be exactly every four lines because that's the least integral multiple of .75 that is an integer, and .7516 is really close.

An entire Electron frame is 312.5 lines long, which is 88672.375 colour cycles. So you should also expect a static image to show a repeating sequence of eight distinct renderings. If you allow the OS to use its ordinary CRTC values then the BBC isn't interlaced in modes other than Mode 7, so has a different repetition frequency. The CRTC can do interlaced displays, programmable lengths of frame, etc, so it'll vary from title to title.

To lay foundations for this: in PAL (and NTSC) world, two channels of colour are added to the composite signal via amplitude modulation of a high-frequency carrier. It deliberately isn't in-phase with the line frequency because that makes the effect less obvious on black and white sets that don't otherwise do anything to eliminate the colour signal, which was all of them when the colour standard was adopted. So if you're a TV then separating the colour from the brightness is about separating one part of the frequency spectrum from the other.

The comb filter referred to was a late-stage development in analogue TVs but is a real approach contemporaneously taken, and is super-efficient for software simulation: you just add a delayed copy of the input to itself. So for each single output sample you need only two input samples. Pretend there's only one colour channel because the principle is the same regardless, then the luminance + colour signal at time t can be expressed as:

Code: Select all

o(t) = l(t) + c(t) * sin(kt)


... where o(t) is the output at t, l(t) is the luminance value, c(t) is the chrominance value, and k determines the frequency of the colour subcarrier. Observing that sin(-a) = sin(a - 180) = -sin(a), you can therefore perform a separation as:

Code: Select all

o'(t) = o(t) + o(t - 180/k)
      = l(t) + c(t) * sin(kt) + l(t - 180/k) + c(t - 180/k) * sin(k(t - 180/k))
      = l(t) + c(t) * sin(kt) + l(t - 180/k) + c(t - 180/k) * sin(kt - 180)
      = l(t) + l(t - 180/k) + c(t) * sin(kt) + c(t - 180/k) * sin(kt - 180)


... which, if you suppose that l(t) = l(t - 180/k) and that c(t) = c(t - 180/k) — i.e. that both signals were constant is:

Code: Select all

      = l(t) + l(t) + c(t) * sin(kt) + c(t) * sin(kt - 180)
      = 2l(t) + c(t) * sin(kt) - c(t) * sin(kt)
      = 2l(t)


So you've separated the luminance perfectly in areas of solid colour. And if the colour and luminance varies a little then, well, you're a little off. But you're probably still doing well enough.

My emulator was using a Kaiser-Bessel high-pass filter but is now using a much more brute-force averaging. Either way, neither of those or comb filtering is either incorrect or correct. They're just emulating different televisions, as implementations varied quite a lot over the almost 50 years of analogue colour PAL.

As to the other topic: I keep meaning to put together the absolute minimal cross-platform edition, using one of the cross-platform libraries, if nothing else as a self-documentation of how you do that. Timing, audio out, input an OpenGL canvas and some concept of where to find program resources form the complete list of requirements. On the Mac side, all of the cross-platform libraries are essentially terrible so I calculated that it was a lot less work to let Apple's code do the normative Mac things as to managing windows, presenting file dialogues, preserving state across sessions, handling window resizing and full-screen display, etc and write the stuff necessary to interface to the emulator than it would have been to let SDL/Allegro/whatever provide a window and the rest and then write the stuff to make my work look like a normal Mac app. Especially as Apple likes to change the rules so often.

EDIT: inline version of Sarah's image, to save people a click:
Image
So that's B-Em, using a comb filter.

EDIT2: it also looks like there's still some disagreement over pixel sizes. I've not written this anywhere in my emulator, it's just a side effect of all the other timings, but by my calculations:

  • The PAL visible area is 52µs wide and 288 lines high.
  • Acorn paints for 40µs and 256 lines.
  • Therefore the aspect ratio of an Acorn screen is (40/52)*4:(256/288)*3 = 46080:39936 = 15:13.
  • So to produce square pixels, an Acorn display would need to be 256*15/13 = ~295 pixels wide. Therefore in 320-pixel wide mode, the pixels are taller than they are wide, because more pixels than the amount that would make squares are being squeezed into the same area.

Your TV would need to be about 8% off on aspect ratios to create square pixels.

User avatar
Rich Talbot-Watkins
Posts: 1121
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby Rich Talbot-Watkins » Thu Apr 13, 2017 8:58 am

Thanks for the explanations, Thomas and Sarah - very enlightening! So I assume that you're converting the pixel RGBs to composite and then decoding it back to RGB (after interpolation) in the shader? Does it work to essentially hold tuples of {luminance magnitude, chrominance magnitude, chrominance phase} at pixel granularity, or are you actually sampling the final luminance+chrominance signal and separating it into its components at render time? I still haven't quite figured how the composite signal is actually composed - it seems rather more complicated than a 5.5MHz AM carrier for luminance, modulated by (or added to?) a 4.43361875MHz subcarrier for chrominance. Also haven't quite worked through the comb filter yet. Haven't done any signal processing for something like 20 years so I'm decidedly rusty on all this.

Edit: OK I understand how the composite signal is composed: the chrominance is modulated onto the 4.43MHz subcarrier and superimposed on the luminance signal. Exactly like you wrote Thomas. #-o

ThomasHarte
Posts: 366
Joined: Sat Dec 23, 2000 5:56 pm

Re: Do you own a Mac, and like your Electron emulators minimal and potentially seizure-inducing?

Postby ThomasHarte » Thu Apr 13, 2017 11:57 am

Rich Talbot-Watkins wrote:Thanks for the explanations, Thomas and Sarah - very enlightening! So I assume that you're converting the pixel RGBs to composite and then decoding it back to RGB (after interpolation) in the shader? Does it work to essentially hold tuples of {luminance magnitude, chrominance magnitude, chrominance phase} at pixel granularity, or are you actually sampling the final luminance+chrominance signal and separating it into its components at render time?

I can speak only as to my emulator, but what's supplied to the shader is a collection of raster runs, which are communicated as a start and end position (both as a count of time since the last horizontal and vertical syncs), a one-to-four channel blob of data that is opaque and a shader that can provide a composite level as a function of linear position, phase and the input data. Each emulated machine uses a different format but the Electron is two pixels per byte TTL RGB. So the GPU both creates the composite signal and then decodes it.

I've been through several approaches so this is very temporal but I've currently a bunch of intermediate buffers. I convert to composite, store that. From composite I separate to luminance and chrominance, store that. From luminance and chrominance I convert to RGB, store that. From RGB I paint the quad that represents that raster run. More or less 256 runs make a whole frame because I've zoomed and cropped, the Electron being fixed in its output region.

Of the other emulated machines: the Atari 2600's palette is just natively a luminance and phase shift so that goes through unprocesssed; the Vic-20 has an internal lookup from palette to luminance and phase shift (Commodore had a patent on this), which I mimic and supply luminance plus phase shift as looked up; the Oric has a composite lookup ROM, which I communicate values from directly so that's basically a fast-clocked monochrome.

EDIT: also, in case it's interesting, the minimal unit of screen repainting in my emulator is a straight line raster. A 144Hz monitor should paint 144 separate frames per second. This is part of my effort not falsely to introduce latency, in much the same way that the emulator is happy pumping 96Khz audio even on my lowly computer. But I think it also feels better even just for displaying PAL 50Hz on standard PC issue 60Hz displays now, rather than if you forced yourself to display only a whole frame at a time, in which case you're going to get a stutter after every fifth frame. There's a bunch of blending going on for the phosphor-ish semi-simulation*, so don't picture the harsh rolling edge you'd associate with tearing.

* which has become ever-less scientific but that's okay. The interface between machine and emulated CRT doesn't assume anything. My hands aren't tied.

EDIT2: oh, also, it strikes me that I forgot to explain why the comb filter has that name. It's because supposing your luminance had content with exactly the wavelength implied by the distance between the two samples you are summing, then you'd amplify that content rather then removing it. Ditto for any multiple of that frequency. So the frequency response graph looks like a bunch of peaks at the integers. So it looks like a comb. There's no combing in the actual implementing, whatever that would be.


Return to “emulators”

Who is online

Users browsing this forum: IanS and 3 guests