malducci

Gross!

Actually, that couldn't be more inaccurate of an analogy. Cars don't run software. If video upgrades, and I mean capability were very common place BITD, then I can kinda see the point of it. But they weren't. Even sound upgrades were VERY rare as a user base for most systems of that era. A video upgrade that's shown in that video, would have been outrageously expensive. It's not realistic in anyway shape or form. If you're making this brand new video upgrade, then it's a completely new system. Why even bother interfacing it with the old hardware? You can't call it a TI/99 any more. There's nothing novel about it. It's basically re-writing history in their minds. It's lame. Very lame. And in now way comparable with a disk or hard drive upgrade. No way.

Whaaaaat!? Why do people make this bullshit? Special video upgrades that are out of the complete spec of the system. I can understand mappers and maybe some tiny audio upgrades on cart, but this... this is just ridiculous. I think there's one (video upgrade) for the 8bit atari computers too. Ridiculous!

Been sharing this demo around: http://www.chrismcovell.com/data/OLD_IS_BEAUTIFUL_PCE.zip Run it on a flashcard or Everdrive. It needs NTSC composite output (not RGB, svideo, or PAL). Lovely demo.

As impressive as the Genesis port of Duke 3D is (it's a Wolf 3D clone and not the PC equiv), the snes version (wolf 3D) is even more impressive considering the processor and hardware - no addon chips were used. These games don't put the systems to their limits - they're just top tier quality games.

Only in the US. He was just a Hudson soft character, in which Hudson soft developed for other systems (in general and the character itself). For us old timers, sure. I mean, NES was my generation, but I still played pre NES stuff when I was younger (including arcades and computers). I thought Pac Man was Atari as well for quite a long time, but I know Mario Bros and Donkey Kong were Nintendo because the arcade had that logo on it, as well as the sticker packs (Donkey Kong sticker cards). But my point, kids these days don't even know of those systems. They have no exposure to it. And wiki provides all they'll ever need (read that with a bit a snark). But Mario? He's soooo huge of an IP, that if someone did say that he was an Atari character and not a Nintendo character, kids would immediately call bullshit on it.

335,544,320 = is 335 megabytes, not megabits. One kilobit = 128 bytes.

Nobody thinks Mario is an Atari character. I have no idea where you would get that idea from. Kids nowadays don't even know what Atari was. They know Mario as a Nintendo character, created by Miyamoto (if anything, because they read wiki sites).

That was the AMD model. I had it as well. The interesting thing, is that it had a multiplier option higher than that. The two common overclock options for that chip were 150mhz and 160mhz. The 150mhz came from a 25mhz bus speed, but it ran your PCI bus at 25mhz instead of 33mhz. The boards we had in our techshop where I worked at the time, could set the bus to 40mhz. As long as your PCI video card could handle it, then most AMD chips would do the 160mhz over clock. It was faster than the P90s and at a fraction of the cost. The P-60/66 series was absolute crap. I felt sorry for anyone who bought them.

Think about it for a sec. If there's no interrupt, then you have to poll the status for Sprite zero collision. You set game logic to run during active display, buffering any PPU updates (nametables, oam, tiles, etc) for NMI routine to upload. The NMI triggers, does PPU upload stuffs, APU handling, and then polls sprite zero collision (in a loop 8 times, because waiting for the end to modify the scroll regs). Then NMI exits and game logic an run. If the game logic take more than one frame, and things slow down, the status bar is still stable because its part of the NMI routine. How are you going to set that up when it's at the bottom of the screen? Frame sequence interrupt set to PAL mode (doesn't have to be pal console)? Things get much more complicated.

You know there's a hidden menu at the title screen for very easy mode, right? Also, no love for Aldynes? That's a great shooter with a great soundtrack. As far as consoles using the term "Megabit", it works rather quite well. No need for kilobyte or kilo anything. Most NES games start at 1 Megabit, except the really early ones. Matter of fact, most roms for NES/Genesis/TG16 were in steps of megabits. Bonk is a 3 megabit game (although most rom dumps over dump it to 4 megabits). It's easier to see 1, 2 ,3 ,4 ,5 ,6 etc megabit games than fractional values.

The NES didn't have an "processors" on the cart - that was SNES. The vast majority of NES/Famicom games had memory controls on the carts (just like the Master System, and later SNES/Genesis/PCE system). There are different "mappers" because Nintendo originally created each mapper with severe memory limits.. and kept expanding the rom range. Thus, newer mappers.. and a lot of them. It was clever programming or is it was a feature of the NES? The way sprite 0 collision works (it's calculated/triggered for each row of the sprite), it's made for doing this. A number of MMC 1 games (and older mappers), also have status bars like that; Castlevania, Ducktales, Robowarrior, Metroid, etc. Was SMB1 the first to do this? SMB is impressive because the whole game is made from 256 tiles and 256 cells for sprites. That's it. And it includes the title screen graphics! I think what's impressive, is NES games having a status bar at the bottom of the screen, without a mapper that has a timer interrupt. That's more difficult to pull off. I know there are a few, but I can't remember what they were.

Some games don't look so great with the oversaturation of RGB (or RGB -> composite mods). Bonks Adventure is one of them (the skin tones on Bonk are too orange). The original composite video of the system isn't just some simple RGB to composite conversion, but is actually a special digital table (ROM) of RGB to YUV inside the VCE graphic chip, and in such some colors blend better (certain purples with greys, some desatured dark reds with greys, etc). If the original composite doesn't have enough color saturation, then adjust your set - that what we all did back in the day.

Do kids really need to know gaming history??? Most kids just want to play some video games, and in that context it means the current stuff out there. There's nothing wrong with that. They're not historians, and they don't need to know the roots of video games, to the enjoy what they enjoy. If they're curious about the past, great, but it isn't required. You guys sound like a bunch of old farts sitting around, complaining how youth today just doesn't get it. Remember when old people said that about the video games you played as a kid, instead of doing something else? Is it sad? Yeah in way it is. Is there some responsibility that youth learn about this stuff, just to enjoy themselves with some modern entertainment? No. Not at all. The curious will find/discover this old stuff. The rest are just fine as is.

Did you do the trick where you dodge the first boss until he disappears, to get 30+ guys, a bunch of bombs, and a bunch of respawns (wish the game would show how many you have)?

Colors and effects, but the PCE and Genesis beat out the SNES as far as graphic bandwidth to vram (Genesis vdma, PCE full write access to vram during active display). The PCE and Genesis also have better sprite size options over the SNES (snes can only choose two options per screen). The PCE and Genesis also have less restrictions to vram, allowing more vram for tiles or more for sprites; snes has a restricting bank system for vram.

It's nice to have a 1.0 or 2.x system card so that you can see the warning screens of 3.0 and later syscard games. Some of the warning screens are entertaining.

The original Duo units don't have gear issues. That's an original CD addon issue. The original Duos have laser issues though and sometimes need a replacement laser module. The original Duos do have problems with caps and need to be serviced. The original CD addons are the only systems that need to have a system card in order to run. There are only two models of the original CD addon; the japanese breif case model and the US attachment for the TG16. All the Duo units (original, R, RX) have the 3.0 system card inside them. The SuperCDROM unit, a smaller addon, also has the system card 3.0 built in. If you have anyone of these four setups, then you can run the Arcade Card Duo which is cheaper than the Pro. It might not have a lot of games, but it's definitely work playing those games. They're rather impressive ports, and fun as well. Strider being the expection (it's crappy). I mean, if you going to delve into CD gaming on the PCE.. might as well include the Arcade Card at some point. Edit: The Arcade Card Pro works in ALL systems, it's just more expensive. I would go with the Arcade Card Duo if you don't need the pro version, because less to worry about (ram chips dying and all that sort of thing. All this stuff is getting old. Even SNES' are starting to break now).

There's a bit in the I/O port that reads back either 1 or 0 (grounded or open). 0 if I recall means Japan. 1 means outside of Japan. US games check for this, Japan ones (including the same game) don't. Only hucard/turbochip games check this region bit. They stopped doing this for CD games for whatever reason.

Pretty much this. Sega used cheap composite encoders for the SMS and Genesis, and the original Japanese systems as well. I have no idea how well it looks in PAL land, but for NTSC land composite encoder has this nasty artifact when scrolling (and I'm not talking about the rainbow artifacts either). It's apparent on certain colors than others, because the TVs can't pull out the color detail from the signal properly. Later on, developers started relying on the crappy composite chip to pull off color blending. You don't see this in first generatio titles. I guess said developers just ignored people with RGB setups (games that go overboard look like a terrible mess of dithering and alternating lines on RGB setups). To the original poster; get your Sega 16bitter modifed for s-video or a different encoder chip. It's worth it.

TG16: Air Zonk??? There are soo many more games that are visually impressive. Sapphire, Dracula X, Lords of Thunder, etc.

1990? Sonic didn't come out until summer of 1991, and a pack in 1992 IIRC.

http://forums.nesdev.com/viewtopic.php?f=12&p=149394#p149394

Hah, there's plenty of other talented people out there that could do this too. There's a guy right now in the Jag subforum here, that's getting ST games to run on the Jag. He has it easier like the nes2pce stuff, but the principle in the end is the same. Others that I can't remember off the top of my head. I honestly don't have the time. School has completely monopolized my time, so things on the homebrew/hack side are slow :/ Though Punch Out, with slightly upgrades graphics on the PC-Engine, would be cool and a fairly small project. Yeah, it's more difficult - but not completely undoable for the right dedicated hacker/coder. Have you ever seen the Donkey Kong arcade rom disassembled and reassembled to run on the CoCo 3? If you end up going the CDL route, then why stop with NES games? Why not actual arcade games like with what sockmaster (coco3 guy) did? The only down side is learning the arcade hardware to make the necessary conversion routines, but mame source code is a great help for figuring that out.

I was looking over the 7800 graphic modes and such, and yeah - it would be quite a feat. On the 7800 side of things, you're gonna end up with less cpu resource due to Maria and managing the display lists, and coupling that with usually unoptimized code for the average NES game - you're gonna run into some speed issues. If an NES game doesn't use a whole lot of cpu resource relative to a frame, then that part would be less of an issue. But other problems arise; the resolution don't match between the two, so coordinates of sprites and BG offsets would have to be recalculated on the fly (via LUT). I would think nes Punch Out could be a decent candidate for this. It would still be some serious hacking. From personal experience though, I think the issue of the 7800 have registers mapped into ZP address space - would be the bigger issue. But there is a nifty tool out there that can help; emulators CDL capability. You basically playthrough the game with the code/data logger enabled. It logs every byte access from the game, and uses an 8bit mask to tell what that access was (including multiple different accesses). Most importantly, it can tell you if the access was the first byte of an opcode. That one important piece of info allows you a clean dissassembly of the game code.