nesdev.org

The better you make the Genesis the worst the Snes would look in comparison.

Dwedit wrote: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.

I have been coding for both the Sega Mega Drive and the SNES. From my experience I can tell you that coding on the Mega Drive is much much easier. Finding documentation about programming the hardware is also much easier for the MD than the SNES. The Mega Drive uses the 68000 processor, which is extremely popular and used in many machines, so you can borrow documentation on it from everywhere - Amiga, Atari ST, Sinclair QL, Apple Mac - all they used 68K processors and there is litterally thousand of documentations you can use for reference. On the other hand the 65816 in the SNES is much less popular and only used in the Apple IIGS which was neither popular, nor prettly well documented. Hopefully the 65816 have 6502 mode you can use, but coding in assembler is much harder with all the required switches to 8 and 16 bit. The 68000 does not have problem with 8 and 16 bit modes.

I prefer to code in assembler for the consoles, but C comes very handy. For Sega Mega Drive you can use almost any 68K compiler and tweak it to work for Mega Drive. And there are dozens of 68K C compilers. For the SNES there is the cc65 compiler, but its 65816 support is limited. There are not much compilers that can be used for SNES development.

For the assemblers, I have dozen of very good 68K assebmlers on the Amiga, but WLA-DX is also very good assembler. Thanks to the author, WLA-DX is open sourced, so I have compiled it on my Amiga as well.

With the Mega Drive you mostly need to know 68K and some hardware registers, while on the SNES you need to program the sound separately in another language. This makes SNES development even harder.

The Mega Drive beats the SNES coding in terms of being easier and faster, but I enjoyed more coding for the SNES, because of the bigger challenge and the need for more experiments, than developing for Mega Drive, where is it much less fun.

on the SNES you need to program the sound separately in another language.

To be fair, you pretty much have to do that on the MD as well - at least if you want to use the DAC, since there's no timer interrupt, and letting the the 68k just sit and poll the timer is usually out of the question.
At last the z80 can access ROM directly, but the serial bankswitching mechanism sucks.

@drHirudo

Nowadays the 65816 is very well documented, so you must've programmed the Snes a long time ago.

psycopathicteen wrote:The way 16x16, 32x32 and 64x64 sprites are decoded is annoying. On the Genesis a 16x16 sprite with a tile number of $00 would take up tiles {$00,$01,$02,$03} while on the Snes they take up tiles {$00,$01,$10,$11) requiring 2 dma loads instead of one. This is a shame because 16x16 sprites are more useful in games than 8x8 sprites.

Unless, of course, you load 8 sprite cels as a unit. An MMC3-style mode of operation loads a 2 KiB block containing 64 tiles (16 sprite cels of 16x16 pixels). The Game Boy Advance supports both Genesis-style mapping ("1D mode") and Super NES-style mapping ("2D mode"), and it has Genesis-style size per sprite, although with 64-pixel instead of 24-pixel dimensions.

Then how does the Snes scroll sprites off the side of the screen you ask? After the main part of the oam there is an extra 32 bytes with the 9th x bit and the size bit for every sprite is stored in an interweved pattern.

What the hell were these people thinking?

They were thinking "engineer everything for NES back-compat", but once they realized that was unworkable, they couldn't go back and undo all the dain bramage they had put in to make the SNES PPU act like an NES PPU.

MottZilla wrote: The PC-Engine supports 16 subpalettes for BG, and another 16 for sprites, giving that 512 total.

As does the GBA.

Afterall, if you own SMS games (back when the Genesis launched) then you already own a SMS console.

Unless your SMS broke. The back-compat in PS2, Xbox 360, Wii, and PS3 helped because laser mechanisms wear out.

mic_ wrote:To be fair, you pretty much have to code in assembly for a separate 8-bit microprocessor] on the MD as well - at least if you want to use the DAC, since there's no timer interrupt

Coding a playback engine that just shift samples right and pipes them to the DAC is far less of a chore than coding a whole music player. Different games could have used different music players with the same sample player. Besides, Z80 was already popular in other circles, and Genesis sound programmers may have started out on the ColecoVision, Spectrum, or Master System, unlike SPC700 which was in the Super NES APU and pretty much nothing else.

psycopathicteen wrote:Nowadays the 65816 is very well documented

Even if it is documented, the documentation isn't in a form that compilers' code generators understand. Plenty of compilers for Pascal, C, and other compiled languages popular in the early 1990s generate reasonably efficient code for the 68K family; fewer do for 65816. Show me a 65816 back-end for GCC to match the 68000 one and I'll listen to you.

Doesn't well documented mean you can go to www.google.com type in "65816 instruction set" and find it on the first page? Or is that called something else?

psycopathicteen wrote:Doesn't well documented mean you can go to www.google.com type in "65816 instruction set" and find it on the first page? Or is that called something else?

By well documented I did not meant only the instruction set. Instruction set is easy to find, but what about certain algorhytms, techniques, tricks to save processsor cycles, registers usage and memory?

For the 68K it is much easier to find such documentation and tutorials. For the 65816 I read a Apple II coding newsletter for a while, which also had some 65816 topics covered, but for 68K you will find more information, easily, more techniques and better tricks. Assembler is not only about learning the instruction set. The instruction set can be learned in a day, to master Assembler you need to practice for years.

psycopathicteen wrote:The better you make the Genesis the worst the Snes would look in comparison.

Which is exactly what Sega needed to do. It was foolish wasting resources on the 8bit era in your 16bit era system. Every last resource should have gone into making the best 16bit system they could. We can all agree that more colors available at once would have made it a much better system.

Unless your SMS broke. The back-compat in PS2, Xbox 360, Wii, and PS3 helped because laser mechanisms wear out.

I highly doubt many people had SMS consoles break and need the MD for BC. Plus Nintendo didn't support any BC and I don't recall people throwing a fit over it. It's a nice feature to have I agree. But it was a bad business decision I think. I really doubt the benefit from having it was worth the cost not only in the cost to the existing MD, but the cost it had on the MD not being able to be something better. As I said before, more Colors like 4 * 16 sets for each of Scroll Plane A, B, and Sprites would have been excellent. Pair that with an improvement in the sound department and I really think Sega could have blown Nintendo away in the 16bit era, atleast in the US and Europe though maybe not Japan.

TmEE wrote:I personally think the fixed phase setup that SMS and MD use looks far better than what Nintendo and everyone else used... I absolutely hate the fuzzy edges that NES...

Actually, the NES, etc. have much sharper edges (thanks to the changing phase) in composite.

A slight diversion from this thread, but your comment, TmEE, inspired me to finish up a clearer comparison page between composite & RGB:

http://www.disgruntleddesigner.com/chri ... mpare.html

I cannot really comment on NTSC composite signal, but on PAL things don't look as bad, at least I don't recall so... in PAL the "fuzziness" stays in place aswell on the NES, in 60Hz on one of my famiclones the edges "move" and I find it looking better

What game was used, I could try to take a sample... my capture card sucks though, lots of noise in the image :/
EDIT: nevermind, I got no NeoGeo

...and I have not got such noise form RGB of my GG

As for MD having more colors, they could have had BGs and sprites use different palettes, even on the same VDP chip they used without modifications... some arcade boards use same VDP but external RAMDAC on the digital video out of the VDP...

I do think they should have dropped S/HL and give free use of the LSB of CRAM...

MottZilla wrote:

psycopathicteen wrote:The better you make the Genesis the worst the Snes would look in comparison.

Which is exactly what Sega needed to do. It was foolish wasting resources on the 8bit era in your 16bit era system. Every last resource should have gone into making the best 16bit system they could. We can all agree that more colors available at once would have made it a much better system.

And the PC Engine has more colors but only one tilemap, and 8KB of RAM, and an 8-bit CPU, besides the fact that nothing was known about the SNES (was it even in active development or just research phases?).

Like I said, it's very possible that CRAM memory actually ate up a lot of space on the die. CRAM memory needs to be fast so it's probably SRAM, which is usually implemented using complex gates (e.g. NOR gates), which eat up quite a fair share of transistors and thereby space. VSRAM may be the same too, which may explain why it has its own memory instead of being stored in VRAM (which is a separate chip in the original VDP).

Basically, the built-in memory probably was too expensive in terms of die space, so they'd have needed to go with separate memory for those too if they wanted to expand them, definitely making it much more expensive.

And if we're going to talk about missing features, well, what about their "superscaler" technology? That one would have been cool =/ Or how about having some proper sample hardware? Because the DAC implementation is completely crap, having absolutely no hardware timing at all. I think no arcade systems used the YM2612's (or whatever clone they used) DAC feature, but instead they used separate PCM chips.

MottZilla wrote:

Unless your SMS broke. The back-compat in PS2, Xbox 360, Wii, and PS3 helped because laser mechanisms wear out.

I highly doubt many people had SMS consoles break and need the MD for BC. Plus Nintendo didn't support any BC and I don't recall people throwing a fit over it. It's a nice feature to have I agree. But it was a bad business decision I think. I really doubt the benefit from having it was worth the cost not only in the cost to the existing MD, but the cost it had on the MD not being able to be something better. As I said before, more Colors like 4 * 16 sets for each of Scroll Plane A, B, and Sprites would have been excellent. Pair that with an improvement in the sound department and I really think Sega could have blown Nintendo away in the 16bit era, atleast in the US and Europe though maybe not Japan.

The SG-1000 Mark III (basically the original Japanese Master System) was backwards compatible with the Mark I and Mark II. I actually think Sega was just following the trend they had for that console line.

TmEE wrote:I do think they should have dropped S/HL and give free use of the LSB of CRAM...

That theory I had made before is crap because it turns out S/H gives a color range that's definitely not 16 shades, besides they could have always made it an internal bit not used in CRAM =/ To be fair I think that the main reason that the LSB is unused is so each component belongs to a separate digit in hexadecimal (e.g. orange is $08E, with 0 = blue, 8 = green, E = red).

Sik wrote:...besides the fact that nothing was known about the SNES (was it even in active development or just research phases?)..

In 1987 the SFC was already in development, but the outside world certainly didn't have any solid technical details about it.

MottZilla wrote:

psycopathicteen wrote:The better you make the Genesis the worst the Snes would look in comparison.

Which is exactly what Sega needed to do. It was foolish wasting resources on the 8bit era in your 16bit era system. Every last resource should have gone into making the best 16bit system they could. We can all agree that more colors available at once would have made it a much better system.

Unless your SMS broke. The back-compat in PS2, Xbox 360, Wii, and PS3 helped because laser mechanisms wear out.

I highly doubt many people had SMS consoles break and need the MD for BC. Plus Nintendo didn't support any BC and I don't recall people throwing a fit over it. It's a nice feature to have I agree. But it was a bad business decision I think. I really doubt the benefit from having it was worth the cost not only in the cost to the existing MD, but the cost it had on the MD not being able to be something better. As I said before, more Colors like 4 * 16 sets for each of Scroll Plane A, B, and Sprites would have been excellent. Pair that with an improvement in the sound department and I really think Sega could have blown Nintendo away in the 16bit era, atleast in the US and Europe though maybe not Japan.

I think that applies to Nintendo too, because of the Snes's near backwards compatable design.

If Nintendo really wanted it to be backwards compatable that much, I think they should've used a slighty upgraded NES PPU, and have a second full fledged 16-bit PPU sitting next to it. The full fledged 16-bit PPU doesn't have to be as powerful as the Genesis's VDP, as long as the sum of both PPUs are more powerful than the VDP.

Nintendo would have been foolish to waste resources too on NES compatibility in the SNES. But the wised up at some point atleast. The only system I really thought that backwards compatibility made sense was the Gameboy line. Other than that I don't think backwards compatibility really is worth the cost and thus the features it takes away from the current generation's games. Who knows, maybe Nintendo went with the 65816 rather than the 68000 because they had envisioned NES compatibility.

Who knows, maybe Nintendo went with the 65816 rather than the 68000 because they had envisioned NES compatibility.

Or developer compatibility. By using a similar scheme as the NES, all the NES developers would be able to pick up the SNES more quickly. Same for the graphical scheme, which is quite similar.