PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
NEC TG-16/TE/TurboDuo => TG-16/TE/TurboDuo Discussion => Topic started by: Press_Run on November 28, 2008, 12:53:51 AM
-
There's no doubt the Turbo-Grafx/PC-Engine was the one of the first console to provide 16-bit graphics yet had 8-bit processing heart. I came across this interesting article months back.
http://www.gamefaqs.com/console/turbo16/file/916398/5708
According to it, TG was able to pull off its 16-bit graphics by utilizing two 8-bit cores. Can anyone substantiate this as I'm hardpressed to believe a single 8-bit core could have done all that.
-
I'm not authority, but I thought the PCE was an 8-bit CPU, with a 16-bit graphics chip of some kind. (I could possibly be 100% wrong though)
-
right you are.
-
Dual core processing in 1987? Now that's Turbo Power! :lol:
That faq is incorrect. There's only one CPU (HuC6280), and it's single core and 8-bit. The PCE/TG-16 pulls off 16-bit graphics (er, grafx) with two 16-bit GPUs: the HuC6260 color encoder and the HuC6270 video display encoder. Furthermore, the specs for the CD-ROM are all jacked up. It doesn't have a 16mhz 65802 processor, though that would certainly be interesting (it's similar to the SNES CPU, though far speedier). The RAM listed for Arcade Cards is also wrong, as they add 16Mb (17.5Mb for the Pro card) to the existing RAM, for a grand total of 18Mb (2.25MB).
-
You must also remember that while there was only one 8-bit CPU, a lot of the work was offloaded on the two 16-bit graphics chips. Also, the CPU operated at 7.16Mhz (or something close to that), which was only a little slower than the CPU in the Genesis and many times faster than the CPU in the SNES.
-
That 7 mhz stuff doesn't mean anything unless you're comparing identical, or very similar, CPUs. Why else would a 2 ghz AthlonXP chip have been able to whip a 2.5 ghz Pentium 4? While it's possible the TG and SNES CPUs are somewhat similar, the Genesis CPU is a very different beast. Thus mhz is not a useful point of comparison. MIPS or actual mathematical performance data is a better comparison.
-
I think number crunchers here before have done so already, and found the PCE Hu cpu to be faster over all then the Snes cpu. Regardless of that even, the proof is in the games, where as you do see the PCE move alot of sprites alot faster over all in everything, and you hardly ever have any real slowdown on the PCE versus the Snes on comparable titles like Gradius 2 PCE versus Gradius 3 Snes, or Rayxanber 3 versus Super R-type on Snes.
Game makers them selves from most companies complained that the Snes cpu was just a tad too slow at times and far less efficient for their liking compared to TG/PCE and Genesis cpus. It took them quite awhile to really get a grip and overcome alot of the slow down probs in the games Snes wise, and they never did fully, no matter what trickery they tried to use. My meager opinion on it is Nintendo was too interested in the graphics chips and sound chips in development, and in the design room at the time, 88-89,the hardware guys and Nintendo programmers just didn't realize that games were going to be as in depth as they were getting upon the Snes release.
Snes release titles are a prime example of this mentality, Super Mario World, F-Zero, and Pilot wings, all nice looking, but basic in premise, with Mario having the most going on on-screen. Once the complex games hit, like Super R-Type, Final Fight, Super Ghouls and Ghost, Gradius 3, Contra 3, ect.. it became painfully obvious that the Snes CPU was having a hard time coping with on screen action that really required faster cpu work in order to eliminate slow down. They prob felt worse comes to worse, they could offload alot of the work onto the graphics chip. Turns out if that was the case, it was a poor decision. The Snes still did really amazing things though when people learned to optimize its cpu, graphics and sound ability.
-
Not just overall of the SNES, but in every category including 16bit operations for direct speed of execution in comparison for PCE CPU. Some instructions can run at 3.57mhz for the SNES, but most run at maximum of 3mhz because the snes WORK RAM has wait states that slow it down. PCE runs between 1.6-1.8 MIPS. This was tested for a number of games running in a PCE emulator.
Can anyone substantiate this as I'm hardpressed to believe a single 8-bit core could have done all that
Thank god the PCE doesn't have dual CPUs at half the frequency. Dual CPUs don't translate into double the power, with most of the time the second processor not even hitting 30-50% resource mark let alone the first one.
PCE and the 68000. The 68000 has slow memory access times (4 cycles VS HuC6280 1 cycle), but can grab a single 16bit value in one memory access. Most operations are done register to register because of this. Some instructions are pretty slow in comparison though, but the instruction set in general is pretty powerful in operation. What that means is that it's harder to write slow code on the 68000, or I should say that it's easier to write efficient code without fine tuning optimizations. The linear address of the 68k makes coding much easier too. The Huc6280(PCE) on the other hand requires specific optimizations - which are beyond the scope of this post.
The PCE's graphic chip is 16bit(VDC) - all the way through. Everything is handled in WORDS(16bit) - WORD address define, WORD memory fetchs, read/writes, registers, data port. The other graphic chip is also 16bit, but it doesn't handle much - mostly palette and TV/monitor signal generation. Both of the 16bit graphic chips are able to work with a 16bit CPU like the 68k or directly with an 8bit CPU like the HuC6280. Funny thing is, the Genesis graphic processor (VDP) is 8bit. 8bit bus, 8bit vram, 8bit address define, read/writes, data port(s), etc. 'Bitness' doesn't really mean much and it doesn't have a direct relation to the colors onscreen, etc. And the Genesis VDP is pretty amazing when it comes to sprites and other effects.
-
Tom? Is that you, mal? If so, welcome back, your technical contributions were missed.
-
mal is/was gone? and if yes, wth? :shock:
-
Tom? Is that you, mal? If so, welcome back, your technical contributions were missed.
Am I that easy to spot? :(
-
Tom? Is that you, mal? If so, welcome back, your technical contributions were missed.
I second that.
-
My meager opinion on it is Nintendo was too interested in the graphics chips and sound chips in development, and in the design room at the time, 88-89,the hardware guys and Nintendo programmers just didn't realize that games were going to be as in depth as they were getting upon the Snes release.
The SNES CPU was chosen because it is backwards compatible with programs written for the NES CPU. At some point in the development, NES backwards compatibility for the SNES was abandoned, but the slower CPU was retained, unfortunately.
-
Am I that easy to spot? Sad
Ha,yea, by the third paragraph i knew who it was aslo, it should definitely be taken as a complement.
-
Am I that easy to spot? :(
Yeah, but consider that a good thing. :)
-
Tom? Is that you, mal? If so, welcome back, your technical contributions were missed.
I second that.
I third it. If you need more, my other personalities n-th it.
-
So, why is Mal now Tom, with only 7 posts? Did someone run him off with massive annoyance or something?
-
So, why is Mal now Tom, with only 7 posts? Did someone run him off with massive annoyance or something?
Guess I just needed a little break ;)
-
Well, since you're back, maybe you can answer another question. The Genesis and SNES have dedicated (perhaps not fully, but enough) sound hardware, where the PCE controls sound generation within the CPU. That's my understanding, anyway. Does the task of sound generation, particularly for HuCard games where the soundtrack and sound effects must all by CPU generated and coordinated, put a significant strain on the CPU? Does that limit the available computing horsepower for other tasks?
Also, and this is completely random, I'm sure... how difficult is the PCE to program for compared to its compatriots? It certainly seems like there are many PCE games that do little to exploit the CPU, merely relying on lowest common denominator capabilities.
-
Re: the "technically limited" PCE games: Here's what I think (copied from an older post):
You could look at it artistically/culturally: On the one hand, most/many of the PCE developers came from the NES/Famicom world, and treated the PCE as just a souped-up Famicom, especially at the beginning of the PCE's life. Meaning blocky graphics, low colours when a lot higher number of colours could have been used. They just didn't push themselves far enough at the beginning. The most impressive games (with more colours and higher resolutions) came from the companies experienced with Japanese PCs.
On the other hand, a lot of the (earlier) developers on the Gen/Megadrive came from the arcade world, experienced with the 68000 CPU and the wider (typically 320) resolutions of their arcade games. Either that or they came from the PC world, did X68000 ports, etc.
That's one big difference, as far as I see it. The PCE was treated by too many of its programmers & artists as an "NES with knobs on", to misquote one British developer.
-
Well, since you're back, maybe you can answer another question. The Genesis and SNES have dedicated (perhaps not fully, but enough) sound hardware, where the PCE controls sound generation within the CPU. That's my understanding, anyway. Does the task of sound generation, particularly for HuCard games where the soundtrack and sound effects must all by CPU generated and coordinated, put a significant strain on the CPU? Does that limit the available computing horsepower for other tasks?
Yes and no. Well, actually no.
First. The CPU itself doesn't generate the signals and such for the audio unit. The audio unit is a separate device just like any other audio chip. It just happens to be located on the CPU dye for cost saving measures - you don't have to fabricate another chip, the system board doesn't need extra address lines and logic decoder chips. As far as the CPU (and programmer) is concerned, the audio chip is external like any of the other chip in the system or cd unit.
Second. Most(all) PCE games keep the instruments simple in design - they change channel registers once every frame at the fastest. Most of the time it's about every 4-5 frames for register changes. This means the music engine only takes about 1-2% CPU resource. If you add PCM samples, then you start to eat a little more. About 4-5% cpu resource per sample being played. Most games only use one channel/PCM effect at a time and mostly for a drumkit or such. SF2 uses two and Batman uses two. And games like Bomberman 93/94 use not PCM samples. The drums and such are all done/modeled with 'noise' modes of channel 5 or 6. The PCE could have played samples at 1% cpu resource if it weren't for a bug in the audio chip. The audio unit channels actually hold PCM samples, just really small ones. You could treat that as a buffer and refill it at like less than 1khz to get really high playback rates (32khz, 44khz, 112khz and such), but the bug in the audio unit causes a sound blip when the channel DAC is turned off for sample reloading. At 1khz, the small spike in audio it causes a low cycle but loud tone - rendering the method unusable. The SGX and coregrafx I fix this bug, but Duo and later models do not. Enough of my ranting about that :wink:
I've been doing a lot of audio/music research this year. Looking into how hucards create instruments, etc. Talking with David Shadoff, who did the MML functions for Magickit over 7 years ago, all the games he looked at used a version of Hudson's MML player for music engine. The developers didn't bother creating their own. Bloody Wolf is the only game that really stands out in how it does some if it's instruments, but for all I know it could still be using a revision of Hudson's player. The system card has this player build into it's bios routines.
The real kicker is that the PCE is capable of playing MOD style music. Yet only two games did something like that. One was that boxing game, but it was reeeeaaallly generic in design and the other was Batman. Batman basically had 1 MOD channel where it could bend a sample into frequencies for notes like a MOD player does. The main instrument that's used for that channel is the 'bass guitar' and some other super r-type-ish sounding instrument. The drums are fixed frequency samples. The PCE is also capable of doing more complex instruments because of the TIMER chip and yet (again) no game ever does this. This isn't some secret knowledge or anything. I'm really at a loss there. Anyway, the PCE is capable of doing up to 6 MOD channels, though you really only need 4. The player code has to be extremely optimized since doing it all in software eats up gobs of cpu resource. I think the fast version I calculated base on my player code was about 26-27% cpu resource - 7khz stereo 4 channel. Not bad at all ;)
Also, and this is completely random, I'm sure... how difficult is the PCE to program for compared to its compatriots? It certainly seems like there are many PCE games that do little to exploit the CPU, merely relying on lowest common denominator capabilities.
From what I could gather, it was more of a style of development. As CCovell put it, the PCE has that 8bit charm in a lot of it's games early games. Even as the games advanced, the game mechanics and over design were usually kept more simplified. It's target audience I guess. Not all games are like that, but overall you kinda get that feeling. It's just a charm about the games. Later games tend to be more sophisticated. Like Seiya Monogatari, Xanadu, Xanadu 2, etc. Not just in design, but hardware interface too. Earlier CD games are really bad at efficient design of code. Unnecessary loads time (really, longer than should be because of the design of the load structure), inefficient memory usage - i.e. most of the time no compression and wasted/empty ram/space. Stuff like that. If you look at Gate of Thunder, it's amazing. Not only does it efficiently store data as a single block for fast loading, it also uses 'real' compression so that the CD ram goes further, and the code is fast enough to decompressed sprites in real time on the fly - that's extremely impressive(I did a lot of research on GOT). The game script which controls all the events is optimized for minimal chance of flicker and sprite positioning. Basically a professionally build game. LOT is the same. Red really knew what they were doing. To top it off, it would have easy to make other shooters using either of the two game engines. Too bad they never did.
Edit: Heh - Chris beat me to it :)
-
some other super r-type-ish sounding instrument.
You mean the http://www.joeredifer.com/crap/superr-typeinstrument.mp3
It should be used in EVERY song.
-
what's an orch?
-
what's an orch?
(http://www.horrorstew.com/images/MoriaOrcMask.jpg)
-
what's an orch?
teh name for one of those typically & cheaper digi synth instruments called "orchestral hit".
-
what's an orch?
teh name for one of those typically & cheaper digi synth instruments called "orchestral hit".
:oops: a non-native speaker had to tell me this :oops:
I was hoping it was some sort of weird steelpan or something. http://en.wikipedia.org/wiki/Steelpan
-
I've been doing a lot of audio/music research this year. Looking into how hucards create instruments, etc. Talking with David Shadoff, who did the MML functions for Magickit over 7 years ago, all the games he looked at used a version of Hudson's MML player for music engine. The developers didn't bother creating their own.
....
The PCE is also capable of doing more complex instruments because of the TIMER chip and yet (again) no game ever does this. This isn't some secret knowledge or anything. I'm really at a loss there.
You know, this sounds like a case of Hudson simply not providing the tools. I remember many complaints from developers about the Genesis and especially the Saturn along the lines of whenever Sega developed new programming tricks they always kept them in-house for a couple games before rolling them into the dev kits, leaving developers effectively working with yesterdays libraries while Sega was always on the cutting edge. That fostered some bad blood. And if anyone knows who Jake Kaufman is (virt in the vgmusic world), it's notably that he complains how often he's had to use Nintendo's music kit in games instead of custom, quality sound libraries. So this is clearly still an ongoing battle.
From what I could gather, it was more of a style of development. As CCovell put it, the PCE has that 8bit charm in a lot of it's games early games.
My comments about game "quality", perhaps more appropriately style, were mostly about HuCard games. The later CD and SCD games really did push the envelope. Seems the HuCard was passed off a bit too early in its life. I would have liked to have seen some of the later programming techniques applied to more HuCard games. But sometimes the NES-styled design does irk me, because when you don't have a CD unit you want some HuCard love, and while there is some good out there, there's an awful lot of "merely OK".
-
Allot of the early games did have that 8 bit feel to them, ccovell gave some good reasons for this, but lets not forget some of the very first games like Rtype I/II which brought great looking arcade graphics, China Warrior with its huge sprites, all of these were only 2 megs.
You know, this sounds like a case of Hudson simply not providing the tools
That reminds me of something from DMA, the developers of Shadow of the Beast, they thought the software development kit that NEC gave them was awful and wrote their own, the following shots show dual layers using sprites with no flicker.
(http://i132.photobucket.com/albums/q13/awack/CD_15628250-004.png) (http://i132.photobucket.com/albums/q13/awack/CD_15628250-001.png)
-
That reminds me of something from DMA, the developers of Shadow of the Beast, they thought the software development kit that NEC gave them was awful and wrote their own, the following shots show dual layers using sprites with no flicker.
(http://i132.photobucket.com/albums/q13/awack/CD_15628250-004.png) (http://i132.photobucket.com/albums/q13/awack/CD_15628250-001.png)
Mike Dailly (http://dailly.blogspot.com/) also worked on that game (the PCECD one). He said something to the effect of regretting not doing a second scroll layer in the dungeon levels.
You mean the Orch Hit?
It should be used in EVERY song.
Is that what it's called? Heh
-
In theory an orchestra hit is supposed to be the sound of every instrument in the orchestra offering a short, loud note, simultaneously. A number of great works use it to positive effect. In translation to mod/midi/digital sound generation systems it just sorta became a muddled blat.
-
Super R-Type ruined the sound forever with its overuse. That is why everyone hates IREM and nobody will have sex with anyone who has ever worked there.
-
In theory an orchestra hit is supposed to be the sound of every instrument in the orchestra offering a short, loud note, simultaneously.
You mean like the last note of the Matlock theme? :P