SegaCD and 32x

[Snake]

Wrote a big reply, lost it, bah. Forgive me if I simplify.

I think mid-line changes are more important than most people realize.

I do agree with you, however...

you have to choose a single fixed point in time to commit every change to the VDP. This is fundamentally inaccurate.

...for most things, this is exactly what the real hardware does, and is therefore, accurate.

As for the documentation, I never trust it.

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.

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.

The rules are pretty simple.

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.

BTW, there's actually a problem with PSG emulation in all current emulators.

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 Kega

You obviously think an emulator which attempts to use threading for CPU emulation is going to be inherently slower with no significant benefits.

No no no, not at all, just in this specific case.

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.

Well it sounds like you've achieved a higher level of timing accuracy than I thought.

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 before

It sounds like a much harder task to achieve this on the SNES. Everything sounds a little more inter-dependent.

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.

[Chilly Willy]

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.

I have one of those old ABit BP6 dual-P3 mobos with two 350 MHz CPUs. Don't use it for more than testing things as it's pretty old and slow.

[Near]

Probably not, its more likely that your context switches are not as optimal as they could be. Mine are down to two instructions, one of which I'd have to do anyway, and the other gets nicely pipelined and effectively takes less than a cycle.

Unless your cores only consist of one single monolithic function (no function calls that can affect timing), and your ABI marks all registers as volatile (or you use the very slow pusha), I don't see how this is possible.

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.

That is indeed the biggest predicament I face with going multi-core now. The slowest dual core is fast enough on a single core already.

Given that the CPU will not see an interrupt till, at the very earliest, the start of the next instruction, there's got to be a way to do this

... and I just recalled why the "look ahead N cycles" part got so sticky: the CPU and PPU wouldn't be aligned, which would greatly complicate out-of-sync comparisons to see if the PPU would change the H/Vblank pins in N cycles, something like: if(hblank_is_clear_at(counter) && hblank_is_set_at(counter + cycles_to_execute)). So not only do I need a special PPU function to look ahead, I also need one to look behind the current time (and have a much greater range) as well as scheduler hooks to access the internal CPU<>PPU skew counter.

Syncing on changes to overscan / interlace won't work well. Interlace can affect PPU tile addressing immediately (though only physically change the scan sweeping once per frame), and overscan toggle can disable or re-enable the display at any given point between Y=225-239. If I recall, this can happen even in the middle of a scanline (causes a few pixels of garbage output). That would force the PPU to never run ahead of the CPU, lest the CPU change these registers.

So they're both pretty much tied to each other to step one clock tick at a time. Bah ...

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.

Seriously? You've spent more time with the SNES? I'm shocked, I figured you were a 100% Sega guy.

In that case, I'm even more interested to hear from you
No rush, though. I understand you're busy. Pretty tied up myself at the moment.

[AamirM]

Hi,

Me too. My PSG also runs at the exact hardware frequency of something-stupid-that-I-dont-recall.

I was curious about this. Is it 234972 Hz??

stay safe,

AamirM

[Nemesis]

The PSG uses the same clock input as the Z80. This is the CLK0 output line from the VDP, which is MCLK/15. Internally, the PSG then divides that clock input by 16 to get its internal clock. On a PAL Mega Drive then with a 53.203MHz clock, you could calculate the internal PSG clock rate like so:

MCLK = 53.203MHz = 53203000Hz
CLK0 = 53203000/15 = 3546866Hz
PSG = 3546866/16 = 221679Hz

So the PSG would have an internal clock of 221679Hz. This would allow the PSG to generate a square wave with a maximum frequency of 110839.5Hz, using a tone setting of 0 or 1.

On an NTSC Mega Drive with a 53.6931MHz clock, the PSG clock rate would be:
MCLK = 53.6931MHz = 53693100Hz
CLK0 = 53693100/15 = 3579540Hz
PSG = 3579540/16 = 223721Hz

[AamirM]

Hi,

Thank you Nemesis. I intend to run PSG at that rate. Right now I am just oversampling 4 times.

stay safe,

AamirM

[TmEE co.(TM)]

Just nitpicking : PAL - 53.203424MHz, NTSC - 53.694175MHz

[Snake]

Hi,

Thank you Nemesis. I intend to run PSG at that rate. Right now I am just oversampling 4 times.

That's still a good idea, I'm also doing 32 times oversampling on PSG. Yeah, it's overkill. But I'm a synth freak at heart