Super VDP for SegaCD

[tomaitheous]

I thought I read somewhere that the SegaCD was going to receive a video upgrade but was canceled. Considering the ASIC is sort of a mismatch for the Genesis original VDP, it would make sense that the extra 68k@12.5mhz and the ASIC be paired with the Super VDP of a version of it (which isn't really super - just a simple BITMAP display controller - probably low cost to boot).

What do you guys think?

[evildragon]

The ASIC in the Sega CD was designed to output tiles to the Genesis VDP.

What you are thinking about is exactly what the 32X does, adds the Super VDP, even to the Sega CD for access.

Don't forget, most of the people here don't even know what a Super VDP is. ;)

[Joe Redifer]

The video would still have to be handled externally like it is with the 32X... wires going everywhere.

[tomaitheous]

Yeah, I know the ASIC output is 4bit pixel packed tiles, but who's to say it wasn't originally for variable sized bitmap images? I mean changing internal rom of the ASIC chip couldn't have been that difficult.

And it seems silly that they added an additional 68k without the increased video hardware (and the fact that the sub-cpu can't access the VDP) to go along with it. It's a bit overkill just to handle additional functions like collision detection and other game physics. In all honestly they could of cut cost and included a cheaper/lower cost MCU. To me, a 68k@12.5mhz + ASIC + Super VDP(or something similar) makes perfect sense. Take out the additional VDP and well.. it's kind of a waste of cost/effort IMO.

Just my two cents..

[evildragon]

If the Sega CD had video mixing hardware, then the 32X wouldn't have worked out too well. TWO video overlay systems? That sounds like trouble.

Besides, I don't think the side card connector on the Genesis even has HSync and VSync, let alone YS for the Genlock system.

[tomaitheous]

If the Sega CD had video mixing hardware, then the 32X wouldn't have worked out too well. TWO video overlay systems? That sounds like trouble.

Besides, I don't think the side card connector on the Genesis even has HSync and VSync, let alone YS for the Genlock system.

Are you sure? YS should be on the expansion connector. I'll have to dig around my docs and see if I have the expansion layout.

[evildragon]

Are you sure? YS should be on the expansion connector. I'll have to dig around my docs and see if I have the expansion layout.
I don't think it is, im 70% certain on this.

[Aarzak]

I used to believe that the combined hardware of the Genesis+Sega CD was capable of handling at least really close conversions of Sega's coin-op sprite monsters (Outrun, After Burner, Super Hang-On, Space Harrier........NOT "Galaxy Force II", good god) with all of that combined hardware under the belt, and I bet many people back in 1990/1991 (when the Mega CD was announced and released) believed that as well.............but we were all dead wrong.

The MCD, 32X and Saturn all suffered from bottlenecks or lack of features that impaired their performance or graphic output, didn't they? Seems like the SMS/GG, Genny and Dreamcast were the only solidly developed Sega consoles, especially for their time.

[tomaitheous]

Anyone have scans of early specs? Maybe from some Japanese mags?

[j_factor]

Saturn's performance impairment came from really poor SDK's and an overall lack of dev support from Sega. That kind of ties in to how it was more successful in Japan -- shitty devkits aren't a big deal for RPGs and dating sims. But developers making more intensive games really had to go out of their way if they wanted to support the Saturn. I believe it was Core Design who created their own Saturn middleware from scratch by programming it in assembly, and Psygnosis made unauthorized modifications to their dev systems. Most developers would never go to such a bother (Core and Psygnosis were a bunch of crazy Amiga programming veterans who probably relished the challenge). But why am I talking about the Saturn?


If the Sega CD had video mixing hardware, then the 32X wouldn't have worked out too well.

All the more reason it should've had it. Maybe then they wouldn't have gone ahead with the ill-advised 32x.

[Aarzak]

Let's not dwell anymore on Sega's lapse of judgement between 1992-1997.

[j_factor]

You mean 1992 to present.

And 1983 to 1990.

Really, Sega sucks.

[Aarzak]

Hey, they were trying their damnest with the Master System but Nintendo shut them out! And they were ripping arse (heh) in the arcades throughout the mid-to-late '80's.

[Psy]

Saturn's performance impairment came from really poor SDK's and an overall lack of dev support from Sega. That kind of ties in to how it was more successful in Japan -- shitty devkits aren't a big deal for RPGs and dating sims. But developers making more intensive games really had to go out of their way if they wanted to support the Saturn. I believe it was Core Design who created their own Saturn middleware from scratch by programming it in assembly, and Psygnosis made unauthorized modifications to their dev systems. Most developers would never go to such a bother (Core and Psygnosis were a bunch of crazy Amiga programming veterans who probably relished the challenge). But why am I talking about the Saturn?

True, and later on Japanese developers did figure out how to work with the Saturn.



All the more reason it should've had it. Maybe then they wouldn't have gone ahead with the ill-advised 32x.
That would have made the SegaCD even more expensive, if Sega had put sprite rotation and scaling into the VDP of the Genesis the SegaCD could have been cheaper, really the lack colors on the Genesis was a minor issue as most people used RF hookups that caused color bleeding anyway (turn the sharpness of the TV all the way down when playing Genesis games to emulate how the Genesis looked back in the day and remember even if you had composite back then TVs have far better comb filters now).

[tomaitheous]

That would have made the SegaCD even more expensive, if Sega had put sprite rotation and scaling into the VDP of the Genesis the SegaCD could have been cheaper, really the lack colors on the Genesis was a minor issue as most people used RF hookups that caused color bleeding anyway (turn the sharpness of the TV all the way down when playing Genesis games to emulate how the Genesis looked back in the day and remember even if you had composite back then TVs have far better comb filters now).

I don't think it would have been much more. They could have easily eaten the small cost. The Super VDP is a very simple/low cost bitmap display controller. I bet the add confusion of the video cable scheme probably deterred more than anything (assuming the rumors of the additional VDP in the original design were true).

Worst cast scenario, they could have used an upgraded TI VDP(with a faster DMA for screen updates, i.e. scaling/rotation) for the base unit that only the sub-cpu could access, and have software turn off the Genesis VDP - no signal mixing. They'd just have to supply a mixer cable like they did for the stereo audio part, so you could still see video for Genesis carts.

Anyway, I'm not trying to discuss Sega's poor decision on the matter. I just like to discuss some of the evidence that the additional VDP was indeed part of the original design by looking at the final release design.

[j_factor]

Hey, they were trying their damnest with the Master System but Nintendo shut them out!

That might be true for Japan, but in North America, Sega made a bad move by handing over the SMS to Tonka.


And they were ripping arse (heh) in the arcades throughout the mid-to-late '80's.

Sega's arcade division has pretty much consistently kicked ass since around 1982.


True, and later on Japanese developers did figure out how to work with the Saturn.

Very true. Japanese third parties ended up making some of the most impressive Saturn games. I still think Saturn would've had a lot more respect in America and a longer lifespan if games like Grandia and DOA had come out here. "AAA" or not. Once again, I would like to throw out a hearty "fuck you" to Bernie Stolar.


That would have made the SegaCD even more expensive,

It's really not that much of a cost, I don't think. And they could've cut costs elsewhere. Like by taking out CD+G support. Who the hell gave a damn about CD+G?


really the lack colors on the Genesis was a minor issue as most people used RF hookups that caused color bleeding anyway (turn the sharpness of the TV all the way down when playing Genesis games to emulate how the Genesis looked back in the day and remember even if you had composite back then TVs have far better comb filters now).

Yes, this is a good point. I don't think people talked about color count differences nearly so much back in the day. It's probably different in Europe, where they had SCART and better TVs, but they loved their Mega Drives anyway.

[tomaitheous]

It's really not that much of a cost, I don't think. And they could've cut costs elsewhere. Like by taking out CD+G support. Who the hell gave a damn about CD+G?

CD+G was handled in software. It's pretty simply, you just read *all* the subchannel data (instead of just the time stamp which audio CD players do) and reconstruct the graphics or scroll or palette change, depending on the script changes. The weird thing is that CD+G uses a 16 colors out of 4096 color palette - both the PCE CD and SegaCD have to show a reduced palette.

Since none of the emulators handle sub-channel data, you could make a security feature out of it.

[tomaitheous]

I just recently(today) noticed a Full Graphics mode for the ASIC chip. It's a single byte (256 color palette) bitmap output mode. Not very useful for the Genesis VDP, but perfect for the Super VDP or other display processors that use 8bit bitmap display mode. Just another piece of evidence that the SegaCD really was going to have a bitmap display processor on the addon unit side - IMO.

[TmEE]

I wonder how things would have looked if CD would have had a SuperVDP in it and you had 32X too... video from MD, video from CD, going to 32X... oh, then there probably haven't been any 32X around... you had colors and stuff... without the 32X SEGa would have had more money and then Saturn maybe would have got some more attention... who knows....

[evildragon]

Since none of the emulators handle sub-channel data, you could make a security feature out of it.

Not true, on KEGA Fusion, you can use CD+G's on it, and it does play fine, depending on if the drive on your computer can read CD+G's.

[tomaitheous]

It can? Now that's interesting because reading sub-channel data from a real PC CD-rom is fairly cumbersome and slow. I wonder if it's only enbled when in CD player mode(the emu detecting this). Well that's assuming you had a CD(or CD-R with burned with the additional sub-channel data). ISO's and CUE sheets dumps don't include the sub-channel data - other formats do though. All CD drives now a days should be able to read all of the sub-channels (even as up to 10 years back).

Hmm... that has me curious on how the subchannel data is retrieved by the SegaCD since it's a DMA style system. On the PCE-CD the CD unit generates an interrupt 96 times per sector in which the CPU reads the status byte from a port(the sub channel data).

[evildragon]

No, it's a part of Fusion and how it just uses your CD-ROM drive. It literally emulates the whole CD controller, and translates the calls to the ATAPI interface. (SCSI drives don't seem to work though)

[tomaitheous]

No, it's a part of Fusion and how it just uses your CD-ROM drive. It literally emulates the whole CD controller, and translates the calls to the ATAPI interface. (SCSI drives don't seem to work though)

Simulate, yeah - but literally emulate? I have a trouble believing they emulated the MCU controlling the actual CD unit. You'd have to dump the internal rom of the MCU (if you can do that via stack over method or such - sometimes requiring decaping the MCU and taking a pic with a microscope to get the rom image like the MAME team has down before). I'm not talking about the BIOS that interfaces API calls to the MCU via whatever memory mapped I/O, I mean the MCU itself.

So.. has anyone accessed sub-channel (all the channels) data in game as a test? That would make for some interesting projects/demos ;)

[evildragon]

I used a real CD+G disc I had lying around, has Elvis music, but prints the lyrics on screen via CG+G. Works in Fusion, but not Gems.

[Black_Tiger]

I used to believe that the combined hardware of the Genesis+Sega CD was capable of handling at least really close conversions of Sega's coin-op sprite monsters (Outrun, After Burner, Super Hang-On, Space Harrier........NOT "Galaxy Force II", good god) with all of that combined hardware under the belt, and I bet many people back in 1990/1991 (when the Mega CD was announced and released) believed that as well.............but we were all dead wrong.

The MCD, 32X and Saturn all suffered from bottlenecks or lack of features that impaired their performance or graphic output, didn't they? Seems like the SMS/GG, Genny and Dreamcast were the only solidly developed Sega consoles, especially for their time.

It could be argued that the Genesis' color limits and single sound channel for samples became nasty bottle necks as 16-bit home games became more advanced.

But then the PC Engine and SNES also have their own weaknesses that hold them back from being able to do everything teh best, so its all perspective.

[j_factor]

Every system has its limitations. I don't think there's any system in the history of gaming that is a total "slam dunk" of design with no significant drawback for its era. SMS definitely could've had better sound capabilities, and Dreamcast could've used a higher-capacity medium (if it hadn't died so early, the limitations of the GD-ROM format would've shown more as time went on).

[Joe Redifer]

Every system has its limitations.
Not the PS3. It has the Cell, you know. Actual cells and bacteria 'n shit run the thing!

[evildragon]

The 32X was never maxed out. It was capable of more. For example, Doom was a shit port, if done correctly, it could have looked a LOT better.

All the coders had to do was take their time and optimize the code.

[Joe Redifer]

Awww, man. I wish you hadn't deleted your post, Aarzak, there are many points I'd like to reply to.

[segagamer]

Every system has its limitations. I don't think there's any system in the history of gaming that is a total "slam dunk" of design with no significant drawback for its era. SMS definitely could've had better sound capabilities, and Dreamcast could've used a higher-capacity medium (if it hadn't died so early, the limitations of the GD-ROM format would've shown more as time went on).

SMS did have better sound capabilities, in the form of FM sound found on the Japanese SMS consoles.

[tomaitheous]

SMS did have better sound capabilities, in the form of FM sound found on the Japanese SMS consoles.

Wasn't that through an add-on, though?

[Joe Redifer]

It was built in to the Japanese SMS and an add-on for the Mark 3. I thought it sounded much worse than bare-bones SMS PSG sound, though.

[TmEE]

You have never heard of R-Type with FM sound... it just kicks ass !!! now I need that FM chip, and I must shove it into either my MD or SMS...

[tomaitheous]

You have never heard of R-Type with FM sound... it just kicks ass !!! now I need that FM chip, and I must shove it into either my MD or SMS...

I've not. Got a clip/link to it?

[Joe Redifer]

You have never heard of R-Type with FM sound.
Yes I have. Sounds like an extremely broken Genesis game. Every game that uses the FM chip uses the same exact drums (which are too loud) and only 2 or 3 channels of musical instruments even though the FM chip has 9 channels or something like that. The PSG version sounds better.

[Aarzak]

*sigh*, do I have to do EVERYTHING for you guys? *throws arms up in air* YouTube people!

Excerpts from the FM-powered soundtrack to the SMS port of Arrrrr-Type (still one of the most impressive 8-Bit arcade ports I've seen, dare I say gives the popular PCE port a run for it's money?):

http://www.youtube.com/watch?v=zWc9DxgbnT4

I've heard something about the Japanese SMS/Mark III's FM chip being a rather decent (at the time) Yamaha soundchip (2413?) that was stripped-down to hell, with most of it's features/channels disabled or something..............'kay, I read it from Wikipedia:

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

Still, pretty impressive for an 8-Bit system. If only it were built-in to the Mark III hardware from the beginning. Only "Lagrange Point " for the Famicom comes close to reaching the sound of the Mark III FM chip.

And pardon me for deleting that post Joe, I just felt it was redundant and that my facts were mixed up. Something about the SCD & 32X being hyped up as being more capable than they really were (Steve SNAAAAAAKE! confirmed that for the 32X) and being severely limited by the Mega Drive hardware which acted as their "spines" and the Saturn having the goods deep down inside it's hardware but being hard to access due to the complicated architecture.

[Joe Redifer]

I will certainly admit that R-Type has the best FM sound for the SMS, but that's because it didn't use the crappy FM drums that most/all other FM games did. I still prefer the sound of an NES.

[Dartagnan1083]

hmmmmmm

if only Sega had used the SID chip

[TmEE]

R-Type has really awesome FM tunes and PSG ones are poor in my mind... PSG chip in SMS is quite poor... I like NES/FC one lot more... but MD is the best in all cases.

[evildragon]

hmmmmmm

if only Sega had used the SID chip
Please don't get Joe started about his false idea on the SID chip.

[tomaitheous]

You mean the SID chip and its "arpeggios"? *blah*

It might have been cool for 1982-83, but....

Those SMS R-Type FM tunes sound great!


R-Type has really awesome FM tunes and PSG ones are poor in my mind... PSG chip in SMS is quite poor... I like NES/FC one lot more... but MD is the best in all cases.

Same here, I like the NES audio system. I had a chance to emulate it. Pretty cool setup. Of course the SMS could do the same effects as NES(sweep, envelope, note length), but with the over head in software/cpu resource.

[Joe Redifer]

Yeah, the SID sounds like ass, like someone's shaking it violently. That's not "false".

[evildragon]

But it's the PROGRAMMER that does the arpeggios.

So don't blame the SID, blame those who programmed it to do that. I use the SID in my music recordings, and never do that.

[j_factor]

Maybe they could've used the POKEY chip.

[playgen]

The FM in the Japanese sms is brilliant, Space Harrier's music is arcade perfect!

I've heard lots of people say that the Nes has better sound than the non-FM Master System, I'm not convinced though. The best Nes music I've heard isn't any better than the best SMS music, whereas both have a lot of games with terrible music. I'd say their evenly matched in the audio department - even if thats because developers mostly wrote bad music that showed up the limitations of the hardware.

[Joe Redifer]

The FM in the Japanese sms is brilliant, Space Harrier's music is arcade perfect!
LOL! Not even close!

[Black_Tiger]

The FM in the Japanese sms is brilliant, Space Harrier's music is arcade perfect!

The Mark III's Space Harrier port doesn't support FM sound, but the Mark III SMS's built in Space Harrier track kicks ass.



LOL! Not even close!

There's no such thing as arcade perfect, but the Mark III FM Space Harrier theme holds up very well to the arcade original.

Sega Mark III FM (http://www.superpcenginegrafx.com/sh_theme_markiiifm.mp3)

Sega Master System PSG (http://www.superpcenginegrafx.com/sh_theme_smspsg.mp3)

Joe, can you seriously say that the FM tune above sounds way worse than the PSG version?


I've always prefered good SMS PSG music over good NES PSG music.

[tomaitheous]

Well one can state their opinion on SMS vs NES sound systems based on games, but no way is the SMS sound system better than the NES system. SMS sound system is really stripped down basic PSG - nothing more. Plus the NES has one more sound channel.

I think it's more of what system you grow up with. To me, there are more better sounding NES games than SMS games.

B_T: Thanks for the links. I really like that SMS FM track from Space Harrier.

[Joe Redifer]

I don't really like the loud drums in the FM version. They stand out above all other instruments (not the bass drum, the other drum, tom or snare or whatever it is supposed to be). Also, was there simultaneous PSG in that? That's what I would have done (if possible) if I were a programmer in order to use as many sound channels as possible. How are the voices on the FM version? The NES had better voices than the SMS.

I find that all SMS FM soundtracks are exactly the same as the PSG, just with re-assigned instruments. That's all.

[tomaitheous]

I don't really like the loud drums in the FM version. They stand out above all other instruments (not the bass drum, the other drum, tom or snare or whatever it is supposed to be). Also, was there simultaneous PSG in that? That's what I would have done (if possible) if I were a programmer in order to use as many sound channels as possible. How are the voices on the FM version? The NES had better voices than the SMS.

I find that all SMS FM soundtracks are exactly the same as the PSG, just with re-assigned instruments. That's all.

I figure they would have reserved the PSG channels for multiple channel sound effects.

[Black_Tiger]

I don't really like the loud drums in the FM version. They stand out above all other instruments (not the bass drum, the other drum, tom or snare or whatever it is supposed to be).

Exactly, just like the arcade. ;)


Also, was there simultaneous PSG in that? That's what I would have done (if possible) if I were a programmer in order to use as many sound channels as possible. How are the voices on the FM version? The NES had better voices than the SMS.

I find that all SMS FM soundtracks are exactly the same as the PSG, just with re-assigned instruments. That's all.

Most of the FM soundtracks I've heard mix PSG with FM.

Space Harrier doesn't support FM sound.

[Joe Redifer]

You are being very confusing. What was that you just posted? Space Harrier 3D? It sounds much shittier than the arcade.

[Black_Tiger]

You are being very confusing. What was that you just posted? Space Harrier 3D? It sounds much shittier than the arcade.

Its the music that plays when when you turn on the Mark III SMS console without a cart inserted. Space Harrier the game for North American SMS and JP Mark III doesn't do FM sound.

I had forgotten about Space Harrier 3D, I just checked it out on emulator and it does support FM sound, but sounds like it has a different simpler theme song.

[j_factor]

People say that the NES has better sound hardware, but I have yet to be able to tell. Both sound very, very 8-bit to me.

[Joe Redifer]

Just as the Genesis and the SNES both sound very, very 16-bit.

[evildragon]

Just for you guys, I have a "seperated" version of the Space Harrier theme for the BIOS.

Left channel is FM, right channel is PSG. There is some bleeding of the PSG in the left channel, but very little.

http://blackevilweredragon.spymac.com/msb.mp3

[Black_Tiger]

Just as the Genesis and the SNES both sound very, very 16-bit.

I think that the SNES sounds very SNES, not so much "16-bit".

[evildragon]

Actually, the CPU that drives the SNES's APU is 8-bit. Just as the Genesis music is usually driven by an 8-bit CPU.

I LOVE the SPC700!!

[Joe Redifer]

Even the SMS' sound is driven by an 8-bit CPU so therefore that MUST mean the SMS' sound is every bit as good as the SNES'. You just can't compete with solid logic like that.

Thanks for the separation of the tune, evildragon. The PSG part sounds almost exactly like Space Harrier 3D. That's definitely the most "instruments at once" I've ever heard any FM-enabled SMS do. I'm sure most games limit the numner of channels since they're busy running graphics, game logic and other complete nonsense.

[j_factor]

Just as the Genesis and the SNES both sound very, very 16-bit.

Poor wording; I just meant that NES and SMS audio sounds very similar to me. Genesis and SNES are somewhat different from each other.

[evildragon]

Even the SMS' sound is driven by an 8-bit CPU so therefore that MUST mean the SMS' sound is every bit as good as the SNES'. You just can't compete with solid logic like that.

Thanks for the separation of the tune, evildragon. The PSG part sounds almost exactly like Space Harrier 3D. That's definitely the most "instruments at once" I've ever heard any FM-enabled SMS do. I'm sure most games limit the numner of channels since they're busy running graphics, game logic and other complete nonsense.
The point I was trying to make, was that it doesn't matter what the system is, it just matters what it's SPU is.

[ary incorparated]

Man i hate to say it but nes sounds better then Sega master system in anyway.Listen to the intergalactic ninja called zen he says the nes oooooooooooowns in sound department while space harier makes your ear,s bleed hell out of them the nes bombs you with tons of arpegios from hell that even Yngwie J cant even compete with in blue shadow and ohww what about batman return,s good sound with actualy decend bass and in lots of rpg volume fading,s to create harmony instead of spitting drum.This time its nintendo and not sega same why i say nintendo now because the xbox 360 is a big mailfunction with awesome games,ps3 dont bother me,so it,s the
WII.


I don't really like the loud drums in the FM version. They stand out above all other instruments (not the bass drum, the other drum, tom or snare or whatever it is supposed to be). Also, was there simultaneous PSG in that? That's what I would have done (if possible) if I were a programmer in order to use as many sound channels as possible. How are the voices on the FM version? The NES had better voices than the SMS.

I find that all SMS FM soundtracks are exactly the same as the PSG, just with re-assigned instruments. That's all.

And the nes its drums actually fit in fine while sms rarely has bass drum etc just more spit drum and with fm its sounds like the drum is seperate from the other channels.its nice it gets extra channels with wider range but still nes owns it rigth?.

[Iron Lizard]

Even better is the Famicom sound which actually actually has another channel of sound or two. The Music in Castlevania 3 sounds much better on it.

[tomaitheous]

Funny that you mentioned that. I was playing the Japanese CV3 translated to english today. The sound is awesome.

[Joe Redifer]

Castlevania 3 on the Famicom has an extra sound chip in the cart. The Famicom sound hardware is the same as the NES. Unfortunately the extra sound is not capable of passing through on the NES, so Konami had to rewrite all of the music for fewer sound channels when getting the US version ready.

[Aarzak]

That be the Konami VRC6.

Konami's VRC7 however, was only utilized in one (notable) Famicom game, "Lagrange Point" and still stands as the best music quality ever cranked out of the Famicom hardware. It's quite similar if not equal to the SMS' FM chip output:

http://www.youtube.com/watch?v=_WPUrXEnpVc


They call it the "8-Bit Star Ocean" in some circles.

[Iron Lizard]

Wow that is amazing

[Joe Redifer]

Why do you keep posting a pic of whoever that guy is? Please stop unless it has actual relevance to the topic.

[Aarzak]

Pardon me, I was just hoping someone would um, recognize who he is and denounce me for trying to pass it off as myself. :)

[Iron Lizard]

He doesn't look 20.

[ary incorparated]

Even better is the Famicom sound which actually actually has another channel of sound or two. The Music in Castlevania 3 sounds much better on it.

I know extra drum and bass corection,in many of the sunsoft titles like batman you can hear the quality.BTW the game langrant something sounds awesome.

Aarzak the picture looks like you 30 or 40 explain the overclocked hormones,too much cerial or is it actually AAArzak?.

[Aarzak]

Just wondering if there were any um, professional wrestling fans around here.

*sigh* here it goes:

That pic was of the deceased professional wrestler Chris Benoit:

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

Who made the headlines earlier this summer for offing his wife, son and then himself in a murder-suicide incuded by a momentary lapse in sanity.

That pic was taken at a doctor's office earlier on the same day he offed his wife.

I was just hoping that passing myself of with a random, decidedly creepy pic of a bearded adult as myself would make people LOL. Guess not, LOL...........:(

http://www.wsbtv.com/2007/0628/13589245.jpg

"Hi, my name is Chris and I'd like to tell you some things about diabeetus."

Alright alright, that's the last time............

Back on-topic, yes I do recall hearing that Sunsoft had the 2nd best series of sound chips for the Famicom behind Konami's. Notably the one used in "Batman: Return of the Joker".

[ary incorparated]

i already tought it couldnt be you he looks more like me lol.im no wresteling fan he sure has the arms of me.

[gamegenie]

Man i hate to say it but nes sounds better then Sega master system in anyway.Listen to the intergalactic ninja called zen he says the nes oooooooooooowns in sound department while space harier makes your ear,s bleed hell out of them the nes bombs you with tons of arpegios from hell that even Yngwie J cant even compete with in blue shadow and ohww what about batman return,s good sound with actualy decend bass and in lots of rpg volume fading,s to create harmony instead of spitting drum.This time its nintendo and not sega same why i say nintendo now because the xbox 360 is a big mailfunction with awesome games,ps3 dont bother me,so it,s the
WII.



And the nes its drums actually fit in fine while sms rarely has bass drum etc just more spit drum and with fm its sounds like the drum is seperate from the other channels.its nice it gets extra channels with wider range but still nes owns it rigth?.

I agree.

Super Mario Bros 3 world 1 theme music alone is a good example of great NES music.

[kool kitty89]

Not sure whay you're reviving an old thread just for that, but thanks, an interesting topic I've wondered about and otherwise might have missed. ;)

The SMS's PSG is very simple, 3 square wave channels and a noise channel. (a common, widely used chip, along with a couple very similar chips) The NES had much more divers audio (in terms of the waveforms available), and even had it's 5th channel for playing 7-bit ADPCM samples, hence the better sounding voiced than on the SMS. (which had to approximate that using some tricks, through the noise channel I think)

Of course this is excluding the Japanese SMS (and Mk. III w/ FM module) for the games that took advantage of this.
OTOH having the PSG in combination with the Genesis's YM2612 certainly adds added depth and contrast to quite a bit of the music on the MD/Genesis. (not just the added sound channels, but a different sound of square wave tones opposed to if the Genesis had 9 FM channels -and makes it actually more compeditive with the SNES audio wise because of this IMO)

Codemasters did some really cool NES music (actually they pulled off some neat stuff on the SMS too), it hase a very C64-ish (almost primitive FM-synth) sound (almost like a kazoo crossed with an electric guitar if that makes any sense), sometimes refered to as "warbly," it's jest an awsome kind of sound. (that kazoo sound was on several Amiga games too, though in that case I think it may be using the Amiga's primitive FM-synth)
Also that distinctive bubly kind of sound in many C64 games (though not uncommon for square wave stuff), really cool. (kind oa an echo/reverb effect)

Like in this: http://www.youtube.com/watch?v=xsccNyTkWCw
xsccNyTkWCw

[tomaitheous]

(that kazoo sound was on several Amiga games too, though in that case I think it may be using the Amiga's primitive FM-synth)

There's no FM synth on the Amiga. FM synth is one carrier changing the frequency of another carrier's (the one you hear) frequency, at a really high rate (into the audible hearing range). If you can do just that, that's primitive FM. The bare basics. Amiga and SID do not do any of that.

As far as SMS PSG vs NES PSG:
The SMS lacks any duty cycles for the TONE channels. The NES has 4 duty cycles which means two of the square channels can be independently set two 4 different types of waveform outputs (really 3 because one is inverted). That gives one reason why sounds more limited on the SMS. That and it doesn't have a triangle channel like the NES for base lines. The NES channels also have a higher divider for frequency than SMS, giving it a little wider/more accurate range relative to notes/octaves.

The SMS PSG unit lacks the EG that similar chips have. EG set to really high frequencies/rates makes for some interesting AM type sounds.

[kool kitty89]

Is this incorrect then? http://en.wikipedia.org/wiki/Original_Amiga_chipset#Paula

Additionally the hardware allows one channel in a channel pair to modulate the other channel's period or amplitude. It is rarely used on the Amiga due to both frequency and volume being controllable in better ways, but could be used to achieve different kinds of tremolo and vibrato, and even rudimentary FM synthesis effects.

[tomaitheous]

Is this incorrect then? http://en.wikipedia.org/wiki/Original_Amiga_chipset#Paula

I guess technically one could argue that's FM (out of context). But being a period base system, you could hardly do even basic FM. You'd get a non proportional negative swing because it's period based and not linear/direct. Basic FM also has the modulating carrier go through an attenuator device before modulating the output carrier. The Paula chipset also lacks that. You could high frequency arpeggio :p

[Chilly Willy]

Is this incorrect then? http://en.wikipedia.org/wiki/Original_Amiga_chipset#Paula

I can't remember where I explained this before, but here it is again. The Amiga had four audio channels. Two are directed to the left, and two to the right (you can't change that either). They are eight bit and can be DMA or set by the CPU. When using DMA, the highest sample rate is about 28 kHz for 15 kHz video modes, and 56 kHz for 30 kHz video modes (set by the fact that each channel gets two slots for DMA per video line). When using the CPU, the sample rate is set by how fast the CPU can fetch and store the samples. Needless to say, using the CPU for the sound is pretty rare.

The DMA is geared towards being double-buffered - the moment you set the DMA pointer, it is copied to a working register and an int is generated. The CPU can generate another buffer worth of audio and set the DMA pointer again. Once the first buffer is finished playing, the DMA pointer is copied to the working register and another int is generated. For each pair of channels on a side (left or right), one of the channels can modulate the other. You can select the channel to modulate the amplitude (the "samples" from one channel are stored into the volume register of the other channel), or the frequency (the "samples" from one channel are stored into the period register of the other channel). So you CAN do simple FM with the Amiga sound channels, where you get one FM synthesizer with two operators tied to each side (one FM to the left, and one to the right). The "algorithm" is always one operator modulating the other's amp or freq. Again, needless to say, no one ever did FM on the Amiga that way. It was more productive to use the amplitude modulation to extend the resolution of the channel from 8 bits to 12-ish.

By setting the modulator to the same sample rate as the modulated channel, you could change the volume of every single sample. The volume is a 6 bit log attenuator. While you could just set the volume to the upper 6 bits of a larger sample to get 14 bit audio, the log nature of the volume meant that introduced some distortion. So in cases where you want cleaner audio, people looked up the 6 bits in a table that corrected for the log curve, which reduced the range from 6 bits to about 4, yielding 12 bit audio that sounded much better. Sound people did any "FM" using wavetable synthesis, then output the 16-bit audio as 12-bit using the method described above.

[philiptwood]

Well actually there was an existing FM music sequencer that started out as an emulator using the Amiga CPU called "Syntrax" formally known as Jaytrax. The guy who created the program is name "Reinier Van Vliet" from the Neitherlands I think. He eventually ported the program over to IBM around 1996 or 97 under a company called "Jaytown (http://web.archive.org/web/*/http://www.jaytown.com/)" thus the progam was named Jaytrax. It was released I guess 98; I didn't know about it until about 98, 99 or 2000 when I downloaded it as a demo program with the "save" feature disabled unless you purchased the program. At the time he was marketing the program claiming that it could run on a 386 PC. I didn't use credit cards online then so I ask the guy if he could snail mail me a copy of it, but it was a download purchase only. I told him I didn't trust on line shopping because it was new to me then, so the Reinier gave me a copy of it for free and I've been using ever since. He told me it started out as a synthesizer for the Amiga computers which was emulated on the CPU. It even came with C64 synth instruments; it was pretty cool... it still is I made a lot music with it. You could create your own synth sounds from scratch simply by drawing inside the wavetable interface using Jaytrax instrument editor. It was a tracker but it was a little better then a tracker because you could create music like building blocks... You have to see the original interface to understand what I'm explaining. I have lots of good memories during my college days with the program perhaps I can post some music here some day. :)

Here's a link to the program both past and present.


Syntrax Homepage (http://www.finished.nl/)
Jaytown on Wayback Machine (http://web.archive.org/web/19981212030123/http://www.jaytown.com/)

If anyone actually downloads the original copy from Wayback Machine, my regestration code is "15180064..." I don't know if it'll work but you can always try.

[kool kitty89]

I just recently(today) noticed a Full Graphics mode for the ASIC chip. It's a single byte (256 color palette) bitmap output mode. Not very useful for the Genesis VDP, but perfect for the Super VDP or other display processors that use 8bit bitmap display mode. Just another piece of evidence that the SegaCD really was going to have a bitmap display processor on the addon unit side - IMO.

Wow, that's really cool; I was discussing something similar with Chilly Willy and he brought this up:


If they had simply added one 256 color mode to the CD, and made the gate array work on bytes as well as nibbles, the CD would have been far better, even with just a 12.5 MHz 68000. If SEGA had done that, we probably wouldn't have seen the 32X. We probably would have seen FAR more CD support as well. All the simple VGA software would have been ported over at least.

Which apparently they did do. (it just couldn't be used)


A pixel is 1 of 16 colors, or 4 bits. We ignore the palette here. Combining two pixels is twice 4 bits, or 8 bits. 8 bits is 1 of 256 colors, just what we need.

So combining the pixels cuts the resolution horizontally, not vertically. The four bits for one of sixteen colors for two pixels gives eight bits. No vertical combining needed at all. So 160x224 (160x240 PAL) would be the output resolution. You could put an enable in the CD GA and switch that on a line to line basis using the HINT.

The video chip in the Genesis has a bus used in the arcades that was not used in the home console. The bus outputs the current pixel (four bits), the palette number (two bits), hilite and shadow (two bits), and whether it's transparent, a sprite pixel, or a scroll plane pixel (two bits). That could have been used to feed into a chip that combined the four bits of two adjacent pixels into 8 bits for a 256 color display. The palette could have been put in the chip as well and built in a number of ways. It could also have been multiple palettes of 256 colors, not just one palette. Remember, we have extra info about the pixel output.

I've thought about getting another Genny to experiment on for this kind of a thing... it doesn't NEED to be for the CD, such a thing could be made for the Genesis alone. Since existing models don't connect the bus I mentioned above, I'd need to solder wires directly to the pins (partly why they didn't do this for the CD - if they had been thinking ahead, they would have connected the bus mentioned to the expansion port). A very simple PGA would combine the pixels, and feed a triple video DAC for RGB output. A few other lines elsewhere for control and setting the palette and Bob's your friend. :D


So technically they had all the hardware they needed with the CD and Genesis VDP, it just couldn't be utilized. :(

If only they had connected those extra pins on the Genesis VDP could have had a 256 color mode (albeit at only 160 pixels wide), and potentially increased the palette to boot. (I believe the VDP supported up to a 16-bit palette of 65,536 colors)


The 256 bitmap mode is also interesting in terms of other possibilities, like a console built off the Genesis and Segs CD (in stead of the saturn, and lacking the interface limitations of another add-on like the 32x), particularly in conjunction with the Super VDP suggestion.



I also noticed this:

The ASIC in the Sega CD was designed to output tiles to the Genesis VDP.

What you are thinking about is exactly what the 32X does, adds the Super VDP, even to the Sega CD for access.

Don't forget, most of the people here don't even know what a Super VDP is. ;)

I thought the CD couldn't use any of the 32x hardware, and 32x couldn't use any of the CD's either. The CD drive could be used by the 32x (for data transer and CD Audio playback), but not the other hardware. (all the CD-32x games using the 32x hardware exclusively)

[TmEE]

Also, the ASIC in MD2 has that color bus removed, but one other mystery bus is still present......

[johnnyb]

...slove that mystery TmEE....:D

[TmEE]

I know its outputting something, but what exactly I don't know, and its outputting stuff when there's some VRAM updating being done, but not always at that...... more investigation needed.....

[Chilly Willy]

The "byte mode" in the CD ASIC doesn't work on bytes, it works on nibbles. However, it only stores one nibble per byte instead of two like normal (which is why they call it byte mode - each pixel is in its own byte, even if it only takes half that byte). That mode COULD have been made into a real byte mode, but there was no reason to since the Genesis and CD didn't use 256 color graphics.

As mentioned by TmEE, later ASIC versions of the VDP removed certain "unused" features, so not all newer Genesis models could be hacked for even a homebrew 256 color adapter (or at least not the simple one I described). I guess that's the primary reason they did the 32X VDP the way they did.

@kool kitty89: CD games CAN use the 32X hardware, just not directly. The way SEGA designed both the CD and 32X is that the Genesis sees (nearly) all the hardware in the add-on, but the add-on sees almost nothing of the Genesis. The way you do CD, 32X, and CD 32X games is to run some code on the Genesis that coordinates actions between the add-ons. So if a CD game needs the Genesis to do something it can't (like read the pads), it sets a communication register telling the Genesis to do it for it. Same thing for the 32X. You have code running on the Genesis (in its work ram) that watches those communication registers and responds to whatever the add-on sends it.

[kool kitty89]

So a 32X CD game could thake ad vantage of the CD's added hardware in addition to the Genesis? (like using the Ricoh RF5C164 and graphics ASIC)

Could the ASIC be used in conjunction with the 32X VDP instead of the Genesis VDP? (and would there be any utility in doing so with the ASIC's 256 color bus removed?)

[Chilly Willy]

So a 32X CD game could thake ad vantage of the CD's added hardware in addition to the Genesis? (like using the Ricoh RF5C164 and graphics ASIC)

Yep! No trouble at all... well beyond knowing how to program the CD of course. ;)


Could the ASIC be used in conjunction with the 32X VDP instead of the Genesis VDP? (and would there be any utility in doing so with the ASIC's 256 color bus removed?)

You could use the CD ASIC to assist in the graphics, but remember that it works on nibbles, even in byte mode. You'd have to make two passes and combine the data for 256 color mode. Hmm - that does sound interesting, though. I should look into that a bit more. Maybe make the ASIC render in byte mode, then render in underwrite mode at twice the width. Definitely an interesting exercise, if nothing else.

I'll try a few demos once I've got my CD code base going and see if it's worth it. I'm not exactly sure how fast the ASIC is, especially using some of the priority modes. It might work fine, but not be worth it from a rendering speed point of view.

[tomaitheous]

I'll try a few demos once I've got my CD code base going and see if it's worth it. I'm not exactly sure how fast the ASIC is, especially using some of the priority modes.
I was wondering how fast the ASIC was at on point. Someone mentioned that Batman (not sure if it was the first Batman driving parts or Batman & Robin driving parts) pretty much maxed out the ASIC bandwidth.

[TmEE]

the problem is more in DMA bandwidth, the ASIC works rather fast AFAIK

[Chilly Willy]

the problem is more in DMA bandwidth,

Not when we're writing the data to the 32X framebuffer instead of the Genesis vram. ;)



the ASIC works rather fast AFAIK

The idea we're discussing is using the ASIC to help make 32X rendering faster. Is it faster than software on one of the SH2s... that's the question here.

[kool kitty89]

Yep! No trouble at all... well beyond knowing how to program the CD of course. ;)


Crap, I've been mistakenly saying otherwise in several recent threads... (mainly as a disadvantage of a "Neptune CD") Oh well.

How about the RAM though, games running on the 32x are still limited by it's 256k of SDRAM, right? You wouldn't be able to use the work RAM in the Genesis or CD. (except for stuff on the Genesis video layer?) Or could you use that RAM for other work as well, like tasks that you move over to the Genesis or CD processors. (ie could the 68k on the CD or Genesis be used to handle game logic and AI working in their own RAM or otherwise?)

This has also been bothering me, the 32x SH2's are on a shared 16-bit bus, but is this bus also shared with the 68k?



BTW, Chilly Willy, a while ago you mentioned you were looking into the CD ASIC's polygon rendering capabilities:


The CD graphics array is capable of polygon rendering as well. I'm doing some experiments in that to see what kind of speed I can get. Of course, it's still 16 color rendering only.

Any luck with that?

[Chilly Willy]

Crap, I've been mistakenly saying otherwise in several recent threads... (mainly as a disadvantage of a "Neptune CD") Oh well.

How about the RAM though, games running on the 32x are still limited by it's 256k of SDRAM, right? You wouldn't be able to use the work RAM in the Genesis or CD. (except for stuff on the Genesis video layer?) Or could you use that RAM for other work as well, like tasks that you move over to the Genesis or CD processors. (ie could the 68k on the CD or Genesis be used to handle game logic and AI working in their own RAM or otherwise?)

With CD 32X software, the 32X only has access to its own SDRAM (256 KB), and the framebuffers. In fact, the way you start up the 32X (for a CD 32X game) is to copy a header/code/data block into the framebuffer, then set one of the 32X communication registers telling it to do a CD-style startup. The 32X then copies the code/data from the framebuffer to the SDRAM and runs it. The Genesis 68000 has access to the CD Word RAM (either 128 KB or 256 KB, depending on the mode), its own Work RAM (64 KB), and the 32X framebuffer. The CD 68000 has access to the CD Word RAM (again, 128 or 256 KB) and its own Program RAM (512 KB). So the programmer has a bit of a juggling act to do if they mean to do something like read a file from a CD that is meant for the 32X processors. I think probably many CD 32X games use the CD 68000 as the main CPU running the main game code from Program RAM (at 512 KB, it's the largest block of RAM available to the CD 32X). It will then tell the Genesis 68000 to do some stuff itself (like read the pads or do some FM sounds or maybe display an overlay on the Genesis VDP), while the Genesis 68000 will then pass some of those tasks on to the 32X, like maybe do some wavetable synthesis, or draw images from SDRAM into the framebuffer. That would be a fairly straightforward way to make a CD 32X game.

Of course, there are many MANY other permutations that a programmer could come up with. Another I could imagine would be the main game code running on the 32X, with the SH2 telling the Genesis 68000 to do something, some of which it then passes on to the CD 68000 (like read a CD file or play a CD audio track).


This has also been bothering me, the 32x SH2's are on a shared 16-bit bus, but is this bus also shared with the 68k?

Not quite. The ROM bus is shared, so if you have the SH2s and the 68000 all trying to get instructions/data from the ROM at once, you wind up with waits. The Master SH2 has first shot at the ROM, the Slave SH2 has next shot, and the 68000 goes last. That's why Wolf32X runs the 68000 code in Work RAM - so it's not on the ROM bus hardly at all. The Master SH2 runs the main game code out of ROM, but its caches are on, so it spends much of its time running from cache, not the ROM bus. The Slave SH2 is put in half-n-half mode and the code it runs is stored in the cache space. So it's not on the ROM bus much either. So with proper coding, a shared bus doesn't have to be a limiting factor.



BTW, Chilly Willy, a while ago you mentioned you were looking into the CD ASIC's polygon rendering capabilities:

Any luck with that?

Not yet. I'll be doing my experiments once I've got my base code for running stuff from CD finished.

[kool kitty89]

Not quite. The ROM bus is shared, so if you have the SH2s and the 68000 all trying to get instructions/data from the ROM at once, you wind up with waits. The Master SH2 has first shot at the ROM, the Slave SH2 has next shot, and the 68000 goes last. That's why Wolf32X runs the 68000 code in Work RAM - so it's not on the ROM bus hardly at all. The Master SH2 runs the main game code out of ROM, but its caches are on, so it spends much of its time running from cache, not the ROM bus. The Slave SH2 is put in half-n-half mode and the code it runs is stored in the cache space. So it's not on the ROM bus much either. So with proper coding, a shared bus doesn't have to be a limiting factor.

Yeah, with this set-up at least.

I was discussing similar issues on the Jarguar recently, one its problems with using it 68000 is the whole system shares a single unified bus and it has to do everything in main and really bogs down the rest of the system. (one of the members actually suggested that a seperate bus with 64 kB dedicated to the 68k would really have helped things and actually made it a useful contribution to the system, rather than a hindrance)

[Chilly Willy]

Yeah, with this set-up at least.

I was discussing similar issues on the Jarguar recently, one its problems with using it 68000 is the whole system shares a single unified bus and it has to do everything in main and really bogs down the rest of the system. (one of the members actually suggested that a seperate bus with 64 kB dedicated to the 68k would really have helped things and actually made it a useful contribution to the system, rather than a hindrance)

The big problem with a single shared bus is the 68000 has no caches. So the only way to take it off the bus is to do a STOP instruction, which will put the CPU to sleep until an interrupt occurs. I imagine the better Jaguar games use the 68000 mainly just for interrupts, with it stopped the rest of the time to allow the more powerful processors more bus time.

[tomaitheous]

Not quite. The ROM bus is shared, so if you have the SH2s and the 68000 all trying to get instructions/data from the ROM at once, you wind up with waits. The Master SH2 has first shot at the ROM, the Slave SH2 has next shot, and the 68000 goes last. That's why Wolf32X runs the 68000 code in Work RAM - so it's not on the ROM bus hardly at all.

I have a question on this. When the 68000 is accessing RAM instead of ROM, it's using CE (or CS) to set the chips active, but the same lower address lines are still attached to the rom chips. If the SH2 tried to access it and enabled the chips, you'd have an address conflict (and a bus conflict) because the 68k is asserting what it needs for address line assuming the rom chips are disable/unactive. Does the 32x unit itself have an intermediate device between the 68k and the cart rom that it can disable the 68k address lines from physically connecting with the rom chips when accessing/running in ram? Some sort of gate array chip?

[TmEE]

the buses are separate, with a middleman between them, like between the 8 and 16bit buses in MD.

[ary incorparated]

Not sure whay you're reviving an old thread just for that, but thanks, an interesting topic I've wondered about and otherwise might have missed. ;)

The SMS's PSG is very simple, 3 square wave channels and a noise channel. (a common, widely used chip, along with a couple very similar chips) The NES had much more divers audio (in terms of the waveforms available), and even had it's 5th channel for playing 7-bit ADPCM samples, hence the better sounding voiced than on the SMS. (which had to approximate that using some tricks, through the noise channel I think)

Of course this is excluding the Japanese SMS (and Mk. III w/ FM module) for the games that took advantage of this.
OTOH having the PSG in combination with the Genesis's YM2612 certainly adds added depth and contrast to quite a bit of the music on the MD/Genesis. (not just the added sound channels, but a different sound of square wave tones opposed to if the Genesis had 9 FM channels -and makes it actually more compeditive with the SNES audio wise because of this IMO)

Codemasters did some really cool NES music (actually they pulled off some neat stuff on the SMS too), it hase a very C64-ish (almost primitive FM-synth) sound (almost like a kazoo crossed with an electric guitar if that makes any sense), sometimes refered to as "warbly," it's jest an awsome kind of sound. (that kazoo sound was on several Amiga games too, though in that case I think it may be using the Amiga's primitive FM-synth)
Also that distinctive bubly kind of sound in many C64 games (though not uncommon for square wave stuff), really cool. (kind oa an echo/reverb effect)

Like in this: http://www.youtube.com/watch?v=xsccNyTkWCw
xsccNyTkWCw


yeah that bubly delay stuff is what cought my head some years ago in carmageddon gbc altought nes is way beyond gbc.nes owned.i still try to get that bubly sound out of my guitar some way.all Hail to the bubly sound maybe some,someday everyone will do the bubly couse theyre going to discover that this is almost to awesome,oh almost forgot that trend is already bubling but seems nothing like it.btw what a kazoo? im from the country with a stupid culture,comon who like schlager and ducth pop and crap muziek not the klomps :p :p .so im curious about what kazoo means.

[kool kitty89]

I think tomaitheous pointed out that the "bubly" effect I was referring to is a form of arpeggio.

This is a kazoo: http://en.wikipedia.org/wiki/Kazoo
http://upload.wikimedia.org/wikipedia/commons/0/01/Kazoo-s.jpg

http://www.youtube.com/watch?v=iC65ufGUvKM

The NES games don't really have that sound I was referring to, but it's extremely prevalent in C64 music (kind of a whiny sound I guess, similar to some of the FM synth of the Genesis and early PC soundcards and also a bit like an electirc guitar in some ways)
On the NES there is something like it, but it sounds simpler, less whiney and more buzzy, I guess. (it's a bit hard to discribe but Mig 29 has this, and a good direct comparison is the theme from Treasure Island Dizzy on the NES, C64, and Amiga) This kind of sound was also fairly prevelent on the Amiga.

http://www.youtube.com/watch?v=6klzhxDtI30
http://www.youtube.com/watch?v=FeZLxEAUwjE
http://www.youtube.com/watch?v=DUcEzUuneeU

[sasuke]

The "Kazoo Guitar" sound in the video kind of reminds me of those toys that you shake and they make a wired, nasally sound (I forget what they're called). It's also used in the cave song in Lunar: Silver Star.

[kool kitty89]

The "Kazoo Guitar" sound in the video kind of reminds me of those toys that you shake and they make a wired, nasally sound (I forget what they're called). It's also used in the cave song in Lunar: Silver Star.

It's pretty common in FM synth stuff, like with the Genesis's YM2612, the JP SMS's YM2413, and the synthe chips of rht Adlib and Soundblaster sound cards. (as well as numerous arcade machines and several other home computers -especially Japanese)

I know which kind toy you mean, there's also longer batton type ones that you turn over and a part slides down making the noise. (functioning similarly to a rain stick)

[kool kitty89]

Continued from an off-tip tangent here: http://www.sega-16.com/forum/showthread.php?p=160923#post160923


I'm sure if you hit the max bandwidth of the ASIC, that would slow down some things but I was referring to the local DMA to VRAM.

So, theoretically, the CD's ASIC could do a lot more with access to something like the 32x's video RAM (which was an unanswered question posed previously). And it would therefor have more capabilities in conjunction with the 32x, but the question there was whether using the ASIC would be faster than using software on one of the SH2's.

Reading through the 1st couple pages here again, it really seems like they'd have been a lot better off elliminating the CD's added CPU and used the Genesis 68000 instead, while adding the "super VDP" (bitmap display processor) along with added video RAM to work with on the CD's side. The only problem with the Genesis CPU compared to the 12.5 MHz CD's one, is that it can only access RAM trhough the expansion port in 128 kB banks, so I don't know what effect this would have on performance. (then again, you've still got the 64 kB of work ram onboard the Genesis to use as well)
Or they could have included additional RAM on a cartridge instead, similar to the PC Engine. (of course then you wouldn't be able to use a memory cart/card for game saves inless an additional slot was added to the CD unit to assept one -which in theory could allow cheaper, more compact, memory cards to be used instead of cartridges)

The only other issue with the Genny CPU would be for playing compressed video (low res/frame rate uncompressed video should still work though), though maybe the ASIC helped with this already as even a 12.5 MHz 68k would be a pretty weak for handling even simple compression like Cinepak, in less of course the existing Sega CD port of Cinepak was highly custimized and cut-down for the console.

And the only physical limitation for this is that you'd need the external video mixing cable like the 32x, but I hink that's a rather minor disadvantage. (particularly as this would have made the system much more versitile and simple to port VGA software to using a 256 color palette, probably at least part of the reason the CD never got a port of Wolf3D)
Plus this cable could still be elliminated with the introduction of an integrated unit.

Too bad they didn't include video lines on the expansion slot... Did the Genesis VDP support video overlay natively (ie unused features from the arcade implimentations), if so that could further simplify things by puting those pins on the expansion port. (otherwise just having the RGB signals included would have been nice, and some more address space, like 20-21 bit instead of 17)

Was the address bus for the expansion port, seperate from the cartrige slot or was it just a redundant, more limited cartriged bus? (if it was seperate, the 17-bit/128 kB limitation makes a bit more sense)
Perhaps an additional need for the CD's CPU was for booting the system and accessing the CD's bios as the address bus was limited as mentioned previously. (again, using the cartridge slot for te RAM+bios like the PCE did would solve this) Had the expansion bus been increased to just 18-bits it could have had the 128 kB bios and 128 kB of RAM address space available as well.



Edit:
I would assume the genesis cartridge bus would only support (expensive) SRAM without any additional logic onboard the cartridge. Soould you'd need to include that logic as well (along with the bios). which shouldn't be too much of a problem. (I beleive the PCE's system cards did this)

I suppose you could have the bios onboad the CD unit on the expansion port bus, but it's probably a better idea to reserve this for the memory cards. (it might be beter to just go with memory cards, nothing onboard, maybe even include logic for using EEPROM for the cards instead of expensive -but simpler- battery backed SRAM)

[kool kitty89]

Ok, one more thing, if the CD graphics ASIC was given it's own video RAM to work with, how much would be useful? Would it need as much as the 32x or would that be overkill?

Also, this could either pertain to the hypothetical super VDP CD system, or for the current set up, how useful would dedicated RAM for the ASIC be in the current configuration? (and how much would be useful/necessary for it, as you'd still have the Genesis VRAM to work with as well) An additional 128 kB would be enough to double buffer a 320x200 screen, right? (with 3 kB left over, right, plus the Genesis VRAM)

[Chilly Willy]

Ok, one more thing, if the CD graphics ASIC was given it's own video RAM to work with, how much would be useful? Would it need as much as the 32x or would that be overkill?

Err - the CD ASIC DOES have its own RAM, and it's the same amount of memory the 32X has, 256 KB. Remember, the CD memory is in two blocks: 512 KB of Program RAM for the CD CPU, and 256 KB of Word RAM for the CD ASIC that can be shared with the Genesis.


Also, this could either pertain to the hypothetical super VDP CD system, or for the current set up, how useful would dedicated RAM for the ASIC be in the current configuration? (and how much would be useful/necessary for it, as you'd still have the Genesis VRAM to work with as well) An additional 128 kB would be enough to double buffer a 320x200 screen, right? (with 3 kB left over, right, plus the Genesis VRAM)

The 32X frame buffers are set up as two buffers of 128 KB. This gives space for a buffer of 320x204 (yes, that resolution is correct) in 15 bit mode. The two buffers allows things to be double buffered.

The Word RAM in the CD can be one bank of 256 KB, or two banks of 128 KB. So it's already in a form that can be identical to the 32X. They just needed the CD ASIC to draw in more modes than just four bit, and add a video display and it would have been perfect.

[kool kitty89]

Then what's with these comments about the ASIC being limited by the Genesis VRAM?
I'm sure if you hit the max bandwidth of the ASIC, that would slow down some things but I was referring to the local DMA to VRAM. For 320x224 (NTSC) it takes 5 frames (12fps) to update the a whole full screen plane. 3 frames(20fps) if you clip the display to 320x200. That doesn't include room for other vram updates (tilemap, etc) and doesn't leave room for double buffering (you'll get lots of mid screen screen tear a cross all those frames). I could see doing 128x128 chunk on a 320x200 clipped display. That'd give 60fps and still have 1/3rd bandwidth left to do tilemap/etc. No need for double buffering and no screen tearing.

[Chilly Willy]

Then what's with these comments about the ASIC being limited by the Genesis VRAM?

The CD ASIC renders cells into the Word RAM, then the Genesis uses the VDP DMA to transfer that data from the Word RAM to the Genesis VRAM because only the VRAM can be displayed. However, the VDP spends most of the time fetching data from the VRAM for display, meaning you have little time for DMAing data. This is a problem for any Genesis game, not just CD games. So they say the ASIC is limited by the VRAM because no matter how fast the ASIC draws, you won't display anything faster than the data can be DMAd into the VRAM.

[tomaitheous]

Then what's with these comments about the ASIC being limited by the Genesis VRAM?

The speed. You can't very well upload a whole frame (screen) of bitmap arranged tile data to the VDP in a single Vblank. If you could, you'd get 60fps. So you're stuck with two methods; 1) write multiple passes to VRAM with multiple vblanks, but you would see the screen updating in realtime and it would look like a chunging FPS with vsync off. 2) use a double buffer in *vram* so that you could write to off screen tile section, in multiple passes still, but *without* seeing the updating process onscreen (tearing). Still slow, but no tear. Side effect; you waste a LOT of vram doing that. Possibly 80-90% vram space, so little is left over for sprites or other stuff.

Method 2 eats up double the vram, but method 1 still eats a nice chunk of vram as well.

Nothing you do is going to add VRAM to the VDP. The whole point of this thread was that the ASIC would be better off paired with the Super VDP and a DMA chip.

And for what it's worth, I'm told that Batman Returns driving parts max the bandwidth of the ASIC. But then again, is simply doing non scaling/rotating overlaying on the ASIC faster? One could assume so.

Thinking out loud; maybe it's possible to use the ASIC to do some nice 16color x 16subpalettes (with some limitation) for sprites for the 32x Super VDP. You do a two pass system. One pass would be the actual pixel data (16color/4bit) and the other pass (and other separate buffer) would be the palettes for those pixels (16 subpalettes). It'd treat the separate as 4bit pixel data, but the 32x cpu would decode it as palette association. A palette mask :D

[Chilly Willy]

Thinking out loud; maybe it's possible to use the ASIC to do some nice 16color x 16subpalettes (with some limitation) for sprites for the 32x Super VDP. You do a two pass system. One pass would be the actual pixel data (16color/4bit) and the other pass (and other separate buffer) would be the palettes for those pixels (16 subpalettes). It'd treat the separate as 4bit pixel data, but the 32x cpu would decode it as palette association. A palette mask :D

I was thinking of doing tests like that once I've got my CD code running, but my idea was plain eight data done in two passes - doing the exact same thing, but on different nibbles of the byte for 256 color data. I do like your idea of one pass being the color, while the second pass is the "palette" selector. Hadn't thought of that. It would make it very similar to the SNES graphics. You could probably quickly fill a square with the palette data, then do the scaling/rotating for the rest.

[kool kitty89]

Wait, don't you still need the word ram to comunicate with the Genesis CPU as well? (though in the proposed layout with the Super VDP, you'd only need to do so for reading controllers, using the genesis audio hardware, and if you wanted to have the Genesis displaying a seperate video layer like in the genesis/32x configuration)

If the word RAM was broken into 2 128 kB blocks, would you be able to use one for comunication with the genesis while the other can be used by the VDP. You'd only need 128 kB to double buffer with 256-color 320x204 anyway, right?


What about the added CPU in the CD, tomaitheous was commenting (toward the begining of this thread, and I think in a couple other discussions as well) that it wasn't really necessary and kind of overkill for the system. OTOH, how could you replace it? Use the Genesis CPU instead? (would that be possible?) And if you did so, wouldn't it make generating an additional genesis graphics layer less practical as well?

Or was the CD's 68k really an asset for the console?

[Chilly Willy]

Wait, don't you still need the word ram to comunicate with the Genesis CPU as well? (though in the proposed layout with the Super VDP, you'd only need to do so for reading controllers, using the genesis audio hardware, and if you wanted to have the Genesis displaying a seperate video layer like in the genesis/32x configuration)

The Word RAM is mainly used to pass video data to the Genesis side for display. The communication registers in the ASIC are used for passing small amounts of data. The Word RAM will also be used for passing code/data to the Genesis, but that's normally just at the start. The code/data will get copied to the Genesis Work RAM, and then the Word RAM will again be used for video data. So it has more use than JUST video, but that's it's main use.



If the word RAM was broken into 2 128 kB blocks, would you be able to use one for comunication with the genesis while the other can be used by the VDP. You'd only need 128 kB to double buffer with 256-color 320x204 anyway, right?

If there had indeed been a VDP inside the CD, I don't see the need for changing the way the Word RAM was handled. Just because you SOMETIMES use the Word RAM to send non-video data to the Genesis doesn't mean it's suddenly no good for video. The frame buffer in the 32X is often used to send data to the 32X from the Genesis when you are running CD 32X games as there is no rom cart.



What about the added CPU in the CD, tomaitheous was commenting (toward the begining of this thread, and I think in a couple other discussions as well) that it wasn't really necessary and kind of overkill for the system. OTOH, how could you replace it? Use the Genesis CPU instead? (would that be possible?) And if you did so, wouldn't it make generating an additional genesis graphics layer less practical as well?

Or was the CD's 68k really an asset for the console?

If there was ONLY the Genesis CPU and a VDP on the CD instead of the CPU, then you'd make the 512 KB of Program RAM on the CD more accessible to the Genesis CPU. That would make it use the Word RAM less, which would then be more free for the VDP use. I think most devs would have exchanged the extra CPU for a VDP and better graphics.

[kool kitty89]

The genesis CPU would still be limited to accessing 128 kB banks of RAM at a time through the expansion port, right?

For practical lmitations of the Genesis 68k's processinbg power, there would still be some of the slowdown issues as with some genesis games, right? (I'm not sure how this would effect performance though)
Could including the program RAM seperately, on a cartridge be advantageous? (in the Genesis CPU arrangement) You wouldn't have to deal with bank switching, but then again, you'd need additional hardware on the cart to manage the DRAM. (plus you'd have to take it out to play Genesis games, and if you wanted a memory card/cart you'd need a seperate port onboard the CD or a onboard the ram cartridge)

And again, would using the Genesis CPU still make it practical to use generate a seperate layer of the game with the Genesis VDP? (like with the 32x) Or would the ASIC+Super VDP be capable enough that this really wouldn't be necessary in either case? (though you'd still need a video mixing cable -or at least passthrough- for the Genesis display to maintain a single video output)


And on a somewhat different note, what if they'd gone the the other direction with the ASIC, with the psudo byte mode it seems like they were planning on having a 256 color mode, but later adapted it for the Genesis VDP (or the ASIC is derived from somthing on one of their arcade boards that did use a 256-color mode), so could it have been more optimized toward the Gensis's VDP? For one it seems like having to store 4b/B is rather wasefull and takes up double the memory it would otherwise (and is completely useless in conjunction with the Genesis VDP, though it could possibly be useful with the 32x as you've both mentioned).
So would it have hellped much if the ASIC worked on ture 4-bit chuncks, or is there some other technically reason I'm ignorant of? (the main advantage I'd think, would be 1/2 the memory to move around, using less bandwidth and with fewer problems with Genesis VRAM)

[Chilly Willy]

It's all hypothetical - what we got is nothing like what we NOW would have like to have gotten. So what would the "ideal" add-on have been? Perhaps the 32X with a CD in place of the SEGA CD. Instead of the other 68000 and the ASIC, have the dual SH2 and the SuperVDP. Keep the CD/audio part the same. The memory could have stayed the same as well given that the 512 KB of Program RAM on the CD was twice what they included on the 32X.

[kool kitty89]

Well, that would have been nice, and doing that could have made it practical a Sega's flagship next-gen console as well. (in an integrated form as well as the add-on) Of course with that tech, it would have to be a few years later as well. (the timeline for SH-2's, and the relatively high cost of comperable chips in the 91/92 timeline, I don;t know if the V60 of their early 32-bit arcade systems would have been an option cost-wise either)

But on that note, being "too soon" was part of the problem with the CD, an the real what-if what would have happened if they posponed the original Sega CD desing in favor of something more advanced a couple years later (around '93/94), a hybrid of the Sega CD and 32x design philosophies would definitely have been interesting. It would elliminate the issue of having 2 seperate add-ons confusing things (being expensive to get both, rather cumbersome, and difficult to take advantage of all the hardware) and would have been practical as Sega's full Next-gen system, that like Sega's home consoles before it, would also be backwards compatible with it's predecessor.

It would still probably be limited in comparison to the PSX, but it should still have a good head start, plus the backing of a popular brand with a large userbase. The only contemporary conpetitors would be 3DO and the Jaguar, neither of which are particularly threatening in the long run. (in less you get into speculation on how they could have been handeled better as well ;) )
Tehen again, it brings the question of how Nintendo may have responded to a successful launch of such a system. (whould they have ramped thins up, possibly chosen something something quicker to develop than the SGI chipset, released their own add-on for the SNES, who knows?)


This is all going a lot further than the initial scope of the thread, but if you really want an ideal Sega Genesis add-on, it might be something more than just a hybrid of the two existing desigs as well, particularly considdering the previously discussed weaknesses on each.
From the past discussions I've read on this (and these recent ones), it would seem to be something like this:
---Interface through the Genesis expansion port and include an external mixing cable for the add-on.
Include an SH-2 as the main CPU of the add-on, plus an inexpensive custom DSP coprocessor for geometry calculations and the like. (something like the SVP)
The current added sound chip in the CD is nice, but add a bit more sample RAM for it. (maybe double it to 128 kB)
Use something more than a simple Super VDP/Bitmap display unit (like the 32x has), have something still relatively cheap and simple, but more than waht the 32x has; maybe encorporate something based on the Sega CD ASIC, or expand on the 32x's simple VDP. (Chilly Willy mentioned that adding a bit to the 32x VDP's fill function would have made it useful for blits and simple 3D) Hardware support for texture mapping and gauraud shading would be nice, but that might be pushing it cost-wise.
-Having a similar RAM set-up to the current sega CD could work, but given the later date you might afford sonething more program RAM, like 1 MB (2 MB might not be too expensive, or add provisions for later RAM expansion -other than the Genesis cartridge slot, a direct connection to the CD/add-on's memory bus) Also, perhaps use the full 32-bit data bus of the SH-2 (and same for the video), again cost could be a deciding factor, and the Genesis CPU would still be limited to a 16-bit access for the word RAM.
-Finally, a 2x speed drive would be relatively expensive at the time, so you might make an initial launch with a cheaper 1x speed unit, later release an upgraded 2x speed unit along with the integraded standalone version. (also featuring a 2x drive) Maybe keep the 1x around as a budget model. (or have a budget version of the main console featuring a 1x speed drive as well, though this could start to get cunfusing for the average consumer)


After that there's less technically important things like how to manage game saves and the controller design. On this, I think memory cards are probably the best way to go, EEPROM would be the cheapest to use, but requires additional logic and being significantly slower compared to SRAM+battery, but I think the cost factor would win out. (could the CPU handel the interfacing for this instead of dedicated hardware? Did the PSX do it that way?)
As for the controllers, you could go with standard 6-button, or add Saturn style L+R triggers, it was mentioned before that the Saturn used the same interface logic as the Genesis, with a propritary connector, so anything on the Saturn should still be possible here. Keeping the standard 2x controller ports should be fine, plus there's already multitaps available that could be carried over.

As for marketing, as long as SoJ was relatively reasonable in terms of freedom with SoA (even if they tightened down a bit, it could have been way better than the way things went 1994 onward) things should be fine. There shouldn't be any issuse with Kalinske, and he could contine the great job he'd been doing.
Of course, this is really far more important than any of the issues with hardware, and the thing that really killed Sega historically (infighting/miscomuinication with SoJ), even with everything the same, the Saturn could have been launched much better, the Sega CD and 32x could have been supported significantly longer during the transition to Saturn (probably with more 32XCD support too), and handeled better overall. (phase out Sega CD, Genesis, and 32x together once the Saturn is well established, but not before)

[parallaxscroll]

It would've been amazing if SegaCD had a SuperVDP, then there would be no need for 32X.

Here's what the actual released SegaCD had:
68000 @ `12.5 MHz
ASIC for scaling & rotation


but imagine if instead Sega CD had:
*two 68000s @ 12.5 MHz (for total of three 68000s with Genesis attached)
*SuperVDP allowing more colors (say 8192 on-screen out of 262,144) more sprites (at least 512 if not 1024) and 4 background tile layers etc
*more powerful ASIC for scaling & rotation, as good as the Super-Scaler arcade tech

Overall Sega engineers the SegaCD in 1991/1992 to be on par with their Super-Scaler 'X Board' of 1987 that powered After Burner II, if not the 'Y Board' of 1988 that powered Galaxy Force II. Sega replaces their older arcade boards (including 'Y Board') with the 2D sprite-pushing monster, System32 and 3D polygon MODEL 1 boards in 1991, so that arcade tech is still superior to their home consoles, including SegaCD. At least the SegaCD can handle any Sega arcade game of the 1980s, upto 1990 (G-LOC games).


There is absolutely no 32X. The SegaCD is supported from 1991/1992 to 1996/1997, with the Saturn coming in no sooner than late 1995 in Japan, and 1996 in the U.S.

We get to kill TWO confusing, hurtful formats that did damage to SEGA:
*32X
*32X CD

For the 16-bit era, Sega only has Megadrive|Genesis and MegaCD|SegaCD.

Also, there's no glut of awful FMV games. The SegaCD gets lots of Sega arcade conversions, lots of deep RPGs with spectacualar Sega-80s-arcade quality graphics, and lots of sequels to the best Genesis games, supercharged on SegaCD's immense 2D performance and capacity. Alot of the games that couldn't be done until the mid-late 90s on Saturn with its good 2D performance, are able to be done on SegaCD instead, and sooner.

The Saturn is mostly a 3D console like PlayStation, yet more powerful, and also able to due 2D with even more powerful VDPs with limitless sprite performance. The SegaCD doesn't have limitless 2D performance, but it's as strong as Sega's super-scaler arcade games.

Cost would be high for SegaCD, but overtime it would get less expensive, and with all-in-one Genesis-SegaCD systems, even more affordable by 1994. With it, Sega has a highend 16-bit platform that surpasses NEO-GEO and FM-Towns, dominating the 16-bit era while Nintendo flownders with its own CD-ROM projects that went from 16-bit to 32-bit, from Sony, to Phillips, back to Sony+Phillips, and eventually canceled in favor of Project Reality / Ultra 64, all the while, Sega eats the market. NEC can compete though, with a 16-bit PC Engine 2 (better than the SuperGrafx) combined with Super CD-ROM, although its not as good as SegaCD :)

[Da_Shocker]

Some of you guys are living in an fantasy land. Rember SoA was pushing FMV games hard as hell back then so all this would've done was is gone from crappy looking FMV games to better looking FMV games. And the machine you guy have bought up sounds a bit underpowered and remember that the main reason Sega dramatically changed the Saturn was to keep up with the PSx.

edit
and parallaxscroll you can't be serious all of that would simply tacked another 1oo dollars on the already exepnsive Sega CD. How on earth can anybody market a 399.99 dollar add on is beyond me. That plus the Genesis takes the unit into Neo-Geo territory.

[kool kitty89]

Shocker, the more I read into the Saturn, th emore that "drastically changed" thing seems like a myth, particularly adding the second SH-2, maybe they beefed up VDP-1 a bit, but even there I'm not so sure... There's also the little used DSP intended for gemoetry calculations, which would largely make the 2nd SH-2 unnecessary to add for 3D (as a lot of 3D work wouldn't have to be done in software as it is on the 32x), had they really wanted to "fix" it, they'd have made the standard dev kit take advantage of the DSP and make DSP-1 work off tirangles instead of quads. (that's a major change though and I'm not sure how much cost and time it would take; really shouldn't hurt 2D performance too much though, using a pair of trips instead of a single quad -and there's still VDP-2 for all the background stuff)

Also, the Sega CD launched at $299 in the US. (albeit more in Japan's earlier launch, and significantly more in Europe as well, but that's how prices tend to go, look at the Saturn's JP launch price, and that sould relatively well with no pack-in and next to no launch titles -but Virtua Fighter was its killer app)


parallaxscroll, I don't think that's really practical at all, cost would have been increased way too much doing that, and a dual 68k layout isn't particularly good (especially if the have to share the same data bus), iirc a lot of the dual 68k arcade borads used one mainly for just booting the system.

If the Sega CD was to be released at the same time it was historically, doing anything more than adding the simple "Super VDP" would be pushing it, and if anything you'd probably want more RAM before anything else. The "super VDP" should be relatively cheap though, but a small increase in production cost tends to lead to significant retail price increases. (inless of course, Sega ate the extra cost, which they probably could have done) In any case, I think the added cost would have been worth it, even if it added another $50 to the final price tag, as the possibilitys are opened up a lot and the console's lifespan could have been a lot longer. (and it would gradually drop in price, of course)


The Sega CD was launched when it was, because (rather like the Saturn), it was designed for the Japanese market, specifically to compete against NEC's new CD add-on (with Sega in a distant 3rd behind Nintendo and NEC). Had they really worked on the Sega CD seriously as a long term product for all markets, they'd ideally have waited at least another year. Add more RAM (something like double the program ram -1 MB instead of 512 k, and more sample RAM for the PCM chip would be nice too), possibly enhance the ASIC, though the existing one (with a real 256 color/byte mode) if pretty capable if it wasn't limited by the Genesis video hardware. Possibly upgrade to a better CPU, maybe a 68EC020 (to keep cost low, probably a lower-end 12.5/16 MHz one), or possible an SH-1 since Sega seemd to be interested in Hitachi's Super H series. (plus Super H seems to have been aimed at low cost consumer applications, so it's a good choic in that respect) The 68k architecture has the advantage of being very familiar/popular though, so probably make things eaiser to program for.
With the 32-bit CPU, you could widen the bus to 32-bit, but this might add significantly to cost, and I don't know if the ASIC would benifit at all from this. (or be easily modified to do so) An added DSP coprocessor for 3D calculations would be really nice (something likt the SVP chip).

Finally, with a 1+ year later release, the cost of a 1x speed CD_ROM drive should have dropped significantly as well, and by the time it was launched ouside of Japan, even moreso.

Then, instead of the CDX, you could have a full blown integrated, backwards compatible next-gen console that's relatively limited compared to the PSX, but has a huge head start and probably enough to forego the Saturn entirely. 3DO and Jaguar were never really a threat, and by the time the PSX is really catching on ~96, and the N64 is out, Sega could have their next system nearing launch. They shouldn't bother with evolutionary development or backwards compatibility at this point as it'd be too cosly and result in overly complex and limited hardware. Go straight for something like the Dreamcast, or if that's too advanced to be developed by '97, they could have done something a bit less advanced, but using a similarly clean design. (maybe based around an SH-3 rather than SH-4, probably regular CS's instead of GD-ROM, maybe a 4x speed drive, but most importantly, a powerful, yet developer freindly architecture)

By that time they really should put effort into a good anti-piracy system, and being earlier would mean it really wouldn't have the issue the DC did with lacking DVD playback capabilities. (playing VCD's out of the box would be nice feature though, at least for the Asian market where the format was popular, good for in-game video too)


Of course, on top of all this, there's the internal problems with SoJ and SoA's relationship and comunication. Though, if this "alternate" Sega CD really took off in Japan, things probably could have been better (less pressure from Nakayama on SoJ to get sales like SoA had, and less subsequent bitterness from Japanese management toward SoA)
So long as the alternate Sega CD was powerful to port well done conversions of popular Japanese arcade titles, it could have had a similar advantage as the Saturn. (particularly with Virtua Fighter)




All highly speculative of course, but even after the Sega CD launched (historically), they still could have had other options, the whole mess with 32x and Saturn and intermingled internal problems really screwed Sega. Instead of pushing SoA to develop the 32x (or even worse, the origianlly planned "Genesis II") or the Saturn, or even Genesis Virtua Racing, they could have expanded on the existing Sega CD design. No more add-ons though, an integrated Sega CD+Genesis (no CDX, as cool as it is, not good from a marketing standpoint), correct the limitations of the Sega CD, more RAM, modified (or at least minimally for a full 256 color mode) ASIC with coresponding "Super VDP," the (SVP like) DSP to help with 3D, and an upgraded CPU, a 68EC020 should be fully compatible with the 68k. (it doesn't even have the problem of the full 020's 32-bit address bus which caused some compatibility problems with select programs) Maybe enhance the audio too, though just adding more audio RAM could significantly help in itsself. (and CD soundtracks would tend to be used as well, so that really suplements things)

[parallaxscroll]

Some of you guys are living in an fantasy land. Rember SoA was pushing FMV games hard as hell back then so all this would've done was is gone from crappy looking FMV games to better looking FMV games. And the machine you guy have bought up sounds a bit underpowered and remember that the main reason Sega dramatically changed the Saturn was to keep up with the PSx.

edit
and parallaxscroll you can't be serious all of that would simply tacked another 1oo dollars on the already exepnsive Sega CD. How on earth can anybody market a 399.99 dollar add on is beyond me. That plus the Genesis takes the unit into Neo-Geo territory.


Actually the SegaCD that i'm fantasizing about is well beyond the Neo-Geo and at least on par with the 32-bit FM Towns, even beyond that as far as scaling & rotation and other sprite-manupulation effects. Yet no more powerful than Sega's high-end 16-Bit arcade boards of the late 80s. It would be expensive to be sure, at least in 91/92, but games would be cheap, at $30~$40. It would actually be less ridiculous than the Saturn with its 8 seperate processing chips in 94/95. We're talking 4 chips for SegaCD:

___________________________
| Genesis 68000
___________________________
|Sega CD 68000 - 68000
|SuperVDP - SuperScaler ASIC
___________________________

The cost of manufacturing a more powerful SegaCD would be far less than the damage Sega did to themselves during the mid 90s with all the different hardware they put out and failed with.



kool kitty89: I don't agree with beefing the SegaCD as far as having limited 3D capabilities or even 32-bit CPU like SH-1. I believe in keeping the SegaCD based on sprite-scaling technology Sega used in their 80s arcade games. I beleive the Saturn should've been based around Lockheed Martin's 3D polygon texture-mapping technology, at least on par with Model 2, if not newer like the Real3D series, although not as advanced as Model 3. If the Saturn "sat" inbetween MODEL 2 and MODEL 3 technically, it could handle ports from both boards. Upgraded Model 2 games, and scaled down Model 3 games. The Dreamcast would then go well beyond Model 3, upto or even a little bit beyond Xbox1, roughly on par with a GeForce 4 or ATI Radeon 9700, easily crushing the PS2 by the same degree the more powerful Saturn would crush the PS1 & N64.

This is all fantasy, none of this happened or will ever happen. It's just FUN to speculate with what ifs.

[kool kitty89]

Actually the SegaCD that i'm fantasizing about is well beyond the Neo-Geo and at least on par with the 32-bit FM Towns, even beyond that as far as scaling & rotation and other sprite-manupulation effects. Yet no more powerful than Sega's high-end 16-Bit arcade boards of the late 80s. It would be expensive to be sure, at least in 91/92, but games would be cheap, at $30~$40. It would actually be less ridiculous than the Saturn with its 8 seperate processing chips in 94/95. We're talking 4 chips for SegaCD:

___________________________
| Genesis 68000
___________________________
|Sega CD 68000 - 68000
|SuperVDP - SuperScaler ASIC
___________________________

The cost of manufacturing a more powerful SegaCD would be far less than the damage Sega did to themselves during the mid 90s with all the different hardware they put out and failed with.

If you're going to compare that to the saturn, then the Saturn's got 4 main chips too (6 if you include the little used DSP).

Now, apples and apples, for 8 (or the somethimes quoted 9 with the 4-bit system/peripheral manager) processors on the saturn, you've got VDP-1, VDP-2, 2x SH-2 CPU's, 1 SH-1 CD-ROM controller, The system control unit (DMA controller plus the aformentioned DSP), a 68EC000 sound CPU, Yamaha FH1 "sega custom sound processor," and the 4-bit Hitachi MCU "manager."

For your enhanced Sega CD, you've got: 2x 68000's, the custom ASIC, Super VDP, Ricoh RF5C164 sound chip, plus (to be fair) all the genesis hardware. (another 68000, YM2612, PSG, VDP, and Z-80)

As to their failure, it had as much to do with lack of cooperation than anything else (and increasing bitterness of SoJ, but that's not until '93), the best add-on they could create would be one that made the Genesis into the next-gen console, along with releasing the new console which was also backwards compatible. Intrim add-ons, or (in the CD's case) one largely aimed at Japan (in terms of design), were not the best idea.



kool kitty89: I don't agree with beefing the SegaCD as far as having limited 3D capabilities or even 32-bit CPU like SH-1. I believe in keeping the SegaCD based on sprite-scaling technology Sega used in their 80s arcade games. I beleive the Saturn should've been based around Lockheed Martin's 3D polygon texture-mapping technology, at least on par with Model 2, if not newer like the Real3D series, although not as advanced as Model 3. If the Saturn "sat" inbetween MODEL 2 and MODEL 3 technically, it could handle ports from both boards. Upgraded Model 2 games, and scaled down Model 3 games. The Dreamcast would then go well beyond Model 3, upto or even a little bit beyond Xbox1, roughly on par with a GeForce 4 or ATI Radeon 9700, easily crushing the PS2 by the same degree the more powerful Saturn would crush the PS1 & N64.

This is all fantasy, none of this happened or will ever happen. It's just FUN to speculate with what ifs.


I think 3D is a major point to go with, and while not the main thing, it should at least have rudimentary support. (to allow decent ports of Model 1 games and stuff better than what Nintendo was doing with Super FX)

As for the ASIC itsself, a big limiting factor was bing tied to the Genesis VDP and VRAM, with the Super VDP and Sega CD's RAM, it wouldn't have the same bottlenecks, I'm not sure of it's actual capable limitations though -I think it would have been pretty darn capable for 2-D stuff though, especially in conjunction with overlayed Genesis Graphics. No need for a "superScaler" chip...

Anyway, you might not even need the additional DSP and/or faster CPU for 3D, the ASIC already has some polygon rendering capabilities, again limited by the Genny's VDP, and very few games took advantage of this. (I think Stellar Fire might be an example)
This is one of the things Chilly Willy's planning on checking out when he's working on the Sega CD.

[Da_Shocker]

Sega CD had shitty support
32X had shitty support
Sega Saturn had shitty support


It's amazing that the PCECD shitted on the SCD even though it was inferior hardware but they allowed ram upgrades and more on screen colors.

[kool kitty89]

The PC Engine was already more popular than the Mega Drive, the CD unit just widened that and was so popular that it supereceded the card format.

I'm not sure exactly how popular the Sega CD was in Japan, but it's pretty clear it was more popular in the West, and much more popular than the Turbo CD in those markets (Was the TG-16 even released anywhere else in the West than North America?) Of course a lot of this was due to NEC's problematic marketing practices in the US. (they very well might have done better with these practices in European countries, especially as Nintendo was weaker over there)

Anyway, the 32x had most of its developer support from Sega itsself or outside of Japan (the early release of the Saturn really killed it though). Likewise, while the CD may have seen significant support from Japan, it was Western developers like CORE that actually pushed the hardware to do some impressive stuff. (and agian, it was more popular in these regions, not surprizing given the Strength of the Genesis/MD) Hell, some of the better Japanese developed games, like Snatcher, weren't even released on the Mega CD in Japan.

The Saturn is the opposite case, doing relatively well in Japan, far more competitive than previously, especially against Nintendo. (granted, both still beaten by Sony by a good margin in the end)
It did get some good Support in Japan too, the PSX was obviously attractive to developers due to the excellent tools and, later, massive popularity. (plus CD's over Nintendo's expensive and limiting carts)


This was a big part of the problem though, Sega of Japan focused more and more on their own region rather than making sure to maintain or even improve their strong American and European markets. (instead becoming bitter over their success)
Sure, try and expand to the Japanese market more, but by no means make it a priorety over your main successful markets. (even the Sega CD feeds into this, but that's in a rather different context, it launched in Japan when the Genesis was just starting to take off in the US and the only other option would be not to release it outside of japan at all, like with so many other accessories; but I don't think this would have been a good idea)


Having the Sega CD already out on the market makes things a bit trickier for Sega in terms of a successor to the genny. If there was just the stok genesis to worry about, building a new system with backwards compatibility in mind would be rather simple (particularly if you can take advantage of the old hadware, or used compatible but expanded versions of it like the Genesis did for the SMS), especially with Sega getting pretty much all the major components on the Genesis into a single ASIC chip (68k, VDP, PSG, YM2612, Z80) by their final model Genesis 2 (VA-4), so it would take up very little board space.

The other option is completely new hardware w/out backwards compatibility, the Saturn had a number of technical shortcomings though that put it at a disadvantage much of the time. (exaserbated by the poor management of the Saturn and relationship between SoA and SoJ after 1993)
The problem with this is you've already released the Sega CD a few years earlier with fiarly significant sales (enough for approximately 1 in 5 Genesis owners to have one), but not significant enough to use the CD as a stopgap and go for a more long term development of an advanced system to be rleased significantly later. (as would have probably happened had they taken up the SGI chipset that eventually became the N64, or a "dreamcast lite" built around an SH-3)

Had the Sega CD been a little more powerful and come a bit later, had the independent, 32x-like "super VDP" it could have provided this though, great 2D and basic 3D capabilities, enough to handel ports from the System 1 (especially Virtua Fighter, in terms of the Japanese market), and being able to handel a port of another very significant killer app, Doom!

[tomaitheous]

It would've been amazing if SegaCD had a SuperVDP, then there would be no need for 32X.

Here's what the actual released SegaCD had:
68000 @ `12.5 MHz
ASIC for scaling & rotation


but imagine if instead Sega CD had:
*two 68000s @ 12.5 MHz (for total of three 68000s with Genesis attached)
*SuperVDP allowing more colors (say 8192 on-screen out of 262,144) more sprites (at least 512 if not 1024) and 4 background tile layers etc
*more powerful ASIC for scaling & rotation, as good as the Super-Scaler arcade tech

Overall Sega engineers the SegaCD in 1991/1992 to be on par with their Super-Scaler 'X Board' of 1987 that powered After Burner II, if not the 'Y Board' of 1988 that powered Galaxy Force II. Sega replaces their older arcade boards (including 'Y Board') with the 2D sprite-pushing monster, System32 and 3D polygon MODEL 1 boards in 1991, so that arcade tech is still superior to their home consoles, including SegaCD. At least the SegaCD can handle any Sega arcade game of the 1980s, upto 1990 (G-LOC games).



Here's the main problem I have with this; where does the Genesis fit into that design? If you're going to give it that much hardware, it doesn't even need the Genesis hardware. Matter of fact, you don't even need the custom ASIC. Might as well condense an X or Y board itself into integrated chips along with the CD interface unit and call it done. What you're proposing is a whole new/separate system rather than an add-on. I also imagine a price tag of like 600-700USD minimum for that thing.

I think realistically you need to meet certain requirements at a target budget that the average gamer can afford. What was lacking on the Genesis compared to the SNES (excluding NEC outside of Japan)? Colors onscreen, scaling/rotation, transparency, sound. I know a lot of people here argue the quality and style of the YM2612 over the SPC700 unit, but at the time of the SNES release - generally speaking the Genesis sound was considered inferior. I think the SNES showed that you didn't even need insane amount of sprites or 5 independent BG layers, or whatever. Hell, the most popular games on the SNES where pretty much eye candy color fidelity and sound. A system X or Y equivalent board would be waaaaay overkill. If the games associated with those arcade board were soooo popular, then why wasn't the home market flooded with them?

The SegaCD already had the ASIC and while not X/Y board prowess, it did provided effects not capable on the SNES. The PCM unit isn't exactly on par with the SNES, but it's close enough and easily paired with the FM/PSG units. It has a dedicated processor to handle sampled-based synthesis using the PCM unit. And then there's the CD audio factor. The only thing missing from the SegaCD was a nice bitmap Super VDP that overlaid with the Genesis video (maybe even a color add/sub/mul mode between the two), and a CLUT system for the incoming pixels of the Genesis RGB signal. No extra processors, no faster ASIC, no super sprite scaling monster. The SegaCD had everything else to be on par and ahead of the SNES except color depth.

If Sega released that as an addon and also released an all-in-one SegaCD "Duo" at the same time in 1992, it would have showed that Sega was truelly focused on CD gaming as its future. The price; $199 for the addon and $299 for the all-in-one.

[kool kitty89]

Yeah, that's probably fine, with ovelay of Genesis and Sega CD video you can have each do part of the game as well and optimize accordingly. (Sega CD do all the backgrounds and any scaling effects, Genesis just do the sprites, or the other way around; or multiple others in between)

I do wonder how good the ASIC is at working with polygons though (as mentioned before it's currently bogged down by the Genesis video, inless you couple it with the 32x, which I beleive Chilly Willy is planning on looking into). This would determine how late you could push the real successor to the genesis. (If it could handel Virtua Racing, VIrtua Fighter, and Doom in some form, great!) WIth the Super VDP, and simple VGA software that was simply held back due to color limitations (with dropping to EGA not being a good option and optimization for 4x 16-color palettes difficult). Wolfenstein3D for one. (Wing Commander would probably look better too) Possible something like Amiga's Gloom (or an actual port of Gloom) if Doom is really unatainable. And lots of psudo 3D to make up for 3D limitations. (and arcade perfect ports of older arcade games like AfterBurner and Space Harrier, like on the 32x, but in compilation form like on Saturn, as well as imperfect, but much improved ports of other game slike Thunder Blade and Galaxy Force/II)

And, in addition to the added audio hardware coupled with the Genesis hardware, there's the CD audio used in most games.

But as to the longevity factor, if the Sega "Duo" became the mainstay console (kind of a very early/transitional 5th gen console), they feasibly could have foregone the Saturn and gone for something closer to the Dreamcast.

[Da_Shocker]

kool kitty89: I don't agree with beefing the SegaCD as far as having limited 3D capabilities or even 32-bit CPU like SH-1. I believe in keeping the SegaCD based on sprite-scaling technology Sega used in their 80s arcade games. I beleive the Saturn should've been based around Lockheed Martin's 3D polygon texture-mapping technology, at least on par with Model 2, if not newer like the Real3D series, although not as advanced as Model 3. If the Saturn "sat" inbetween MODEL 2 and MODEL 3 technically, it could handle ports from both boards. Upgraded Model 2 games, and scaled down Model 3 games. The Dreamcast would then go well beyond Model 3, upto or even a little bit beyond Xbox1, roughly on par with a GeForce 4 or ATI Radeon 9700, easily crushing the PS2 by the same degree the more powerful Saturn would crush the PS1 & N64.

Are you really serious. That system sounds like doomed M2. And there is no way that a system of that magnitude is gonna cost 399.99 in 95 you'd be lookin at 599.99. The Saturn was the perfect successor to the Genesis. The support was just terrible and SoJ was to busy trying to run SoA and SoE.

[kool kitty89]

Well, to be fair, the Saturn had it's share of technical issues, particularly in terms of 3rd party deveopers, even putting buroratic/internal problems aside. While possibly not its biggest problem, the choice of quad rendering was a bit odd, but again, this is whare it seems to have been optimized for 1st party, and not just for 2D (though quads are great in that respect), for some reason, sega seemed to be fond of using quadrilateral based polygon models in general, like on Model 1 games, perhaps Virtua Fighter skews this a bit for me as it's so blaringly quad based. (Virtua Racing seems otherwise, but then again, that started life as a tech demo)

Anyway, while quads were an issue, they weren't necessarily a technical limitation, the smaller problem was the lack of flexibility compared to triangles, the bigger problem being that almost everyone else was using triangle based rendering, making it a pain to port to or develop a multiplatform game for.
On top of this there are actual technical problems like the lack of good tools to take advantage of the system's power (to really push it you had to program in assembly language, while the PSX had a very well done programming library), and some bugs like with transparency. (some things weren't just poorly optimized in the dev kit, but left out entirely, at least in early kits, like the DSP in the system controll unit, intended as a coprocessor to handel 3D geometry calculations, somewhat analogus to the PSX's Geometry Transformation Engine coprocessor) Really taking advantage of the dual CPUs is also part of the challenge.

And there's the issue of difficult to consolidate hardware, but that's really on top of the rest. (and I think this may have been exaggerated a bit)


Still, I'll agree that the Saturn was a lot better than what parallaxscroll was suggesting.


And thinking again, the enhanced versions I was suggesting really aren't necessarily a good idea either. (it could be OK, but simply adding the Super VDP would mean releasing the system about the same time as historically, and giving it much more time) Plus any other changes would add to cost, which otherwise would be dropping as the system progresses on the market. (if it could make the kind of impact the PCE CD did in Japan, great!) And as a note, bumping the 68k up to 16.7 MHz and/or going up to a slightly more efficient 68010 would probably have been more practical than a dual 68k layout.

Now, with the S-VDP, there'd still be the FMV "shovelware" (but it really was popular, not just Sega pushing it, but on virtually every CD platform, and not all bad), and much better looking at that (at least 256 color, actually you could optimize for more depending on how the Super VDP was set-up, the 256 colors would be more of a limit of what the ASIC could put out) Of course, using Cinepak, you'd be getting 256 colors integral to that codec. So much better looking than the Sega CD is in reality, depending on the VDP, possibly very similar to 32x/CD re-releases. (inless they're using the SH-2's for better compression)


I still think bypassing the Saturn (or taking parts of it and refining/expanding them, like maybe keeping the same sound system and VDP's, but maybe it would have been possible to allow VDP-1 to have both quad and triangle rendering modes), but released later possibly with an SH-3 CPU. (or the "Dreamcast lite" I aluded to before, which would facilitate development of a backwards compatible successor as well) Released more around the time of the N64 (with the successor being later than the Dreamcast, and DVD based, thus elliminating that issue against the PS2).
Or they could have done what SOA had pushed for and gone with the SGI chipset (which Nintendo later picked up and developed into the N64).
And I'd still think getting Sega of Japan to partner with Sony over the PlayStation would have been quite difficult. (particularly depending on the terms: in articles, it's usually mentioned that the proposed deal was to split hardware costs and allow each company to keep profits from their own game sales, but there's no mention of how 3rd partly licencing/royaltees would have worked out -really the major factor)


I think tomatheus really summed things up nicely in his last post though, just add the bitmap display, keep the rest the same.

[Da_Shocker]

kool kitty89 it really boiled down to SoJ being assholes and not giving developers the support that they needed. I often wonder if SoA had gotten Saturn development kits in mid or late 94 instead of releasing the 32X they could've gotten the 3rd parties support that they needed. And let's be honest Doom and SWA would've helped the Saturn sell more systems rather than going to waste on the 32X.

[kool kitty89]

Not to mention SoA's in-house software development teams not having access to the tools either.

Yeah, doom would be good, as long as it wasn't the Crap port of the PSX version the Saturn eventually got... (I think it would have been really cool to get a port using the 3DO's music too, great arrangements rather than the re-done ambient crap the PSX port got... Intro music in that was cool though) I think Doom might have even worked well with the Saturn's quad rendering as there are little to no triangular portions to the environments, plus all enemies and objects done with sprites.

However, if they changed just one thing about the Saturn hardware, I think it should have been to make VDP-1 work off triangles instead of quads. (all it would really mean for 2D stuff is using 2 triangles for each sprite instead of single quads, possibly requiring the related portions of VDP-2 to be modified accordingly -the features for manipulating tiles from VDP-1, the rest could stay the same, though fixing the transparency bug would have been nice)

Then, as you say, the rest is tools, make the existing dev kits available as soon as possible and continue working on improving them. (particularly featuring that geometry DSP, which would otherwise require calculations to be done in software on one of the SH-2', even worse if a developer only uses a single CPU- optimizing dev kits to properly utilize both CPU's)


But, again, as to Doom, it would be aging rather quickly as a killer app, so it would definitely need to be a launch title to really make an impact.


And yes, problems with SoJ, Kalinske leaving and being replaced by Stolar, with the subsequent crap decisions made by Stollar ("quality control" for one, the advertizing/commercials, and finally "Satun is not our future") on top of the mess with SoJ. But before Kalinske left SoJ had been limiting SoA's freedom and atonomy more and more (the biggest reason for Kalinse leaving), and that snafu with the US launch. (confusing/angering customers and developers+retailers who'd been left out of the loop, and allowing Sony to undercut the price at their launch)

[Da_Shocker]

You can't really blame Stolar as he was being told what to do by SoJ too. I think issues such as quads,the sound chip being unable to use compressed samples, and the SH-2's didn't really operate in parallel. It's also amazing how despite having a chip dedicated to only backgrounds that alot of PSx games had games had backgrounds that were superior to there Saturn counterparts. Which either means that the chip was grossly underpowered or the developers were hardly using it at all.

[TmEE]

for sound not having compressed sample support there 2 solutions :you have a damn powerful 68K there which can do 32 channel player in software only, and the sound chips is also a powerful synthesizer capable of generating very complex sounds, BUT latter option got used very rarely, and first option that involves putting that 68K into use makes me think it was not always put into best use....

[kool kitty89]

You can't really blame Stolar as he was being told what to do by SoJ too. I think issues such as quads,the sound chip being unable to use compressed samples, and the SH-2's didn't really operate in parallel. It's also amazing how despite having a chip dedicated to only backgrounds that alot of PSx games had games had backgrounds that were superior to there Saturn counterparts.

This thread may clear up some of the parallel questions about the SH-2's: http://www.sega-16.com/forum/showthread.php?t=6751

Basicly the problems stem from a shared 32-bit data bus (16-bit on the 32x), the best option being for on CPU to work in cache while the other works in main. (you still won't be getting power of a single SH-2 ad 2x the speed -which wouldn't have been available anyway -and SH-3's probably much more expensive at this time- even with separate buses you wouldn't be getting 2x power, but still much better than just a single SH-2) Programming for a multiprocessor system tends to be more difficult too, but it's still nice to have the extra power available (a faster CPU wouldn't be an option at the time), but one thing that hurts it, as I mentioned, is the lack of support for the geometry DSP. (many games offloading this to the second SH-2, or worse, only using a single SH-2 for everything)

Also, the 2nd VDP wasn't just for BG layers, but also for manipulating the VDP-1 framebuffer. (scaling, rotation, distortion)


As to Stolar, I agree to a degree, but how much direct input did SoJ have over blocking a bunch of Japanese titles (particularly RPGs and 2D), the advertisements (look at the cool Japanese adds, inless SoJ wasn't just trying to take control, but actually hurt the American market, which makes no business sense at all), or the fateful "Saturn is not our future!" when Japan had asked him to tactfully and gently phase out the Saturn. (supposedly) Then later statements like "there is no more tekken"

[Da_Shocker]

http://www.eidolons-inn.net/tiki-index.php?page=SegaBase+Saturn+p5&bl=y

THat links pretty much summed up everything for good ole Bernard Stolar.

[Silanda]

As to Stolar, I agree to a degree, but how much direct input did SoJ have over blocking a bunch of Japanese titles (particularly RPGs and 2D), the advertisements (look at the cool Japanese adds, inless SoJ wasn't just trying to take control, but actually hurt the American market, which makes no business sense at all)

Business sense often goes out of the window when egos are at stake. SOJ's influence over advertising probably wasn't a deliberate attempt to sabotage the US market, but rather just an example of their woeful lack of knowledge regarding markets outside of their own combined with their arrogant need to keep SOA on a tight leash.

[kool kitty89]

Yes, but from what I've read, policies like limiting import title conversions (especially RPG's) were already there when he was at Sony (and part of the reason they fired him). The shocking statment about the Saturn was rather a bad move as well. Neither of these would make sense in terms of SoJ IMO.

Peter Moore otoh, seemed much more reasonable, though in the end he was pushed to pull the plug on the Dreamcast. :( Of course, parts of Japanese management had been wanting to drop to Software for a good while already.

[parallaxscroll]

Apparently Sega was using an SH3 variant for the console that would've quickly replaced Saturn had it gone forward. This is the unreleased hardware that also used the failed Nvidia NV2 chip.



Sega-16: As a Technical Director at Sega, what new hardware did you get to evaluate? Were there any that never saw release?

Toshiyasu Morita: I evaluated a lot of hardware, mostly PC 3D hardware such as the SMOS Pixelsquirt, Lockheed-Martin Real3D, and processors such as the PowerPC. Was involved in two pieces of hardware which were never released: an SH3E+Nvidia combo which never went anywhere, and I was on the compiler/debugger guy for the SH4+3Dfx board.

This was seperate from Katana/Dreamcast which was developed later and of course used the far more powerful SH4.

[kool kitty89]

Yeah, and the 3DFX based system was the Skunkworks project, intersting on the SH-3 design though, hadn't read about that before. What article is that from?

[Da_Shocker]

The rumored Saturn upgrade car aka 64X? LOL

[kool kitty89]

Wow, I just looked it up, calling something like that a "64x" would not only be bad in terms of the 32x stigma, but also in terms of technical accuracy. (the SH-3 is a 32-bit processor, as is the DC's SH-4, nothing to do with power of course, hence why the marked abandoned "bitness" ratings in this context shortly after trying to label things "128-bit")
Then again, calling it the "Saturn 2" wouldn't be much worse. (kind of like SoJ's "Genesis 2" idea, preceding SoA offeing the more reasonable 32x -as they were pushed to do something)

Still, parallaxscroll, what sega-16 atricle is that from?

Edit: found it http://www.sega-16.com/feature_page.php?id=323&title=Interview:%20Toshiyasu%20Morita

[kool kitty89]

Tomaitheous,


I thought I read somewhere that the SegaCD was going to receive a video upgrade but was canceled. Considering the ASIC is sort of a mismatch for the Genesis original VDP, it would make sense that the extra 68k@12.5mhz and the ASIC be paired with the Super VDP of a version of it (which isn't really super - just a simple BITMAP display controller - probably low cost to boot).

What do you guys think?


I just recently(today) noticed a Full Graphics mode for the ASIC chip. It's a single byte (256 color palette) bitmap output mode. Not very useful for the Genesis VDP, but perfect for the Super VDP or other display processors that use 8bit bitmap display mode. Just another piece of evidence that the SegaCD really was going to have a bitmap display processor on the addon unit side - IMO.

I just realized that this discussion occured a bit before this one:


Hey Fonz,

When you say automatically converted to tiles at full speed, are you referring to brute force method of the main CPU or the ASIC? I know ASIC has bitmap output mode, but I wasn't aware of any BMP input mode.




Right, but I would call it an issue per say. You can swap out either 1megabit (128k) buffer between of the SUB-CPU and man CPU instantly (like NES mappers) or use the 2 megabit memory mode and have the main CPU run in system ram. Either way is instantaneous. The only issue I ever saw with the SEGACD setup was the small amount of memory available to the main CPU in comparison to the SUB-CPU. If the SEGACD had it's own VDP then I could understand the layout, but otherwise it's kind of strange.

In flipflop 1M ram mode, the other unused 1M is a mirror of the first one in hardware BMP2TILES conversion on the genesis side.
On megacd side, the unused 1M area is a mirror of the other 1M but with several little modes possible, I remember reading about a byte>4bpp automatic conversion which is quite handy because a cpu can't write one single pixel at a time without hardware help*.

* On megadrive 3d rendered games, they either had to write 2 similar pixels at a time (so the second pixel is mostly dithering garbage) or they used some slow cpu manipulation to write 2 different pixels at a time.

Oh, I see (page 13 of the manual). I interpreted it backwards (ASIC full graphic function). The input it bitmap(scanline) format and the output is 4bit cell format. That is pretty handy :D


So dis this change some of your reasoning in the original Super VDP topic? (particularly the Sega CD ASIC as evidence that the engineers had intended there to be a video upgrade)
Also, in the original topic post, when you said "Super VDP" were you referring specifically to a bitmap display processor with more color capabilities (like an 8-bit/256 color mode or higher, like the 32x vdp), or just a bitmap display in general? (even just a 16-color bitmap display) Were you specifically thinking in terms of a packed pixel/chunky display, or planar display as well? (the latter wouldn't seem to be that logical, as -as I understand it- the ASIC uses chunky pixel type stuff)

This doesn't change the more recent discussion of how useful higher color capabilities coul have been, but rather if Sega had actually planned to do this some point in the design, and if the ASIC's final design reflected this.

[Jorge Nuno]

Someone asked if the MD's VDP can do video overlay natively: yes it can, it's the pin called YS.

The VDP could be a powerfull thing with some extra HW, but on the MD, it was crippled to use it's shitty color DAC and limited palette, while ignoring the color bus (this way the amount of colors would rocket) and the "unknown bus", which was probably for another 64k chunk of VRAM (suspected by it's pins positions and it's activity):



http://www.sega-16.com/forum/attachment.php?attachmentid=994&stc=1&d=1255883013
blue is S&K blue component on Mushroom hill
while the other color componets are random bits of this unknown bus (anyone notices the 64 pixel gap? there is a reason for that: refresh cycles)

Of course, for proper pixel manipulation, the VDP has it's pixel clock available externally, too.

[kool kitty89]

by crappy DAC do you just mean the 3-bits/RGB used? (rather than say, the 4-bits/RGB used in contemporary Sega Arcade boards and the GG, let a lone 5-bits/RGB) In any case, having only 4 16-color palettes to work with is rather limiting. (compared to the SNES or especially PC Engine, which had 16 palettes for each sprite and BG layer)

YS wasn't connected to either the cartridge slot or expansion port, right? (even though audio was for both I beleive) And with this you could mix the video and output fromt he Genesis AV port, or though another port on the add-on console?


As for the color bus, that is a really neat possibility, with a number of different possibilities, the main one Chilly Willy suggested (in context of the Sega CD) being to combine pixels (at 1/2 horizontal resolution), creatinging (8-bit) 256 color palettes. (you could add a larger master palette to work from as well)

Going firther with this though, in a hypothetical discussion about an evolutionary SegaCD+Genesis Saturn alternative, Chilly Willy suggested pairing 2 Genesis VDPs (with 2 banks of 64 kB each), using the color bus to feed 2 pixels together (so 256 color palettes, but at full resolution), and feed them into an external RAMDAC using a larger palette as well (preferably 24-bit like contemporaries, 18-bit like with VGA would probably be OK too).

[Jorge Nuno]

those 4 palettes is one of the shitty parts of the VDP =P

Using SPA/B you can extend them to 8 palettes, a group of 4 for plane maps and another 4 for sprites. and the color dac being shitty is that: the 3 bit limitation.

Suppose you have the VDP like this:

Plane A and plane W use one bank of 64k vram, while plane B and sprites use another 64k vram bank. Having a 3x4bit DAC (keeps compatibility with current MD games) instead of 3bit, and 4 banks of 8 palettes each (4 for planes, 4 for sprites - 1k memory). The color banks are to be used in situations like water in sonic games, where all colors are changed (instead of DMAing all those colors (and glitching the screen, due to the cram glitch), just change the bank to be used and puff, 128 new colors)

It would kick ass..


YS is presented on the cart connector near H, Vsync and EDClk signals


Remember the maximum DMA length is 128kBytes... How convenient :p Thats another reason I think the unknown bus is for Vram expansion

I really wish I had the VDP datasheet (hey it's from yamaha, even though it says sega on it)

[Chilly Willy]

Plane A and plane W use one bank of 64k vram, while plane B and sprites use another 64k vram bank.

The problem there is the VDP is accessing both banks all the time (except in blanking periods). You want another bank so the CPU can update the bank without VDP interference for MUCH better frame rates in games. Racing games or 3D games at 60 FPS instead of 15 to 20.


Having a 3x4bit DAC (keeps compatibility with current MD games) instead of 3bit, and 4 banks of 8 palettes each (4 for planes, 4 for sprites - 1k memory). The color banks are to be used in situations like water in sonic games, where all colors are changed (instead of DMAing all those colors (and glitching the screen, due to the cram glitch), just change the bank to be used and puff, 128 new colors)

The internal DAC would be for backwards compatibility only. Have an external RAMDAC for the new modes that allowed four palettes of 256 colors using 24 bit entries. You could even put a little more into your external RAMDAC for palette tricks, like have four palettes of 1024 colors, and have an offset register so that the 256 colors can be anywhere within the 1024 entries. Or have a table inside that converts the pixel data into the palette entry number so ANY pixel value could point to ANY palette entry. Either one is really very simple to do. The offset would affect all colors at once with a single register, but isn't as powerful. The table is more powerful, but would require more updates to change all the colors. I'd probably go with the offset method.

[Jorge Nuno]

But for that stuff you would need to make a VDP yourself... while the stuff I said can be "easily" added to the current VDP (I'm not sure about the 128kB Vram capability, though).

EDIT: building the homemade VDP wouldn't be too hard, too, it's just some kind of shift register, where the pixels are shifted out at the rate of the pixel clock to the CRam memories and then DAC'ed...

[tomaitheous]

So dis this change some of your reasoning in the original Super VDP topic? (particularly the Sega CD ASIC as evidence that the engineers had intended there to be a video upgrade)


I guess so. It looked like the way the ASIC was setup, that it wasn't setup for the Genesis VDP originally. But to be honest, the ASIC could just be a DSP like device with an embedded rom. Something that could more easily be changed over to use the Genesis VDP/tile format.


Also, in the original topic post, when you said "Super VDP" were you referring specifically to a bitmap display processor with more color capabilities (like an 8-bit/256 color mode or higher, like the 32x vdp), or just a bitmap display in general? (even just a 16-color bitmap display) Were you specifically thinking in terms of a packed pixel/chunky display, or planar display as well? (the latter wouldn't seem to be that logical, as -as I understand it- the ASIC uses chunky pixel type stuff)

I never thought of it using a planar format. As it is, the Genesis uses linear BPP (packed) format. Since the ASIC is just a blitter, with scaling/rotation features - it pairs nicely with a bitmap display. Just like the Super VDP in the 32x.

As it is, the ASIC can still work with the 32x sVDP in a hack I suggested (and support 8bit tiles/sprites). But to be honest, by the time you get the data (whole frame) to the sVDP - you're probably better off doing a 30hz software VDP system with one of the 32x CPUs. Chilly Willy and some others were figuring out some overlaying statistics/numbers over at spritesmind forum. IIRC, it look liked doing a decent amount of sprites and two BG layers (with 16x16 tile cells) all on the 32x side is doable in a 30hz output rate/system.


Jorge Nuno: It'd be a cool project to output the VDP's pixel bus data to a VCE chip from a PCE. Just for fun :)

[kool kitty89]

I figured a lot of that stuf out in more recent discussions already. ;) (including that the ASIC can output in packed 2pixels/byte format, in addition to the "byte" mode)



As it is, the ASIC can still work with the 32x sVDP in a hack I suggested (and support 8bit tiles/sprites). But to be honest, by the time you get the data (whole frame) to the sVDP - you're probably better off doing a 30hz software VDP system with one of the 32x CPUs. Chilly Willy and some others were figuring out some overlaying statistics/numbers over at spritesmind forum. IIRC, it look liked doing a decent amount of sprites and two BG layers (with 16x16 tile cells) all on the 32x side is doable in a 30hz output rate/system.

What if you were to use the ASIC for other things, like affine mapping? Ccould you have it set-up for the 32x CPUs to handel the 3D calculations and rasterize the polygons and have the ASIC texture them, or not even necessarily polygond, but surfaces in a raycasting type game. Or use it for 2D stuff in combination with software rendering. (some layer/sprites handeled by the ASIC and others by the SH2s in software, ignoring anything being done on the Genesis layer of course)



If the Sega CD had enhanced the color capabilities with its own VDP, there might have been soe side effects as well. If 256 color rendering was standard, uncompressed streaming video would be a lot more limited, either 1/2 the framerate or 1/2 the resolution (or something in between, 1/2 the pixels/s in any case). So youd need compression for any decent kind of video, although, 256 color at lower res could look better than some of the really dithered, low-color, videos, like the digital pictures stuff. (if you could used doubled, or maybe quadroupled pixels to maintain a larger screen size, it might actually look better, as the dither effectively lowered the resolution by at least that much already)
Could you set it up to have video that was effectively stored as something like 128x96x256 colors (which should allow for sonething like ~10 fps video plus room for 8-bit ~22 kHz mono audio), but displayed as a 256x192 window?