Hello,

I want to congratulate you for releasing retrocopy with sega genesis emulator.
I'm working on a sega genesis emulator written in C++ too and I know it's a big work !
Did you write all part of the genesis emulation or did you use existing emulation core?
I wrote in your blog you will write a cpu cycle accurate core, what is the difference with existing core (Musashi, C68K from Gens author ...)
In my emulator, i don't use a scnaline like base for timings.
I'm using events system. So the main loop is executing cpu instruction and add master cycles in a global counter. the components like VDP, PSG ... can add events in a list with a precise value of this global counter.
For example when emulator start VDP will add an event VDP_HINT (Horizontal interrupt) at global_counter + 3420 (number of master cycles for a line).
So when the counter reach this value, the event is executed and add new VDP_HINT event at at global_counter + 3420 ...
Wich system do you use in your emulator?

Hi, thanks for the kind words.

I wrote everything but the Musashi 68K core. I had written a scanline based Genesis emulator like 8 years ago so I was semi-familiar with the system already. This time around though I already had cycle accurate Z80 and PSG, so I just needed to do the graphics and YM2612 at cycle level. A lot of the graphics work backed off my knowledge from SMS VDP so it was helpful in the end doing that.

The way I prefer to emulate systems is in lock step, cycle by cycle, as this is the way the hardware did it and usually ends up less cluttered and easier to debug. It isn't the "fastest" way to do it, but with the right optimization techniques it's pretty decent. When you have non cycle accurate components like the Musashi you are pretty much limited to its resolution though, that being an instruction. In most cases this isn't too bad, but it also means you're going to need to tweak and tweak and tweak until you get values right, and then you'll probably still have issues.

The way you do things is probably similar in accuracy to how I do things with the 68K if you're incrementing after each instruction rather than doing many in a row like scanline emulators.

When will we see your emulator?

For moment i only wrote the psg for sound part.
CPU and VDP (with High resolution mode) are working very good.

I think there is problems with your timings.
Outrun and mickey mania (level demo) aren't working good.

Here are post about sega genesis timings.
Perhaps it will help you or perhaps you can add you knowledges !!

http://gendev.spritesmind.net/forum/viewtopic.php?t=388&postdays=0&postorder=asc&start=0

http://gendev.spritesmind.net/forum/viewtopic.php?t=519&postdays=0&postorder=asc&start=30

thank you !!

And then it depends on your goals. Like, I just like the coding of something. The accuracy doesn't bother me, its what I can do with the end result. Like, I guess you figured when I added HLSL pixel shader support to BSNES. Maybe I am just weird, but thats why I do things

Nice work with this, I have to admit. How did you go about the Yamaha audio chip emulation? The MAME stuff researched by Nemesis for SSG is pretty nice.

I'm agree with you I prefer having clean code instead having accuracy with bad code.
When code has good structure you know what the emu do and you know more easily how to debug it.
My emulator is coded with this way ...

If I can help you to improve your genesis emulation i will be happy :-)

Yes of course it entirely depends on what people want to do. You also are limited by platform, RetroCopy probably wouldn't like the current WII too much for instance, though the XBOX and PS3 would probably be fine. Being on the PC and limiting myself to semi modern computers means I can do a lot more things than others have usually attempted which from my perspective is nice.

I'm a lot like you in that I want to do "weird and fun" things with the end result, but also different in that I want the source to be very accurate too I guess. I didn't realize you had done anything with BSNES, but that sounds cool. It's good that byuu is improving his emulator.

How did I go about the YM2612 emulation? Well I just wrote it.... MAME and other sources were helpful in obtaining information on how it worked though.

[quote]
I'm agree with you I prefer having clean code instead having accuracy with bad code.[/quote]

I have to agree. I started to change my attitude especially since I started my Vectrex emulator. Having everything cleanly done in classes is nice, and getting info from MAME and other sources helps, since there is quite a scarce bit of info, compared to the NES, SNES and other systems. That said, I like the best of both worlds: speed and accuracy, but not accuracy to the point its useless. Like SNESGT, its a awesome SNES emulator which has very accurate sound emulation. No other emulator except for BSNES comes close to that.

Hello Ralph,

Did you notice the link i gave you?

When you say you emulate the genesis cycle by cycle, does the main loop look like :

while (true)
{
68k.addcycle(1);
z80.addcycle(1);
vdp.addcycle(1);
...
}

For dma transfer, you transfer data byte per byte?

When i started my emulator i was thinking to do this way but i was not sure about speed and that's why i prefered make a opcode based emulator insted of cycle based emulator.

I had already read that link but thanks for posting it anyhow. I pretty much know where the issues lie in regards to the errors in the emulation. It will just require a little bit of tweaking to get it right. After working for 3 weeks on it I had enough tweaking and wanted to move onto something else for a little while.





Kinda, due to the instruction accurate musashi it doesn't return on a cycle boundary so is a bit different. You also need to make sure the pins of the CPUs in question read signals at the right time in regards to a "cycle".



Yes, pretty much at the same spots the real machine does them.



It can be very slow if you don't know what you're doing that is for sure, and it will be slower than other methods generally speaking.

So that's why i read in your blog you plane to write a 68k cycle based core?
I plane to write it one to :-)

The difficulty i have is to have correct vdp timings and real hcounter/vcounter values regarding of current cycle of a scanline.
As you can read in sprite mind forum, we have only supposed values based on tests.

Yes not many people in the world really care too much about the information that we want, so we will have to find it ourselves I believe.

When are you writing the cycle based 68K?

[quote=RetroRalph]

Yes not many people in the world really care too much about the information that we want, so we will have to find it ourselves I believe.

When are you writing the cycle based 68K?[/quote]

For the moment i'm searching all docs about motorola 68000 and timings (number of cycles during read/write operation ...) .
I saw some year ago an offcial doc of motorola with these infos, but only doc i find on the web isn't precise enough.