Advantages of SNES hardware vs. Genesis hardware

I've been studying 68K assembly to experiment with Genesis homebrew and hacking, among other things.

I however would like to know the pros and cons of SNES and Genesis hardware, besides graphics and sound, as I may also be interested in SNES homebrew. Supposedly Genesis is the fastest since it has 7mhz CPU, however I don't know how it performs when everything is put together.

I know SNES has mode7 but that's simply off the bat. I mean, can't you create a similar engine for a Genesis game? And what about the space limitations? Answers to these and other questions appreciated, thanks.

Mode 7 is a hardware feature of the SNES. In fact, it gets its name from being the 7th video mode of the SNES. On the Genesis, you could really simplify the SMS video setting by calling it Mode 4. I wish the "Mode 7" effect had a better name, so people would stop labeling every pseudo-3D effect as Mode 7. The Lynx can do it too, but it isn't called Mode 7...

You can do lots of things in software on the Genesis. Hard/Race Drivin and the unreleased game ResQ had software rendered polygons, Pier Solar did a Mode 7-like effect and I bet some games have done sprite scaling and rotation.

Perhaps the only thing the Genesis really suffers from, is a lack of colors. Not much can fix that, not even software tricks can get you very far. In fact, I'd go so far as to say, the colors ended up killing the Genesis. The 32X was partly designed to address the paltry colors, Donkey Kong Country looked better than any pre-rendered Genesis game because it used more colors, and most magazines complained about the colors a lot too.

What Guntz said, it's kinda silly that people call the "landscape" effect "mode-7", since the actual screen mode number 7 on the SNES doesn't actually do a landscape effect, the landscape effect mixes raster effects with mode-7. Mode-7 by itself just gives you bowser from Super Mario World.

As far as SNES vs Genesis.

The SNES gives you a lot in hardware including stuff like amazing transparency effects, scaling and rotation of a single background at 60 fps, gradient fills, shape drawing (like triangles or circles), lot's of color, 3 layers of parallax scrolling, 8 channel adpcm audio, etc... But... That's all you get without addon chips. The weak CPU plus the bitplane graphics format and the weird ram access means you're not doing special effects in software. Wanna do 3D? Add a chip.

The Genesis doesn't give you even close to that in hardware (it's 2 years older afterall), but the graphics hardware is very simple and easy to program. It also uses a chunky graphics format, has much more VDP bandwidth and the best CPU of the time. This means software effects (including 3D!) are possible. Audio wise it's a lot better than people think, comparable to arcades of the time, FM is hard to program by nature, and PCM on the genesis requires timed code, which is a total BITCH when allied to the shitty bankswitching mechanism used in the system. That's why the sound in most games sucks, and why some sound so awesome. Some people figured it out, others didn't.
The big problem is the color.

SNES also explodes if you try to write VRAM in active scan. Even SMS lets you du it (albeit with few limits)

SNES hardware is configured in such a way that it can be used as a containment-lure for high-functioning autistic men. You just set up a SNES in a basement, dangle the controllers and cardboard game-boxes in front of the subjects, then leave them to their dirty pleasures. Once you complete this task, you can go play a real video game console without having to worry about shouts of 'THE SOUNDS NOT AS GOOD MY VERSIONS BETTER DURRR' every 3 seconds.

That's the second best usage of the SNES I've heard so far Kogen.

SNES has more advanced audio and video hardware, but the Megadrive is much faster and flexible.

You can practice soldering after they've died, since their build quality is shit.

Quote:

---

Originally Posted by 5233

I've been studying 68K assembly to experiment with Genesis homebrew and hacking, among other things.

I however would like to know the pros and cons of SNES and Genesis hardware, besides graphics and sound, as I may also be interested in SNES homebrew. Supposedly Genesis is the fastest since it has 7mhz CPU, however I don't know how it performs when everything is put together.

I know SNES has mode7 but that's simply off the bat. I mean, can't you create a similar engine for a Genesis game? And what about the space limitations? Answers to these and other questions appreciated, thanks.

---

All the snickering aside, every console has at least some few tricks it does better (or at all) than other consoles. Are you looking to make a game, or make a demo to show such tricks (or your exploits of them)? Snes has quite a few tricks it can pull off that would be for some great demos IMO.

Some of the cool things the sPPU can do:
A color window register (defines a color to be transparent over the sub and main windows). You can clip with this as well (see the SMW key-hole effect).
BG transparency overlay (only certain modes).
Sprite transparency mode (only certain sprite priorities with certain sub palettes can do this)
2048 color mode (8bpp+extra bits in the tile map section per tile)
256 8bpp mode
4 layer BG mode (might be 2bpp but it still has unique subpalettes for each layer)
hdma allows up to 8 registers to be changed per scanline
Can change any graphic 'mode' on any scanline (Mario Kart does this)
up to 32 sprites per scanline. You can do some cool 8x8 sprite effects with that kind of limit
Tileoffset mode (both X and Y!!!). This is a VERY cool effect, but only a handful of games use it. It's done on an 8x8 tile resolution
The mode 7 rotate and scale registers can be changed every scanline, making for some weird warpy effects not doable on other consoles of that era (space megaforce does this for the spacestation level IIRC).

There's more, but I forget off hand.

Quote:

---

Originally Posted by tomaitheous

Tileoffset mode (both X and Y!!!). This is a VERY cool effect, but only a handful of games use it.

---

Super Bonk 2 is one of them isn't it? On the bonk face at the start of the first level.

To me it seems like they studied the MD and made the SFC the exact opposite in every regard.

FM based sound -> PCM based sound
straight to the point 8-bit based VDP -> 16-bit based VDP with tons of video modes
16/32-bit Motorola CPU -> bw compatible 8-bit MOS 6502 based CPU
black "Hi-Fi" CD player design -> bright toy-like design (JP/EU consoles)

Quote:

---

Originally Posted by Christuserloeser

bw compatible 8-bit MOS 6502 based CPU

---

This is just flat out wrong. The SNES used a 65C816, which was fully 16-bit.

http://en.wikipedia.org/wiki/WDC_65816

I wrote "6502 based CPU". Not "8-bit CPU". I meant that -from what I understood- it is fully compatible to the 8-bit code.

SNES can change colour, Genesis cannot. That is it.

Quote:

---

Originally Posted by Christuserloeser

I wrote "6502 based CPU". Not "8-bit CPU". I meant that -from what I understood- it is fully compatible to the 8-bit code.

---

Yeah, I understood that as what you meant, but he probably just mistook what you said as the other way around. The 65816 has an "emulation" mode where it's fully compatible with the 65C02 processors, but not the original 6502 processors - the 65C02 did away with the undocumented instructions and added a few more useful instructions, like pushing/pulling X and Y, storing zero, bit operations, etc.

My SNES has an eject button, but since they removed it in later versions you can't count that. Also the Genesis has Blast Processing ™ I'm not sure if the Mega Drive does though. I think it was only included in the American systems.

The eject button is completely pointless. I mean, did someone at Nintendo think it was really that had to remove carts? Hell, it's easier to remove carts from the SNES than it is the Genesis anyways.

The SNES is a great console for people whose favorite color is yellow.

Quote:

---

Originally Posted by Solkia

The eject button is completely pointless. I mean, did someone at Nintendo think it was really that had to remove carts? Hell, it's easier to remove carts from the SNES than it is the Genesis anyways.

---

Yes. I'm sure their rationale came from the same idiots who thought the zero insertion force design of the NES was a good idea. Both features scream "trying to be like a VCR so Americans will understand it."

This seems like as good a time as any to have some of you proof read the spec sheets I pulled together from various RE docs. Am I missing anything that was known back in the day? Did I over simplify something to the point that it can be read wrong? Are there newer or revised docs that I haven't cited yet? I'd appreciate any feedback. I intend for these to be useful for the casual reader and the aspiring programmer, the later as a quick reference guide to the appropriate docs.


http://www.gamepilgrimage.com/sites/...enesislogo.JPG 1 2 3 4

Lifespan:	1989-1995
CPU:	7.67 MHz 16-bit 68000
Co-Processors:	3.58 MHz Z80 (Audio/Master System) 5 Texas Instruments 76489 (PSG Audio): 4 Channels 6 Yamaha 2612 (FM Audio):7 6 Channels: One 8-bit Stereo Digital Audio Channel (DAC) replaces one FM channel 8 10 Audio Channels total
Audio RAM:	8KB
VIDEO:	VDP Master System Compatibility 9 Hardware Shadow and Lighting 10 Direct Memory Access (DMA): Transfer Rate: 7.2 KB per 1/60th second11
Resolutions:	256x224, 320x224, 320x448 12
RAM:	64 KB
Video RAM:	64 KB
Color RAM:	72 Bytes 13
VSRAM:	40 Bytes 14
Colors On Screen:	61 (30-75 in game, average 50) 15
Color Palette:	512
Sprite Max & Sizes:	80 sprites at 320x224 64 sprites at 256x22416 Sprite Sizes: 8x8, 8x16, 8x24, 8x32 16x8, 16x16, 16x24, 16x32 24x8, 24x16, 24x24, 24x32 32x8, 32x16, 32x24, 32x32 17
Sprites per Scanline:	20 at 320x224, 16 at 256x224 18
Background Planes:	2 layers with 16 colors per 8x8 pixel tile19 VDP handles scrolling as single planes, independently scrolling 8 line rows, and independently scrolling lines.20 Each 8 line row can can be displayed over or under others. 21
Storage:	Cart 32 Megabit (4 MegaByte) 40Mbit Super Street Fighter 2 Avg: 4 Mbit ('89-'91), 8-24 Mbit ('92-'95)

http://www.gamepilgrimage.com/sites/...s/SNESlogo.JPG 22 23 24 25 26

Lifespan:	1991-1997
CPU:	3.58 MHz 16-bit 65c816 27 6502 Compatibility (unused)
Co-Processors:	SPC700 (Sound CPU) S-DSP (Sound Generator) 8 Digital Audio Channels Filters for audio smoothing and echo 28 Compressed audio decoding 29
Audio RAM:	64 KB
VIDEO:	PPU 1 PPU 2 (On the same chip) 30 Mozaic/Pixelation DMA Transfer Rate: 5.7 KB per 1/60th second for each of 8 Channels 31 HDMA Used for per line updates 32
Resolution:	256x224, 256x448, 512x224, 512x448 33
RAM:	128 KB
Video RAM:	64 KB
Sprite RAM:	512 + 32 bytes 34
Color RAM:	512 Bytes 35
Colors On Screen:	240 36 37 (90-150 average in game)
Color Palette:	32,768
Sprite Max & Size:	128 sprites at: 8x8 or 16x16, 8x8 or 32x32, 8x8 or 64x64, 16x16 or 32x32, 16x16 or 64x64, 32x32 or 64x64, 16x32 or 32x64, 16x32 or 32x32 38
Sprites per Scanline:	32, 34 8x8 tiles, 256 sprite pixels per line 39
Background Planes:	Eight Modes Numbered 0 - 7 4 (96-colors, 24 per background, 3/tile) 3 (two 120-colors, one 24-colors) 2 (120-colors) 2 (240-colors, 120-colors) 2 (240-colors, 24-colors) 2 (120-colors, 24-colors, interlaced) 1 (120-colors, interlaced) 1 (240-color, scaled, rotated, etc) 40
Storage:	Cart 32 Mbit (4 MegaByte) 48 Mbit Star Ocean and Tales of Phantasia Average: 8 Mbit ('91), 16-32 Mbit ('92-'97)

There is 576 bits of CRAM in MD and a whole lot more than 512 colors

Yeah, in the footnote on the actual page it says 64x9 bits and references MacDonald's VDP doc. Looks like I left an older reference in the sheet. Fixing it now. How does it have more than 512 colors though?

The japanese super famicom and original famicom also have an eject buttons. I don't think the eject button idea was purely to make the console american friendly. However adding "normal mode" in megaman 2 and making the american version of mario 3 slightly easier clearly is something to make games more "stupid american" friendly. The same goes for final fantasy 4.

Quote:

---

Originally Posted by Obviously

Yes. I'm sure their rationale came from the same idiots who thought the zero insertion force design of the NES was a good idea. Both features scream "trying to be like a VCR so Americans will understand it."

---

The MD only does 64 sprites total in 256 wide mode. 80 is only for 320 wide mode. 512 colors is the basic palette; with high-lighting and shadowing, you about double the colors. Some people say it triples the colors, but many are the same as the initial 512.

Shadowing normal 512 colors only has 64 overlapping colors, highlight should give a bit bigger figure but still total count will be between 1200...1400. I need to make some calculations to determine the real number...

The shadow and highlight palette demo shows 1536 colors. How can we add that to the practical ability of the system though? In specs it's a 512 palette with 61 on screen. The fact that palette swap techniques and shadow and highlight can increase that is important but can also be overstated. Chilly, thanks for reminding me about the sprite limit in 32 column mode. I will add that back in.

It's exactly as relevant as SNES being capable of 1080i (or whatever the internet claims). Everwhere you go you always get colder than cold facts for Sega hardware while SNES games run in 512x448 and PS2 can do Full HD with ten billion polygons, no problem. - I demand "Blast Processing" to be added to the Genesis product description in ebay's catalogue, goddamit.

I liked the eject button. :(

I agree with wikipedia the m68k should be considered 32bit from http://en.wikipedia.org/wiki/16-bit#...nd_Intel_386SX

Quote:

---

The Motorola 68000 is sometimes called 16-bit because its internal and external data buses were 16 bits wide, however it could be considered a 32-bit processor in that the general purpose registers were 32 bits wide and most arithmetic instructions supported 32-bit arithmetic.

---

I was always confused on why people call the m68k 16 bit. The avr is 8bit because for the most part it can only do 8 bit math and the msp430 series is 16bit due to the fact that registers are 16 bit and that most math goes up to 16bit although there is nothing stopping you from doing 8bit math. I don't think that address bus should determine how many bits a processor has.

Did any commercial games use 32-bit instructions? I would think that if any games used it Sega would have made a huge deal about it.

Quote:

---

Originally Posted by sheath

Did any commercial games use 32-bit instructions? I would think that if any games used it Sega would have made a huge deal about it.

---

Yes the vdp needs 32bit commands to run it so ever game that displayed something on the screen at some point used 32bit instructions. Also maybe sega did not want to make a huge deal about it because of the 32x.

Hah, the 32X came out at the very tale end of the Genesis' life, I doubt it was a factor in Sega not mentioning the 68000 could do 32-bit instructions. What are we talking about though, 32-bit registers, 32-bit integer or floating point calculations? The VDP is 8-bit. If the 68000's buses are 16-bit how can it send 32-bit instructions, DMA?

It all seems more like an incidental bit of trivia than anything that would affect the games. I sure as heck don't want to slap 32-bit on that spec sheet and have every fanboy in the world complain about it while all I have is a handful of forum comments about it, oh, and wikipedia.

Quote:

---

Originally Posted by sheath

The VDP is 8-bit.

---

Wrong the vdp glitches on 8bit writes just read http://cgfm2.emuviews.com/txt/gen-hw.txt

Quote:

---

1.2) Memory access quirks

Byte-wide writes

Writing to the VDP control or data ports is interpreted as a 16-bit
write, with the LSB duplicated in the MSB. This is regardless of writing
to an even or odd address:

move.w #$A5, $C00003 ; Same as 'move.w #$A5A5, $C00002'
move.w #$87, $C00004 ; Same as 'move.w #$8787, $C00004'

Byte-wide reads

Reading from even VDP addresses returns the MSB of the 16-bit data,
and reading from odd address returns the LSB:

move.b $C00008, d0 ; D0 = V counter
move.b $C00001, d0 ; D0 = LSB of current VDP data word
move.b $C0001F, d0 ; D0 = $71
nop
move.b $C00004, d0 ; D0 = MSB of status flags

Word-wide writes

When doing word-wide writes to Z80 RAM, only the MSB is written, and
the LSB is ignored:

0000: AA BB CC DD ; Z80 memory
move.w #$1234, $A00000 ; do a word-wide write
0000: 12 BB CC DD ; result

Word-wide reads

A word-wide read from Z80 RAM has the LSB of the data duplicated in the MSB.

0000: AA BB CC DD ; Z80 memory
move.w $A00000, d0 ; do a word-wide read
d0 = $AAAA ; result

---

Also the vdp control and data port are 32bit addresses that is what I meant by you have to use 32bit instructions some where to draw stuff on the screen.

Okay, I don't even remember where I saw the VDP called 8-bit and it didn't make sense at the time anyway. I think it might have been earlier in this thread and being compared to the SNES PPUs. Anyway, does the VDP requiring 32-bit addresses (registers?) mean that the CPU needs to have 32-bit capabilities, or could a straight 16-bit or 8-bit CPU handle that as well?

I was referring to the MD's VDP being based on the Master System's VDP, I didn't know whether it really was an 8-, 16- or 32-bit chip.

The 68000 is 16-bit because the ALU (Arithmetic Logic Unit) is 16 bits. Any time you do a 32-bit operation, it's automatically broken into two 16-bit operations by the hardware. The architecture is 32-bit - you don't need to use two 16-bit operations to do a 32-bit one (like add or subtract or whatever); as mentioned, when you use 32-bit operations, the hardware internally takes care of breaking it into pieces to fit the ALU. On the 68000/68010/68008, that's 16 bits. On other members of the family, that's 32 bits. So from a programmer's point of view, it's a 32-bit CPU. From a hardware designer's point of view, it's 16. That's why you see it called 16/32 bit in many articles.

The bus is a bad way to judge a CPU... many systems use buses that are smaller but faster. For example, the N64 was the first 64-bit console, using the MIPS 4300. But it used a 16-bit bus! Well, technically speaking, 18 bits, but only the GPU could use those extra two bits. While only being 16 bits wide, it was STUPIDLY fast (for the time) as it used 500 MHz RDRAM for the memory. As a contrast, the Jaguar bus was 64 bits wide, but fairly slow (about 7MHz).

Quote:

---

Originally Posted by sega16

I agree with wikipedia the m68k should be considered 32bit from http://en.wikipedia.org/wiki/16-bit#...nd_Intel_386SX

I was always confused on why people call the m68k 16 bit. The avr is 8bit because for the most part it can only do 8 bit math and the msp430 series is 16bit due to the fact that registers are 16 bit and that most math goes up to 16bit although there is nothing stopping you from doing 8bit math. I don't think that address bus should determine how many bits a processor has.

---

The 68000 and the 386SX are* NOT* the same thing. The 386SX actually has a 32bit ALU. The 68000 has one 16bit ALU, not 3 (or two or chained or whatever, it's multipass for operations larger than 16bit). All the instructions on the 68000 are microcoded and all 32bit instructions (handing 32bit arithmetic and such) are basically hardware macro instructions. That's why it takes longer to do 32bit operations on the 68000 than 16bit operations. From a software perspective, it feels like a 32bit cpu I guess. But from a hardware perspective, it's not. Funny thing is, I don't see the need to make it out to be this 32bit CPU like I see on some forums and such. If you really want a real 32bit 68k so badly, go use a '020 or higher version. That whole Atari "ST" is bullshit. Yeah, maybe "ST" would make sense if they there using '020 or '030s with a 16bit data bus. Not the original 68000.

Quote:

---

I don't think that address bus should determine how many bits a processor has.

---

It doesn't. The ALU does.

Quote:

---

Wrong the vdp glitches on 8bit writes just read http://cgfm2.emuviews.com/txt/gen-hw.txt

---

Charles and I had quite a few discussions about the VDP in the MD in IRC. All ports to the VDP are 8bit. The data bus fetching from vram (the chips themselves) is 8bit. The ports use to access the VDP from the CPU side are also 8bit. I forget the specifics, but I do remember one specific thing that led to this finding; set the auto increment to an odd number and do a 16bit write to vram. The upper 8bits and lower 8bits end up in two different locations.

Quote:

---

Anyway, does the VDP requiring 32-bit addresses (registers?) mean that the CPU needs to have 32-bit capabilities, or could a straight 16-bit or 8-bit CPU handle that as well?

---

No. You can write 16bits at a time. He's making the '32bit' instructions out to be a lot more than what it really is. IMO it's a hack of an extension to the original SMS VDP modes and how you accessed vram. This is pretty much the only thing I didn't like about the VDP in Genesis/MD mode.


Sheath:

You have the sprites for SNES like 8x8 or 16x16, etc. But it should read 8x8 and 16x16, or .... etc. "Or" makes it sound like you can pick one or the other, but you actually have access to those two sizes per frame setting. Just not more than two.
Also, the 8bpp mode are 256 colors - not 240 colors. They don't use subpalettes per se. The pixel from the 8bit value directly corresponds to the value in CRAM. So you don't have duplicates in 8bpp tile modes. Also, for the NTSC model SNES/SFCs the max transfer rate in 224 vertical res mode is ~6.8k not ~5.7k. And you're missing one vertical res mode: 239 pixels. The vertical res can be either 224 or 239 for any of the horizontal res modes. In high res mode (512) sprites are in low res mode at double wide pixels. So only the BG is high res. I would also list the COLOR WINDOW plane too (it's its own plane) and besides fancy clipping, it's responsible for quite a bit of transparency effects seen in SNES games.

As do I.

Quote:

---

Originally Posted by old man

I liked the eject button. :(

---

Quote:

---

Originally Posted by tomaitheous

No. You can write 16bits at a time. He's making the '32bit' instructions out to be a lot more than what it really is. IMO it's a hack of an extension to the original SMS VDP modes and how you accessed vram. This is pretty much the only thing I didn't like about the VDP in Genesis/MD mode.

---

Do you know off hand if any of the available RE docs mention the 32-bit instructions of the VDP? Every time I've seen it mentioned has only been in forums, and never in any kind of discussion on how it would actually benefit anything at all.

Quote:

---

Originally Posted by tomaitheous

Sheath:

You have the sprites for SNES like 8x8 or 16x16, etc. But it should read 8x8 and 16x16, or .... etc. "Or" makes it sound like you can pick one or the other, but you actually have access to those two sizes per frame setting. Just not more than two.
Also, the 8bpp mode are 256 colors - not 240 colors. They don't use subpalettes per se. The pixel from the 8bit value directly corresponds to the value in CRAM. So you don't have duplicates in 8bpp tile modes.

---

Fixed these, I was wondering about the 256 color modes, they were being discussed differently than the 15-color tile modes.

Quote:

---

Originally Posted by tomaitheous

Also, for the NTSC model SNES/SFCs the max transfer rate in 224 vertical res mode is ~6.8k not ~5.7k. And you're missing one vertical res mode: 239 pixels. The vertical res can be either 224 or 239 for any of the horizontal res modes. In high res mode (512) sprites are in low res mode at double wide pixels. So only the BG is high res. I would also list the COLOR WINDOW plane too (it's its own plane) and besides fancy clipping, it's responsible for quite a bit of transparency effects seen in SNES games.

---

How does the math work out for the DMA rate? When I posted that number a few years back nobody challenged it, now I'd have to re-re-re check my own math. I'd rather just see how you arrived at 6.8k. Is the color window plane mentioned in the docs I have cited? I don't remember reading about it. It sounds like the background layer on the VDP that was usually used for menus and whatnot. I'd like to read up on the color window plane.

Quote:

---

Originally Posted by Solkia

The eject button is completely pointless. I mean, did someone at Nintendo think it was really that had to remove carts? Hell, it's easier to remove carts from the SNES than it is the Genesis anyways.

---

I think it was a great idea. Most gamers at the time would have to wiggle and yank carts outcast the time this eject device would save undue strees to the contacts, I like it.

The pin connector barely holds onto the contacts of my SNES. A piece of floss could pull carts out of it.