Too bad that didn't continue to build on past hardware when they built Saturn and Dreamcast.
Printable View
Too bad that didn't continue to build on past hardware when they built Saturn and Dreamcast.
Quote:
Originally Posted by Dant
Yes, there may have been some limitations tied to building on the SMS VDP in the first place, but as the tech guys have already mentioned (moreso in other threads), the main issues (subpalettes and master palette) could fiarly easily have been improved. (time possibly being the deciding factor -a delayed release could have allowed for substancial improvement in some areas -not just color -some of which should even have saved on cost -like switching to DRAM instead of PSRAM for 68k -maybe Z80 too)Quote:
Originally Posted by Christuserloeser
But the SMS's VDP is really a massive overhaul of the TMS9918, it's so much more capable and there are substancial differences overall; the color palettes are completely different even, TMS9918 uses 15 YCbCr values opposed to RGB. (the SMS VDP must have a built-in transcoder to output RGB for SG-1000 -or just approximates the colors eith 6-bit RGB values)
Donig so for the Saturn probably wouldn't have been too tough, but retaining comaptibility on the DC might have been more challenging to maintain similar cost and capabilities. Probably doable though, all the video/audio hardware, Z80, and 2x 68000s could probably have been crammed into one ASIC -assuming a Genesis+CD derived Saturn prior to DC, the SH2s would be another issue, I'm not sure if you could omit one and have the SH4 fill the gap or not; otherwise I'm sure you could put a pair of SH2s to good use -probably replacing soem other parts of the DC hardware, the Sound system for instance. (-but you've got 2x 68000s and a Z80 to make use of as well -and a bunch or RAM that needs to be mapped properly for compatibility -even if you drop MD specific compatibility) I mean Sony managed to do it for the PS2, but that wasn't entirely cost effective, though it worked OK. (had the Saturn/alternate used a single CPU, or the DC used dual CPUs things may have been a bit easier -I think 2x SH3s could allow for backwards compatibility of a dual SH2 system -requiring switchable clock speeds of course -2x SH4s would be too expensive)Quote:
Originally Posted by gamegenie
But way off topic. ;)
That's six :) 16x16,16x32,16x64,32x16,32x32,32x64.Quote:
Originally Posted by TmEE
But you know, the sprite cell size and cell build structure option (sprite size) is one of my favorite features on the Genesis VDP :D Reducing to 8 (which would probably be something like 4 sizes and 1bit for 8x8 cell or 16x16 cell option) just isn't as nice IMO. But they wouldn't need to reduce any bits to get the additional 4 more subpalette support though. I mean, the upper 64 registers/memory cells aren't there (they're mirrored) - right? The whole thing is that they tied the sprite subpalette association to the first 64 registers because the second/addition set is not on the chip anymore.
If you think about it in reasons of cost, and the excluded all SMS video modes, removed the z80 and z80 ram, hooked the YM's interrupt lines 68k (so you get proper PCM playback) - then I sure they would have enough money/resource for a DAC expansion to 4bit and 8 subpalettes. So sure, that's a possibility. But specifically the VDP? Hmm. It's possible just the additional logic needed for backwards compatibility would cost as much as 64 more 16bit memory cells (could be 9bit wide, I never checked if the LSbit holds a value or not. But regardless, that many registers isn't cheap cost or space wise, relatively speaking). Considering all the attributes of the VDP (it really is an amazing chip for its time), removing the additional memory cells and mirroring the existing palette addressing back to the sprite table at the time to save money, was probably considered a reasonable downgrade VS cost.Quote:
Just a thought, has anyone considered that perhaps the genny's video chip was so gimped in terms of colors in comparison to all the other 16-bit era consoles because they wanted to retain MS (Master System) compatibility?
Still a curious one though. PCE came out in Oct '87, as a huge success and extremely popular on its release (building up a premise here). It out sold the Famicom the first year (and continually). While the Megadrive came out about 1 year later, development was probably at the most 6 months out for the VDP at the latest - but more likely about 1 year I'm guessing (in other words the VDP was done sooner and they still needed time to ramp up supplies of the chips). If it was up to 6 months, then it's was a poor choice on their part. But if the choice was made around the time of the PCE's release or a little afterwards, then it's understandable. The comparison being, PCE has 32 subpalettes and released in '87 - while the Megadrive has 4 subpalettes and released in '88 (but had the capability of 8 subpalettes very-very easily).
And Sega did add the 12-bit RGB palette so the SMS VDP for the Game Gear too, albeit a couple years later.
Given that the Genesis VDP is built on the SMS's design, wouldn't backwards compatibility have been kind of integral? (or are the similarities more superficial -the MD VDP uses chunky instead of planar pixels, so that's a significant change at least)
Having a 12-bit color DAC wouldn't require additional external pins either. (which is a significant component of the cost of the chip in addition to silicon -granted it wouldn't matter if the package had extra unconnected pins already)
Usign DRAM for 68k memory should have made for significant cost savings too (even with more RAM -like 128-256 kB). As for PCM playback, you could the YM's interupt lines to the Z80 for the same reason (as Chilly willy suggested in the 10 changes to the Genesis thread), that and the Z80 could have been clocked faster. (TmEE mentioned the current Z80 is good for 6 MHz already -and 1/9 of 53.7 MHz give a nice 5.97 MHz)
Who said the 68k isn't using DRAM already? Well Its PSRAM, but internally it's a DRAM (memory cell is composed by a transistor and a capacitor, where it's charge is transfered to one of the longlines and then to the sense amplifier). Well it needs refresh, so it's a DRAM for certain.
Anyway kool kitty, the VDP has no unconnected pins. All of them seem to have an internal connection. Just becuase they don't appear on the genesis schematics it doesn't mean they're NC (I can guarantee you they're not). And a 12bit color DAC needs resistors and they take up a a not-so-little area inside the chip (more if you design dummy ones, which for analog is advisable).
Also tomaitheous, it seems the LSB of the colors is set sometimes, when a color is readback, but I can't understand it.
Oh don't forget the shitty serial reg on for the Z80 page...
I cant really understand if the VDP was specially done for the MD, or if it was a graphics chip designed to be used in various console(arcade) architectures. Its external capabilities make me beleive the second.
Yes, PSRAM, but pretty exotic at the time and much more expensive than comperable DRAM. (still cheaper than SRAM though) Perhaps they did it to expedite development time.Quote:
Originally Posted by Jorge Nuno
OK, I wasn't sure. There are at least a fair amount of unused pins though (unused busses, like the pixel/color bus and possibly one intended for a 2nd 64 kB VRAM bank). I beleive both features ended up getting used in the arcade and later implementations did remove the color bus. Ideally, both added busses should have been used, allowing VRAM to be configured as 2x 32kB banks perhaps, and possibly adding the colro bus to the expansion port and/or cartridge port. (which would have major connotations for expansion -albeit other changes to the expansion port would be necessary to really help the CD -or have it connected to the cartridge port instead)Quote:
Anyway kool kitty, the VDP has no unconnected pins. All of them seem to have an internal connection. Just becuase they don't appear on the genesis schematics it doesn't mean they're NC (I can guarantee you they're not). And a 12bit color DAC needs resistors and they take up a a not-so-little area inside the chip (more if you design dummy ones, which for analog is advisable).
Other than switching to a parallel banking mechanism, Chilly Willy also mentioned slpitting the 32 kB space into 4x 8kB banks instead. (if serial bank selection was still used)Quote:
Oh don't forget the shitty serial reg on for the Z80 page...
The SMS VDP did such as well, I beleive there was an arcade board usign an SMS VDP with dual VRAM banks and I seem to recall one using dual SMS VDPs as well. (maybe both)Quote:
I cant really understand if the VDP was specially done for the MD, or if it was a graphics chip designed to be used in various console(arcade) architectures. Its external capabilities make me beleive the second.
Yeah, some years later. Not to mention the SMS VDP is much simpler in design and number of gates (and how fast they need to operate internally). Simply adding a 12bit DAC mode to the existing SMS VDP design doesn't seem like a big deal at the time of the GG. Not compared to the juggernaut that is the Genesis VDP.Quote:
Originally Posted by kool kitty89
Other than both are tile/sprite based systems, the SMS and MD - they're really nothing alike. The sprite table, how it fetches vram/pixels, the pixel mode being completely different, has a line buffer system for sprites, etc. It couldn't be more different from the SMS in low level design. That definitely leads me to believe there is additional space on the IC wafer just for handling SMS specific modes (specific SMS mode logic operation/behavior, and such that can't be handled with the existing MD mode's logic layout).Quote:
Given that the Genesis VDP is built on the SMS's design, wouldn't backwards compatibility have been kind of integral? (or are the similarities more superficial -the MD VDP uses chunky instead of planar pixels, so that's a significant change at least)
Having a 12-bit color DAC wouldn't require additional external pins either. (which is a significant component of the cost of the chip in addition to silicon -granted it wouldn't matter if the package had extra unconnected pins already)
As far as a 3x4bit DAC vs a 3x3bit DAC, it's more complicated than that. Sure, the cost of wider range DAC is more expensive (though relatively speaking, probably not much more. But still, don't forget these are high speed DACs, not very low speed ones like 40-60khz audio DACs). But there's the additional cost of now having 3 more bits per palette storage register and assuming still *only* four subpalettes - that's 3x64 more lines to lay down as well and interface to. The additional logic and such.
The z80 is basically a waste of money though. The 68k could easily handle PCM playback on that single channel with an interrupt+programmable timer input which is exactly what the 2612 already has. Why involve the z80 at all? I guess the only bad thing would be breaking up VDMA into smaller calls as not to delay any interrupts, but this is what I would do anyway if the z80 is reading from 68k mapped rom space to the DAC. So the point is still moot. There are cheaper solutions to getting single channel streaming PCM than using a z80+ram and interfacing logic, traces on the PCB, etc. IMO - the z80 wasn't included on the MD mainly for audio handling. It was included for the sole purpose of SMS backwards compatibility. There's nothing intensive about updating a few 2612 or whatever audio chip regs every so many frames. Nothing at all. Because Sega never hooked up the timer flag lines to the 68k interrupt input, is the only reason why the z80 is seen as a valid choice for PCM playback. Because it's the only option. And a rather more expensive and poorer option at that. A work around by programmers.Quote:
Usign DRAM for 68k memory should have made for significant cost savings too (even with more RAM -like 128-256 kB). As for PCM playback, you could the YM's interupt lines to the Z80 for the same reason (as Chilly willy suggested in the 10 changes to the Genesis thread), that and the Z80 could have been clocked faster. (TmEE mentioned the current Z80 is good for 6 MHz already -and 1/9 of 53.7 MHz give a nice 5.97 MHz)
Probably just open bus (and other logic using redundant lines). I've seen this on other systems ( and PCE does the exact same thing in regards to palette memory, but the 16bit write - it's the upper 7bits that are open bus internally on the chip. Sometimes you get patterned values and sometimes it's random. But never storable space internally). On the cpu side the read/write appears to be a full 4/8/16bit/whatever, but in fact internally there's no reason to waste such bits and is translated to whatever memory structure they laid out in the design. Sounds like this is the case with the MD VDP and palette registers to me.Quote:
Also tomaitheous, it seems the LSB of the colors is set sometimes, when a color is readback, but I can't understand it.
As for the MD VDP being designed for arcades primarily, I'd have to say probably not. Just because of the SMS backwards compatibility, but I would agree that they most likely had arcade usage in mind at some point for this chip - when looking at the digital pixel bus and that some Sega arcade systems not based on MD hardware also use this type of because for layer priority mixing. Again, the PCE is the same way. Its VDC was also used in a few arcade systems - even though it first appeared as a home console video device. It's designed to run a number of types of resolutions nonstand to NTSC (up to 512 scanlines (1-512 programmable, regs for vblank scanlines, etc) and as little as 8pixels to 1024pixels output on a scanline. It can run by itself *or* run with other ICs driving the H and/or Vsync output lines as input lines. You can still define a frame layout within an external defined/controlled frame. I did this to get horizont rolling image, but digitally by setting the VDC to run just the Hsync output instead of input :D ). I always wanted to hook up the VDP of the MD to the VCE (this chip holds the palette ram, has the pixel bus input lines, and provides a programmable dot clock for the supplying device, as well as all h/v frame timings and outputs) of the PCE, via the digital bus. Haven't figured out how to sync the two yet >_>
Huh, I wonder why they pushed for it then, the SG-1000 and SMS hadn't been very popular in Japan or North america, and SoJ didn;t seem especially eager to cater specifically to Europe (though they did continue to release SMS games there alone -most released on GG, of course).Quote:
Originally Posted by tomaitheous
Was the SMS's VDP very similar to teh TMS9918 derivative of the SG-1000, or was that tacked on as well? (I know the palettes are entirely different so either they'd need to remap the colros to 6-bit RGB, or include the YCbCr palette as well)
Yeah, I kind of mentioned that here: http://sega-16.com/forum/showthread.php?p=214823 rambling a bit though. Especially I was thinkig in terms of the added CRAM necessary for larger palettes (increased subpalettes and/or master palettes -let alone a 256 indexed half res mode) Again, the PCE and SNES used FAR more entries than the MD. (PCE must use more CRAM than SNES to have those 512 9-bit entries -compared to the SNES's 512 bytes)Quote:
As far as a 3x4bit DAC vs a 3x3bit DAC, it's more complicated than that. Sure, the cost of wider range DAC is more expensive (though relatively speaking, probably not much more. But still, don't forget these are high speed DACs, not very low speed ones like 40-60khz audio DACs). But there's the additional cost of now having 3 more bits per palette storage register and assuming still *only* four subpalettes - that's 3x64 more lines to lay down as well and interface to. The additional logic and such.
What if you wanted multiple PCM streams goign simultaneously (mixed onto the YM's DAC)? (chilly willy was suggesting 4 PCM streams, not to mention any decompression)Quote:
The z80 is basically a waste of money though. The 68k could easily handle PCM playback on that single channel with an interrupt+programmable timer input which is exactly what the 2612 already has. Why involve the z80 at all? I guess the only bad thing would be breaking up VDMA into smaller calls as not to delay any interrupts, but this is what I would do anyway if the z80 is reading from 68k mapped rom space to the DAC. So the point is still moot. There are cheaper solutions to getting single channel streaming PCM than using a z80+ram and interfacing logic, traces on the PCB, etc. IMO - the z80 wasn't included on the MD mainly for audio handling. It was included for the sole purpose of SMS backwards compatibility. There's nothing intensive about updating a few 2612 or whatever audio chip regs every so many frames. Nothing at all. Because Sega never hooked up the timer flag lines to the 68k interrupt input, is the only reason why the z80 is seen as a valid choice for PCM playback. Because it's the only option. And a rather more expensive and poorer option at that. A work around by programmers.
Though in that case, going for a faster 68k could be the solution as well, like a 10 Mhz one. (especially with the cost savings of the Z80+RAM and coresponding board space -and again DRAM would have helped a lot)
No, but it was an existing user base. At the time, they needed everything they could get. Remember, Sega wasn't that popular at the time (in comparison to Famicom, MSX, PCE, and the many PC systems). I'm sure they figured they needed all the help they could get (BC is one way if your user base is small and you need to compete. I think BC doesn't make that much of a difference for the more successful systems/companies).Quote:
Huh, I wonder why they pushed for it then, the SG-1000 and SMS hadn't been very popular in Japan or North america, and SoJ didn;t seem especially eager to cater specifically to Europe (though they did continue to release SMS games there alone -most released on GG, of course).
You could. But all that work and just for an 8bit DAC - no volume? Remember, the more channels you have - the lower the bitrate is for those channels. And be it digital hardware or software volume, anything that's not max volume is also lower bitrate. 4 channels on an 8bit DAC at max volume is 6bits per channel. If you were to use non linear shift volume (closer to decibels steps/range than anything linear would be), one shift per volume step on that channel is 1bit taken away from that channels resolution. The aliasing noise is somewhat detracted by the lower amplitude, but it's still there. If they were going to go through all that work/design - might as well do a separate DAC with higher bitrate (10bit DAC) and put into a custom IC with a small FIFO per channel (and maybe a realtime hardware shift volume mechanism per channel). Tie the custom IC to the scanline frequency (15.7khz) or double it or and option for both speeds. And totally ignore the 8bit direct write channel of the 2612 (keep it in FM mode).Quote:
What if you wanted multiple PCM streams goign simultaneously (mixed onto the YM's DAC)? (chilly willy was suggesting 4 PCM streams, not to mention any decompression)
Though in that case, going for a faster 68k could be the solution as well, like a 10 Mhz one. (especially with the cost savings of the Z80+RAM and coresponding board space -and again DRAM would have helped a lot)
And as for the 10mhz mode, I'm not sure what the price difference was back then between them - but that speed increase also means faster ram and more importantly rom speeds. Unless you had some sort of wait state system for the rom, but then you start adding up the complexity and cost again. 7.67mhz is fine and has proven to be just fine over the course of the Genesis' life span.
Remember that even as late as 1994-95, adding multiple channels of 8 bit audio together for output at 8 bits was still the dominant form of audio. So a MD with four channels added together via the Z80 to output on the YM2612 DAC would have been adequate until the MD's replacement came. Unless you knew your game output four VERY loud sounds at all times, a programmer would almost certainly add the channels together (with saturation) at either 7 bits per channel, or perhaps the full 8 bits per channel if they knew the game normally had quiet sounds, or few infrequent louder sounds. For volume, a simple right shift on the final sample would do for a non-linear 3 or 7 settings volume control. Most people tend to set the volume on their games to maximum and use the TV volume control in any case, so it's usually a moot point. You could easily not do any volume and tell the player to control the volume via the TV/audio deck volume control.Quote:
Originally Posted by tomaitheous
Yes, a separate audio DAC for each channel would be better, but I think people were thinking of the simplest, cheapest changes that could be made that would improve things without the added expense and complexity of something like a four channel DAC. Boosting the Z80 speed to 6 MHz would have been super-easy and cheap, while improving things. Making four banks to the 68000 space instead of one would have also been super-easy and cheap. Both of those changes would have allowed for reasonable multi-channel PCM for almost the exact same expense and complexity as what the MD has right now.
OK, it was chilly willy who was really pushing the faster CPU starting here: http://sega-16.com/forum/showthread....&postcount=191Quote:
Originally Posted by tomaitheous
Initially mentioning 12 MHz, I suggested 10 might be more reasonable, and the ROM speeds didn't even come up, so that would definitely be a significant consideration.
This whole side discussion really would fit better in the above thread, but what I will say is that the PSRAM thig is still significant and using DRAM would have allowed for more ram (128 kB at the very least, perhaps 256 kB) while still reducing cost compared to PSRAM.
The other big thing would have been a more comprehensive expansion port, have larger address space, YS, and the color bus connected at least. (they could probably have had the connector sort of a clones cartridge slot with a toggling system set to give the cart slot priority with a cartridge inserted, then the added VDP color bus of course -YS already being on the cart slot -probably analog audio and RGB signals as well to allow for passthrough)
Otherwise they could have added to the cart slot alone and doen away with the expansion port. (use the cart slot alone for expansion, have the added connections outboard liek on the SNES or A7800 so normal games wouldn't require larger PCBs -could be smaller in fact, if some of the existing pins were moved to the outboard portions as well)
And regardless of there being a Z80 or just the 68k the int line should have been connected to the YM2612. (perhaps have it connected for both even, if that would work -allowing either to be used more effectively)
True, but I'm sure the cost of the z80 and the z80's ram would be at least twice that of a single monotone low speed 10bit DAC on a custom IC (or just a custom IC attached to it)... I'm guessing. If not more.Quote:
Originally Posted by Chilly Willy
Famicom came out in 1983 and had a separate 7bit DAC ( separate from its other four 4bit DACs). PC-Engine had six 5bit DACs and along with six 5bit DACs uses as volume reference. I'm sure a single 10bit DAC wasn't that expensive back then - though maybe a bit irregular for home console, but then again what wasn't irregular in certain aspects of each system.
Not to mention the audio in lines on the cart for whatever future audio upgrade device on cart. More surprising than anything, is that they never took advantage of that. Famicom sure did.Quote:
Yes, a separate audio DAC for each channel would be better, but I think people were thinking of the simplest, cheapest changes that could be made that would improve things without the added expense and complexity of something like a four channel DAC.
All said and done though, I still see the z80 as unnecessary component for audio. Disregarding BC, leaving it on the system is a more expensive option than other much better and cheaper audio routes.
Definitely. Even if it was a PCB design error (can't really think of any other reason why they wouldn't), that should have been fixed via a wire patch or such. And fixed correctly in any newer board revisions.Quote:
And regardless of there being a Z80 or just the 68k the int line should have been connected to the YM2612. (perhaps have it connected for both even, if that would work -allowing either to be used more effectively)
That removes SMS compatibility of course. (and the merit of BC is another discussion entirely -with only a few notable examples in the video game industry -A7800, Nintendo portables, Sega, and Sony)Quote:
Originally Posted by tomaitheous
If you really wanted to drop cost, you could just remove the Z80 entirely and still use the YM2612 DAC. (or use a pair of YM2612s -and omitting the PSG if you don't need SMS compatibility) You could go with something like the YM2608 with various added features including a single ADPCM channel up to 16 kHz sampling, but that requires an additional companion DAC chip for output. (2612 has a built-in DAC to avoid this -so dual 2612s might be more worthwhile)
And the Z80 uses PSRAM too I think (according to TmEE) so that would be more expensive than necessary as well. The Z80 has built-in DRAM refresh hardware, so this really puzzels me unless 8 kB wasn't one of the sizes the Z80 supported. (I seem to recal there were only specific IC sizes the Z80 refreshs would support, though I also recall 8 kB being among them)
There was the 32x which mixed throught he cartridge port. (A/V port was passthrough only for audio -and the headphone jack would be the only way to get Stero from a model 1 genesis still, even for PWM)Quote:
Not to mention the audio in lines on the cart for whatever future audio upgrade device on cart. More surprising than anything, is that they never took advantage of that. Famicom sure did.
Yeah, that really seems odd, but as to my latter comment, could they have connected both the Z80 and 68k without having any confilts. (though, with the Z80 onboard, it would make most sense to dedicate it to audio and leave the 68k free from that duty anyway)Quote:
Definitely. Even if it was a PCB design error (can't really think of any other reason why they wouldn't), that should have been fixed via a wire patch or such. And fixed correctly in any newer board revisions.
What do you think about the choice of PSRAM? It doesn't seem a very practical choice given that DRAM of sufficient speed should have been readily available. Minimal performance loss to refresh while remaining much cheaper than SRAM would still not seem to outweigh the advantages of plain DRAM. The most reasonable conclusion would seem to be time constraints. (probably similar for a few others simple changes which weren't made -but could have had substancial impacts)