kool kitty89

The mambrane buttons are interesting, though I'm not sure how comfortable they'd be to use, inless they were revised with a domed surface (to provide better tactile response) And I beleive some mambrane buttons tend to ware out more than some other types, though it would depend on the quality. (i've got a bunck of those old interactive kids books with speech/soud FX buttons, membrane keys, with many buttons that are worn out; again this may just be cheapness) Either way they're cool from an esthetic standpoint. If they scrapped the new joystick case design and stuck with the classic CX-40 (and CX-20 and -30 driving/paddles) then the storage bin would be less practical (the paddles and probably keypads could fit but I doubt the CX-40 would), wich they'd probably remove for cost reduction as well.

Ah, do you prefer to use the CX-40 for most single button games? (and do you have the screw-in thumbstic for the joypad?) Have you tried the Flashback's mini 7800 controller, it seems like it might be a bit more comfortable? (I think it's compatible with the 7800, though I'm not quite sure if they wired button 2 the same way...) I was noticing this trend when looking at various refrences to RAM IC sizes, though I hadn't seen any specfics on it. Is the same thing true for DRAM? Reading several articals and a cfew discussions it seems to imply this, and the charts here: http://phe.rockefeller.edu/LogletLab/DRAM/dram.htm only show IC's of 4, 16, 64, 256K, 1, 4, 16, and 64M. (so it would seem the same 4x multiple, albeit starting a 1 or 4, rather than 2)

The gameboy was compact, initially much cheaper than its competitors, had a very long battery life on 4 AA's (with standard alkalines still long by today's standards), and was backed by the biggest name in video gaming market (in NA and Japan) at the time. (and lots of software support) Also a reflective screen may suck in dim situations, but beats a (similar quality, of which the original GB's screen was not) backlit screen in direct sunlight (even Nintendo's DS sucks there). Nintendo users were stuck with unlit reflective screens untill 2003, so that's a long time, so any competition wouldn't be at a disadvantage in that respect and prior to 1998 they'd have the color advantage as wel. (same going for the Game Gear) I still use my original gameboy, and granted the screen blurs a bit (durring motion), but I end up using it far more often than the pocket, or my little brother's GBC or GBA (which have superior screens) For one reason, I prefer the feel (the others are actually a bit too small), the battery life still seems better than the others (most certainly the CBPocket), definitely has the loudest speaker (without headphones) and I've never really minded the screen quality, I actually like the softer look of the green screen to the sharper GBP/Color/Advance. Now this may be partially be due to me being nearsighted, and thus seeing very well up close, so I may have less issues with seeing the screen than others; I've never really had trouble with seeing it clearly, even in moderate light conditions. (though obviously it isn't good in dim conditions, though I still find it useable indoors, away from unshaded windows during the day, with lights off) I was never suggesting a transflective baclit screen either, as I think I've clarified a bit, I meant a noremal reflective screen with no light at all. However, without a transflective screen or true bbacklight, you could stll have built in lighting in the "sidelit" fassion, as Nintndo did with the Gameboy Advance SP. This could allow the "sidelighting" to be provided by a couple LED's directed through a diffusing filter to scatter the light fairly evenly accross the screen, and still far more energy effecient than the flouro tubes used to light the Game Gear, Nomad, and I assume Lynx as well. The only actual issue with using less batteries (technically speaking) would be modifying the system to run from a lower voltage power sourse. (6V instead of 9)

Meh, there's the FM Towns Marty, PC-FX, and Apple Pippin to considder as well. (I think the 32x and Virtual Boy were a bit ahead of other failures, pending the actual numbers for the 3DO)

A problem with doing Star Fox 2 is it requires the 21.48 MHz Super FX 2, the only games using that are Doom and Yoshi's Island (the former lacking a save feature. Both of which use 2 MB (16 Mbit) ROMs, while Star Fox 2 is only 1 MB, so I think the program would need to be "doebled" to work in these. I found a thread on people woring on these awhile back, but I cant remember where... You could use a Super FX cart (Star Fox, Stunt Racer, Vortex, and Dirt Trax) Vortex (and maybe Dirt Trax) are only .5 MB (4 Mbit) so those are no good, which leaves the original Star Fox and Stunt Racer FX. It has been shown to work (a guy in the aformentioned forum had it working using a Stunt Racer cart) but it runs pretty slow and I'm not sure how much overclocking you can push on the GSU-1 (SFX-1). I've heard of people pushing the imput signal past 24 MHz but this still only means it's running at 12+ MHz. (which will help with slowdown in Star Fox but insufficient for Star Fox 2)

ataarian63 I'm not sure what you're getting at, do you mean create a subsidiary or partner company specifically to build the Jag through and then going public, using the stock market to get the necessary funding? (the very thing Bushnel's Atari had considdered and dissmessed at the time in favoe of a merger -with Warner- due to the poor stock market at the time) Was it a good time to do this, in terms of the economy in 1993? Furthemore, with Atari's computer market drying up what would they do, act as a holding company and continue to support the Lynx possibly along with sone legacy support for their computers? On the topic of hardware again I got thinking. It's been mentioned that using ARM or MIPS (the latter used in the CoJag) processors to replace the 68k would be too expensive (some ARM's like the 3DO's would also still be speed limited and lack cache), while building another J-RISC would take further development, and just like the 68k-less proposition, having good tools for the JRISC's would be key. What about other chips on the market, it was mentioned already that Intel chips would not work with the current interface (and adapting it would be expensive, and using such a CISC processor would still not be advantageous over the comperable 68k series (ie the 020), especiallt the 386 which lacks an onboard cache. However, another commercially produced RISC chip might warrent consideration, especially one optimized for low cost consumer applications; what if a Hitachi SH2 (ie Saturn and 32x) was used in place of the 68000? Would the interface have supported it or have been practical to modify for it? As I understand it, the SH2 would be significantly cheaper than the aformantioned ARM or MIPS chips, was powerful, with a decent amount of onboard RAM (4K cache of which 2K was able to be used as scratchpad RAM), and with tools already available as with the other comercial chips (granted not as common as something likt eh 68k archetecture), and easily able to run as fast as the current J-RISCs (I beleive it was limited to 28.7 MHz, at least the early models) I beleive it became availabe in 1993, so it would be new, but still proctical for the timeframe. (an SH1 would not be a good option, as I think it was limited to 20 MHz at this time, was less cycle efficient than the SH2, and lacked the onboard cache)

He is the one that pointed out the reason interleaving wan't a good option either. The cart's he describes would still only be using a single circuit board, but presumably with prong like portions of the board containing additional connectors, sot of like the extra ones used on some enhanced SNES carts. (granted these only added 12 pins) I actually considdered this myself, but there's a problem. Doesn't the 2600 slot have prongs to unlock the built-in dust covers on the Atari produced 2600 carts? Without these you'd loose the compatibility, and these plastic prongs are located in the same place as the proposed added cart connectors would go... (inless you made the carts super wide to compensate for this as well) The main reason I mentioned a seperate bus for Maria would be to keep it from being slowed down by having to share the bus with the CPU, though with slower DRAM, I don't know how much of an advantage this would be over shared SRAM. (plus there's the speed issue of the CPU feeding graphics data after reading the ROM, instead of MARIA having acces to the ROM itsself) The option of simply adding more SRAM might be interesting, it was braught up that using a single 8K SRAM instead of the par of 2K ones would save space as well. (I'm not aware of what other IC sizes would be available, but no 4K SRAMs weren't available?) Of course this could add to cost, depending on the relative cost of the 2K and 8K chips, and if there would be significant savings from having one less chip on the board. (or course adding a POKEY would effect this as well) DRAM is cheaper, but slower and requires the refresh circuitry, so would the system be worse off with say 16K of shared DRAM in place of the 4K of SRAM? Also, what are you guys thoughs on the joypads for the 7800, should they have been used in the US as standard, replacing the proline sticks, probalby keeping the prolines available as accessories for those that prefer them. (though I think most games that are better with joysticks would probably play better with the CX-40 anyway, particularly Robotron in dual stick mode)

You'd have to modify a lot of stuff, the sound hardware was a bit weak (though flexible, using DAC with the CPU -no dedicated sound processor or DSP- is limited -the CoCo did this too). You'd also have to modify the video hardware, I don't know if it was capable of higher resolution, but the 16-color limit is certainly significant. Plus, it would still be pushing against the Genesis's release date and still have to cut through Nintendo's tight market. (which really wasnt acheived until 1991 by Sega) I'm not sure whay they released dev tools for the Amiga only (did they release other later?), it would seem a little odd to limit themselves like this. (granted I would assume the Amiga decision would have been made prior to Atari picking it up -other wise that really makes no sense) in the line of a home console, it would have been better to go with something derived from the ST line, I'm not sure how much it could have been optimized and modified for the task (stripping it down and altering some of the video and audio features to better support this), but at minimum it could have used the same video, added an FM synth chip, some nice controllers, and a good case design. (with a consolidated board with perhaps 256 kB of RAM) Basicly released in place of the XE Gaming System- in 1987. (you could even use a similar case design, though honestly I'd alter the color scheme a bit, perhaps the traditional Atari black, seperating it from the compuer, and making it more reminicent of their game consoles) I beleive '87 and '88 were the 7800's most successful years as well, so this would give it time to pick up steam before becoming the main system. (and a good head start over the Genesis and SNES, not to mention lacking the issue of clashing with the Jaguar, as a Falcon based console might) Again this is getting off topic, and as I already mentioned, IMO the bast hardware change on the Lynx would be elliminating the backlight in favor af a reflective screen, and a more compact design using fewer batteries. (preferably smaller than the Game Gear)

Yeah I know about the 2800, though its a bit different, and certainly a new overall design. (I beleive the 7800's case was identical though, or perhaps with only minor modifications, like the angle) And of course there's also the 2600 Jr. though I'm not entirely sure why they didn't go with the 2800 in that case (perhaps tho reduce confusion with the 7800, and perhaps the Jr's case design was even cheaper), or why they didn't use different controllers with the 2600 Jr (initially they'd planned to use the 7800 proline sticks with the 2600 Jr.) The Jr's case design had been recycled from the cancelled Voice Commander Module project. Another reason the 2800 probably wan't picked up over the Jr. was it used semi-incompatible controllers; it used 4 controller ports and controllers that were combination paddle/joysticks (hence the dual buttons), so that would confuse things with the rest of the 2600's hardware in the US (though it wouldn't be an issue in Japan). Also the 2800 didn't come about until close to the crash and well after the launch of the 5200. Perhaps it was simply cheaper to switch to the Vader 2600 case design (presumably they'd have used the 2700 case arround the same time as the switched to the Vader), and the new stylish look wasn't felt to be worth it. Though technically, the 2700 design already had ports for the standard joysticks/paddles (on the side, which was more convienent than on the back of the 2600/Jr) and removing the back tray could have saved cost (and should change things minimally), you could probably chop off a bit more than just the compartment as the RC receiver equipment would be elliminated. Then the only issue would be the styling of the paddles/joysticks, thy could easily have adapted the 2700's controller into a single joystick, dual paddles, and a driving controller to go with the revamped case, or you could continue to use the 2600's standard controllers. As seen here: The 2700 is quite a bit larger than the 2800, though removing the storage bin could reduce this alot, and the Jr. would be even smaller (though not really any narrower). Perhaps another reason they favored the Jr. case design is it could use the same board as the late CX-2600A's had, with the same controller port and difficulty switch locations. (the only changes would be the power, B/W, select, and reset switches)

So Tramel Technology was in a better position than Ninrendo? (I'm talking 1984 here)

http://en.wikipedia.org/wiki/User_talk:Mcjakeqcool Luckily wikipedia is pretty tight in correcting this kind of stuff, they even caught my edit on the Atari 7800 sales figures (of which there are none listed) as I used Curt's thread as a sourse. (discussion forums are not a valid resourse; I couldn't really just use his name though, and the text file was indefinite as well, and only downloadable, not an actual web page)

Nah, that was just the particular programmer, and was Pacman specifically, not JP games in gereral iirc. (look how well Space Invaders turned out, for example) But this idea about Atari buying Nintendo is just dumb, in 1984 they were in the pit of the video game crash and Warner had been looking for a way out, and found it with Tramiel. Now Warner could have possibly been in a position to buy out, absorb, or get specific rights with Nintendo in America after dumping Atari, though I doubt a total buy-out would be accepted. Remember Nintendo was doing well with their system in Japan, launched in 1983. (and Sega's SG-1000 was doing poorly) Atari itsself, under Warner or (especially) Tramiel, would be in no position to buy out Nintendo, actually it could have been the other way arround (N buying Atari off Warner's hands), and Nintendo may have considdered it, but Atari's name was soiled to retailers due to the crash, thus there wasn't too much of a point. (though the brand certainly still held a lot of weight in the public, so there would be that advantage) This latter bit is much more conceivable (though again a mixed bag as there's Atari's debt and soiled rep with retailers), it's still weird to think of though, Atari becoming Nintendo of America.... Yeah that's defintely an odd one. (an , of course the 7800 would never be fully launched, possibly the 2600 Jr. as a budget machine as it wouldn't be in direct competition with the Famicom/NES/"AES" and Atari's 8-bit computer linewould still be profitable, and certainly not in direct competition with Nintendo's system)

Or ratherAtari was owned by a company with deep pockets. (Warner Comunications) Though the 2600 did have other advantages as well, and the Atari name had been growing by the time they were picked up by Warner. (most notably with Pong) Still, they probably wouldn't have had the necesary funding to properly support the 2600, or had they tried it could have been slow going. Before Warner though they were relatively successful, though money was always tight and they were often close to the edge financially. Again they had been building a name for themselves though: starting wwith the moderately Successful "Computer Space" (the first video Arcade game to se comercial success, and was produced before Bushnell and Dabney had formed Atari), and later with the much more successful (and well known) Pong, first in the Arcade, later released as a home console as well. So Atari had certainly been building a following in the fledgling market. Again, they would probably have struggled a lot trying to manage a launch anywhere close to what Warner did, and wouldn't have been able to compete as well with competing companies with bigger wallets. (like Mattel and later Coleco) ANd it wasn't just the money that hurt the Lynx, though a tight budget was certainly part of it. It didn't have the necessary developer support (agan, in part due to funding, but not all), which is particularly unfortunate as the Lynx has been expressed in having some of the most freindly systems to program for.

Sorry the 500,000 figure is for the 32x, not the 3DO, sorry if I worded that confusingly. ALso, I retract my statements about the 360 and PS3's CPU's which I made in my "bitness" discussion in my first post in this topic. Neeither are 32-bit, The cores of both have some similarities (at least the PPE portion of the PS3's Cell), these both featuer 64-bit "general purpose" registers" and floating point registers, and bot contain additional 128-bit altivec registers. Additionally, the majority of the Cell's cores are SPE's which contain only 128-bit registers) The Wii's CPU is still 32-bit though, and there's nothing "256-bit" about any of these.

Correction, both the 360 and PS3 use 64-bit cores. (along with some 128-bit registers too, in the PS3's case most of it's cores are only 128-bit) but still, no 256-bit. (and the Wii's is 32-bit) They use a fixed 32-bit RISC instruction set, but that has nothing to do with the cores themselves, the Super H series (in 32x, Saturn, and Dreamcast to name consoles) uses 16-bit fixed length instructions, but they are most definitely 32-bit processors. (the SH4 of the Dreamcast additionally using a 64-bit data bus, though this has nothing to due with the core itsself, just the data bandwidth) And yeah a lot of the hardware really doesn't have "bitness" to it, like the Jag CD. (though I'm sure there are controller/processor chips in both the VR set and the Jag CD which do have "bitness" too...) not that that would add anything to the games themselves, it's just to support the devices. The Saturn for example has a 32-bit RISC SH-1 as it's CD-ROM controller.

Well I beleive the 3DO sold significantly better in markets outside the US (esp Japan) than the Jag did, but stil, 200,000 beats the CD32 as well, though the 32x (which could technicallt be considdered 16/32-bit due to the SN2's being on a 16-bit bus, though it's still in the same early part/trasition of the 5th gen) sold over 500,000 (that many had been produced in the initial run for North America alone I beleive, at which point orders were exceeding available units). In any case the Saturn did poorly in the US market, somwhere between 1-2 million, far less than the PSX or N64, and I have no idea why you mentioned the PS2... (the Sega CD did better in the US market) Of course it did quite well in Japan. The Jaguar was still pretty powerful, but heavily limited by design flaws and lack of tools to compensate for this. (and generally limited development support) No, just no, there are so many things wrong with such a simple statement, it's about as bad as the initial topic post... The PSX had a MIPS R3000 series RISC cpu on a 32-bit data bus, the saturn has a pair of SH2 RISC's on a shared 32-bit bus, and the only thing relate to a 68k is the Saturn's 68EC000 audio controller. Now it should be noted that the 32x might be considdered 16/32-bit as it's pair of SH2's share a 16-bit bus, but that's a seperate issue and still has nothing to do with the 68k. Furthermore a 68k is a 32-bit processor internally, just stuck on a 16-bit data bus, granted it's ALU is also 16-bit, and this still doesn't necessarily make it more powerful than a comperable 286 or 65816. (though the 816 is actually 16-bit on an 8-bit data bus, though it's significantly more cycle efficient, also note all 3 of these examples offer 24-bit addressing) One advantage though is that the 68k can perform 32-bit operations and use 32-bit code. However, later members of the "68xxx" family as you called it, genuinely are fully 32-bit, the 68020 actually having some advantages over Intel's 386 (like an on-chip cache), the 68030 added some minor features like a split data/instruction cache and an on-chip MMU, it topped out at a higher speed than the 020. Continuing along the x86 comparison, the 040 was another jump, and more comperable to the 486, being pipelined much more cycle efficient than the 020/30, featured a larger cache and added an on-chip FPU, however (unlike comperable predicessors) it topped out at a much lower speed than its x86 counterpart. Likewise the 68060 featured further improvements including superscalar (multiple instructions per cycle), comperable in many respects to the Pentium, however (like the 040) it tooped out much slower than its counterpart and Motorola discontinued development in favor of RISC designs after this. (but I hope you get the general point by now)

This isn't the place to discuss this (there's a couple 7800 threads active on this topic as well), but I think the reason the sound was wired to the cart port at the last minut for an on-cart chip, instead of putting a POKEY (or something else) on the board was MARIA was supposed to have included sound capabilities as well, but it ended up getting cut out. In a practical sense, even putting a POKEY on a riser board (with later revisions integrating it of course, particularly had a low cost, sound-only, min-pokey been developed) is a lot better than adding chips to cartridges. Once you make saizable runs of a couple titles including the POKEY you've already used more than you would in the system it's self. It really doesn't make sense in a practical manner. (had no alternative been available it might have made sense, but as POKEY was certainly available it doesn't, even the much smaller, though less capable, SN76489 should have been a consideration -though an Atari owned chip would have cost advantages even if it was more expensive to produce as there's no middle man to deal with) As to the topic at hand, I think it's pretty clear that the simplest change to make to help the Jag would be swapping the 68k for a 68EC020 runing at J-RISC speed. There are plenty of other options for harware alterations, some (like elliminating the 68k) necessitate better tools to be produced, and others that can be done in addition to changing/removing the 68k. (like double buffering the blitter or fixing the MMU bugs -the latter probably being important enough to consider the next thing to change) And finally if it should be CD based form the start without being unreasonably expensive. (you might be able to keep it under $350 with the 020 and a 1x CD drive, but that might be pushing it) It certainly has the advantage in being attractive to developers as a cheaper medium with far more storage capacity, so the games are cheaper to produce and can be sold at a lower price and higher profit margin. Of course CD's emphesize the limited RAM of the Jag a bit more, but it should still get by. (and the overall advantages of the media trump this) Maybe speeding up the system from 26.6 MHz to arround 33 MHz as well, again as a minor concern. (after the MMU, probably along the same priority as double buffering) Seeing as the lack of software for the system was it's biggest problem, and using CD's would help this as well, that's another pluss in this respect. Even if the unit is farly expensive initially (though still far less than the 3DO) a nice launch lineup of CD based games would compensate. (again as long as it's not rediculously expensice and hase acceptable advertizing and distribution) Woha, don't start brining that bits BS back in, it left the market early into the 6th gen and it should stay that way, there are no current "256-bit" ystems (inless you're talking about data paths, even then that's going to be uncommon outside the graphics bus) Just no, most current gen systems indeed have 32-bit cores in their CPUs, even PC's only recently started to really shift toward 64-bit CPUs and OS's (with a 64-bit proc with a 32-bit OS still acting like a 32-bit proc). (granted we've had 64-bit CPU data buses since the original Pentium) Still, the (often erronius, gimicky, and inconsistant) "bitness" hype died in the manstream console market, so please let it RIP.

This has got me interested, we've got a fully functional TRS-80 Model 2 (boots up to TRS-DOS after imputting the date and reads disks fine -even Y2K compatible with its 4-digit year imput ), I know it's pretty useless in a practical sense, the thing was a buisness computer, so not even any games. (granted it was a lot more technically capable and expensive than the M1/3 contemporaries) It's got the dust cover and screen cover as well, the only thing wrong is a small crack in the insulation over the kewboard's DIN connector. I think we've got the manuals too, and some other binders full of Radio Shach doccuments that go with it. (they're mostly manuals/instructions in one form or another) And a lot of 8" floppies as well.

I've actually read the opposite in some cases, people haveing issues with the plates used that were resolved by removing them, completely unnecessary for functionality either way, just like the RF sheilding inside the genesis itsself. (japanese consoles lack it as they don't have the tight regulations like from the FCC) The plastic spacer for the Model 2 is somewhat necessary to provide proper support for the unit and avoid stress on the cart slot, but inless you're rough with the console it isn't necessary either. (and lacking it you could easily use a couple sheets of cardboard wedged in there

This seems like an od way to go about adding a second button, why didn't they keep the circuitry layout identical to the CX-40 otherwise, and add a second button by using a pot circuit, much like was done for the keyboard controllers. (you could actually get 3 buttons this way, and you should even be able to program 2600 games to use this set-up)

That's interesting, if that happened and I was in that position (as stitch) I'd collect anything that looked woth it (maybe those old PC's as well), and try to get in touch wit hthe original owner if I could, otherwise keep it, give it to someone who wants it, or thrift store. It really sounds like that stuff was left to rot, stitch even mentioned the TV he got was all wet (presumably from sprinklers on the lawn), so it sounds like a lot of this stuff was really being salvaged/rescued and would otherwise be ruinined and/or trashed. (assuming noone else came along and picked it up)

Most know this was ready to be release for 1981 but was scrapped at the last minute due signal interference isues with the controllers, with portions of the design being recycled for the 5200. (mainly the case styling) However, why didn't they rework the unit into a non wireless version? Remove all the components and buttons on the console associated with the remote controlls, and rework the controller into compatible, standard 2600 joysticks. (same design, no reset+select or paddle functionality) Just a fresh, updated look with new controller design and the storage bin. Perhaps add joystick ports to the storage bin to allow the controller to be stored wile plugged in. They had the disign all layed out, and I think production was already set up, so why not modify the design for a minmum of added cost so as not to make it a waste. (and it certainly gave it a nice sleek look) Basicly as a replacement for the CX2600A, and in place of (and a bit earlier than) the "Atari 2600" "vader" model. I know a lot of this is hindsight, but had there been complaints about the controller design (which was similar in some ways to eh 5200's and, particularly the 3200's; and of course the 2800 as well) and the bulkiness of the storage compartment, perhaps these are things that could have been corrected on the 5200 before it's release. (granted the major problems with the 5200 would not be directly addressed through this)

Had the "JAN" chip (TIA+6507+RIOT ASIC) have been completed that should have saved quite a bit of board sapce and reduced cost. Of course, it would make the 2600 Jr. cheaper as well. http://www.atarimuseum.com/videogames/cons...tari2600jr.html

Well, games were still abig part of Warner Atari compated to their computers, and the 7800 was designed for them, and initially launched (test market) by them in 1984. GCC was a very small company, with a hndfull of designers actually working on it, particularly the actual new components like MARIA. (the system itsself being developed throughout 1983) Low cost was obviously a mjor factor though, and something they wanted to correct compared to the 5200. (not to mention better compete in the market, and stay well below the price of encroaching contemporary home computers) Adding sound chips seperately seems bad in the long run as it discourages 3rd parties (inless it's subsidized, which is worse than inclusing in in the system) and Atari itsself from adding chips to the cart due to the added cost, even with a low cost chip it would have been far more significant on cart. Adding it to the console, then later repalcing it was a cut-down, compatible (ie sound-only "mini POKEY") chip later one would be far more effective. The onboard audio from TIA was simply insufficient, especially in the long term. Adding chips (and RAM) in other cases like the NES (and most cart systems in the RAM case), is a different issue. This allows additional hardware that's too expensive, or completely unavailable at initial launch, but may become far cheaper/available in the future, cheap enough to have on-cart. (as was the case for the majority of SNES chips, and the few added chips on the NES) Though in some of these latter cases the chips were dretimentally expensive (especially to use for more than one title), mainly the Super FX chip for SNES and Sega's SVP chip. (both costly enough to merit a seperate lock-on/adaptor cart containing the added hardware possibly with improvements over the in-cart versions -much cheaper and more appealing to developers) This last though also raises a further point I made previously: even if the POKEY was ommited from the design, they could have released it in a passthrough cart instead of requiring it to be inside the game cartridge. (an add-on cart could additionally contain other enhancements like added RAM, but that's a seperate thought) This could be made cheaper as well with a cost cut POKEY, and could be integrated into the 7800 board in later revisions.

A component signal is a close as you can get to an RGB monitor/TV, and is really indistinguishable in quality difference, both being similar to emulators on a VGA monitor. (some talk on sega-16 has been made over possible RGB to VGA-RGB -which would be useful for both VGA monitors and HDTV's supporting VGA imputs) The problems with many HDTV's is that they're not compatible with a 240p video signal (native Genesis/MD resolution, and often for saturn as well), recognizing it as 480i and (wrongly) trys o de-interlace a progressive signal resulting in crappy video. Some HDTV's will properly support this so check first. All SDTV's and I think all CRT (tube) HDTV's will support this and 480i as well w/out interlacing as that's what SDTV/LDTV is. S-Video is generally the cheapes rout to go if you just want better than composite for your genesis (note the M2's with poorest video use a samsung chip which won't support S-video), there's even a simple mod which just involves a little soldering and a single 56-75 ohm resistor that may work depending on your TV and the video encoder in your system. (otherwise you need to build a video amp, which isn't too tough, and if you can handel it, it's still way cheaper than an RGB adaptor)