Turbografx Emulation

[slaanesh]

Glad to hear that, Exophase. The real benefit of this new handheld should be to make 8 and 16-bit console emulation dramatically more accurate and improve on the experience with better controls/screen/battery life....

And I really doubt that NES emulation is slow, that goes against everything I've heard on the matter as well, and I just can't see how people would put up with that this long. Are you sure you aren't imagining this, or are you just very, very out of date?


GPFCE is a brilliant emulator for the NES and is IMHO very accurate. One of the few handheld NES emus that can run Elite correctly. I have had no problem running anything that I throw at it though I haven't tried Castlevania III which is supposed to be finicky?

One of the most amazing PC Engine emulators I know of is PCEAdvance - PC Engine on the GBA! It's really amazing considering the host system has a 17Mhz CPU.
I know that it makes use of GBA capabilites using native character mode and sprites so there's a big saving in terms of video rendering as the hardware takes care of most of this.


@ Exophase: Are you including CD emulation?

 

[StealthBagel]

I'm not trying to do a super accurate emulator, it's important that it runs very well on GP2X. Fortunately I think you have an exaggerated idea of what's necessary for accuracy in emulation. Usually it doesn't cost much more, although there will usually be a few games that require such a thing.

I'm mostly just a stickler for accurate audio since it's usually hard to screw up the rest too badly, unless you cross over into incompatibility territory where games don't even run correctly.... Graphical problems like color vibrancy being off from the real deal is pretty minor and you have to expect an emulator not to look like the real deal on a TV or what have you... But glaring flaws like the lack of horizontal interrupt-based palette switching on MD emulators do bother me. I agree though, speed is the most important, but it shouldn't cripple the experience either.

I think with this new handheld there is a lot of power on tap to make the experience as rich as possible, and especially taxing emulators can have options to let the user make the tradeoff between accuracy and CPU time utilized, and therefore battery life....

What's so inaccurate about SNES emulation on handhelds anyway? I haven't heard about it myself but I thought it was more that it was slow under certain conditions (which is entirely expected), not inaccurate.

It's not usually; I meant the lack of implementation of some graphical elements like transparencies or such for the sake of speed. But they aren't unsupported, just disabled usually... a big problem on the DS and GBA SNES emulators is lots of games have broken graphics, over half of them, probably due to slow work in accelerating the renderer by using the system's native hardware.... which is an advantage that cannot be overlooked and the new handheld stands to take advantage of, if developers will put in the time to effectively utilize it... compare how the DS SNES emulators achieve dramatically faster performance with a CPU that is almost 4 times slower than the Gp2x's, thanks to it..... but of course it's much more work than porting an emulator in C from the PC and therefore compatibility is only slowly improving...

GPFCE is a brilliant emulator for the NES and is IMHO very accurate. One of the few handheld NES emus that can run Elite correctly. I have had no problem running anything that I throw at it though I haven't tried Castlevania III which is supposed to be finicky?

One of the most amazing PC Engine emulators I know of is PCEAdvance - PC Engine on the GBA! It's really amazing considering the host system has a 17Mhz CPU.

That is quite a feat indeed.... I'm not saying GPFCE is bad, just that at the time I stopped using my gp2x, which wasn't very long ago, it was a slow C port and didn't even have an ASM based 6502.... so it wasn't very snappy and you had to run at 200 MHz+ to see good performance..... there's really no reason for that with how simple the NES hardware is, how simple the PPU is, and how low-end the CPU is... there were a number of complaints about it actually, and because people were so infatuated with what new things the Gp2x could do the Gp32 couldn't, the NES got comparatively little attention from developers. I'm not trying to say it ran at 20 fps or something. Don't read too much into it.

 

[Exophase]

GPFCE is a brilliant emulator for the NES and is IMHO very accurate. One of the few handheld NES emus that can run Elite correctly. I have had no problem running anything that I throw at it though I haven't tried Castlevania III which is supposed to be finicky?

On NES timing is a huge, huge deal I think :/ I'd hate to try going for high compatibility there. On the other hand, it doesn't have all of the horrible VDC timing variables PC-Engine does. Castlevania III could be mapper related in addition to timing things.

One of the most amazing PC Engine emulators I know of is PCEAdvance - PC Engine on the GBA! It's really amazing considering the host system has a 17Mhz CPU.

I haven't used it but from what I've heard (and a video I've seen) calling it impressive would be a gross understatement. I think it does show that a lot of PCE games aren't using the CPU even close to its full potential. Idle loop detection could probably work a lot of the time.

PCEAdvance uses a very optimized interpreter, but I want to actually use a dynarec. Maybe. It's just very tempting is all :B (I wouldn't have thought so but I came up with a lot of justifications)

I know that it makes use of GBA capabilites using native character mode and sprites so there's a big saving in terms of video rendering as the hardware takes care of most of this.

It does help (it also prevents certain things :/)..

The nice thing about PC-Engine is that the graphics are actually very simple. With a well optimized renderer it should be much faster to render than Genesis or especially SNES. In fact, it should only be somewhat more intensive NES. Only one layer, color depth doesn't really matter. There's a lot more sprite real estate though.

@ Exophase: Are you including CD emulation?

In the first release definitely not. If I can get around to it I might make an attempt to do it on the x86 build. Unfortunately I can't test that on a real GP2X because I only have NAND to work around in. In fact, I can't do much testing in general so I'll need some dedicated testers anyway.

SuperGrafx is probably slightly easier than CD (now that I said that I'm sure I'll find it hell)

 

[notaz]

But glaring flaws like the lack of horizontal interrupt-based palette switching on MD emulators do bother me.

You bother on things you don't bother making sure of.

 

[StealthBagel]

On NES timing is a huge, huge deal I think :/ I'd hate to try going for high compatibility there. On the other hand, it doesn't have all of the horrible VDC timing variables PC-Engine does. Castlevania III could be mapper related in addition to timing things.

Mappers do make things ugly... probably not slow though. Just tricky for the developer getting it just right.... as far as mappers go fortunately most of them are now well understood. The biggest hangup for me again is audio accuracy. Fortunately the NES has such a simple audio generator, now that it's been so thoroughly reverse engineered there's not much excuse for bad NES audio anymore.

QUOTE

I haven't used it but from what I've heard (and a video I've seen) calling it impressive would be a gross understatement. I think it does show that a lot of PCE games aren't using the CPU even close to its full potential. Idle loop detection could probably work a lot of the time.

I would wonder what games such performance was exhibited in... the PC Engine games I own work the system's CPU quite hard, Air Zonk is the biggest culprit.

QUOTE

The nice thing about PC-Engine is that the graphics are actually very simple. With a well optimized renderer it should be much faster to render than Genesis or especially SNES. In fact, it should only be somewhat more intensive NES. Only one layer, color depth doesn't really matter. There's a lot more sprite real estate though.

I agree. The CPU is basically the NES' at a higher clockrate (it's also CMOS, IIRC, not NMOS)... and the PPU isn't that complicated to my knowledge. And no mappers. It's too bad the PC Engine, like other less popular consoles (I'm looking at you Sega saturn, Atari Lynx, and many more) were really left out in the cold emulation wise so the developers who take on such projects have a fresh road ahead of them, not like NES, MD, SNES, etc. where there are lots of people who went before and can provide info on how to implement things in an emulator for that platform effectively.

QUOTE
In the first release definitely not. If I can get around to it I might make an attempt to do it on the x86 build. Unfortunately I can't test that on a real GP2X because I only have NAND to work around in. In fact, I can't do much testing in general so I'll need some dedicated testers anyway.

I do hope you can get around to the CDROM games. Either way, I've got quite a bit of PCE hardware now, both a PC-Engine Duo and a PC-Engine CoreGrafx II, and a large variety of games. I'd be more than happy to compare the graphical and audio accuracy when you have test builds together..... and of course when we have these shiny new handhelds in our hands.

But glaring flaws like the lack of horizontal interrupt-based palette switching on MD emulators do bother me.

You bother on things you don't bother making sure of.
Using the gp2x I don't have anymore, that would be a difficult thing to 'make sure of'.... I respect the work you've done, it's quite impressive from what I've seen, and I'm not trying to deny your work either.... I was making generalized observations on accuracy in general and that was an example off the top of my head. You don't need to get rude about it.

 

[Exophase]

Mappers do make things ugly... probably not slow though. Just tricky for the developer getting it just right.... as far as mappers go fortunately most of them are now well understood. The biggest hangup for me again is audio accuracy. Fortunately the NES has such a simple audio generator, now that it's been so thoroughly reverse engineered there's not much excuse for bad NES audio anymore.

Mappers can add a lot of functionality like event IRQs but they probably don't add too much to emulation speed. You do have to carefully consider how to put everything together from the start probably..

I would wonder what games such performance was exhibited in... the PC Engine games I own work the system's CPU quite hard, Air Zonk is the biggest culprit.

I wonder how well Air Zonk runs on PCEAdvance, if it does at all.. Games like this might seem like they're using a lot of CPU power but they aren't necessarily. Shooters only need to do collision detection on bullets against the player and enemies onscreen and usually there aren't that many enemies around. PC-Engine can only display 64 hardware sprites no matter what, it can't switch sprites midframe, so there will definitely be less bullets than that.

So if you look at CPU time, there are ~7.1 million CPU cycles per second, that's about 120,000 per frame, instructions take around 4 cycles each on average so 30,000 instructions per frame, to perform collision detection, sound, bullet paths, parallax things, and some other less serious things. The latter two are probably done with a lot of tables which the CPU is decently good at, sound probably takes a constant percentage of CPU time since it's tied to a timer IRQ every 1024 CPU cycles (maybe something like 10-20%).. It wouldn't really surprise me if this game and other "demanding" ones have plenty of CPU to spare. Now if the game was rendering rudimentary 3D that'd be a different story. Some Genesis games actually do and the CPU is actually a lot slower than PC-Engine's in terms of average instructions per second, but they are instructions much better suited to 3D rendering.

I agree. The CPU is basically the NES' at a higher clockrate (it's also CMOS, IIRC, not NMOS)...

PC-Engine's CPU is very underrated. Even though it's only 8bit it can still churn out nearly twice as many instructions per second than SNES's CPU, and it does have a number of additional features over NES's. It's not really a problem but it can't be as lazily implemented as an NES CPU interpreter. When it comes to emulation number of instructions per second usually dominates emulator performance for CPU emulation, even if those instructions are limited.

and the PPU isn't that complicated to my knowledge.

It really isn't, unfortunately the VDC timing is really problematic for a lot of games -_- Other than that I'd say it's even simpler than NES because it isn't nearly as "weird", although like other platforms it is planar so you do have to tile cache.

And no mappers.

Luckily NEC had the good sense to use a CPU that had memory translation built in, even if it was still an 8bit 65xx derivative.

It's too bad the PC Engine, like other less popular consoles (I'm looking at you Sega saturn, Atari Lynx, and many more) were really left out in the cold emulation wise so the developers who take on such projects have a fresh road ahead of them, not like NES, MD, SNES, etc. where there are lots of people who went before and can provide info on how to implement things in an emulator for that platform effectively.

PC-Engine really did get good emulators for PC, even early on Magic Engine was fairly compatible and performed very well on my Pentium 75MHz (which is kind of shocking when I think about it, that should mean that GP2X can do it fine at under 150MHz perhaps...)... these days Ootake, Mednafen, and Hu-Go are quite robust PCE emulators. But you have to wade through a lot of pretty bad emulators before you find them. And the docs are just not there for these platforms, I don't really know where some emu authors get their information.

I do hope you can get around to the CDROM games. Either way, I've got quite a bit of PCE hardware now, both a PC-Engine Duo and a PC-Engine CoreGrafx II, and a large variety of games. I'd be more than happy to compare the graphical and audio accuracy when you have test builds together..... and of course when we have these shiny new handhelds in our hands.

I hope so too. But I only really care about getting this emulator working well on GP2X. For Craiginator I'm sure a direct port of something will suffice. We'll see.

 

[geise69]

I'm not sure if this is of any help, but you can maybe try this site. You might already know about it, but thought it was worth giving the link to it. His name is Malducci on the pcenginefx.com forums. He's done quite a bit of pc-engine homebrew and is quite knowledgeable of the system. He might know where to get extra info for you.

 

[DaveC]

Using the gp2x I don't have anymore, that would be a difficult thing to 'make sure of'.... I respect the work you've done, it's quite impressive from what I've seen, and I'm not trying to deny your work either.... I was making generalized observations on accuracy in general and that was an example off the top of my head. You don't need to get rude about it.

Well you constantly bring up things that are a non-issue anymore such as raster interrupts in Megadrive and slowness in NES. Since you don't have or care about the GP2X maybe you should only mention problems that you know still exist. The only thing wrong with NES now are some incompatibilities such as SMB3 turning to mush after awhile, MD is pretty much perfect.

 

[TyBO!]

The only thing wrong with NES now are some incompatibilities such as SMB3 turning to mush after awhile, MD is pretty much perfect.

Glad I'm not the only one who had problems with SMB3! I'm at a point in the game where when I enter a certain level, Mario immediately falls into a bottomless pit and there's no platform nearby to save me. It's definitely a compatibility issue.

I've also had a couple instances where Picodrive will freeze on me, but it's usually avoidable (you can skip the part of the level where the game freezes), and Picodrive freezes much less frequently (as in, hardly ever) than DrMD did.

Not to sound too nit-picky, or ungrateful. I use Picodrive and GPFCE more than any other emus on my GP2X. Those two programs alone make the GP2X worth buying.

 

[kfuse]

I use picodrive myself a lot. Shinobi 3 FTW!!! anyways yea I just hope turbografx here picks up a little bit at least so I can play past the 2nd level of blazing lasers...

 

[StealthBagel]

Mappers can add a lot of functionality like event IRQs but they probably don't add too much to emulation speed. You do have to carefully consider how to put everything together from the start probably..

Yeah, I would see CPU IRQs adding more complexity for the developer than actual expensive operations to the program. Most mappers do very simple things like allow a status bar to display stationary with a scrolling BG, or parallax, etc. Some do get complicated, like some that add new sound channels care of the Famicom's audio in/out pins on the cart slot-- not present on NES... but I understand these are few and far between.

You know something that would be great to see while I am thinking about it, is FDS support on a Gp2x/Mystery Handheld NES emulator.... such a rare feature for NES/FC emus in general.

I wonder how well Air Zonk runs on PCEAdvance, if it does at all.. Games like this might seem like they're using a lot of CPU power but they aren't necessarily.

I base what is 'stressful' on the PCE's CPU on what causes noticeable slowdown indicating the game's issued instructions aren't being fully executed by the CPU between vblanks.... frequent in Air Zonk. Seems the most intensive bits are the complex movement paths for objects, like enemies and boss elements. There's some really neat things going on movement-wise....

QUOTE
PC-Engine's CPU is very underrated. Even though it's only 8bit it can still churn out nearly twice as many instructions per second than SNES's CPU, and it does have a number of additional features over NES's.

Right. Well, 6502 is a good architecture and all that crippled the SNES' was the low clockrate; not much of an upgrade over the NES CPU. 6502 based architecture, 1.79 Mhz vs. the typical SNES CPU clock, 2.68 MHz, the 3.58 MHz clock was rarely used... I Recall a few other bottlenecks like the 8-bit bus, though since 65c816 didn't seem to really benefit from being a 16-bit part except for having a wider address range. Could be wrong on that. Also, doesn't the SNES CPU halt everytime there is a DMA transfer? That would explain all the 'load time' on SNES games, with the extra long intro credits sequence. I'm looking at you Turtles in Time....

Well you constantly bring up things that are a non-issue anymore such as raster interrupts in Megadrive and slowness in NES. Since you don't have or care about the GP2X maybe you should only mention problems that you know still exist. The only thing wrong with NES now are some incompatibilities such as SMB3 turning to mush after awhile, MD is pretty much perfect.

Constantly is a bit of an exaggeration isn't it? ...... either way understood, but don't get yourself so worked into a frenzy about someone who might not be as well versed on gp2x software as you... some of us have more pressing concerns than compatibility of emulators on handhelds we have long since sold... my statements were general suggestons for future improvement of emulators and not criticisms so no need to take a defensive stance....... especially since you didn't write the emulators. Choose your battles man

 

[Tobriand]

<snip>

my statements were general suggestons for future improvement of emulators and not criticisms so no need to take a defensive stance....... especially since you didn't write the emulators. Choose your battles man

I think they were taken badly principally because the examples you bring up have been sorted out as of about a year ago.

The "glaring flaw" of "lack of horizontal interrupt-based palette switching on MD emulators" doesn't exist anymore, and therefore is redundant as an example, despite being mentioned at least three times by you, as I recall.

 

[hercule18]

Hi Everybody,

Does anybody had news about Exophase Pc Engine Emu?

I bought a GP32 specially because of GPengine, because i sold few years before my PCE-GT (I'm Dumb, i know)

this emu really rocks, for sure!!! but lacks of 1 things to me, Autofire!! Savestate is a plus but not necessary (according to me)

I bought my Gp2x, for NeoGeo Emu and being sure that a good Pcengine emu would be there too.

Me dreams came true with Gngeo2x, but i'm still searching a good emu as Gpengine had been for GP32.

Gp2xengine, Hu6280 are very good but compared to Gpengine they don't stand the distance.I'm not a coder

I don't have this talent, and I guess people who worked these 2 previous emu, did it hard and with talent, the

the problem is that a lot of projects are started and nerver finished.

So please exophase, give us some news!! (good wood be better for us )

I really hope you'll to the end of your project.

Bye

Herc. h34r:

 

[Exophase]

Okay, I'll give some news.

Just an overall idea of what my work on this has been like: mainly I work hard for a few days then do very little for a few weeks. It's hard to really stay motivated on this project for some reason so it has been taking a long time.

Still, it's actually pretty close to being ready for a first release (at least, it seems that way). I've got the ARM Hu6280 core "done", it just needs some more debugging to fix the final lingering bugs to make games not crash at random places. It's fast enough that I don't think any games will be under fullspeed at 200MHz, and with idle loop detection and more heavy optimizations it should eventually work okay at well under 200MHz. Since "fast" PC-Engine emulation isn't really a new thing I'd like to aim towards REALLY fast. But I'll try to get a version out that's "fast enough" before that.

Compatibility is high, although I introduced a couple bugs recently that I need to fix. Basically, something like 98-99% of games are fully playable, but a few percent have graphical glitches.

Sound is pretty good, it doesn't have any filtering but it seems accurate. Digital audio can get kinda noisy for me right now, I have to determine if idle loop elimination has made it worse because it seemed fine.. it's hard to pinpoint because it still seems fine most of the time. It could be my speakers or headphones too.

It's totally lacking in anything aside from the emulation, like menus and save states. I'll probably crunch on these as it approaches maturity.

 

[slaanesh]

I'm keenly waiting for this to be released. I've got a hoard of real PC Engine games that I'd love to play again on a handheld. Despite my real PC Engine out and ready to play, I just find it hard to use due to other family commitments. A good GP2X version would be very much appreciated!

 

[naples39]

It's fast enough that I don't think any games will be under fullspeed at 200MHz, and with idle loop detection and more heavy optimizations it should eventually work okay at well under 200MHz.

Sounds great.

 

[Vince2501]

Okay, I'll give some news.

Just an overall idea of what my work on this has been like: mainly I work hard for a few days then do very little for a few weeks. It's hard to really stay motivated on this project for some reason so it has been taking a long time.

Still, it's actually pretty close to being ready for a first release (at least, it seems that way). I've got the ARM Hu6280 core "done", it just needs some more debugging to fix the final lingering bugs to make games not crash at random places. It's fast enough that I don't think any games will be under fullspeed at 200MHz, and with idle loop detection and more heavy optimizations it should eventually work okay at well under 200MHz. Since "fast" PC-Engine emulation isn't really a new thing I'd like to aim towards REALLY fast. But I'll try to get a version out that's "fast enough" before that.

Compatibility is high, although I introduced a couple bugs recently that I need to fix. Basically, something like 98-99% of games are fully playable, but a few percent have graphical glitches.

Does this include CD support?

 

[Exophase]

Does this include CD support?

No.

 

[Rivroner]

I suppose that include CD support in the future will not be a problem

Thank you very much for the work Exo

 

[hercule18]

Hi Exophase,

Many thx for these updates!!

I'm looking forward to see your work.

Bye

Herc. h34r:

PS:I you have a paypal account leave it in the forum, may be some of us, really excited by this emu,
could help you with some bucks