malducci

Would they need to cut back on the action on screen? No, actually - they wouldn't. The primary and most important function of that mapper is memory. If you remove that mapper, you loose the ability to access large amounts of memory. SMB3 uses single tilemap mirroring, it simply zeros out X/Y regs and switches which tilemap to read from (you don't need a mapper for this). Could the status bar still be at the bottom? Sure. Is it more convient with an interrupt? Sure. Are any of those games mentioned possible without the interrupt? Most definitely. Hell, all but two Megaman games use char-ram. Ever looked at Battletoads? That's one of the simplest mappers and the game uses chr-ram (not vrom mapped memory). No external interrupts. I'd argue they could be just as good, because I understand what's happening under the hood. Because none of those games use the external interrupt for excessive h-sync scrolls. Those games would be the exception, but I would just say "see below". Because it's like saying, if a game didn't have chr-ram or chr-rom then it wouldn't look the same. Actually, you wouldn't see anything at all. The same can be applied for external ram (a minimal of 2k work ram is on the system, and there's open bus in the address range for a reason: more memory via cart). That's true. And I'll take it one step further and say any h-sync scroll divides are impossible on a practical level without it. I.e. Ninja Gaiden 3 for example. But in reality, it's actually no different than they idea that the PPU isn't complete and actually requires functionality from the cart even to operate. That was my point. It's part of the design scope of the system, it's part of the ppu functionality, and its delivery mechanism *is* the cart and all the options it entails. The only real mapper outside the scope of this, is MMC5. The idea you were proposing, is that it's common place for NES to have 'upgrades', and the library by examples proves the rule and validation for the XM module. I personally think MMC5 is the exception to the rule, not the rule. And that these aren't upgrades so much, as they are development options within the scope of the original design. There's this point of view that the NES needed these "upgrades" because the 'base' system couldn't handle it, when the reality is that these are development extensions of the original system. This is the way the system was design; it's both extremely flexible and quite unique IMO. The SNES followed a similar development path, but not nearly as flexible as the NES' design. So that's the problem; people are defining the NES architecture by the design and measurements of other systems. When in fact, the NES is a fairly unique design. If you consider that an unfair advange on behalf of the NES, then that's fine. But that was always part of the system's design. There's a difference between being part of a system's functionality, and an unforseen exploit of a system's functionality, and something that goes above and beyond the scope of a system's functionality. 99% of mappers fall into the first category, with MMC5 falling into the second category. Nothing so far that I know of that fits the third. I mean, we're not talking about the 32x here ;>_> That said, was the 7800 designed with XM type capabilities in mind? Or does that fall under the second category? (I would say the 2151 falls closer to the third category, but I'm sure that's horse is long dead by now) That would be me (see my sig). Which is I brought it up. Yeah, I wrote emulation code for the PPU and APU in realtime thanks to the extra processing spead, but it can be done the other was as well: replace the apu and ppu drawing routines with custom ones. More work, for sure, but still doable. Well, that, and I'm partial to the NES one over the arcade game

Dammit. I only wanted to address Trebor's misinformation, not completely derail this thread or talk about what's already been apparently discussed a thousand times over. I appologize. I probably should have left out my trailing comment about the homebrew scene, etc. But about Nintendoage; I stay far away from that place as possible. I might like a lot of NES game from my childhood (among systems that came before and after), but I don't normally jive with Nintendo "fans" in general. They always treat Nintendo as the end all / be all, and everything else is a far distant 2nd or 3rd. It's a mentally tiresome to deal with. Lynxpro: I was looking over that mapper, and I'm not sure the PPU aspect of it will help out the 7800. Or would the 7800 benefit from fine memory slice mapping (1kbyte) in parts of rom/ram? I like the idea of reuse because of the tie back to Atari, but it seems like a lot of work just that sake. You could probably make a 'cleaner' version of the mapper via fpga. I'm not sure how everything aligns up between the two consoles (7800 and NES), but has anyone looked at hacking an NES rom to run on the 7800? I know the graphics architecture is different enough that simply patching the port read/writes wouldn't work, but that doesn't mean you could patch the functions themselves with your own hooks to your own display routines. Alot of work, sure, but something really cool none the less. With this in mind, I was thinking specifically Punch Out. But other smaller/easier games as well (maybe SMB 1, since there's already a hacked NES rom running on the TG16 and Sega Megadrive).

??? Care to explain which NES games have MMC5 upgraded audio? Or even better, how it upgrades the NES audio. Are you just quoting stuff, or do you actually understand what that actually means??? Okay. What does that have to do you missunderstanding and mispresentation of NES mappers? I think part of the problem, is that you're taking these explanations out of context. EVERY game on the NES upgrades/enchances the PPU regardless if it has a mapper or not. I already told you before, all VROM or VRAM is on the cart. The system was made to hae PPU funcationality extended to the cartridge. Two of the four tilemap memory area need to come from the cart, or the cart has to 'mirror' them (this is done with or without a mapper). The NES can scroll in ALL 8 directions without any mappers, regardless of the mirroring setup or if any memory is applied to the last two tilemaps. MMC1 provides the ability to change the mirroring instead of it simply being soldered/bridged on the cart. This doesn't give the NES multiscrolling, it allows you to set the mirroring to either horizontal or vertical - minimizing the artifacts on the edges of the screen depending on which way you're scrolling the tilemap and what mirror layout you have. It's a cheap option to providing the ram needed for the remaining 2 tilemaps. MMC2 does not allow larger graphics on screen; that's absurd. What it does provide, is an automatic mapping system for VROM instead of having the CPU do it - mid screen (which the CPU could still do). The result is allowing more than 256 tiles to be used on a single screen - but that still has severe limits (which is why it wasn't used outside of Punch Out). MMC1 only supports so much memory (program rom and vrom), so MMC3 is the extension of that; it allows for larger games. It has an external interrupt, which is part of the cart design, but no it doesn't magically give you split screen or status bars. It's done the same way it was always done; the program code changes the X/Y scroll on a specific line (Castlevania, SMB1, Ducktales, etc. Hell SMB1 doesn't even have a 'mapper'). Again, it's just an interval interrupt. Nothing more, nothing less. And nothing beyond the original design scope of the system (which is why is was available to the cart). Split screen is no different; could be done before (without a mapper) and it's some special exploit; the cpu just changes the x/y scroll values mid screen. MMC5 definitely expliots the system outside the original design scope with its graphic enhancing capabilities (the only chip to qualify as this), but only a small handful of games used it *and* most didn't even take advantage of the upgrade graphics (Castlevania 3 doesn't touch that part of the chip; MMC5 is used for accessing large rom size). One game used the vertical split mode (Uchuu Keibitai SDF) and it does so only during the opening cinema/intro. Also, you're looking at mapper capabilities and what Nintendo packaged together as a feature set. The NES specifically had open bus in the address range so that memory or memory mapped ports or whatever external devices, can be access from the cart. Save ram and SRAM are one in the same, and most games use it as both. "Save ram" is SRAM with a battery. But regadless, save ram and/or sram extension is not a mapper thing; it doesn't require a mapper. It requires address decoding logic. It's just easier to consolidate that logic into a single chip. And from Nintendo, features where limited to a range of these chips. Hell, Nintendo was really cheap on these 'mappers', which resulted in limitations (bus conflict mappers needed special duplicate rom values when changing banks, because Nintendo was too cheap to do a proper interface. Later 'mappers' resolved this). Even the interrupt on the MMC3 is cheaply made, instead of a real programmable counter - it just uses the PPU address lines as a makeshift replacement for a counter, which results in design limitation for 8x16 sprites (and limiting which sprites and BG tiles can be in which banks). A proper interrupt on the cart would have been tied to a counter (resettable to be sync'd to vblank). Finer memory mapping requires much more logic, and is why earlier mappers only worked with 8k for vrom and 16k for program rom. It was only until development demanded for finer segment memory mapping, that Nintendo made changes (as well as other companies that made their own mappers). This is the reason why there are sooo many mappers on the system; it's about keeping costs to a minimum. If a game uses MMC3, it by no means it requires everything on that chip. Most "NES" games use MMC1 chip for the Famicom counter part that had a lesser chip, simply because NOA tried to kept mappers to a minimum. I can tell you though, the primary function of a mapper in a Nintendo game is to access larger memory sizes. Secondary would be finer vrom mapping. A distant third would be any other features it offered, which outside a very small list of games - it's usage was minimal and wouldn't be missed if removed. Right off the top of my head, I can say the whole Megaman series fits this bill. These features in the third subset, hardly make or break an NES game (graphic or otherwise). I have that list. For one, this shows me that you really don't have much of an idea. Again, you speak with authority on the subject, but you actually have no knowledge outside of looking at some list. It's not just simply a region thing; the NES has hardware differences from the Famicom. The NES (US or Europe) cannot use the audio expansion chips. Period. The audio expansion chips provide the analog audio signals and use the input lines on the Famicom in which it mixes the two audio signals together. The NES simply does not have this feature. There are no NES games that have upgraded audio. The only point of contention IMO, since the XM module's capabilities are supposed to be within the scope of the time/era, is the use of the YM2151 chip. Since NES and SMS are used as a basis for comparison, not even those system had a chip close to that grade/quality/cost. Even the Sega Megadrive/Genesis, which Sega tried to make as close to an arcade machine as possible, used an inferrior/cheaper FM chip (only 6 channels) than the YM2151. Something equivalent to the 2413 would be much more realistic for that era, for the 7800. Or probably more accurately, the YM2203. Simply saying that Atari used it in its arcade systems (hell, everyone did), isn't a qualifier that they would have used it on carts as well (assuming the 7800 reached the level of success of the NES. This module is always put into that context). Home systems weren't arcade equivalents, and used cheaper and inferior parts for a reason (cost). FM chips (only available through Yamaha; they held the patents on it) were expensive in comparison to PSG and other lesser chips. Not only that, but you had to actually get an approved contract with Yamaha at the time (yamaha tightly controlled where these chips would be used in applications, since they had competing products that used their own chips). On that note, the Famicom using the YM2413 in *one* at the end of its life span, isn't a qualifier either. Only the japanese SMS is in this respect. Lol. I love that qualifier: I don't hate console "X" because here's one game that I really like. So now my criticism is valid. Dude, I really don't care if you like the NES or hate it, or something in between. All I'm saying, is if you're gonna speak with authority on the subject, then at least have an understanding of what you're talking about. Else, you're talking out your butt - armchair commentator, whatever. Sorry. No doubt. I think there are way more people that would like to see what the 7800 was truly capable of, than not. Even for people that aren't diehard fans of it; it's exciting seeing a system being pushed to its limits or what it's capable of. GrooveBee is the first person to come to mind. I remember quite a bit of trash talking the NES and nesdev scene. I remember him saying that he was going to learn NES dev *just* to put the NES to shame - no other reason. Not only a waste of time and talent (he's quite talented), but such a childish and igorant mentality to have towards something that's.. well, supposed to be fun. But yeah, the comparisons were always focused towards the NES, and not the SMS (or PC-Engine or any "8bit" console). I don't remember the others, but the 7800 fans specifically surrounding the 7800 homebrew scene contributed to that negativity. I'm not an Atari fan, or Amiga fan, or C64 fan, etc. I don't have a stake or bias in any of this, so I have a distinct view point of the Atariage forum. I see rivalry and contention everywhere here; Atari VS everyone else. I'm just pointing out the contrast to other 'dev' themed forums, specifically NES because that seems to be the 7800's rival, for 7800 fans. Though I'll admit that Sega forums are similar in negativity against the 'rival' (I'm talking dev here), still nothing close to Atari dev scene. I'm no stranger to coding for underdog console systems and all that it entails, but this whole forum was an eye opener for sure. Maybe I didn't explain myself clearly enough, or maybe you just misunderstood me. NESdev scene isn't 'superior', it's just much more light hearted and open minded kind of atmosphere. I'm not talking about NES 'fans' in general (god, no), I'm talking about the dev scene.

I think the 7800 should be able to do a pretty decent version. The game is more about movable objects, than background details. That's something the 7800 excels at over the NES, even without the XM expansion module. But hey, if the NES used a mapper specifically designed just for this game, then the XM module (or any exclusive cart hardware) is fair game on the 7800. It's clear you don't really know what you're talking about (at least NES). Sorry to be blunt. The Famicom specifically was made with audio upgrades on the 'cart', in mind. This isn't a 'cheat' or whatever you would like to think. But this is the Famicom, not the NES. The NES has no audio upgrades via the cart because they removed the audio in lines on the cart connector when the localized the Famicom to the NES model. So every chip you mentioned that had 'audio' upgrades, applies to zero NES games. Secondly, the NES is designed very much like an arcade system: video memory is ALWAYS on the cart. It's either RAM or ROM, but either way it's always on the cart. And just like arcade systems, mappers could be used to map out ROM (video or program). It's not an afterthought or cheat; it's part of the design. Third, there are a VERY few exceptions as to where the mappers extended the video capabilites of the NES or Famicom. Punch Out is one of them; the mapper isn't the advantage (mapper chips were standered EVEN before the Famicom) - design around the software application is though. It's specific to this game and is why you didn't really see it for any other game. When a certain tiles is read from vrom, the mapper automatically switches banks. There are two tiles like this (the last two tiles IIRC). The NES/Famicom ALWAYS had the ability to do multidirection scrolling. The NES supports 4 tile maps (each being 256x240 pixels), but there's only enough vram on the NES to support 2 of them. The console was made for the remaining memory to be on CART. It cuts the cost of the console down. If the developer didn't want to pay for the extra tilemap memory, then there were options (again, the cart) to setup 'mirroring' of that tilemap layout. Nothing stops a game from doing multidirectional scrolling, but there will be artifacts on the edge of the screen (attribute artifacts) without the extreme memory. Some devs cared, some didn't (SMB3, a large budget game, doesn't even bother with expanding the tilemap memory on cart and scrolls 8 way just fine). The vast majority of mappers are just that; memory mappers. There's absolutely nothing special about them, in that respect. The NES does lack an internal timer for hsync effects (sprite #0 was used to create boarder windows at the top of the screen), but again - the external interrupt line is on the cart for a reason. It doesn't provide anything to the NES that's outside the scope of the system's design. MMC5 is the only chip (that I know of), that seriously exploits vrom mapping to enchance the graphics - in that they most likely did NOT design the Famicom in such a manner. It allows finer color resolution per tile area (8x8 instead of 16x16) and allows more tiles for both BG and Sprites. Castlevania 3 barely even touches those capabilities. This was a point of contention for nes dev fans (that the MMC5 was wasted potential). Again, the vast majority of games with 'mappers', are just games with memory mappers. Nothing out of the ordinary, and nothing 'expanding' the graphics. Early NES games didn't require mappers, because they were simple and small. But the functionality was always there. And video memory was ALWAYS on the cart. Something the SNES should have done. And something the NeoGeo did do. You know what the biggest differences between 95% of mappers on the NES were? The size of the memory area being mapped out, or the size of external memory addressed. The second would be external interrupt (later gen NES games, for the games that did hsync scroll effects). If you're gonna use the NES mapper thing to validate the XM expansion device, then that's fine. But get your facts right first. I like seeing new 7800 homebrew. I like homebrew for any old retro console. But just an observation: the nes dev guys never even think about the 7800, or the XM module, or even competing with it. Most NES dev guys don't see the rivalry between the consoles; it's kind of a one sided rivalry from the 7800 scene. Not like the C64 vs A8. It's weird. If anything, it's NES vs SMS - and even at that NES dev guys just care about making games for the NES (not about out doing other consoles). It's just a completely different atmosphere here, than over at nesdev. There's some level of hate or negativity here, and it's really light hearted over there. So that said, if you really want to have a real rivaly - then create some demos with text seriously dissing the NES and nesdev scene. That's definitely get the response you want - lol

The 2600 should be silver. But I'm not sure about the 5200. The 7800 shouldn't be anything - lol. Maybe fools gold

Nice. I have an original White PC-Engine and a SuperGrafx. I run the SuperCDROM2 attachment. Hucard games are nice, and there are a handful of must haves, but CD games is where it's at. Once I went CD, it was hard to go back. Mostly because hucard sizes limited the games. The sizes increased over time, but their increase never matched the Megadrive and SuperFami increases in cart size. CD games is where you start to see the evolution of games on the system. If you're into the charm of hucard games, that's cool - but CD games took over the system less than half its life span; it's the real meat of the system. As far as CD-Rs and the real units, it's not that complicated. The original Duos and the original CD units (breifcase model and the US model) have problems with CD-Rs. Some gamers have replaced the laser modules in those early units, with success and read CD-Rs just fine, but I have no experience with that to say yah or nay. The SuperCDROM2 and Duo-R/RX systems do not have problems reading CD-Rs.

That's the most retarted division of generations I've ever seen. Why even have generations, if you're gonna go that far??? Might as well go with: NES is 3.5, the master system is 3.75 and the TG16 is 3.91. The Genesis is 4, but the SNES is 4.3-ish. NeoGeo is 4.5, but the 3DO, Jag, 32x are 4.63. The CDi isn't even 4th gen. It's not even a gaming console; it's an interactive multimedia device. I voted for NES. The VCS has its charm, but the games are just too simplistic for my tastes. I played it BITD, but I had more fun going outside and getting into trouble. The NES was the first real gaming console that could keep my indoors, all day long. That thing was addictive.

The blobs in Dungeons of Daggorath.. when you first start out. The noise they used to make, when they got closer, use to give my chills.

My original US Duo, had problems reading CD-Rs. So did two others (friends units). My original brief case japanese CD setup also had problems reading CD-Rs. I've heard good things about the Duo R/RX models, for reading CD-Rs. I've also heard that if you replace the laser unit in the original Duo units - it'll handle CD-Rs much better. Though I have no experience with that or Duo R/RX models, so take that for what it's worth. But myself and others have had great success with Super CDROM add on unit. Also, the Super CDROM unit is like the Duo units; it doesn't need a system card to operate (has it built in). And you can also use the Arcade Card Duo with the addon, which is cheaper than the Pro card.

I have the Super CDROM addon unit. Haven't had cap problems with it. I've heard the audio levels are slightly different than the Duo, but I haven't noticed anything. What I do know, is that this unit (stock) has one of the best lasers of the CD units (though late model Duo R/RX is supposed to be the same). It can read even the crappiest CD-Rs without problems. I've used mine for over 8 years now, with lots of CD-Rs, no problems. Great for trying out games before you buy them, or playing CD homebrew/translations.

Bloody Wolf is a must have TG16 game. It's a great top down run'n'gun arcade game from the late 80's. Splatterhouse is also pretty decent. Jackie Chan is great too, but a bit on the expensive side. If you're into shmups, Aero Blaster is great (and 2 players). And of course Dungeon Explorer, with it's 5 player support (that was the party game back in the day). Edit: Also, if you can, try to join PCFX forums. You'll find better deals on games/hardware than you will on ebay. Oh, and there's also a homebrew scene for the PCE/TG16. You'll find quite a bit about it there.

It's a novelty thing only. Some PCE games have sensitive timing, so some games might have glitches (even CD games). Some games will run with slower music/soundFX and some won't (using the timer to drive the music engine, instead of screen refresh Hz interrupts), but all the games ~will~ run slower. That right there is a deal breaker for me. Especially since I played almost all of these games in full 60hz mode.

Lol - that looks like a TG16 without the back cover (a common sight for used TG16's).

The Lynx isn't 'sprite' based. The NeoGeo is 'sprite' based. The Lynx is blitter based. Nothing more, nothing less. Blitter based video systems are completely different than raster tile/sprite based systems like the SNES/Genesis. The TG16 hardware is just like the SNES/Genesis. Neither of those systems has 'sprite manipulation techniques' (I assume you mean scaling or warping). The Lynx has a single 16 color bitmap screen. Everything gets blitted to that screen map/buffer. The 16 colors point to one of 4096 colors. The TG16 has 512 colors total, but it can show 481 unique colors on screen without ~any~ hardware tricks or extra cpu resource. The TG16 processor is faster and has more opcodes than the lynx 65c02. The TG16 sound has more channels and is superior in design (timbre/effects/waveforms/etc). Being sprite and tile based, the TG16 requires very little cpu resource to move objects and backgrounds around on screen at 60fps - compared to the Lynx. Even more so if you consider the resolution difference between the two (TG16 is building/moving/pushing way more pixels around per frame than the Lynx). The higher screen resolution of the TG16/Express, dismisses any advantange of the 4096 vs 512 master palette difference. All you have to do, is look at games like CV: Rondo, or Fatat Fury Special, or World Heroes 2, or SF2:CE on the TG16/PCE - to realize this. Even the GameGear has the Lynx beat in the color department (same 4096 master palette, but 31 colors on screen without tricks). A blitter system offers some more flexibility over sprite/tile bases systems, but it's directly limited by the blitting speed and the overhead of having to make a BG map via blitting blocks/tile-segments to the buffer. There's more overhead on the cpu side, and the frame rate is limited by how fast the blitter can perform the pixel draw functions. That said, the low bitmap color hurts the Lynx IMO. But the resolution is what kills it for me. The TG16 could have added a blitter chip on the card/cart, and do any of the effects the Lynx does.

You know that's a logical fallacy right? Lol. (I've pulled that one a few times) Nice try See.. I thought the ridiculousness of my response mirrored the ridiculousness of your guy's arguement. You know, in a fun bit sort of way. That wasn't apparent? I dunno. I just think it's a little bit ridiculous arguing about 'filters' when it just comes down to preference (especially when the argument has dwindled down into squabbling sematics - to the point of uselessness. All because someone mentioned 'vector' or some such). I mean, as long as there's a choice - what does it matter?. Instead, you guy's are arguing over preferences (originally, anyway). Who's opinion is more valid, holds more weight, sinks more ships, whatever. But I think it's quite obvious that neither of you are going to convince or change the mind of the other. But, by all means - continue on

You guys are arguing about a bunch of circles and 3's, you know that - right?

Some, yes. Most? No. I like this forum, but there's a H-U-G-E bias for Atari here (well, duh) and very defensive for anything competitive to Atari BITD. There's also a farily large (what seems like to me, anyway) anti-japanese game design sort of thing that I've seen here quite a bit (more so in the atari specific sub forums, and less so here in the classic gaming sub forum - but it's still here too). Well, with the exception of Pac-man and Donkey Kong (for whatever reason). The problem here, as with other forums that have this type of debate, is that people come the conclusion solely based on their experience with said history. North America is a pretty damn big place (let alone the rest of the world) and there are going to be different experiences across counties, towns, cities, states, countries, etc (etc ??? Jail cells and prisons! Yeah!). I even fall into this trap. I was born in the mid 70's. I might not be as old as some of you fuq'ers, but I'm old enough to remember playing the 2600. I went to the arcade at age 4-5. I can tell you, that growing up in the 80's, I was one of the few kids that actually had a small home computer (CoCo 2). Be it neighborhood or school. I never cared for the 2600 or the 5200 as kid (I thought the games were too simplistic and boring. Still do to this day). I knew of 2 or 3 people that had a 2600 or such, during the 80's. I'm sure kids had them at school, but no one talked about them. No one talked about video games as at all, before the NES came out. I was one of the few that continued to play arcade games quite frequently. I had one friend that had a C64 and he got that after the NES was already hitting it big. Never knew of anyone that had an Atari 8bit ot ST computer. One person had an Amiga (my older bother's friend). Nobody had PC's, or rather PC's that were worth playing anything on (8086 with monochrome 1bit graphics - no thank you). And I was the only one that knew how to code in basic. Even in high school (freshman 1990). So when I see all these posts about how well the 2600 was still doing in 1985, I have to ask myself.. what??? My parents were always going out to pay bills or whatever at the stores. I was ALWAYS looking at toys, electronics, and computer mags (or hanging around radio shack or whatever small computer store). All the atari and coleco stuff that I saw, was at USED game markets (mostly swap meets or used shops). I've had people tell me that the Amiga was fairly big in the US. I NEVER saw an amiga in the stores. Only that one Amiga magazine at the book store along with the rest of the computer mags (which is how I knew about it). I did see an ST once, but that was at a used shop. Let alone, knew any body to have such systems/computers. It wasn't until the 90's, when that stuff was being sold used for dirt cheap, did I see some of that stuff pop up. And even then. Yeah, Tucson wasn't the biggest city - but it was a 'city'. And lots of stores. When NES hit the scene, everybody and their mother was carrying that system and softs. I remember even a 'lamp' store carring a few games. Now, maybe my experience is directly related to the age I was at the time. I wasn't old enough to have a job, thus no income other than allowance or odd work around the house/birthdays/xmas. Same with my friends (obviously). Though we weren't exactly poor (my Dad spent $400 on that CoCo 2 in 1983 long with a big 27" TV that cost $800 at the time). But I have a feeling that older kids (teens), with income (most likely jobs), had the money to buy such expensive things and thus had a different experience than mine. And mostly likely their friends as well. If not that, then it definitely had a variance from area to area. When the NES hit the scene, it was thee-hottest-thing-ever. The games were incredible, fun, and completely new/different than anything I had played before it. My brother had an NES in '86. He sold it after a few months. I bought one a few months later. There was nothing like it. And by 1989/1990, even dirt poor kids had an NES. Sure, games were expensive - but you could rent NES carts. That, and we trade-borrowed carts between friends and associates. So while you guys can argue the definition of 'saving' the game industry in North America, I'll falt out say that the NES revolutionized gaming in the US. SMS was a blip. 7800 what? I didn't even know atari came out with a new console (and I read lots of game mags) in the late 80's. I did see the reshelfing of the 2600 and 5200 at playworld as the 'cheap' alternative to the NES (and I do remember the atari commercials stating as much). Or maybe I did see some 7800 games, but they just looked like old 5200 stuffs at the time (pretty sure PlayWorld had the 7800, if they were carring the SMS, 2600 repacked, and 2600/5200 games). When I saw the sales numbers for the 7800 posted a number of years ago, I couldn't believe it. Who the hell bought those systems? I had a ton of gaming friends and associates and never once heard of anyone saying they owned a 7800 or even talk about the system. A few SMS systems, yeah. A handful of TG16s. But 7800??? I still have a hard time believing those numbers. Someone made the remark that if Nintendo didn't exist, that SMB and Zelda wouldn't either. I disagree. Not because what's-his-face would have created those on another system, but because of the fact in Japan - Nintendo wasn't the only choice for gaming. The MSX/2/2+ and the NEC PC lines were ripe with Japanese style softs.Those were very popular alternatives to the Famicom. They all drew influence from each other. Similar games would have existed, though they might not have been world renowned. If Nintendo hadn't come in when they did in the US, I suspect that he US would have went the way of Europe. Though probably not as big of a small computer scene. It probably would have taken until the 16bit home console scene to gain that sort of following (that the NES did). The US != EU or UK. Different regions, different mentality, different habits, etc. Err.. yeah....

Really? You have to ask? When has rock music ever been nerdy?

Those stars are hardware sprites. There are examples of games that use 'dynamic tiles' for psuedo separate layers of BG stuffs, but this game isn't one them. The PC-Engine has 64 sprite entries in the Sprite Attribute Table. Those sprites can be one of six different sizes per SAT entry; 16x16, 16x32, 16x64, 32x16, 32x32, 32x64 in pixels. The sprite limitation is 256 sprite pixels per scanline. All SAT entries and their sizes are made up of 16x16 bitmap cells. When the limitation of 256pixels if met for that scanline, the internal sprite buffer (though it's not a line-buffer like with Genesis/Megadrive) can't display anymore more pixels than that per line. Like with almost all other consoles of the time (NES,SMS,Genesis,SNES,etc), the whole line of the sprite cell is counted for. That means even if only 1 pixel is 'visible' on a horizontal line of a sprite 'cell', the whole line still gets counted and buffered. Because the PCE's sprite "cells" are no smaller than 16x16 (compared to other systems with 8x8 core "cells"), you can only fit 16 sprite cells per scanline (regardless if the resolution is increased; the internal buffer is fixed in size). Sprite cells that get dropped in 16 wide pixel segments (blank out, or flicker if the programmer codes for it. Flicker is a software thing, not a hardware thing. Blank out is a hardware thing). Long story short; all those sprites in that image are under or fit into single 16x16 cell segments. Looking at the top row, there's eight 16x16 cells across the screen. That's 128 pixels. That leaves rooms for eight more 16x16 sprite cells. Plenty for the star sprites and bullets from the ships. Plus, there are quite a few vertical shmups on the PC-Engine that use this trick - with much more action going on, on-screen. Blazing Lazers first level immediately comes to mind (but any of the star soldier series too). If the stars 'flicker' or 'blank out', you won't really notice. And it doesn't happen that often in vertical shmups and such. Some games even flicker or atlernate the sprites for even and odd frames (makes the real flicker look less noticeable on the star field). I'm pretty sure some late® gen games for the NES do this. Probably for SMS as well.

Even using full 32bit regs on the original 68k, it's not that much faster than the Txx opcodes of the 6280. I wrote a few mem copy routines for the 68k. A copy loop that did fourteen 32it regs for 56 bytes per instance took 5.1 cpu cycles (just the copy and loop, excludes the prep overhead). Txx instructions are 6 cpu cycles a byte. If you unrolled the copy part of the 68k loop, 26 times to negate overhead of the sub/branch - you're looking at 4.64 cpu cycles per byte. More limited though (need multiples of 26*56bytes). 6 vs 5.1 cycle per byte isn't that big of a difference.

It's pronounced like that in the official English dubbing of Ys book I & II and Ys 3 for the TG16 CD. And since this is for the same system, it makes perfect sense to me. I was pretty disappointed to hear his name being pronounced "ah-doll" in Ys 6. It was always "Ayedol" to me.

Trailer: http://www.youtube.com/watch?v=aQxusqqY5Kw Site: http://www.pcenginefx.com/forums/index.php?topic=13136.msg259515#new

Yeah, a 2600 game on the TG16 isn't going to happen unless you port it (write it yourself) or seriously hack the ever-living-hell out of the 2600 rom (re-writing all the sound and graphic routines). Both cases are doable; both cases require a lot of work and dedication. NES shares fundimentals with the NES like tiles, tilemaps, sprites, sprite tables, etc. But it ends there. The planar style and planar byte order are different between the two, the sprite coords are different, tilemap format and layout is different, vram and where everything goes is *completely* different. Hell, the TG16 GPU only takes 16bit read/writes (port) where as the NES PPU is an 8bit port (this creates a serious headache for only the fly conversions and writing to vram; tilemaps, tiles. sprites, everything). And there's the fact that the NES has some hardware specific things that the PCE doesn't not have (the NES tilemap mirroring is a pain in the ass to simulate on the PCE - requires hsync interrupt code to fix it).The graphic emulaton on the NES2PCE ports is realtime. The graphic assets (tilemap, tiles, sprites) are all in their original format and converted on the fly as the NES code writes to the PPU and APU ports (the only thing hacked in the rom are the port read and writes; replaced with JSRs to emulation backend code). Even though the PCE/TG16 cpu runs 4x as fast, I'm still amazed that the backend emulation code is able to keep up (it does and Megaman even has elimination of slowdown of the NES original - hah!).

Could be a number of factors (main ram). DRAM was generally cheaper than SRAM for the same size in bytes (or whatever the 'word' definition is for the ram chip). NES had the option for both CHR-ROM (character rom or vrom) or CHR-RAM (character ram or vram). But the SMS was a VRAM only setup. That, and the 8x8 graphic cells took up twice as much memory as NES' 2bit format. Better compression techniques were needed to maintain and keep rom sizes down on the SMS. Having a large work space for caching/buffer decompressed sprites meant you could grab frames and such at just as fast rate as uncompressed - but with the benefit of compression. Otherwise normally you need a 'break' area where you can decompress and upload to vram. On the VDP side, SMS had twice the bit depth for tiles/sprites than NES - so it needed twice the vram size to hold the exact same amount of cells (the 16k listed). In comparison, the Genesis has 64k of system ram and the SNES has 128k of system ram. But the PC-Engine stock only has 8k of system ram. It was originally designed with 32k (the 8k is mirrored to 32k and on the SGX this mirrior is actually populated with the additional 24k). This meant carts (hucards) that had no additional ram, had poor compression schemes (i.e. the trade off being speed over size) and coupled with small to average rom sizes - limited games graphically. Typical compession for hucard games are simple RLE varaints and/or just using 3bit planes (7 colors) for graphic cells. It wasn't until CD games for the PC-Engine, that provided more ram, that compression schemes got more advanced like LZSS variants. Like someone else stated, computers are a separate beast. The larger amount of ram acts as rom would in a game system, abliet temporary storage. The PC-Engine CD system was a small computer in this way. Sure, there was a bios rom that houses a font and some math functions - but the CD ram is where everything held and run for that 'instance' or area or section. The original had 64k of ram 'cart' ram. That proved to be fairly limiting and was bumped up to 256k for SuperCD (and then later on to 2304K with the Arcade Card). SegaCD is similar, but the ram is divided between the main system and sub system, and neither CPU can access all of it (with the Genesis CPU having access to only a small amount at any one time). Back to the NES; 2k+2k is what wiki lists? 2k system ram, 2k for tilemap and attribute/palette stuff (tilemap stuff). But it's pretty common to have CHR-RAM setup for games, which is an additional 8k of vram to hold tiles/sprites - so 2k+2k+8k. Not a lot of games increase the system ram, and IIRC out those that do - it's usually for battery backup save game data.

I never been to the Bookmans in Phoenix/Mesa, but there are three of the stores in Tucson. The eastside store is pretty decent. I've picked up quite a bit form there, including my Saturn. They have TG16 stuff, 2600, Coleco stuff etc. Just like stated previously, it's all about what people bring in/sell/trade and the timing of it all.