Getting started (sticky?)

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic

Getting started (sticky?)
by Jeroen on 2009-01-30 (#42547)

Ok post stuff to get started in snesdev in this thread:

So far:
http://en.wikibooks.org/wiki/Super_NES_Programming
http://hirudov.com/nintendo/Nintendo.html
http://www.snesdev.net/

Hope to find more info later.

by cybertron on 2009-01-31 (#42596)

The wikibook is ok I guess for basic things, but is really incomplete

Download MazezaM from here here This is a great framework for SNES program

For the assembler you need WLA-DX

There are tons of text files describing programming and the hardware. I think most of them are on Zophar's Domain. I have a collection of these files, I can email them if anyone wants it...

Programming in assembly isn't as hard as you think, but its still a huge pain to get anything done on that horrible CPU

by Memblers on 2009-01-31 (#42597)

I remember MazezaM, the player.asm file in there is from my NSF Player.
Sounds like it never got implemented though, spc.obj is dated 1994 and sounds like Censor's SID emulator.

If anyone ever wants NES sound in their game, I'll help.

by Hamtaro126 on 2009-01-31 (#42620)

cybertron wrote:
The wikibook is ok I guess for basic things, but is really incomplete

Download MazezaM from here here This is a great framework for SNES program

For the assembler you need WLA-DX

There are tons of text files describing programming and the hardware. I think most of them are on Zophar's Domain. I have a collection of these files, I can email them if anyone wants it...

Programming in assembly isn't as hard as you think, but its still a huge pain to get anything done on that horrible CPU

WLA-DX is what I hate about SNES-dev. You have to use .W or .B to try to port NES games. (Although I am also recoding a couple routine)

I am making a hack to enhance SMB1 (porting to SNES) using doppleganger's disassembly (although the game is in SMAS already. SMAS's Sprite arrangement is crappy in it's SMB1/2j port).

Until there is a Windows Assembler with x816 (and SNES Opcode) compatibility and do not have to use .B/.W with opcodes. I am stuck with that one *OUTDATED* assembler

________________________________________

About the NSF Player: I would like it if you can use HEBEREKE.NSF for a demo music player for SNES under one of these two conditions:

1: Make a DPCM porter/converter and player for SNES BBR format (Can give seperate DPCM samples to you to convert to BBR)

2: Use NO DPCM at all, I can do that part already as a modded NSF. Since it is simple to remove DPCM Data and remove DPCM channel ASM

by Celius on 2009-01-31 (#42625)

On the main page of this site (nesdev, I mean), there's a small section for SNESdev info. I downloaded some of the stuff a while back, and it helped me a lot for getting started. Though I still find lots of the information totally confusing/ambiguous.

Find Qwertie's documentation on SNES video registers. It elaborates more on what Yoshi explains in his docs and what's explained in other places. Which also brings me to say get Yoshi's documentation. I've heard stuff about anomie's documentation on rom hacking dot net which is up to date sort of, but I don't remember finding it very useful (I don't think I looked at it for very long). Then there was some official SFC docs floating around not so long ago, so uh, maybe back those up .

Then there's probably some good info in this thread:

http://nesdev.com/bbs/viewtopic.php?t=3780

about an emulator to use for debugging.

Then yeah, use WLA-DX. It's really not that awful. But I seriously don't know crap about SNES hardware and all that hi rom low rom crap in the header. Basically where you'll find yourself struggling is in the setting-it-up phase, initializing the system properly and making a good header. I kind of put learning about SNESdev aside after getting annoyed and having completely different results on different emulators with my test roms. I couldn't figure out some of the really basic stuff. I guess we're spoiled with the NES because it's easy to debug your stuff, with everyone having such great and up-to-date tools to do so.

by tepples on 2009-02-01 (#42633)

Hamtaro126 wrote:
Until there is a Windows Assembler with x816 (and SNES Opcode) compatibility and do not have to use .B/.W with opcodes. I am stuck with that one *OUTDATED* assembler

CA65 runs on Windows and supports 65C816, leaving only the SPC700 for some other assembler to handle.

by Banshaku on 2009-02-01 (#42634)

Hamtaro126 wrote:
Until there is a Windows Assembler with x816 (and SNES Opcode) compatibility and do not have to use .B/.W with opcodes. I am stuck with that one *OUTDATED* assembler

Then write your own.

by Hamtaro126 on 2009-02-01 (#42641)

tepples wrote:
Hamtaro126 wrote:
Until there is a Windows Assembler with x816 (and SNES Opcode) compatibility and do not have to use .B/.W with opcodes. I am stuck with that one *OUTDATED* assembler

CA65 runs on Windows and supports 65C816, leaving only the SPC700 for some other assembler to handle.

The problem is that CA65 has that in the WIP areas and possibly very incomplete, So the Assembler is no use right now for SNESdev

Yes. Initianization is another gripe, and may look hard. but there is a INIT routine for x816 from SNES Developer's lobby.

I can put together a version of the WLA-DX version of the INIT routine from the original wiki above. That is... once the 65c816 support CA65 has is completed

(If you do not believe me about the WIP support stuff. Look at the ''What's New'' or something like documentation of the current version)

EDIT: I read that may only apply if using CC65 with it, So I can do the assembler then.

EDIT 2 (Off topic): Moral of this part of my story: Make sure you look at EVERY document and website concerning info about it and double/triple check it, or do not talk at all.

by Memblers on 2009-02-01 (#42651)

I thought the unfinished 65816 support was only with the C compiler. I would think the assembler part of it would work fine, I haven't used it though.

by Memblers on 2009-02-01 (#42652)

Hamtaro126 wrote:
2: Use NO DPCM at all, I can do that part already as a modded NSF. Since it is simple to remove DPCM Data and remove DPCM channel ASM

I could do this sometime, I don't think I'm motivated enough to make a DPCM hack though (removing regs writes would be unnecessary since my player would just ignore it).

by Hamtaro126 on 2009-02-01 (#42653)

Memblers wrote:
Hamtaro126 wrote:
2: Use NO DPCM at all, I can do that part already as a modded NSF. Since it is simple to remove DPCM Data and remove DPCM channel ASM

I could do this sometime, I don't think I'm motivated enough to make a DPCM hack though (removing regs writes would be unnecessary since my player would just ignore it).

I thought the original player had a bit of a problem with DPCM (and possibly unfixed $4017 writes).

by Memblers on 2009-02-01 (#42655)

Since the emulated memory is all in the WRAM (bank $7F, right?), all register writes will just go into RAM and wait for the sound emulator to pick it up. It ignores $4017 also.

by d4s on 2009-02-04 (#42806)

Hamtaro126 wrote:
WLA-DX is what I hate about SNES-dev. You have to use .W or .B to try to port NES games. (Although I am also recoding a couple routine)

Wrong.
You don't have to specify accumulator/index size for wla dx in general and certainly not for porting NES games, it's optional.
It will guess the current mode if you don't specify the size, probably by trying to keep track of the corresponding status flags.
Putting the cpu into emulation mode and a sep #$30 should be enough.

Wla dx might become confused once you start mixing 16bit and 8bit code, but that's another story.

Also, here's a tip from someone who has already struggled to win the battle of getting his code to run on real SNES hardware:
Only use Anomies register documents as reference and disregard all other previously published ones such as Qwerties or even Y0shis, the latter ones will only get you in trouble in the long run.

Anomies doc absolutely is the most accurate and it describes every hardware quirk that can stop your code from running on the real thing.
In fact, it tells you more about the hardware than the available official Nintendo documentation.

If you have trouble understanding something in Anomies docs, consult Nintendos official documentation available on romhacking.net. (the 1995-ish ones, not the 1989 prototype specs.)

by Hamtaro126 on 2009-02-04 (#42835)

d4s wrote:
Wrong.
You don't have to specify accumulator/index size for wla dx in general and certainly not for porting NES games, it's optional.
It will guess the current mode if you don't specify the size, probably by trying to keep track of the corresponding status flags.

d4s wrote:
Wla dx might become confused once you start mixing 16bit and 8bit code, but that's another story.

True, I will not worry about the Accumulator anymore as long as codes from 16bit has not been mixed with 8bit codes.

d4s wrote:
Putting the cpu into emulation mode and a sep #$30 should be enough.

That is also a very wise thing that I could have for NES to SNES conversion, since 6502 is emulated that way

d4s wrote:
Also, here's a tip from someone who has already struggled to win the battle of getting his code to run on real SNES hardware:
Only use Anomies register documents as reference and disregard all other previously published ones such as Qwerties or even Y0shis, the latter ones will only get you in trouble in the long run.

Anomie's Documents are what I am using right now, So I am pretty much set

Thanks d4s, And say to that ''Mystery Person'' that I appreciated the tip.

EDIT: The Last Complant about ''Lables'' Unlike ASM6 and others like DASM:

WLADX only uses this:

Code:
Lable:
;Insert ASM Routine(s) Here

But Does not allow:
Code:
Lable: ;Insert ASM Routine(s) Here

And Is the official SNES docs illegal to distribute? If not, Does the official NES2GBC doc have to go in RHDN? I am confused!

by cybertron on 2009-02-05 (#42877)

Did romhacking.net just go down yesterday? Good thing I downloaded that snes developers manual at work

I was going to suggest to put this site into the top post...

by d4s on 2009-02-05 (#42883)

Hamtaro126 wrote:
d4s wrote:
Putting the cpu into emulation mode and a sep #$30 should be enough.

That is also a very wise thing that I could have for NES to SNES conversion, since 6502 is emulated that way

I have to be honest here, I never actually tried to port a NES game to SNES, I just believe that this should at least execute the code correctly. I'd imagine that the biggest gripe would be adapting NES raster code to work correctly.
A total rewrite of these using HDMA would probably be the way to go here. The SNES doesn't have hardware sprite/bg collision detection built-in, so you'd have a hard time directly porting that kind of code, anyway.

Hamtaro126 wrote:
And Is the official SNES docs illegal to distribute? If not, Does the official NES2GBC doc have to go in RHDN? I am confused!

I'm sure it's not legal, as this is confidential Nintendo material.

by Hamtaro126 on 2009-02-05 (#42901)

d4s wrote:
Hamtaro126 wrote:
d4s wrote:
Putting the cpu into emulation mode and a sep #$30 should be enough.

That is also a very wise thing that I could have for NES to SNES conversion, since 6502 is emulated that way

I have to be honest here, I never actually tried to port a NES game to SNES, I just believe that this should at least execute the code correctly. I'd imagine that the biggest gripe would be adapting NES raster code to work correctly.
A total rewrite of these using HDMA would probably be the way to go here. The SNES doesn't have hardware sprite/bg collision detection built-in, so you'd have a hard time directly porting that kind of code, anyway.

For Sprite 0 hits, Disch gave me a little ASM example using IRQ in place of Sprite 0. It uses one RAM byte in $B8 (and include $B9 if 16 bit)

In NMI:
set $B8 to #$00, change Sprite 0 hit detection from STA $2002 to STA $B8 then make IRQ Init code, now redirect to the main NMI stuff with RTI at the end

In IRQ:
set $B8 to #$40, then disable/acknowlage IRQ. RTI it

by cybertron on 2009-02-05 (#42914)

Phew, Romhacking is back up. That developer manual is really interesting! Should be required reading. Maybe a Soviet spy took it...

Has anyone ported a NES game before? I would imagine it would be really difficult as you would have to re-write most of it

I know someone ported Sonic 1 to the 32X, but thats a whole different concept.

by MottZilla on 2009-02-05 (#42916)

Porting a NES game to SNES is not hard if you have the source code. Most of the code can stay the same, the differences will be three things. Audio, Graphics, and Memory Mapping. Simple NES games that are NROM have been hacked by various groups to run on SNES without any access to source.

by Memblers on 2009-02-05 (#42921)

I always wanted to be able to hack my sound emulator into those hacked-up ports. Maybe I'm optimistic, but I don't think it would be hard to make an NES PPU emulator for SNES. Replace register writes with JSRs and have at it.

The real fun would come though, with any cycle-timed PPU tricks (I'd just forget about it). Bankswitching would be a chore.

Sound part is done, except for DPCM.

by Hamtaro126 on 2009-02-06 (#42947)

I am going to contact the people under development of WLA-DX to see if the lables can be fixed like explaned last time, or it's unportable!

by Bregalad on 2009-02-06 (#42949)

Quote:
Sound part is done, except for DPCM.

Mmh, it seemed that the noise part needed some serious optimization. You should probably use noise simples with a lockup table for pitch instead of using SPC-700's noise, so that you can get the 2 loop lenght proprely.

Quote:
The real fun would come though, with any cycle-timed PPU tricks (I'd just forget about it). Bankswitching would be a chore.

The SNES features both raster IRQ and HDMA which can handle all of this very easily. Games that use, say, MMC3 IRQs could be redirected to raster IRQ on the SNES, and those who does loop to do wavy effects could store the result of the loop in a buffer that would be sent on HDMA next frame (needs a 1-frame delay). Altough each game would have to be hacked manually.
Quote:
Simple NES games that are NROM have been hacked by various groups to run on SNES without any access to source.

I'm interested to see that, but I didn't see that anywhere. Link please ?

by Memblers on 2009-02-06 (#42974)

Bregalad wrote:
Quote:
Sound part is done, except for DPCM.

Mmh, it seemed that the noise part needed some serious optimization. You should probably use noise simples with a lockup table for pitch instead of using SPC-700's noise, so that you can get the 2 loop lenght proprely.

Oh, I did forget about that. Even Chibi-Tech's song in the intro, which was even arranged for that intro, used the looped noise. That's so blatantly wrong, heheh.

I don't think it could ever sound right because of the samplerate and especially the SNES's sample format (loop alignment is comparable to making looped DPCM instruments on NES - not as bad though). But it could at least sound similar, I'll keep that in mind if I ever end up working on it again.

Quote:
Quote:
The real fun would come though, with any cycle-timed PPU tricks (I'd just forget about it). Bankswitching would be a chore.

The SNES features both raster IRQ and HDMA which can handle all of this very easily. Games that use, say, MMC3 IRQs could be redirected to raster IRQ on the SNES, and those who does loop to do wavy effects could store the result of the loop in a buffer that would be sent on HDMA next frame (needs a 1-frame delay). Altough each game would have to be hacked manually.

I think that would work too, the danger is that the SNES is 2X faster than the NES, so if those 224+ writes include much workload, then it'll be too late. I can see $2006 writes being a problem, $2005 should be doable though. HIRQ could go every scanline (or maybe 2) to change the indexing for the emulated PPU write buffer while it's being created.

by Memblers on 2009-02-06 (#42981)

Bregalad wrote:
Quote:
Simple NES games that are NROM have been hacked by various groups to run on SNES without any access to source.

I'm interested to see that, but I didn't see that anywhere. Link please ?

Look under AS. http://www.theesa.com/
Also, Arkanoid right above those.

[No links to romz sitez please. --MOD]