News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - w7n

Pages: [1]
Currently the engine is only meant for this hack, but I might release a patch for the original SMB that implements the engine.

The level data format is still in the planning stage, but some of it has already been implemented in code. It has alpha-stage functionality in the project currently.
The following are adapted from my own notes. Feel free to fill in the missing blanks.

The level editor is being programmed in Delphi. I'm not really familiar with the IDE though, so progress on this level editor is rather slow. If you're familiar with Delphi then help is welcome.

C1 System architecture

1.1  I/O format of the editor
Editor-specific level data files can be in any format, but the editor should be able to output either hex files or compilable asm source.
The editor should output these files:
> Level data files
> Background files
> Table file for background of upr & lwr areas in H+V levels
Outputing to a compilable asm source is the recommended solution for level data, while outputing to a hex file is the recommended solution for backgrounds.
A line of an object in the asm source code looks like:
  HOR 0,3,8,14,QuestionFlower
The HOR is a pre-defined macro.

1.2  Hierarchy

First note that a 'metatile' is a 16x16px tile. The SMB system process almost everything about level loading in metatiles.

-- Area data --

               [decides w/table]         
(World number) ----------------- (Map bank) (Maximum size 8191 bytes)

Map bank file: Map**.65s (** denotes a number)

The structure of a map bank:

Code: [Select]
64 area data pointers (areas are labeled $00 to $3F) ------
 64 enemy data pointers -------------------------           |
                                                 |          |
 |                                               |
 V                                               |
 (Data of area $00)                              |
 Header part                                     |
 Objects part, with a specific termination byte  |
 Enemy objects part and 'area entry' data part, with a specific termination byte

-- Background data --

Code: [Select]
         [Find ID of lower and upper area w/table]
                     /                  |            [BG is filled with a single metatile]
                    / Y                 |             /
                   /                    |            /  Y
(BG setting) -- [H+V level?]         (BG ID) -- [ID < 4?]
                   \  N                 |            \  N
                    \                   |             \
                 [Setting = ID] --------             [Look for the (ID-4)th background stored in the BG banks]

Background bank file: BGBank*.bin (* denotes a number, for example BGBank0.bin)

The structure of a BG bank is simple: One background is composed of 1 page, stores 256 metatile bytes. Thus a BG bank stores 32 backgrounds.

Code: [Select]
    0 1 2 3 4 ... F  (y)   +--------------> y
0   * * * * *     *        |
1   * * * * *     *        |
...                        |
F   * * * * *     *        V  x
The only thing needs attention is that xpos and ypos are not the same as aligned in a hex editor, instead they are swapped.

-- Metatile data --

There are a total of 256 metatiles available for use. Since the CHR banks are not fixed though, the metatile graphics are determined by several bytes in the level header: One is the area style byte (determines CHRBank4 and CHRBank5), another is the area BG byte.
To actually calculate the graphics isn't easy work perhaps, so the metatile GFX setting can be an editor-exclusive setting that is never exported.
Earlier, I've made a .BMP exporter to export metatile data.

1.3  How the map is preprocessed in the ROM hack

1.3.1  Basics

Firstly: a horizontal level takes up at most 16 pages, while a H+V level takes up at most 8 pages horizontally and 2 pages vertically.
For the map data, the lower part of an H+V level is stored separately from the upper part, and its ID is the AreaID of the upper part plus 1. And the lower part has no header.
For example, if you're loading area $0B which is an H+V level:


Area0C: ;The corresponding lower part of area $0B

This doesn't apply to enemies: Enemies are all stored in Area0BEnemy, there is a flag to indicate whether the enemy object is in the upper or the lower area.

The y-length of a horizontal level is 13 metatiles, while for H+V levels it's 28 metatiles. Usually it's 28 = 16(upper) + 12(lower), the exception is the terrain.

1.3.2  The metatile map

We can say that there are 3 'layers' of the metatile map and they are written in the following order:

#1: Background.
Backgrounds are saved separately in the files, as explained above. The header includes a BG setting, and BG settings can be changed midway during the level.

For horizontal levels -- BG setting = BG ID. Only the top 13 lines of metatiles are actually used.
For vertical levels -- Use the H+V BG table to find out the BG ID for the upper and lower areas. The upper area takes all 16 lines, while the lower area only takes the top 12 lines.

The BG processing routine processes BG by column, and when it finishes column 15 it goes back to column 0.
Changing the BG setting midway does not reset the column of the BG renderer, instead it renders the changed BG from the next column.

Note that after BG rendition, metatile $00 will be treated as 'transparent' and doesn't overwrite the BG. Hidden blocks don't overwrite the BG ingame, but in the map editor showing them is better.

#2: Terrain.
Terrains are controlled by terrain bit objects, and the header also has two bytes for them.

For horizontal levels -- 13 lines
For vertical levels -- Upper = 15 lines, Lower = 13 lines

Terrain graphics have a Metroid-like approach: Although the existence of terrain blocks is only controlled by a bit on/bit off, the actual terrain block is determined by its surrounding blocks.
The terrain block metatiles are defined as such in the source code:

;4 6

TerNothing = $D0 ;This means a solitary terrain metatile
Ter2 = $D1
Ter4 = $D2
Ter6 = $D3
Ter8 = $D4
Ter24 = $D5
Ter24_1 = $D6
Ter26 = $D7
Ter26_3 = $D8
Ter28 = $D9
Ter46 = $DA
Ter48 = $DB
Ter48_7 = $DC
Ter68 = $DD
Ter68_9 = $DE
Ter246 = $DF
Ter246_1 = $E0
Ter246_3 = $E1
Ter246_13 = $E2
Ter248 = $E3
Ter248_1 = $E4
Ter248_7 = $E5
Ter248_17 = $E6
Ter268 = $E7
Ter268_3 = $E8
Ter268_7 = $E9
Ter268_37 = $EA
Ter468 = $EB
Ter468_7 = $EC
Ter468_9 = $ED
Ter468_79 = $EE
Ter2468 = $EF
Ter2468_1 = $F0
Ter2468_3 = $F1
Ter2468_7 = $F2
Ter2468_9 = $F3
Ter2468_13 = $F4
Ter2468_17 = $F5
Ter2468_19 = $F6
Ter2468_37 = $F7
Ter2468_39 = $F8
Ter2468_79 = $F9
Ter2468_137 = $FA
Ter2468_139 = $FB
Ter2468_179 = $FC
Ter2468_379 = $FD
Ter2468_1379 = $FE

#3: Area objects.
Area objects should always be sorted by their x positions, and the latter objects would overwrite metatiles created by former objects.
Objects on the same column can be manually sorted, but (if on the same column) objects in the lower area always come later than objects in the upper area and will overwrite their metatiles.

For horizontal levels -- 13 lines for normal objects, last 3 lines for settings
For vertical levels -- Upper = 16 lines for normal objects, Lower = 12 lines for normal objects and last 4 lines for settings

Note that if an object in the upper area is long enough, it will find itself occupying space in both upper and lower areas.

1.3.3  Enemies

Enemy data are separated from area objects, and they are much easier to document.
Enemy data also stores 'area entry'(where a pipe should lead to) data and other settings.

There are several sets of enemies, but only one set can be used at a time. Exactly which set to use is set(overwritten) by an enemy object.

1.4  Area object structure

Once again:
For horizontal levels -- 13 lines for normal objects, last 3 lines for settings
For vertical levels -- Upper = 16 lines for normal objects, Lower = 12 lines for normal objects and last 4 lines for settings

The termination byte for area data is #$FE, while the page skip byte for area data is #$FD. Otherwise, the first byte of an area object is always in this structure:


X = X column, Y = Y column

Normal objects:


B always denotes the object length. The actual object length is B+1.

A = Type of object.
A = 00: Special object
A = 01: Vertical block (starting from x,y and goes downward)
A = 10: Horizontal object (starting from x,y and goes rightward)
A = 11: Objects of infinite vertical length (starting from x,y and goes downward infinitely, then copied horizontally)

If A != 00, then B denotes the object length (B denotes the horizontal length if A = 11) and C is the metatile ID.

If A = 00, then C is the routine ID. For example C=0 means a vertical pipe.



If X=15 this is the page skip object and there is no second byte. The object will be treated as if it carries a page flag by default.
Otherwise, the Ath routine will be called. Usually used to conditionally skip or load the next object, for example, if the player has Lens of Truth then skip / load the next object.


XY = #$FE means end of data. Otherwise:
If A<>0, this is a setting object with B as a coefficient. List:
A=1: X autoscrolling. If B=0 then revert to normal scrolling.
A=2: Y autoscrolling. B=coefficient: 0=cancel, 8=stopped, 1=upwards fastest, 15=downwards fastest
A=3: Y scroll position autoscrolls to B*16.
(Others undefined for now)

If A=0: Setting object without coefficient. Current list:
0: Hard mode
1: Smart enemies
2: Enemies won't be removed if out of screen boundaries
3: Certain enemies run in normal code
4: Certain enemies' trajectory are set with preloaded code chunk 1
5: ...code chunk 2
6: Certain enemies fire a bullet aimed at the player every 4 seconds
9: Stop enemy frenzy
10: Checkpoint - start at bottom of upper area
11: Checkpoint - start at bottom of lower area
12: Scroll stop (x only, same as below)
13: Scroll stop (end of level)
14: Scroll stop (Megaman cutscene-ish)
15: Scroll stop (until all enemies onscreen defeated)



A: Setting type.

IF A==00:
B: Palette type
C: BG type

IF A==01:
B and C: Terrain bits. If H+V level, then it stands for the terrain bits of the lower part.

IF A==10:
B: Lower 4 bits used, this means 'When player reaches a position that's the same as the object's x position and lower than B*16 px, trigger cutscene C'. If the high bit of B is 1 though, the Y judgement is ignored.

IF A==11: Setting object whose type depends on B.
B=0: Change BG (of the SMB's own mechanics, for example castle walls).
B=1: Preload chunk 1. C=routine number
B=2: Preload chunk 2.
B=3: Set the type of the next undefined powerup. The highest bit of C means upgraded status.
(Others undefined)

Y==12 of lower part of H+V level:

A: Terrain bits.




TT: Type. 00: Normal, 01: Appears on the left edge of screen, 10: Trigger, when the player touches its bounding box it disappears and triggers an event, for example 8 projectiles shoot towards the player. The third byte stands for trigger ID. 11: NPC with dialogue, this kind of enemy uses another format.
BBBB: Enemy type. Determines PRG and CHR bank used for the enemy. If B=0, then do not change PRG and CHR bank settings.
R: Random enemy.
E: Enemy ID. If R=1, E stands for random enemy setting.

IF T == 11 (NPC with dialogue):
E: Enemy ID
C: Cutscene ID

Y==14: Pipe entry data.
A: Entry area number
E: Entry type, 0=none 1=leftward 2=rightward 3=downward 4=upward 5=vine upward 6=vine downward 7= (undefined)
B: Entry page
x,y: X and Y coordinates. Actual X and Y coordinates are: xxxx xxx0 and yyyy 0000.
p: If p==1, then player appears at the lower half of the level
W: World number
Unlike the original SMB, this object doesn't work like 'when it's loaded then change pipe entry settings' but rather 'all entries right of this object use this setting'.

Y==15: If XXXX YYYY = #$FF then it's the end of data byte, else:
A=0: If B=0 then it's a blank object. Otherwise, B is the routine number. (Also may be used to conditionally skip objects) If the highest bit of B is 1, then it's not executed in real-time but rather in level data preloading.
A=1: Change BGM.

Level header:
> TTTT AAPP   T: Time setting (0=do not set), A: Area type, P: Initial Y position
> TTTT TTTT CSLT TTTT  C: Ceiling judgement (0: Ceiling hollow; 1: Ceiling has same attributes as the highest metatile of the same x position), S: Safe zone, L: Landform(terrain) GFX type, T: Terrain bits
> LSSS SSSS  L: L+R level, S: GFX settings type
> One byte for BGM
> One byte for starting BG
> VPPP PPPP  P: Palette, V: H+V level
> One byte for local map ID
> One byte which determines the level's position on the local map. YYYX XXXX
> TTBB BBBB   T: Time flowing speed setting, B: Player to background collision setting (used for moving background)
> Two bytes depending on the area type:
--If H+V level: The starting terrain bits of the lower area.
--If not H+V level: The two routine IDs for preloaded data.
> Finally a null-terminated string for the name of the level.

Notice: This project is not dead. Unless this notice says otherwise or if 10 years have passed since this message was written (2017), this project is ongoing and will be hosted on RHDN (probably along with other sites) when released.
However, updates will not be posted on this page regularly anymore. If you wish to join, contact me.
This is not due to any grudge towards the site (I have mostly none).

Political views aside, this slogan is good for memetic use.

The short version: This Super Mario Bros. hack project, named Mario Gaiden, is meant to be as epic as possible. It's almost impossible for me to finish this project on my own, since I don't do well in coping with some aspects like graphics.
What kind of things or people do I need?
I need more ideas, people who draw good NES graphics, people who can help me with the story, and probably an English->Japanese translator. If someone is good at the NES chiptune, please help too!
PM me if you'd like to help.

The short version doesn't look promising? Check the long version below.

Before the summer vacation in 2013 the project Rohrleitung Gate was progressing really slow due to lack of graphics. At that point, I copied the Rohrleitung Gate ROM into a new file, removed some of the effects and added some new effects. The new project was named Mario Gaiden.
However, later my computer's hard disk was broken and then later I underwent a surgery. My SMB hacking projects were suspended until September. The ROM file was still yet to be recovered by then, so I started making patches for the new project.
For now I've abandoned the Mario Gaiden ROM and started to use doppelganger's SMBDIS to program. (I still need to have the ROM recovered to retrieve some effects, though.)

List of effects already done in the old Mario Gaiden ROM:
1: VRC7 music, although limited to 1 channel like in Rohrleitung Gate. The music system is already a giant improvement on the SMB music system. (A new music system has been set up now.)
2: Multi-layer background, using CHR bankswitching.
3: IRQ. Now the split screen is not done by detecting sprite 0, it's done by using the IRQ system. This saves plenty of time.
4: Ground graphics forming. This was originally made by ATA, and altered by me.
5: The 'snake' effect. This is an effect used in a stage of Rohrleitung Gate. The snake goes in a fixed route. When it eats coins it grows.
6: Better usage of item attributes. One tile may appear to be tile A but function as tile B(stored in the level data).

New powerups, abilities, blocks and other minor changes / mechanics:
1: 'Soft' bridge. You can jump up onto it from below. (No demo image)

2: Megaman type cutscene.

3: Platform whose route is fixed and user-defined.

4: Boo. (The patch was updated later, this image is the demo of an older patch)

5: Special abilities, equipment etc: These are categorised into 4 categories: Ability-A (jump abilities), Ability-B (offensive abilities), Equipment, Spell Card (one shot items).
Using the abilities consumes coins.
Currently complete or half-complete items:
Feather (slow the descending speed down)
Spin jump (graphics and mechanics incomplete)
Double jump
Cloaking (injury invincibility)
Starman (star invincibility)
Cross (destroys normal enemies and do damage to bosses).
Ether Ring (halves manacost i.e. coin cost)
Speed Booster (I'm still considering adding the shinespark ability along with it)
Charge Shot (Different powerups have different charge shots, for example Fiery Mario fires a charged wave)
Pausing the game will let you switch abilities; Also all of these have descriptions(both serious description and memetic description). See Re#26

6: Powerups:
Fiery Mario - Mostly same as the original, but Mario can shoot upwards('Technical fire' from Extra Mario Bros). Upgraded powerup creates a huge blast when the fireball explodes, killing enemies nearby.
Bat Mario - Fires a larger but slower fireball, can turn into a bat and fly but this consumes coins. Upgraded powerup consumes less coins when in bat form, and automatically turns the player into a bat when he's about to fall into an abyss.
Gunner Mario - Fires powerful shots in 10 directions but only on the ground. (Upgrade: Not yet designed)
Ice Mario - Freezes enemies in place, frozen enemies can't harm the player but can be stepped onto. Upgraded powerup will destroy fiery enemies immediately.
Ninja Mario - Wall clinging(slower descending speed in fact) and jumping. (Upgrade: None.)
And probably two more to come.

7: Smart enemies setting: For example, goombas would jump if they are on the edge of a platform, and Lakitu throws spinies in a direction depending on mario's position. (No demo image)

8: The slope(only 45 degrees available).

9: Cheats: In the pause menu you can input cheats, but using one cheat would set the continue count to the maximum. Some cheats are sequence / game breaking.
For example, the cheat 'AKARIN' sets the injury invincibility timer to the maximum.

System improvements:
System 01: Tired of H- scrolling? We have ATA's V- scrolling. Tired of V-scrolling too? We have H+V scrolling.

(This is an experimental patch, hence the '000000' in the background.)
This system has been enhanced: Now scrolling in 4 directions is possible.

Update: System 02: Boss fighting(see Re#1)  Programmed boss fights
System 03: VRC7 music system(see Re#13)  Supports up to 6 channels, currently not many note effects are supported(unsupported: e.g. arpeggios).
This has gone under a revision, but probably yet another revision is necessary for more complex music.
System 04: Cutscene system(see Re#26) Very powerful in manipulating SMB mechanics, supports dialogue boxes
System 05: Multi-layered map(not just background)
System 06: New level data structure and loading mechanics, which allows more freedom in designing.

Other stuff mostly complete: IRQ system(which supports parallax scrolling), reworked sprites(minimum=8x16 instead of 8x8 and allows more freedom in arranging sprite slots: sprite shuffling is removed for this)

Help or ideas on any aspect is welcome. If you're interested you can even join the project.

Info about the ROM:
This ROM uses Mapper 85(Konami VRC7), 4-screen mirroring, CHR ROM(not RAM).
(some emulators don't support VRC7 4-screen, but according to the nesdev forum it's theoretically possible. FCEUX supports VRC7 4-screen anyway.)

For anyone who wants to design graphics for the game please be sure to read some detailed plan:
The script:
W1 Cutscene: Mario goes to the castle and talks with Peach.
W1: (Dawn)Plains, hills and forests.
W2: (Noon)Desert land + Inside the pyramids.
W3: (Day)Sky land + Paradeisos(Paradeisos looks like the Upper Kingdom in Chrono Trigger)
W4: (Evening)Shimizu Town, (Night)Mountains & lakes.
W5: (Dawn)Shin City, (Day)Mountains, the Great Wall, the underground ruins, the Ghost House. There is a huge tree at a certain spot, from one of the branches of which can people be HANGED.
W6: (Noon--afternoon)The fort, and mountain scenery.
W7: (Sunset)The drawbridge, (Evening--Night)Lava castle.

Also, if possible the post-game content would be quite large, with more sidequests and dungeons.

Do not design starry skies. The story takes place when it's rather near full moon, and when a full moon is in the sky there are few stars... Both the moon and the few stars are sprites.

Programming / Curious about a problem with the MMC3 IRQ.
« on: September 29, 2013, 08:54:32 am »
Some time ago I was reverse engineering ATA's 'vertical' patch for the game Super Mario Bros. The patched game works on VNES, but it doesn't work on FCEUX or Nestopia. I used the FCEUX's debugging function, and I found that the game got stuck in the IRQ routine.

So here's the code:
;IRQ Routine
LDA #$00
STA $C000
STA $C001
STA $E000

And the result: the IRQ routine gets executed immediately after the RTI, creating an infinite loop. Seemingly the IRQ isn't acknowledged at all--although this part of code ALWAYS gets executed.

So... Is there any problem with the code? Or, in what cases can this glitch occur?

Personal Projects / Project Rohrleitung Gate(SMB1 Hack) (Now released)
« on: February 28, 2013, 09:30:18 am »
13 Sept 2016 Update: It's now released on RHDN.
A playthrough video of this version:

Rohrleitung Gate is a project I started in 2012. Initially I didn't want to make a huge project, but now it's a 100+ KB ROM.
It probably should have been released in 2013, but after I completed the custom background mechanics, the lack of graphics prevented me from releasing it, and as of now this part is still very underdeveloped. Since I've shifted my focus towards Mario Gaiden, it's time to put the finishing touch to this hack and work on Mario Gaiden. (In fact that project borrowed several of the ASM changes from this hack)
Main contributor is me, co-contributor goes to GAP (GAP_15 on Baidu Tieba) for designing a few stages.

The game is a puzzle-solving game. It's not a maze like Extra Mario Bros. The course is linear, but almost every stage is a puzzle.

Current changes include:
-- Forward&backward scrolling within 2 pages.
-- Multi-layer background effect in various stages.
-- Koopa shells can break bricks and bump into hidden blocks, revealing them.
-- Enemies can appear on the first page.
-- Konami code(Up Up Down Down Left Right Left Right B A) can be entered on the title screen, increasing the num of lives to 31 and activating hard mode.
-- Recomposed soundtrack. What's significant about the soundtrack: SMB only used the 4 traditional channels, but here I've made use of the DPCM and VRC7 channels. A PCM sound effect is also included.
-- More minor effects.


The background I used in a stage. Note that it's actually a multi-layer background: The stars won't move, the hills move at 1/2 speed, others move normally.
(It's not raster scroll of course, it's done by changing the CHR tiles. The limitation is that the background gets repetitive. If a part of the background doesn't use the multi-layer effect, that part can be completely user-defined.)

The infamous fake wall.(This is not a new effect.)

A puzzle-solving stage. The pipe shown is the exit, but it's blocked. (Things are not so simple here... Currently, this is the best stage I've designed in this project. Note: Edits are made to this stage later to fix some issues)

OK I don't know the term for 'translating' in this way, I'll just call it 'transliteration' here.
We got games like Super Mario Bros, Dragon Quest, and their names in Japanese are Suupaa Mario, Doragon Kuesuto, respectively.
Now suppose the German word 'Rohrleitung' is in the name of a game, how should this word be translated in this way?
(The game I'm talking about is one of my projects. I have the title screen coded in a different way, so I want to finish it now and leave it unchanged.)

OK, I don't know the answer to the spambot question on the NESDEV forum register form, so Mr.Bot is trying to look for an answer here.

Some time ago I did a simple experiment on the Super Mario Bros (JU) ROM--changing the mapper number from 0 to 85(VRC7 mp). Emulation on different emulators varied. On some emulators like VirtuaNES, NNNesterJ, all was well; on some others like Nestopia, it couldn't run. On FCEUX, emulation was OK, but when a savestate was loaded it started glitching.

This puzzles me. Truly, different mappers have different bank sys, IRQ sys etc. But this problem was beyond my explanation although seemingly simple. The SMB ROM sets the I flag at the very beginning and leaves it on. But when FCEUX loads a state, an IRQ is generated, and the IRQ routine(in SMB1 the routine is an infinite loop) is called, and the CHR banks are in a mess. I tried coding IRQ routines and handling(disabling) IRQs in different ways, but eventually I reached wit's end.

'It appears as if' loading the savestate in FCEUX sets some things which should have remained their own values. But this is highly impossible. The other explanation I can think of is that there are some settings which should be set in the reset routine, but if so, what are these settings? This is not related to VRC7 audio of course.

Waiting for a genius...

Hiya folks. I'm w7n here, and I already have a hack submission and a doc submission at RHDN. I've been active in the Baidu SMB Bar(a Chinese community) since 2 years ago, but ever since the admin there banned the distribution of the 'spike' IPS, the community went into chaos, so I'll try to stay active here.

Some time ago I learned ASM and I have some ASM projects and unfinished WIPs here. A complete project named 'Lost Mario' can be found at my home page. One unfinished project is an action-puzzle game, which includes both left&right scrolling within 2 pages, and koopa shell breaking bricks and hitting hidden blocks, and tunes which use DPCM samples. Only the levels and the 'Game Clear' BGM are unfinished now. I have another unfinished project, meant to be huge, but currently I have only expanded another 32KB into the ROM, and only <10KB has been used. The WIP of the latter project includes auto scrolling(that's ATA's patch), a 7-level Mario upgrade(6 complete), and various other patches. The expanded part only includes Mario's 'Let's go!' voice at the world intro screen, and a VRC7 music processing system(incomplete, and cannot run for the time being). All BGM are composed, though.

What I'm going to talk about here is the latter unfinished project. Personally speaking, no better project than Extra Mario Bros has been released since 2005. Has anyone had the idea to create a real advanced project? Consider making use of expanded memory($6000-). Consider a cutscene system based on the original system. Consider cancelling the gravity routine for hammers, and design 'spell cards' using hammers. Consider a VRC7 music processing system(and simply change the value in $FB to choose which BGM to play, if required by the cutscene system).

I'm not trying to find someone and then leave the project to him, seriously. I'm just providing an idea, and also looking for ideas and information. If anyone wants to join, I'm honoured. I have been working on this, but progress has been slow and continually delayed since I'm a sophomore.

PS: Are there simple ways to contact other members?

I'm found numerous tutorials on how to convert x.wav files to x.dmc files. However, I haven't found any tutorial that tells me how to finally put this sound into the NES.
Can anyone tell me what part of data means what in a x.dmc file? How should I give values to the CPU Addr $4010, $4011, $4012, $4013, so that this sound can be heard?

ROM Hacking Discussion / Anyone got, or can help rip Mario's voice?
« on: December 25, 2011, 09:25:08 pm »
Anyone got Mario's 'Let's go!' and 'Oh, Mamamia!' sound (e.g. in Super Mario Advance 2)? Or can anyone help me rip them, I don't know how to rip these.
If you've got Luigi's sound, it'll be better.
File type better be 'x.wav'.

If you can help, submit the files to Thanks a lot!

Programming / OK, starting 6502 work but really puzzled... need help.
« on: October 12, 2011, 10:58:08 am »
Well, trying to work on Super Mario Bros. 1... Got 3 questions:
1. The 6502 asm is, of course, very different from languages such as C, Pascal, etc. Though I can understand the meanings of commands, I hardly know what the values in WRAM and others mean. What should I do if I want to know what a specific value mean? I'm completely all thumbs...
2. Well I just figured out that a nonsense series of 'commands' are usually data instead of commands. Of course I need some more experience, so anyone can share some?
3. I'm using a debugger called NO$NES, but I don't know if it's the best. My computer is a million years old, so it cannot survive the attack from FCEUX. Any good debuggers u know?

Thank you Mario, but our #1(How do you call it?) is in another country... So are there English mistakes in the words above? If yes, also tell me.

Script Help and Language Discussion / Japanese translation problem.
« on: August 29, 2011, 01:33:24 am »
2 sentences needed to be translated:
'Go into [the world which has appeared before]!'
'Let's [hoot]!'
The words in [] are actually names of 2 songs. I know that the Japanese name for the first song is 'また巡り逢えた世界', but I can't find the Japanese name for the second.

I need translations which can represent the meanings, and also indicate these songs. Can anyone help? Thanks.
(Is there a Japanese 'sone'...?)

Well, I have a complete and quite good(at least I think) hack here, and I want to upload the hack into's hack database.
However, 'thanks' to the GREAT FIREWALL (All Hail Communist Party of China!!), I can not visit website like youtube, facebook etc. in the regular way. Once I used a software called freegate, and I found that I could go to these websites, but I couldn't visit Chinese websites. So I really doubt if Chinese URLs work here.

I think most other people will tell me the answer to that question. Just check the link here(This is not the hack I mentioned), and tell me whether it works. Thanks. And I'm sorry if this question is really silly.

[ROM link removed]

ROM Hacking Discussion / Some help needed on a new hack rom.
« on: August 09, 2011, 06:14:02 am »
(My English is bad, forgive me...)
2 days ago, my project [YoonA 1.00] is complete. It's a SMB1 hack, which changes the map and the BGM completely. I also did some changes in GFX(Oops, is there a plural form...?) and 'GFX links'(well, direct transl from Chinese...). I'm planning to work on a new project [YoonA 2], and now I need some help, about both YoonA 1&2.

Q1. Although the players in YoonA 1 are Sunny and Yuri, the GFX is merely Peach(without a crown) from SMB2(USA). Why didn't I design the GFX myself? The reason is, I always make terrible GFX drawings. Anyone have some advice on that? Maybe in YoonA 1.01, I will use GFX that seem(s?) real.
Q2. Is it legal to change the BGM in SMB1 to various Girls' Generation songs?
Q3. In YoonA 2, I want to use some real NES 6502 programming instead of searching for hex values, guessing their meanings, and change them. Is there a good tutorial about 6502? Are there NES debuggers?

Thanks a lot, I think there must be a lot of ROM hackers here who make perfect hacks.

Pages: [1]