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


zx-81

Certified Guru
Joined
Apr 5, 2007
Messages
679
Age
50
Location
Earth
Website
zx81.zx81.free.fr
dingux-hugo-v110.jpg


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

Member
Joined
Apr 15, 2008
Messages
168
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

Member
Joined
Apr 15, 2008
Messages
168
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

Nothing good will ever come of Exophase.
Joined
Sep 21, 2006
Messages
10,308
Age
37
Location
Cleveland OH
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

Certified Guru
Joined
Apr 5, 2007
Messages
679
Age
50
Location
Earth
Website
zx81.zx81.free.fr
PolloLoco said:
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.

PolloLoco said:
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.


exophase said:
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 ;).


exophase said:
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.

exophase said:
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 :).
 
Last edited by a moderator:

Exophase

Nothing good will ever come of Exophase.
Joined
Sep 21, 2006
Messages
10,308
Age
37
Location
Cleveland OH
zx-81 said:
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.

zx-81 said:
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.
 
Last edited by a moderator:

zx-81

Certified Guru
Joined
Apr 5, 2007
Messages
679
Age
50
Location
Earth
Website
zx81.zx81.free.fr
Exophase said:
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.


Exophase said:
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 :).
 
Last edited by a moderator:

A600

Certified Guru
Joined
Mar 9, 2003
Messages
368
@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

Certified Guru
Joined
Apr 5, 2007
Messages
679
Age
50
Location
Earth
Website
zx81.zx81.free.fr
A600 said:
@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 ?).
 
Last edited by a moderator:
Top