Questions on developing a Mega Drive emulator

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Re: Questions on developing a Mega Drive emulator

Post by Eke » Wed Aug 17, 2016 8:09 pm

Sik wrote:W If you attempt to, what will happen is that the first column (remember: two tiles) for plane A will reuse the same tiles as the last column of window, because it didn't fetch new tiles yet.
Sik wrote:When this is not the case though the first visible tile of plane A falls under the same column as the last visible tile of window, and hence the VDP ends up reusing the same data it fetched for that layer.
Except that's not exactly how the "window bug" behaves (and I don'think it's described in official docs, only Charles genvdp.txt). What happens is that, when plane A hscroll is not a multiple of 16, the first 2-cell column of plane A following Window plane last column (column N) will actually use plane A column N+2 instead of plane A column N+1 (so plane A column N+2 is actually displayed twice).

Charles MacDonald
Very interested
Posts: 292
Joined: Sat Apr 21, 2007 1:14 am

Re: Questions on developing a Mega Drive emulator

Post by Charles MacDonald » Thu Aug 18, 2016 4:21 pm

Bart did a good write-up on some poorly documented/undocumented aspects of the 68000 too:
https://emu-docs.org/CPU%2068k/68knotes.txt

Other quirks include:

MOVEM reading one address past the source location:
viewtopic.php?f=13&t=2010&p=25882

CLR to memory being read-modify-write

TAS doesn't work on the Genesis 1,2 but does work on the Genesis 3 (Gargoyles uses it) because the bus controller expects /AS to change on each new bus cycle, but TAS holds /AS asserted after the read extending into the write which is then ignored. So it reads from memory, but the write is ignored and work RAM doesn't get modified.

During a bus or address error the stack frame word that contains the R/W, I/N, and FC2-0 fields has all other bits set to the same value of the instruction register (marked undefined in the manual).

For test cases: Hard Drivin' is an easy game to get running first as it uses no DMA, the Dragon Slayer games use invalid playfield sizes in-game, unlicensed EA games (Budokan, etc.) use H40 mode with the wrong combination of RS1,RS0 set, Batman & Robin sends partial commands (one 16-bit word before VRAM I/O, not 32 bits) to the VDP to set addresses often. I think Super Skidmarks does DMA across 128K boundaries but I can't recall exactly. Chaos Engine and Herzog Zwei do some strange things with the window layer and Undead Line is picky about Z80 communication.

Sorry the documentation is so out of date (16 years, yikes), but there's tons of goodies in the forum posts here. SpritesMind ended up being the best collection of Genesis information, thanks to KanedaFr and our forum members. :D
Last edited by Charles MacDonald on Thu Aug 18, 2016 8:28 pm, edited 1 time in total.

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Re: Questions on developing a Mega Drive emulator

Post by Mask of Destiny » Thu Aug 18, 2016 5:13 pm

Charles MacDonald wrote:TAS not working on the Genesis 3 (Gargoyles uses it) because its bus controller expects /AS to change on each new bus cycle, but TAS holds /AS asserted after the read extending into the write which is then ignored. So it reads from memory, but the write is ignored and work RAM doesn't get modified.
I think you've got this slightly reversed. TAS doesn't work on the Model 1/Model 2 and Gargoyles depends on the broken behavior. The Model 3 properly handles the special read-modify-write cycle used by TAS, fixing that instruction and breaking Gargoyles.

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 » Thu Aug 18, 2016 5:59 pm

Charles MacDonald wrote:unlicensed EA games (Budokan, etc.) use H40 mode with the wrong combination of RS1,RS0 set,
How does that even work, that should result in an invalid TV signal.
Charles MacDonald wrote:Chaos Engine and Herzog Zwei do some strange things with the window layer
The vertical split screen thing I was mentioning about, the Dragon Ball Z game does it too.

It's actually pretty trivial: set window so it covers the right half of the screen and leave it completely blank, then use plane A for the left portion and plane B for the right portion. Plane A will cover plane B in the left region, while window will hide plane A in the right region, effectively ensuring only one of them is displayed on each half.
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 » Thu Aug 18, 2016 6:29 pm

I remember Chaos Engine relies on emulating VRAM access time during active display otherwise the scrolling get updated too soon (mid frame) resulting in "tearing" appearing on screen... I do have an old "rom to solve" folder sitting somewhere that i used to debug Gens.

Charles MacDonald
Very interested
Posts: 292
Joined: Sat Apr 21, 2007 1:14 am

Re: Questions on developing a Mega Drive emulator

Post by Charles MacDonald » Thu Aug 18, 2016 8:27 pm

Mask of Destiny, good catch! I've edited my post for clarity.
Sik wrote:
Charles MacDonald wrote:unlicensed EA games (Budokan, etc.) use H40 mode with the wrong combination of RS1,RS0 set,
How does that even work, that should result in an invalid TV signal.
For one of the combinations of bits yep, it's a scrambled mess, for the other one the screen is shifted a bit to the right and the colors are more saturated than normal through composite video but is otherwise stable.

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 » Thu Aug 18, 2016 8:42 pm

Hmmmm, but that wouldn't fit the description I heard that one bit controls the resolution and the other controls the timing. So what does each bit actually do then?
Sik is pronounced as "seek", not as "sick".

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Re: Questions on developing a Mega Drive emulator

Post by Mask of Destiny » Thu Aug 18, 2016 9:32 pm

What I've been told is that one bit (I believe bit 0 based on Eke's post) controls both the logical resolution (how many columns the VDP thinks it should produce) and the clock speed of the internal clock divider. The other bit (bit 7) controls whether the internal or external clock source is used.

If you just set bit 0 you'll get an H40 mode with a fixed MCLK/4 divider rather than the mix of MCLK/4 and MCLK/5 provided by EDCLK. So in H32 and the proper H40 mode, you get a horizontal scan rate of ~15.7kHz for an NTSC model and a refresh rate of 59.92Hz. In the improper H40 mode you get a 15.98KHz horizontal scan rate and a refresh rate of 60.99Hz. Now neither of these are an exact match for the proper NTSC values (15.734 kHz horizontal scan), but the proper one is much closer. Given the funny little extra clock circuit on VA0 models, I believe what happened was they originally intended there to just be one bit for selecting between the modes, with H40 using the fixed MCLK/4 divider, but late in the process decided it was far enough out of spec to cause compatibility problems with some TVs. So they made a minor revision of the VDP (or perhaps the external clock bit already existed for testing purposes) and added an extra little board so they didn't need to completely redesign the PCB.

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

Re: Questions on developing a Mega Drive emulator

Post by Near » Sat Aug 20, 2016 12:12 pm

Mike, what's up with this from BlastEm?

Code: Select all

		int16_t y = ((context->sat_cache[cache_address] & 0x3) << 8 | context->sat_cache[cache_address+1]) & 0x1FF;
		int16_t x = ((context->vdpmem[address+ 6] & 0x3) << 8 | context->vdpmem[address + 7]) & 0x1FF;
You're building sprite coordinates from ((hi&3)<<8|lo), which makes a value from 0x000-0x3ff. Then you mask by 0x1ff, discarding the d9 from the address.

http://md.squee.co/VDP#Sprites says that the Y coordinate is 10-bits, and X coordinate is 9-bits. http://jiggawatt.org/genvdp.txt says both coordinates are 10-bits. Your code effectively makes them both 9-bits. Which is it? @_@

..........

Also, a question: when scrolling horizontally and vertically: do you scroll horizontally first, or vertically first?

For instance, let's say my horizontal scroll for a scanline is 32, and I'm rendering pixel# 16. So that's an effective nametable X lookup of 48, right? So when it's time to look into VSRAM for a column, do I look in word 1 (16>>4) of VSRAM, or word 3 (48>>3) of VSRAM? I presume the former.

... oh, and it looks like you're supposed to subtract the value you read for the horizontal scroll from the current pixel X location? I figured it would be addition.

This is what I have now (my VRAM, VSRAM, CRAM are all 16-bits wide):

Code: Select all

auto VDP::Background::scanline(uint y) -> void {
  uint15 address = io.horizontalScrollAddress;

  static const uint mask[] = {0u, 7u, ~7u, ~0u};
  address += (y & mask[io.horizontalScrollMode]) << 1;
  address += (this == &vdp.planeB);

  state.horizontalScroll = vdp.vram[address].bits(0,9);
}

auto VDP::Background::run(uint x, uint y) -> void {
  output.priority = 0;
  output.color = 0;

  static const uint tiles[] = {32, 64, 0, 128};
  y -= vdp.vsram[(x >> 4) & (io.verticalScrollMode ? ~0u : 0u)];
  y &= (tiles[io.nametableHeight] << 3) - 1;
  x -= state.horizontalScroll;
  x &= (tiles[io.nametableWidth] << 3) - 1;

  uint tileX = x >> 3;
  uint tileY = y >> 3;
  uint15 nametableAddress = io.nametableAddress;
  nametableAddress += tileY * tiles[io.nametableWidth] + tileX;

  ...
}
It looks "sort of" correct on Sonic, but not really >_>

Image

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

Re: Questions on developing a Mega Drive emulator

Post by Near » Sat Aug 20, 2016 4:23 pm

More fun here. The SEGA splash screen for Sonic is supposed to have a white background, yet I get black:

Image

Comparing to Mednafen trace logs to confirm I am writing the correct values at the correct locations.

What I see for pixel 0,0 on the screen is that there's no scrolling, and our nametable points to $6000 (or $c000 in bytes.)

Code: Select all

00142a  3c99  move.w  (a1)+,(a6)                             40000003 00000027 0000001b 00000027 00800000 00000000 00002715 0000ffff tS7cvznx 0001ec6c 00ff0180 fffff700 00000000 00000000 00c00004 00c00000 00fffdf8 00000000
* VRAM write 6000=0013
We write a tiledata attribute word of $0013. So that's palette #0, tile #$13. Let's make sure it's supposed to be writing that value there:

Code: Select all

001760  32ca  move.w  a2,(a1)+                               00000006 00000000 ffff0000 00006000 0000ff78 000003ef 0000000b 00000002 tS7cvZnx 0001ebb4 00ff0180 00000013 00000000 00000013 00000007 00c00004 00fffdc4 00000000
001762  524a  addq.w  #1,a2                                  00000006 00000000 ffff0000 00006000 0000ff78 000003ef 0000000b 00000002 tS7cvznx 0001ebb4 00ff0182 00000013 00000000 00000013 00000007 00c00004 00fffdc4 00000000
Yep. Confirmed with Mednafen too.

So that means we fetch tiledata from $130 for the first tile.

Code: Select all

001506  2882  move.l  d2,(a4)                                00000000 0000000e 11111111 00000000 ffffeeee 0000f800 0000000a 00000007 tS7cvznx 0001e797 ffffaa00 fffff700 00001504 00c00000 00000350 00c00004 00fffdc0 00000000
* VRAM write 0130=1111
The tile fetch returns $1111. Which means the first pixel has a color value of 1, palette #0.

And what's the color of CRAM entry 1? #$0000. So where is that getting set?

Code: Select all

001090  2abc  move.l  #$94009340,(a5)                        000000ff 0000ff00 0000001a 0000ffff 00800000 00000000 00002715 0000ffff tS6cvZnx fffff608 00a10005 00002280 0000fb80 00000000 00c00004 00c00000 00fffdae 00000000
001096  2abc  move.l  #$96fd9580,(a5)                        000000ff 0000ff00 0000001a 0000ffff 00800000 00000000 00002715 0000ffff tS6cvzNx fffff608 00a10005 00002280 0000fb80 00000000 00c00004 00c00000 00fffdae 00000000
00109c  3abc  move.w  #$977f,(a5)                            000000ff 0000ff00 0000001a 0000ffff 00800000 00000000 00002715 0000ffff tS6cvzNx fffff608 00a10005 00002280 0000fb80 00000000 00c00004 00c00000 00fffdae 00000000
0010a0  3abc  move.w  #$c000,(a5)                            000000ff 0000ff00 0000001a 0000ffff 00800000 00000000 00002715 0000ffff tS6cvzNx fffff608 00a10005 00002280 0000fb80 00000000 00c00004 00c00000 00fffdae 00000000
0010a4  31fc  move.w  #$0080,($fff640)                       000000ff 0000ff00 0000001a 0000ffff 00800000 00000000 00002715 0000ffff tS6cvzNx fffff608 00a10005 00002280 0000fb80 00000000 00c00004 00c00000 00fffdae 00000000
0010aa  3ab8  move.w  ($fff640),(a5)                         000000ff 0000ff00 0000001a 0000ffff 00800000 00000000 00002715 0000ffff tS6cvznx fffff608 00a10005 00002280 0000fb80 00000000 00c00004 00c00000 00fffdae 00000000
0010ae  6024  bra     $0010d4                                000000ff 0000ff00 0000001a 0000ffff 00800000 00000000 00002715 0000ffff tS6cvznx fffff608 00a10005 00002280 0000fb80 00000000 00c00004 00c00000 00fffdae 00000000
* CRAM write 0000 = 0000
* CRAM write 0001 = 0000
68K->VDP DMA from 7ffd80*2=fffb00 of length 0040
DMA from $fffb02. Okay then ... where's that set?

Code: Select all

000370  2cc7  move.l  d7,(a6)+                               0007ff00 0000afc7 00000000 00000000 00000000 00000000 000000bf 00000000 tS7cvZnx 00080000 0000018e 00000000 00000000 00000000 00000000 00fffb00 00fffe00 00000000
* RAM write fffb02=0000
So ... that's it. I don't see any possible way we can render white for pixel 0,0 on the SEGA splash screen for Sonic the Hedgehog.

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Re: Questions on developing a Mega Drive emulator

Post by Mask of Destiny » Sat Aug 20, 2016 6:52 pm

byuu wrote:http://md.squee.co/VDP#Sprites says that the Y coordinate is 10-bits, and X coordinate is 9-bits. http://jiggawatt.org/genvdp.txt says both coordinates are 10-bits. Your code effectively makes them both 9-bits. Which is it? @_@
I haven't explicitly tested myself that the upper bits go unused, but I believe X is always 9-bits and Y is 9-bits in normal mode and 10-bits in double-resolution interlace mode. The extra bit is needed in double-res mode because interlacing gives you double the vertical resolution. The horizontal resolution remains unchanged though so the extra bit is not needed for X.
byuu wrote:Also, a question: when scrolling horizontally and vertically: do you scroll horizontally first, or vertically first?
Does it matter? The combination of the vertical scroll value and the current line number pick the line within the plane and the horizontal scroll and horizontal position choose the horizontal offset into the line. These seem independent of each other to me.
byuu wrote:For instance, let's say my horizontal scroll for a scanline is 32, and I'm rendering pixel# 16. So that's an effective nametable X lookup of 48, right? So when it's time to look into VSRAM for a column, do I look in word 1 (16>>4) of VSRAM, or word 3 (48>>3) of VSRAM? I presume the former.
Oh, now I understand the confusion. VSRAM and the horizontal scroll table are purely screen space. This is what makes them independent
byuu wrote:... oh, and it looks like you're supposed to subtract the value you read for the horizontal scroll from the current pixel X location? I figured it would be addition.
I can't say why they went with subtraction, but things would definitely be wrong in an obvious way if I had it backwards in Blastem.
byuu wrote:This is what I have now (my VRAM, VSRAM, CRAM are all 16-bits wide):

Code: Select all

auto VDP::Background::scanline(uint y) -> void {
  uint15 address = io.horizontalScrollAddress;

  static const uint mask[] = {0u, 7u, ~7u, ~0u};
  address += (y & mask[io.horizontalScrollMode]) << 1;
  address += (this == &vdp.planeB);

  state.horizontalScroll = vdp.vram[address].bits(0,9);
}
[/quote]
This part seems reasonable depending on what you're passing to the scanline method.

[quote="byuu"]
auto VDP::Background::run(uint x, uint y) -> void {
  output.priority = 0;
  output.color = 0;

  static const uint tiles[] = {32, 64, 0, 128};
  y -= vdp.vsram[(x >> 4) & (io.verticalScrollMode ? ~0u : 0u)];
  y &= (tiles[io.nametableHeight] << 3) - 1;
  x -= state.horizontalScroll;
  x &= (tiles[io.nametableWidth] << 3) - 1;

  uint tileX = x >> 3;
  uint tileY = y >> 3;
  uint15 nametableAddress = io.nametableAddress;
  nametableAddress += tileY * tiles[io.nametableWidth] + tileX;

  ...
}
So for whatever reason, while horizontal scroll is subtracted vertical scroll is added. Other than that, I don't see anything obviously wrong here.
byuu wrote:And what's the color of CRAM entry 1? #$0000. So where is that getting set?
It shouldn't be. Both entry 0 and 1 are white during the splash screen in BlastEm. I'd have to dig in a bit more to see where that value comes from though.

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 » Sat Aug 20, 2016 7:06 pm

Mask of Destiny wrote:I haven't explicitly tested myself that the upper bits go unused, but I believe X is always 9-bits and Y is 9-bits in normal mode and 10-bits in double-resolution interlace mode. The extra bit is needed in double-res mode because interlacing gives you double the vertical resolution. The horizontal resolution remains unchanged though so the extra bit is not needed for X.
Yep, X is always 9-bit, Y is either 9-bit or 10-bit depending on whether interlacing is on or off.
Mask of Destiny wrote:Does it matter? The combination of the vertical scroll value and the current line number pick the line within the plane and the horizontal scroll and horizontal position choose the horizontal offset into the line. These seem independent of each other to me.
i.e. first vertical then horizontal =P

Yes, in the hardware they look independent, this is more about the outcome on screen. Especially when not using the full scroll modes (i.e. per-tile or per-line hscroll, and per-2-tile vscroll). And yeah the hscroll table is relative to screen, it always starts with the first entry regardless of the vscroll value.
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 » Sat Aug 20, 2016 7:33 pm

> X is always 9-bits and Y is 9-bits in normal mode and 10-bits in double-resolution interlace mode.
> Yep, X is always 9-bit, Y is either 9-bit or 10-bit depending on whether interlacing is on or off.

I see, thank you! The SNES just doubles Y, so you can only move two pixels at a time in interlace mode there.

> So for whatever reason, while horizontal scroll is subtracted vertical scroll is added.

>___>

Man, and I thought tile lookup for BGs using Y*width+X and sprites using X*width+Y was dumb ...

> It shouldn't be. Both entry 0 and 1 are white during the splash screen in BlastEm. I'd have to dig in a bit more to see where that value comes from though.

EDIT: found it, finally. MOVEA wasn't sign-extending word reads.

Of course like every bug fix, it doesn't fix anything else on my bug list =(

Code: Select all

002e80  7000  moveq   #$00,d0                                463a0003 00000002 0000ffff 0000ffff 00800000 00000000 00002715 0000ffff tS7cvznx 0001ec6c 00ff0a4c fffff700 00000000 00000000 00c00004 00c00000 00fffdfc 00000000
002e82  6100  bsr     $002110                                00000000 00000002 0000ffff 0000ffff 00800000 00000000 00002715 0000ffff tS7cvZnx 0001ec6c 00ff0a4c fffff700 00000000 00000000 00c00004 00c00000 00fffdfc 00000000
002110  43f9  lea     ???,a1                                 00000000 00000002 0000ffff 0000ffff 00800000 00000000 00002715 0000ffff tS7cvZnx 0001ec6c 00ff0a4c fffff700 00000000 00000000 00c00004 00c00000 00fffdf8 00000000
002116  e748  lsl.w   #3,d0                                  00000000 00000002 0000ffff 0000ffff 00800000 00000000 00002715 0000ffff tS7cvZnx 0001ec6c 00002160 fffff700 00000000 00000000 00c00004 00c00000 00fffdf8 00000000
002118  d2c0  adda.w  d0,a1                                  00000000 00000002 0000ffff 0000ffff 00800000 00000000 00002715 0000ffff tS7cvZnx 0001ec6c 00002160 fffff700 00000000 00000000 00c00004 00c00000 00fffdf8 00000000
00211a  2459  movea   (a1)+,a2                               00000000 00000002 0000ffff 0000ffff 00800000 00000000 00002715 0000ffff tS7cvZnx 0001ec6c 00002160 fffff700 00000000 00000000 00c00004 00c00000 00fffdf8 00000000
00211c  3659  movea   (a1)+,a3                               00000000 00000002 0000ffff 0000ffff 00800000 00000000 00002715 0000ffff tS7cvZnx 0001ec6c 00002164 00002200 00000000 00000000 00c00004 00c00000 00fffdf8 00000000
00211e  3e19  move.w  (a1)+,d7                               00000000 00000002 0000ffff 0000ffff 00800000 00000000 00002715 0000ffff tS7cvZnx 0001ec6c 00002166 00002200 0000fb00 00000000 00c00004 00c00000 00fffdf8 00000000
002120  26da  move.l  (a2)+,(a3)+                            00000000 00000002 0000ffff 0000ffff 00800000 00000000 00002715 0000001f tS7cvznx 0001ec6c 00002168 00002200 0000fb00 00000000 00c00004 00c00000 00fffdf8 00000000
002122  51cf  dbf     d7,$002120                             00000000 00000002 0000ffff 0000ffff 00800000 00000000 00002715 0000001f tS7cvznx 0001ec6c 00002168 00002204 0000fb04 00000000 00c00004 00c00000 00fffdf8 00000000

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Re: Questions on developing a Mega Drive emulator

Post by Mask of Destiny » Tue Aug 23, 2016 7:10 am

byuu wrote: > So for whatever reason, while horizontal scroll is subtracted vertical scroll is added.

>___>
I thought about it a bit more and actually this makes a lot of sense. If you think of the scroll value as the position of the plane in the viewport, the setup they chose has positive horizontal scroll values moving the plane to the right and positive vertical scroll values moving the plane up. It's a it annoying if you're implementing the VDP, but it makes sense from the point of a user.
byuu wrote:Man, and I thought tile lookup for BGs using Y*width+X and sprites using X*width+Y was dumb ...
I can sort of see why they did that. In the context of sprite drawing, viewing it as a series of column strips rather than a collection of tiles makes a certain amount of sense. Horizontally, the tile aspect is sort of baked in to the way VRAM is managed, but vertically the fact that tiles are 8 pixels tall is sort of arbitrary. Making it vertically oriented probably saved them a few gates.

For tile maps, things have to be arranged horizontally in memory to get along with the 4-byte at a time read.

For the most part, I feel the decisions they made make sense. The DMA engine is kind of a mess though. DMA Fill and Copy seem like they were tacked on at the last minute. 68K -> VRAM copies could run twice as fast if they used a less general design that took advantage of the serial write mode of the VRAM. You would definitely lose some flexibility, but the extra performance would be more than worth it. Similarly it's really lame that CRAM updates are limited based on VRAM access slots since most of those are at points in the display in which CRAM access is contended.

The color limitations are also really unfortunate. 12-bit palette entries + separate palettes for backgrounds and sprites would have gone a long way. I wonder what they could have done if they hadn't spent some of their transistor budget on SMS compatibility.
byuu wrote:EDIT: found it, finally. MOVEA wasn't sign-extending word reads.
Glad you figured it out.

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 3:00 pm

Mask of Destiny wrote:The color limitations are also really unfortunate. 12-bit palette entries + separate palettes for backgrounds and sprites would have gone a long way. I wonder what they could have done if they hadn't spent some of their transistor budget on SMS compatibility.
Or if they got rid of the linked list in sprites and just went through them linearly like everything else did (even the SMS). I mean, nearly every game just puts sprites in order anyway, making the list useless.

Consider this: storing the linked list in the cache requires 7 × 80 = 560 bits. The size of CRAM is 64 × 9 = 576 bits. What are the chances that getting rid of the list would have made it possible to double the CRAM amount and allow their original idea of 4 palettes for backgrounds and 4 for sprites? I mean, trying to squeeze in 16 bits more certainly looks more feasible than squeezing in 576.
Sik is pronounced as "seek", not as "sick".

Post Reply