How would you PWN a SNES fanboy?

[gamevet]

Yeah. Could very well be the emulator. It's possible that the emulator isn't emulating all the delays of the real system (like the work ram wait states), etc. Thus, less or no slow down - but without running faster normal because games are 99.9999% timed to the refresh period. Most emulator authors try not to speed up cpu emulation because there will always be games that rely on strict timing of the real system or they break. The old way of doing emulation was to identify problem roms and apply hack code to get it to run. The new school of thought, since we have much faster systems now, is for extreme cycle accuracy. Even Fusion isn't entirely cycle accurate (wouldn't surprise me if it still employed hacks for some games). And the only accurate SNES emulator that I know of is Bsnes (zsnes is full of hacks and unaccurate emulation).

It could be that the PAL version doesn't run as smoothly either.

I've played Biometal using Bsnes or one of the other emulators, and it ran fairly smooth. I've seen countless posts on message boards that talked highly of how well Biometal ran. Unfortuneatly, Biometal is one of the few shooters I don't actually own, but I haven't seen a shooter that I do own, that ran as well with emulation.

[jesus.arnold]

I've played Biometal using Bsnes or one of the other emulators, and it ran fairly smooth. I've seen countless posts on message boards that talked highly of how well Biometal ran. Unfortuneatly, Biometal is one of the few shooters I don't actually own, but I haven't seen a shooter that I do own, that ran as well with emulation.

Don't get me wrong though, the game runs well, it's certainly no Gradius III or Super R-Type, it just tends to slow down a bit when there's a lot on screen.

[gamevet]

Don't get me wrong though, the game runs well, it's certainly no Gradius III or Super R-Type, it just tends to slow down a bit when there's a lot on screen.

Lightening Force has it's share of slowdown as well. It's pretty rare that a shooter doesn't have slowdown in one area or another.

[Zebbe]

Try playing it in 50 Hz, it slows down MUCH less then.

[Baloo]

Try playing it in 50 Hz, it slows down MUCH less then.

Playing any game in 50hz gets rid of the slowdown...

[TmEE]

TF4 has no slowdown in 50Hz other than 1st stage...

[Karakasa-Obake]

Why hasn't anybody brought up Ristar? That game is more colorful than most SNES games.

[TmEE]

....and sounds better than most SNES stuff

[Karakasa-Obake]

....and sounds better than most SNES stuff

Agreed.

[tomaitheous]

Why hasn't anybody brought up Ristar? That game is more colorful than most SNES games.

I think it's how people use the term colorful. I think most(some?) use it to mean more shades of a color. Many SNES games tend to choose the drab colors of the palette though (well, from memory anyway).

[QuickSciFi]

Why hasn't anybody brought up Ristar? That game is more colorful than most SNES games.

I did, my good friend. In the first page. But then a certain some(NO)body decided to trash my every post. I would repost it with a quote, but don't want to give him the liberty to start another Sh^t storm, if you know what I mean.

Awesome game indeed.

[tomaitheous]

True, but utilizing the VDP and Z80 directly might help. And you can do amazing things with assembler.

True, but you still have to translate the video emulation on the fly - by the 68k (convert the pixel format, tilemap format, palette map format, nametable system, etc on the fly into something VDP compatible). NES audio and video are nothing like the VDP format. This has to be handled by the cpu still (I have some experience in this -> megaman nes rom running on the PCE via my emulation code. Source code included ). The 68k has powerful instructions, but the cycle times are slow. MD cpu might be 4.2 times the clock speed, but given 8bit operations and indexing(because you would have to emulate them as such) - that's only like ~2x times faster (in relation to clock speed). Not to mention other factors like 6502 arch optimizations not translating well. Having coded for the MD, PCE, NES, GB/C as well as coding NES emulation, I have a little experience in this

The assembler has nothing to do with it. It's just a tool to convert mnemonics to opcodes. You could possibly "re-assemble" 6502 into 68k code, but that isn't emulation. And would take months to do as well.

Yuji Naka programmed an NES emulator for the Mega Drive.

So could I. But that doesn't say anything about speed or playability. Probably something in the range for 30% or less of the original game speed and that's only for the simplest non-mapper games.

[Cornugon]

It's not the same but somewhat comparable: A Amstrad CPC emulator (the machine having a Z80A at 3.5MHz) running on a basic Amiga (one with a similar 7-point-something MHz 68000) is extremely slow. So probably an inferior CPU like a 6502 (or 6510) would run a bit faster but still slow.

[Nunzio]

So wait, people say the SNES has better sound? That may be true, but based on what I've heard Genesis/MD has better music. There is hardly anything that gets close to Streets of Rage and that's just a beat em up! True, the Square stuff has nice music but generally... but it's a little bland.

[tomaitheous]

It's not the same but somewhat comparable: A Amstrad CPC emulator (the machine having a Z80A at 3.5MHz) running on a basic Amiga (one with a similar 7-point-something MHz 68000) is extremely slow. So probably an inferior CPU like a 6502 (or 6510) would run a bit faster but still slow.

The z80 instructions translate better to the 68k than the 6502. Z80 is faster for register to register stuff and slower for immediate and direct addressing. The fairs well on the 68k (the 68k can do both though). The 6502 being a totally different arch, has lots of usage of immediate and direct addressing. Also direct+indexed addressing (lots of that going on). Not only that, but it's much faster on the 6502 for such direct addressing. The 6502 can also add/sub/shift/cmp with direct addressing where as the z80 can not. Z80 code is optimized for registers operations.

ld a,#imm = 7 t cycles on the z80
lda #imm = 2 cycles on the 65x
cp #imm = 7 cycles z80
cmp #imm = 2 cycles 65x

ld a,(absolute) = 13 t cycles
lda absolute = 4 cycles

ld a,(XI+n) = 19 cycles (there is no equiv to the 6502 instruction, but this is the closest)
lda absolute,x = 4 cycles

On the opposite end, the z80 has 16bit hardware macro instructions. These emulate just fine on the 68k, but the 6502 uses several instructions for these operations - making more emulation overhead.

most 16bit operations on the 6502 are usually just 8bit+16bit->16bit. So you don't have the full impact of a 16+16->16 stack of opcodes, but you still have a branch opcode (with are 2 min or 3 max cycles on the 6502. compare that with 10 cycles on the 68k and it still has to do the emulation of that and it's own 10 cycle branch opcode). Anyway, the point is that the 6502 doesn't translate well to the 68k for emulation like a z80 does. And I haven't gone into all the other stuff on the 6502 that's a pain to emulate on the 68k; zeropage indirect, indirect-indexed, indexed-indirect, flag status updates for register loads, etc. On top of that, the 6502 is very fast cycle wise for its instructions too. That's why you can get away with 1mhz (c64) or 1.79mhz (nes) VS 3.58 and 4 mhz Z80's.