Make a wish / What if : Genesis

[ob1]

Reading the TF530 topic (viewtopic.php?f=13&t=2721), and just for fun, I thought about a make-a-wish / what if for the Genny. If you could have added one feature, just one, single, feature, what would have it been ?
A more-evolved CPU (think about 68010 cache mode) ?
Wider data bus ?
Some cache ?
A FPU ?
A faster CPU (think 16 MHz Freescale DragonBall) ?
More RAM ?
More VRAM ?
A rotatable/scalable layer (Mode 7 anyone) ?
A Frame Buffer (a la 32x) ?

I'll go first.
If I could have blessed the Megadrive/Genesis with one single more feature, it would have been ... 12-bits palette entries (RGB444).

Edit: come to that, 15-bits (RGB555) would have been fine too

[cero]

More palettes.

[Stef]

In priority order :
- 4 palettes for sprite + 4 palettes for BG.
- RGB444 colors would have be neat too.
- Z80 having priority on BUS.
- 128 KB of VRAM just to make the VDP design more elegant (no weird hacked 8 bits VRAM access).
- very simple logic to transform TILE <--> BITMAP (a la SegaCD)

I think the rest of the hardware is already perfect :p

[Flygon]

Pretty much what Stef said, and some kind of audio buffer to put PCM audio into, rather than the existing method of essentially banging the DAC.

It's a bit of a shame - I'm pretty sure a bit over half of what Stef described is what the hardware originally had!

EDIT: To clarify - I meant before the cost cutting during the hardware's design stage.

[ob1]

• 4 palettes for sprite + 4 palettes for BG.

Neat. 8 palettes, and no need to modify background tile or sprite entries (still 2 bits for the palette number).

I think the rest of the hardware is already perfect :p

[TmEE co.(TM)]

* YM IRQ connected to Z80
* Bus management allowing to Z80 to make proper accesses to 68K side (so you can read and write RAM and VDP properly).
* VDP turning unused sprite GFX fetches into CPU access slots
* Line interrupts should start much earlier so that 68K hits the end of line rather than misses half the HBL area. If sprite slots turned access slots you'd get a whole lot of extra access slots.

[KanedaFr]

* more pal (à la PCEngine/TG16)
* a way to know when your V/Hhandler used too much cycles !

[Stef]

@TmEE> In fact from my tests the Z80 *can* write 68k RAM, it just can't read it
"YM IRQ connected to Z80" is a good one too but probably an issue for SMS backward compatibility

[TmEE co.(TM)]

Writing is the part that isn't useful though, I got to pass stuff to Z80 side and almost never read back any responses. Workaround is using cart RAM, that's not subject to access issues from Z80.
SMS compatibility is not a problem, NMI never happens in MD mode and YM IRQ never happens in SMS mode. You can pretty much just connect the signals together. Big missed opportunity...

And one more thing, get rid of the serial banker and go SMS style parallel writes. Much less wasted cycles...

[Matej]

Mini Itx board, midi ports, 68010, on board everdrive sd, more ram (for homebrew), more videoram or new vdp 9990, 16bit stereo dac as covox for more sample channels (amiga mod, pc xm), ps/2 keyboard port, ps/2 mouse as sega mouse, 250mhz eZ80 (playing samples DAC), ethernet (mmorpg,multiplayer games), sockets for easy original ic installation.

[Sik]

Guys, the idea is to ask for a single thing, not a whole list (・＿・)

- very simple logic to transform TILE <--> BITMAP (a la SegaCD)

To be fair, if you're doing a custom cartridge with RAM on it you can do that by just mirroring it and arranging the address lines differently in the mirror (note that the bitmap width needs to be a power of two for this to work), then whether it's tiles or bitmap depends entirely on which address range you access (and conversion is literally instantaneous). Doesn't Virtua Racing actually do something like this?

@TmEE> In fact from my tests the Z80 *can* write 68k RAM, it just can't read it

In some late revisions it can't write either (this breaks a couple of games if I recall correctly).

[themrcul]

I wish wish wish wish the Mega Drive had the things on Stef's list.
My order would be:
1) 4 palettes for BG, 4 palettes for Sprites.
2) RGB444
3) 128KB VRAM

1 Is the most tragic, as it could theoretically be achieved for free, as ob1 mentioned.
From what I understand, 2 could have been achieved by sacrificing Master System compatibility.

I don't know about the rest of you, but Master System compatibility was the biggest mistake in creating the Mega Drive. Having those extra palettes or palette depth would have helped the Mega Drive immensely in all of the MD vs SNES comparisons back in the day, and helped make the games look nicer for longer.
The sad part about it is there isn't a Master System game I can point to and say "having that game on the MD work was worth the sacrifice"...

Extra VRAM would be so nice as that would help in giving backgrounds more fidelity, or having larger sprites on screen. Both would be awesome.

But choosing between 1 and 2 is really hard.

[Flygon]

Wasn't the choice of going with 9-bit RGB instead of the full 12-bit mostly to do with the cost of the RGB DACs involved?

I'm not a particularly savvy man, but I understand that the cost difference was pretty strong.

Cheapness has to be the explanation as to why the Atari ST also initially had such a low colour RGB DAC!

[Sik]

1) 4 palettes for BG, 4 palettes for Sprites.
[...]
1 Is the most tragic, as it could theoretically be achieved for free, as ob1 mentioned.

No. It was part of the original plan but they had to cut it because they ran out of die space (a bunch of other features got cut out for the same reason).

From what I understand, 2 could have been achieved by sacrificing Master System compatibility.

I don't know about the rest of you, but Master System compatibility was the biggest mistake in creating the Mega Drive. Having those extra palettes or palette depth would have helped the Mega Drive immensely in all of the MD vs SNES comparisons back in the day, and helped make the games look nicer for longer.
The sad part about it is there isn't a Master System game I can point to and say "having that game on the MD work was worth the sacrifice"...

Everybody keeps saying this but we don't have any proof that it's the biggest die eater.

I really wish we would just decap a VDP to put a rest to this (・＿・) Pretty sure that the sprite linebuffer is eating up a lot of die space. If you want to double the amount of palettes, you'd probably have to get rid of 320px wide modes (this should free up enough die space that it'd become way more feasible). Nobody likes to hear that though.

Extra VRAM would be so nice as that would help in giving backgrounds more fidelity, or having larger sprites on screen. Both would be awesome.

It also doubles the transfer speed as a side effect.

[Stef]

- very simple logic to transform TILE <--> BITMAP (a la SegaCD)

To be fair, if you're doing a custom cartridge with RAM on it you can do that by just mirroring it and arranging the address lines differently in the mirror (note that the bitmap width needs to be a power of two for this to work), then whether it's tiles or bitmap depends entirely on which address range you access (and conversion is literally instantaneous). Doesn't Virtua Racing actually do something like this?

It was what i meant when i said "simple logic", just a different memory address range to address the WRAM in a different way so linear addressing is directly arranged in tile