Disch wrote:
Hamtaro126 wrote:
Tokumaru: I want it converted because the Genesis has better features, But I cannot do it on the SNES, Because it is hard to know how to put certain tiles (Status bar, Tiles, etc) in the SNES's PPU (Layer Related) and the Genesis is a little better anyways.
I have to question your decision here.
1) The SNES's CPU is backwards compatible with the NES's (it even has a 6502 "emulation" mode), so code conversion wouldn't even be necessary apart for a few initialization things and things you'd have to do anyway (like the code that interfaces with the PPU/APU/etc)
But here's another reason: The lockout chip on the Genesis is well known: just write "SEGA" to one specific memory location within the first few instructions. The one on the Super NES isn't, nor is it back-compatible with that of the NES.
Quote:
2) I'm curious as to what features you claim are better on the Genesis. From what I understand the only advantage Genesis has up on the SNES is its CPU is faster -- but since you'd be doing a code conversion with a conversion utility, you'd probably lose all that speed increase because the new code would be bloated compared to the original (look at the conversion file that comes with the program you linked -- it converts one 6502 instruction to like 6 or 7 68000 instructions.. unless the Genesis CPU is 6x the speed of the NES CPU, which I doubt, your conversion will actually run slower than the original game).
Sometimes it's possible to recognize more than one 6502 instruction and translate it to one 68000 instruction. For example, I believe there's one 68000 instruction 'dbeq' that does the equivalent of 68000 'dex; bpl'. Things like 'lda #something; sta somewhere' can be optimized into memory-to-memory 'move' instructions. But still, the amount of time spent optimizing the CPU would figure into the cost-benefit curve, probably with a lower weight for optimizations that can be performed automatically for each ROM.
Quote:
As far as the SNES goes, it has tons of features -- but the only one you'd probably use would be DMA... and probalby HDMA to split the screen (unless you put the status bar on another layer, which would probably be easier)
All-Stars appears to use the third (low-color) layer for both the status bar and a parallax plane.
Quote:
3) The same nametable concepts that apply to the NES apply to the SNES as well. The only real difference is the SNES is 32x32 tiles and the NES is 32x30 tiles -- and the tiles are formatted a bit differently (SNES has bits to H/V flip tiles, assign attributes, etc). I can't imagine that Genesis' tile format is more similar to the NES's.
Documents from zophar.net (I admit, they're old) disclose this:
Code:
FEDCBA9876543210 MD VDP nametable format
||||||||||||||||
|||||+++++++++++- Tile number
||||+------------ 1: Flip horizontally
|||+------------- 1: Flip vertically
|++-------------- Palette number
+---------------- Priority
FEDCBA9876543210 SHVC PPU nametable format
||||||||||||||||
||||||++++++++++- Tile number
|||+++----------- Palette number
||+-------------- Priority
|+--------------- 1: Flip horizontally
+---------------- 1: Flip vertically
Quote:
Quote:
As for the SNES's sound, It is kinda hard to create.
How do you figure?
One hard part is to get the equivalent of "hello world" even working on the SPC700.
Quote:
The hardest part is creating the BRR encoded samples
Really? Couldn't one just take samples from the mod archive, write a BRR encoder, and encode those samples?
Quote:
-- but you could probably just rip those from Mario All Stars or a similar game. Hell you probably even be able to rip the music engine straight out of All Stars and drop it right into the conversion -- that way you wouldn't have to rescore the soundtrack and write a new music engine like you would have to on the Genesis.
As I understand it, we're using SMB1 only as an example of a generic NROM/CNROM/U*ROM game that would be ported. So we have to pretend All-Stars doesn't exist, as it wouldn't for the other games.