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.
Quote:
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.
Quote:
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.
Quote:
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:
Quote:
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:
Quote:
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:
Quote:
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:
Quote:
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)
Quote:
EDIT: how the checkerboard pattern in Project MD works:
Normal speedSlow 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.
Quote:
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..
gilligan wrote:
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
Like x86 is any different.
Quote:
Wasn't nintendo also looking at a 68K CPU for the SNES at some point ?
There's a 68K in the CD-i.
Instruction size on the x86 isn't nearly as tricky to figure out on the fly, since you don't usually have code flipping between 16 and 32 bit mode on the fly from function to function.
gilligan wrote:
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 ...
An execution-based disassembler can (and can distinguish data from code).
Er, stupid question, and not to be mean, but what does all this have to do with the idea I've written in the original post? ^.^'
Sik wrote:
Er, stupid question, and not to be mean, but what does all this have to do with the idea I've written in the original post? ^.^'
It's called digression. Whenever you notice it, feel free to PM me the URL of the post at which the digression began (right-click the little page icon next to the post date and choose "Copy Link Location") and I'll consider splitting the digression into a separate topic.
EDIT: Done. Thanks for pointing it out.
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).
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)
I thought this initially two but you can easily get around this without adding more bits to the nametables or sprites. Simply have more Color RAM, and registers that control which palette various layers use. So for example you could have 2, 3, or 4 palette sets of 64 colors. You could choose for Scroll Layer A whether to use the 1st, 2nd, 3rd, or 4th set of 64 colors for rendering. Same with Scroll Layer B (or Window) and Sprites. This would easily have allowed developers alot more color. You probably could have even implemented a cheap way to increase the colors available to sprites, or just added more bits to them as apparently they did have room.
I really think it's a shame Sega didn't see the need for more color to be available. Other than that the only thing I don't like about the MD is I think the sound hardware could have been better, or atleast I wish it was. But the #1 thing is colors available.
MottZilla wrote:
I thought this initially two but you can easily get around this without adding more bits to the nametables or sprites. Simply have more Color RAM, and registers that control which palette various layers use.
Even if it was as simple as just giving the sprites their separate set of 64 colors it would've helped plenty, like the SNES did. 8 palettes would've done so much for it.
Quote:
I really think it's a shame Sega didn't see the need for more color to be available.
I agree with the 64 colors thing being the #1 issue with the system. Even in 1988 it seems really shitty when you see the PCE released a year prior with even more subpalettes than the SNES.
Games trying to force music that was not made with synths in mind onto the YM2612 comes second for me. Whenever a game tries and fails to imitate a real instrument (guitar power chords come to mind) it sounds absolutely horrible. Rock n Roll racing being an incredibly offensive example =p
Each have their strengths; but overall the MD kills the SNES in terms of hardware. But I care more about the games, specifically my favorites: 2D role-playing games. It's for that reason that I care more about the SNES than the MD.
MD had Shining Force 1&2, and if you can call it a game, Shining in the Darkness. SNES had FF4, FF5, FF6, Chrono Trigger, Seiken Densetsu 2&3, Der Langrisser, Lufia 1&2, DQ12R, DQ3R, DQ5, DQ6, BoF 1&2, Bahamut Lagoon, Rudora no Hihou, Emerald Dragon, Tales of Phantasia, Star Ocean, Terranigma, Aretha 1&2, Earthbound, Daikaijuu Monogatari 1&2, Far East of Eden Zero, Illusion of Gaia, and on and on.
smkd wrote:
Even if it was as simple as just giving the sprites their separate set of 64 colors it would've helped plenty, like the SNES did. 8 palettes would've done so much for it.
Quote:
I really think it's a shame Sega didn't see the need for more color to be available.
I agree with the 64 colors thing being the #1 issue with the system. Even in 1988 it seems really shitty when you see the PCE released a year prior with even more subpalettes than the SNES.
That's what really bothers me. The SNES came after, so you can't say Sega was stupid because SNES supports 256 colors. But you can say that the PCE Engine which I think has 512 colors in its sub-palettes was right in their face and they thought or didn't think about how 64 was not enough. That's why the Sega CD was a real drag to me, since the #1 upgrade that would have made it look much better would have been a VDP upgrade that results in more color. The 32X breaks the color barrier, but came too late, and broke the bank too. Plus I think that the 32X is all frame buffers and bitmaps and not your typical PPU or VDP setup with hardware sprites and background layers. I suppose just since it seems like such a minor change could have had a huge impact it's so bothersome. I can't imagine it would have cost anything significant to have add more palette RAM to give BG and Sprites seperate palettes. And I've always said even if it did add cost I think they should have cut out Master System components. Like the Master System only modes left in the VDP.
MottZilla wrote:
That's what really bothers me. The SNES came after, so you can't say Sega was stupid because SNES supports 256 colors. But you can say that the PCE Engine which I think has 512 colors in its sub-palettes was right in their face and they thought or didn't think about how 64 was not enough.
I thought the PC Engine had 16 sub-palettes o_o; Oh well... And then again, their arcade systems allowed up to 4096 colors in some cases (talking about those on which the MD is based).
I guess it all comes down to cost, since the MD wasn't exactly cheap on launch from what I recall.
MottZilla wrote:
That's why the Sega CD was a real drag to me, since the #1 upgrade that would have made it look much better would have been a VDP upgrade that results in more color.
That'd have made the Sega CD much more costly due to requiring yet another custom chip. Not only that, but the extension port doesn't have any way to feed video signal into it, so it'd have needed to use a wrap cable like the 32x did.
MottZilla wrote:
The 32X breaks the color barrier, but came too late, and broke the bank too. Plus I think that the 32X is all frame buffers and bitmaps and not your typical PPU or VDP setup with hardware sprites and background layers. I suppose just since it seems like such a minor change could have had a huge impact it's so bothersome.
Yeah, the 32x only adds a framebuffer (double buffered, actually), but the VDP layers still are available so it's possible to use the tilemaps and sprites. Now, the 32x does software rendering in the framebuffer, which is why it's so slow...
MottZilla wrote:
I can't imagine it would have cost anything significant to have add more palette RAM to give BG and Sprites seperate palettes.
Yes, it was, especially when you consider chip space. The kind of memory used on CRAM probably eats quite a fair amount of chip space.
MottZilla wrote:
And I've always said even if it did add cost I think they should have cut out Master System components. Like the Master System only modes left in the VDP.
They did, they removed 4 of the 5 modes supported by the Master System (which didn't matter since only one Master System game used one of those). The main reason why they didn't remove backwards compatibility is because the Master System was successful in Europe and they didn't want to lose the market share there.
THE thing that always drove me nuts about the MD was the ugly columns always visible in the composite video output, due to them not varying the color carrier phase each scanline. Scroll in a game and as your eye follows moving things, their columns widen and narrow in a very ugly fashion. The SMS had the same problem, and they never fixed it. Hell, even the TI 99/4A had the problem. They all used the same graphics chip line.
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, SNES, PSX, Saturn, DC, N64 and all other machines produce...
Luckily there's RGB and all Sega machines starting from SMS do that so I'm happy. Now if someone makes a NES PPU replacement that does RGB and has those bugs I heard about that PlayChoice10 PPU has fixed up, I'd be first in line to get some, no matter if it costs 100USD per chip
If I recall correctly, one of those methods looks better for still images, while the other looks better for scrolling images, so yeah, I guess it's a tie when you consider that. In the end both suck anyways =P
A major downfall for the Snes is it's sprite management.
As I've already mentioned the Snes only having 4 sprite sizes, pick 2 at one time. One hardware sprite on the Genesis might require several hardware sprites on the Snes. This means that eventhough the Snes has 128 sprite entrees and the Genesis has 80, neither of the two has a clear advantage of having more onscreen objects.
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.
Then there's the fact that the Genesis can use up to 2048 tiles as sprites just as long as you give enough room for backgrounds, while the Snes is limited to only 512 tiles at one time with 2 moveable banks.
The way it is stored in oam is also pretty dumb, because on the Genesis you have 16 bit x and y coordinates, whereas on the Snes you have 8 bit coordinates. 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?
Sik wrote:
I thought the PC Engine had 16 sub-palettes o_o; Oh well... And then again, their arcade systems allowed up to 4096 colors in some cases (talking about those on which the MD is based).
I looked it up to be sure. The PC-Engine supports 16 subpalettes for BG, and another 16 for sprites, giving that 512 total.
Quote:
MottZilla wrote:
I can't imagine it would have cost anything significant to have add more palette RAM to give BG and Sprites seperate palettes.
Yes, it was, especially when you consider chip space. The kind of memory used on CRAM probably eats quite a fair amount of chip space.
MottZilla wrote:
And I've always said even if it did add cost I think they should have cut out Master System components. Like the Master System only modes left in the VDP.
They did, they removed 4 of the 5 modes supported by the Master System (which didn't matter since only one Master System game used one of those). The main reason why they didn't remove backwards compatibility is because the Master System was successful in Europe and they didn't want to lose the market share there.
I have heard both of these reasons before. While it may have cost something significant for 64 more colors and the logic to use different sets for BG and Sprites, I really think it would have been worth the cost. As far as Master System compatibility, perhaps they could have cut it from NTSC versions but retained it for PAL. And also I have always found backwards compatibility to be a luxury feature and not essential. Afterall, if you own SMS games (back when the Genesis launched) then you already own a SMS console. Would you really want to buy PowerBase converter just to play them on this new console? I think the money spent on Master System compatibility was money that could have been much better spent on improving the MD/Genesis hardware, which was the future and the whole point of the product's existence. Scrap SMS, add more colors, maybe more sophisticated sound, suddenly you may have a system that is a whole lot better.
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.
Quote:
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.
Quote:
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.
Quote:
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.
Quote:
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/chrisc/gotRGB/rgb_compare.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:
Quote:
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.
Quote:
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.
Quote:
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.
It's not the 65816 nor the PPU that bottlenecks the system, it's interface between the 65816 and the PPU that bottlenecks both the 65816 and the PPU.
blargg wrote:
Quote:
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.
That's a good point which I wasn't thinking of. Though I think that Nintendo was in such a powerful position after the Famicom that they didn't need to baby the developers. They should have just chosen the best CPU and other hardware components they could have.
psycopathicteen wrote:
It's not the 65816 nor the PPU that bottlenecks the system, it's interface between the 65816 and the PPU that bottlenecks both the 65816 and the PPU.
That depends on what you mean by bottleneck. The 65816 certainly is a barrier as you don't have a whole lot of CPU time. I'm not certain about the CPU<->PPU interface (I assume you mean speed of DMA) is a huge issue. I mean everyone would love even faster DMA so you could update even more tiles and background data each frame.
Both SNES and Genesis despite their issues were able to produce amazing top quality games. There was a big thread about this sort of thing on Spritesmind forums, basically a Sega forum similar to Nesdev.
MottZilla wrote:
blargg wrote:
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.
That's a good point which I wasn't thinking of. Though I think that Nintendo was in such a powerful position after the Famicom that they didn't need to baby the developers. They should have just chosen the best CPU and other hardware components they could have.
It still would have slowed developers, no matter how much market force Nintendo had. Slowing their developers would weaken their position in relation to the competition. With the 65816, a lot of code could be ported very easily, with minimal changes.
MottZilla wrote:
That depends on what you mean by bottleneck. The 65816 certainly is a barrier as you don't have a whole lot of CPU time.
Are you kidding me? You've seen how cpu intence my game is, and that doesn't even take half the availeable CPU time, and I'm not doing that much optimization either.
Honestly people should do more experimenting with hardware and not just accept what is often repeated. Don't be afraid to try
Quote:
I'm not certain about the CPU<->PPU interface (I assume you mean speed of DMA) is a huge issue. I mean everyone would love even faster DMA so you could update even more tiles and background data each frame.
Sort've. I was refering to the Snes's redundant register set. They could've had a lot less PPU hardware registers. It pulls my hair out whenever I need to use the PPU.
The way the OAM is organized requires a lot of extra CPU calculation. It's not running out of cpu time that I'm worried about, it's getting everything done that I worry about. The fact that the 65816 takes more instructions to do tasks is more of a problem than it's clock speed. Especially when you also are required to do more tasks than other systems. It could be clocked at 14 Mhz and not make a difference for me, since I already have plenty of cpu time left to do cpu intense calculations.
A quick point about the CPU speeds.
65816: 21.477275/6 (FastROM), instructions are 2-9 cycles or so.
So, at 3.58MHz, the insruction rate ranges from 1.78M insns/sec to about 360K insns/sec
68000: wikipedia says it's running at ~7.67MHz
Move instructions range from 4-34 cycles, giving instruction rates from 1.9M/s to 226K/sec.
The two are not in completely different leagues, despite what some might try to claim. Well written 816 code that takes proper advantage of the direct page and whatnot should run on par with 68k code running primarily from registers. The 68k does have an easier time working with 16 bit quantities, since there's no extra penalty on those over bytes.
A fun thing to point out. I had heard 68k opcodes ate a lot more cycles, but never got raw instruction to instruction counts.
Overall the 68k could do more with its instructions, SNES cannot multiply, divide, shift by more than one place, or really do anything remotely interesting to its other two registers.
You waste a lot of time on the SNES juggling the index registers on the stack, and on switching register sizes around. However, you really can do some amazing low-level optimizations.
There's also the SA-1, if you count it. Out of I-RAM, it's two clocks per cycle, so you can tripe your theoretical instruction counts. But more often than not you need lots of BW-RAM, which is four clocks per cycle. Could compare to the SVP to make that more fair.
CPU<>PPU being a bottleneck sounds silly. Maybe for 256x240 output on NTSC, sure. But you can always crop the screen vertically and get a lot more time, SFA2 and similar games do this. There's enough bandwidth to play full motion video that blows away even the Mega CD. Just not enough ROM space for it.
I have a hard time imagining which PPU registers they could have gotten rid of. There's a few missing bits, especailly on the enables that tend to use five or six bits. But short of being stupid and unevenly bit-packing the whole thing, it's actually quite amazing how well utilized the 64-byte region was. The PPU can do a ton of things at the same time.
Byuu, from what I know you're kind of authority when it comes to SNES, so can you give some numbers regarding VRAM bandwidths per line/frame with and without DMA ...?
On MD one can achieve ~18KB/sec per frame in 320x240 or ~21KB/sec on 320x224, in 50Hz of course, using DMA. in 60Hz you're limited to ~11KB/sec per frame using DMA. Those figures are maximum you can transfer during a single frame without blanking anything... full blanked frame gives you ~59KB/sec in 50Hz
byuu wrote:
There's also the SA-1, if you count it. Out of I-RAM, it's two clocks per cycle, so you can tripe your theoretical instruction counts. But more often than not you need lots of BW-RAM, which is four clocks per cycle. Could compare to the SVP to make that more fair.
Comparing the SVP to the SuperFX would actually be more fair (isn't the SuperFX faster than the SA-1?).
byuu wrote:
CPU<>PPU being a bottleneck sounds silly. Maybe for 256x240 output on NTSC, sure. But you can always crop the screen vertically and get a lot more time, SFA2 and similar games do this. There's enough bandwidth to play full motion video that blows away even the Mega CD. Just not enough ROM space for it.
No, there isn't, if you want to load an entire frame on the Mega Drive (assuming no cropping and such), you're looking for 4 frames per update (well, on NTSC at least, PAL has over double the amount of transfer rate in blank x_X). That's why you're meant to use sprites, tilemaps, etc. =P
Sik wrote:
Comparing the SVP to the SuperFX would actually be more fair (isn't the SuperFX faster than the SA-1?).
Super FX is heavily specialized for 3D graphics, as is the Sega Virtua Processor. The SVP, which appears to be based on a Samsung SSP1601 core, is clocked at roughly the same speed as the FX2. SA-1, on the other hand, is a general-purpose application coprocessor, as are the SuperH family CPUs in the 32X, Saturn, and Dreamcast.
Quote:
if you want to load an entire frame on the Mega Drive (assuming no cropping and such), you're looking for 4 frames per update (well, on NTSC at least, PAL has over double the amount of transfer rate in blank x_X). That's why you're meant to use sprites, tilemaps, etc. =P
A full frame in either console's 256-pixel-wide mode is 256x224x4bpp, or 28 KiB. I've been quoted 7 KiB per vblank for DMA copying on SNES too. But if you cut the full-motion video to a cinematic display aspect ratio with 160 lines, I don't see why you can't easily fit 30 fps with an external FMV decoder. Imagine a coprocessor that decodes WebM from an SD card soldered onto the cartridge.
Quote:
Byuu, from what I know you're kind of authority when it comes to SNES, so can you give some numbers regarding VRAM bandwidths per line/frame with and without DMA ...?
You don't even want to know the bandwidth without DMA.
But with it ... you have effectively 1324 cycles per scanline. DMA consumes 8 cycles per byte transferred. NTSC mode has 262 scanlines @ 60hz, PAL mode has 312 scanlines @ 50hz.
My numbers are in bytes per frame. So for your average 256x224 NTSC game, that gives you 6.28K/f. For your average PAL game, that gives you 11.9K/f. NTSC can use 256x240 at 3.6K/f, and PAL can use 256x224 at 14.56K/f.
You can however disable the screen using force blank, and take lines off the top and bottom, which allows you to increase bandwidth further. Say you cut an 8-pixel row off the top and bottom, which would be lost to overscan anyway, you can get 8.93K/f for NTSC. The video rendering trick cuts off even more lines, and uses page-swapping at 20-30fps to double or triple that rate.
Without the active display getting in your way, the maximum bandwidth is 43.36K/f, or 2.68M/s.
Quote:
Comparing the SVP to the SuperFX would actually be more fair (isn't the SuperFX faster than the SA-1?).
The SuperFX is garbage. It is specialized to the point of absolute insanity. The SA-1 by comparison is a full general-purpose CPU with lots of nifty tools like bitmap<>bitplane conversion, H/V/counter IRQs, vector address override, RAM/ROM protect, two distinct DMA modes, etc.
I think I'll just have to cut 16 pixels off the top and bottom of the screen, since I'm trying to become more practical and less idealistic.
I'm even changing my metasprite routine so instead of using for the x and y displacement and sprite attributes, the metasprites will be just be a rectangle with how many blocks tall and how many blocks wide.
tepples wrote:
The SVP, which appears to be based on a Samsung SSP1601 core, is clocked at roughly the same speed as the FX2.
I guess that explains this (make sure it seeks to 6:36):
http://www.youtube.com/watch?v=PklSWesc1dM#t=6m36sAlthough somebody I know checked the cartridge and it seems to take the same clock used by the 68000... I guess there's some multiplier there, but if it uses that directly then WTF o_O (actually the SVP can use less instructions than the SFX to achieve the same result IIRC, so that probably also helps)
byuu wrote:
The SuperFX is garbage. It is specialized to the point of absolute insanity. The SA-1 by comparison is a full general-purpose CPU with lots of nifty tools like bitmap<>bitplane conversion, H/V/counter IRQs, vector address override, RAM/ROM protect, two distinct DMA modes, etc.
Still my point stands, the SVP is more akin to the SuperFX than to the SA-1.
EDIT: talking about SA-1, these instructions are listed in the docs:
http://srb2town.sepwich.com/junk/lolinstructions.PNG
(just mentioning for the sake of it, couldn't miss the chance XD)
byuu wrote:
You don't even want to know the bandwidth without DMA.
Hehe, must be really slow then
I could decode and display around ten 320x240 4-bit BMP files on MD per second in 50Hz, so even without DMA, things are not too bad, but still quite a bit worse than possible with DMA.
byuu wrote:
But with it ... you have effectively 1324 cycles per scanline. DMA consumes 8 cycles per byte transferred. NTSC mode has 262 scanlines @ 60hz, PAL mode has 312 scanlines @ 50hz.
My numbers are in bytes per frame. So for your average 256x224 NTSC game, that gives you 6.28K/f. For your average PAL game, that gives you 11.9K/f. NTSC can use 256x240 at 3.6K/f, and PAL can use 256x224 at 14.56K/f.
You can however disable the screen using force blank, and take lines off the top and bottom, which allows you to increase bandwidth further. Say you cut an 8-pixel row off the top and bottom, which would be lost to overscan anyway, you can get 8.93K/f for NTSC. The video rendering trick cuts off even more lines, and uses page-swapping at 20-30fps to double or triple that rate.
Without the active display getting in your way, the maximum bandwidth is 43.36K/f, or 2.68M/s.
This does not sound that bad at all IMO... it is still slower than MD in 256 pixel modes ~9.5KB/f for 60Hz, ~18KB/f for 50Hz but not too major.
And I gave wrong value for max per blanked frame... it is 63KB/f for 50Hz, 53KB/f for 60Hz, total of 3.1MBytes/sec
Sik wrote:
EDIT: talking about SA-1, these instructions are listed in the docs:
http://srb2town.sepwich.com/junk/lolinstructions.PNG(just mentioning for the sake of it, couldn't miss the chance XD)
Those are SuperFX instructions, but yes. I've tried to make a juvenile program, but haven't had much luck.
All of these are legal SFX opcodes: STOP CACHE TO WITH LOOP PLOT SWAP COLOR NOT ADD SUB MERGE AND LINK SEX LOB OR COLOR.
Maybe one of you can come up with a funnier sentence using only the above words. Bonus points if the sequence actually does something useful on SFX hardware.
Something like:
Code:
SexyPlot:
STOP
LINK
WITH
CACHE
AND
HAVE
SEX
OR
; ... I got nothin'
ShakespeareanFilter:
TO
STOP
OR
NOT
TO
STOP
; That is the question, that I might ask.
Yeah, see ... so close, yet so far :/
byuu wrote:
Something like:
Code:
SexyPlot:
STOP
LINK
WITH
CACHE
AND
HAVE
SEX
OR
; ... I got nothin'
UNIX is the same way:
Not exactly safe for work (UNIX counterpart to Windows chkdsk is close to an indecent word)
byuu wrote:
Sik wrote:
EDIT: talking about SA-1, these instructions are listed in the docs:
http://srb2town.sepwich.com/junk/lolinstructions.PNG(just mentioning for the sake of it, couldn't miss the chance XD)
Those are SuperFX instructions, but yes. I've tried to make a juvenile program, but haven't had much luck.
Gah. I hate going through the SNES docs to figure out to what does each thing belong, OK? =P (I guess I skipped where did the SuperFX stuff start)
byuu wrote:
Code:
SexyPlot:
STOP
LINK
WITH
CACHE
AND
HAVE
SEX
OR
; ... I got nothin'
WTF?
TmEE wrote:
byuu wrote:
You don't even want to know the bandwidth without DMA.
Hehe, must be really slow then
Well, if you want to do something completely useless like filling the v-ram with $05 without a DMA, using the fastest way method possible you can do this.
rep #$20
lda #$2100
tcd
lda #$0505
sta $18
sta $18
sta $18
sta $18
sta $18
sta $18
sta $18
sta $18
sta $18
sta $18...
In 16-bit mode "sta $18" takes 4 cycles and stores 2 bytes, so it takes 2 cycles to load 1 byte, which should be about 4kB.
Quote:
In 16-bit mode "sta $18" takes 4 cycles and stores 2 bytes, so it takes 2 cycles to load 1 byte, which should be about 4kB.
SNES timing is best done in master clocks, not CPU cycles, since the cycle length varies depending on where the memory is.
Sik wrote:
WTF?
I'll be nice:
Quote:
I've tried to make a juvenile program, but haven't had much luck.
Maybe one of you can come up with a funnier sentence using only the above words.
In other words, as you astutely pointed out with your "lolinstructions.PNG" image, many of the opcode names sound rather dirty, or juvenile. So that was an example of trying to string multiple opcodes together in such an order that it comes off as if you were actually saying something dirty or offensive. I screwed it up anyway because HAVE isn't a valid opcode.
If you still don't follow, then I will quote Samuel L. Jackson from Pulp Fiction. You've been warned :P
SEX is an instruction. Oh my god. What were they thinking ??
Maybe the same thing as the
6809 designers? The 6809 also had a COMA instruction (which sadly doesn't put the processor in a hibernated state for an indefinite period of time).
blargg wrote:
Quote:
In 16-bit mode "sta $18" takes 4 cycles and stores 2 bytes, so it takes 2 cycles to load 1 byte, which should be about 4kB.
SNES timing is best done in master clocks, not CPU cycles, since the cycle length varies depending on where the memory is.
I didn't touch work ram.
That wasn't his point. Point was that CPU Cycles mean nothing because depends on access to FastROM, SlowROM, WRAM, Registers, and Internal Operations the length of time taken will vary. And if you are concerned about the actual time you have in VBLANK to transfer data that matters.
sta $18
okay lets analyse this instruction
first cycle it accesses ROM (3.58 Mhz)
second cycle it access ROM again (3.58 Mhz)
third cycle it accesses v-ram data port (3.58 Mhz)
last cycle it accesses v-ram data port (3.58 Mhz)
I didn't touch anything that used 2.68 Mhz.
Anyway, my post was supposed to be a joke since nobody would ever use that kind of method in the first place.
blargg wrote:
Quote:
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.
That's what I thought as well. And probably the biggest reason why the Hudson chose to go with a 65x variant processor for the PC-Engine over a 16bit bus processor (as both the 16bit graphic chips support full 16bit data bus mode processor interface as well).
Quote:
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?).
I don't see what that has to do with Sega's decision on CRAM?
Quote:
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).
And? By comparison, it's still only bytes, not kilobytes more (or more precisely, bits. I highly doubt CRAM is 16bit wide, but more likely 9bit internally). I highly doubt it would have broke the bank or come anywhere near that, to include another 64 entries of 9bit SRAM on the chip. Giving sprites access to either block and each layer access to either block. No external DAC needed.
Anyway, wasn't this thread originally about which system is easier to program for? Or did I miss something?
Not which is better, but which is easier or more straight forward:
Genesis:
68k;
A very lovely cpu. The instruction set is very powerful in that you don't have to write a lot of small logic. This translated into speed, of course, if it matches to what you need to accomplish. And at other times, it can be slow. But the main point, is that it's very nice. The addressing modes (EA) being the real bread and butter, IMO. Follow very closely with a straight linear address range. No banking or mapping. Pure bliss. I have to say, from the small projects I've done on the 68k - it was like I was on vacation (coming directly off of a 65x project). The downsides were small. Minding your WORD and INT boundaries, small set of address registers (depends on how you code, on the 65x I use a lot of ZP just for address registers - making the 68k feel a little cramped to me in that regard), and unable to create equates for address names (probably just a limitation of the assembler I used). The last one made my code less clear (again, coming from 65x my address regs had corresponding names and even normal zp variables did - ZP being uses a data register VS 68k's use of Dn, by comparison).
VDP;
Everything is straight forward. Nothing felt convoluted or restricted, much. You have a wide range of sprite sizes for any SAT entry. Tilemaps were easy to setup. Tiles and sprites used the same cell format. You're a little restricted as to where to place the tilemap pointers, but no a problem really. The only thing that I disliked, was the convoluted vram address setup for the COMMAND port. Not sure WTF they were thinking there. It was a real pain/chore first time around, getting used to it. Given how powerful the instruct set it, linear address range, powerful addressing mode, etc - makes it perfect for something like a C compiler. But where's the fun in that??? C for these old consoles? Pfft.
Sound;
Didn't really do anything in this department, but reading over the DOCs - the 2612 looks fairly simple to use (interface with, that is).
z80;
Haven't touched it yet. I've done some z80 work in the past, and it is what is it. Can't say that I'm a fan of the z80 ('cause I'm not
), but you're not going to be doing a lot with this little as either way.
SNES:
sPPU;
Very convoluted IMO. Lot of strict limitations too on the layout of things (tiles, sprites, formats, etc). Strange, both convoluted, kind of a mess, and strict about layouts, and yet very powerful and a lot of features.
sCPU;
It's 65x. Like all 65x based/similar processors, you need to learn to cut on teeth on these. In general, the processor itself isn't that hard to learn (IMO), but becoming really proficient is a whole 'nother story. You can really get some speed out of this arch, but the code almost always results in a convoluted mess of near unreadable code to most other coders. One of the reasons I love this processor. The rewards are worth the labor. But for any sort of speed related programming, definitely *not* a beginners processor. C compilers also suck for this arch (and understandably so).
SPC/DSP;
Haven't touched either. Sound registers look straight forward. I like the instruction set of the little processor
I'd honestly take a 7.16mhz version of that little 8bit processor over the funky slow banked '816 as the main console processor, but that's just me
tomaitheous wrote:
Quote:
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?).
I don't see what that has to do with Sega's decision on CRAM?
They most likely thought that having two tilemaps made it superior to the PC Engine (which they didn't care so much anyways since they were looking at the NES), and they probably knew nothing about what the SNES would do with color, so they just stuck with that because it was better than both the Master System and the NES.
tomaitheous wrote:
Quote:
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).
And? By comparison, it's still only bytes, not kilobytes more (or more precisely, bits. I highly doubt CRAM is 16bit wide, but more likely 9bit internally). I highly doubt it would have broke the bank or come anywhere near that, to include another 64 entries of 9bit SRAM on the chip. Giving sprites access to either block and each layer access to either block. No external DAC needed.
Actually, I'm not sure. I should check what happens when reading CRAM, it's possible that actually all 16 bits are stored. Pointless, but hey, this is Sega, they also screwed up majorly other things. I believe this is the same situation for VSRAM (despite the fact that only 10 bits would be needed).
tomaitheous wrote:
and unable to create equates for address names (probably just a limitation of the assembler I used)
Yeah, definitely your assembler. ASM68K supports aliasing of registers.
tomaitheous wrote:
The only thing that I disliked, was the convoluted vram address setup for the COMMAND port. Not sure WTF they were thinking there.
By doing it this way, the 68000 never gets direct access to video memory and has to go through the VDP. Then the VDP can decide if allow the access or make it wait because it needs the memory first.
tomaitheous wrote:
Sound;
Didn't really do anything in this department, but reading over the DOCs - the 2612 looks fairly simple to use (interface with, that is).
Until you try to use the DAC. There's a complete lack of hardware timing, and no buffering at all, so you need to load samples at the exact moment they should play. Not fun at all. That's why many drivers are 68000+Z80, while some are Z80 only and hope it sounds decent, and some simply completely ignore the DAC.
tomaitheous wrote:
z80;
Haven't touched it yet. I've done some z80 work in the past, and it is what is it. Can't say that I'm a fan of the z80 ('cause I'm not
), but you're not going to be doing a lot with this little as either way.
The Z80 is fine... until you stumble against bank switching. What was Sega thinking on? I know that 9 bits don't fit in one byte, but there wasn't any reason for having to write to an address 1 bit per time... that's extremely slow. Writing two bytes (separate addresses if needed) instead would have been much better.
Sik wrote:
The Z80 is fine... until you stumble against bank switching. What was Sega thinking on? I know that 9 bits don't fit in one byte, but there wasn't any reason for having to write to an address 1 bit per time
Probably to save pin count, same as on MMC1. The MMC1's serial port allows connection to just D0 and D7 instead of D0, D1, D2, D3, and D4, allowing the IC to use the next smaller package size. Yet NES PCM engines worked around this limitation: how many words can you make before the sun goes down?
As for "complete lack of hardware timing", can't the Z80 see the HV counter?
That timing would be software based, and it would not be too useful... no more than YM2612 timers.
Regarding serial banker, pincount has nothing to do with it, Z80 is wired parallel to one of the ASICs, and all magic happens in that ASIC.
Something that was actually a good idea for Nintendo was having a 16x16 pixel tile mode. No longer a need for metatiles, and you can update a lot more onscreen tiles without running out of time. I wonder why this wasn't used much.
How do you know that it wasn't used much? I would imagine a fair number of games probably used it. Pretty sure BS-Zelda uses it.
MottZilla wrote:
How do you know that it wasn't used much? I would imagine a fair number of games probably used it. Pretty sure BS-Zelda uses it.
Your right, I don't know why I just said that. Maybe it was a brainfart.
You're right it was probably a good idea. Maybe the developers liked the idea to be eventually able to assign a palette for each 8x8 tile (as opposed to the NES) ?
I guess Romancing Saga and Secret of Evermore uses this... but that's all I can remember.
Bregalad wrote:
You're right it was probably a good idea. Maybe the developers liked the idea to be eventually able to assign a palette for each 8x8 tile (as opposed to the NES) ?
With 16 colors in a palette I imagine programmers would rarely need to apply them to 8x8 blocks individually...
16 colours oughta be enough to anybody, but don't quote me on it!
One problem with 16x16 pixel hardware tiles is that you end up with a bunch of redundant blank tiles taking up VRAM.
Yeah I guess that's the only reason not to use them - but then the tilemap would take up 4 times less VRAM if 16x16 tiles were used, probably compensating it largely.
Another good reason is if you're using a 8x8 or 8x16 font on the same BG as the game's graphics - but as long as you use a separate BG for text I fail to see any reason not to use 16x16 tile mode.
Quote:
16 colours oughta be enough to anybody, but don't quote me on it!
Sorry couldn't resist.
Quote:
By doing it this way, the 68000 never gets direct access to video memory and has to go through the VDP. Then the VDP can decide if allow the access or make it wait because it needs the memory first.
No, I don't mean I/O port access to vram. I mean the vram address write
setup via the COMMAND port. Requires two 16bit word writes, but the 16bit address isn't straight linear line of bits. It's a carry over from the SMS mode, the upper bits are in the second part of the WORD command. For immediate addresses, you can do a quick macro to shift in the bits. But for dynamic stuff (random tilemap and other stuff), it was just an annoyance. I think the eventually built a subroutine for it. Like I said, not a huge deal once you get used to it. But still an annoyance, though, when you need to do some quick changes or such.. or whatever.
Quote:
and they probably knew nothing about what the SNES would do with color, so they just stuck with that because it was better than both the Master System and the NES.
The PC-Engine was already out a year before and had set the bar. The PC-Engine's popularity was very widely known in Japan and was extremely popular the day it was released. While it might have been nothing outside of Japan, I think it's foolish to think that Sega wasn't targeting competing with the PCE with the Megadrive as well as the Famicom.
There's also the fact that the Megadrive subpalette system is barely an upgrade from the Master System specs. And the Famicom was already capable of 8 subpalettes. Not to mention arcade systems, which Sega was no stranger to, easily has 16 and 32 and larger number of subpalettes (a lot of arcade systems still had the 16/15 color per sprite/tile cell limit). You don't need the SNES to compare to the MD, to see how made a poor decision there.
Quick question to someone that knows about the MD/Genesis, does it support 16x16 background tiles?
tomaitheous, didn't we have a similar debate about the MD on SpritesMind forums? I can't believe people defend Sega's very bad decision on the MD's sub palette situation. I think Sega's engineers (or whoever made final decisions) were just not very thoughtful, or they were just stupid. I don't think MD needs PCE level subpalettes, but 128 colors would have made a huge difference. I've said it before that maybe if they had done that people wouldn't have compared games like Mortal Kombat 1&2 between the SNES and MD and been so disgusted by the lack of color/blandness on MD.
One really bothersome thing on MD I remember is in MK1, because of palette limits Jonny Cage's projectile is a gray blob instead of the green energy bolt it was intended. I think Kano's knife is a gray color as well instead of a light blue. Not sure about some of the other characters but it was very apparent. Which makes for the very interesting situation where the MD version plays excellent while looking poor, sounding just OK. Then the SNES version looks pretty good, sound good, and plays terrible.
The 400bits of on-chip VSRAM could've gone towards another color palette instead. It's most of what another set of 64 colors would cost. I've no idea why they thought of adding vertical offset-per-tile before addressing the horrible color palette.
MottZilla wrote:
Quick question to someone that knows about the MD/Genesis, does it support 16x16 background tiles?
8x8 cells. Horizontal and vertical flip options. Tile priority too.
Quote:
tomaitheous, didn't we have a similar debate about the MD on SpritesMind forums? I can't believe people defend Sega's very bad decision on the MD's sub palette situation. I think Sega's engineers (or whoever made final decisions) were just not very thoughtful, or they were just stupid. I don't think MD needs PCE level subpalettes, but 128 colors would have made a huge difference. I've said it before that maybe if they had done that people wouldn't have compared games like Mortal Kombat 1&2 between the SNES and MD and been so disgusted by the lack of color/blandness on MD.
Yeah, we did
And you're right. It didn't need the
overkill amount of subpalettes that the PCE had (I'd go so far as to say that the PCE needed that many subpalettes because of the single layer BG system). 128 color would have been a huge increase in color flexibility - IMO. I've done little stuff on the MD, but the biggest project I did was porting Bonk 1 over to the MD. Something as simplistic looking as
that, still had to have the colors stripped back for just the first level. It was a pain (and I have a bit of experience in this department already, so I'm not stranger to color reduction by hand). I had room left for another 32 colors - which I reserved for sprites. 1 for Bonk (15 colors) and two 7 color slots on the last subpalette for enemies. No room for flashing or greyscale/frozen state of the original for the enemies, either. I really applaud developers that manage to get good visuals out of the system. It's a testament to their skills.
Quote:
One really bothersome thing on MD I remember is in MK1, because of palette limits Jonny Cage's projectile is a gray blob instead of the green energy bolt it was intended. I think Kano's knife is a gray color as well instead of a light blue. Not sure about some of the other characters but it was very apparent. Which makes for the very interesting situation where the MD version plays excellent while looking poor, sounding just OK. Then the SNES version looks pretty good, sound good, and plays terrible.
Yeah. And it really had little to nothing to do with the 9bit color palette. Most games don't even hit that limitation on the Genesis, because of the restrictive subpalette issue.
tomaitheous wrote:
[The MD] didn't need the overkill amount of subpalettes that the PCE had (I'd go so far as to say that the PCE needed that many subpalettes because of the single layer BG system).
It might have been overkill at the time, but GBA gave up priority per tile to use the same number of subpalettes.
Quote:
128 color would have been a huge increase in color flexibility - IMO. I've done little stuff on the MD, but the biggest project I did was porting Bonk 1 over to the MD. Something as simplistic looking as that, still had to have the colors stripped back for just the first level.
What are you talking about? Bonk was also on the NES.
Quote:
What are you talking about? Bonk was also on the NES.
...but didn't look anywhere near as good as the original.
Quote:
128 color would have been a huge increase in color flexibility - IMO. I've done little stuff on the MD, but the biggest project I did was porting Bonk 1 over to the MD. Something as simplistic looking as that, still had to have the colors stripped back for just the first level.
You only used one single palette for the whole BG... on PCE there were more used....
ReaperSMS wrote:
A quick point about the CPU speeds.
65816: 21.477275/6 (FastROM), instructions are 2-9 cycles or so.
So, at 3.58MHz, the insruction rate ranges from 1.78M insns/sec to about 360K insns/sec
68000: wikipedia says it's running at ~7.67MHz
Move instructions range from 4-34 cycles, giving instruction rates from 1.9M/s to 226K/sec.
The two are not in completely different leagues, despite what some might try to claim. Well written 816 code that takes proper advantage of the direct page and whatnot should run on par with 68k code running primarily from registers. The 68k does have an easier time working with 16 bit quantities, since there's no extra penalty on those over bytes.
Forgot to respond. YOU ARE ABSOLUTELY CORRECT!!!
Perhaps the effective MIPS of the 65C816 needs to be lowered, as I'm guessing the average instruction will have a cycle of SlowRAM access. Immediate and jump instructions have fewer, instructions in 16-bit have more, and RMW instructions have more.)
With similar instructions-per-second counts, the question becomes how much does each instruction do? The 68K has autoincrement addressing, memory-to-memory addressing, 'addq' and 'subq' which work like 'inc' and 'dec' with values up to 8, 'asr' that saves an instruction over cmp/ror on the 6502 family, 32-bit ALU ops, hardware 16-bit multiply and divide, more conditions for branches involving <=, >, signed <, signed <=, signed >, and signed >=, fused decrement and branch for loops ('dbxx'), and multi-register block copies like ARM's LDMIA/STMIA.
ASL.W #4,d0 on the 68000 takes 14 cycles whereas ASL, ASL, ASL, ASL on the 65816 takes 8 cycles, despite being more instructions. Shifting takes 2 cycles per bit on both cpus, but the 68000 always has an overhead of 6 cycles when using shifting instructions.
DBRA.W d0,loop on the 68000 takes 10 cycles whereas DEY, BNE on the 65816 takes 5 cycles.
So is it another 6502 vs. Z80 story here, where the 6502-family CPU performs as if it has an internal clock doubler?
More or less. The 68k's cycle counts get pretty ridiculous when you start using all the features, though it does have the advantage of only needing one bus cycle to load a 16-bit value.
I don't really see the benefit of having a 16-bit data bus with a 4 cycle memory accesses, over having an 8-bit bus with 2 cycle memory accesses.
The 65816 has a 1-cycle memory bus though.
The benefit is the ability to use slower RAM. By having each memory cycle take multiple processor cycles, the processor can be doing other things while it's waiting for memory.
tepples wrote:
Perhaps the effective MIPS of the 65C816 needs to be lowered, as I'm guessing the average instruction will have a cycle of SlowRAM access. Immediate and jump instructions have fewer, instructions in 16-bit have more, and RMW instructions have more.)
I agree. You can't really say the SNES CPU runs at 3.58mhz since in not practical game program will it ever run that speed. That's the peak, not the average. I really do think it should be obvious that the 68000 @ 7.6mhz is going to be able to get more done than the 65c816 @ 2.68mhz ~ 3.58mhz. Not basing that solely on clock speed but more on how the processors work and just observing some commercial software for both platforms.
The SNES obviously isn't pathetically slow to some point where it can't do anything. But I do think it's quite fair to say on the SNES you don't have as much cpu time to be wasteful with.
It's a benefit when you consider the predecessor chips were an 8-bit data bus with a 4 cycle access period. Pretty much the entirey of the 8080/8086 derivatives used that sort of bus, and the 6800 and it's children used a very similar one.
One thing I like to point out.
It's 2010, FastROMs are dirt cheap nowadays.
Anyway, I'd say in FastROM mode it is approximately 3.3 Mhz and it's about the same as a 5 Mhz 68000.
And how did you come up with these numbers?
The 68000 beats the 65816 mainly at 32-bit calculations. It still has more overhead compared to 16-bit calculations, but it's definitely much faster than faking it.
MottZilla wrote:
And how did you come up with these numbers?
I estimated it being 1 out of 4 cycles is a work ram accessing cycle, which is about 3.3 Mhz.
I estimated the 65816 as about 1.5x as cycle efficient as the 68000.
Taking into account the costs/limits of when the system was commercially viable (like expensive FastROM) makes for a fairer comparison.
Quote:
]The SNES obviously isn't pathetically slow to some point where it can't do anything. But I do think it's quite fair to say on the SNES you don't have as much cpu time to be wasteful with.
I agree with Mottzilla here. There's a decent speed advantage over the '816 but I'd say both systems are not really challenging in terms of homebrewing a random game.
The cycle counts for the 68k are reasonable given how much work it can do with the time especially on 32bit stuff with nice addressing ability and specialized instructions. A CPU that can access memory faster isn't a huge advantage if it needs a whole lot more accesses to do an equivalent job. 65816 is cool with 16bit shifts, but try 32bits and it's 9 cycles per bit for example. It's a clear disadvantage before the clk speed differences are brought in.
tepples wrote:
What are you talking about? Bonk was also on the NES.
Huh? What does
that have to do with my Bonk port project to the MD? And NES Bonk != PC-Engine Bonk.
Quote:
You only used one single palette for the whole BG... on PCE there were more used....
Ehh? I used two subpalettes. I know, because beside doing the conversion myself, I had to use my PCE conversion util on the first level tileset to help in reducing the colors (then convert the output data to MD's tile format). I left the other two subpalettes for enemies and objects. PCE original used 3 or 4 subpalettes for the BG total, for each area. And 4-6 for sprites.
As far as the whole 68k VS '816 thing, really.. little examples mean nothing. You can provide examples on both sides to show strengths and weaknesses. Try writing code for both. Optimize it for both. 8 or 9 times out of 10 (for game consoles and 2D gaming), ignoring clock differences, the '816 will come out ahead with less overall clock cycles. I done just that. If you're not getting similar results, well.. then you're not really efficient with coding on the '816 or 65x arch in general (would be my guess). LUTs and indexing in general is a huge strength of the 65x. And you play to the strengths of the processor. The difference between normal code and optimized code on the 68k, is not nearly as drastic in difference as it is on the 65x arch (65x= anything 65xx or 65xxx). Not to mention the 68k is the perfect CPU for a computer or operating system, but game consoles are more slimmed down and specific tasks. The requirement for the type of code is fairly different, and it's that difference that brings the differences or strengths between the two archs closer together, or rather.. eliminates some of the normally big benefits of the 68k design.
Quote:
The 68000 beats the 65816 mainly at 32-bit calculations. It still has more overhead compared to 16-bit calculations, but it's definitely much faster than faking it.
Addition/subtraction, IIRC, the '816 even beat it out cycle wise (not to fuel this debate any further, we had this out in the genesis dev forums already).
Quote:
Anyway, I'd say in FastROM mode it is approximately 3.3 Mhz and it's about the same as a 5 Mhz 68000.
Any instruction that touch ram, which is almost all of them since the 65x has practically no on dye registers, is closer to 3.15mhz.
Quote:
ASL.W #4,d0 on the 68000 takes 14 cycles whereas ASL, ASL, ASL, ASL on the 65816 takes 8 cycles, despite being more instructions.
And that is the worst possible comparison. The SNES is great at shifting, if you know what you're doing. You can shift six places faster than four:
XBA; LSR; LSR; and ten places at the same speed a six. Just have to be sure B (top 8-bits of A) is clear first.
Multiplication and division is a real treat, too. ASL; ASL; PHA; ASL; CLC; ADC $01,s == A*=12.
Quote:
65816 is cool with 16bit shifts, but try 32bits and it's 9 cycles per bit for example.
Yeah, you can chain ROLs, but those require RMW operations, which suck. If you have a fixed number of bits you want to shift, it should be pretty easy to at least mitigate that damage.
I myself would have really liked MUL/DIV opcodes in place of the absolutely useless MVN/MVP opcodes (okay fine, they allowed barely faster WRAM->WRAM, but that was it.) Division by 56 for instance is a nightmare, and that SNES-specific ALU was such an ugly, slow, annoying, interrupt-unsafe kludge.
Quote:
It's 2010, FastROMs are dirt cheap nowadays.
A lot of the time you are accessing WRAM, which is SlowROM. Nowadays you could throw some in-cart RAM at $f0-ff banks, but direct page is still going to be SlowROM.
So, in summary, it has been argued the MD's graphics are 100 times more limited than SNES', MD's FM sound sounds like a joke compared to SNES's Wavetable sounds (when the chip is used correctly, that is), and now we're debating whenever the MD's CPU is much faster, a little faster or not even any faster at all ?
Anyway, even if it were this much faster, the SNES would still end up pushing the MD to shame. A faster CPU is good for computers, but for consoles, it's really the graphics and sounds that matters. Even today's action games typically doesn't handle more than a dozen of bullets and enemies on screen at a time - not much more than what was made in the 80's. (okay I'm not very knowledgeable about today's games so I might be missing something).
And I didn't even talk about the controllers... The MD was originally made to compete with the NES (which it did quite well in fact !). But then the SNES came out and booom !
Sega's policy of releasing a new consolle every couple of years is weird, and what caused them to eventually go to their doom, instead of releasing better consoles less often. Yet I know the MD is Sega's best console and all, but hey... I just don't like Sega very much for some reason. I know I'm biased
Bregalad wrote:
So, in summary, it has been argued the MD's graphics are 100 times more limited than SNES', MD's FM sound sounds like a joke compared to SNES's Wavetable sounds (when the chip is used correctly, that is), and now we're debating whenever the MD's CPU is much faster, a little faster or not even any faster at all ?
Faster CPU means software rendering without having to include a coprocessor (DSP, SFX, SVP).
Quote:
A faster CPU is good for computers, but for consoles, it's really the graphics and sounds that matters.
When the game's graphics model doesn't map easily onto that of the video chip, the CPU has to take over. The Super NES is better for some kinds of racing games because it can do mode 7, but the Genesis might win at software rendering of first-person shooters; compare Zero Tolerance (MD) to Wolf3D (SNES) or Jurassic Park (SNES).
Quote:
Even today's action games typically doesn't handle more than a dozen of bullets and enemies on screen at a time
Google
Touhou to see the exception that proves the rule. I don't think any of the three major 16-bit consoles can handle bullet curtains like this.
Quote:
And I didn't even talk about the controllers... The MD was originally made to compete with the NES (which it did quite well in fact !). But then the SNES came out and booom !
If you mean "boom" as in 6-button pads became standard, then I agree. At least I got one with my used Genesis.
I certainly think Sega would have been better off with a number of different hardware decisions. Bump the MD up to 128 Colors from the start with 64 for BG and 64 for Sprites is just one. Another would have been to have instead of releasing the Sega CD as it was, cut out some of the extra stuff (like second 68000 cpu) and instead add a VDP that would function similar to the 32X's VDP overlay, only with the purpose to add either just sprites or bg layers with their own colors to boost colors that way. Another thing about the Sega CD is again I think they should have cut alot of the extra hardware in it and gone for a more PC-Engine approach where all the unit would be is a CD-ROM drive, with an upgradable Cartridge CD-ROM System Card.
Then ofcourse I think they never should have released the 32X. And the Sega Saturn could have used a more thought out design that was less complex and easier for developers to put to use, like the PS1. Only thing I can complain about with the DreamCast is they should have known better than to let the system have such a terrible security issue. And I suppose also perhaps the 1GB Discs were not going to be enough in the long run.
Despite these things though I do enjoy all of Sega's systems.
Bregalad, I'll say again that I fail to see the "obvious" superiority of the SNES over the MD. You keep bashing the MD's sound, but I remember half of the SNES games I played sounding like shit because the sound was muffled as hell. A lot of these games sounded like they were played over a telephone or something. You might claim that "they weren't using the hardware right", but that doesn't change the fact that half of the games sucked on the sound department.
I think both consoles were perfectly able to compete with each other, and there is no "obvious superiority" on either side. And they did compete side by side for a long time I think, without one console having to mandatorily kick the other's ass.
I bet you like to bash the MD because you probably played a lot of SNES as a kid, and thought it was the most awesome thing ever back then, and only got to look at the MD recently (maybe even using emulators only), and of course under that perspective it will not look like much. I had a MD as a kid, but I played a lot of SNES at friends' houses and I always thought both consoles were very good.
tepples wrote:
compare Zero Tolerance (MD) to Wolf3D (SNES) or Jurassic Park (SNES).
I don't even think Zero Tolerance is the better looking 3D shooter on the MD. I find
Bloodshot / Battle Frenzy very interesting, and also
Duke Nukem (too bad that the overall presentation of this game sucks, because the raycasting aspect is pretty good).
It's true those games looks awesome to say they are 16-bit - but I'm not into 1st person shooters anyway.
And I'm sorry, but the sound on the MD is HORRIBLE. Those videos just reminded it to me the hard way. Any noise out of it just make my hears bleed. Perhaps it's those unfiltered very high frequencies that hurts my heardrums. Or it's just it remind me how MIDIs sounded on my very old pc - that is that they sounded like crap.
About the graphic parts, it's true I exaggerated the difference, especially after viewing those videos. Let's say the SNES is supperior, having much more colors and more BG layers - but only a little supperior.
Anyway it's games that are fun not the console - so no matter what are the system's possibilities, a good game on a lower system will always be better than a bad game on a higher system. In this sense, I fully respect that people might think their favorites MD games are the best. It's just that I'm into RPGs, and the SNES is
THE conosle of RPGs. I'm sure someone will point me to MD RPGs, pehaps some good ones, but to be honest I'll likely not be playing them more than a few minutes.
Quote:
I bet you like to bash the MD because you probably played a lot of SNES as a kid, and thought it was the most awesome thing ever back then, and only got to look at the MD recently (maybe even using emulators only), and of course under that perspective it will not look like much. I had a MD as a kid, but I played a lot of SNES at friends' houses and I always thought both consoles were very good.
If 14-yo is being a kid, then yes you bet it. (as a younger kid I was playing PC and PS1 games).
Note that I don't say the MD is that much a bad console or wathever - I just want to point out that it IS technically inferior to the SNES, and significantly so. I'll amit any day that the MD is technically supperior to the NES, despite the fact I personally like the NES and NES games much better - I won't deny it.
Maybe a better example would be GBA vs PSP. When the PSP came out is was maybe 800 times supperior to the GBA in terms of graphics and sound. Nevertheless I always prefered the GBA console and games by a LONG way, but I won't try to find stupid arguments to prove the GBA's nonexistent technical superiority. I'd rather say that despite being technically inferior I just like it better and that's it. (note that I also prefer the GBA to the DS, because I still use my DS 70% of the time to play GBA games
)