Why does Comix Zone sound so good?

I know the SNES had a better sound processor than the Genesis. At least, that seems to be the general consensus from what I gather on these boards (I'm not particularly knowledgeable about specs and hardware design). It certainly seems to be true that digitized voices on the SNES tower over the Genesis. Digitized voices on the Genesis suck hard. I don't expect perfection from a cart-based, 16-bit system, but often times the scratchy voices are so painful, I'd rather they just left them out. Contra comes to mind:)

So why are the digitized voices in Comix Zone so good? The "Se-gaaa" that opens the game is pretty clear, and miles above anything else I've heard on the system. The game only uses very short voice samples in the game, but they sounds pretty good. Were the programmers for Comix Zone just better than others? Could the Genesis been made to look a little better with respect to digitized voices if the programmers perhaps put a bit more effort into it?

The one thing I do notice about Comix Zone is that there is not a lot happening graphically on the screen. The backgrounds are nicely detailed, but static, and no parallax (which wouldn't make sense for a comic book anyway). The number of sprites is typically very limited to one or two bad guys (although some sections have effects like rain or snow - not sure how that's handled, if each piece of snow is a sprite). At any rate, is it possible that the programmers used some extra horsepower not utilized for graphics for sound processing? Even the music quality sounds particularly good to my ear (although that may just be good MIDI programming?).

Anyway, for those of you who are more technically minded, what gives? How come Comix Zone's voices are so much better than anything else on the system?

In before FM synthesis praise and muffled pillow sounds resulting in thread derailment.

Quote:

---

Originally Posted by Olls

In before FM synthesis praise and muffled pillow sounds resulting in thread derailment.

---

Don't you know this board? Kool Kitty will come and tell us about how programmers could have used every single compression format in existence followed by possible theories about how to make sound with more than 8-bit per sample, then references about how to do it on the Amiga, Mega CD and PC Engine, followed by questions about how to make a module player and using hblank interrupts for timing, etc.

Back on-topic: parallax pretty much comes for free since that's handled entirely by the VDP. It has no effect on sound at all, other than transfering the hscroll data into VRAM (and even then it isn't that big - the worst case would be equivalent to loading 14 tiles, which isn't much when you consider that a 32×32 sprite (e.g. Sonic when spinning) is made out of 16 tiles).

Comix Zone uses GEMS by the way, so I wouldn't praise the sound engine developers that much =P

Quote:

---

Originally Posted by Sik

Don't you know this board? Kool Kitty will come and tell us about how programmers could have used every single compression format in existence followed by possible theories about how to make sound with more than 8-bit per sample, then references about how to do it on the Amiga, Mega CD and PC Engine, followed by questions about how to make a module player and using hblank interrupts for timing, etc.

Back on-topic: parallax pretty much comes for free since that's handled entirely by the VDP. It has no effect on sound at all, other than transfering the hscroll data into VRAM (and even then it isn't that big - the worst case would be equivalent to loading 14 tiles, which isn't much when you consider that a 32×32 sprite (e.g. Sonic when spinning) is made out of 16 tiles).

Comix Zone uses GEMS by the way, so I wouldn't praise the sound engine developers that much =P

---

What's GEMS? And why didn't everyone use it? :)

Quote:

---

Originally Posted by sketch

And why didn't everyone use it? :)

---

http://www.militaryphotos.net/forums...5&d=1238774506
:p


http://gdri.smspower.org/wiki/index....nd_Engine_List
http://www.sega-16.com/forum/showthr...-Sound-Drivers

Quote:

---

Originally Posted by agostinhobaroners

http://www.militaryphotos.net/forums...5&d=1238774506
:p

---

^

Okay, so GEMS is some kind of sound engine. Still doesn't answer the question. Comix Zone's voice samples sounds much better than anyone else's, and on top of that, they're using a standard sound engine of some sort. So why do their voice samples sound better? And yes, why not give kudos to the developers? They managed to do something with a standard tool that apparently others could or would not do.

Sometimes, it's tough to get a straight answer around here.

You didn't get it... I wasn't trolling you, pal.
Thing is many people would prefer that GEMS never existed in favor of the Japanese sound engines/drivers. Get it?

Very few programmers/composers did a great job using GEMS. Take a look in that list, most of bad sounding games used GEMS.

GEMS is horrible. PCM playback is its only saving grace, at everything else it outright sucks. It has a serious tendency to become unable to keep up with the tempo.

So far I can only think on two situations where it sounds good: whenever Howard Drossin is the composer (note: true for Comix Zone), and in Jelly Boy (for whatever reason GEMS doesn't crap out there).

EDIT: and I seriously need to go finish Echo ack, but I need to fix some stuff first. Echo uses the same method as GEMS to do PCM playback, so it's possible it sounds the same way there.

Quote:

---

Originally Posted by sketch

Sometimes, it's tough to get a straight answer around here.

---

It's better to wait for actual knowledgeable people to come in.

Yeah, try to avoid the FM synthesis haters.

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

Quote:

---

Originally Posted by agostinhobaroners

You didn't get it... I wasn't trolling you, pal.
Thing is many people would prefer that GEMS never existed in favor of the Japanese sound engines/drivers. Get it?

Very few programmers/composers did a great job using GEMS. Take a look in that list, most of bad sounding games used GEMS.

---

I wonder if it was the tool or the skill of the people using the tool. Amazing how bad developers tools can totally screw a system (or at the least impair it).

Quote:

---

Originally Posted by Da_Shocker

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

---

Good video. Amusingly, most of the good samples are from games I don't own and haven't played.

Quote:

---

Originally Posted by sketch

I wonder if it was the tool or the skill of the people using the tool. Amazing how bad developers tools can totally screw a system (or at the least impair it).

---

That's just it, not every developer knows what they're doing. Some of them just plain suck, that's pretty much still the case today. Why else would we get crappy games, no one sets out with the goal of making a shitty game that will get bad reviews and sell poorly. It's just a question of the skill of people making it. Combine that with other similar factors like how much time they have to develop and test the game, and functionality or disfunctionality of the development team as a whole and you get your answer.

GEMS was "good" for sample-fests like fighting games. MK3/UMK3 and WWF Wrestlemania show that, with a great job by Sculptured software.
However, specially in WWF, the compositions sound weak...

Quote:

---

Originally Posted by sketch

I wonder if it was the tool or the skill of the people using the tool. Amazing how bad developers tools can totally screw a system (or at the least impair it).

---

It is the sound engine. The problem lies in it's channel allocation system. Because apparently musicians can't understand the concept of limited hardware channels (despite MIDI itself having it) GEMS developers decided that every note should play in a new channel. The problem is that this means loading the entire FM instrument every time you wanted to play a note. Such an operation is horribly slow. Now you get why GEMS can't keep up with the tempo.

Quote:

---

Originally Posted by Sik

It is the sound engine. The problem lies in it's channel allocation system. Because apparently musicians can't understand the concept of limited hardware channels (despite MIDI itself having it) GEMS developers decided that every note should play in a new channel. The problem is that this means loading the entire FM instrument every time you wanted to play a note. Such an operation is horribly slow. Now you get why GEMS can't keep up with the tempo.

---

I was actually more interested in the voice quality as it relates to GEMS/the Genesis. Apparently GEMS sucks but Comix Zone, as I just found out uses this tool and has some of the best sounding voice samples on the Genesis (IMHO).

Quote:

---

Originally Posted by sketch

I was actually more interested in the voice quality as it relates to GEMS/the Genesis. Apparently GEMS sucks but Comix Zone, as I just found out uses this tool and has some of the best sounding voice samples on the Genesis (IMHO).

---

Because GEMS is constantly checking if it's time to play the next sample while it's parsing FM and PSG. This results in more even playback than SMPS - or even Tiido's sound engine, for that matter (which means you can get away with a lower sample rate without losing much quality).

Well what sound engine was the SF series using? I assume they were SMPS and if they did those voices sounded like shit. And what was the MK1 and 2 using because even thought like 70% of the voices were gone they did sound clear or better than what SF had.

I think the Street Fighter games were using a custom sound engine.

Alright, I'm not claiming to be more knowledgeable on the subject, but the Genesis DAC was relatively poorly documented for Assembly language programmers. The Digital Audio Channel (DAC) is software driven and replaces one of the six FM channels of the YM 2612. By software driven I mean that the Digital Audio had to be timed perfectly with other aspects of the system to stop it from being broken up (that garbly sound we all know and love). Early Genesis documentation simply encouraged halting all other audio to play a sample, which was the case in Space Harrier II and other launch games like Altered Beast. As is the case throughout videogame history, when something is left up to the programmers it is usually underutilized at best and poorly utilized at worst. GEMS and other sound engines were created to mitigate this issue, but it introduced another problem. When a programmer takes on somebody else's engine they work with in the confines of the engine rather than the actual hardware.

If anybody wants to read more, I documented all of the sources I could find a couple of years ago here.

Quote:

---

Originally Posted by sheath

Alright, I'm not claiming to be more knowledgeable on the subject, but the Genesis DAC was relatively poorly documented for Assembly language programmers. The Digital Audio Channel (DAC) is software driven and replaces one of the six FM channels of the YM 2612. By software driven I mean that the Digital Audio had to be timed perfectly with other aspects of the system to stop it from being broken up (that garbly sound we all know and love). Early Genesis documentation simply encouraged halting all other audio to play a sample, which was the case in Space Harrier II and other launch games like Altered Beast. As is the case throughout videogame history, when something is left up to the programmers it is usually underutilized at best and poorly utilized at worst. GEMS and other sound engines were created to mitigate this issue, but it introduced another problem. When a programmer takes on somebody else's engine they work with in the confines of the engine rather than the actual hardware.

If anybody wants to read more, I documented all of the sources I could find a couple of years ago here.

---

That's pretty hilarious that the early documentation just recommended stopping other audio to play samples. "Who would possibly want to hear voice and music simultaneously? Madness!"

Early documentation never suggested that. Also the DAC wasn't poorly documented... there just wasn't more to it that could be documented, really. It's a really simple piece of hardware. The problem is actually getting something useful out of it, but that's entirely the software's job.

Early sound engines would stop all playback just because programmers didn't have a clue about how to get something out of it. As time passed they started finding out ways to get PCM playback without interrupting everything else.

It seemed to me that companies with experience in arcades seemed to, typically, do a much better job with FM synth than others. I'm sure it had to do with z80's and FM chips being a staple for arcade boards throughout the 80's.

Quote:

---

Originally Posted by Sik

Early documentation never suggested that. Also the DAC wasn't poorly documented... there just wasn't more to it that could be documented, really. It's a really simple piece of hardware. The problem is actually getting something useful out of it, but that's entirely the software's job.

Early sound engines would stop all playback just because programmers didn't have a clue about how to get something out of it. As time passed they started finding out ways to get PCM playback without interrupting everything else.

---

See the end of Nemesis' Genesis Technical Overview 1.00 pg 92. I have read this in several other official Sega docs as well.

Are you referring to this part?

Quote:

---

The 8-bit Digitized Audio exists as a replacement of FM channel 6, meaning that turning on the DAC turns off FM channel 6. Unfortunately, all timing must be done by software -- meaning that unless the software has been very cleverly constructed, it is impossible to use any of the FM channels at the same time as the DAC.

---

Emphasis mine, notice that part in bold. Also, let's be fair, the dual CPU architecture was pretty much made encouraging having the Z80 do all PCM stuff with the 68000 doing everything else, and if you were to see this, you'd probably think that's the easiest way to get away with it.

EDIT: fffffffff why quotes are always 100% italicized?

I am not debating whether the Z80 should have been used to handle the PCM timing, I am simply regurgitating reasons I have read as to why it was not. I recall Tomaitheous even claiming that the Z80 wasn't very useful for audio at one point while we were arguing about wasted/stupid engineering decisions in the MD/Genesis. If I can remember where I have read the specific recommendation to halt audio in a Sega document I will post it, for some reason I can't find any notes on it right now.

Quote:

---

Originally Posted by sheath

I recall Tomaitheous even claiming that the Z80 wasn't very useful for audio at one point while we were arguing about wasted/stupid engineering decisions in the MD/Genesis.

---

Because using a proper PCM fetching hardware would have been much better than anything else =P Let's be fair though, the Z80 has 100% of its time alloted to audio. The real issue is when you get the Z80 do PCM and other stuff at the same time (as is the case of most Z80-only engines). Then yes, you're screwed for the total lack of any proper hardware timing.

Quote:

---

Originally Posted by sheath

If I can remember where I have read the specific recommendation to halt audio in a Sega document I will post it, for some reason I can't find any notes on it right now.

---

What some addenums suggest is to halt the Z80 when accessing the I/O ports, because that could potentially cause a serious bus timing issue when the Z80 is reading from ROM (although in practice I never found that to actually happen). By no means they suggest to stop sound playback though.

Quote:

---

Originally Posted by Sik

Don't you know this board? Kool Kitty will come and tell us about how programmers could have used every single compression format in existence followed by possible theories about how to make sound with more than 8-bit per sample, then references about how to do it on the Amiga, Mega CD and PC Engine, followed by questions about how to make a module player and using hblank interrupts for timing, etc.

---

jajajajaj xDDDDDDDDDDDDDD

I really admire Kool Kitty, but your comment made me laught insanely at work
thanks!!

Quote:

---

Originally Posted by sketch

I know the SNES had a better sound processor than the Genesis. At least, that seems to be the general consensus from what I gather on these boards (I'm not particularly knowledgeable about specs and hardware design). It certainly seems to be true that digitized voices on the SNES tower over the Genesis. Digitized voices on the Genesis suck hard. I don't expect perfection from a cart-based, 16-bit system, but often times the scratchy voices are so painful, I'd rather they just left them out. Contra comes to mind:)

So why are the digitized voices in Comix Zone so good? The "Se-gaaa" that opens the game is pretty clear, and miles above anything else I've heard on the system. The game only uses very short voice samples in the game, but they sounds pretty good. Were the programmers for Comix Zone just better than others? Could the Genesis been made to look a little better with respect to digitized voices if the programmers perhaps put a bit more effort into it?

---

Maybe you just haven't compared it with enough other games . . . there's a combination of factors, but the main ones are: quality of the samples used (that's both in the quality of conversion/preprocessing to the final digital format, and the actual space taken up by that sample -higher sample rates -ie 16 kHz vs 4 kHz- take more space, and uncompressed 8-bit PCM takes more space than 4-bit PCM or DPCM/ADPCM, and the latter 2 take more Z80 resource/programming to decode- ), and finally there's the evenness of playback. (uneven or inconsistent playback will distort the sound, something even more problematic at low sample rates)

There are some fairly early games with pretty low quality samples (like 4 kHz 8-bit PCM) that sound quite clean due to good conversion and even playback (and certain types of sounds just working better at low quality). Altered Beast and Space Harrier II come to mind. (I think the Saaaygah! is also only 4 kHz) Note that the samples in SFII are also all 4 kHz 8-bit PCM, but with very uneven playback. (there are numerous other games with similar problems)

There's a few early games that actually use very high quality samples (as far as the system goes), like the drum samples used in Vapor Trail, Atomic Runner, or Mega Turrican (all only 1 MB/8Mbit games). Albeit those 2 Data East games don't show that off with SFX or speech (all the high quality samples go to music and Vapor Trail uses fairly low quality speech -though the Arcade original had intentionally stylized radio-chattered speech). Mega Turrican does sport some nice speech in the title (Presented by Data East) and for the powerups. (though I'm not sure that's as high quality as the drums)

Madden '96 has some nice speech and Drum samples . . . and a really long sample for the title screen:
http://www.youtube.com/watch?v=e9AYz6CIq2E

Quote:

---

The one thing I do notice about Comix Zone is that there is not a lot happening graphically on the screen. The backgrounds are nicely detailed, but static, and no parallax (which wouldn't make sense for a comic book anyway). The number of sprites is typically very limited to one or two bad guys (although some sections have effects like rain or snow - not sure how that's handled, if each piece of snow is a sprite). At any rate, is it possible that the programmers used some extra horsepower not utilized for graphics for sound processing? Even the music quality sounds particularly good to my ear (although that may just be good MIDI programming?).

Anyway, for those of you who are more technically minded, what gives? How come Comix Zone's voices are so much better than anything else on the system?

---

Comix Zone's graphical style probably has little to do with it: the only major issue with graphics that can compromise sample playback is heavy animation. Animation requires updates to VRAM, and that can lead to contention between the Z80 and VDP (VDP blocks the Z80 from reading samples). There are ways around that issue, but it can be a significant problem. (it's also one reason that some games have nice speech in the sound test that gets worse in-game . . . it seems that's not the case with SFII though, but that's another topic ;))


As for the Music quality, that's mainly up the the skill of the composer/sound programmer. GEMS (unlike most sound engines on the system -and certainly all other licensed ones) supported MIDI, realtime listening, and other features that made it relatively easy to compose for without computer programming skills. However, it had a relatively limited default instrument set and didn't make some effects obvious to inexperienced composers (or rather, those unfamiliar with FM synth chips -not inexperienced in music in general). Composers who knew how to make custom FM instruments, make good/selective use of sampled percussion, and used some additional effects (like paired channels for reverb/echo) could do far better than those just making generic midi arrangements. (most ended up as the latter with GEMS, but a few were really nice -like the Earthworm Jim games and Comix Zone)
DOS games had the same problem with bland sounding compositions. (they also tended to lack use of samples for drums and such in spite of the Sound Blaster making that pretty easy)

Quote:

---

Originally Posted by sketch

What's GEMS? And why didn't everyone use it? :)

---

Developers chose to use GEMS for 2 main reasons: 1, it was easy to use for non-programmers (greatly expanding the pool of possible composers/sound designers and/or avoiding the need for close cooperation of a programmer with a composer -if the composer wasn't also the sound programmer).
and 2, it was offered by Sega for 3rd parties to license. (and was the only licenseable option that fit criteria 1 -there were some 3rd party drivers that were really nice that fit that too though, like the Crysalis driver used by Matt Furniss -Mickey Mania, F-15 II, Alien 3, etc)

Also, the PCM playback is relatively good in GEMS and both 8 and 4-bit PCM (but not DPCM or ADPCM) are supported standard. (and only 1 channel . . . the playback is well above average for MD stuff at least)

There's another problem with GEMS on a technical level: it requires each channel to have an instrument assigned for every note played (rather than only changing instruments as needed), and that tends to overload the Z80 and lead to uneven tempo or slowdown of the music.
However, while this is one of the bigger complaints of developers of capable composers, it's not the main complaint you see for GEMS music. (that simply has to do with composers making rather bland arrangements due to inexperience with the format)

It's a shame that Sega didn't design GEMS better, or provide major upgrades to it. That instrument assignment thing was rather wasteful and pointless, but aside from that there's things like not providing a wealth of alternate instruments to chose from (rather than the limited default selection), tips on using added effects (echo/reverb, etc) if not actually adding some sort of software assistance for those effects (ie allowing composers to simply select pairs of channels or such to do additional effects or more complex sounds), and possibly expanding the PCM driver. (supporting more channels and/or formats -like DPCM or ADPCM)

Quote:

---

Originally Posted by sketch

I wonder if it was the tool or the skill of the people using the tool. Amazing how bad developers tools can totally screw a system (or at the least impair it).

---

Skill of a composer to work with the format is certainly a major factor. (being skilled with FM synth chip music in general is a big part of it, though there's obviously some specifics to the Genesis sound set up to cater to as well)

Quote:

---

Good video. Amusingly, most of the good samples are from games I don't own and haven't played.

---

As above, it's interesting that several "good" examples are actually among the poorer (technical) quality samples in the system. (Space Harrier II and Altered Beast both at 4 kHz)

Some composers simply were/are awesome in general though, like Tim Follin.

Quote:

---

Originally Posted by Sik

Don't you know this board? Kool Kitty will come and tell us about how programmers could have used every single compression format in existence followed by possible theories about how to make sound with more than 8-bit per sample, then references about how to do it on the Amiga, Mega CD and PC Engine, followed by questions about how to make a module player and using hblank interrupts for timing, etc.

---

No, more like I'd point out it was the composer's skill and experience with the specific format . . . unless the question was to SFX/speech rather than music quality. (in that case, it's just up to GEMS's playback capabilities and the quality samples used ;) . . . and maybe limiting V-DMA to reduce contention issues) :p

Quote:

---

Originally Posted by Sik

GEMS is horrible. PCM playback is its only saving grace, at everything else it outright sucks. It has a serious tendency to become unable to keep up with the tempo.

So far I can only think on two situations where it sounds good: whenever Howard Drossin is the composer (note: true for Comix Zone), and in Jelly Boy (for whatever reason GEMS doesn't crap out there).

---

The Eartworm Jim games sound pretty good too.

Your complaints don't match the normal complaints about GEMS though. Until your explanation of the instrument assignment issue, I'd never even seen complaints directed towards slowdown/uneven tempo. All the complaints were about the bland/generic/limited sounding instruments and the corresponding arrangements. (similar to complaints about EA's stuff . . . or the FM music in most DOS games)

Quote:

---

Originally Posted by Sik

What some addenums suggest is to halt the Z80 when accessing the I/O ports, because that could potentially cause a serious bus timing issue when the Z80 is reading from ROM (although in practice I never found that to actually happen). By no means they suggest to stop sound playback though.

---

Hmm, I wonder if that's one of the problems with Capcom's driver. If the Z80 is being halted whenever the 68k accesses I/O ports, that could cause some problems. (depending how long and how often the 68k accessed I/O) That or the 68k simply spends too much time updating YM registers for FM. (or something else that causes sample playback to be much more even when the 68k is halted -ie if you select a SFX sample in the sound test and quickly halt the 68k in time before the sample plays)

Quote:

---

Originally Posted by agostinhobaroners

You didn't get it... I wasn't trolling you, pal.
Thing is many people would prefer that GEMS never existed in favor of the Japanese sound engines/drivers. Get it?

Very few programmers/composers did a great job using GEMS. Take a look in that list, most of bad sounding games used GEMS.

---

The problem is that there's a good reason GEMS was used:
things like SMPS were a pain in the ass to use . . . or just plain impossible for non-programmers. So you'd need a composer who could code, or a composer partnered with a programmer.

Getting rid of GEMS isn't what they needed, but a better GEMS or a good (easily licensed) alternative is what was needed. Something that was even easier for non-programmers to use (tracker/midi support, etc) with more preset instrument patches to select from and more support for added effects (like reverb or instruments requiring multiple channels). Then there's the separate issue that Sik addressed. (rather pointless forced per-note channel/instrument assignment that hogs Z80 time and tends to screw up tempo -albeit NOT the thing most people complain about)

Quote:

---

Originally Posted by sheath

Alright, I'm not claiming to be more knowledgeable on the subject, but the Genesis DAC was relatively poorly documented for Assembly language programmers. The Digital Audio Channel (DAC) is software driven and replaces one of the six FM channels of the YM 2612. By software driven I mean that the Digital Audio had to be timed perfectly with other aspects of the system to stop it from being broken up (that garbly sound we all know and love). Early Genesis documentation simply encouraged halting all other audio to play a sample, which was the case in Space Harrier II and other launch games like Altered Beast. As is the case throughout videogame history, when something is left up to the programmers it is usually underutilized at best and poorly utilized at worst. GEMS and other sound engines were created to mitigate this issue, but it introduced another problem. When a programmer takes on somebody else's engine they work with in the confines of the engine rather than the actual hardware.

---

DAC standard for digital to analog converter, not digital audio channel. And it's just that, a bare 8-bit DAC with a parallel bus connection to the Z80 (and 68k) via the YM2612. (it's rather like the covox DACs or disney sound source for PCs -or homebrew parallel port DACs) To make that do PCM playback, you need the CPU to write every single PCM sample word (ie 8-bits, etc) to the DAC manually, with precise timing. (if the timing is off, the PCM will be uneven)

Documentation was never, ever the problem. The problem was the limited abilities of programmers to write tight, precisely timed Z80 code for playback . . . or developers not putting a high enough priority on managing even PCM playback. (ROM space was also an issue, but there's many more problems than just low quality samples . . . or the issue of using compressed samples with software decompression, or just plain 4-bit PCM -and the latter probably should have been used far more than it was, most low quality 8-bit samples would be better as 4-bit as 2x the rate -ie 4 kHz 8-bit could be 8 kHz 4-bit) Then there's the issue of programmers having trouble with software mixing of multiple channels.

There's also no hardware assistance for PCM. The PC Engine has convenient interval timers to generate timed interrupts for software PCM playback (and a CPU that's extremely efficient with interrupt handling), the ST also used interrupt driven PCM for most in-game cases (precise, software timed PCM stuff was limited to demos/title screens) though the ST tended to use only very low rate samples usually no more than 4 kHz. (due to the excessive overhead for interrupts on the 68000)

The Z80 in the MD has no interrupts for such (only timed interrupts are vblank, and that's only 50 or 60 Hz). There are the YM2612 timers, but Sega oddly left the IRQ line on the YM disconnected. (though even with those timer interrupts, the YM timers don't loop, so you need to reset them after each interrupt -so more overhead and less consistent timing than looping timers)
As it is, you could still manually poll the timers in the YM for smooth playback without precise CPU timing, but that's even more overhead than interrupts (though GEMS does that along with a handful of others). For the many games that didn't even bother to use higher sample rates than ~8 kHz, that probably would have been a fairly decent option though.

Some drivers use the Z80 only for PCM and have the 68k handle FM/PSG updates. (simplifying Z80 coding/timing) This was more foolproof and resulted in some of the higher quality sample examples. (aside from pre/SMPS-68k, there's Vapor Trail and Atomic Runner -Mega Turrican oddly uses the 68k for PSG, but Z80 for FM+PCM) Capcom also took that route, but the results were far from impressive.

There's the added issue of the Z80's slow bank switching (lots of cycles wasted each time you need to jump to a different 32k window in ROM), but that's especially problematic for multi-channel playback. (without added buffering to Z80 RAM, you'd have to change banks after each sample . . . unless the 2 samples being mixed are located in the same 32k ROM area)

Quote:

---

Originally Posted by kool kitty89

Hmm, I wonder if that's one of the problems with Capcom's driver. If the Z80 is being halted whenever the 68k accesses I/O ports, that could cause some problems. (depending how long and how often the 68k accessed I/O) That or the 68k simply spends too much time updating YM registers for FM. (or something else that causes sample playback to be much more even when the 68k is halted -ie if you select a SFX sample in the sound test and quickly halt the 68k in time before the sample plays)

---

I'm going to take a blind guess (never checked the code) and say that it's probably doing this:

• Stop Z80
• Write FM register
• Resume Z80
• Stop Z80
• Write FM register
• Resume Z80
• Stop Z80
• Write FM register
• Resume Z80
• ...

Instead of this:

• Stop Z80
• Write FM register
• Write FM register
• Write FM register
• ...
• Resume Z80

This is especially dangerous because the Z80 can take up quite a lot of time to halt processing (probably same deal when resuming, never checked). This can severely affect Z80 performance.

It has already been accurately described but we can resume bad voices playback to a single reason : Z80 interruption.
If you avoid Z80 interruption then the PCM (and so voices) playback can be really good.
You can avoid Z80 interruption by handling FM & PSG stuff on Z80 side and not use the DMA.

Quote:

---

Originally Posted by Stef

You can avoid Z80 interruption by handling FM & PSG stuff on Z80 side and not use the DMA.

---

Easier said than done. Not using DMA is asking for instantaneous slow down as soon as you want to do anything interesting with the video hardware, and if the Z80 handles FM and PSG then you're forced to deal with a lot of timing issues Z80-side because now you need to make sure FM and PSG processing doesn't interrupt PCM playback.

Quote:

---

Originally Posted by Sik

I'm going to take a blind guess (never checked the code) and say that it's probably doing this:

• Stop Z80
• Write FM register
• Resume Z80
• Stop Z80
• Write FM register
• Resume Z80
• Stop Z80
• Write FM register
• Resume Z80
• ...

Instead of this:

• Stop Z80
• Write FM register
• Write FM register
• Write FM register
• ...
• Resume Z80

This is especially dangerous because the Z80 can take up quite a lot of time to halt processing (probably same deal when resuming, never checked). This can severely affect Z80 performance.

---

I assume then that Sega's (pre)SMPS-68k drivers don't have that problem. (as the samples aren't nearly as distorted)

I'd also thought it might be a case of the 68k being used to read/mix the samples and then copy the mixed stream into a buffer in Z80 RAM (so fairly long periods of contention in Z80 RAM), though that wouldn't account for the Z80 being able to play a complete sample with the 68k halted. (unless the entire sample is being buffered into SRAM, which isn't practical as some samples would take too much space -2 seconds of 4 kHz PCM would leave no room for any Z80 code)

Quote:

---

Originally Posted by Stef

It has already been accurately described but we can resume bad voices playback to a single reason : Z80 interruption.
If you avoid Z80 interruption then the PCM (and so voices) playback can be really good.
You can avoid Z80 interruption by handling FM & PSG stuff on Z80 side and not use the DMA.

---

Doing all sound on Z80 requires tighter coding though, and many Z80 based drivers sounded quite poor compared to 68k contemporaries. (uneven/distorted playback) The best sounding early drivers (or best sounding drivers in general for commercial games) used 68k+Z80. (pre/SMPS-68k stuff tended to sound far better than pre/SMPS-Z80 -and preSMPS Z80 halted FM/PSG for PCM- and then you've got Data East's Vapor Trail driver and the odd case of Factor 5's Mega Turrican with the Z80 handling FM+PCM and 68k handling PSG)

Quote:

---

Originally Posted by Sik

Easier said than done. Not using DMA is asking for instantaneous slow down as soon as you want to do anything interesting with the video hardware, and if the Z80 handles FM and PSG then you're forced to deal with a lot of timing issues Z80-side because now you need to make sure FM and PSG processing doesn't interrupt PCM playback.

---

The simplest workaround I've seen is to interleave DMA, not using DMA on every scanline in vblank. (thus only causing moderate amounts of missed writes in vblank, not a huge issue)

If you did avoid DMA, and handled VRAM updates with the 68k, that would cut bandwidth by more than 1/2 for H40, but less than 1/2 for H32. (which means you could potentially copy more using the 68k in vblank than you could if you only DMA'd on every other scanline in vblank, in H32)

Quote:

---

Originally Posted by Sik

Easier said than done. Not using DMA is asking for instantaneous slow down as soon as you want to do anything interesting with the video hardware, and if the Z80 handles FM and PSG then you're forced to deal with a lot of timing issues Z80-side because now you need to make sure FM and PSG processing doesn't interrupt PCM playback.

---

Of course that imply a more complex Z80 driver but i think it really deserves it...
Also about the VRAM limited bandwish, honestly i think a big majority of game doesnt require to use DMA to keep 60/50 FPS...

Quote:

---

Originally Posted by kool kitty89

The simplest workaround I've seen is to interleave DMA, not using DMA on every scanline in vblank. (thus only causing moderate amounts of missed writes in vblank, not a huge issue)

---

Unfortunately interleaving the DMA won't really help for Z80 driver which use cycle counting for timing instead of YM2612 timers.

Quote:

---

Originally Posted by kool kitty89

The simplest workaround I've seen is to interleave DMA, not using DMA on every scanline in vblank. (thus only causing moderate amounts of missed writes in vblank, not a huge issue)

---

Wouldn't it be easier to just break up DMA transfers into smaller pieces?

That said, in H40 mode you get like around 6 tiles per scanline while in H32 you get like around 5 tiles per scanline. So if you're transfering just sprite graphics, it's unlikely that any DMA transfer will be too long. You'll get some missed reads, but still not as bad.

Bear into mind this is more important for Z80-only engines than 68000+Z80 engines, since those have to read FM/PSG data *and* PCM at the same time. I know that for Echo to be stable you'd end up with at most 4 tiles per DMA. Let's be fair, if the Z80 had priority over the VDP for the 68000 bus this wouldn't be an issue -_-'

Quote:

---

Originally Posted by kool kitty89

If you did avoid DMA, and handled VRAM updates with the 68k, that would cut bandwidth by more than 1/2 for H40, but less than 1/2 for H32. (which means you could potentially copy more using the 68k in vblank than you could if you only DMA'd on every other scanline in vblank, in H32)

---

The fastest you can do is 8 CPU cycles per longword write (so ~4 CPU cycles per word) and that isn't very useful (it'd be something like move.l d0,(a0) so it's pretty limited in what you can do). That's less than 1/3 of DMA speed in H40. Your usual data transfer would be more like 12 CPU cycles per longword write (move.l (a0)+,(a1)), so that's more like 1/5 of DMA speed in H40.

DMA is much faster than the 68000, plain and simple.

Quote:

---

Originally Posted by Stef

Of course that imply a more complex Z80 driver but i think it really deserves it...

---

You say that 68000 interruption is what causes scratchiness, but if you make the Z80 process FM and PSG, what you gain from not halting the Z80 is wasted in processing everything else (and possibly the end result is worse).

Of course, there are other advantages to a Z80-only engine, like being easier to handle (since it doesn't mess with your game code), not relying on vblank speed (since it can afford to constantly poll the YM2612 timers) and not eating up 68000 time which could be used for other stuff.

Quote:

---

Originally Posted by Stef

Also about the VRAM limited bandwish, honestly i think a big majority of game doesnt require to use DMA to keep 60/50 FPS...

---

Look what I said about DMA speed above. DMA is much faster than the tightest 68000 loop =P

Quote:

---

Originally Posted by Stef

Unfortunately interleaving the DMA won't really help for Z80 driver which use cycle counting for timing instead of YM2612 timers.

---

And the YM2612 timers aren't much better, to be fair. At least they won't get unstable while they're counting, but they aren't accurate either. Since they don't loop, you need to restart them every time a tick is over, and since you have to poll them constantly, this means that every tick will have a different length. Ugh.

They're still useful if you need to count something but can't waste time waiting for the next tick and have to do other stuff.

Quote:

---

Originally Posted by Sik

Wouldn't it be easier to just break up DMA transfers into smaller pieces?

That said, in H40 mode you get like around 6 tiles per scanline while in H32 you get like around 5 tiles per scanline. So if you're transfering just sprite graphics, it's unlikely that any DMA transfer will be too long. You'll get some missed reads, but still not as bad.

Bear into mind this is more important for Z80-only engines than 68000+Z80 engines, since those have to read FM/PSG data *and* PCM at the same time. I know that for Echo to be stable you'd end up with at most 4 tiles per DMA. Let's be fair, if the Z80 had priority over the VDP for the 68000 bus this wouldn't be an issue -_-'

---

Bus priority settings for 68k/Z80/VDP would have been extremely useful. A "slow" DMA mode that interleaved with the 68k/Z80 (like the ST/Amiga interleaved DMA with 16-bit CPU bus latch) would also have been nice.

Quote:

---

The fastest you can do is 8 CPU cycles per longword write (so ~4 CPU cycles per word) and that isn't very useful (it'd be something like move.l d0,(a0) so it's pretty limited in what you can do). That's less than 1/3 of DMA speed in H40. Your usual data transfer would be more like 12 CPU cycles per longword write (move.l (a0)+,(a1)), so that's more like 1/5 of DMA speed in H40.

DMA is much faster than the 68000, plain and simple.

---

I also forgot VRAM is only 8-bits, so you'd need to do 8-bit writes with the 68k rather than 16-bits . . . (if the MD had the sort of freedom the PCE does for VRAM updates, that would be a bit different -still more 68k time to update things than DMA time could be, but much more flexibility of when you do those updates -ie not just in vblank . . . albeit, having fast DMA AND lack of contention for VRAM would have been even nice -especially with a slow, interleaved DMA mode)

Quote:

---

Originally Posted by kool kitty89

I also forgot VRAM is only 8-bits, so you'd need to do 8-bit writes with the 68k rather than 16-bits

---

It doesn't matter at all. The 68000 writes go to the FIFO (which has 16-bit words), and since the 68000 is writing slower than the amount of available access slots (in fact, it misses slots because it's so slow), ultimately the speed isn't affected.

Quote:

---

There are the YM2612 timers, but Sega oddly left the IRQ line on the YM disconnected. (though even with those timer interrupts, the YM timers don't loop, so you need to reset them after each interrupt -so more overhead and less consistent timing than looping timers)

---

Quote:

---

And the YM2612 timers aren't much better, to be fair. At least they won't get unstable while they're counting, but they aren't accurate either. Since they don't loop, you need to restart them every time a tick is over, and since you have to poll them constantly, this means that every tick will have a different length. Ugh.

---

Just for the record, FM timers DO loop when they overflow.

Sega most likely preferred the Z80 to be synchronized with main game loop (VSYNC) rather than FM timers, because accurate digital samples were not so important at the time it was designed. It was only later that games started promoting "realistic" voices or sfx, then digital samples became the norm so we feel like complaining about this aspect but the Genesis was really designed around FM synth.

Quote:

---

Originally Posted by Eke-Eke

Just for the record, FM timers DO loop when they overflow.

---

Is there any way to reset a timer flag without stopping the timer? (serious question) And yes, I want to know what combination of LOAD/ENABLE/RESET bits would do the trick =P

EDIT: wait, now I remember why that was useless, the timers don't loop properly, they just overflow, so I wouldn't get the same tick length as the initial settings =/ (or am I wrong here?)