PC-Engine

[AamirM]

Hi,

Are you implementing the delay for the transfer instructions too?

Yes I am. Is there any other game that depends on this behaviour? I need to test this more.

Does this mean you have tested all HuCard games aside from it? Final Soldier is finicky about hblank timing (and I don't know how to get it really correct), although it only shows up in the title and pause screens.

No, that means as much as I could test, which are 58 games (thats less, I know).

What's wrong with those two? Or do you want something not GPL? ;P

No, I just want something simpler to understand. Mednafen is using blip buffer and and has a wierd coding convention with strange naming of things (moo, breepbreep etc.). Ootake has all of iats comments in Japanese and its impossible for me to understand why is it doing something the way it is. As I said previously, I have already implemented the PSG (minus LFO) and it is wroking very nice. I just wanted to see how some other emus do the same thing.

It's not like with the 2612 DAC. The PSG unit is based on 3.579mhz master clock and when in DDA mode data port is passed directly to the DAC, there's no divider used for the update rate. So Unless you're outputting to the DAC faster than 3.579mhz, then you won't be missing sample writes.

It can happen, even when the Z80, which has the same clock as the PSG, is driving the YM2612.

stay safe,

AamirM

 

[AamirM]

Hi,

Noticed another thing. After the emulation of VDC access timings, the glitch in F-1 Pilot is now gone. It was just like you mentioned it was in your emu before.

stay safe,

AamirM

 

[malducci]

It can happen, even when the Z80, which has the same clock as the PSG, is driving the YM2612.

On the 2612, it's not a matter of the cpu though. It has to do with the way the 2612 cycles the channels six times in series to a filter. The DAC only has 1 of those output slots *and* the interface ports to the 2612 are CPU access slotted as well - hence the busy flag. That leaves room for missed writes.

That's not the case on the PCE. There are six independent DACs, each with their own volume mixer, operating in parallel. Each channel register has its own master clock divider and in DDA mode it fetches a byte from the data port rate of 280ns. The fastest the CPU can even write to it is 640ns. If there's a misalignment, it will catch is on the next fetch - which is faster than any stow instruction of the CPU. If this weren't the case, then writes to the other register would be in jeopardy of being missed - like frequency, volume, etc. That would be pretty drastic. On a low level, the ports are either buffered or the audio unit is asserting /RDY.

 

[AamirM]

Hi,

I think you didn't understand the problem (or I couldn't explain it right). I was not referring to the missed writes to PSG but instead missed playing of some samples by the emulator. What I meant was that some games want that emulator play the audio buffer very often than sometimes possible to sound correct. Listen to this demo in any Megadrive emulator (like Gens,Regen) then run this demo in Kega Fusion and you'll understand what I mean.

stay safe,

AamirM

 

[Exophase]

No, I just want something simpler to understand. Mednafen is using blip buffer and and has a wierd coding convention with strange naming of things (moo, breepbreep etc.). Ootake has all of iats comments in Japanese and its impossible for me to understand why is it doing something the way it is. As I said previously, I have already implemented the PSG (minus LFO) and it is wroking very nice. I just wanted to see how some other emus do the same thing.

I can send you mine if you promise not to let anyone else see it and not use any of the code. Also if you give me your source in return.

Noticed another thing. After the emulation of VDC access timings, the glitch in F-1 Pilot is now gone. It was just like you mentioned it was in your emu before.

I wouldn't be too confident about this, because it's possible to "remove" this bug (and many others) by giving very generous hblank windows. Of course, this also breaks other games, and is far from correct.

It can happen, even when the Z80, which has the same clock as the PSG, is driving the YM2612.

I don't know of any games which playback samples at a rate higher than the timer can drive, which is roughly 7KHz. So you shouldn't have a problem with correctly sampling that back to whatever your emulator outputs.

 

[AamirM]

Hi,

I can send you mine if you promise not to let anyone else see it and not use any of the code. Also if you give me your source in return.

Fair enough. But you will have to wait a bit. I'll PM you when mine is presentable (its a messy x86 asm code right now ) and then we'll exchange the code.

I wouldn't be too confident about this, because it's possible to "remove" this bug (and many others) by giving very generous hblank windows. Of course, this also breaks other games, and is far from correct.

I ain't confident either. Timing of the emulator are way off and more games are coming up as non-working (Cyber Core, Blodia, Benkei Gaiden etc..). Although most non-working games do have sound and controls working but no image.

I don't know of any games which playback samples at a rate higher than the timer can drive, which is roughly 7KHz. So you shouldn't have a problem with correctly sampling that back to whatever your emulator outputs.

Yeah, that shouldn't create that problem. But I guess we'll see.

stay safe,

AamirM

 

[Exophase]

Fair enough. But you will have to wait a bit. I'll PM you when mine is presentable (its a messy x86 asm code right now ) and then we'll exchange the code.

Should I even ask? It's pretty weird that your goal is writing a "cycle accurate" emulator and yet you dive right into using a language that'll make it about as complicated as possible to write, maintain, and change...

Sure, my emulator has a lot of ARM ASM, but it also has C versions of all of that that I wrote first to get things working... what you're implying is that you're starting with x86 ASM and then converting it to something else which would be bizarre to say the least.

 

[AamirM]

Hi,

Should I even ask? It's pretty weird that your goal is writing a "cycle accurate" emulator and yet you dive right into using a language that'll make it about as complicated as possible to write, maintain, and change...

Please understand one thing, I like my emulators not only to be as accurate as possible but also as fast as possible to be actually usable. I always try to achieve both at the same time but giving accuracy more priority. Using assembly doesn't mean that I am sacrificing accuracy in any way, I just it to be fast too by just using optimizations (not hacks). Right now, only the CPU core and PSG are in asm and everything else is in C. As far as maintaining/changing goes, I have maintained/changed much more complex things in asm than these. They both seemed to be simple enough to be written in asm. And I don't rewrite things in C if I don't have to. About 99% of the users are using Windows/Linux/MacOSX on x86 PCs. TurboEngine, which right now is far less complex than Megadrive but running at cycle granularity, give 1/3 the FPS that Regen gives on my PC. I just want my stuff to be used by as many people as possible.

I am not trying to say that everyone should use asm. I am just using it because I can and need it. Once again I would like to emphasize that accuracy has not been sacrificed in any way. It comes foremost.

stay safe,

AamirM

 

[Exophase]

Hi,



Please understand one thing, I like my emulators not only to be as accurate as possible but also as fast as possible to be actually usable. I always try to achieve both at the same time but giving accuracy more priority. Using assembly doesn't mean that I am sacrificing accuracy in any way, I just it to be fast too by just using optimizations (not hacks). Right now, only the CPU core and PSG are in asm and everything else is in C. As far as maintaining/changing goes, I have maintained/changed much more complex things in asm than these. They both seemed to be simple enough to be written in asm. And I don't rewrite things in C if I don't have to. About 99% of the users are using Windows/Linux/MacOSX on x86 PCs. TurboEngine, which right now is far less complex than Megadrive but running at cycle granularity, give 1/3 the FPS that Regen gives on my PC. I just want my stuff to be used by as many people as possible.

I am not trying to say that everyone should use asm. I am just using it because I can and need it. Once again I would like to emphasize that accuracy has not been sacrificed in any way. It comes foremost.

stay safe,

AamirM

No offense, but it sounds like a naive mindset to assume that everything in ASM will be much faster from the start. Granted, there are usually a lot of opportunities for this in a CPU interpreter, but I've also seen a number of interpreters that miss several obvious optimizations in a C core, then have ASM cores that also miss all of these obvious optimizations.

What I don't really understand is why someone so preoccupied with absolute accuracy would care about a relatively small performance improvement (that might not exist anyway). When someone declares that they want to make a completely "cycle accurate" emulator they're saying that, from the start, they don't necessarily care about just making the emulator compatible. That even if 100% of all games created worked perfectly they would not be content if something was not accurate. Most of them say they do this for preservation, although a few say they do it for development purposes as well I think this is completely overblown as real developers should not find it so difficult to test their code on the real platform in addition to emulators. If users care about speed then they'll probably pick the emulator that already plays all of the games over yours that is much slower due to being more accurate, and if they pander to the accurate emulators for whatever then they probably won't care about speed.

My emulator right now is not strictly cycle accurate, but I designed it so it could be, and the changes that would be necessary to make it so (with respect to PSG, timer initiation, and VDC) are relatively trivial, and I'm all but certain that they would have a minimal impact on speed. Right now my pure C emulator also sounds like it's much faster than your emulator that incorporates ASM, unless Regen has gotten a few orders of magnitude faster over the course of its development.

Bottom line, it seems absurd to willingly throw away 10x performance for whatever reason (maybe that you didn't need to) then go to great lengths to try to reclaim a small amount of it.

 

[AamirM]

Hi,

In the following "in ASM" means "coding in ASM on x86".

No offense, but it sounds like a naive mindset to assume that everything in ASM will be much faster from the start. Granted, there are usually a lot of opportunities for this in a CPU interpreter, but I've also seen a number of interpreters that miss several obvious optimizations in a C core, then have ASM cores that also miss all of these obvious optimizations.

I never said that anything written in ASM would be faster from the start than an equivalent code written in other language. If you can manage to efficiently use the registers then even a normally written ASM code will straight away out perform any compiler generated code in terms of speed. And if you use other tricks as well (efficiently utilizing the cache, parallelization, out of order execution, loop unrolling and the list goes on) then the performance gains are huge. Here is the performance comparision of different 68000 CPU emulators emulating Puzzle Bobble(on NeoGeo). This data was gathered from my Nugen emulator. Given is the average time to emulate one frame by running a set number of frames. The C emulators were compiled with MSVC 7.1 compiler with maximum optimization settings. Here are the times:

Musashi (in C): 0.637 milliseconds
C68K (in C): 0.564 milliseconds
A68K (in ASM) : 0.179 milliseconds

Note that A68K can be optimized even further. When not in ASM, you usualy have find another way (which is more complex and sophisticated usually) to do the same thing and achieve the same performance. There are other gains as well, like code size. TurboEngine compiles(and assembles) to 68.5 KB executable right now.

When someone declares that they want to make a completely "cycle accurate" emulator they're saying that, from the start, they don't necessarily care about just making the emulator compatible. That even if 100% of all games created worked perfectly they would not be content if something was not accurate.

I can't say what other think but I think if all games are not working (which worked on real hardware) then its not accurate and there is something that needs to be corrected. I do care about the compatibility. Everything that works on real hardware should work on the emulator as well (without using hacks of course). If you read the Regen 0.85's history.txt file you'll find out that I went to great lengths just to make a small demo work which would run on real hardware but not on Regen due to incorrect timings.

If users care about speed then they'll probably pick the emulator that already plays all of the games over yours that is much slower due to being more accurate, and if they pander to the accurate emulators for whatever then they probably won't care about speed.

Wouldn't it be perfect if they could have both? And what about those who actually want both? My rule is to always see things from the end user side and not as a developer. And if you had a poll or something, I am pretty sure every user will select speed and accuracy over just speed or just accuracy.

My emulator right now is not strictly cycle accurate, but I designed it so it could be, and the changes that would be necessary to make it so (with respect to PSG, timer initiation, and VDC) are relatively trivial, and I'm all but certain that they would have a minimal impact on speed. Right now my pure C emulator also sounds like it's much faster than your emulator that incorporates ASM, unless Regen has gotten a few orders of magnitude faster over the course of its development.

Maybe your emu would runs faster than mine, but as you said you are not running cycle-accurate, mine is (CPU and VDC timing things only). The render is line by line. And yes, Regen has gotten faster than it was before. You can check out the most oldest version (0.2) and the most newest one (0.85) and compare their speeds. You will find about 2x increase of speed. The latest one 0.91 (unreleased yet) is even more faster than 0.85 by about 63.5% in nearly all games that use YM2612. For example in Sonic 3D, Regen 0.85 gives average 402 FPS on my PC compared to 0.91 which gives an average of 633 FPS under same settings. You can compare the FPS yourself when I release 0.91.

Your giving the impression that anything written in ASM is either not accurate or not any faster than C which, no offense, seems naive to me. I would convert my code to C only if someone asked me to port the emu to a non-x86 platform. And btw, where can I download your emulator from? (for Windows).

stay safe,

AamirM

 

[Exophase]

I never said that anything written in ASM would be faster from the start than an equivalent code written in other language. If you can manage to efficiently use the registers then even a normally written ASM code will straight away out perform any compiler generated code in terms of speed.

Strong register utilization doesn't mean nearly as much on x86 as it used to. For instance, the author of nullDC reported that completely disabling register allocation from his recompiler only resulted in a 9% reduction in speed. It's not difficult to see why this is - a decent and wide enough modern out of order CPU can keep the load/store units busy while work is being done so that registers are loaded on demand. This only becomes a more serious issue if you don't have enough registers to hide load-use latency, if you are strongly memory dependent in your typical operations, or if the icache footprint gets out of control.

I've done enough x86 ASM coding (a lot, actually) to know that it's not necessarily trivial to beat a good compiler anymore.

And if you use other tricks as well (efficiently utilizing the cache, parallelization, out of order execution, loop unrolling and the list goes on) then the performance gains are huge.

Efficiently utilizing the cache - is higher level than ASM and should apply to your C coding
parallelization - I'll give you this one, because auto-vectorization isn't good, but I'll be damned if you can apply this to a CPU interpreter at all. For C code you can use intrinsics.
Out of order execution - The CPU does this, not you..
Loop unrolling - compilers are good at this...

I'm not convinced from your list.

Here is the performance comparision of different 68000 CPU emulators emulating Puzzle Bobble(on NeoGeo). This data was gathered from my Nugen emulator. Given is the average time to emulate one frame by running a set number of frames. The C emulators were compiled with MSVC 7.1 compiler with maximum optimization settings. Here are the times:

Musashi (in C): 0.637 milliseconds
C68K (in C): 0.564 milliseconds
A68K (in ASM) : 0.179 milliseconds

Note that A68K can be optimized even further. When not in ASM, you usualy have find another way (which is more complex and sophisticated usually) to do the same thing and achieve the same performance. There are other gains as well, like code size. TurboEngine compiles(and assembles) to 68.5 KB executable right now.

I do (and did) admit that CPU interpreters can have special benefits from being in ASM that most other programs do not, especially with flag calculation (okay, that's the main one). However, I don't see how your comparison is at all fair given that you're comparing completely different interpreters.

A much more fair comparison: my ARM CPU core for Temper is very efficient and performs well under less than 2x what the C one does. GCC outputs much worse code for ARM than it does for x86, so I think your comparison is incredibly loaded.

I can't say what other think but I think if all games are not working (which worked on real hardware) then its not accurate and there is something that needs to be corrected. I do care about the compatibility. Everything that works on real hardware should work on the emulator as well (without using hacks of course). If you read the Regen 0.85's history.txt file you'll find out that I went to great lengths just to make a small demo work which would run on real hardware but not on Regen due to incorrect timings.

You said games, not some random demo no one cares about. Face it, getting demos like this to work only secures bragging rights, much like making a tiny executable then strapping it to x86 only. I think much of the time these demos are made JUST to trip up emulators.

Wouldn't it be perfect if they could have both? And what about those who actually want both? My rule is to always see things from the end user side and not as a developer. And if you had a poll or something, I am pretty sure every user will select speed and accuracy over just speed or just accuracy.

But you don't have both. Regen is not competitive in terms of speed amongst the fastest Genesis emulators, and from what you're describing, your PCEngine emulator is considerably slower. You're sacrificing huge amounts of speed for accuracy (possibly much more than is necessary to get the same levels) and then are trying to reclaim relatively tiny portions of it by writing things in ASM.

Maybe your emu would runs faster than mine, but as you said you are not running cycle-accurate, mine is (CPU and VDC timing things only). The render is line by line. And yes, Regen has gotten faster than it was before. You can check out the most oldest version (0.2) and the most newest one (0.85) and compare their speeds. You will find about 2x increase of speed. The latest one 0.91 (unreleased yet) is even more faster than 0.85 by about 63.5% in nearly all games that use YM2612. For example in Sonic 3D, Regen 0.85 gives average 402 FPS on my PC compared to 0.91 which gives an average of 633 FPS under same settings. You can compare the FPS yourself when I release 0.91.

You don't have a cycle accurate PSG? Oh, then mine is as cycle accurate as yours. And is strictly a line renderer.

Surely I believe that you have improved the speed, because it was really not that fast when you first released it; of course if you start off with something inefficient it's easy to make it faster. The fps you give sound high, but you don't say what your machine is like. It's probably a good 40x or more faster than the Pentium 75 I had that could run a lot of Genesis games surprisingly well.

I think the more meaningful comparison would be your fps vs what they'd be in a C version of your emulator, but one doesn't exist so it can't be made.

Your giving the impression that anything written in ASM is either not accurate or not any faster than C which, no offense, seems naive to me.

It's not my fault that you completely misinterpreted everything I said because no where did I give any kind of impression that writing in ASM meant less accuracy, I said that it's more difficult to write straightforward code which is important for getting accuracy right, and I think pretty much any other emulator author would agree with me. Obviously it CAN be done, you're just making things harder for yourself. You're also pushing away preservation which is the main thing a lot of accuracy zealots are interested in. Of course ASM can be faster than C as well, but it's not an automatic win for every platform/compiler. That's really not the point. It's more that by focusing on accuracy from the start you tend to incur speed hits where that can only recoup a tiny amount of by writing ASM. That's probably why the emulators out there for platforms like Genesis (that have high compatibility but oh noes might not run 1 out of 50 games correctly or might not correctly emulate some demo no one cares about) are written in C now.

I would convert my code to C only if someone asked me to port the emu to a non-x86 platform. And btw, where can I download your emulator from? (for Windows).

Okay, port it to a non-x86 platform.

My emulator isn't available for Windows, so you don't get a download. If you want to play it get a GP2X.

 

[AamirM]

Hi,

You know what, we are not going to agree with each other on this one so its pointless to continue it (at least here on this PC-Engine thread). I can give you many examples and you can give me too. Its just that our experiences, when writing emus, have contradictory results. I understand what your trying to say and I do agree with you in some cases. But I still think one can reclaim large amounts of speed by rewriting things in well written ASM while you do not. Maybe I am too bad a C coder and you're good at it.

If you want, we can discuss this somewhere else because I don't want to de-rail this nice thread. I just came here to write a PCE emu, thats it .

Okay, port it to a non-x86 platform.

Although I don't have anything non-x86 but I'll write the PSG in C because you requested.

stay safe,

AamirM

 

[Exophase]

Okay, while we're on the subject of PSG, I've been trying to get LFO to sound more correct. I'm not really sure what the problem is... but based on tests + recordings people have done this is the best info I have right now: shift register is by 0, 2, or 4 (this agrees with the patent, not psg.txt) but does overflow into the upper 4 bits of the 12bit frequency (this doesn't agree with the patent). I don't know how overflow is handled within 12bits (saturation or wraparound). Effective LFO frequency is a multiplication of register $808 and channel 1 frequency like both documents say. $808 values of 0 is probably like 0x100.

I only know of three games right now that use LFO (having tested all HuCard games and about half of all CD games), for HuCard:

Hani in the Sky - vibratto during title screen
Juuoki - sound effects

And for PCE CD:

Flash Hiders - sound effects, LFO is used very prominently

Getting Hani in the Sky to sound correct doesn't seem to be very troublesome, I can give you a recording someone made of the title if you want it. Flash Hiders still doesn't sound correct, according to my tester, so I don't really know what the problem is there.

 

[AamirM]

Hi,

Thanks for the information on LFO. In my testing of very few games, my emulator shows that the game Bullfight is also using the LFO (very less though) so you might want to test that too. I'll also would like that recording of Honey in the Sky.

stay safe,

AamirM

 

[AamirM]

Hi,

If somebody wants to try TurboEngine, head to here. Its not much though.

stay safe,

AamirM

 

[Exophase]

Hi,

If somebody wants to try TurboEngine, head to here. Its not much though.

stay safe,

AamirM

Hm, for me it's running pretty slowly and the audio is quite jumpy (doubt it's a speed issue, it's an AthlonX2 2GHz). Or at least I really hope it isn't a performance problem because that'd be really embarrassing... hm, maybe there's a way to unthrottle it and show FPS, because I'd like to compare it with Temper (the much less optimized PC version)

It doesn't have a heuristic for bit swapped USA ROMs either, I see. And it seems to fake SuperGrafx support? Games boot but clearly are not being rendered correctly. You're also not emulating the sprites per line limit (After Burner 2 is a really obvious example of this)

Here are some bugs from SOME games I tested (I didn't test even close to all of them) - I'll ignore the lack of LFO since you said you're not doing it yet.

5 in 1 Famicom emulation - buggy scrolling in from bottom with Donkey Kong 3 (Temper has this problem too, but I can toggle it to be fixed - it's because it isn't setting the timer cycle intervals fresh when the timer is turned on)
Battle Royale - does nothing, this game is waiting for TIM to be -1
Blodia - stalls (are you delaying IRQs after cli?)
Body Conquest 2 - hangs
Bravoman - graphical glitches, might be sprite priority related
Bouken Danshakan Don Sunheart Hen - horrible high pitched sound from its use of freq 1
Cadash - graphical bug on title screen
Daichikun Crisis Do Natural - broken graphics
Dragon's Curse - color and priority glitches
Fighting Run - glitchy sprites due to no 2bpp sprite support (Temper doesn't either though)
Final Soldier/special edition - stalls
F-1 Pilot - you said this was fine but it's not supposed to jump like that
Gai Flame - graphics are broken
Idol Hanafuda Fan Club - stalls
Impossamole - glitchy graphics
Jackie Chan's Action Kung Fu - stalls
Legendary Axe 2 - pressing start breaks the game
Mahjong Gakuen Mild/Touma Shiro Tojo - glitchy graphics
Makai Hakkenden Shada - locks up while walking around
New Adventure Island - stalls
Order of the Griffon - bottom part gets cut off, not handline mid-screen resolution changes correctly
P-47 The Freedom Fighter - very glitchy graphics
Power Gate - bottom portion scrolls a scanline early
Street Fighter 2 - doesn't work, you're probably not handling the bank switching for it though
Strip Fighter 2 - glitchy status display and whatnot
Turrican - no title screen graphics
Violent Soldier - title has line error, in-game line is scrolling incorrectly in middle (are you emulating low clock speed mode?)
Yo Bro - glitchy graphics (you should ignore out of bounds VRAM writes)

No offense but I think these are a lot of bugs, indicating a lot lower than 97% compatibility unless that just means that it's possible to play the game, and even then I'm not at all sure...

EDIT: Adding some more as I find them.

 

[AamirM]

Hi,

Yeah, its not great right now. In fact, I should say its pretty lame right now and I myself am not very proud of it. I just released because some people asked for it and I wanted to show how far I've gotten (which is not much) and so it can be tested as well (like you did a bit). There ARE bugs/missing things in it, if it wasn't clear from the readme. But I'll fix them when I know how to (you've already told a few fixes, thanks). By compatibility, I mean the game boots and runs (ignoring the glitches, which are are present in almost every game) and is very much playable. The games which don't run at all, in my testing, are:

Blodia
Body Conquest II
Champion Forever
Cyber Core
Double Dungeons
Download
Final Soldier
Idol hanafuda fan club
Jackie Chan (Action Kung Fu)
Kyuukyoku Mahjong Idol Graphic
Kyuukyoku Mahjong Idol Graphic II
PC Pachi-Slot 777

You've pretty much hit most of these games. If you find others by all means tell me. I'll rewrite all of the renderer and VDC timings after I finish up some stuff that I've started on Regen.

Hm, for me it's running pretty slowly and the audio is quite jumpy (doubt it's a speed issue, it's an AthlonX2 2GHz). Or at least I really hope it isn't a performance problem because that'd be really embarrassing... hm, maybe there's a way to unthrottle it and show FPS, because I'd like to compare it with Temper (the much less optimized PC version)

Thats odd. I have a 733 Mhz P3 and its running pretty good on it. I don't know why my code always has problems running on Athlons . Anyways, you can use the Backspace key to unthrottle it but there is no FPS display though. If you want, I can upload one which does.

It doesn't have a heuristic for bit swapped USA ROMs either, I see. And it seems to fake SuperGrafx support? Games boot but clearly are not being rendered correctly. You're also not emulating the sprites per line limit (After Burner 2 is a really obvious example of this)

Shit, I forgot to undefine SYS_SGX . Yep, sprite per line limitation isn't implemented. Thats because I am drawing sprites in reverse order to partially emulate sprite priority.

No offense but I think these are a lot of bugs

Yes, I know. You can't expect a Magic Engine/Mednafen quality emulator at the first go. I made it in three days working about 2-3 hours each day. I implemented as much stuff as I could to run/boot most games. It would seem there are many things which are simple enough that they should've been added but there are reasons they aren't there (besides the obvious one that they didn't work correctly). Again, as I said above, VDC timings and renderer are to be fully rewritten later on. Its just mostly a proof of concept right now .

stay safe,

AamirM

 

[Exophase]

Okay, when I hit backspace it does indeed go super fast. So I think the bug is in your synchronization code somehow. Are you using vsync? Because my refresh rate is not a multiple of 60Hz, it's 75Hz. Also, it uses 100% CPU time on one core when throttled. Regen does this for me too though. Actually, it appears Regen has the same throttling problem. I turned on "print FPS" but the onscreen messages just appear as garbage so I can't tell what it's running at.

I have some notes on some of the games that aren't working, if there's a debugger accessible I can possibly confirm it for you to help you fix them.

I would be hesitant to call some of the games that go in-game as playable though.

Anyway, good luck with the VDC timings - no documentation lists mid-line timings which are of course important. I have a test that gets numbers for some things that I had ran on a PCE-CD system to determine some timings. This did fix glitches in most games but unfortunately some persist. I can give you those numbers some time, although I want to do more tests.

 

[AamirM]

Hi,

Okay, when I hit backspace it does indeed go super fast. So I think the bug is in your synchronization code somehow. Are you using vsync? Because my refresh rate is not a multiple of 60Hz, it's 75Hz. Also, it uses 100% CPU time on one core when throttled. Regen does this for me too though. Actually, it appears Regen has the same throttling problem. I turned on "print FPS" but the onscreen messages just appear as garbage so I can't tell what it's running at.

I am not using vblank for timing. As for the messages problem in Regen, turn off Superfast rendering if its turned on and restart the emu and try again. Are you using NVidia Forceware 93.71 drivers? Because there is a problem in it which makes messages appear garbage. I've uploaded a build of TurboEngine which displays FPS (in the title bar) here

I have some notes on some of the games that aren't working, if there's a debugger accessible I can possibly confirm it for you to help you fix them.

There is no debugger atm. I am debugging the hard way right now. The biggest problem in timing right now is that interrupts are happening a bit early. I did added support for delaying interrupts one instruction because of the reason you mentioned in your post here (After Burner II works because of this) but I think its not working 100% correctly. Anyways, you can post your notes on the games here and I can try them out myself.

I would be hesitant to call some of the games that go in-game as playable though.

Me too . But at least they run. Thats important to me.

Anyway, good luck with the VDC timings - no documentation lists mid-line timings which are of course important. I have a test that gets numbers for some things that I had ran on a PCE-CD system to determine some timings. This did fix glitches in most games but unfortunately some persist. I can give you those numbers some time, although I want to do more tests.

One thing I wanted to ask was whether VRAM to sprite buffer transfer interrupt occurs 2 or 4 lines after vblank? Both of these seem to work very well but I haven't tested it much. Right now it occurs two lines after vblank in TE.

Thanks again for your help and constructive criticism.

stay safe,

AamirM

 

[Exophase]

One thing I wanted to ask was whether VRAM to sprite buffer transfer interrupt occurs 2 or 4 lines after vblank? Both of these seem to work very well but I haven't tested it much. Right now it occurs two lines after vblank in TE.

This I do not know, what I do know is that almost nothing relies on it. I can write up a test to find out how many cycles it takes, hopefully exactly. Or, at least, when the flag goes high, finding exactly when the interrupt hits would be trickier.

EDIT: That crafty Charles MacDonald already figured this out afterall, it's 1024 dot clocks. That's 3 scanlines in VDC mode 0.