Dingux-Hugo: Pc Engine Emulator For Dingux V1.1.0

[zx-81]

Hi All,

Hu-Go is a famous emulator of NEC PC Engine console, running on many system such as Linux and Windows. (see http://www.zeograd.com/ for details)

Dingux-Hugo is a port on Dingoo/Dingux of my latest PSP version of Hu-Go.

How to use it ? Everything is in the README.txt file.

Sources are included, and this package is under the GNU public licence v2, read COPYING.txt file for more information about it.

Many new features have been added compared to original Hu-Go version, have a look to the README for details.

You can find it here : on my blog

Enjoy,

Zx.

 

[PolloLoco]

Awesome, I love your PSP port - I'll have to try this on my Dingoo in a few hours. That said, the one feature I'd like that wasn't available on the PSP (that I know of) is autofire selectable to 1 or 2 buttons. A lot of PC Engine games almost required it - because there were switches on the TG16 controllers to enable it.

 

[PolloLoco]

OK - I've played it now, and for one thing - this is the fastest PCE/TG16 emulator for the Dingoo A320. Everything that worked played fullspeed.

Games like the Bonk series and Splatterhouse played perfectly - the only thing missing was the aforementioned autofire. I did find glitches in the following games:

1) Legendary Axe 2 - Constant screen flashing makes the game unplayable.
2) Keith Courage - The sprites kept disappearing when certain backgrounds are available. It happens right away and makes the game unplayable.
3) Neutopia 2 - Weird music bug, the music is slow.
4) Rastan Saga 2 - In most emulators it won't work, but it does on yours! However, there's a weird screen wrap issue - where the picture is shifted to the right, and what belongs on the right is now on the left.

 

[Exophase]

Sounds good zx81, guess this means I don't have to fix up Temper for anyone to try to port. I was looking at the authors list and was surprised to find Laurent had contributed.

I'm curious about the "overclock" option. It would appear you are using it to reduce the number of cycles executed per scanline. You should instead perform some kind of idle loop elimination. Most HuCard games have idle loops that are easily detected, I think the number is at least 85%. For the ones that don't it might not be a good idea to manually underclock them anyway.

 

[zx-81]

Awesome, I love your PSP port - I'll have to try this on my Dingoo in a few hours. That said, the one feature I'd like that wasn't available on the PSP (that I know of) is autofire selectable to 1 or 2 buttons. A lot of PC Engine games almost required it - because there were switches on the TG16 controllers to enable it.

Yes, i could add it. You can already do it if you remap the B button to fire2, because auto-fire always press Dingoo 'B' key.

OK - I've played it now, and for one thing - this is the fastest PCE/TG16 emulator for the Dingoo A320. Everything that worked played fullspeed.

Games like the Bonk series and Splatterhouse played perfectly - the only thing missing was the aforementioned autofire. I did find glitches in the following games:

1) Legendary Axe 2 - Constant screen flashing makes the game unplayable.
2) Keith Courage - The sprites kept disappearing when certain backgrounds are available. It happens right away and makes the game unplayable.
3) Neutopia 2 - Weird music bug, the music is slow.
4) Rastan Saga 2 - In most emulators it won't work, but it does on yours! However, there's a weird screen wrap issue - where the picture is shifted to the right, and what belongs on the right is now on the left.

Thanks for your feedback, i will have a look on those issues, but it might be already present in original emu.

Sounds good zx81, guess this means I don't have to fix up Temper for anyone to try to port.

If someone wants to port temper to dingoo, i guess it will run fullspeed without any dingoo overclocking stuff . Your emu on Wiz is very fast and very accurate. Before Dingux-Hugo, i've ported Hugo to Wiz but never release it, mainly because it can't compete with your emu from speed and accuracy point of view .

I'm curious about the "overclock" option. It would appear you are using it to reduce the number of cycles executed per scanline.

Yep, it's something empirical i've found. On several games it increase speed without any graphical glitches.

You should instead perform some kind of idle loop elimination. Most HuCard games have idle loops that are easily detected, I think the number is at least 85%. For the ones that don't it might not be a good idea to manually underclock them anyway.

very good idea, i will investigate in this way .

 

[Exophase]

If someone wants to port temper to dingoo, i guess it will run fullspeed without any dingoo overclocking stuff . Your emu on Wiz is very fast and very accurate. Before Dingux-Hugo, i've ported Hugo to Wiz but never release it, mainly because it can't compete with your emu from speed and accuracy point of view .

In fact, it'd probably be slower. Temper on GP2X and Wiz benefits greatly from having ARM ASM versions for its CPU core and almost all of its video too, which helps tremendously, especially for CPU. The C core for the CPU is alright but yours is probably better since it uses goto tables and presumably opcode threading, and mine is probably not very cache friendly. I ported it to PSP once and the performance was disappointing, although maybe there were hidden factors dragging it down. The video stuff is algorithmically the same between the C and ARM versions but the ASM still manages to be much faster than what GCC produces.

I can look at your code more and see if there are any optimizations that come to mind, not sure if I'll even find anything worth bothering with.

very good idea, i will investigate in this way

Have I sent you Temper's source yet? If not, I can. I don't mind you using the same kind of idle loop detection it does if you want.

 

[zx-81]

I can look at your code more and see if there are any optimizations that come to mind, not sure if I'll even find anything worth bothering with.

Sprites stuff is taken from original emu, and it's not so good. I'm sure we can do something better. Btw, i'm using SDL stuff and i don't know if there is specific hint for the dingoo as it is the case for psp (with specific uncached memory address, or anything that can increase the speed). I've unrolled manually some loops etc ... but nothing more.

Have I sent you Temper's source yet? If not, I can. I don't mind you using the same kind of idle loop detection it does if you want.

Yep, you sent me v0.70 a long time ago . i will have a look on idle stuff, big thanks .

 

[A600]

@zx-81: how faster is a goto table compared to a switch? With cap32 and hugo you use goto tables. I tried the same "trick" with vice, the c64 emu,  but the resulting code isn't faster (maybe gcc already uses jump tables for switches?)

 

[zx-81]

@zx-81: how faster is a goto table compared to a switch? With cap32 and hugo you use goto tables. I tried the same "trick" with vice, the c64 emu,  but the resulting code isn't faster (maybe gcc already uses jump tables for switches?)

Yes, it depends of gcc version and host target you use. Afaik gcc uses jump tables, but as exophase said gcc is not always very good. On PSP it's very bad, on gp2x it's better. Generally i tested the two (switch and jump tables) and i keep the best one. It might depends of the codop you want to decode. I'm doing also instruction profiling to identify what are the few instructions that are executed the most of the time, and try to put them in the first place (they will have more chance to be in the instruction cache of the main instruction decoding loop ?).

 

[A600]

Thanks for the detailed explanation