High level SMB Disassembly on RHDN

[Hamtaro126]

The RHDN release seems to not have a good upload...

As in: It is corrupt.

Movax12, Can you please solve it?

EDIT: The person actually posted a corrupted link posing as a ZIP file using the WikiSend File Shareing site, He should find a better place to upload things like this!

[Movax12]

I'm sure it will be resolved soon.

[Movax12]

This is fixed, Hamtaro126. Please see http://www.romhacking.net/documents/635/


Edit: Maybe we could change the title of this thread? Maybe: High level SMB Disassembly - Released

[rainwarrior]

Here, I made some FCEUX debugging symbols with this, for people who would like to inspect it with FCEUX.

(It also works on a regular SMB ROM, you don't need to go compiling Movax12's.)

[teremochek]

Hey. The really interesting code!
I want to ask questions.
When I change the source code (make mistakes), then build, wait, and nothing happens.
In the folder "obj" appears Fail "smbdishl.o". No more files do not.
What a way to debug?

[Movax12]

I don't think I understand the problem. Could you try to explain more?

If you are getting an assembly error, please check the line referenced in the error output.
Example: There is something wrong at line 188:

src\smbdishl.s(188): Error: Unexpected trailing garbage characters

[tepples]

The problem with ca65's error messages for programs that use lots of macros is that "Unexpected trailing garbage characters" shows up on the line where the macro is called even if the error is inside the macro.

[thefox]

The problem with ca65's error messages for programs that use lots of macros is that "Unexpected trailing garbage characters" shows up on the line where the macro is called even if the error is inside the macro.

This was fixed (kind of) a long time ago, but I'm not sure if the change has made it in to the release version yet. In some situations what you described will still occur, but it's pretty rare.

[Movax12]

The problem with ca65's error messages for programs that use lots of macros is that "Unexpected trailing garbage characters" shows up on the line where the macro is called even if the error is inside the macro.

There was the opposite problem for some time with the snapshot releases: It would only show the error line inside the macro and not where it was called from at all. This was fixed: The error messages are pretty verbose/helpful now.

[teremochek]

Now I'm running CMD and see a error message.

Code: Select all

ld65.exe: Warning: src\nes.cfg(9): Memory area overflow in 'ROM', segment 'CODE' (1 bytes)
ld65.exe: Error: src\nes.cfg(9): Start adress too low in 'ROM', segment 'VECTORS'

[Movax12]

Unfortunately there is no room left in the ROM. If you want to add code you're going to have to figure out what you can remove or a way to add banks.

[teremochek]

Unfortunately there is no room left in the ROM. If you want to add code you're going to have to figure out what you can remove or a way to add banks.

If I add a bank, then the new code will work with your code?

What is better to remove the code inside?

Another question. Which program is better to edit the code?

[teremochek]

Can anyone explain how to add a bank?

(Good idea to port Mario for easy programming language. I do not understand how the assembler, too many unclear statements.)

[qbradq]

There's been a lot of discussion about this in the past, but I'll give you the 10,000-foot view as a starting point. Also, I'd like to mention that this is an excellent first hack to get your feet wet with NES development! Don't dismiss it as too complex!

First, understand what a memory mapper is and what it does. The wiki doesn't really have a high-level overview, so I'll start with that.

The NES's memory goes something like this:
$0000 - $07FF RAM
$0800 - $7FFF Registers and etc.
$8000 - $FFFF Game code and data

That gives you 2KB of RAM and 32KB of game code and data to work with, of which SMB uses just about all of it. Using only the NES, there is no way to access more game code or data.

A memory mapper allows a game to access game code and data beyond the 32KB limit by means of "bank switching". For instance, if we have a game with 128KB of code and data, we could think of it as 4 separate 32KB "banks", and we could call them banks 0 through 3. By means of bank switching, we can select which of the four banks are visible to the NES in the address space $8000 - $FFFF at any given time.

One way to approach extending SMB into multiple banks is to use the fairly simple BNROM mapper, which provides 4 separate 32KB banks for code and data, but uses RAM for the character patterns.

The strategy is to embed all character data (8KB) into the first bank, along with the code to load that data into character RAM, and the rest of the code to initialize the system. The other three banks will contain copies of the original 32KB SMB code and data bank with your code modifications, consuming level data to make up the extra room. Finally you split the level data into separate banks and change the level load routine to bank switch prior to passing the data pointer back.

There are other approaches that have been used in the past, and many more to come I'm sure.

[cpow]

I wonder if I'd face any repercussions making a NESICIDE project out of this? Source code is OK but CHR is not?