What do you guys think of the PC Engine / PC Engine CD?

[MintyTheCat]

The PCE's isn't a hack-job (it's actually quite well designed and simple). The MD's isn't exactly gross, but it is strange and peculiar, mostly lending to the fact that it's built off of older technology rather than designed from scratch.

They're actually not too different though; the PCE VDP also stores everything in one memory area (so higher resolution means less space for other things), and it has DMA between the CPU and VDP to help speed it up significantly.

That spec-sheet is about right, but I don't know if I'd say MIPS is particularly relevant when comparing CPUs. Of course running a series of NOPs will be faster on the PCE, because it has less bytes to fetch, and less overhead. But when you have to deal with 16 bit and large amounts of numbers, the PCE CPU starts to show its age.

I'd probably put the PCE CPU's performance slightly under the MD's.

The Megadrive - like much of the older Stuff was based on Arcade Hardware with some of the Resources reduced.
Tried and tested will often be enough. SEGA developed Custom ICs but NEC most likely had more than enough IC Development expertise available at the Time - any one not working on PC Class Hardware was free to work on the Console.
The PCE is indeed elegant and cost effective. However, the Megadrive is not unlike most Home Consoles of its Day: it used fairly standard Components such as RAM, PROMs, Microprocessors and then it had some Custom Logic ICs. The NeoGeo is pretty close in terms of Components to the Megadrive.

Also, note that the Megadrive can handle a Resolution 320x448 for PAL and NTSC but could actually support 320×480 for PAL Mode.
I am not sure what the highest Resolution that the PCE can support though.

Critical Design Factors:

1. DMA between Memory Device(s) and the GPU/VDP
2. Amount of usable VRAM
3. Amount of autonomy that the Graphic Hardware has without provision from the main Processor - the Amiga immediately springs to mind here.

I suppose something wasn't thought about at the Time but would have been very significant:

Fast Decompression of Graphic-Data. Most of these old Consoles use Tile-Based Graphics - harkening back to Arcade Machines. Having to compress and then decompress the Graphic-Data can really start to add up for certain types of Games but I do not know of much support for this task on the PCE and the MD and the SFC/SNES.

You cannot compare the Architectures of the 68000 to the 6520 and its Derivatives. It comes down to Pipelines and Caches and then it comes down to the type of Data and Application the System is being used for. The best way to test the Limits is to assume that every single Vetical-Blank you would have to alter every Tile held in Memory and then update the Tile-Map(s). This would be a better test of the Memory and Graphic Hardware - the Microprocessor/Controller would only have to start the DMA activities and could effectively 'nop' for the rest of its Time until the next V-Blank.

Tbh I thought that the PCE would have a higher number of on-screen Colours available as it tends to look really nice and bright compared to many of the Megadrive Games. Of course you'd have to view all the Colours the PCE could generate and then compare it to all the Colours that the Megadrive could generate to see the spread of Colours.

[MintyTheCat]

This is all quite interesting but surely that resolution of 512 x 224 for the TG16 is wrong? I thought the PCE was a 256 x 192 machine (that slight lack of vertical resolution adding horrible vertical scrolling to games like R-type) though it also has that odd double rez interlace mode.

Actually I thought Skykid's reply was debating not the 8/16 bit thing but rather the bestness, or rather the fact that some might think the Famicom had the best shmups.

It's funny how the PCE had to be changed for the US market with the big box and the 16 bit nonsense. I remember SNK also proved that 8 plus 16 does equal 24 bit with the Neo Geo..... Shite.

Marketing tend to get it 'wrong' and they also lie... It may be that it cannot display 512 - anyone know?

Technical basis and 'bestness' is all highly relative. The NES/famicom in terms of Technology is a pile of shite - but People love it and it's all down to the Software - once the Hardware is in place very few People really think about it, they just think about the Games they can play - which is most important.

SNK did not 'prove' this incorrect Arithmetic - more likely their US Marketing Department thought it would be a good Idea to 'try to look hard' Most of the general public would not be any the wiser should they put any combination of Numbers and other Symbols on the Specs - it is all just talk But it was amusing to see all this first hand back in the early 1990s

Has anyone noticed that i dislike 'Marketing Types' for all their Lies?

[null1024]

I'd probably put the PCE CPU's performance slightly under the MD's.

It seems to depend hugely on what kind of game it is, which meshes with my experience doing low level programming: If you're doing a shmup, I imagine you can get away most of the time with 8-bit values (especially when the width of the screen is 256 pixels and not 320). But if you're doing a game with, let's say, jumping or inertia or otherwise lots of fractional values, you'll probably wind up with more 16-bit math or perhaps more lookup tables at the least.

That said, the characterization of a system as 8-bit or 16-bit is really misleading. I used to think it was simple, but it's not. Take the Genesis: It's got a 16-bit data bus, but is 32-bit internal. I think there's a penalty for 32-bit operations though. But I was speaking with an old videogame author, and he was saying the SNES CPU has a penalty for 16-bit math, and the site at cpu-world says it's an 8-bit data bus! So is the SNES 8-bit or 16-bit? If the SNES is 16-bit, does that make the Genesis 32-bit?

On some level, it really doesn't matter. It's all about improvements that come with a new generation of hardware, with the display processor being pretty damn important, and other improvements like DMA transfers (copying blocks of memory around without involving the CPU) or other coprocessing. Amount of memory (both game data and RAM) is also extremely important, as exhibited by the enormous jump in quality you see from earlier HuCard games to CD-ROMs.

Bitwidth just describes the native integer size [important in deciding how much memory the system can access without bankswitching in some way, especially since the address bus is either equal to or smaller than the native integer size], that's all.
It's often extremely misleading when it comes to system power. Especially in the case of the 68k, which is almost a 32bit CPU [this caused problems with early Macs when better 68k-series CPUs were used, as the 68k's address bus was 24bit, allowing it to access 16MB of memory, programs that used the other 8 bits for other purposes [such as flags] failed on fully 32bit 68k-series processors]. It is a 32bit processor otherwise. The data bus bitwidth doesn't matter when counting how many bits your CPU is [hell, don't Pentium series processors have a 64bit data bus?].

take note, some of this is almost certainly wrong, please correct any issues with the above please, better informed folk... [trap15, help me out, I'm not terribly well studied here]

If Sega was more clever, they could have said the Genesis was 24bit, like SNK did, and they wouldn't be lying. Yes, SNK wasn't lying.

Bitwidth is lies. "Do the math" has corrupted us all.

also, on a semi-unrelated note, the SNES's design bothers me, because it has all this might in high-power video and sound hardware, but you still need a good main CPU for object management [and the SNES's CPU is dog slow compared to the MD or PCE], so more action packed games can't flood the screen with stuff without slowdown.

[MintyTheCat]

I'd probably put the PCE CPU's performance slightly under the MD's.

It seems to depend hugely on what kind of game it is, which meshes with my experience doing low level programming: If you're doing a shmup, I imagine you can get away most of the time with 8-bit values (especially when the width of the screen is 256 pixels and not 320). But if you're doing a game with, let's say, jumping or inertia or otherwise lots of fractional values, you'll probably wind up with more 16-bit math or perhaps more lookup tables at the least.

That said, the characterization of a system as 8-bit or 16-bit is really misleading. I used to think it was simple, but it's not. Take the Genesis: It's got a 16-bit data bus, but is 32-bit internal. I think there's a penalty for 32-bit operations though. But I was speaking with an old videogame author, and he was saying the SNES CPU has a penalty for 16-bit math, and the site at cpu-world says it's an 8-bit data bus! So is the SNES 8-bit or 16-bit? If the SNES is 16-bit, does that make the Genesis 32-bit?

On some level, it really doesn't matter. It's all about improvements that come with a new generation of hardware, with the display processor being pretty damn important, and other improvements like DMA transfers (copying blocks of memory around without involving the CPU) or other coprocessing. Amount of memory (both game data and RAM) is also extremely important, as exhibited by the enormous jump in quality you see from earlier HuCard games to CD-ROMs.

It does depend on the type of Game:

Snow-Bros and Bubble-Bobble are very low in terms of Resources and would require virtually none if any swapping of Tiles. If you wanted to animate the Backgrounds then the only risk of swapping Tiles out to replace the Tiles to effect the Animation would be a Problem if you had no VRAM left to hold the Tiles used in the Animation - probably a very bad Design Decision would be to animate the Backgrounds with Tile Animation if you had such low Resources (i.e. VRAM space available) - I'd try to colour cycle or do something else to 'animate' the Background there and that would require no update to the Tile-Map(s) where a Tile-Swap would.

Most of these old School Consoles have no Floating-Point Support whatsoever. The Developer has to effect Inertia and all that stuff using some kind of State-Machine or simple calculation. Tables are used a lot, yes but then you hit your Resources limit Issue if you only have Tables in your Code.

Isn't the SNES's Microprocessor based on a 6502? That would be 8-bit. The 68000 has a pentalty for dealing in Bytes as indeed it does have the need for all Addresses to bound to even Offsets. So if I had a For-Loop that used a Byte instead of an Integer and I wrote it in C, well the Assembler would maybe have to check to ensure that my Values are within the Limits - which costs the Machine Instruction-Cycles. It really depends on the Architecture being used. I would never even think about doing multiplication on a 68000 - it's something like 172-176 Cycles per Operation! In this case it is easier to simply 'add' or add and use a Table.

Yes, I agree that it doesn't matter that much. But I have to add that the most important thing is that the Developers know how to use the Hardware and they can write decent Software for the Platform. We cannot expect Miracles from these Python and Java Developers but we can from these old School Assembly Developers

[MintyTheCat]

I thought the main purpose of the "main" SNES CPU was facilitating data transfer from the cartridge - the SNES video chip does a lot more of the heavy lifting in creating graphics there.

No - more often than not the 'Main CPU' is responsible for managing the 'State' of the Game. This includes things such as checking for Sprite-Collisions (if you have no support in Hardware or if it is limited to telling you only which 'Line' the Collision occurred on), swapping out Colours to Colour-RAM (CRAM), updating Sprite Positions, managing the Player's Character/Spaceship and any Software Scrolling Effects or other Effects that are not handled by the Video-Hardware.

The main Thing is to offload as much Effort from the Main CPU to the Peripheral ICs such as the Sound and Video ICs. The more DMA you have the better.

[mulletgeezer]

Wasn't it because of the (at the time) hugely important NES backwards compatibility that the SNES ended up with it's odd slow cpu with 16 and 8 bit buses? So of the 16 bit console generation we have the PCE (8 bit) the MD (maybe 16/32 bit) the Neo Geo (true 24 bit!) and the SNES (not quite 16 bit) so there are actually no 16 bit consoles at all.

The prize for greatest 16 bit shmup system therefore is awarded to........

The Amiga!

[louisg]

I thought the main purpose of the "main" SNES CPU was facilitating data transfer from the cartridge - the SNES video chip does a lot more of the heavy lifting in creating graphics there.

No - more often than not the 'Main CPU' is responsible for managing the 'State' of the Game. This includes things such as checking for Sprite-Collisions (if you have no support in Hardware or if it is limited to telling you only which 'Line' the Collision occurred on), swapping out Colours to Colour-RAM (CRAM), updating Sprite Positions, managing the Player's Character/Spaceship and any Software Scrolling Effects or other Effects that are not handled by the Video-Hardware.

The main Thing is to offload as much Effort from the Main CPU to the Peripheral ICs such as the Sound and Video ICs. The more DMA you have the better.

Yeah, the CPU is what the game actually runs on-- it's handling input, any physics, enemy AI, any movements and animations (it figures them out then tells the graphics chips what to draw and where), sometimes special effects or 3d. On some systems, it calculates what notes to play for the music or shoves samples into a buffer for digitized sound.. it does a ton. It's the cornerstone of the system. When you write a game, you're really writing it for that CPU to do the bulk of the work.

Some other uses:

Sonic the Hedgehog is basically a "watch how fast our processor can uncompress the level data" demo.

And on the SNES, when you see games like Pilotwings, it's doing a lot of the perspective calculations on a DSP (secondary CPU-like processor) embedded inside of the cart. I think that was Nintendo's strategy-- slow main CPU, and we can throw extra chips into the carts if we have to.

IIRC, and I could be wrong, but the SNES didn't have a programmable GPU in the sense that you could upload an independent program to it (like on its SPC-700 soundchip or the Amiga's Copper).

[MintyTheCat]

Wasn't it because of the (at the time) hugely important NES backwards compatibility that the SNES ended up with it's odd slow cpu with 16 and 8 bit buses? So of the 16 bit console generation we have the PCE (8 bit) the MD (maybe 16/32 bit) the Neo Geo (true 24 bit!) and the SNES (not quite 16 bit) so there are actually no 16 bit consoles at all.

The prize for greatest 16 bit shmup system therefore is awarded to........

The Amiga!

I read that nintendo wanted to have backward compatibility on the SFC/SNES for the NES/FC but had to cancel that Idea due to costs.

You could easily emulate an 8051, Z80 or a 6520 in Software/Hardware using a faster Microcontroller - that Ricoh Device they used may have been for other Reasons, e.g. a development/manufacturing collaboration between one or more of the IC Manufacturers and nintendo at the Time - I do not know.

68000 has a 16-bit Data-Bus but a 24-bit (A0-A23) Address-Bus.

How can you add the Data-Bus Width of the Z80 that handles Sound to the Data-Bus Width of the 68K that handles everything else to get 24? It is like adding Goat to Wheelbarrow to equal Mercedes - they handle completely different Tasks and as such only Marketing Types would think to add them to try to sound impressive

Btw: the Megadrive does have backward compatilibility with the Master-System - it merely hands over the Control the MD's Z80 and changes the Mode in the VDP to Mode #4 - if I can recall correctly.

[Ed Oscuro]

Yes, the SNES was originally planned to have backwards compatibility with the NES; Nintendo Power reported it. I'm not so sure the old story that if Nintendo left this out from be beginning that they could have selected a significantly better CPU, though - if it's faster than the Genesis CPU despite running at half speed, and given the numbers they cranked out, it was probably pretty decent and cost-effective. Supposedly the SNES CPU does 1.5 MIPS over the Genesis at under 1 MIPS, despite the comparatively halved clock speed of the Ricoh CPU in the SNES. I do find it kind of hard to believe - the Genesis might have somewhat less color and resolution, but it doesn't feel completely outclassed by the SNES.

Of course the CPU has to handle game state logic - but, in the case of the SNES peripheral CPUs, I still think it's mainly doing DMA to a faster CPU housed in a cartridge - no 3D calculations on its own, I am sure; and I thought its only contribution to sound was sending data and commands to the internally programmed sound chip, which certainly needs no help from the main CPU in this case. I had thought game logic for the SNES was the lesser share of CPU resources than DMA. It still wouldn't surprise me to find the SNES CPU doing much less work overall than the video hardware (or if the CPU was tasked with much of what has been offloaded to the video chip - for example sprite rotation, which I thought was done on the CPU in the case of the Sega Genesis, not the video generation chip). It'd be interesting to see a direct comparison between the video hardware and the CPU in terms of capability (I don't imagine they don't map simply, for example comparing MIPS, because they serve different functions) but I doubt the main CPU could really pull off sprite rotation, Mode7 effects, transparency, and many of the other advanced effects seen in the SNES.

And on the SNES, when you see games like Pilotwings, it's doing a lot of the perspective calculations on a DSP (secondary CPU-like processor) embedded inside of the cart.

Which is not what I was talking about with the main CPU, of course.

[louisg]

Of course the CPU has to handle game state logic (but, in the case of the SNES peripheral CPUs, it's doing DMA to a faster CPU housed in a cartridge - no 3D calculations on its own, I am sure; and I thought its only contribution to sound was sending data and commands to the internally programmed sound chip, which certainly needs no help from the main CPU in this case) but I had thought this was the lesser share of CPU resources than DMA (admittedly, that doesn't make sense). It still wouldn't surprise me to find the SNES CPU doing much less work overall than the video hardware. I don't know of a direct comparison between the video and CPU hardware in terms of processing capability (it's a given they don't map simply because they serve different functions) but I doubt the main CPU could really pull off sprite rotation, Mode7 effects, transparency, and many of the other advanced effects seen in the SNES.

Well, it depends how you define work. Traditionally, CPUs are worse at simple logic that's in a tight loop, and operations like that are better off in hardware. For example, doing an operation with the background (e.g., looping over every pixel and doing something simple with it). But don't underestimate how much work game logic and everything else is-- it's a ton of work! This is why you have so many games that start slowing down when there are so many on-screen objects. Although the sprite limit is fixed at N objects per scanline and drawing them is the job of the VDP, the CPU is still animating all of them, calculating collisions, and that sort of thing. It might not initially seem like a lot, but factor in dozens of objects with a variety of things they can be doing, and it builds up.

And this design is hardly unique to the SNES. Pretty much everything has a VDP that shares a huge chunk of the workload. This is in contrast to something like the Apple ][ which had to do everything via CPU. Notice that you almost never see a fully tiled background on it which is scrolling. Or another good case is the Atari 2600: It had some accelerated features, but the CPU basically baby-sat the video chip, which stole time that the Atari could've put into the game logic instead (note that it's virtually the same CPU as the C64, clocked at the same rate, IIRC).

EDIT: OR, here's another comparison: The VGA-based PC! You needed essentially a Pentium to get it to behave at SNES quality because the CPU was responsible for doing so much. It was a strange design because it had so much raw number crunch ability that it could do amazing 3d (like Doom, Falcon 3.0, and all that), but at the same time still hardly be able to deal with sprites and tiles.

[Ed Oscuro]

Well, it depends how you define work.

I thought I already did - approximating the function of the SNES video hardware from within the CPU. I don't mean emulation-level quality, just what would have been considered acceptable at the time. Obviously I expect the SNES would still have had graphics hardware, but what if it had been more like the Genesis' - without rotation or Mode7 functions (so games like Contra and Batman & Robin have to rotate sprites or create Mode7-like effects on the CPU, if I have it right)? If the MIPS comparison is correct it should still have had a slight edge over the Genesis, assuming the Genesis hardware didn't access memory faster.

EDIT: OR, here's another comparison: The VGA-based PC! You needed essentially a Pentium to get it to behave at SNES quality because the CPU was responsible for doing so much. It was a strange design because it had so much raw number crunch ability that it could do amazing 3d (like Doom, Falcon 3.0, and all that), but at the same time still hardly be able to deal with sprites and tiles.

Indeed. Besides some rare platformers, though, I can't think of much (Abuse? Blackthorne maybe? Certainly no Apogee Software game comes to mind as having SNES-like qualities) that would have been a direct comparison - by the time the Pentium line of PCs were capable of SNES-like graphics, most games development had moved onto 3D games, even Quake-like engines (1996 and the introduction of the MMX CPU). I could run a ported Sega Genesis game (Comix Zone) perfectly on mine, in a window, but that's just pushing some pixels to the monitor, not applying lots of effects.

On the other hand a 286 alone (which is actually highly powerful compared to the CPUs mentioned here) was probably capable of doing just the Mode7-style tasks, in terms of perspective effects seen in Mode7, not so much on sprite rotation (all the 3D shooters shied away from any kind of sprite rotation; I think even Rise of the Triad's famous gib fountains are just flipped if necessary)

[louisg]

Well, it depends how you define work.

I thought I already did - approximating the function of the SNES video hardware from within the CPU. I don't mean emulation-level quality, just what would have been considered acceptable at the time. Obviously I expect the SNES would still have had graphics hardware, but what if it had been more like the Genesis' - without rotation or Mode7 functions (so games like Contra and Batman & Robin have to rotate sprites or create Mode7-like effects on the CPU, if I have it right)?

Well, there are some ways around it. Road Rash appears to have real scaling, but it's probably a combination of lookups while repeating lines (for vertical stretch), or maybe repositioning sprites as they're being drawn, or something like that. I don't think it's that fast, and it's chunky and inaccurate. I also corresponded with one of the authors of that game, and it also has some degree of actual 3d calculation.. but this is derailing the discussion.

Approximating the quality of the SNES' video hardware would be likely impossible with the consumer-level CPUs available in 1991, assuming you started with a Genesis-quality VDP (not counting the color limitations-- assuming for the sake of argument that it's 256 color and you have access to the individual pixels). While a 386 CPU at a few dozen Mhz could do "rotozoom" style effects, something below 10mhz sure couldn't do that very well. Translucencies can be done using lookups, or simple translucencies can be done if the memory layout is bit-planar. It's a pretty complex topic that has to do with methods, memory layouts, what hardware acceleration *can* provide (using it in combination with the CPU to make it do something it wasn't designed for), and that sort of thing.

So, I'd never argue that the SNES VDP isn't impressive in terms of crunching pixels, but it also can't fill in for what a CPU can achieve either. To me, the "SNES feel" is a game where all the sprites and backgrounds look very nice, and it might have some great special effects, but tends to be sparse because it just can't handle a lot of movement without some very clever programming (like Compile's complete bad-assery). The worst-case scenario ends up being something like Thunder Spirits where you can't use autofire because having more than a few player shots is enough to cause slowdown. Not that this was an excusable programming job...

EDIT:

Re: 286s or 386s. I remember an awful lot of 2d games running at 30fps or lower, something that was extremely uncommon on a console. Wacky Wheels, for example, ran pretty slowly compared to Mario Kart. Zone 66, a game by some serious demoscene tweakers, still chugged along at something really pokey like 15hz. Yeah, by the 486 you could do some emulation at a decent speed. Callus was usable on my 486 @132mhz. So I guess I'd say that by 486 era you could do some SNES quality stuff if the hardware was harnessed well, but not that I saw on the 386 with rare, limited exception. I think the 386 was about up to Amiga quality though-- one background plane and a few sprites. Tubular Worlds ran well.

[louisg]

So, uh, what do you guys think of the PC Engine / PC Engine CD?

[MintyTheCat]

So, uh, what do you guys think of the PC Engine / PC Engine CD?

IT RULES!

[Ganelon]

You needed essentially a Pentium to get it to behave at SNES quality because the CPU was responsible for doing so much.

What about Cool Spot? I remember that playing and looking pretty similar across SG, SNES, and 386DX (it supposedly even worked on a 286 but not on mine). By the 486 era, there were already games like Super Street Fighter II Turbo with sprites and smoothness comparable to versions on 32-bit consoles.

As for the PCE, I think it's interesting that folks nowadays seem to nearly ubiquitously lump CD-ROM2 games with Super CD-ROM2 games. It's even more common than mixing MSX and MSX2 games together. It's interesting because there tends to be huge graphical differences between the 2 formats.

[powerflower]

One of the best consoles ever made.Have the white Engine with CD-Rom (with RGB mod),GT aaaaand the LT.So much awesome shooters on this system,love it:)Oh and recently bought Ginga Fukkei Densetsu Sapphire (mint) for only 190 Euros including the Arcade Card.Now I can die in peace.

[Bloodreign]

It had the best version of Gradius 1 and 2 on it (X68K is fine, but it's no console),

If you like the arcade original, Gradius has a direct port on X68000.

Yeah, it apparently has 2 different versions of Gradius 1, music tends to sound somewhat different between them. There's also Gradius II and Parodius, as well as Detana Twinbee for the thing.

Speaking of Detana Twinbee, the PCE version I was actually able to 1CC once, shame I didn't remember to copy the score down anywhere, as I couldn't do it again.

[louisg]

What about Cool Spot? I remember that playing and looking pretty similar across SG, SNES, and 386DX (it supposedly even worked on a 286 but not on mine). By the 486 era, there were already games like Super Street Fighter II Turbo with sprites and smoothness comparable to versions on 32-bit consoles.

As for the PCE, I think it's interesting that folks nowadays seem to nearly ubiquitously lump CD-ROM2 games with Super CD-ROM2 games. It's even more common than mixing MSX and MSX2 games together. It's interesting because there tends to be huge graphical differences between the 2 formats.

Yeah, maybe a 486 is the point where it starts being console-quality. That's what Jazz Jackrabbit needed.. but I think that one didn't have true parallax. 'course the PC Engine only has one background layer too, but you can do split screen tricks that I don't *think* you can do on VGA. It's hard to separate out what's slow/bad on the PC due to people not harnessing the hardware well (see: FM music). Still, I think we got on this because of Ed asking about what it'd take to do 16-bit-quality stuff without acceleration. The answer: lots and lots of mhz

Re: the quality difference between CD-ROM2 and Super CD-ROM2 games is huge, I agree. Most of the time, it's a difference between being able to pull off better-than-Genesis graphics and not. IIRC, the sole difference is the amount of memory.

[Ghegs]

You want an RGB-modded PCE Duo-R? I got an RGB-modded PCE Duo-R.

[Edmond Dantes]

So, uh, what do you guys think of the PC Engine / PC Engine CD?

Best console ever.... when I feel like it.

I have the "Briefcase" model and I sleep with it every night. It's that good.

Also Galaga '88 is better than the arcade version. I sleep with that too.

[louisg]

[
Also Galaga '88 is better than the arcade version. I sleep with that too.

Oh what was improved on it? I really like the PCE version, and haven't played a whole lot of the arcade one.

PC Engine has a good selection of classics. It's got that Galaga, it has Xevious with a remixed/modernized game, Space Invaders with the same, ports of old games like Pac-Land, and the really insane 1943 Kai port that kicks into a nigh-impossible modern shmup halfway through. Seriously, it's a total fake-out. Too bad it's not better balanced.

And Skweek!

[Edmond Dantes]

To be honest, I didn't play the arcade version for long (MAME'd it just to see the differences) but the things I noticed immediately were that the PCE version's graphics seemed brighter/more colorful and for some reason the movement of the ship felt smoother in the PCE version. I can't explain, but I remember in the arcade one the ship felt like it was too slow.

[PC Engine Fan X!]

Paging PC Engine Fan X, please pick up the white courtesy phone.

Ah yes, somebody rang for me.

As for the venerable PC Engine platform, it's certainly a cult favorite amongst the retro gaming crowd indeed. The American NEC subsidairy branch was caught off guard when they lauched their TurboGrafx-16 console in the summer of 1989 and Sega launched their Sega Genesis console within a mere two weeks of each other. NEC had no clue or idea that Sega was going to pull that type of stunt off like that, so when TTI got around to releasing the Turbo Duo console in October of 1992, they made sure that no other major gaming console competitor was going to release theirs on that particular day. Not to mention TTI had plently of Turbo Duo demo kiosks set up at the USA based Toys-R-Us store in 1993-1994 as well to get the word out that it was out there to try out.

The 411 about the rarest TurboGrafx-16 Hu-Card title of Magical Chase with it's December 31st, 1993 release date is, it got very little retail distribution period. I don't ever recall seeing it for sale at the local Babbage's, Software Etc., Electronic Boutique, etc. during the entire 1994 year but it was up for sale for a mere $19.99 USD at the USA-based Toys-R-Us store in early 1994. I made the mistake of dismissing the TTI version of MC as a "kid's shmup" and passed it up. Fast forward to May of 1995, a local used video game shop had a complete but used copy of TTI MC for a mere $11.99 USD and snatched it up. Upon booting it up at home the same day, I found out that it was quite a stellar TG-16 shmup worth owning. There was no indication nor any clues that both the TTI Hu-Cards of MC & Legend of Hero Tonma (the USA-based TRU stores sold it at a $19.99 USD pricepoint in early 1994 as well) were the very last Hu-Cards to be released by TTI themselves. It wasn't until later on, that fact was disclosed/known amongst the hard-core TG-16 fans/gamers/collectors.

Nowdays, the commanding prices for a super mint and complete TTI MC set will easily fetch in the neighborhood of $1,400-$1,500! Some have been willing to pay more than that for such a mint and complete TTI MC set (but the TG-16 gamers that do have one in their gaming collection won't sell theirs, period). The cheapest way to be able to play it is with an Turbo Everdrive flash cart and boot it up on a PCE or TG-16 console setup and see what the hype and furor over the TTI MC shmup title was about.

Sure, it was possible to buy a brand new copy of TTI's MC from the Turbo Zone Direct mail-order business based out of Southern California back in 1995 for a mere $39.99 USD.

As for the many CD platforms that NEC put out over the PCE's lifespan, CD-Rom2, Super CD-Rom2 & Arcade CD-Rom2, it was necessary to get either an optional NEC Arcade Duo upgrade card or the NEC Arcade Pro upgrade card just to be able to play those particular games. With the only Arcade CD-Rom2 based shmup title by the name of Ginga Fukei Densetsu Sapphire, it's a fine PCE shmup in your gaming collection -- goes for about $250.00 USD or thereabouts these days.

If you want to see a real amazing tech demo of what the PCE is capable with scaling sprite effects, look no further than Sega's Afterburner II Hu-Card release. It was through some nifty assembler programming & Sega's in-house arcade expertise/wizardry, that such scaling effects was possible on the PCE platform (with it's 8-bit CPU & 16-bit graphics setup). Now, if NEC had come up with a SuperGrafx console with a dedicated 16-bit CPU on-board (rather than using the current 8-bit CPU in place), then things would've been quite different.

NEC hoped to recapture the popularity/glory of it's PCE platform with it's 32-bit powered PC-FX console but wasn't able to do so and thus, it was the end of a era.

The real reason why there wasn't more PCE game distributed/sold in the USA was that TTI had to negoiate and deal with each PCE game developer/publisher in Japan seperately - hence the resulting meager number of TG-16 & TTI gaming titles in the overall gaming collection. Now, you know the real story.

PC Engine Fan X! ^_~

[null1024]

If you want to see a real amazing tech demo of what the PCE is capable with scaling sprite effects, look no further than Sega's Afterburner II Hu-Card release. It was through some nifty assembler programming & Sega's in-house arcade expertise/wizardry, that such scaling effects was possible on the PCE platform (with it's 8-bit CPU & 16-bit graphics setup).

Holy crap, I just looked up a video, that scaling effect is cool. It's a shame it's only done for the large objects [the rest are done by sprite switching], but hey. It looks like a better port than the Genesis one too.

[louisg]

If you want to see a real amazing tech demo of what the PCE is capable with scaling sprite effects, look no further than Sega's Afterburner II Hu-Card release. It was through some nifty assembler programming & Sega's in-house arcade expertise/wizardry, that such scaling effects was possible on the PCE platform (with it's 8-bit CPU & 16-bit graphics setup).

Holy crap, I just looked up a video, that scaling effect is cool. It's a shame it's only done for the large objects [the rest are done by sprite switching], but hey. It looks like a better port than the Genesis one too.

I think that's really debatable. I mean, from what I've seen, people will swear that the PC Engine one blows the Genesis port out of the water. BUT.. as someone who likes the PCE and owns Afterburner II, here's my opinion: The 3d ground on the PCE version doesn't look 3d, but looks like it's sprites falling from the center of the screen-- it's a bit narrow and something makes me think it's even more faked than usual. Also, the plane autocenters, which makes it hard to pull off certain tactics. Despite this, it's way too easy. Now, the good: The music is great, it's one of the few versions with the lead on the first level theme, the scaling effects and colors rock, and there are fewer graphical glitches than the MD port. It's a remarkable version, and blows the hell out of most other ports either way.