Would you play Resident Evil on the jag?

[kool kitty89]

Yeah what LinkoVitch said. Anyone know if this game uses mostly the 68k? That could help explain it if it does.

 

Not necessarily. 68K usage does not automagically equal shit capabilities or performance. You'd be amazed at what you can accomplish with just the 68K driving the custom chips...

The 68k is certainly a bottleneck that limits the potential of the hardware, but using it for most/all of the game logic/AI/etc still doesn't render the system useless. (and even games supposedly using the crappy GPU compiler like Club Drive look far better)

The Flare engineers certainly intended it to be used heavily, just like they'd intended the Z80 in the Flare 1 or 8088 in the Slipstream. (granted, there were no other options in that chipset whereas in the Jaguar, Flare made the GPU's RISC core flexible enough to be pressed into the role of a real CPU)

 

The slow bus accesses is the worst hit to the system; it was those slow accesses that older/slow systems like the Amiga or Megadrive took advantage of to allow interleaved accesses on the 68k bus, but with the Jaguar, the bus is much faster and more efficient using fast page mode and thus serial bus accesses are most efficient to avoid page beaks. (plus a 13.3 MHz 68k is too fast to interleave DRAM accesses with anyway)

Though if they'd added a separate 16-bit (or wider) bank of RAM in the Jag, they could have used the 2-bank interleaving feature that could keep both banks in fast page mode with concurrent accesses, even better if they implemented Amiga-like interleaving in conjunction with the dual banks. (with fast page mode interleaving, you should have fast enough accesses to allow the 68k to run full bore and still allow 50% fast page bandwidth for TOM working in the 64-bit bank -having a 2nd bank also would have meant JERRY could spend more time in that 16-bit bank with the 68k and put much less of a hit on TOM -texture mapping speed would also be more than doubled as the blitter could use the 2 banks for source and destination and keep in fast page mode)

 

It's a shame there weren't 26.6 MHz rated 68ks on the mass market, let alone 40 MHz. A faster 68k would have been a big help too. (and should still have been cheaper than most other options, at least if it was a commodity mass-market product -68EC020s were not openly licensed and only produced by Motorola, plus used a lot more silicon and a higher pin count, lower-end ARM CPUs probably would have been more expensive too though the ARM2as may have been a viable option, 386SXs would have been more expensive to manufacture than 68EC020s due to the larger amount of silicon but maybe the more competitive/higher volume market would have made those more favorable -Cyrix's 486SLC also added a 1k cache, so much better still for the Jaguar, IBM's 386SLC had 8k but with restricted production contracts and would have been more expensive to manufacture than Cyrix's CPU core anyway)

It would be cool to find some mass market pricing information on lower-end CPUs of the time to see what sort of options Atari had.

 

Of course, they also could have added a 2nd bus for the CPU (probably better to have JERRY in that too), but that was contrary to the single-bus design emphasis of the Jaguar.

 

 

For that matter the 'action' parts of Highlander look like they could have been written better on unexpanded 68K computers like the ST or Amiga.

Yeah, that's what I noted earlier. It's almost like they didn't use the GPU (RISC) at all and just had the 68k do all the 3D math as well. (probably at least used the blitter for line filling)

And, on top of that, used less than tight code to manage all of that. (ie tight code on a 13.3 MHz 68k should have given better results)

[+remowilliams]

Yes, point being efficient 68K code driving custom chips in local can be very, very effective.

 

That and Highlander is shit on a shingle.

[Austin]

Shit.. on a shingle.. That would be an amusing sight, for sure!

 

Oh wait.. That's Highlander..

[bmx]

I haven't read the whole thread and just want to add some trivia.

As far as I remember, was the the elevator sound from Resident Evil 1, the exact same sample as in Alien VS. Predator from Rebellion (Jag). I don't know how this comes, but the file on the CD for the elevator sound was named something like AVP_Elevator_Sound. I think a german magazin (Maniac!) wrote this as trivia in an review article about RE1 back in the days.

 

Edit: The Review is printed in Maniac! Issue 12/1994 Page 68.

Could't find it online.

Edited March 26, 2011 by bmx

[sh3-rg]

I haven't read the whole thread and just want to add some trivia.

As far as I remember, was the the elevator sound from Resident Evil 1, the exact same sample as in Alien VS. Predator from Rebellion (Jag). I don't know how this comes, but the file on the CD for the elevator sound was named something like AVP_Elevator_Sound. I think a german magazin (Maniac!) wrote this as trivia in an review article about RE1 back in the days.

 

It's possible it was a stock sample from some library, buy a good spot by the Manic! staff.

[bmx]

I haven't read the whole thread and just want to add some trivia.

As far as I remember, was the the elevator sound from Resident Evil 1, the exact same sample as in Alien VS. Predator from Rebellion (Jag). I don't know how this comes, but the file on the CD for the elevator sound was named something like AVP_Elevator_Sound. I think a german magazin (Maniac!) wrote this as trivia in an review article about RE1 back in the days.

 

It's possible it was a stock sample from some library, buy a good spot by the Manic! staff.

 

Sorry ment: Maniac! 6/1996, page 56.

[PeterG]

I haven't read the whole thread and just want to add some trivia.

As far as I remember, was the the elevator sound from Resident Evil 1, the exact same sample as in Alien VS. Predator from Rebellion (Jag). I don't know how this comes, but the file on the CD for the elevator sound was named something like AVP_Elevator_Sound. I think a german magazin (Maniac!) wrote this as trivia in an review article about RE1 back in the days.

 

Edit: The Review is printed in Maniac! Issue 12/1994 Page 68.

Could't find it online.

 

There is a sound that reminds me exactly of that in a Tool Song called The Grudge from their Lateralus album. It's just before the song starts and it always made me think about the AvP Elevators. It probably isn't the same sound and I can't remember the elevators from Resident Evil. But Björns comment made me think of this:

[greencoman]

You may be right it could be the same sound. By the way I hear the same sound they use for the dogs out in the forest alot of times in movies, alot of cheap sci fis. The overwhelming sound is yes people would play re on the jaguar which is cool. I loved the first game. By the way guys I am really really thrilled you guys posted on this but this was a yes or no question. There was no need for getting angry and off topic. As for more ports on the jaguar I thought of it. Like doom2 avp 2 and a couple others. Keep on posting. I am very suprised at how many jag lovers we have here on AA. This just makes me realize that making games for the jag would be well worth it. If just for the community of hardcore gamers. Thanks for your posts.

Edited March 27, 2011 by greencoman

[kool kitty89]

Yes, point being efficient 68K code driving custom chips in local can be very, very effective.

 

That and Highlander is shit on a shingle.

Another note on this:

Chilly Willy (32x homebrew programmer) recently mentioned that Jaguar Doom actually does all the game logic on the 68k with only the graphics (and sound) handled by the custom chips. (presumably the 32x version Carmak assisted with in parallel with developing the Jag version also used the 68k for the game logic -in that case without bus contention, but at ~58% the clock speed- with the SH2s doing all the rendering and sound, but there's no source code available for 32x Doom like there is for Jag Doom, so there's nothing definite on that issue)

[JagChris]

Just out of curiosity, what brought this question up?

[Tyrant]

Chilly Willy (32x homebrew programmer) recently mentioned that Jaguar Doom actually does all the game logic on the 68k with only the graphics (and sound) handled by the custom chips.

There's an interview with Carmak somewhere in which he says that they started off just porting the entire thing onto the 68k, with just enough extra code to get the graphics and sound working. It ran incredibly slowly, of course, but then they would compile and test one routine at a time for the riscs until they got it running at a reasonable speed.

[LinkoVitch]

Chilly Willy (32x homebrew programmer) recently mentioned that Jaguar Doom actually does all the game logic on the 68k with only the graphics (and sound) handled by the custom chips.

There's an interview with Carmak somewhere in which he says that they started off just porting the entire thing onto the 68k, with just enough extra code to get the graphics and sound working. It ran incredibly slowly, of course, but then they would compile and test one routine at a time for the riscs until they got it running at a reasonable speed.

 

Tyrant fail or Forum Fail? (given this post is in the Resident evil thread and not the doom thread)

[+Sauron]

Tyrant fail or Forum Fail? (given this post is in the Resident evil thread and not the doom thread)

 

More like kool kitty89 fail, as he's the one to bring up Jag Doom in this thread in the first place.

[LinkoVitch]

Tyrant fail or Forum Fail? (given this post is in the Resident evil thread and not the doom thread)

 

More like kool kitty89 fail, as he's the one to bring up Jag Doom in this thread in the first place.

 

See kids, this is why you don't skip to the end

 

DOH! I thought somehow Tyr had managed to reply to one thread in another my bad

[wozencl]

Chilly Willy (32x homebrew programmer) recently mentioned that Jaguar Doom actually does all the game logic on the 68k with only the graphics (and sound) handled by the custom chips.

There's an interview with Carmak somewhere in which he says that they started off just porting the entire thing onto the 68k, with just enough extra code to get the graphics and sound working. It ran incredibly slowly, of course, but then they would compile and test one routine at a time for the riscs until they got it running at a reasonable speed.

 

I know it's not exactly related to this thread but I'll digress as well...

 

The graphics part of the engine was split into 9 segments of RISC code, Carmack stated later, with the benefit of hindsight of course, that he could have accomplished the same task using 3. The DSP handles some of the game logic as well as the usual sound and I believe this is one of the reasons Jag Doom ended up without music. Turn it on and you lose the SFX.

[kool kitty89]

Chilly Willy (32x homebrew programmer) recently mentioned that Jaguar Doom actually does all the game logic on the 68k with only the graphics (and sound) handled by the custom chips.

There's an interview with Carmak somewhere in which he says that they started off just porting the entire thing onto the 68k, with just enough extra code to get the graphics and sound working. It ran incredibly slowly, of course, but then they would compile and test one routine at a time for the riscs until they got it running at a reasonable speed.

 

Tyrant fail or Forum Fail? (given this post is in the Resident evil thread and not the doom thread)

Wait, there's an active Jaguar doom thread? (I haven't seen one) . . . Or do you mean an old/long dead/dormant thread?

 

The most applicable ones I could find are these:

http://www.atariage.com/forums/topic/69035-doom-music/page__p__848481#entry848481 (hasn't been touched in over 5 years)

http://www.atariage.com/forums/topic/25350-jaguar-doom-source-code-released/page__p__281654#entry281654 (source code thread, over 2 years inactive, but definitely seems to be the most applicable)

 

So the options are to continue the off-topic discussion here (where there's been more off topic then on-topic anyway . . . and the main topic was pretty much addressed already), or move it to one of the old threads.

 

I'll stick here for now unless it really bothers people and/or the mods want it to be moved.

 

 

Chilly Willy (32x homebrew programmer) recently mentioned that Jaguar Doom actually does all the game logic on the 68k with only the graphics (and sound) handled by the custom chips.

There's an interview with Carmak somewhere in which he says that they started off just porting the entire thing onto the 68k, with just enough extra code to get the graphics and sound working. It ran incredibly slowly, of course, but then they would compile and test one routine at a time for the riscs until they got it running at a reasonable speed.

 

I know it's not exactly related to this thread but I'll digress as well...

 

The graphics part of the engine was split into 9 segments of RISC code, Carmack stated later, with the benefit of hindsight of course, that he could have accomplished the same task using 3. The DSP handles some of the game logic as well as the usual sound and I believe this is one of the reasons Jag Doom ended up without music. Turn it on and you lose the SFX.

Hmm, interesting. I wonder why he'd use the DSP at all for game logic given the bandwidth problems and given that game logic tends to be relatively bandwidth heavy and not so computation heavy. (so it would usually make more sense to push that onto the GPU even if it meant slowing other GPU tasks down since the dramatic gain in bandwidth would tend to outweigh any advantages of using the DSP)

The DSP's very slow (and buggy) main bus connection would make it pretty weak for anything but extremely computation heavy and relatively bandwidth-light operations. (it might be useful for 3D math in some cases, but even that could be a pretty big hurt on the main bus and slower than loading that onto the GPU -audio processing with minimal main bus bandwith, especially with mostly reads and little to no writes to external memory would tend to be best -avoiding the buggy writes to main would be significant)

 

Hell, due to the buggy writes (and 16-bit bus), the DSP's bandwidth in main is no better than the 68k. (it can read at 8.8 MB/s, but write at 1/3 that, so on average it would be about the same as the 68k as far as bandwidth goes)

 

 

I wonder if the sound/music thing is bandwidth or DSP cycle limited. (if the DSP is loaded up with bandwidth heavy operations, it would waste tons of cycles accessing main RAM)

That and I wonder what sort of compression schemes were used or sample rates. (if bandwidth was the main limitation, lower bitrate samples could have solved the problem -either lower sample rate or higher compression ratio like 4-bit ADPCM -if not already used, 2-bit ADPCM, 1-bit CVSD, etc -CVSD would probably be good mainly for SFX and not music- that and use of interpolation if lower sample rates were used) If it's all uncompressed 8-bit PCM, there's definitely a lot more than could have been done.

They could have dropped down to 1 SFX channel to make things easier too. (playing the PC version with 1 channel doesn't sound too bad at all, not a big leap from 4 channels -which is what I normally have it set to)

 

That or they could have used the FM synthesis driver instead. (that's computationally intensive though, so might hit another bottleneck depending on just what's going on in Doom)

 

 

 

 

Hmm, actually looking at the comments in the source code thread, it seems only the 68k and assembler RISC code was released in the source files (none of the compiled RISC code), so that could explain the discrepancy Chilly Willy's comments. (that would also make the source code less useful for building the homebrew CD32x Doom conversion he's planning -he mentioned he was planning on starting with a modern source port as the basis, but more recently mentioned he was considering the Jag source code as a starting point)

Edited May 2, 2011 by kool kitty89

[wozencl]

Apologies again for replying in the RE thread... Feel free to pelt me with rotten fruit.

 

Hmm, interesting. I wonder why he'd use the DSP at all for game logic given the bandwidth problems and given that game logic tends to be relatively bandwidth heavy and not so computation heavy. (so it would usually make more sense to push that onto the GPU even if it meant slowing other GPU tasks down since the dramatic gain in bandwidth would tend to outweigh any advantages of using the DSP)

 

I imagine they were making the best use of what the had in the given time. I think the GPU is probably working flat out as it is - someone far more knowledgeable than I will probably be able to check this - and I know John Carmack stated that given more time he would have been able to write a far more efficient renderer that took of advantage of the hardware's abilities.

 

They gave the DSP some of the maths heavy logic to deal with - one of the DSP's supposed strongpoints? - and then come up against it with the bugs. In all the DSP source there's a continuous use of LOAD'ing a recently used register into R30 and then OR'ing it, nicely commented with F*****G DSP (Excuse my ignorance, was this a pipeline problem? ). I think that's quite a good indicator of the problems and frustration they had using it.

 

I wonder if the sound/music thing is bandwidth or DSP cycle limited. (if the DSP is loaded up with bandwidth heavy operations, it would waste tons of cycles accessing main RAM)

 

I have no idea, sorry. In the example you've given aren't the two different sides of the same coin?

 

Hmm, actually looking at the comments in the source code thread, it seems only the 68k and assembler RISC code was released in the source files (none of the compiled RISC code), so that could explain the discrepancy Chilly Willy's comments. (that would also make the source code less useful for building the homebrew CD32x Doom conversion he's planning -he mentioned he was planning on starting with a modern source port as the basis, but more recently mentioned he was considering the Jag source code as a starting point)

 

I'm not sure what ChillyWilly is basing his comments on. I'm sure the source files show that the renderer runs on the the GPU and the game logic is split between the 68K and the DSP, which is also responsible for the SFX and music (where applicable). The issue with the source was the fact that we received the compiled RISC files as opposed to the original C files that were compiled using the, now lost, C compiler John Carmack had "targeted to the RISC's".

[Zerosquare]

In all the DSP source there's a continuous use of LOAD'ing a recently used register into R30 and then OR'ing it, nicely commented with F*****G DSP (Excuse my ignorance, was this a pipeline problem? ).

Yes it is. The LOAD and STORE operations aren't actually executed immediately, they're queued until the bus is free and the DSP (or GPU)-to-main bus gateway can actually execute them, while the DSP (or GPU) continues executing code in parallel. There is a mechanism which is supposed to delay the execution of any instruction using a source register which is going to be written by a pending instruction, until after the write is complete ; unfortunately, it's broken in some cases, and the following instruction will fetch invalid data from the register as a result. ORing the target register with itself adds an extra dependancy which happens to fix the problem.

 

Hell, due to the buggy writes (and 16-bit bus), the DSP's bandwidth in main is no better than the 68k. (it can read at 8.8 MB/s, but write at 1/3 that, so on average it would be about the same as the 68k as far as bandwidth goes)

Where are you getting these figures from? Edited May 3, 2011 by Zerosquare

[frogstar_robot]

I know I shouldn't get involved, I REALLY know I shouldn't get involved, but I do have to point out the blatantly obvious here, and I do so as someone who has the required talent, and currently, the time, to create new and decent Jaguar titles (I don't know how worthwhile any game is however, they're all just for entertainment after all).

 

This kind of infighting makes me, and other developers, want to have nothing to do with the scene.

 

Read that again.

 

I love the Jag, not so much for its games, which are on the whole fairly meh (with a few gems), but for its hardware, and the joy of trying to create something on such a weird buggy system. The Jag had potential, which still has rarely been tapped. I like the fun of writing code for it, and trying to make things that are awesome and exploit some of that potential...

 

Perhaps you and some those other developers could have your own scene. And you don't necessarily have to do full blown games. If the fun is all in getting weird difficult hardware to do neat things then do a few demos. Basically, I'm saying hack on the Jag to please yourselves and who cares what the more difficult members of the scene wants. If you create a forum of your own and just don't let the non-devs in or least have a low threshold for swinging the ban hammer then have at it and have some fun.

 

After all, you'll still get the credit for any new techniques that come out of it and others with more patience for the bickering prone Jag scene can make the games using them.

[+Sauron]

Perhaps you and some those other developers could have your own scene. And you don't necessarily have to do full blown games. If the fun is all in getting weird difficult hardware to do neat things then do a few demos. Basically, I'm saying hack on the Jag to please yourselves and who cares what the more difficult members of the scene wants. If you create a forum of your own and just don't let the non-devs in or least have a low threshold for swinging the ban hammer then have at it and have some fun.

 

After all, you'll still get the credit for any new techniques that come out of it and others with more patience for the bickering prone Jag scene can make the games using them.

 

I think it's safe to say that most (if not all) of the naysayers on here are gone, so this should no longer be an issue. At least as far as AA is concerned.

[+CyranoJ]

Naysayers, RIP.

[kool kitty89]

Hell, due to the buggy writes (and 16-bit bus), the DSP's bandwidth in main is no better than the 68k. (it can read at 8.8 MB/s, but write at 1/3 that, so on average it would be about the same as the 68k as far as bandwidth goes)

Where are you getting these figures from?

Kskunk (I believe Atariowl and Gorf were both present for a couple topic where this was brought up too).

 

JERRY (the DSP rather) has a very buggy memory interface that (to make a long story short) results in a 16 bit read taking 6 DSP cycles to complete (a 64-bit read would thus take 24 cycles due to the 16-bit bus -could have been 32-bit with a 32-bit bus master rather than the 16-bit bus of the 68k). That's opposed to TOM's GPU has 2 cycle reads (for any word size) in main RAM (assuming page mode . . . a random access would delay that to 5 cycles, but still with up to 64-bit accesses).

Then there's additional bugs that result in 16-bit writes taking 12 cycles rather than 6.

 

So, while 16-bit reads with the DSP are somewhat faster than the 68k, writes to main RAM are significantly slower than with the 68k.

Both are huge bus hogs, but due to the less buggy reads, the DSP would ideally be pulling data (and possibly chunks of code) from main, but almost never writing anything back. (in the case of PCM based audio, it should be mixing/writing to the local 32-bit SRAM, which has no bug issues at all, and then reading that PCM buffer out to the DAC -since there's no DMA or even FIFO cue to help with that, as you mentioned recently)

 

 

Now, back to the issue of using the DSP for game logic, it has similar pitfalls to using the 68k (worse in some areas -various bugs from aforementioned pipeline hazards to the inability to run code from main RAM, even slower writes, etc), with the main advantage being some very specific computation-heavy and proportionally bandwidth light operations (generally not part of game logic/AI, but things like sound processing and 3D math -possibly ray-casting calculations and similar).

 

With the horrible bottlenecks making is such a bus hog, you're better off loading most things onto the GPU (the increased load -and reduced performance- of the GPU would generally be preferable to the huge hits to the main bus that use of the DSP over GPU would result in). Even for super computationally heavy operations, you REALLY need extreme circumstances to make the bus hogging, low bandwidth main DSP access to be worth it over using the GPU instead. (things like ray-casting or 3D vertex plotting would still require a lot of writes to main RAM for emitting the results . . . and in a generalized summary of the jaguar Kskunk once did, if a game needs 4 MB/s to read data and emit polygon lists and you use the DSP for that, you've just used up almost 50% of the main bus bandwidth just for a geometry engine -vs about 4% if you used the GPU, so unless using the GPU for the same 3D math causes close to a 50% drop in overall game/rendering speed, it wouldn't be worth it in that specific example . . . actually for 4 MB/s, it would be worse than Kskunk's simplified summary as you'd have 8.8 MB/s for reading data, but only 4.4 MB/s for emitting lists -so depending on the ratio of reads to writes for that composite 4MB/s requirement, it could be well over 50% of the main bus bandwidth with the DSP)

 

It's similar to how most/all games would be better off running all game logic/AI on the GPU rather than the 68k. (except in that case, the 68k is easier to use due to lack of bugs and better tools . . . vs the DSP where it's a good deal more problematic all around than the GPU)

 

If the DSP memory interface worked as well as the GPU's (even with the 16-bit bottleneck), it would have been extremely useful as a general purpose coprocessor in the system (like the GLP planned for the Jaguar 2 . . . but without a dynamic cache), but that's not the case.

 

 

Hmm, there could be a caveat to the above argument though. If the GPU or blitter have external access to JERRY's scratchpad (perhaps support for using JERRY's 16 or 32-bit data bus as I/O ports able to read/write to the scratchpad), that could allow a major workaround for the main bus access problems. (I haven't seen anything on that in the jag documents or in comments from programmers, so I don't think its a feature)

 

 

 

 

 

 

Apologies again for replying in the RE thread... Feel free to pelt me with rotten fruit.

 

Hmm, interesting. I wonder why he'd use the DSP at all for game logic given the bandwidth problems and given that game logic tends to be relatively bandwidth heavy and not so computation heavy. (so it would usually make more sense to push that onto the GPU even if it meant slowing other GPU tasks down since the dramatic gain in bandwidth would tend to outweigh any advantages of using the DSP)

 

I imagine they were making the best use of what the had in the given time. I think the GPU is probably working flat out as it is - someone far more knowledgeable than I will probably be able to check this - and I know John Carmack stated that given more time he would have been able to write a far more efficient renderer that took of advantage of the hardware's abilities.

Yes, I assumed the GPU was already working flat out, that's not the problem. As above, the issue is that using the DSP could be worse than slowing down the GPU with more tasks. (similar reasons for using the GPU over the 68k for game logic . . . except the DSP is good for some very fast computations too, just with a very slow/buggy connection to main RAM -making it about as bad as the 68k for bandwidth intensive operations)

 

They gave the DSP some of the maths heavy logic to deal with - one of the DSP's supposed strongpoints? - and then come up against it with the bugs. In all the DSP source there's a continuous use of LOAD'ing a recently used register into R30 and then OR'ing it, nicely commented with F*****G DSP (Excuse my ignorance, was this a pipeline problem? ). I think that's quite a good indicator of the problems and frustration they had using it.

OK, I just didn't associate the game logic comment for something needing low bandwidth and heavy computations. (more like part of the rendering logic; the ray-casting calculations might be worth loading onto the GPU, but even that sort of computation -like with 3D math- still can have some significant bandwdith needs for emitting results . . . and writing to main RAM is the biggest problem with JERRY's memory interface)

 

So, again, it would have to be a case of extremely high ratio of computation to bandwidth performance needed to be worth using the DSP over the 68k. (audio processing tasks not only fall under that category, but can be performed without needing to write back to the main bus at all, just using the scratchpad for the mixing buffer and reading that off to the DAC, staying off the main bus other than to read sample data -preferably heavily compressed sample data to further alleviate the main bus bandwidth bottlenecks)

 

I wonder if the sound/music thing is bandwidth or DSP cycle limited. (if the DSP is loaded up with bandwidth heavy operations, it would waste tons of cycles accessing main RAM)

 

I have no idea, sorry. In the example you've given aren't the two different sides of the same coin?

From what I've seen commented on the issue, things point to it being a bandwidth issue and not a DSP resource issue. Bandwidth COULD be addressed by reducing the bitrate of the samples used or (for music) not using sample based sound generation at all. (FM and various other realtime synth techniques -including true wavetable synth using the on-chip wave ROM -also useful for waves for FM operators) You'd need someone experienced with such synth techniques to get a good arrangement though, so sample based audio would have been easier. (be it a tracker or MOD-like format or a general midi compliant driver -the latter would be really bandwidth intensive if using the full general midi standard of 24 voices)

 

As far as compression (or bitrate reduction) is concerned in general, there's plain sample rate reduction (the DSP could interpolate and filter to make that sound better), after a point, uncompressed 8-bit PCM will sound worse than 4-bit PCM of similar bitrate (double the sample rate), so that would be preferable as well (the threshold for bitrate/samplerate favoring 4 vs 8-bit varies depending on the sound, and in all cases you need optimized conversion for a given format -both 8 and especially 4-bit should have samples -especially voice- heavily processed for dynamic range compression to minimize alising).

Then there's true lossy compression algorithms like various flavors of 4-bit ADPCM, 3-bit (not a convenient word size but among the formats covox promoted in the late '80s for use with the Speech Thing via CPU decoding), 2-bit ADPCM (also among covox promoted formats), 1-bit CVSD (best for speech and some SFX, not good for most musical instruments), 1-bit delta modulation (used on the NES decoded to 6-bit PCM in hardware), or variants of those. (like a 2-bit flavor of CVSD or various custom formats; 2-bit CVSD is one of the better resulting formats of a recent 22 kHz Z80 based decompression/playback engine for the Genesis on spritesmind -a 2-bit format was implemented after relatively poor results came from normal 1-bit CVSD for streaming music)

Lots of formats in relatively common (or at least accessible) use by the early 90s. (1-bit CVSD, 2-bit ADPCM, and the more common 4-bit ADPCM formats would be among the most common)

 

Of course, different formats could be used for different sounds depending on the circumstances. (some sounds would work better with different schemes at similar bitrates -ie lower compression ratio at lower sample rate could sound better for certain things but higher sample rate at higher compression could be better for others)

Additional filtering and/or interpolation could also have been performed by the DSP. (for high sample rate stuff, interpolation won't help, but filtering can be useful where aliasing is a problem)

1-bit CVSD might be appropriate for the SFX used in Doom, though a 2-bit format may be more appropriate in general. (no real voice samples, lots of grunts, growls, yells/screams, weapon/explosion sound, etc so probably not ideal for 1-bit CVSD compared to 2-bit CVSD at 1/2 the sample rate, but who knows without testing? )

 

I'm not sure what ChillyWilly is basing his comments on. I'm sure the source files show that the renderer runs on the the GPU and the game logic is split between the 68K and the DSP, which is also responsible for the SFX and music (where applicable). The issue with the source was the fact that we received the compiled RISC files as opposed to the original C files that were compiled using the, now lost, C compiler John Carmack had "targeted to the RISC's".

Perhaps he simply hasn't scrutinized the assembly files in the source code heavily enough.

 

The fact that only the assembly language RISC sources (and not the C files) were released would also explain some previous comments (over a year ago) where Chilly Willy mentioned he didn't see anything done in C targeting the RISC processors. (actually, having those C sources for the RISC stuff would have been far more useful for using that source code as a starting point for other homebrew Doom projects, particularly the CD32x Doom Chilly Willy is planning to do -the very one he was considering use of a modern source port to start with, but more recently mentioned he might try looking at the Jaguar code as a baseline)

Having the 68k stuff (C or assembly) would be pretty useful in any case for the 32x or (especially) CD. (no bus contention like the Jaguar, a 7.67 MHz 68k with 64k work RAM and -with the CD- a 12.5 MHz 68k with 512k of program/work RAM -plus 256k of word RAM on a separate bus that can be toggled between the MD and CD . . . and used for the graphics ASIC to render into -a blitter limited to rendering 4-bit pixels as scaled/rotated affine textured stamps, or warped/3D textures if set on a line by line basis, very similar to the jaguar blitter's texture mapping feature but limited to 4-bit pixels and running at 12.5 MHz and should have a nominal performance of 1.79 Mpix/s -should have been much faster if not for the slow 3 cycle DRAM accesses, similar to the jaguar's 5 cycle accesses to DRAM due to a lack of buffering or separate source and destination banks -except the Jag CAN use separate source for textures loaded into TOM's scratchpad and also have single cycle reads from that SRAM -but overhead to re-load different textures into that buffer; oh, and of course, a huge bottleneck if you wanted to use that ASIC for 32x framebuffer graphics -you've got the Genesis 68k as a middleman between the CD and 32x, so bandwidth between the 2 is limited by that 7.67 MHz 68k's ability to block transfer data from CD word RAM to the 32x -which ends up being around 1.53 MB/s, and that's not taking into account additional waits for when the 68k is occupied with other tasks)

[greencoman]

You know guys/gals a simple yes or no would have sufficed on here.

[JagChris]

You know guys/gals a simple yes or no would have sufficed on here.

 

roffles.

[greencoman]

Roffles???