Quantcast

Page 3 of 5 FirstFirst 12345 LastLast
Results 31 to 45 of 63

Thread: Emotion Engine VS Hitachi SH5

  1. #31
    Nameless One SonicTheHedgehog's Avatar
    Join Date
    Aug 2011
    Location
    Cardiff, Wales
    Age
    37
    Posts
    80
    Rep Power
    11

    Default

    Quote Originally Posted by kool kitty89 View Post
    I think it was thoroughly addressed earlier that you wouldn't need to go nearly that far to make a competitive CG-class version of the DC . . . just an up-clocked DC with expanded RAM would have been enough for most/all respects. (or if not truly GC class performance, still reasonably close -with some advantages- and generally good cost effectiveness)
    Plus, the original context was matching the EE, not the Gekko.

    Boosting the SH2 to 266 MHz, main RAM to 32 MB at 133 MHz, video RAM to 133 or 166 MHz (still 8 MB), and the GPU clocked to match that bus speed. (and perhaps a boost in sound RAM too)

    The SH5 didn't actually improve clock per clock performance over the SH4 in terms of normal integer/floating point performance, though it was available at higher clock speeds (400 MHz) then standard SH4 models and had a larger cache (so potential real-world performance gains there) . . . but the SH4 itself was available at 266 MHz by the time the SH5 was released anyway (let alone in volume production), and if more than 266 MHz was really felt necessary, Sega may have been able to negotiate a special speed grade for the DC specifically. (with Sega's relationship with Hitachi, the volumes the DC would be ordered in, and the fact that such SH4 production wouldn't have the normal conflicts of interest with SH5 sales/marketing should have made that a fairly realistic proposition for the time)

    An up-clocked derivative of the PowerVR 2 GPU may have been reasonable too, and should have been a much cheaper option than PVR3. Or, if they did go with PVR3, it would probably make more sense to use a custom/modified version of that with a 64-bit external bus to keep cost down. (keeping GPU pin count down as well as RAM chip pins and motherboard traces needed for a 128-bit bus)
    A 166 MHz version of the PVR2 would have been the best option if possible/practical to manage.


    Hardware T&L was nice (and did become the standard for future GPUs), but was hardly necessary for competent performance . . . especially since the DC virtually already had hardware T&L built into the CPU ASIC (in the form of the vector coprocessor).

    Hardware T&L offloads more overhead that would otherwise fall on the CPU to perform . . . the PSX and 3DO already did part of that "in hardware" (via dedicated matrix coprocessors handling 3D transformation/vertex calculations) and the N64 and Jaguar did it all "in hardware" via the GPU and RSP. (technically still done in software since it wasn't hard-wired logic . . . but that's generally also the case for modern GPUs with T&L support -and more recently handling physics calculations and such too)

    So, if you already have a system that handles T&L very efficiently in software (or "hardware" separate from the GPU itself), there isn't much argument for hardware T&L at all. (for that matter, PCs themselves could have continued relying on CPU based T&L calculations, and rather than GPUs extending that support, CPU designs may have incorporated instruction extensions and coprocessing logic oriented towards graphics acceleration assist . . . which consoles had more or less been doing to some degree already and PC CPUs had as well to some degree with increasing emphasis on FPU performance and multimedia extensions -MMX, 3DNow!, SSE, etc- )

    And, for that matter, some APIs took quite a while to even support hardware T&L properly (DirectX in particular lagged a fair bit there), so it took even longer to gain popular support on the software end.


    As to the separate matter of actual support being dropped for PowerVR . . . that's not something that should have really hurt Sega either, since they'd have their own software/tool support to maintain. Granted, it would also be nice to have established 3rd party support for newer revisions of standard APIs in addition to Sega's own tools. (especially OpenGL and DirectX which were becoming the defacto standards at that point)



    Though, if Sega did opt to partner/license with another graphics hardware company, the best option probably would have been ATi with their fairly broad/flexible array of designs and tendency towards more flexible licensing terms than Nvidia. (one of the pitfalls of the Xbox in hindsight that limited potential cost reduction/consolidation of the chipset -and the system itself had fairly considerable potential for cost reduction/consolidation with the unified/shared system bus)
    3DFX didn't really fare much/any better than PowerVR in terms of longevity/support on the market, and PowerVR had better low-cost/embedded options for the time.

    So in that respect, Sega's options for a system aimed at ~2000 would either have been one of the late gen RAGE chips or maybe an early Radeon. (though the latter probably would have been a pretty major addition to cost while the former wouldn't have been that big of an advantage over PowerVR -or even at a disadvantage depending on the specific GPUs being compared, at least in terms of raw performance rather than software/API support)

    Also, don't just go by wiki's lists of API support . . . they're a bit vague (though not necessarily inaccurate -more of a contextual issue). In particular, looking at the GPU lists, it appears that the API support listed is for at/around the time of release for those chipsets rather than the latest supported release. (many RAGE cards have drivers supporting up to DirectX-8, not sure about PowerVR or Voodoo cards though)

    And, of course, discontinuation of production of a card/GPU doesn't "cut-off" its software support. (you often see additional patches/drivers/updates years after the fact, especially for more popular cards/GPUs -in some cases, to the point of getting homebrew/3rd party legacy support beyond that of the original manufacturer)
    Yeah i guess after thinking about it, if Sega wanted DVD playback built in and wanted to sell at a profit then a higher clocked version of the DC with more memory would of been the best way to go. But couldn't the SH4 actually be clocked all the way up to 299mhz? Im sure i heard somewhere it could. That would of equalled the clock rate of the emotion engine although i'm aware that clockrate doesn't mean superior chip.

  2. #32
    I remain nonsequitur Shining Hero sheath's Avatar
    Join Date
    Jul 2010
    Location
    Texas
    Age
    44
    Posts
    13,313
    Rep Power
    132

    Default

    Since both processors depend on other chips to do the lions share of the game related processing, I'm not sure what the clock rates have to do with anything. Also, I persist that a $300-350 Dreamcast at US launch with DVD functionality would have flopped big time. The $200 price tag coupled with the amazing next generation graphics and gameplay made the Dreamcast irresistible early on.

    Jack the price up and Sony could have added another myth to their PS2 hype engine by claiming that it'll be the same price while being able to render individual grains of wood in a door and jack you into The Matrix.
    "... If Sony reduced the price of the Playstation, Sega would have to follow suit in order to stay competitive, but Saturn's high manufacturing cost would then translate into huge losses for the company." p170 Revolutionaries at Sony.

    "We ... put Sega out of the hardware business ..." Peter Dille senior vice president of marketing at Sony Computer Entertainment

  3. #33
    Road Rasher
    Join Date
    Apr 2011
    Posts
    469
    Rep Power
    25

    Default

    A nominal bump in processor and ram speed would be acceptable, if small performance boosts, in line with keeping the DC chipset cheap and competitive. But then the issue is whether you could get enough parts at higher rated speeds, you must remember the custom SH-4 in the dreamcast was an already marginal bump in speed from the original reference design which was rated around 166 MHz (don't quote me on that), Hitachi also customised it by adding the 3D math vector instructions for the SH-4's geometry engine. Sega couldn't wait on manufacturing delays if yields weren't high enough, seeing some examples of modded dreamcasts with bumped up processors doesn't mean all SH-4's where capable of higher speeds, nor that a standard and quiet cooling system would be robust enough.

    Really the best and most viable option to bump the DC's architecture would be the Élan T+L chip, and an increase in ram speed and amount. Less burden on the main cpu with T+L handled by the Élan, with more ram for game data and on the GPU VRM side space for more textures, the display buffer and more breathing room for poly counts. The more polys transformed and displayed the more it ate into GPU VRAM.

    That could have been a very competitive system with the PS2 and provided ram prices kept dropping, cheap also provided the Élan wasn't too expensive (no doubt it probably was!). Of course I imagine this would fit more in with a 1999/2000 timeframe of release. But the stakes where too high, and upper Sega management where already desperate to move on from the Saturn, you'd really need to have a competitive Saturn to give the Dreamcast any more leverage in the market place. I think we should all be thankful the Dreamcast competed as well as it did in such tough market circumstances, but Sega really needed to be healthier for the the DC to go further.
    Last edited by TVC 15; 11-17-2011 at 03:44 PM.

  4. #34
    ESWAT Veteran Chilly Willy's Avatar
    Join Date
    Feb 2009
    Posts
    6,744
    Rep Power
    79

    Default

    Perhaps the worst comparison between the DC and PS2 is the sound: while on the surface, they SEEM fairly even - 2MB sound ram each, 48 channels for the PS2 vs 64 for DC, and a 36 MHz R3000 on the PS2 vs a 25 MHz ARM on the DC - the sound processors are woefully lopsided. While the 36 MHz R3000 easily handles mp3 or ogg decoding, testing shows the ARM only gets enough bus access cycles to sustain perhaps 3 MIPS of processing power, which can't do more than simple note handling for tracker style music. The ARM chip doesn't have caches or divide instructions, and only the oldest, least useful multiply instruction. It's completely worthless in decoding (or even helping decode) mp3 or ogg.

  5. #35
    I remain nonsequitur Shining Hero sheath's Avatar
    Join Date
    Jul 2010
    Location
    Texas
    Age
    44
    Posts
    13,313
    Rep Power
    132

    Default

    Hmm, I was under the impression that a number of Dreamcast games were playing music straight from the sound chips rather than as tracks off the GD-ROM. I couldn't confirm it but it was intimated that Crazy Taxi and the Sonic Adventure games were playing sampled music straight from the audio system.
    "... If Sony reduced the price of the Playstation, Sega would have to follow suit in order to stay competitive, but Saturn's high manufacturing cost would then translate into huge losses for the company." p170 Revolutionaries at Sony.

    "We ... put Sega out of the hardware business ..." Peter Dille senior vice president of marketing at Sony Computer Entertainment

  6. #36
    ESWAT Veteran Chilly Willy's Avatar
    Join Date
    Feb 2009
    Posts
    6,744
    Rep Power
    79

    Default

    Quote Originally Posted by sheath View Post
    Hmm, I was under the impression that a number of Dreamcast games were playing music straight from the sound chips rather than as tracks off the GD-ROM. I couldn't confirm it but it was intimated that Crazy Taxi and the Sonic Adventure games were playing sampled music straight from the audio system.
    Probably, but that doesn't mean ogg or mp3. It's probably ADPCM. Depending on the size of the samples, they could even be plain PCM. Think of it like the enhanced music off the CD for Pier Solar. It's not CDDA, but better than synthesized/tracker music.

  7. #37
    Road Rasher
    Join Date
    Apr 2011
    Posts
    469
    Rep Power
    25

    Default

    Quote Originally Posted by Chilly Willy View Post
    Perhaps the worst comparison between the DC and PS2 is the sound: while on the surface, they SEEM fairly even - 2MB sound ram each, 48 channels for the PS2 vs 64 for DC, and a 36 MHz R3000 on the PS2 vs a 25 MHz ARM on the DC - the sound processors are woefully lopsided. While the 36 MHz R3000 easily handles mp3 or ogg decoding, testing shows the ARM only gets enough bus access cycles to sustain perhaps 3 MIPS of processing power, which can't do more than simple note handling for tracker style music. The ARM chip doesn't have caches or divide instructions, and only the oldest, least useful multiply instruction. It's completely worthless in decoding (or even helping decode) mp3 or ogg.
    I was always under the impression the Yamaha ASIC was quite powerful, particularly after reading quite a bullish PR Statement from Yamaha, the original doc isnt up on the net anymore but I've found a forum post in a dreamcast thread where a user posted some of its contents.

    http://dcemulation.org/phpBB/viewtopic.php?p=241423

    I was also under the impression the ARM7 was rated at 45MHz at 40 mips, but thats probably the DSP not the Arm7, the press statement even suggests the ARM7 was faster than one of the Saturns SH-2. On further reading the ARM7 actually used in the ASIC lacks a cache and is only rated at 25Mhz.

    In fact there's a qoute further down in that link from one of the Bleem coders...

    Oh, and it's not an ARM7TDMI -- there's no Thumb and there's no Multiplier logic... there *may* be the Debug logic, but I'm not sure
    So just as useless as that paltry 68EC00 in the Saturn, well at least the Saturn had a second SH-2 and the DSP to help if there was any spare cycles free on decoding compressed Sound samples.

    Man thats depressing.

  8. #38
    I remain nonsequitur Shining Hero sheath's Avatar
    Join Date
    Jul 2010
    Location
    Texas
    Age
    44
    Posts
    13,313
    Rep Power
    132

    Default

    Quote Originally Posted by Chilly Willy View Post
    Probably, but that doesn't mean ogg or mp3. It's probably ADPCM. Depending on the size of the samples, they could even be plain PCM. Think of it like the enhanced music off the CD for Pier Solar. It's not CDDA, but better than synthesized/tracker music.
    Hmm, now that you mention it I do recall it being referred to as ADPCM, but this was on some website back in the day so who knows what they knew besides nothing.
    "... If Sony reduced the price of the Playstation, Sega would have to follow suit in order to stay competitive, but Saturn's high manufacturing cost would then translate into huge losses for the company." p170 Revolutionaries at Sony.

    "We ... put Sega out of the hardware business ..." Peter Dille senior vice president of marketing at Sony Computer Entertainment

  9. #39
    Hero of Algol TrekkiesUnite118's Avatar
    Join Date
    May 2010
    Age
    33
    Posts
    8,327
    Rep Power
    137

    Default

    Didn't most Dreamcast games use ADX for sound? I know thats even carried over into a lot of Sega's post Dreamcast games on the PS2 and PC. Phantasy Star Universe on PC, PS2, and I'm pretty sure 360 uses ADX encoding for music and some sound effects/voices. The rest are either 16 bit PCM (PC/360), or ADPCM for PS2. Which is really weird considering PSO:BB on the PC used ogg files for music and most sound effects.

  10. #40
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    32
    Posts
    9,725
    Rep Power
    65

    Default

    Quote Originally Posted by sheath View Post
    It has been a while since I made those comments, but I think the context was in response to Sega waiting until the PVR3 was cost effective and using that instead. The only reason I mentioned hardware transform and lighting and the decline of Power VR PC graphics cards was to point out that if Sega had even a year they likely would have been looking at N-Vidia or Ati instead.
    It should have been more of an issue of cost (both manufacturing cost and licensing fees) vs performance more than anything else . . . though obviously good API support would have been necessary (something the PVR chipset already had with the DC).

    ATi or Nvidia being more relevant on the mass/consumer market has relatively little to do with that . . . and the extreme example would be a totally custom in-house design rather than outsourcing/licensing at all. (but by that time, it was obvious that outsourcing was generally more cost effective, especially short of having an extremely talented and efficient in-house R&D team with skills and experience suited to 3D GPU design for low-cost embedded systems -so if they did go custom at all, it still probably would have been largely outsourced R&D -this was due to their being many, established R&D companies that catered to such design work, something not true a decade earlier)

    As such, if Sega did consider using an ATi part, they might be more attracted to one of the simpler/cheaper/older RAGE line of GPUs over the new Radeon line. (more so since ATi also had some specific RAGE models that had been cost-reduced/consolidated and better suited for embedded systems)

    Of course, if we're talking a 2001 console release, yeah, probably more towards the Radeon class GPUs. (and probably using a bare-bones SH4 rather than the custom ASIC with the vector unit -since the GPU would be handling T&L)



    Quote Originally Posted by SonicTheHedgehog View Post
    Yeah i guess after thinking about it, if Sega wanted DVD playback built in and wanted to sell at a profit then a higher clocked version of the DC with more memory would of been the best way to go. But couldn't the SH4 actually be clocked all the way up to 299mhz? Im sure i heard somewhere it could. That would of equalled the clock rate of the emotion engine although i'm aware that clockrate doesn't mean superior chip.
    By 2001 (or perhaps slightly earlier), it shouldn't have been unreasonable to have a 400 MHz SH4, but the question would be if the price would have been right for Sega, especially as a custom part. (the DC's CPU ASIC was already custom, but still at a clock speed offered for standard SH4s in 1998 . . . and from what I can gather, Hitachi only offered the SH4 up to 266 MHz in 2001, though the new SH5 was offered at 400 MHz -with similar clock-per-clock performance as the SH4, but an expanded cache and some other added features, which would have been unnecessary for Sega's needs)
    Plus, even if the SH5 itself was a reasonable price, it wasn't available in quantity soon enough to make a 2000/2001 release date . . . unless bulk orders from Sega changed that. (but, in any case, a simpler speed-boosted SH4 would have been more realistic, certainly a 266 MHz part if not faster)

    There's also the issue of the bus speed: commodity SDRAM maxed out at 133 MHz (somewhat higher end 166 MHz stuff was usually relegated to graphics applications and such -and still considerably cheaper than DDR), and I'm not sure the SH4 supported fractional clock multipliers. (if it didn't, that would mean 266 or 400 MHz would have been the only realistic options with a 133 MHz bus)

    On top of that, clocking the CPU faster can only do so much within other system limitations. Obviously there's the graphics resource limitations, but in terms of the CPU itself, there's also I/O and memory bandwidth bottlenecks that make performance gains of higher clock speeds less significant. (some operations will be faster, but some will always be limited by external bus bandwidth)
    That's also why the note for boosting the main bus to 133 MHz is so significant. (as such, a 266 MHz SH4 on a 133 MHz bus would have significant advantages over a 300 MHz SH4 on a 100 MHz bus)


    As for DVD playback, no that would have been too costly, and would have been counter-productive for generating profits on hardware. (if they wanted profits sooner, it would have been more sensible to make the modem a separate peripheral -at least on low-end bundles- and wait longer to drop the price -especially since the DC's launch price was already substantially lower than the PS2's, so the further price drops didn't accomplish much -IMO, that money would have been better spent on boosted advertising/hype, or simply not spent at all in favor of increased financial stability . . . being selectively conservative in spending could have gone a long way)

    Albeit, in the context of a 2001 release, off the shelf DVD-ROM drives were getting more realistic in price, so perhaps that would have made sense over GD-ROM. (albeit not DVD video playback, since that requires additional licensing/royalties -though Sega could have done like MS and tacked that licensing overhead onto a simple peripheral)





    Quote Originally Posted by sheath View Post
    Since both processors depend on other chips to do the lions share of the game related processing, I'm not sure what the clock rates have to do with anything.
    No, the CPU performance is always significant . . . the GPU isn't going to help with game logic/AI/physics/etc. (and even if it could, that would mean contending for graphics bandwidth/computational resource to do so)

    The slower CPU of the DC was indeed a liability as much as the graphics performance. (if not more than graphics in some cases)

    CPU resource is only unimportant in graphics demos, and even then only if the graphics subsystem isn't relying on CPU resource. (ie not like early 3D cards requiring the CPU to handle the 3D math)

    Also, I persist that a $300-350 Dreamcast at US launch with DVD functionality would have flopped big time. The $200 price tag coupled with the amazing next generation graphics and gameplay made the Dreamcast irresistible early on.
    Yes, DVD would have been impractical in 1999 and probably 2000, though a $200 system with DVD in 2001 (or 2000 in Japan) should have been quite realistic. (after all, Nintendo did it . . . and their proprietary/custom drives actually probably added costs over cheap/mass-market DVD mechanisms -they still would have had to pay royalties for patent holders in either case)
    Note: this was in the previously mentioned context of Sega being more successful in the previous generation (for whatever reason) and thus waiting longer to release their next-gen console.

    And again, they could do like MS and pass the DVD video license overhead to an optional peripheral.

    For 1998/1999 though, GD-ROM was a brilliant solution for low-cost drives/media at much higher capacity than normal CD-ROM. (and perhaps with potential to push that a bit further than the ~1.2 GB discs initially used -obviously not to DVD levels, but perhaps closer to 2 GB)






    Quote Originally Posted by TVC 15 View Post
    A nominal bump in processor and ram speed would be acceptable, if small performance boosts, in line with keeping the DC chipset cheap and competitive. But then the issue is whether you could get enough parts at higher rated speeds, you must remember the custom SH-4 in the dreamcast was an already marginal bump in speed from the original reference design which was rated around 166 MHz (don't quote me on that), Hitachi also customised it by adding the 3D math vector instructions for the SH-4's geometry engine. Sega couldn't wait on manufacturing delays if yields weren't high enough, seeing some examples of modded dreamcasts with bumped up processors doesn't mean all SH-4's where capable of higher speeds, nor that a standard and quiet cooling system would be robust enough.
    Yes, but we were talking about a machine planned for release some 2-3 years later than the DC's 1998 launch in Japan. (though, if an up-clocked PVR2 chipset wasn't available, PVR3 very well may have been more realistic . . . if not a GPU from another company) A 133-166 MHz CLX1/PMX1 derivative would have been great, but a PVR3 chip may have been more practical depending on the circumstances. (if they DID go for a PVR3 chip -or another 128-bit bus GPU for that matter- it may have made more sense to use a slightly customized derivative that used a 64-bit external bus -to significantly cut cost of pins/traces on the GPU ASIC, RAM chips, DRAM controller, and motherboard- . . . then Again, by early 2001, the PowerVR 4 chipset was released with a 64-bit bus -though using DDR . . . not that it should have been impractical to switch to slower/cheaper SDRAM)

    Though on the issue of CPU speed, 166 MHz was only the early introductory speed and 200 MHz SH4s were available at the same time as Sega was getting their custom 200 MHz CPU ASIC. (I'm also pretty sure the vector coprocessing logic was a Hitachi design that had been in development since the mid 90s, it's mentioned here: http://www.hotchips.org/archives/hc7/index.htm as "150MHz Superscalar RISC Processor with Pseudo Vector Processing Feature" -not the SH4 itself wasn't presented in those conferences until 1997, at least within those archives)

    An up-clocked SH4 should definitely have been practical for 2000 . . . at very least a 266 MHz part (which was available off the shelf) if not a special higher speed rating. (like the 400 MHz of the introductory SH5 -so more a target for a hypothetical 2001 DC)

    Really the best and most viable option to bump the DC's architecture would be the Élan T+L chip, and an increase in ram speed and amount. Less burden on the main cpu with T+L handled by the Élan, with more ram for game data and on the GPU VRM side space for more textures, the display buffer and more breathing room for poly counts. The more polys transformed and displayed the more it ate into GPU VRAM.
    Which Élan chip (the one used in early/mid 90s SGI workstations)?

    That would seem a rather odd choice compared to other GPUs available. (ie one of ATI or Nvidia's chips with hardware T&L available in 2000 or a faster CPU/coprocessor coupled with another GPU without T&L support)

    Hell, it also probably would have been cheaper to dedicate a 2nd SH-CPU/DSP as the T&L coprocessor.






    Quote Originally Posted by Chilly Willy View Post
    Perhaps the worst comparison between the DC and PS2 is the sound: while on the surface, they SEEM fairly even - 2MB sound ram each, 48 channels for the PS2 vs 64 for DC, and a 36 MHz R3000 on the PS2 vs a 25 MHz ARM on the DC - the sound processors are woefully lopsided. While the 36 MHz R3000 easily handles mp3 or ogg decoding, testing shows the ARM only gets enough bus access cycles to sustain perhaps 3 MIPS of processing power, which can't do more than simple note handling for tracker style music. The ARM chip doesn't have caches or divide instructions, and only the oldest, least useful multiply instruction. It's completely worthless in decoding (or even helping decode) mp3 or ogg.
    Huh, that's odd . . . and I guess that also means the quoted "45 MHz ARM7" and "66 MHz SDRAM" for audio are incorrect. (and would imply that it's not a normal ARM7 either, but a special cacheless MCU derivative)

    That makes me wonder even more why an SH2 wasn't used instead . . . or if they did want a basic/cheap MCU, an SH1 derivative instead. (given their relationship with Hitachi)

    But a fast SH2 with decent enough RAM for reasonable performance (PC-66 SDRAM coupled with a 66 MHz SH2 would have been awesome for the time, though something more modest also would have made lots of sense), especially with the expense put into the sound processor itself. (in that respect, it may have even made more sense to cut-down the sound chip considerably, and instead use a simple DMA PCM buffer -or several hardware PCM channels- and a fast CPU/MCU doing all decompression/mixing/synthesis/effects in software -in which case, that 66 MHz SDRAM+66 MHz SH2 idea sounds pretty realistic . . . or perhaps an SH-DSP or DSP+MCU for that matter -especially a highly integrated sound ASIC combining an SH-MCU, SH-DSP, and DMA/PCM/DAC hardware)
    Or an SH3/SH3DSP if they wanted even higher performance.

    The DC's sound chip did have a powerful DSP embedded in it, but like the Saturn it was limited only to manipulating the output, not doing additional work on the input end. (so no acceleration of decompression/mixing/etc) Otherwise the Saturn's sound system may have been totally superior to the PSX's as well.


    Quote Originally Posted by Chilly Willy View Post
    Probably, but that doesn't mean ogg or mp3. It's probably ADPCM. Depending on the size of the samples, they could even be plain PCM. Think of it like the enhanced music off the CD for Pier Solar. It's not CDDA, but better than synthesized/tracker music.
    Yes, like quite a few Saturn and PSX games did too.






    [QUOTE=TVC 15;424934]I was always under the impression the Yamaha ASIC was quite powerful, particularly after reading quite a bullish PR Statement from Yamaha, the original doc isnt up on the net anymore but I've found a forum post in a dreamcast thread where a user posted some of its contents.

    I was also under the impression the ARM7 was rated at 45MHz at 40 mips, but thats probably the DSP not the Arm7, the press statement even suggests the ARM7 was faster than one of the Saturns SH-2. On further reading the ARM7 actually used in the ASIC lacks a cache and is only rated at 25Mhz.
    I assume Chilly Willy has looked further into this. (in previous discussions I recall him making comments more directly based off those press-release "specs")

    A 25 MHz ARM7 CPU would be much more powerful than 3 MIPS . . . but an ARM7 based MCU with no cache and a slow external bus (presumably the 66 MHz quote is also inaccurate) could indeed be heavily crippled as such.

    As to the power of the Yamaha ASIC: like the Saturn's SCSP, it's more impressive as a music synthesizer and far less impressive as a general-purpose sound coprocessor. It has a powerful DSP, but (like the SCSP) it's only available in a very limited role (ie not useful for general sound coprocessing), so much of that power goes to waste when not being used for the specific limited tasks it was designed for. (ie music synthesis)

    Unlike the SCSP, it did at least support hardware ADPCM decoding and doubled the number of sound channels . . . and also dropped the little-used FM synth modes for the PCM oscillators.

    So just as useless as that paltry 68EC00 in the Saturn, well at least the Saturn had a second SH-2 and the DSP to help if there was any spare cycles free on decoding compressed Sound samples.
    Yes . . . and if you mean the SCU DSP, yes as well. (the SCSP's DSP is not useful for sound coprocessing in that sense though) Albeit, I'm not sure if any developers actually used the SCU DSP for that purpose.

    Again, it seems like Sega went overboard with a very specifically powerful/advanced sound/music synthesis system that lacked many useful general-purpose features, and thus greatly degraded the overall value of the system . . . and did so twice at that. (in both the Saturn and DC's cases, using a simpler, general-purpose audio coprocessing set-up with fast CPU, MCU+DSP, or similar along with simple DMA PCM sound output would have been far, far more useful . . . plus, for games with relatively simple sound engines, you'd also get extra coprocessing resource for other tasks -or, alternatively, have the main CPU -perhaps coupled with other coprocessors- handle all the sound processing in general, mixing to simple DMA PCM output -like the 32x and N64 . . . or somewhat like the Jaguar for that matter, and obviously onboard sound for PCs -not sure if the Xbox takes that route, or if it has a dedicated sound processor)
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  11. #41
    ESWAT Veteran Chilly Willy's Avatar
    Join Date
    Feb 2009
    Posts
    6,744
    Rep Power
    79

    Default

    Quote Originally Posted by kool kitty89 View Post
    Huh, that's odd . . . and I guess that also means the quoted "45 MHz ARM7" and "66 MHz SDRAM" for audio are incorrect. (and would imply that it's not a normal ARM7 either, but a special cacheless MCU derivative)
    Yeah, I got into a discussion about this over at dcemulation, and it turns out that "45 MHz ARM7" is actually a 22.5 MHz ARM7DI... which is a rather wimpy processor. It wouldn't be nearly so bad if it had full access to the ram, but it apparently doesn't. In the end, it's barely better than the 68000 in the Saturn.

    EDIT: If you check out the ARM7DI datasheet, the maximum clock is about 23.8 MHz. The 45 MHz probably came from someone reporting a 45 MHz crystal in the sound circuit without realizing it would need to be cut in half to fit the processor used.


    Quote Originally Posted by TVC 15 View Post
    I was always under the impression the Yamaha ASIC was quite powerful, particularly after reading quite a bullish PR Statement from Yamaha, the original doc isnt up on the net anymore but I've found a forum post in a dreamcast thread where a user posted some of its contents.
    I assume Chilly Willy has looked further into this. (in previous discussions I recall him making comments more directly based off those press-release "specs")

    A 25 MHz ARM7 CPU would be much more powerful than 3 MIPS . . . but an ARM7 based MCU with no cache and a slow external bus (presumably the 66 MHz quote is also inaccurate) could indeed be heavily crippled as such.
    Yes, I did. I was interested in moving my MIDI playing code to the ARM for my Doom port, and maybe adding ogg support since with the published specs, it should handle that no problem. Here's a link where the discussion was, with other links to info on the subject:

    http://dcemulation.org/phpBB/viewtop...27120#p1027120


    As to the power of the Yamaha ASIC: like the Saturn's SCSP, it's more impressive as a music synthesizer and far less impressive as a general-purpose sound coprocessor. It has a powerful DSP, but (like the SCSP) it's only available in a very limited role (ie not useful for general sound coprocessing), so much of that power goes to waste when not being used for the specific limited tasks it was designed for. (ie music synthesis)

    Unlike the SCSP, it did at least support hardware ADPCM decoding and doubled the number of sound channels . . . and also dropped the little-used FM synth modes for the PCM oscillators.
    Yeah, given the processor was barely better than the 68000 in the SCSP, it's good that they added the other features.
    Last edited by Chilly Willy; 11-17-2011 at 09:45 PM.

  12. #42
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    32
    Posts
    9,725
    Rep Power
    65

    Default

    Quote Originally Posted by Chilly Willy View Post
    Yeah, given the processor was barely better than the 68000 in the SCSP, it's good that they added the other features.
    Still odd that they (apparently) felt that having a DSP on the output end was important to have, yet they heavily limited MPU/DSP resource on the external/input end of the sound system. (the same trade-offs made with the Saturn's sound system . . . except a bit more extreme given the later timeframe)

    Making that mistake with the Saturn would be fairly understandable (defacto standards/common use of audio not being as definitively established), but doing the same thing with the DC is a bit harder to understand. (and even in the Saturn's case with the design being developed in the early 90s -presumably in the 1992~93 timeframe- it would have been fairly obvious that sample based sound was becoming common, and mostly with limited use of "extra" features -like envelopes, filtering, etc- and very limited use of additive/subtractive/wavetable/etc synth methods as well as FM . . . with most popular examples being fairly simple MOD style trackers -with sample compression being the most significant added feature, probably interpolation/filtering after that . . . and the compression support was obviously significant for SFX too, and for streaming audio clips/tracks too)



    Hmm, actually, with the SCU DSP applied to audio coprocessing (to complement the 68k), the DC may actually have been at a disadvantage compared to the Saturn for some things. (aside from resorting to main CPU resource)
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  13. #43
    ESWAT Veteran Team Andromeda's Avatar
    Join Date
    Jul 2010
    Location
    Wales, UK
    Posts
    6,538
    Rep Power
    76

    Default

    Quote Originally Posted by TrekkiesUnite118 View Post
    Didn't most Dreamcast games use ADX for sound? I know thats even carried over into a lot of Sega's post Dreamcast games on the PS2 and PC. Phantasy Star Universe on PC, PS2, and I'm pretty sure 360 uses ADX encoding for music and some sound effects/voices. The rest are either 16 bit PCM (PC/360), or ADPCM for PS2. Which is really weird considering PSO:BB on the PC used ogg files for music and most sound effects.
    yes almost all did and ADX only needed to use 1% of the SH4. ADX was some dame fine middleware by CRI
    Panzer Dragoon Zwei is
    one of the best 3D shooting games available
    Presented for your pleasure

  14. #44
    I DON'T LIKE POKEMON Hero of Algol j_factor's Avatar
    Join Date
    Jun 2005
    Location
    NorCal
    Posts
    9,328
    Rep Power
    132

    Default

    Quote Originally Posted by Chilly Willy View Post
    Perhaps the worst comparison between the DC and PS2 is the sound: while on the surface, they SEEM fairly even - 2MB sound ram each, 48 channels for the PS2 vs 64 for DC, and a 36 MHz R3000 on the PS2 vs a 25 MHz ARM on the DC - the sound processors are woefully lopsided. While the 36 MHz R3000 easily handles mp3 or ogg decoding, testing shows the ARM only gets enough bus access cycles to sustain perhaps 3 MIPS of processing power, which can't do more than simple note handling for tracker style music. The ARM chip doesn't have caches or divide instructions, and only the oldest, least useful multiply instruction. It's completely worthless in decoding (or even helping decode) mp3 or ogg.
    The homebrew release "Tetris 2" allows you to use your own MP3 files as in-game music. Does it simply ignore the sound processor and use the main CPU?


    You just can't handle my jawusumness responces.

  15. #45
    ESWAT Veteran Chilly Willy's Avatar
    Join Date
    Feb 2009
    Posts
    6,744
    Rep Power
    79

    Default

    Quote Originally Posted by j_factor View Post
    The homebrew release "Tetris 2" allows you to use your own MP3 files as in-game music. Does it simply ignore the sound processor and use the main CPU?
    Yes. All mp3/ogg decoding done on the DC is done by the SH4. You would expect that for "early" homebrew as people wouldn't know how to use extra resources, like the ARM, but as developers learned more about the ARM in an effort to move the work to it, they learned that would not be possible.

    My port of Doom to the DC uses libWildMidi running on the SH4 to generate the music. This takes only a very little percentage of the main CPU's time, but at some point you feel the need to make things run as fast as possible, so you look into things like changing who is responsible for playing the music. So I started looking into moving libWildMidi over to the ARM, and that's when I stumbled onto the info I linked to above.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •