nesdev.org

Regarding Project SNES and Project MD:

Isn't the Megadrive much easier to develop for than the SNES? You can even use GCC as your compiler.

You can program the SNES in C as well. There's a compiler and some libraries available. Just don't write anything speed- or size-critical in C.

I think Dwedit's point is that far more effort has been expended getting C compilers to generate halfway efficient code on 68000 family CPUs than on 6502 family CPUs.

psycopathicteen wrote:Screw metatiles. I'll just use the Snes's 16x16 tile mode and nobody would even know the difference.

That's what it's there for you know.

Dwedit wrote:Isn't the Megadrive much easier to develop for than the SNES? You can even use GCC as your compiler.

Having both the MD and SNES docs, yes, I can say the MD is much easier to program, and here I'm assuming that both would be programmed using assembly.

For starters, the 68000 has 15 general use 32-bit registers, and almost all operations can be performed with 32-bit values. As far as I know, the 65816 doesn't do very well on that area, which means that the 68000 has a huge advantage when it comes to processing large values (although I believe the 65816 still may beat it at 8-bit data, but I'm unsure how many cycles does it eat up for each instruction so I can't comment). The few operations that can't be done as 32-bit on the 68000 are those that you'd want to avoid anyways since they're slow (e.g. multiplication and division, and even then, those deal with larger values than what the SNES was provided).

Then there's the VDP. Yes, it may not have four tilemap layers or scan-line deformation (mode 7 on the SNES), but all the features it has can be turned on simultaneously. If you want, you can have it to use 320×224*, horizontal scroll per line, vertical scroll per 2 tiles, 8KB tilemaps, window plane, shadow/highlight and interlaced mode all together (on the SNES, what features are availble depend on which mode you're using). Also, if you try to write outside blank, the write will still make its way into memory (albeit it'll be slower). If you saturate the VDP, it'll stall the 68000 until it's free to accept new commands. All 2048 tiles can be used for anything (no dedicated areas for sprites and such, use them the way you want!). Also, the MSB of the horizontal sprite coordinate isn't given in a separate bit in a separate table =P

The Z80 has only 8KB of RAM, so at first it may seem like in a much worse situation than the SPC700. However, it's also able to read all of the ROM on its own, so those 8KB of RAM generally are left for the program and its variables, and the sound data is read straight off the ROM (where it has much more room to breathe). The SPC700 needs to put in its 64KB the program, its variables, music data, SFX data, and also the samples. And the only way it can communicate to the exterior is through four ports and hope the 65816 is paying attention to them.

And finally, reading joypads isn't tied to VBlank. Like, seriously, WTF? Why does the program have to wait until a bit after VBlank to read the joypads on the SNES? o_O (and before you mention things like lightguns, on the MD the peripherals can generate an interrupt so that isn't an issue)

It feels stupid talking about this on a SNES development board, but the topic arised. I guess somebody here can do the exact opposite and talk about things the SNES does easier than the MD. Let's be fair though, Sega decided to go easy when it comes to programming the hardware. Yes, there are the add-ons which are harder to program, but what did you expect, that's like trying to run a game using hardware from two/three separate consoles at the same time =P

*Technically, with interlaced mode it becomes 320×448, but you get my point.

You forgot to mention sprite sizes:

Genesis:
8x8, 8x16, 8x24, 8x32, 16x8, 16x16, 16x24, 16x32, 24x8, 24x16, 24x24, 24x32, 32x8, 32x16, 32x24, 32x32

Snes:
8x8, 16x16, 32x32, 64x64
PICK TWO

Also the fact that the MD doesn't have a CIC. There is some layer of security, yes, but it's pathetically easy to defeat. Just have "SEGA" at $000100 (where the header starts) and write "SEGA" to $A14000 in your code. There isn't even any need for proper timing, you just have to do it before accessing the VDP. This is probably the main factor here, actually, since it made flashcarts much easier back then.

There are more things (e.g. the 68000 can access the sound hardware directly) but I guess the topic is derailed. I didn't expect this discussion appearing on a board like this o_O

Sik wrote:Then there's the VDP. Yes, it may not have four tilemap layers or scan-line deformation (mode 7 on the SNES)

Which rules out certain kinds of racing games like Mario Kart and On the Ball.

All 2048 tiles can be used for anything (no dedicated areas for sprites and such, use them the way you want!).

This carries a color penalty: a tile or sprite may select from only four, not eight, sets of colors.

And finally, reading joypads isn't tied to VBlank. Like, seriously, WTF? Why does the program have to wait until a bit after VBlank to read the joypads on the SNES?

I thought this was true only for automatic controller reading (bit 0 of $004200), not NES-style manual clocking at $004016 and $004017. But then this takes place during the first three lines of vblank, during which time the program is likely still copying data into VRAM.

Yes, there are the add-ons which are harder to program, but what did you expect, that's like trying to run a game using hardware from two/three separate consoles at the same time =P

At least the SNES add-ons were cheap enough to include in a cartridge, unlike 32X which bombed in part because it was sold separately.

But you've pointed out some of the reasons that I'll probably progress from NES to geNESis.

tepples wrote:

All 2048 tiles can be used for anything (no dedicated areas for sprites and such, use them the way you want!).

This carries a color penalty: a tile or sprite may select from only four, not eight, sets of colors.

To be fair this is probably unrelated. I guess Sega was just trying to save money on memory (they also screwed up the vertical scroll RAM by making it 20 columns long instead of 32). The MD is inferior in terms of color no matter from where you look at it, anyways. Less palettes, less colors to choose from. Project MD masks this by using a flickering checkerboard pattern (probably the only FX worthy from that game).

tepples wrote:

And finally, reading joypads isn't tied to VBlank. Like, seriously, WTF? Why does the program have to wait until a bit after VBlank to read the joypads on the SNES?

I thought this was true only for automatic controller reading (bit 0 of $004200), not NES-style manual clocking at $004016 and $004017. But then this takes place during the first three lines of vblank, during which time the program is likely still copying data into VRAM.

Touché.

tepples wrote:

Yes, there are the add-ons which are harder to program, but what did you expect, that's like trying to run a game using hardware from two/three separate consoles at the same time =P

At least the SNES add-ons were cheap enough to include in a cartridge, unlike 32X which was sold separately.

The only MD game really meant to be like that was Virtua Racing (it uses the SVP). The 32x was Sega's stupid attempt at tackling into the 32-bit generation (when they already had the Saturn for that!), and the Sega CD was made to compete against the PC Engine's CD add-on.

Also, Nintendo almost makes the same mistake (remember, the SNES CD add-on), and for the record, that ended up in a worse mistake (Sony decided to keep going on its own and then they released the PlayStation and took both Sega and Nintendo by surprise).

EDIT: how the checkerboard pattern in Project MD works:
Normal speed
Slow motion

Granted, it looks much better when used for gradients (like it would be here), but that level was a palette whore because the mirroring ate up 50% of the color...

Sik wrote:

tepples wrote:

All 2048 tiles can be used for anything (no dedicated areas for sprites and such, use them the way you want!).

This carries a color penalty: a tile or sprite may select from only four, not eight, sets of colors.

To be fair this is probably unrelated. I guess Sega was just trying to save money on memory

Can't say that I blame Sega. In order to provide more bits for color base, nametable entries would have had to either double in width, lose flipping, lose a tile number bit, lose priority per tile, or use a second packed table (like the NES does).

NES nametable format: tttttttt / cc (for group of 4 tiles)
MD nametable format: pccvhttt tttttttt (sprites use same format)
SNES nametable format: vhpccctt tttttttt (sprites use one more p and one fewer t)

EDIT: how the checkerboard pattern in Project MD works:
Normal speed
Slow motion

A bunch of 6-bit LCDs use the same trick (temporal Bayer dithering) to display 8-bit images.

Oh, and the shadow/highlight function is much more general (i.e. more powerful) on the SNES.

tepples wrote:Can't say that I blame Sega. In order to provide more bits for color base, nametable entries would have had to either double in width, lose flipping, lose a tile number bit, lose priority per tile, or use a second packed table (like the NES does).

That isn't an excuse for sprites, though. The field for the size has four spare bits.

tepples wrote:Oh, and the shadow/highlight function is much more general (i.e. more powerful) on the SNES.

That isn't even shadow/highlight, that's alpha blending directly.

Although if we're going to continue on the topic of features, the VDP's interlaced mode affects everything (tilemaps, sprites, scrolling), while on the SNES it only affects the tilemaps. Interlaced mode is completely useless anyways because the horizontal resolution isn't affected, so you end up with 256/320×448. Only Sonic 2 uses this in a licensed game AFAIK, and that's so it can reuse the 1P graphics in the 2P mode.

Also there's the fact that the MD has a horizontal scroll table, so there isn't any need to change the scrolling values per line during active scan. Then again, the SNES has a HDMA table while the MD only has a HBlank interrupt, but changing the horizontal scrolling values with HDMA eats up time that could be used for loading other data (e.g. colors).

Sik wrote:Interlaced mode is completely useless anyways because the horizontal resolution isn't affected, so you end up with 256/320×448.

It's not completely useless. The fighting game Ehrgeiz for the original PlayStation is one game that uses 320x448 pixels well. But then if you have a 3D game that runs at 60 Hz in 240p, running it in 480i is nearly free anyway. A 2D game, on the other hand, needs more tile graphics, which in turn needs more memory.

Also there's the fact that the MD has a horizontal scroll table, so there isn't any need to change the scrolling values per line during active scan.

You can't change the vertical position with the horizontal scroll table. So you can do Pole Position, Street Fighter, or NBA Jam (flat road), but not Rad Racer (hills) or Yoshi's Island (boss morphmation). These effects need timed code on the NES, the HDMA features of the Super NES or GBA, or an hblank interrupt.

I think pretty much all racing games on the Mega Drive used HBlank interrupts for that very same reason (and of course hills are quite commonplace). Using palette rolling doesn't look smooth so games just change the vertical scroll position every line (and then there's OutRun 2019 abusing both tilemap planes like crazy...).

On MD you have a vertical scroll table aswell, though its not line based but you can modify it midframe, that's how Road Rash games do their hills and numerous other games some vertical scaling effects (Mega Turrican and High Seas Havok coming to mind).

How about the plain and simple fact that 65816 is painful to develop for because you can't properly disassemble code thanks to CPU flag dependent, ambiguous opcodes ...

Wasn't nintendo also looking at a 68K CPU for the SNES at some point ? Or am I confusing things ? What a shame that did not come to be..