Super VDP for SegaCD

[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

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 .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://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/showthr...923#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.