I do agree with you, however...Nemesis wrote:I think mid-line changes are more important than most people realize.
...for most things, this is exactly what the real hardware does, and is therefore, accurate.Nemesis wrote:you have to choose a single fixed point in time to commit every change to the VDP. This is fundamentally inaccurate.
Oh sure, I've wasted a big chunk of my life running tests for various things over and over and over again until I'm sure I've fully understood what's going on However I have not tested every single bit of every single register to see if it's one that gets latched or not. As I'm sure you're aware this is a lot of work, and particularly when your only output device is a crappy old TV, it can be hard to even see what's going on sometimes. From the documentation, however, it is obvious which ones definitely *should* be latched, and I tested those just to make sure. Some others that I know should not, are not, and are updated at the correct time. So my renderer isn't strictly 'line based', although that is what happens most of the time, since thats what happens on real hardware most of the time.Nemesis wrote:As for the documentation, I never trust it.
CRAM writes are actually done, internally, when they should be. It does make a difference to my renderer, although you don't currently see each individual write, that would be almost trivial to do.
Most of the other registers, whether they can or can't be written at any time, is something I'll get back to when I am able to test on hardware again - however 99% of them are never, and will never be done on anything but the very test programs you're writing, because the results are undesirable, and to be avoided anyway. So this stuff got pushed to a lower priority eventually, because I had way too many other, more important, things to test.
Have you tested every mode, under every condition? It's been a very long time but I'm sure I was seeing white dots appear when all I was writing was zeroes. I could be completely misremembering. Try it with the background colour set to something other than zero, and the rest of the palette filled with white.Nemesis wrote:The rules are pretty simple.
Yes, you may have noticed I do that for the noise channel. Problem here is that on a real system, all the high frequencies get completely removed by the filtering. Unless you're emulating the filtering, this sounds very nasty, so the best solution is to 'filter' them yourself in this way - and of course if you filter it to zero you get no samples. Maxim probably figured this by testing with KegaNemesis wrote:BTW, there's actually a problem with PSG emulation in all current emulators.
No no no, not at all, just in this specific case.Nemesis wrote:You obviously think an emulator which attempts to use threading for CPU emulation is going to be inherently slower with no significant benefits.
Looking at it from another angle - you can pretty much assume nobody is going to be using a dual core system thats less than 1GHz - and since 1GHz is fast enough to do what needs to be done, you don't get any benefit from dual core.
Sure, for other systems, it may make perfect sense.
Indeed, and I would have made this clearer had I not known that the current build has some stupid test code and typos that can affect timing The next build I (should have, hopefully) removed all that crap, and It'll be extremely accurate, as it was supposed to be beforeNemesis wrote:Well it sounds like you've achieved a higher level of timing accuracy than I thought.
Hmm. From all my work on the SNES (actually, a lot more than on the Genesis) I would say the opposite is true. Really need to get into this with Byuu properly when I have time.Nemesis wrote:It sounds like a much harder task to achieve this on the SNES. Everything sounds a little more inter-dependent.