:) It’s great emulator, but Air Zonk is not working, can you fix that? :mad:
Printable View
:) It’s great emulator, but Air Zonk is not working, can you fix that? :mad:
To everyone having problems with certain games, here's a hint: there was never a game called "Air Zonk" released in Japan. Most PC Engine emulators are only setup to read dumps from Japanese chips.
Illegal: Isn't the source for DGEN floating around somewhere? I could've sworn that someone recently released a dodgy port of it for the Slim... If you know of any experienced developers who have a good reason for needing the source straight from syn-z then I'd be happy to try and get in touch for them. Until then I'd rather not bother him since I wouldn't know what to say -- half the time when people ask me to contact someone they show little follow through (!_!)
My understanding is that U.S. HuCards had an encryption on them that caused emulator problems...There are ones out there that have that encryption taken care of..but still seems a few have issues either from the encryption or errors form the decryption maybe? I have never had the wrestling game work in anything but a PC emu...name escapes me at the moment...has funny looking characters.
And while Air Zonk has worked on the PCE PSP emu for me it seems to stutter and sometimes freeze up...
Keep in mind I'm absolutely NO expert and this is just what I have been told/learned over time....I still don't know how to go about upgrading my firmware (which version etc...)
But the Turbo and 2600 emu's are essentially what I am afraid of losing if my PSP ever dies....I had the TurboExpress and loved it (had console,Express,TV Tuner and over 90 Hucards...sold it for $300...big mistake)...I still miss it...but while playing it on the PSP doesn't feel the same...the better screen size and all the cards without a bunch of cards is still remarkable....
In that case then doesn't everything I said apply to the version you modified? Or did it come with a readme? If it did you shouldn't be distributing it without it. If it didn't then it should have one (and I'm guessing, again, that this is not an originally done emulator)Quote:
Originally Posted by Illegal Machine
The encryption in some USA TG16 games is very simple. If you look at the source of Hu-Go you can see it pretty plainly.. so there's no good reason for emu authors not to implement it (should take a few minutes at most).Quote:
Originally Posted by Poem58
Actually I was referring to the rom of the game having the encryption and there was a program awhile back to strip the encryption out for emu's...I think that is what has some buggy roms floating around and I forget what emu but there was one in the past I used that only supported PCE roms...UNLESS you used the program to strip the US encryption...I never got the US games to work on it....
I only mentioned this as a guess as to why just a couple of games sometimes work in HuGo but not other emu's...etc...
I am not qualified to look at source code...
I'm still trying to find a volunteer to PM me with advice as to what Custom FW to install and where the directions are so I don't lose emu and can play new games (currently on 3.03OE after a long time of research so I didn't mess it up):o
Is there any way to go back to the game list once you choose a game? I've been exiting and going back in...
On the issue of TG-16/PC Engine TurboChip/HuCard compatibility:
The US TG-16 games aren't encrypted. They simply had a different pin configuration that wouldn't allow you to simply stick a US game in a Japanese console, or vice versa. The data simply appears encrypted when it's been dumped with a rom dumper that has the Japanese pin configuration. Has Exophase said already though, this is EXTREMELY easy to fix for emulators that haven't taken this situation into consideration. In addtion to HuGo, MESS also has an algorithm to automatically compensate for incorrectly dumped ROMs. I've compiled a command-line tool (originally strictly for personal use) for OS X that will "fix" incorrectly dumped TurboChips, if any OS X users are interested.
Exophase:
I know that you implemented a system to dynamically load only the needed portions of a GBA ROM that's too large to fit entirely into memory for gPsp, are you at all familiar with how hard it would be to do that with PCE CD data tracks? As far as I can tell, that's the biggest hurdle in improving e[mulator]'s compatibility, and I'm rather keen on getting a fully functioning PCE emulator scrapped togeather for the PSP. Even if it means eventually picking the project up myself.
They are.Quote:
Originally Posted by EvilDooinz
Cloudy
Thanks, I didn't know that it was due to using a Japanese ROM dumper. The algorithm is very simple (to "unencrypt" the ROMs). It's referred to as "USA encryption" in the Hu-Go source.Quote:
Originally Posted by b8a
Dynamically loading the CD-ROM into memory is at the very least a lot more efficient than doing it for a cartridge since the CD-ROM isn't on the address space. When you think about it, a PSP can load from memory stick a ton faster than a 1x CD-ROM can load from CD (probably at least 10x faster), so it shouldn't be necessary to heavily buffer the CD-ROM image.Quote:
Originally Posted by b8a
If you're interested I'm up for talking about PC-Engine emulation.. if you wanna find me somewhere *_*
Thanks for the info Exophase. I'm not exactly savy about the practical issues involved with writing an emulator, but I do know that from a simple coding standpoint, it doesn't sound at all difficult to simply seek into an iso data track and fetch the needed data at any given point (which is the only way I could think of achieving this without reading the entire file into memory), I guess I just figured that there would be too much overhead involved with constantly opening the file. The original hardware almost certainly had less RAM than the PSP though, so it's probably just sufficient to open the data track(s) at the same in-game events that the PC Engine would normally access the disk anyway. Even though the PCE had some serious load time issues, like you mentioned, it should still be much quicker to load the data from the memory stick, and only doing so at the same times that the original hardware did deffinitely should not result in any noticeable file access overhead. ...But then again, this approach sounds so elementary that I wonder if it isn't already implemented in the emulator...
I'll have to set aside some free time in the near future to have another look at the source code and see if I can't make enough sense out of it to tell if something similar isn't already implemented. It might take me a little while to get enough free time, but I'll try to get in touch with you once I've had a chance to get familiar with the basic code layout.