How can one make ASM patch code for systems besides SNES...

...And most specifically systems like NES, GB/C/A and other platforms?

The only four availible seem to be WLA DX (of which I hate), Bass (not availible right now), Xkas and Asar (SNES-specific only)

I would love to see a new ASM patching program for those people working on those gaming platforms, one that is user friendly and most likely has a good ASM syntax.

It is just a excellent example of where I cannot find a good program for patching something human-readable for something not for the SNES.

Wait, what are you trying to patch? Because patching formats themselves are system-agonstic as a general rule.

For the record, you could probably try to grab an assembler and then generate the patch file yourself (by manually entering the bytes used to make the file and then writing the code that has to be assembled). Not ideal, but it's doable at least (and you would only need an assembler and nothing else).

You could try the approach I used for an UNROM hack of Solar Wars. I used ca65 but the concept (.incbin calculating the number of bytes to the next patch point) probably ports to other assemblers.

My process for patching an NES game with the cc65 toolset is something like this:

1. Play the game in FCEUX making a code/data log.
2. Use the log to create a disassembly.
3. Create SEGMENTS in the disassembly around the region of code you want to patch (keeps the code following the patch from moving).
4. Write the patch.

Example code: http://rainwarrior.ca/projects/nes/startropics_music_fix.zip

I am making an example patch for SMB2USA using DataCrystal Wiki's Data and a bit more (although I do not go to RHDN logged on, I still view it logged off)

It requires a way to manage data and code similar to those patching-oriented assemblers.

Will try those CA65 patch methods to see if they work out, The FCEUX way may need to be avoided because SMB2 requires code on RAM at $6000-$7FFF like Zelda, making FCEUX hard to decide where the ASM is!

Between editing the code/data log, breaking things into banks and segments, and annotating things with a disassembly info file, you can deal with situations like that. I try to do as much annotation as I can just via the info file, so that I can always just re-disassemble when I find something new.

PCEAS version 3.22 should handle NES stuffs - I think. I also had a build based on this for NESASM, but I don't think anyone was interested. It specifically dealt with this issue; including a binary file to assemble over, but also be able to have an opcode cross a bank boundary (the original would error out). For games that used 16k code banks and such.

You might want to try ASW (Macro Assembler). I used this for Sega Genesis in attempting to hack the arcade system-16a Shinobi game to run on the Genesis. I think it supports most 65x processors. Not sure about GBz80.

I'd rather go with the NESASM method,

Also, I wish for both your NESASM and PCEAS to include support for strings with table support, and fix data alignment errors, If you can.

Can you explain these features in further details?

Assemblers like CA65, Xkas and Bass have the feature to make ASCII and Code use a Customized Character Encoding using a Table (examples: systems like C64, Atari, along with some other games like Mario uses different character usage, as opposed to ASCII)

Also, The NESASM Data feature (.byte, .word) are limited to say, about 7 or 8 rows (.db $00, $00, $00, $00, $00, $00, $00, $00) worth of data due to a glitch (or a bad feature for when dos was popular, or both) that makes the assembler (your NESASM or PCEAS) throw up an assembler error.

The way that some people got around it was ''Splitting Data from X amount to that of Y'': X could mean a infinite number (more than 7 or 8). Y could mean a number less than 7 or 8,

So a substitution table for ascii text?
Something like .text table, "this is a string",0 ?



I've done larger than 7 or 8. I've done at least lines of 16 elements. I know what you mean though, but I think it's a line length limitation rather than anything related to 'defines'. Either way, I'll put it on the list of thing to update for the next release. I plan to update the macro system again (it has the best custom macro system of any 6502 macro assembler that I've used, but it still needs a few more things).

Yes, That's the one function!

I don't know if it's a bug (still?) in NESASM but in PCEAS, .db blocks would fail to assemble if there were comments after the bytes. Eg:

.db $02,$03 ;This is a comment

fails to assemble. Stupid, eh?

Great find, Chris!

Now we have to wait to see if anything comes of this!

Now that school is out, and I got a month free for winter break, I'll be doing some coding with PCEAS. So, I'll take a look as this for NESASM and PCEAS. I'm gonna add BMP support for PCEAS too. The PNG thing is annoying (BMP is more universal IMO).

No! ILBM!!!

Is there any progress in the new NESASM and PCEAS versions?

Also, I would like much better examples, in the form of PCE Video and Music/Sound code in ASM, to suit source code conversions from NES to PCE (When there is time, that is.)

The sources I'm working on will be a much enhanced version of Super Mario 1 (Maybe even do ''President (open source)'' as an alternative, if Tepples releases it!), as well as 3 when I manage it and have time.

About the graphics formats: YY-CHR should be efficient enough for the job as my alternative to using bitmaps, all I need is the aforementioned ASM code needed and a simple .INCBIN directive!

Also, Happy 2015!