malducci

Magical Dinosaur Tour for TGCD

Wow.... creepy. I'll miss your avatar, though (seriously)

So.. you wrote a piece of fiction about Craigslist? >_> This comes off more as lame than anything else (especially since people took this as an actual event).

Uhm.. why? Why does this question even need an answer? I think it's pretty clear why there wasn't a second crash during the late '80s. I know some members on here are either jealous of Nintendo's success and take over the market in the US, or just didn't like the new generation/style of video games - but the large majority of people (current gen gamers) were in love with video games during NES and the 16bit era. Why would there be a "crash"? Of course, this is relative to the US. Apparently, Europe never had a crash per se. Nor Japan. Yeaahh, that's not a video game crash scenario. That's called out of with the old and in with the new. And that's, well.. completely different. The phasing out of an old generation and phasing in with the new/replacement one, doesn't constitute a "crash". If you were actually there in that era, and experienced all these "new" games, you'd understand. It was damn exciting. New stuff was coming out all the time, and there were tons of great games. If anything, there was more crap during the last part of the 16bit generation... when US developed crap starting flooding the market again (and not so up to par EU softs too).

Usually that's split between the 3rd (7800/NES/SMS) and 4th (PCE/TG-16+CD, SNES, MD/Genesis+CD) generations due to the big graphical (and audio) difference as well as time. (like comparing an A8-bit or C64 to an Amiga) I agree they're different generations of technology, but not different eras. The NES, Genesis, SNES all represent pretty much the same style of games, the later systems just ran them better. Not much changed between those years other than the graphics and sound getting better. I think it really depends on your threshold point of differences. BITD, the difference in gameplay between 8bit and 16bit was pretty noticeable. I guess relative to 2600/coleco/etc to NES/SMS/later gen home computers, it is a bigger difference than 8bit to 16bit. But I don't think that lessens the differences. In the whole scope of things, it looks like a smaller difference, but BITD - it was a pretty big difference in general. Having more sprites on screen, larger enemies and bosses, really changed the gameplay mechanics IMO from 8bit to 16bit consoles (NES/SMS to Genesis/SNES/TG). Of course, there will be simplistic games to be found earlier on the Genesis and TG16 as they were the first and closest to the 8bit transition. But in general, or ignoring those, the difference was fairly large.

Game Gear, if you can get your hands on Gunstar Heroes port. Incredible game, so say the least. The majority of the GG library is "meh" - but there are a few decent titles. And like others have said, the screen isn't too great. I have two GGs and about 30 games. I never play it. The lynx looks interesting and I would like to try out a few games, but overall - the library won't keep me interested (at all). Zaku would probably be the only reason I'd get a lynx (never owned one, but a friend had one). For all its technical prowess, the screen is too low res and the library just sucks not to my liking.

Hahahahaha

Plenty in relative to what? I would bet these late adopters were in the very low percentile compared to the gamers that were making these companies... their money. There's also the fact that old gen hardware, in the next or even two generations later - has the unfortunate effect of being susceptible to these frugal "gamers" buying used software for cheap (instead of new and/or repackage stuff). Why buy new stuff when you can buy the same thing for a lot less money? The business model doesn't really work. Hence, why companies don't really do it. As it is, the used game market is huge even for the current generation of consoles. And add renting on top of that. No wonder companies are slowly trying to sneak in DLC. Before you know it, it will be pretty much all DLC. The whole frog in the boiling pot of water analogy.. thing.

Yeah, but that's Majesco - right? Seems a little too desperate even for Sega for them to try and milk the Genesis for every last penny, when the N64 was out and the DC was just around the corner. Was Sega really that bad off at the time, or was it in fact just the start of Majesco? I do remember the "retro" Majesco Genesis systems hitting CompUSSR when I worked there waaaaaaayy back. IIRC, DC was already out (or maybe it had just come out, I don't remember). Anyway, I never considered anything repacked by Majesco to be Sega. Licensed or not.

The Genesis is STILL being produced to this day. Well, it's not THE Genesis, but it is still licensed by SEGA. The Firecore and Gencore are what I'm talking about. Of course, 20-year old chipsets are not hard to emulate, which is why you get 3-way systems from ybit, or whatever the hell its name is. I'm not counting clone systems though, and as far as Iknow, sega's not licensing any games at all....That's what I'm meaning, Frogger, 96, is the last game I'm aware of for the SNES, and I personally got several games for the genesis from 98 (and think thee were some 99's, but won't swear to that) Real honest to goodness licensed games from Sega for the Genesis in 1998? Do you have a list? It's not that I don't believe you, but.. what store was going to carry this new titles? It just seems absurd that any company would take the time to develop a game for the Genesis in 1998, when no stores (non! in my area) carried anything "new" for the Genesis. Used shops, sure. But new? Nope. Toys R Us had some old stock left over, but you had to "ask" for this at the counter. Once in a while you'd get discount bins, but I'm almost positive this stopped by 1997 for Genesis and SNES stuff (and it was old stock, not new developed games on shelves).

The N106 is wavetable. It's just like a GUS sound card ( a unified bank of memory and channels that point into this global memory for which sample to play. The more channels you enable, the more frequency steps you loose. And the max frequency starts dropping). It's also a very similar the Konami SCC and PCE audio chip (which are small wavetable chips). Not the frequency thing, but that you define small samples for it to playback at a specific frequency. MMC5 adds a PCM channel. Not sure what others add as far as PCM (never heard of ADPCM for NES). The DPCM channel on the NES is just 1bit deltas (signed) that accumulate the PCM sound (it's padded to 2bits though. The reason becomes apparent when you look at the frequency table). But the DPCM channel is a bit too coarse in frequency steps to be considered wavetable. And I'm not sure on the specs of the FDS extra channel. (Wavetable is kinda incorrect, it's really referred to as sample-based synth) In the NES scene, all pulse modes are referred to as square. It's not the literal sense of the meaning (50% duty cycle). It's square in the sense that it's only "on/off" (square edged pulse), as opposed to anything else (like triangle, saw, sine, or something custom). Per: That's cool. I've would have never thought to check it out like that. Kudos

Well, you have a very distinct way of looking at things Or you put your threshold pretty far out there. PS wasn't "active" 6 years after the PS2 came out. PS was on it's last legs in 2000. Just because a couple of games a year come out for a few years, doesn't mean anything in the context of "chugging along". The NES was pretty dead before the SNES came out. A handful of titles doesn't mean squat. If you look at the system realistically, 1-2 years is the lead out time of the previous generation. This really hasn't change since the NES days. 16bit started in very late '89 in the US. By the start of 1991, the NES was pretty much dead and definitely forgotten by end of 1991. Same with SNES/Genesis and the Playstation/Saturn 32bit generation (yes, 3DO and Jag were out before, but come on - putting them in the same 32bit generation as the PS/Saturn just makes them look even that more pathetic). 360 came out in the end of 2005, PS3 end of 2006. By the end of 2007, PS2 was hurting bad. Admittedly it lasted a little big longer than expected, but I'd contribute that fact to the problems of the PS3 it had early on (priced pretty expensive, looked at best on par with 360 but mostly looking slightly worst in graphics and frame rate). I was a gamer in all of those generations. Including this one. And I wasn't an early adapter of systems either (for the most part early for 8bit and 16bit, but not for the rest).

That Jag looks awesome. Nice job

Yeah, 1megabyte of ram doesn't do much for consoles of that date. Unless you mean 1megabit (128k), which is what the snes had. And 10,000 polygons per screen? Screen as in a single frame instance of movement? 60fps, that's 600,000 polygons a second. Hell, even at 30fps that 300k polygons a second. Pretty unrealistic. Unless you mean 10k polygons per second. But that's extremely low (333 polygons per frame as 30fps). I like the 6309 idea. That is one badass CPU. Of course, it needs to be matched by clocked speed of around 7-8mhz and back up by at least 8k logical segments for external memory mapping. DMA doesn't have to happen at interleaved memory access. If the video system is "port" based like SNES and Genesis, then a fast DMA that stalls the CPU until finished... is just fine (it's what happens on both the SNES and Genesis).

I'm sick of Genesis being thought of as a sports games and Sonic-only system. Both of you have good points. I had a SNES and loved it growing up, but I played a lot of Genesis at a friends house during the time also, so I think both systems are very good. Each system had it's pluses. The Genesis had a faster processor so it was better at doing action and shoot-em-ups. The SNES had superior sound and video hardware, so it featured better graphics and music. But a great game could be made for EITHER system if the programer knew what they were doing. The Genesis had some awsome RPG's made for it (the Phantasy Star and Shining Force games) and the SNES had some great fast paced shooting and action games for it (Gradius III, F-Zero, and Contra III) After all, it's not the HARDWARE that determines if a system does well or not -- it's the GAMES. the kumbaya speil fails when you list the snes port of gradius iii as 'great' and 'fast-paced' the snes port of gradius iii is an abomination, the quintessential example of 'great graphics are more important than great gameplay' fact is, nintendo had 2 years to come up with a system that bested the genesis in every way imaginable. they didnt I'd say that they remedied that one sole problem with via cart addons (the way the bottom half of the logic address range is layed out/fixed - it's obvious that they planned on this idea from some point of developing the SFC).

No problem, the 65816 is backwards compatible with the 6502, so I guess the SNES should be able to run 8-bit code too. That is true. Actually, if you happen across the Super8, you can play NES and Famicom games on your SNES. Some how I doubt it's using the SNES processor in 8bit mode. More like it's a mini NES packed via crappy emulation and the video (register writes and data updates) is passed onto the snes cpu to send to the sPPU (like how the wideboy works for the NES and the super gameboy works for the SNES).

I'm wondering how the Genesis differs from the Super Nintendo. On the Genesis, I know you can request local to vram DMA during active display - but there are only a tiny amount of slots available during active display to write to vram, scrollram, or palette ram (which all reside inside the VDP). So I would imagine a DMA request from vblank would still try to continue on through when active display hits (it doesn't necessarily mean that, but the logic supports it. I've never tested for that). And the CPU is stalled during the DMA process (and should also be during active display DMA). There is a DMA status flag, which normally you couldn't read because the CPU would be halted during the whole DMA process, but if the DMA were somehow stalled or stopped on active display transition - I guess you could read that flag to see if the VDMA completed or not. So maybe on the Genesis, it does get halted/stalled when going into active display. On SNES, Anomie's doc states that regular DMA will be halted when the display goes active. And if the current DMA channel is also the same HDMA channel used for active screen FX, it will be canceled out (otherwise it'll continue when the display has ended). There's no mention of the CPU being halted during active display when the DMA is temporarily halt, but the logic suggests that it would be halted/paused and the cpu would be free - except for the few cycles HDMA might take on those scanlines.

You'd have to know your out of cycle time first, if you were going to make a setup dropped frame rate VS just slowing down. Not to mention the serious complexities of doing something like that on these old system.

The SNES has a Color Window. You can just update that instead of changing the palette entries mid-screen (can fade the screen down, etc). Not to mention transparency of BG layers to others and sprites. And like you said, more subpalettes means you could just change the map position to another point in a mirror section of the map that has alternate subpalette references. Lords Of Thunder does this on the PCE for the water level, for when the enemy smashes the ground and the water pours into the hole - lowering the level (which is absent on the SegaCD version).

It's doing more than fetching from ROM. 99.99999% of code is running from ROM. Thus, all instructions are slower. There's also the problem that you have to access rom in the higher banks of the SNES memory map layout. All lower rom range is still slow access regardless if you turn on the high speed (could allow you to mix fast and slow roms). Or just mirror the lower range with the higher range, though you half your normal cart space (little bit less because "all ram mode" is in the last few banks). Then you have to start using mappers and such for larger carts.

Correct, because it runs at 7.16mhz. I typically use 120ns rom/ram. (internal system ram is usually 120ns or 100ns - depends. Guess whatever they had on stock/hand at the time). The memory bus cycle of the 68k is 4 cpu cycles, not 1 like on the 65x arch. But, IIRC - you still need memory to respond in 2 cycles (unless you stall it with dtack or such). I.e. the data needs to be on the bus by the end of the second cycle. So in theory on the original 68k, you should be able to get away with memory at half the processor speed without any wait states. A look through the data sheets would say for sure though. Heh, it is. But what are the timings? It's possible that the address setup time to the latch is less than 1/2 memory cycle or even faster. It just happens that on the 65816, they chose 1/2 memory cycle. They could have achieved it in faster time. 1/4 or 1/8, etc. Register latches were fairly fast and cheap (8bit latches easily in the 20ns range). Like I said for the original 88/86, you'd have to look at the external memory timing charts to see what speed ram/rom is required.

It goes for anything on the bus. The 65816 is missing the upper address lines, so externally you only have 64k of address lines. To overcome this, the multiplexed the upper address lines on the data bus. So what would normally be 1 complete memory cycle, is now 1/2 + 1/2. 1/2 the memory cycle you take the data bus and store it in a simple register latch (external or on the die/package), then on the second 1/2 cycle you use the 16 address lines of the normal 6502 pins and the 8 from the latch to form a 24bit address line, you then read in the contents from the data bus. But the problem there in lies, you need memory to respond at 1/2 memory cycle or twice the speed of a normal memory cycle. The 65816 on the snes is custom. It's not stock. It has another memory layout ontop of the existing memory layout/system. It facilitates somethings, and hinders performance in other situations. You use long addressing more often. Anyway, if the cart itself had ram mapped to second half of the external address range - you could turn on the CPU to 3.58mhz mode and access that ram at full speed. But that still doesn't fix the whole DP (re-termed from ZP) address range. It's still going to get a penalty since it's in original ram. DP are the 65x address registers. But anyway, a 3.58mhz 65816 requires a little faster than 139ns memory. A 65xx at 3.58mhz only requires a little faster than 279ns memory. The original x86/x88 had so many other problems - this would be the least of them. Instruction times are incredibly slow. But I don't remember it having a multiplexed address bus (it has a bank system, but that's different). Other MCU types do though, but are like that for small pin package format. Internally or externally handled, I don't think it doesn't makes a that big of a different. Only that the mechanism/system exists. On the PCE, you're saved the trouble of having to write to a memory mapped port in the cpu's logic address range. The registers are on the CPU itself, and you you can transfer between Acc and the MPR (8k page register) like you would the SP(stack pointer) and X register. It's convenient and a little faster, but you're not swapping memory in and out for single bytes fetches and such. So the over head is tiny to non existent in most cases. Hardwiring writes to right before the int vector range for MMU external regs would be just as good. You only need 8 bytes for eight 8k pages. There are two 65C02's. The original ones WDC put out are missing some instructions. Rockwell later added a few bit set/clear, bit logic against address, and bit test branch. WDC adopted these sometime after and made them official. So you could say there's a ver1.0 and ver 1.1 of the C02. These never made it into the 65816 line. The PC-Engine's 65x variant is based on Rockwells design, but adds more instructions, dma/block transfer instructions of the 65816, and internal registers for mapping in external memory (21 external address range like you said). The PCE HuC6280 also has the beginning of branch relative addressing (for JSR and for JMP), but they limited the operands to 8bit. The 65CE02 extends them to full 16bit which makes them more useful, but this is more computer related coding (you write completely relative based code that can be loaded anywhere in ram) There's also nothing stopping them from making long addressing modes like on the 65816. It just takes one more operand byte for the 3 byte of the PC. About C? Two things really help the 65816 in C. 1) long addressing(indirect, direct, indirect+indexed, direct+indexed). This REALLY speeds up things up for pointers. 16bit index registers VS 8bit ones definitely effects speed too on the C compiler generated code. 2) Stack relative addressing. C is built on passing arguments on the stack and the '816 added SP+index mode just for retrieving this. The 65CE02 has stack relative addressing too. Though, I have to say the second part could be simulated easily in pseudo stacks just fine (and is).

You realize that the '816 requires twice the ROM/RAM speed as the 65c02 even though both are 3.5mhz, right? It has a multiplexed address and is the stupidest thing ever (that they didn't release a full pin package version without the over head and need for faster rom). It's one of the reasons why the SNES cpu runs as slow as it does. ROM speed costs. I would personally take Rockwell's R65C02 (over the plain 'c02) at twice the speed (7.159mhz) than that regular ol' '816 at half speed. You could even add onto Rockwell's design like Hudson did (and mitsubishi did). The 65CE02 or clone of would have been an excellent choice too.

No love for the CoCo? Or Zelda clones? http://nitros9.lcurtisboyle.com/questforthelda.html

Anybody who says the 32X library's crap obviously haven't played many games for the system. There are 31 cart releases, compare these numbers to my recommended list. Yes it includes already mentioned games: After Burner Complete Blackthorne Doom Golf Magazine Presents 36 Great Holes Starring Fred Couples Knuckles' Chaotix Kolibri Metal Head Mortal Kombat II NBA Jam Tournament Edition Pitfall: The Mayan Adventure Shadow Squadron Space Harrier Spiderman: Web of Fire Star Wars Arcade T-Mek Tempo Virtua Fighter Virtua Racing Deluxe Zaxxon's Motherbase 2000 These are all legitimately good games. Some may have some faults or carry the shame of being Genesis upgrades, but they aren't outright bad. That's 19 out of 31 cart releases. That means more than half the 32X library is worth owning. Try saying that about the Virtual Boy, or ANY console for that matter. Yeah, nothing on that list interests me though. So that's 0 out of 31 for me SH and AB were "OK", BITD - but I didn't even play them on the Genesis when they were new. Not even when they there were in the $5 bins and I was bin hunting in the late day of the Genesis. No, I went through the whole library with emulation. Nothing I cared for (and couldn't stand Metal Head). I own a 32x (because it came free with one of the Genesis' I bought), but I have (IIRC) no games for it. I really dislike all virtual fighter games/series (Tekken 1 BITD was badass, VF was just crap). VR has no appeal to me. Doom was a poor port of a fun game that I already had on the PC (and which I quickly grew tired of. Doom 2 was boring). I don't care for any of the other games either. Back then, I felt extreme about this. Nowadays, I'd picked up SH, AB, and Tempo. That's about it. And Tempo "only" for the sole reason that it was developed by Red Company. I think there could have been quite a few gems on it, but just never happened IMO. And for the record, the only "gems" I live on the SegaCD are the japanese ports. I can't stand the EU and US dev'd softs on it. Probably why I don't like anything on the CD-i, 3DO, CD32, Jag. Sorry. In comparison, Genesis is awesome with lots of great games. SNES too. SegaCD offers a handful of gems, but by comparison to the Genesis library - you're not missing a much if you go by ratio. And 32x, IMO pretty much nothing at all.