What's new

PC-Engine

OP
E

Exophase

Emulator Developer
I'm back from a convention I was at. I had some sound stuff implemented but it wasn't working in most games. Turns out my timer code was busted. I actually wrote 1024 * 768 where I meant to write 1024 * 3 (embarrassing, I know.. I think my brain is on auto a lot of the time).

Then I redid the audio. I decided on the output frequency stepping afterall. This was a good move since the FM capability doesn't seem to be used much and I think I was overreacting to the cost of the divides anyway. If the divides are too much of a problem for the normal frequency settings then a 4096 entry table can be used. I actually haven't even encountered a game that uses LFO..

And I implemented DDA (which sounds alright) and noise (which doesn't sound entirely right). I need better docs on how noise works.

Still lots of little bugs preventing a lot of games from working right but it's getting closer to release quality. I might start working on a GP2X version soon.
 
OP
E

Exophase

Emulator Developer
Here's something kinda horrible I encountered. A surprisingly large number of games (a few percent of the ones I tested) are doing this. Near the beginning of an interrupt handler a cli is being done right before the interrupt is actually acknowledged. As far as I was aware this should cause the CPU to go into an infinite loop of receiving that interrupt, which is exactly what was happening on my emulator. This is not the case. I can only imagine that due to the partial pipelining of the CPU interrupts do not actually trigger until the instruction after the cli has completed. This might not be the case for plp and rti (both of which modify flags as well and can thus enable interrupts) since they take more cycles.

This shouldn't be too hard to fix, but it's pretty annoying. Things like this just make me want a dynarec more.
 

Cyberman

Moderator
Moderator
Interesting this is one of those pipeline delay things people take advantage of. I am not certain why they would use it if they didn't absolutely need to do that however. Like in the MIPS there are a number of instructions that can execute before a branch that is taken after the branch instruction ocures, this is in a way a similar thing.

That is kind of funny though that they were doing that. I can't see the benefit off hand but I'm sure you might be able to think of something.

Cyb
 
OP
E

Exophase

Emulator Developer
Lots of little fixes and strenuous testing... I haven't kept great track of everything and I've looked at Ootake and Mednafen's source a lot. Actually, my render timing right now is mostly like Mednafen's. Some games are still bugged, but compatibility should be somewhere around 95%. I'm going to have a beta tester go through it as much as possible, then I'll begin moving it where I originally intend to have it on, GP2X.
 

aprentice

Moderator
Lots of little fixes and strenuous testing... I haven't kept great track of everything and I've looked at Ootake and Mednafen's source a lot. Actually, my render timing right now is mostly like Mednafen's. Some games are still bugged, but compatibility should be somewhere around 95%. I'm going to have a beta tester go through it as much as possible, then I'll begin moving it where I originally intend to have it on, GP2X.


wow, 95% compat is pretty good, nice job :p
 
OP
E

Exophase

Emulator Developer
As I mentioned in the NES thread, I'd post here what happened to this emulator.

Its name is "Temper", which stands for Turbografix EMulator PEr Request, and it came into being because people using the GP2X handheld wanted a better emulator. The few out either had significant compatibility/feature problems or were too slow, so I aimed to make one that was both fast and compatible.

My first release was last weekend and my second release will probably be tomorrow. The core PC-Engine emulation is pretty good, and it's pretty fast, thanks to having an optimized ARM CPU interpreter and part of the video code in ARM ASM as well. I'd still like to continue optimizing it though. There are a few compatibility problems but nothing too major.

Next big step is to support PCE-CD and SuperGrafx. Unfortunately there isn't a lot of documentation on the former, so I've been looking through the source of the current emus for it and contacting people in the PC-Engine emulation/demo coding scene to try to gather info. I'll post whatever documentation I can write up from these sources.

Quick primer on the CD-ROM addon, for some reason called CD-ROM^2:

- Single speed CD-ROM which is capable of playing CD-DA audio directly from the CD drive at 44.1KHz, 2 channel (stereo), 16bit per sample. Like a standard CD player.
- Has a SCSI like interface for transferring data.
- 64KB of general purpose RAM is added and accessible in a previously invalid area of address space.
- There's an ADPCM unit which plays back samples encoded in OKI ADPCM format (4 bits per sample). There's a special 64KB of RAM dedicated to this unit: games DMA ADPCM from CD-ROM to this RAM, then the ADPCM chip can output from it. I think some games use this RAM as general purpose as well (pushing memory through ports to it). The algorithm is supposed to be optimized for voice, so that's probably what it's used for most of the time (as opposed to music). I figure with CD-DA playing the CD-ROM is being used at 100% capacity, so you can't stream in anything else at the same time anyway, and have to preload all this stuff.
- 2KB of backup RAM. Actually, some PC-Engine games let you use this too, if it detects the add-on. I would have implemented just this already, but I have save states so it isn't really a big deal.
- The cartridge port takes system cards which give BIOS functions to the games. Version 3.0 also adds 192KB of RAM, forming "Super CD-ROM^2." Most released games were actually for this configuration and not for the original. This RAM is, of course, accessed in the cart space.

So you can see it offers a lot more RAM (which it needs to because there's no more addressable ROM for the game) and audio features, as well as a ton of storage. And offers nothing in the way of enhanced graphics or processing power, unlike the Sega CD add-on. Fortunately that makes it less painful to emulate.. in theory anyway.
 

AamirM

New member
Hi,

I'll be giving a shot at writing an accurate PC-Engine emulator after I finish some stuff with Regen. Do you have some of your own docs/notes on it? I see there are a few things you have written here but it would be nice to have them at one centralized place. Also would be nice if you could point out some wrong/inaccurate things from Charles MacDonald's docs.

stay safe,

AamirM
 
OP
E

Exophase

Emulator Developer
Hi,

I'll be giving a shot at writing an accurate PC-Engine emulator after I finish some stuff with Regen. Do you have some of your own docs/notes on it? I see there are a few things you have written here but it would be nice to have them at one centralized place. Also would be nice if you could point out some wrong/inaccurate things from Charles MacDonald's docs.

stay safe,

AamirM

I don't think anything is wrong with his documentation, it just isn't absolutely complete. But unless you have a PC-Engine yourself that you can code tests for I don't think you're going to be able to solve the mysteries that no PCE emulators do, like the VDC timing nuances.
 

AamirM

New member
Hi,

If there are chinese clones of PC-Engine they might be available here. I'll see. Anyways, do any games use these timing nuances? Can you name a few ones? Last time I checked, I thought Magic Engine could run all the games.

And btw, what things is Charles MacDonald's docs missing? (so I'll try figure them out from some emu sources).

stay safe,

AamirM
 
OP
E

Exophase

Emulator Developer
Hi,

If there are chinese clones of PC-Engine they might be available here. I'll see. Anyways, do any games use these timing nuances? Can you name a few ones? Last time I checked, I thought Magic Engine could run all the games.

No real point getting a cheap clone PC-Engine (that may not even have the same timing anyway) when you'll need to get an expensive flash card to get things on it... you're better off getting a real TurboDuo and writing CDs for it.

Most of the glitches are lines being off by one, usually in an unstable way, and sometimes causing the screen to shake. The ones that go bad vary depending on the emulator and where it decides to trigger RCR IRQs relative to the scanline, and where it latches BXR/BYR, probably some other things. So doing something to fix one may break another. Changing the number of cycles per scanline may influence things too....

Bear in mind that emulators like Ootake use many per-game hacks to get around this. Magic Engine may do the same. The emulator used on Virtual Console appears to as well.

These are the HuCard games that my emulator has glitches in:

Final Soldier: title screen and start screen shake
Pachiokun: shaky intro screen with glitchy middle line
Devil Crash: line below status at top is incorrect
F1 Pilot: screen shakes a bit - note that this game is not even using RCR IRQs but is instead cycle counting for lines
Wonder Momo: top of title is repeated, screen is glitched during curtain fall

There are probably some others I'm forgetting..

My tester has only tested about half of all CD games so I don't know for sure what the story is there, plus I've probably forgotten some anyway, but I'm all but certain that VDC timing issues are causing Popful Mail to completely break during cutscenes, and this is something that plagues all emulators. Ootake uses very elaborate hacks to get around it; if you overclock to something like x4 all the time you can probably escape it.

Another thing to look out for are a few games that rely on DMA timing somewhat, which we also don't really have tests for. Riot Zone for instance appears to write to VRAM that DMA is working on simultaneously.

As far as CD is concerned, I have to warn you that none of the emulators really handle it within the same tolerances as the real machine. I tried writing my own low level CD-ROM code (not using the syscard) and while it worked on all of the emulators it did not work on the real machine and I simply was not able to fix this. At least one game, Steam Hearts, which uses custom CD routines, may be broken because of this (no emulator emulates this correctly either, Magic Engine has a hack for it and so does Temper for that matter, although not a per-game hack per se)

And btw, what things is Charles MacDonald's docs missing? (so I'll try figure them out from some emu sources).

stay safe,

AamirM

CPU timing, PSG, peripherals, most things about CD/ADPCM. Charles did write a great cycle level CPU timing doc but I don't think he posted it publicly. If you come on IRC (efnet) I can invite you to a channel where you can talk to the man himself about it, and other PCE homebrew devs.

For PSG there's a good doc on romhacking.net. Peripherals you can find a lot of information about on archaicpixels, and for CD/ADPCM.. I have some documents that mirror what I did in Temper that I can give you after I expand them slightly and fix some errors.
 

AamirM

New member
Hi,

Thanks for the help. I completed reading Charles pcetech.txt today. VDC and VCE are pretty stright forward to implement, although there is some obscure things like palette flickering, blur bit (VCE control, which games use this?), VRAM dot widht (again, any games use mode other than 0?). I will probably add CD-ROM, Supergrafx emulation later on. Btw, does the current MAME's 6280 core has correct flag calculation/cycle count (i think not)? Thats because I'll be using that as reference for my own CPU core.

I'll come to the IRC when I can actually run games with my emu (Racing Spirits is on top of the list of games to run :) ). By then I'll know much more then I do now. Unitl then I'll keep asking things here. Once again, thanks for the help.

stay safe,

AamirM
 

AamirM

New member
Hi,

This was a bit tougher than I thought this should be. Anyways, after some trying and debugging I have got quite many games (including Racing Spirits) running accurately. Some screenshots below:

rsco0.png


Racing Damashi running almost perfectly.

ab2nc9.png


After Burner II runs perfectly.

wmkz5.png


Wonder Momo runs perfectly too.

Still needs loads of work on it though. VDC emulation is missing inter-sprite priority and CPU core still has a few bugs. I will be working more on this as I get some time. Any suggestions for a name of this emulator? I've named it Turbo Engine for now :) .

stay safe,

AamirM
 

AamirM

New member
Hi,

Yep, VDC timing delay is not implemented yet. I hope it doesn't break anything even after its done. Thanks for the info though. Can you tell me of any game that uses wierd resolutions and/or uses the blur bit?


I have also partially implemented the PSG. But I have left probably the most simplest thing in it, the DDA mode which is similar to YM2612 DAC. When I implemented DAC in my YM2612 core in Regen I noticed that most games have very tight loops that send the data to it to achieve very high rates. This creates the problem that some samples get missed because before I could play them, the buffer get overwritten with other data. I noticed this problem in almost every emulator and I want to avoid it here. So how should I update sound buffer to avoid this problem?

stay safe,

AamirM
 
Last edited:

AamirM

New member
Hi,

I added the cycle delay on VDC/VCE access and Wonder Momo still runs correctly. Although the text displayed like 'ACT 1' has gotten below but I thinks it right where it should be because Magic Engine displays it at the same position too.

The only game that has not worked so far is Final Soldier. I haven't looked what its doing but I am almost certain its due to wrong interrupt timing (probably timer interrupt).

Anyways, is there any other accurate PSG implementations available besides the Mednafen's and Ootake's?

stay safe,

AamirM
 

malducci

New member
So how should I update sound buffer to avoid this problem?

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.
 
OP
E

Exophase

Emulator Developer
Hi,

I added the cycle delay on VDC/VCE access and Wonder Momo still runs correctly. Although the text displayed like 'ACT 1' has gotten below but I thinks it right where it should be because Magic Engine displays it at the same position too.

Are you implementing the delay for the transfer instructions too?

The only game that has not worked so far is Final Soldier. I haven't looked what its doing but I am almost certain its due to wrong interrupt timing (probably timer interrupt).

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.

Anyways, is there any other accurate PSG implementations available besides the Mednafen's and Ootake's?

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

Top