SpritesMind.Net

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 CP...

notaz wrote:And true, it syncs once per line, not frame.

Well, once a line is still a HELL of a lot better for speed and multi-core than "lockstep". Spinlocking between lines would be quite doable and not waste much time. Not like spinning between intructions.

It's rather uncommon to find CD/32X games that require strict timing. I certainly would not agree with that. I play most of my CDs without strict timing in PicoDrive. I can't think of the ONE that requires strict timing off the top of my head, but out of about a dozen, there was ONE that needed it....

Err, what games run lock-stepped? If you look at games like Metalhead, they only coordinate at the vertical blank, when one sh2 is started on the game logic, and the other is started on rendering the frame. Most SEGA CD games run just fine with "relaxed" timing - i.e., the two 68000s aren't synchron...

In order to use the TSC reliably in that way, you'd have to be able to deal with cases where the counters are not in sync. Eg, what happens with multi-processor systems, or "fake" quad-core systems like the Core 2 Quad, where you've got two cores on the same die? It might be possible to base a syst...

At the moment, SMP requires all TSCs (for x86/amd64 cpus) be as close to the same value as possible (they're within 10 counts on linux). It seems to me that by using the TSC as the speed control on emulated code, it should be possible to keep emulated CPUs in sync without any interaction at all.

Given the prevalence of multi-core CPUs now, how do you think a one emulated cpu per core emu would fair? Of the three main computers in my house, two are dual-core.

Go look at the SEGA CD docs, and then look at the source for Frog Feast.

http://frogfeast.rastersoft.net/SegaCDSrc.html

That's understandable - DOOM has WAAAAAAAAY too much data to fit hardly any into SDRAM. I'm fairly certain the only thing in SDRAM is probably screen buffers (DOOM uses more than 2) and sound buffers. The DOOM executable wouldn't even fit in the SDRAM. A small level MIGHT fit in the SDRAM (just the ...

I've looked over the format and plan to make a python script to convert the format, but haven't gotten around to it. Pretty low on my ToDo list.

So what areas are valid for the Z80? Just the cart?

I think he's referring to something like this (extreme example to make a point): you can hook several hundred feet of bad cable to the audio out of the console and hook it to a crappy amp hooked to even worse speakers. The sound will be truly dreadful. Now an emulator is NOT supposed to emulate the...

I think he's referring to something like this (extreme example to make a point): you can hook several hundred feet of bad cable to the audio out of the console and hook it to a crappy amp hooked to even worse speakers. The sound will be truly dreadful. Now an emulator is NOT supposed to emulate the ...

I have a lot of experience in hamradio and I can tell where you are wrong. You have hamradio experience, but clearly not TV experience, and you're wrong about nearly everything but the color subcarrier for PAL. It still doesn't negate the fact that most TVs used to low-pass filter the luminance at ...

That really isn't simulating a TV very well. To REALLY simulate a TV, you need to take the RGB frame and convert it to YIQ. Low-pass filter the Y channel to 2.5 to 3.5 MHz (depending on how "sharp" you want the simulated TV to be). Then low-pass filter the I and Q channels to 0.5 HMz. Then delay the...