Gaming History 101

Know Your Roots

Archive for the ‘Master System’ Category

Podcast: Sega Hits the Third Mark

leave a comment »

sms_post

 

This week Fred and Jam are celebrating Sega’s first console attempt, the Master System.  While a technical powerhouse against the NES, business practices in the US and insconsistencies in Japan made it a commercial failure.  It did thrive in Europe and Brazil, not to mention it’s quite an enticing package in hindsight.


Download this episode (right click and save)

Subscribe: RSS iTunes Google Podbean

Written by spydersvenom

September 10, 2014 at 11:00 am

Video: Retro Game Night – Zillion

leave a comment »

zillion

It’s taken a bit to get uploaded but this first part of Retro Game Night is going to be the “Metroid-like” (MetroidVania) title Zillion for the Sega Master System.  Click on the image above to be taken to the video.

Written by spydersvenom

June 6, 2014 at 7:10 pm

Version: Mortal Kombat

leave a comment »

In this new video series we dissect the home versions of the arcade classic Mortal Kombat.  Check out the roughly 10 minute video for a quick retrospective on the title and the craze that resulted in September 1993 as many kids brought this violent title home.

Written by spydersvenom

December 1, 2013 at 6:21 pm

Podcast: CIB – Complete in Box

leave a comment »

cib_post

This week Fred is joined by Chip Cella of the B-Team and Derrick H of All Games and Dead Pixel Live fame to discuss how games used to come packaged.  This includes the box, instructions, and a bunch of freebies we pay good money for today.

Opening Song – Joe Esposito You’re The Best

Closing Song – Iron Maiden Run to the Hills


Download this episode (right click and save)

Subscribe: RSS iTunes Google Podbean

Written by spydersvenom

September 11, 2013 at 11:00 am

Podcast: Me Money Bin

leave a comment »

ducktales_rm

This week Fred and Trees are discussing Capcom’s Disney games.  In the 8-bit era Capcom received the Disney license and created a little game called DuckTales based on the popular Saturday morning cartoon.  Not only was it a mass success, but it was an excellent game that gave way to a whole slew of 8-bit and 16-bit gems on Nintendo and Sega consoles.


Download this episode (right click and save)

Subscribe: RSS iTunes Google Podbean

Written by spydersvenom

August 14, 2013 at 11:42 am

Hardware Profile: Game Cartridges

leave a comment »

carts

It’s hard to believe, but the typical cartridge game began to phase out of gaming in 1995 when the new wave of consoles and the subsequent movement to disc-based media began. I’m sure plenty will be quick to point out that the N64 was a cartridge-based console, but I truly believe this decision was the result of Nintendo not wanting to give up the control over manufacturing and sordid history making a machine that read discs. This change happened 18 years ago, which means there is a significant number of gamers that are now in their early to mid 20s that have never played games on a cart. This is truly a shame because the versatility of cartridges is much more abundant than most people realize, but the crutch will always be that carts offer little storage for massive prices. In today’s lesson we will discuss what makes up a cartridge, benefits/setbacks, and how the cartridge was used to literally upgrade consoles for more than two decades.

Anatomy of a Cartridge

NESCartridgeOpenFor the most part a cartridge is a plastic-encased board containing “read-only memory” or ROM data that has exposed pin connectors (male) that fit into a slot on the reading device (female). Since it’s a complete circuit board, multiple ROMs can be used to store data, which we will get to in a second, and allow for an expanse of memory based purely on the connected printed circuit board (PCB) and the device reading it. Of the most popular uses for ROM carts is software for computers that expands almost solely into gaming once game consoles begin to release. It was the dominant format for many microcomputers, mostly used outside of the United States, and almost all game consoles for two decades (mid 1970s to mid 1990s). Many believe that the use of a cartridge was due to no other decent format being available, but this is simply untrue. By the time carts were in use, programs/games could be loaded via floppy disc (5.25″), compact cassette tapes (not unlike audio cassettes), and removable circuit boards (think arcade machines). The decision to use cartridges was due to the fact that the memory was permanently stored in the chip and memory mapped into the system’s address space (ie: it was basically integrated into the machine). As a result data access was almost instant (no load times), the cart could be used for hardware expansion in addition to loading code, and due to the streamlined process it was very difficult to extract the code and thus safest for mass distribution of software. Unfortunately it was also quite expensive and thus storage space was expensive, not to mention that the code could never be altered or accessed, which made for difficulty with saving and loading.

The first console to use cartridges was the Fairchild Channel F, a game console that predates the Atari VCS/2600 by a year and featured many of the same aspects of the pop culture sensation. It is not as widely known due to the similarity of titles that were mostly archaic sports titles or educational material. Naturally in 1977 when Atari introduced the VCS with arcade ports and diverse addicting third party titles like Pitfall resulted in the streamline of the format. Due to the fact that the cartridge is an integrated part of the machine, Nintendo made heavy use of the cartridge to make both the Famicom and the NES capable of keeping up with changing times for quite a while. Not only that but some carts, especially in Japan where custom chips were allowed, were capable of acting as a game, a hardware upgrade, a save state, and an anti-piracy device all at once. This practice was pretty standard for most consoles that utilized carts until the aforementioned 32-bit era where expansions moved to actual hardware expansion ports and even the N64, which could lean on carts, used ports instead to expand the on-board RAM.

ROM types and Special Chips

EPROM

EPROM

The oldest ROM type is Mast ROM, which refers to information stored permanently via integrated circuit when the chip is manufactured.  The term “mask” refers to the masking pattern on the integrated circuit when it is created.  This is the oldest form of ROM and definitely what went into the creation of Nintendo carts, which were manufactured by Nintendo and worked as a supplemental business to the license fees and cut of each unit sold on the NES.  This is the cheapest way to get the most memory, however unless you have a mass production line the masking of the integrated circuits can be a costly endeavor and without the vast quality controls like Nintendo had one poorly made program or coding error can ruin an entire production.  You can understand why Nintendo was so strict back in those days, especially because masked integrated circuits cannot, by their very nature, be re-written or reused.  The up side is that there is little chance once successfully produced that the chip will suffer decay, failure, bit rot, and various other issues that can plague other ROM types, which is why you will see most classic carts last nearly forever (please note that the save battery memory is a different story).  I know that this was the most common type in all Atari consoles, NES, Turbografx-16, and Sega Master System.  Beyond that it is entirely possible that the SNES, Genesis, 32X, and portable consoles may have used other formats like  Erasable Programmable ROMs (EPROM) that allowed you to reprogram chips with ultraviolet light or Electronically EPROMs (EEPROM) that allow you to erase and re-write electronically.  There are generic PROMs that can be created with a ROM burner and remove the need to produce them like a mask ROM, but they are still one time use and were more for arcade and pinball repair, which may mean they can be found in Neo Geo carts.  As for Jaguar and N64, I’m guessing EEPROMs, but there’s still a striking possibility that these companies known for mass production of carts since the 80s still made traditional mask ROM carts, especially with the lowering price of PROM and the relative high emulation/piracy of the late 90s.  It has been said that PROM, EPROM, and EEPROM may have a higher chance of failure, but most carts don’t seem to have a problem no matter what is used and plenty of fixed arcades have had no problem whatsoever (especially because they can be wiped and reprogrammed).  ROM chips typically varied in size from 2 kbit (not to be mistaken for the large 2 kbyte) that held roughly 256 bytes all the way up to the expensive 32 megabit chip that held 4 megabytes.  This is why you saw statements on Street Fighter 2 that said things like “32 MBit Chip!” because it was touting massive storage space.  Some games are rumored to have even larger ROM chips that compressed data and justified hefty price tags like Final Fantasy III launching for $80 in the US or Street Fighter Alpha 2 having load times on the SNES while data uncompressed.  It was all par for the course when trying to get as much data on a cart as possible.  I do believe that as RAM was integrated into consoles, like we saw on the N64, that compression and temporary storage allowed for more data to be stored for the larger 3D games of that console.

In addition there can be extra chips placed into the carts to allow all kinds of extra functionality, which basically means the carts acted as hardware upgrades.  This makes sense when you think about the massive leaps between launch games and later releases.  2600 carts were pretty straightforward, but NES carts had a few extras like the anti-piracy NES10 chip that was required to be on the PCB in order for the NES to play (if it doesn’t detect this due to a loose connection you get the popular blinking console effect, which is the NES10 chip on the console rejecting the cart).  Saving became a large feature as well, which led to almost all cart-based save states to be stored on Static Random Access Memory (SRAM), which was able to keep save data stored after power is cut (uncommon for RAM) provided that a small current still passed through.  This is why a lithium button cell CR2032 battery is used in most cases and once that battery dies (typically around 20 years, but can go much longer) the SRAM no longer functions.  To fix this, simply de-solder the dead battery from the SRAM leads and solder in a fresh battery to the leads.  In Sonic 3 as well as a few others, Sega decided to use much more expensive non-volatile RAM (NVRAM), which was an early form of flash memory we have today and retains information after power is cut, which is why Sonic 3 carts should retain save data indefinitely.

As for expanding the functionality of a console, special chips could literally upgrade a console to allow it to do things it was never intended to do.  In Japan the Famicom was allowed to have special chips put into its carts so companies could go crazy on internal development – due to no video game crash, Nintendo did not force Japanese development studios to manufacture carts through them like in the US.  This explains the VRC6 chip in Akumajo Densetsu (Castlevania III) that allowed for extra channels on the Famicom’s unused sound port.  In America Nintendo began releasing special Memory Management Controller (MMC) chips that allowed for some of the Japanese innovation to happen on the NES, albeit in a stripped form due to the different hardware profile of that console.  Here are some of the popular chips:

  • UNROM: Split the program data from a 32 kbit chip into two 16 kbit chips, one that stored the data and one that transferred data to RAM chip for faster loading and effects.  This was seen early with impressive titles like Ikari Warriors and Mega Man and assisted in side scrolling of dynamic characters and certain effects.
  • MMC1: Allowed for save games.  In addition to having 16 or 32 kbit ROM programs, 4 and 8 kbit SRAM was integrated and powered with a button cell lithium battery.  This was essential to getting Famicom Disk System titles that had save data to run on NES carts such as Legend of Zelda, Metroid, and Dragon Warrior.  Although Metroid didn’t support saved checkpoints like the FDS version did, massive passwords allowed pre-stored save data.
  • MMC2: Basically split a 32 kbit chip into a 24 kbit chip with two sets of 4kb banks for pre-loaded graphical data.  It allowed more graphics to display on screen at once due to the additional banks being only referenced without assets in the main code.  Only used for one game, Mike Tyson’s Punch-Out!! to load the massive sprite opponents.
  • MMC3: This massively split the memory allocation and integrated a scanline IRQ counter to allow for certain assets to scroll while others remained stagnant.  Necessary when keeping dynamic items like consistent scores, life bars, and more fixed on the screen and moving while a second “window” was performing more dynamic gameplay.  Nintendo’s most popular chip and key in many large titles such as Mega Man 3 and Super Mario Bros. 3.
  • MMC4: Utilized only in Japan for the Fire Emblem titles to create effects similar to the MMC2.
  • MMC5: The biggest, most versatile, and most expensive chip Nintendo offered.  Developers avoided it like the plague due to the high cost and reduced profit margin.  This had several different memory allocations, IRQ counters both horizontally and vertically, allowed for very dynamic effects, and opened extra sound channels along with a 1KB of active RAM.  Since Koei was almost the sole user and none of its MMC5 titles came out in America, the only title to really use it was Castlevania III to create a similar, but still inferior, version of the Famicom title in America.  The MMC5 chip was so complex that almost all clone consoles do not support it and emulation took a long time to decipher integration of the ROM.  For this reason alone Castlevania III was one of the few games you had to have original hardware to run.  Emulation is currently no problem however clone systems that run actual carts still do not support the title.
  • MMC6: This final mapper chip extended the size of SRAM over the MMC3 chip by 1KB, which allowed for the larger save files of Startropics and its sequel to save games.

There were more custom chips that did eventually show face in America, but these were the most common and basic chips.  Nintendo would loosen their policy and generate several custom chips for the SNES as well allowing for all kinds of impressive hardware tricks.  Some of those are as follows:

  • DSP: The digital signal processor chip allowed for various 2D and 3D calculations in several iterations that allowed for asset conversion for older graphics techniques, rotation effects, raster effects, and mathematics that could all be performed independently on the cart instead of using the SNES.  Popular games that used this rotation technique are Super Mario Kart and Pilotwings.
  • sfx_snesSuper FX: This was a supplemental CPU for performing graphics calculations that the SNES simply could not do.  Think of it as an external graphics card for the 16-bit console, as it was a separate 16-bit CPU integrated into the cart.  Since it had simpler duties than the SNES, the Super FX chip’s iterations were capable of 10.5 mhz and eventually 21 mhz of processing power, which blows past the 3.5 mhz processor of the SNES and allowed for the 3D rendering of titles like Starfox.  Later updates allowed for support of larger ROM sizes (for a long time the game program had to be less than 8 mbit or 1 mbyte of data).
  • Cx4: This chip was Capcom’s way of showing off rotational, polygonal, and wire-frame effects in the Megaman X series.  While the first title used a traditional chip, Megaman X2 and X3 had special test screens and crazy title screens that to this day cannot work on cloned consoles, flash carts, or even later hardware emulation (like the Megaman X Collection on PS2/Gamecube).  Of course the emulation community has successfully gotten this working on software-based ROMs.
  • SA1: The Super Accelerator chip that independently worked with the SNES as a co-processor creating a faster 10 mhz clock speed over the 3.5 of the original hardware, faster RAM functionality, MMC capabilities (see the NES section above), data storage and compression options, and new region and piracy lock out protection.  This chip was essential in certain impressive titles like Super Mario RPG! and Kirby’s Dream Land 3, which cannot currently be replicated on flash carts.  Software emulation on both the openware PC scene and official Nintendo Virtual Console titles do support the chip.

There were several others that were utilized for specific function in addition to the Genesis having the Sega Virtual Processing (SVP) chip in Virtua Racing to make the most technically impressive 16-bit game ever created.  Unfortunately it also cost $100 at initial launch, wasn’t impressive from a gameplay standard, and doesn’t work with any clone or flash carts out there.  Emulation is possible but with varied results.

Well there you have it.  A brief breakdown of the technical marvel that was the cartridge and the hardware benefits it provided.  It’s almost difficult to imagine a world without load times, where data access is instantaneous (something even flash carts can’t currently do).  While it wouldn’t be possible with the massive memory required today and the equally massive cost of manufacturing, there was a time where a few bits in a plastic case meant to world to each and every gamer.

Written by spydersvenom

July 30, 2013 at 8:35 pm

Retro Game Night: Sonic Xtreme and Sonic Blast

with one comment

This week we play the two 3D Sonic titles most of you have never touched.   First up is the unreleased demo of Chris Coffin’s late in the development cycle version of Sonic Xtreme as discussed on this week’s podcast:

And next is the Brazilian Master System port of the Game Gear’s final Sonic title, Sonic Blast, which utilized much of the same technology as Donkey Kong Country:

Written by spydersvenom

July 27, 2013 at 11:00 am

Retro Game Night: Sonic the Hedgehog, 8-bit Edition

with one comment

This week in honor of our Sonic podcast, I’m playing the 8-bit (Master System/Game Gear) outings of Sega’s mascot.  If you’ve never seen them before, they are drastically different than the 16-bit versions.

First up is the original Sonic the Hedgehog:

Next is, obviously Sonic 2:

And finally, Sonic Chaos (Sonic & Tails in Japan), which was to be the 8-bit companion to Sonic 3 had it not been delayed:

Written by spydersvenom

July 13, 2013 at 11:00 am

Podcast: Blast Processing – The Story of Sonic

leave a comment »

sonic_post

This week Fred is joined by Ali (@thealmiesta) and Andy (@damien14273) from the 42 Level One podcast to discuss Sonic the Hedgehog.  With a heavily documented history, Sega’s official mascot to combat Mario had quite the history.  In part 1 we discuss the origins of Sonic and all of his 16-bit era outings (which include his 8-bit Master System/Game Gear titles, spin-offs, and his CD outing), complete with the games themselves and the stories of development. While long, there’s no lack of content or stories tethered with the beloved hedgehog.

Opening Song – Sonic Theme (from Sonic the Hedgehog on Genesis/Mega Drive)

Closing Song – Sonic Boom (from Sonic CD on Sega CD/Mega CD)


Download this episode (right click and save)

Subscribe:   RSS   iTunes   Google   Podbean

Written by spydersvenom

July 10, 2013 at 11:00 am

Getting It Backwards

leave a comment »

ds_nesVideo game consoles are one of the most interesting electronics items on the market for several reasons. Probably the most prolific is the fact that there are frequent hardware upgrades, which we call generations, that move home consoles forward. Because each new console is basically a piece of hardware frozen in time, the need to innovate and improve on future games demands that they be constantly updated. This works counter to movies or music, which see improvements from new hardware but don’t require the upgrade to enjoy the medium. Imagine if you could play Super Mario Bros. on the Wii but with drastically upgraded visuals or Dead Space on the original Playstation with the juxtaposed setback, this is exactly what we see when we watch Ghostbusters on VHS versus DVD versus Blu Ray. As a result new consoles come out all the time, typically in 5-8 year intervals, and usher in a more interactive experience – it’s important to note that the greatest difference between games and other media is that they are active, not passive experiences – and with it comes a new format for software.

Enter the concern of the consumer. It can be frustrating for both gamers and parents of gamers alike to purchase a new console, especially when it renders an entire collection on an older console useless. As retro gamers I’m sure we see the value in it, but for the majority there’s a want to move forward and never look back. Well, that is until there are enough new games to get me to migrate over. This is another slow start that prevents all but early adopters to purchase new hardware, which can then result in fewer sales. With fewer sales comes more canceled projects on new hardware, which then results in fewer sales of the hardware and the cycle continues until a console is considered dead in the water. Just look at the Virtual Boy, Jaguar, and possibly even the WiiU about this problem; developers have enough to worry about, they can’t also deal with poor penetration rate due to a false start console. One excellent solution to help usher in that awkward period between consoles is the concept of backwards compatibility, or a new console that can play a previous generation’s games.

bc_SonyBackwards compatibility started off as mostly an afterthought, typically triggered by a new console’s use of inexpensive available hardware for another component in a new console. For the most part this was sound boards – the Genesis used a Master System processor for sound as did the Playstation processor for PS2’s I/O port. That made it easy: either use a firmware initialization string or hardware bypass to force the sound chip to be used as the older hardware rather than its intended use. This isn’t always the case, though, and many consoles utilized such drastically new hardware or are so complicated in architecture that making a new console backwards compatible is impossible. All three main console manufacturers ran into this problem with the current generation and had to increase the cost of the machine to prevent lack of backwards compatibility from being an issue. In the case of Nintendo, extra components were installed to make Gamecube accessories and media possible, while the similar architecture of the Wii allowed it to become an overpowered Gamecube. Microsoft had an entire new hardware architecture and opted for software compatibility, which was terrible when it first launched and unnecessary when it was fully integrated. It still shocks me how many people don’t know the poor quality of many original Xbox titles on 360 and how many of the console’s best games are completely unplayable. Sony, fearful of what they saw with Microsoft and holding the largest console library of all time with the PS2, opted to just shove an entire PS2 motherboard into the PS3, making it the biggest console of all time (so far) and costing up to $600 at launch. This was the point at which both the industry and gamers found their limits and suddenly backwards compatibility may not have been all that important. At this point no one cares about backwards compatibility in modern consoles, it has been stripped from Wii and PS3 (which generated significant price drops), and the previous consoles are so cheap that they are worth re-purchasing if absolutely necessary.

It’s important to keep your eyes on the prize and prepare for the next generation of consoles, all of which will be available by this holiday season. Backwards compatibility is good, but rarely is it as good as the original and it will never be worth the expense. Before giving a used retailer your PS3 or 360 for a mere $50-$100 off your new expensive console, consider holding on to it just in case. Like a hard drive in a 360, you’ll surely find it saves you money in the long run. After all, isn’t it about time you joined this retro gaming revolution?

Okay, so here’s why you probably clicked on this article in the first place, the list of backwards compatible consoles. Below is not only the list, but an explanation as to how each console achieves it (mildly technical):

  • ColecoVision: With an add-on, which provided the necessary chipsets to do so, the ColecoVision could become an Atari 2600, however there were almost no similarities in hardware (which explains the need for the add-on). This was legally allowed because Atari didn’t use proprietary hardware and thus it was like two manufacturers making the same specs on a PC. Unfortunately for Atari, this hit came twice as hard because the 5200 was not backwards compatible either. With the courts ruling in the favor of Coleco, they even created a clone system called the “Coleco Gemini” that was, chip for chip, an Atari 2600 and sold it in stores.
Coleco Gemini (Atari 2600 Clone)

Coleco Gemini (Atari 2600 Clone)

  • Atari 7800: This was the first console to actually be backwards compatible and played both 7800 and 2600/VCS games, but not 5200. Atari fans were livid with the 5200’s lack of 2600 backwards compatibility, which made sense considering the 5200 contained updated versions of most of the 2600 library. The 7800 ran a SALLY 6502 processor, which could be slowed to 1.19 Mhz and thus operate like the stripped 6507 of the 2600, and then a television interface chip created graphics/sound while adapted chipsets allowed the 7800 to function with limits to the confines of the 2600. This would have been implemented sooner than the late release window of the 7800 had the console not been shelved for over two years after the video game crash.
    Known Issues: Atari integrated a content lock-out chip that blocked adult 2600 games (Custer’s Revenge, etc).
  • Sega Genesis/Mega Drive: The Sega Genesis may have used a 68000 processor for its “blast processing” but it also used the Master System’s Z80 processor for its sound chip. Thanks to an add-on called the “Power Base Converter”, which plugged into the cartridge slot and gave the Genesis a Master System cart/card slot, the 68000 was deactivated and the Z80 took over. This made the Genesis literally turn into a Master System, which was one of the first to do so thanks to the previous console’s co-processor chip.
  • Gameboy Color: While it may seem to be a no-brainer, the Gameboy Color actually has significantly more processing power, RAM, and palette as its predecessor. This is why you cannot play Gameboy Color games in a Gameboy, it just can’t keep up. On the other hand, the Gameboy Color was backwards compatible with Gameboy thanks to a few of its similarities. For starters the Sharp LR35902 processor was merely an adapted (possibly overclocked) version of the Gameboy’s Z80 processor, screen resolution and cartridges were the same, and RAM was merely three of the Gameboy’s RAM chips. As a result the machine could be locked off into “Gameboy” mode, much like the 7800 could do for 2600 games, and the four hues of green on the Gameboy were adapted into multiple color pre-sets that the user could choose from.
  • Gameboy Advance: Like many other consoles, the Gameboy Advance used a Z80 coprocessor for its sound chip. This allowed the console to play both Gameboy and Gameboy Color games by simply making the co-processor function as the only processor. Pressing L and R buttons allowed you to toggle between the original resolution and a stretched version in the larger GBA resolution.
  • Playstation 2: It’s hard to find good techinical data on the topic, but I’m fairly certain that the I/O port processor, or the device that reads the media and transfers it to the hardware, utilized the PS1’s R3051 33 Mhz processor. This meant that when it was reading a disc and detected it was a PS1 game, it could stop sending information to the PS2 and simply function as a PS1 instead. Having no true knowledge about how these consoles work beyond that, I can’t tell you for sure how it was able to control all other aspects of the system needed to play PS1 games, but that’s how it was able to do so.
    Known Issues: Due to the console not having the true hardware configuration of the PS1, there is a short list of games incompatible with the PS2 depending on your console. Oddly enough, the slimline model was even incompatible with some PS2 games.
  • Nintendo DS: Nintendo definitely wants to keep its legacy alive, and repurposing the chipsets of older consoles is an inexpensive way to innovate, but the DS was the first console not compatible with all previous consoles. While it does technically have all the hardware needed to play all previous portables, the DS only has a cartridge slot for the Gameboy Advance and the later DSi and DSi XL models have removed that slot completely. Still, for those that have a DS or DS Lite (preferred), you can run any GBA game you like on it.
  • Xbox 360: Light years had passed, technologically speaking, between the original Xbox and the 360 even though ironically only four short years had passed in actual time. The 360 and its predecessor were both basically streamlined computers and their hardware configurations were so diverse that it would be impossible to have the 360 function like an Xbox. Microsoft’s solution was software emulation. With a scant 733 Mhz Pentium III in the Xbox and a beefy 3.2 Ghz multi-core PowerPC in the 360 the console was basically running an emulator when it plays Xbox games. As with most emulators, especially early on, the results are scattered with lots of odd effects. It’s not true backwards compatibility.
    Known Issues: Plenty. It was such a headache that after only two major updates Microsoft discontinued support. A large number of games will work, although the setbacks can be as simple as ghosting in Halo 2 and as drastic as the crawling framerate of KOTOR.
  • Playstation 3: Sony’s answer shows the extensive hubris they had in the wake of the Playstation 2: jack the price of the console up $150 and slam an actual PS2 into it. There’s no reason to have the PS2 hardware in the console except to play Playstation 2 games, which accounts for the massive size and equally massive price tag. It has some value, though, because these early models provide significant graphical upgrades over the PS2 and are the best way to play its games. Eventually the PS3 dropped the hardware, resulting in a $200 retail price drop for the console, and attempted software emulation that came with a whole new batch of issues. Nowadays, and since 2009, the PS3 has had no PS2 backwards compatibility whatsoever. If you’re looking today, any launch 60GB and 20GB model is fully backwards compatible with PS2 because it has a literal PS2 built in. Any 2008-June 2009 80GB models are software backwards compatible, which is best tested by popping a PS2 game into the console and seeing if it plays. The gunmetal grey Metal Gear Solid limited edition 80GB console is also software backwards compatible. All models of the PS3, including the slim models, support PS1 games. There are PS2 games available on the PSN, which are re-programmed to support the PS3 hardware.
    Known Issues: Original 60GB and 20GB have no issues, they are essentially PS2s as well. Software emulation has a long list of unsupported games and issues just as the 360 does.
Original Wii Prototype

Original Wii Prototype

  • Wii: The age old joke is that the Wii is two Gamecubes duct taped together in the box. While this is not true, there is some truth behind it. The Gamecube and Wii use an IBM PowerPC processor and ATI graphics architecture in the same configuration, which basically means the Wii is a mildly souped up version. As a result, the Wii can easily re-create the Gamecube library by literally adjusting the processor speeds. In 2012, Nintendo discontinued Gamecube backwards compatibility, which can be determined by searching the outside of the console for Gamecube controller ports.
    Known Issues: For the most part, none. All backward compatible Wiis are also Gamecubes. There are some limited hardware issues when trying to play hardware-specific games or integrate accessories like the Gameboy Advance cable.

Written by spydersvenom

May 2, 2013 at 6:10 pm

Follow

Get every new post delivered to your Inbox.

Join 505 other followers