What's new

PC-Engine

synch

New member
We should do a DS emulator together one day ^^ And by that I mean share ideas and review code.

I'm, by no means, a DS expert, there's quite a lot of pieces of the internal DS hardware that are unknown to me, because I assumed Desmume did it right. Anyway, we could some day, but right now, if I'd have to start a new emulation project, it would either be something smaller (a portable Neogeo Pocket emulator) or something bigger (Dreamcast or Saturn), but at the moment I'm still not sure :p
 

Danny

Programmer | Moderator
I'm, by no means, a DS expert, there's quite a lot of pieces of the internal DS hardware that are unknown to me, because I assumed Desmume did it right. Anyway, we could some day, but right now, if I'd have to start a new emulation project, it would either be something smaller (a portable Neogeo Pocket emulator) or something bigger (Dreamcast or Saturn), but at the moment I'm still not sure :p

Btw synch, do you plan on releasing your version of DesmuMe soon? Not trying to pressure you into a yes or no its just your version looks great :)
 

blueshogun96

A lowdown dirty shame
So zion, are you going to write a PC-Engine emu or what? :icecream:

No offense, but this thread went offtopic as soon as you started posting ;)
 
Last edited:

Danny

Programmer | Moderator
So zion, are you going to write a PC-Engine emu or what? :icecream:

No offense, but this thread went offtopic as soon as you started posting ;)

Na don't have the time to commit to it :p

I think you will find This post de-railed it mate :evil: (no offense exo :king: )

I merely continued the de-railment :p For which I apologize.

Back on topic then :)
 
Last edited:

blueshogun96

A lowdown dirty shame
Nah, don't worry about it :) Just letting you know.

@Exophase, how long did it take you to write this emulator?
 
OP
E

Exophase

Emulator Developer
Working on it for a few weeks here and there (that means some days for a few hours but more days I haven't worked on it at all -_-).. but please keep in mind it is very far from done, it is quite buggy and incomplete still.
 
OP
E

Exophase

Emulator Developer
Make it open-source and maybe you'll receive some help

I can't make it open source if it's not even out yet ;P I'll try to figure it out on my own for now, I haven't given it a lot of hard effort.

I'm not sure I ever want to make it open source because I don't want someone else taking it over without talking to me at all. I didn't think this would happen but sure enough it did last time :| I guess it's less likely to happen with PCE (especially if I don't release it for PSP, ahem) but I don't think I want to take that chance.

It's more likely I'll just send the source code to reliable sounding people who ask for it and have some kind of good reason for wanting it.
 

blueshogun96

A lowdown dirty shame
I guess I can understand. I always make my projects open source, but I never feared anyone would steal my code.
 
OP
E

Exophase

Emulator Developer
I fixed a graphical bug that was plaguing me for a while. It wasn't really clear in any of the docs I read and it isn't really intuitive at all.

Apparently, 16 wide sprites (single wide) are stored the same way 32 (double) wide ones are. What this means is that if a 16x32/48/64 sprite won't be stored as 2/3/4 contiguous patterns but there will be a pattern gap between each one. This was causing graphical errors in almost every game for me but I didn't notice it until I looked at a graphical dump of all the patterns (good thing to have I guess).

I also tried implementing raster effects. I already handle graphics on a scanline basis so I figured it wouldn't be a problem but for some reason they're not really working correctly at all. It's pretty weird. Hopefully it'll be something simple.

At least I finally did horizontal clipping for sprites. For some reason vertical clipping doesn't seem to be working though :/ (well, against the top of the screen anyway)

And some other bugs still persist. I wanted to have it mostly "working" by November (including sound) but I think there's no way that'll happen. Ah well.. at least I'm making SOME progress. Emulators are such a pain to debug.
 

xtra krazzy

Dolphin Developer
I guess I can understand. I always make my projects open source, but I never feared anyone would steal my code.

I used to be afraid I'll get scammed (which I did: Built a program for $200, only to find out it was sold in $1000 to more than 2 people), but open-source made things easier by giving me the option to show that a piece of the code was indeed mine at the date X which comes before release date Y of the other program. (Of course, I'm talking about free programs here)

Exophase said:
Emulators are such a pain to debug.

Yeah, if only every console had its own "console debugging program", which contains all kinds of stress tests (graphics-wise, CPU-wise, sound-wise and so on) presented in a row. Then all you had to do is run the emulator and wait for the next segfault. :)
 
OP
E

Exophase

Emulator Developer
Yeah, if only every console had its own "console debugging program", which contains all kinds of stress tests (graphics-wise, CPU-wise, sound-wise and so on) presented in a row. Then all you had to do is run the emulator and wait for the next segfault. :)

Haha, yeah, I wish. Not so much stress tests but validity tests. GBA actually has a lot of great tests for it, especially for the ARM CPU (armwrestler/thumbwrestler), and I had a friend who was learning GBA development who would write demo programs for me when I needed them. I guess that made everything go a lot easier. That and GBA is just better documented. And I had tons of other emulators with debuggers to compare against (with PC-Engine there's Mednafen, but it's harder to track some things that happen in a PCE game since the graphics are less direct access).

I have an idea what's causing the weird bugs in raster IRQs. I'll see if it fixes things later today.
 
OP
E

Exophase

Emulator Developer
My suspicion was correct, it was because I forgot to handle missed IRQs (when the I bit goes low again). There was another misunderstanding in my code - I figured that writing to the IRQ status cleared all status lines. Actually it only clears the timer IRQ status. Reading from the VDC status (which isn't part of the IRQ registers, so that threw me off) is what will clear the VDC IRQ status.

Now the parallax demo works well. Here's a screenshot ^_^
 
OP
E

Exophase

Emulator Developer
I fixed some other raster stuff and I tracked down a CPU bug using Mednafen. Turns out I was supposed to be setting flags after a pull instruction. I wonder if that was in the instruction table I was using as a reference >_>

That fixes some bugs, but others still persist as usual. I'm hoping that when I implement sprite 0 collide and DMA IRQs some games that don't work will. Still, the compatibility isn't terrible now, a lot of games really are working fine.

I'm going to start working on sound now. I was going to have a sound I/O logging system but I don't really think it's worth it anymore. It might end up being worth it for graphics...
 

xtra krazzy

Dolphin Developer
Why is it that in emulation sound always comes last (or at least, after the graphics)...

Well I guess I know the answer (no way to test things), but sometimes implementing sound is VERY easy (not so many opcodes, fast, asynchronous PC interface, no need to optimize), but people tend to keep it last (well, microphone support for N64 is STILL not available so there are even things with less importance)
 
OP
E

Exophase

Emulator Developer
Why is it that in emulation sound always comes last (or at least, after the graphics)...

Well I guess I know the answer (no way to test things), but sometimes implementing sound is VERY easy (not so many opcodes, fast, asynchronous PC interface, no need to optimize), but people tend to keep it last (well, microphone support for N64 is STILL not available so there are even things with less importance)

The problem with sound is that it's very difficult to determine what exactly is wrong with it when something is. When a picture is on the screen it's a lot easier to spot problems. And it's not going to be fast if you don't do it right. I've seen some really slow implementations of sound in emulators.
 
OP
E

Exophase

Emulator Developer
Really? Where?

Okay, for instance, rendering samples at the rate of the audio clock (which is usually in the MHz, in the case of PC-Engine it'd be 3.58MHz) then downsampling that to the output rate (in the KHz, something like 44.1KHz is typical, less can be offered too). This is how Hap does it and recommends doing it in the NES thread. Doing it this way is obviously both simple and very accurate but at a huge speed hit. For high-frequency noise it's definitely the most obvious way to do it.

There are less extreme examples of sound cores that can be very sub-optimal as well. For instance for PS1's SPU or any wave synth kind of playback with compressed voices, not caching voices and not playing several samples in a row when possible. These platforms actually have a very high polyphony and if you don't optimize it you won't get good speed (which is fine on PCs now but I guarantee that Sony's PS1 emulator for PSP and Bleemcast for DC had more optimized SPU implementations than that).

Also have to consider that a lot of platforms have secondary CPUs that are either exclusive for sound or near exclusively used for sound that don't need to be emulated until later. This is often bundled with sound emulation. SNES is an obvious example.

Then you have to consider a high level of timing accuracy necessary to handle real-time streaming sound for platforms that support it but don't have any kind of buffering provided for it. Even on platforms with small buffers like GBA synchronization can still be very painful (which is why most GBA emulators actually have pretty bad sound). Synchronization in general is important if you want the audio to not start skipping over itself. Of course, this is a good place to get the emulator properly synchronized anyway.

For gpSP I did manage to sample at the output rate directly, and it sounds good. But it's a mess because it has to deal with a lot of fixed point arithmetic and there are more divisions than I'd like. For a platform with frequency modulation this just isn't going to work well at all (especially for one with any real amount of it like Genesis). PC-Engine only has one FM channel, but this is still enough to not want to have to do things like I did them before.

So there's kind of two "directions" to do this in, both involve iterating counters. One is to iterate through a position that maps from the destination stream to the source streams. To do this you have to transform the frequencies from their natural rate to the destination rate. With FM you have to do this a lot, and since you end up with fractional values you will end up accumulating error. It's best to use fixed point even if you have floating point (unless you have very fast conversion to integer) because you'll be using the counter to index the source data. So, for every 1 step you take in the destination frequency, you take an F step in the source data which is some fixed point frequency value that has been converted from a natural frequency. One advantage of using this method is that you can perform interpolation on every source channel since you're doing fractional steps through it.

The other way to do it is to render to a frequency that "fits" the natural frequency of the platform, which the channel frequencies calibrated to. If you render at the frequency of the clock this means decrementing the individual frequency counter by one and when it hits zero increment the source index by one, and for every iteration go up by one in the destination. The thing is, even though these machines really did render audio internally at several MHz it's not as if so much is needed (and there will be a cut off frequency thanks to low pass filters, limitations of the speakers used, and your ears).

What I'm thinking is to have an approach that's kind of inbetween the two. Instead of decrementing by one decrement by several - then the frequency you render to becomes some integer division of the natural frequency of the machine. When this value goes below zero go forward then increment it back up by the full amount. You could handle rendering directly to the output frequency you're using by having fractional steps, but this will accumulate error. If you render to a different frequency you can then resample the entire thing to the destination frequency. This will allow you to use interpolation on the final result, which is only one channel (well, two, for stereo) as opposed to all of the input channels. I don't really know which will sound better..

With this approach you could have a configurable internal sound quality. You could set the render frequency to be very low to save CPU time at the expense of quality. Or you could set it higher and see how it works out. I'm not really sure if this is a very good approach yet.. this is more of an idea.

Maybe some other people could share some of their approaches to sound emulation.

EDIT: sarencele pointed out that I was mistaken about how blargg's libraries work (so I removed that part). Sorry blargg :<
 
Last edited:

ShizZy

Emulator Developer
Really tempted to do a PC-Engine emulator, not sure why... maybe just for something different. Quite sure I wouldn't have enough time, however I'm pretty sure it wouldn't take too long to get something up and running....
 

Top