Page 4 of 14 FirstFirst ... 23456 ... LastLast
Results 31 to 40 of 134

Thread: PC-Engine

  1. #31
    Emulator Developer
    Join Date
    May 2006
    Posts
    215
    Mentioned
    1 Post(s)
    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.


  2. #32
    Dolphin Developer
    Join Date
    Feb 2004
    Posts
    66
    Mentioned
    0 Post(s)
    Quote Originally Posted by blueshogun96 View Post
    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)

    Quote Originally Posted by Exophase
    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.
    Stop reading signatures and get a life


  3. #33
    Emulator Developer
    Join Date
    May 2006
    Posts
    215
    Mentioned
    1 Post(s)
    Quote Originally Posted by xtra krazzy View Post
    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.

  4. #34
    Emulator Developer
    Join Date
    May 2006
    Posts
    215
    Mentioned
    1 Post(s)
    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 ^_^

  5. #35
    Emulator Developer
    Join Date
    May 2006
    Posts
    215
    Mentioned
    1 Post(s)
    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...

  6. #36
    Dolphin Developer
    Join Date
    Feb 2004
    Posts
    66
    Mentioned
    0 Post(s)
    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)
    Stop reading signatures and get a life


  7. #37
    Emulator Developer
    Join Date
    May 2006
    Posts
    215
    Mentioned
    1 Post(s)
    Quote Originally Posted by xtra krazzy View Post
    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.

  8. #38
    Dolphin Developer
    Join Date
    Feb 2004
    Posts
    66
    Mentioned
    0 Post(s)
    Quote Originally Posted by Exophase View Post
    I've seen some really slow implementations of sound in emulators.
    Really? Where?
    Stop reading signatures and get a life


  9. #39
    Emulator Developer
    Join Date
    May 2006
    Posts
    215
    Mentioned
    1 Post(s)
    Quote Originally Posted by xtra krazzy View Post
    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 by Exophase; January 7th, 2008 at 19:22.

  10. #40
    Emulator Developer ShizZy's Avatar
    Join Date
    Feb 2005
    Location
    RI, USA
    Posts
    758
    Mentioned
    0 Post(s)
    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....
    ~****Zy

    6Bit.net Emulation & Gaming | Forums
    Gekko GameCube Emulator

Page 4 of 14 FirstFirst ... 23456 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •