====================================================================
                     1.Before the translation
====================================================================
First of all, you need to be sure the disassembly you're going to use is well formated. In other words, is necessary that all the code is perfectly converted, and all the labels are well ubicated, specially the lists of offsets (only the ones who points to code). This, however, isn't necessary for the sections of data (can be present as disassembled code, it doesn't matter) or the list of offsets who points to more data (it's explained below).
It's preferable that the access of the I/O (or, basically, all who aren't ROM and RAM) are replaced by labels (ie. PPU_CTRL replacing all the $2000 accesses), so the translator doesn't take them as a RAM access, plus they will be easier to locate after the translation.
About the translating's options, use the ones you prefer, but I, personally, would check the options 1,6,7,9 and 10, and leave the others unchecked. The usage of macros for the instructions CLC/SEC/PLA/PHA  makes the code looks a bit more clean, and the usage of AND.L/MOVE.L instead of AND.B/MOVE.B it's a safer way to be sure that the content of the registers is always free of garbage on the upper 24 bits. I used the options 2 and 3 during the development of SMB since, at certaint point, I had no idea how manage the Carry Flag (in the M68K, acts a bit different compared with the MOS 6502), but preferably, don't use them. About the option 1, it only changes the instructions used when loads/saves data: for example, the instruction
	LDA $0210
is translated to
	MOVE.B	($FF0210),D0
if unchecked (at $FF0000 starts the RAM in the MD, but you can change it for your purposes) and into:
	MOVE.B	$0210(a5),D0
if checked (and suposing you selected A5 as the Memory Register). The labels are always translated like the first way. For example, the instruction
	STX SPR_DMA
will be translated as
	MOVE.B	D1,(SPR_DMA)
always.

====================================================================
                     2.After the translation
====================================================================
Once you got the code, there is a few things who need to be manually touched:
-----------------------------------
1. The management of the Carry Flag
-----------------------------------
This is probably the worst part to do, and the one which can paralize your project for 2 years :P
Remember that the Carry flag in the NES is only affected by the arithmethic instructions, and NOT by the move instructions, logical instructions, etc. A lot of games takes advantage of this and use the Carry Flag as an indicator of something (the player is dead, there is no collision, etc), so you will need to manually check each location where a BCC/BCS is present, and check if the Carry is set/clear by some operations, or if it's used as I said before. If this is the case, you will need to save the Status register (onto an empty register or to the Stack), and replenish it manually after the Branch instruction.
Additionally, the CMP and SBC instructions set the Carry Flag INVERTED, so the BCC/BCS instructions after them need to be swapped to works properly.
Another thing is the instructions CLC/SEC before the ADC/SBC, which can be erased and the ADDX/SUBX instruction can be replaced by simples ADD/SUB. But be careful of the ones who aren't preceded by those instructions, since that means they are getting the Carry Flag from another side, and you will be back in the first case.
The carry checks before ASL/LSR don't need to be touched.
------------------------------
2. The Indirect Adressing mode
------------------------------
By default, after the translation, the instructions who use indirect adressing will be bad translated, giving a piece of code which doesn't do what should do. This is actually my fault, because there are multiple ways to implement those instructions, but I never choosed one...
The easiest thing to fix is the indirect jump, which is used in the "Magic Jump" subroutines. Usually, there is a list of offsets where the current code can jump, and the specific number of routine in a register (usually, in the Acumulator). In the jump subroutine, the return offset stored on the Stack is poped, stored in a temporary adress, and jumps onto its content. You just need to replace this routine for a new one which do the same. For example, let's say you have this code:

	[...]
	jsr MagicJump	; the number of subroutine is in the Acumulator
	.dw Routine1
	.dw Routine2
	.dw Routine3
	[...]

MagicJump:
	asl
	tay
	pla
	sta $00
	pla
	sta $01
	lda ($00),Y
	sta $02
	iny
	lda ($00),Y
	sta $03
	jmp ($0002)

can be replaced by:

	[...]
	jsr	MagicJump	; the number of subroutine is in D0
	dc.l	Routine1
	dc.l	Routine2
	dc.l	Routine3
	[...]

MagicJump:
	andi.w	#$FF		; this line isn't absolutly necessary
	lsl.w	#2,d0
	move.l	(a7)+,a4
	move.l	(a4,d0.w),a4
	jmp	(a4)

but this isn't the only method. Games like Nuts & Milk have only one list of adresses, so you don't need to get the data from the stack; other games like Excite Bike, has a master list, where is stored the offsets of the sublist, so two consecutive reads need to be done to load the correct offset to jump. It's necesary to trace the instruction JMP ($XXXX) to know what method uses each game, and recreate the jump subroutine.

The other fix is related to the instructions which save/load data from the RAM/ROM (whatever with the form of (NN),Y or (NN,X) ). However, can be easily fixed if you load the original ROM at the end of the RAM. There is a reason for this: the NES memory map is 64KB, the RAM is at the begining($FF0000-$FF07FF), and the ROM is at the end($FF8000-$FFFFFF). At this way, you don't need to know if the code is trying to access to ROM or RAM.
Now, you need to adjust the instructions to correctly load/save this data from/to the memory (this method isn't the fastest one, but gives less headaches). For example:
	STA ($04),Y
can be "emulated" like
	LEA	$04(A5),A4
	JSR	MakeRamOffset
	MOVE.B	D0,(A4,D2.W)
	[...]

MakeRamOffset:
	MOVE.B	0(A4),(READ_ADDRESS+3)
	MOVE.B	1(A4),(READ_ADDRESS+2)
	MOVE.L	(READ_ADDRESS),a4	; the content fo READ_ADDRESS is 0xFF0000
	RTS

By the other side, instructions like
	AND ($04,X)
which are rarely used (I have never seen this instruction be used), can be replaced by
	LEA	$04(A5),A4
	JSR	MakeNewOffset
	MOVE.B	(A4),D7
	AND.B	D7,D0
	[...]

MakeNewOffset:
	MOVE.B	0(A4,D1.W),(READ_ADDRESS+3)
	MOVE.B	1(A4,D1.W),(READ_ADDRESS+2)
	MOVE.L	(READ_ADDRESS),a4
	RTS

----------------------
3. The BIT instruction
----------------------
As far as I have seen, all games that use this instruction, is only to perform an AND between the Acumulator and some value in memory, and change the value of the Zero Flag, but without change the value stored in the Acumulator or in the memory. You just can let the translator do it for you, but just in case, first analize what the game do in that particular case after making a decision.

In other cases, is used to mask instructions when multiple routines use the same code but differ in a constant, like

Label1:
	LDA #00
	.db $2C		; BIT $NNNN opcode
Label2:
	LDA #01
	.db $2C		; BIT $NNNN opcode
Label3:
	LDA #02
	[...]

this can be solved with a lot of jumps

Label1:
	MOVE.B	#00,D0
	BRA	Label3_
Label2:
	MOVE.B	#01,D0
	BRA	Label3_
Label3:
	MOVE.B	#02,D0
Label3_:
	[...]

Sometimes, instead of the 2C opcode, is used 2A. It's the same thing, since both will skip the next instruction (2C uses the next 2 bytes, but 2A only uses the next byte).

====================================================================
                     3.I/O Stuff
====================================================================
----------
1. Joypads
----------
This is probably the easiest part.
First, you need to locate where is located the routine that reads the joypads so you can replace it by your own routine (or the one included). In most games, this routine is THE SAME, or varies only a bit from one game to another. Looks like this

	LDA #$01
	STA JOYPAD_PORT1
	LDX #$00
	LDA #$00
	STA JOYPAD_PORT1
	JSR ReadJoypads
	INX
ReadJoypads:
	LDY #$08
ReadJoypads_Loop:
	PHA
	LDA JOYPAD_PORT,X
	STA $00
	LSR
	ORA $00
	LSR
	PLA
	ROL
	DEY
	BNE ReadJoypads_Loop

followed by the code which store the data in some variables. The most significant part starts after the ReadJoypads label.
--------
2. Video
--------
Here are 4 subsections:

2.1) Graphics (the patterns).
You need to convert them to a proper format, but don't panic, since there is an included subroutine  you can use for this purpose. By default, the background patterns uses the color indexes 0,1,2 & 3, and the sprites patterns uses the indexes 0,8,9 & 10 (usefull info if you want to convert the graphics manually)

2.2) Sprites management.
This is quite easy, since all the games use the DMA to transfer sprites. All of them do this:
	LDA #$00
	STA PPU_SPR_ADDR
	LDA #$02
	STA SPR_DMA
there is a subroutine included which simulate this functionality. You only need to change the address where resides the sprite list ($FF0200 in the example above)

2.3) Scroll.
It's equal in all the games. Usually, you will see
	LDA $12
	STA PPU_SCROLL_REG
	LDA $13
	STA PPU_SCROLL_REG
or similar, where the first access sets the horizontal scrolling and the second access sets the vertical scrolling. A general aproximation of how the NES values should be converted to MD values are:
	for the horizontal scroll: (-NES)+(HP*256) where HP is the number of horizontal page (1 bit in the register $2000)
	for the vertical scroll: since each page is 256*240, is good to simulate the plane B as the first 2 pages, and the plane A as the second ones. In this case, the scrolling is (NES+8)-240 for the plane A and (NES+8) for the plane B (or viceversa if the 2 bit in the register $2000 is set).

2.4) Writes to the PPU.
Depending of the game, some do a lot of continuous writes on the PPU(Nuts & Milk), others have a semi-decent writing routine(Super Mario Bros), etc, but all them use, more or less, the same principle:
	LDA $03
	STA PPU_ADDRESS		; write MSB of the direction
	LDA $02
	STA PPU_ADDRESS		; write LSB of the direction
	LDA $00
	STA PPU_DATA		; write the data
This is the way in which all games write data to the PPU, since always sets the MSB and inmediatly after the LSB. You need to find and replace all the accesses, like this
	MOVE.B	$03(A5),D0
	MOVE.B	D0,(PPU_ADDRESS)
	MOVE.B	$02(A5),D0
	MOVE.B	D0,(PPU_ADDRESS+1)
	MOVE.B	$00(A5),D0
	JSR	Write_PPU
or, in the worst case
	MOVE.B	$03(A5),D0
	JSR	Set_PPU_ADDRESS
	MOVE.B	$02(A5),D0
	JSR	Set_PPU_ADDRESS
	MOVE.B	$00(A5),D0
	JSR	Write_PPU

	[...]
Set_PPU_ADDRESS:
	MOVE.W	(PPU_DIR),D7		; PPU_DIR is a "half-word selector"
	EORI.W	#1,(PPU_DIR)
	LEA	PPU_ADDRESS,A4
	MOVE.B	D0,(A4,D7.W)
	RTS

With this method, the current address of the PPU is automatically set, and you don't need to waste time seeing if the MSB or the LSB is being write.
"Write_PPU" is an included routine, and it's actually called "PPU_CORE".