Underlying reasoning? I'm writing an emulator because writing emulators is fun. I want to be explicit about this: I have no delusions. There is no objective need for a new emulator. Probably almost nobody will ever use my emulator. VICE is a very good emulator. People should use VICE.
However, mine will be distinguishable because: I hate manual configuration, I hate applications that don't adopt the host OS's normal user interface patterns, I want to spend that CPU and GPU power in a semi-modern computer to produce a more authentic emulation. That's how I've arrived at:
- standard document-model application architecture. Run as many simultaneous emulations as you like. Size, place, scale, however you like;
- the machine produces a genuine composite video stream that is decoded by the emulated CRT. So all artefacts are inherently correct;
- ditto audio is generated at the machine clock rate and filtered. VICE does this too, it appears, albeit via a different mathematical approach*.
(* mine's a windowing FIR; theirs looks like a spring-model IIR based on my superficial parsing but I don't claim to speak for them — short version is that mine's more expensive but via the SIMD unit it's not as intractable as it might feel)
My 6502's already almost certainly already perfect; it passes AllSuiteA, Klaus Dormann's tests and Wolfgang Lorenz's tests, and runs the other two emulated machines without noticeable issue. In addition mine is genuinely cycle accurate, making the exactly correct memory access every single cycle — all of them, every single one — and interleaving with the 6560 exactly like the real hardware.
The VICE 6560 is instructive but doesn't directly adapt because of the philosophical difference in what must be produced. For the benefit of fairness, VICE's currently manages the timing and behaviour a lot better than mine does. But it should be an easy fix.
(a side effect of the difference: I have no RGB or otherwise 3d colour palette. None. Anywhere.)
The 6522 could be directly lifted but for code style differences. And that doing so wouldn't be fun. Also I don't think it's all that complicated, but again to be explicit: it's not all that complicated because a lot of people much smarter than I have produced a lot of excellent documentation, because host processing power is in such abundance that I don't even have to write my code all that well, and because the trivial support for unit testing and the rest means that I don't even have to do all that much to verify it. The various communities for machines with 6522s have discovered all the edge cases and documented them thoroughly. I don't need to find the title that doesn't work, figure out what it's doing, figure out what it thinks the result should be, figure out why my code doesn't produce that result. I just need to read the documentation that says "this deprotection scheme works only because the 6522 will read $FFFF if read exactly N cycles after writing at Q"**, write a unit test for that, move on with my life.
(** a trivial example, which even the data sheet hits by quoting a 1.5-cycle reload time for repeating timers, but you get the idea)
EDIT: there's some sort of nasty CRT bug still lurking, clearly; it's to do with the sync marks passed to the GPU sometimes causing a misalignment between its reading of data and that from which the CPU reconstructed the raster timing, but occurs only under heavy load. To the extent that I hadn't even seen it prior to this morning. That being said, the best policy always being warts-and-all, here's 21 Vics more or less running at once:
... and here's one I blew up to full screen:
There's phosphor persistence that means that is not a field grab as you'd normally get from an emulator. Also it's a poor example of the artefacts that a real composite stream brings because a white background has no chroma, so there are no chroma phase transitions in this image. But nevertheless zoom in to see some banding within the characters (the asterisks show it reasonably well) and note that the gradient to the left of a row is pixels is different from that to the right, and that its specific colouring depends on the exact horizontal position of the text (close together, compare the V to the 2).
I am at work so shall not be downloading any commercial PRGs. Running my own little project at all for five minutes is already a stretch but it's a distraction that's helping me to think.
EDIT2: actually, looking at my own screenshot even more closely, "blah 2 copy 15.png" shows a machine that appears momentarily to have lost horizontal synchronisation as you can see the flywheel catching back on with stereotypical sinusoidal. The frames shown aren't the full NTSC frame, they're a crop to around 90% of the centre. But, ummm, whatever the problem is, it might be worse than I think. Hmmm.