Questions on developing a Mega Drive emulator

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Questions on developing a Mega Drive emulator

Post by Stef » Tue Aug 23, 2016 5:47 pm

Honestly I would have even removed hilight/shadow, interlacing modes (both of them) and SMS compatibility just for a doubled palette :p The linked sprite list is a nice idea but not really easy to take advantage of to be honest..

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Questions on developing a Mega Drive emulator

Post by Sik » Tue Aug 23, 2016 10:02 pm

Surprised you didn't mention window in that list :P (its main use was as a horizontal HUD and you probably could achieve the same with a raster effect)
Sik is pronounced as "seek", not as "sick".

Near
Very interested
Posts: 109
Joined: Thu Feb 28, 2008 4:45 pm

Re: Questions on developing a Mega Drive emulator

Post by Near » Wed Aug 24, 2016 12:32 am

Yeah, to me, 9-bit color is the most obvious misstep. I would even be okay with the same number of palettes ... but it's really evident how cramped 9-bit color is. 12-bit would have really helped liven things up.

So ... I'm still having some trouble understanding the window layer. I followed the docs as best I could, and came up with this:

For register writes:

Code: Select all

  //window plane horizontal position
  case 0x11: {
    if(!data) {
      //disable
      io.windowHorizontalLo = ~0;
      io.windowHorizontalHi = ~0;
    } else if(data.bit(7) == 0) {
      //left
      io.windowHorizontalLo = 0;
      io.windowHorizontalHi = ((data & 31) << 4) - 1;  //width is by two cells, or 16px
    } else {
      //right
      io.windowHorizontalLo = ((data & 31) << 4) - 1;
      io.windowHorizontalHi = ~0;
    }
    return;
  }

  //window plane vertical position
  case 0x12: {
    if(!data) {
      //disable
      io.windowVerticalLo = ~0;
      io.windowVerticalHi = ~0;
    } else if(data.bit(7) == 0) {
      //up
      io.windowVerticalLo = 0;
      io.windowVerticalHi = ((data & 31)) << 3) - 1;  //height is by one cell, or 8px (todo: interlace stuff?)
    } else {
      //down
      io.windowVerticalLo = ((data & 31)) << 3) - 1;
      io.windowVerticalHi = ~0;
    }
    return;
  }
And then for each pixel rendered, where state.y = 0-239, state.x = 0 - 319:

Code: Select all

  bool windowed = true;
  windowed &= state.x >= io.windowHorizontalLo && state.x <= io.windowHorizontalHi;
  windowed &= state.y >= io.windowVerticalLo   && state.y <= io.windowVerticalHi;
  //replace planeA with window when windowed==true
  auto& planeA = windowed ? this->window : this->planeA;
And of course, in the actual background layer, I don't apply VRAM horizontal scroll or VSRAM vertical scroll adjustments for the window plane.

In some things (vdpdoc.bin), it seems to work fine. In others (Altered Beast), it seems to obstruct plane A when it shouldn't.

Anyone see any obvious mistakes with this? :/

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Questions on developing a Mega Drive emulator

Post by Sik » Wed Aug 24, 2016 1:21 am

Wouldn't it be easier to just check against the coordinate in the register and then flip the condition when the register's MSB is set?
Sik is pronounced as "seek", not as "sick".

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Questions on developing a Mega Drive emulator

Post by Stef » Wed Aug 24, 2016 8:11 am

byuu wrote:Yeah, to me, 9-bit color is the most obvious misstep. I would even be okay with the same number of palettes ... but it's really evident how cramped 9-bit color is. 12-bit would have really helped liven things up.
For me the number of palette is the first hit, look at the PCE which is using the same 9bit RGB color encoding but with more palette, it definitely helps a lot (SF2 is a good example). Still having 4+4 palette and 12 bit RGB would have been ideal. And i believe they could get it without raising costs by removing useless features... in fact it looks like the interlace modes consume quite a bit of die space as the possible 128 KB VRAM configuration but SMS compatibility is probably the one using the most. I remember back in time i always though the SMS compatibility was really useless, i mean, why would you want to play old SMS games on your Megadrive when you can play far better 16 bit games ?? Also the SMS adapter was released quite late for me... and costed almost the same price that a brand new SMS2 (in France the SMS adapter was about 450 Fr when the SMS2 costed between 490 Fr up to 590 Fr depending the period).
Anyway we can't redo the story :p

Near
Very interested
Posts: 109
Joined: Thu Feb 28, 2008 4:45 pm

Re: Questions on developing a Mega Drive emulator

Post by Near » Wed Aug 24, 2016 1:51 pm

Yeah, I never understood why these consoles added interlace modes. They look atrocious.

The SNES would have been just fine without RPM Racing; and the Genesis just fine without Sonic 2-player mode. Even as a young kid I remember thinking about how awful it was playing in Sonic 2-player mode, so we never did that.

Besudes, Uniracers showed that you could do 2-player split screen without interlace and it'd be just as good anyway. And Rock 'n' Roll Racing showed that the game would be *way* better without the interlacing.
Wouldn't it be easier to just check against the coordinate in the register and then flip the condition when the register's MSB is set?
Sik and I worked on this last night until I got too tired to continue. We still can't quite get this working, though =(

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Questions on developing a Mega Drive emulator

Post by Stef » Wed Aug 24, 2016 2:29 pm

byuu wrote:Yeah, I never understood why these consoles added interlace modes. They look atrocious.

The SNES would have been just fine without RPM Racing; and the Genesis just fine without Sonic 2-player mode. Even as a young kid I remember thinking about how awful it was playing in Sonic 2-player mode, so we never did that.

Besudes, Uniracers showed that you could do 2-player split screen without interlace and it'd be just as good anyway. And Rock 'n' Roll Racing showed that the game would be *way* better without the interlacing.
Wouldn't it be easier to just check against the coordinate in the register and then flip the condition when the register's MSB is set?
Sik and I worked on this last night until I got too tired to continue. We still can't quite get this working, though =(
Well in fact i played a lot the sonic 2 versus mode when i was young with my brother :p but still i believe they could made it with normal mode without too much hit on gameplay.
Another game is using interlaced mode on MD: https://youtu.be/Omu-zI0HKu4?t=199
For this one, the interlaced mode helped a bit more to anticipate the direction to take as the game speed is really fast...
Still some games as Skidmark does split screen without interlacing and it works pretty nicely (but game speed and map size are lower obviously).
Anyway not a big deal, only 2 games on MD and 1 on SNES...

Near
Very interested
Posts: 109
Joined: Thu Feb 28, 2008 4:45 pm

Re: Questions on developing a Mega Drive emulator

Post by Near » Wed Aug 24, 2016 2:57 pm

There's a few menu screens on the SNES that use interlace mode, but it's pointless. Progressive fonts are perfectly legible too.

...

Figured out windowing, finally. Many, many thanks to Sik!

Code: Select all

  //window plane horizontal position
  case 0x11: {
    io.windowHorizontal = data.bits(0,4) << 4;
    io.windowHorizontalDirection = data.bit(7);
    return;
  }

  //window plane vertical position
  case 0x12: {
    io.windowVertical = data.bits(0,4) << 3;
    io.windowVerticalDirection = data.bit(7);
    return;
  }

Code: Select all

  auto windowedX = (state.x < io.windowHorizontal) ^ io.windowHorizontalDirection;
  auto windowedY = (state.y < io.windowVertical  ) ^ io.windowVerticalDirection;
  auto windowed = windowedX || windowedY;
  auto& planeA = windowed ? this->window : this->planeA;
What's weird is that H=00, V=00 disables the window. But H=00, V=1C makes it take up the entire screen. So you really do need the || instead of && on that final windowed test.

Onto the next bug ... Altered Beast isn't responding to any gamepad inputs. Sonic, Project MD, Crazy Bus are.

EDIT: and found it. When reading Up/Down/A/Start, d2/d3 went unused, so I had those bits as 0s. When at the end I returned latch<<7|select<<6|(~data&0x3f), it was setting those two bits. That was breaking the input. Setting them to 1, so that they return 0 from the read function, fixes input.
Last edited by Near on Thu Aug 25, 2016 2:41 am, edited 1 time in total.

Huge
Very interested
Posts: 197
Joined: Sat Dec 13, 2008 11:50 pm

Re: Questions on developing a Mega Drive emulator

Post by Huge » Wed Aug 24, 2016 10:39 pm

byuu wrote:There's a few menu screens on the SNES that use interlace mode, but it's pointless. Progressive fonts are perfectly legible too.
Yeah but on the SNES you are heavily limited in colours and background layers if you use the interlaced mode. On the Megadrive you are pretty much only limited by whether you have enough VRAM to fill up the twice as big screen with enough graphics. That probably explains why it was only used in split-screen games officially. Unofficially, one of the Censor picture demos also run in interlaced mode.

And it looks fine on the TV as long as you don't sit too close to it (which you should not do anyway).

Flygon
Very interested
Posts: 60
Joined: Mon Sep 28, 2009 11:26 am
Contact:

Re: Questions on developing a Mega Drive emulator

Post by Flygon » Thu Aug 25, 2016 10:56 am

Huge wrote:Yeah but on the SNES you are heavily limited in colours and background layers if you use the interlaced mode. On the Megadrive you are pretty much only limited by whether you have enough VRAM to fill up the twice as big screen with enough graphics. That probably explains why it was only used in split-screen games officially. Unofficially, one of the Censor picture demos also run in interlaced mode.

And it looks fine on the TV as long as you don't sit too close to it (which you should not do anyway).
Non-expert opinion wandering in here. The Interlaced Mode makes a lot more sense, considering this, when you remember the 128kb VDP RAM mode.

It makes sense, really. Still, drawing an entire games worth of anamorphic artwork would've been quite interesting. And, with modern TVs, having to deinterlace that stuff is a terrible process.

Post Reply