Where did you learn assembly from?

[LatchGameDev]

Hello everyone

When I heard about Rom Hacking it seemed like learning assembly was the way to go. I'm on chapter 10 so far and was just wondering where did everyone else learn the assembly language?

PSX MIPS Assembly
http://chortle.ccsu.edu/assemblytutorial/

[tvtoon]

Learning assembly as in "starting to write ASM code" then "Art of the Assembly", by Randall Hyde.

[Psyklax]

I'm learning assembly through ROM hacking. A guy on this forum explained a couple of instructions which helped me make a hack several months ago, I read up on the basic idea, then hacked a bunch of games. Learning on the job, that's the way I like it.

I should point out I only know about the 6502 used in the NES amongst others. That tutorial of yours is obviously for something a lot more advanced.

[Disch]

I learned 6502 from the classic "6502.txt" manual, and then writing an emulator based on it.

I would not recommend this approach.

[FAST6191]

+1 for art of assembly. I also like Gavin's guide https://stuff.pypt.lt/ggt80x86a/asm1.htm
That mostly did for the concepts involved, independently of that I also did an awful lot of electronics which did not hurt.
http://www.coranac.com/tonc/text/asm.htm
http://blog.quirk.es/2008/12/things-you-never-wanted-to-know-about.html

and of course http://problemkaputt.de/gbatek.htm

Learn one type of assembly and the second will be far easier, learn two and you can muddle your way through most things. Wind in a bit of CPU design history* as well as the general programming logic/functions (ceiling, floor, the various divides...) and boolean operations and you are laughing.

*mainly just enough to not be too put out when you go for an older thing and find it lacks a divide function, floating point and instead of registers being a type of very fast general purpose memory they are almost separate things unto themselves -- for x86 you have however many dozens of registers and thus considering instructions individually for each register is insane but for the NES 6502 with three ones you will spend almost all your time considering and instructions that play accordingly.

I learned 6502 from the classic "6502.txt" manual, and then writing an emulator based on it.

I would not recommend this approach.

Writing an emulator does tend to get you to be quite good at a given system. To that end while I may or may not suggest the former (never read it but being .txt I can imagine it will be a bit lacking compared to some) the latter is worth considering.

That said I think my suggestion for a less intensive method is tracing in emulators. Start from an action replay type cheat and do something cool with it. You might not get the really exotic instructions being used but you can always look those up once you have the core set down.

[kuja killer]

from a #rom-hacking IRC log by DahrkDaiz i found one day on google search.
Daiz was teaching a couple people like "Solid T-Snake" (some name like that) how to do some simple things with Mario 1 NES. It was a super extremely long conversation, and that's how i learned how to do NES programming. Just because of reading a IRC chat log.

Spoiler

Solid T-Bone
~MoN

[close]

[ineedahorse]

Hello everyone

When I heard about Rom Hacking it seemed like learning assembly was the way to go. I'm on chapter 10 so far and was just wondering where did everyone else learn the assembly language?

PSX MIPS Assembly
http://chortle.ccsu.edu/assemblytutorial/

(To the extent that I know how to code in ASM) I learned a lot from that very tutorial. Really good stuff. I wanted to mod Diddy Kong Racing, but getting beyond the basics (e.g. changing the number of laps) seemed like more effort than I wanted to put into it.

At one point, I also followed along with a series of AtariAge threads about 6502 assembly for the Atari 2600. Also -- on some other site -- there was a NES specific tutorial that I followed long enough to learn how to make a pong game.

For the SNES stuff I'm working on now, I've mostly just perused the opcodes and tried to figure out how the hardware works as best I can. There's a lot of info out there. These links have been helpful:
https://wiki.superfamicom.org/snes/show/65816+Reference
https://emu-docs.org/Super%20NES/General/snesdoc.html
https://en.wikibooks.org/wiki/Super_NES_Programming

Also, I can't recommend bsnes-plus highly enough for SNES romhacking purposes.

[snarfblam]

I learned assembly by diving into the FCEUX debugger and using an opcode reference chart. NesDev hardware reference came in handy, too.

[Drenn]

I learned by writing an emulator.

...In retrospect, not the best introduction, but it sure was comprehensive.

[RedComet]

Rodney Zaks' "Programming the 6502" plus a lot of time combing through the docs at NESDev and tinkering in FCEUXD.

[SleepyFist]

I'm in the process of learning from the Nerdy Nights tutorial from Nintendo Age (got it backed up to my computer), fun to experiment with too, trying to make optimizations and seeing whether they break or not is fun.

[STARWIN]

I never had to learn how to think in asm, as I already knew C.

Then, for 6502 specifics http://www.obelisk.me.uk/6502/ was perfect, as I didn't have to waste time reading small talk.

[flame]

For MIPS (PSP R3000), they said go read the MIPS manual.

It doesn't have all the answers there but it has most of them.
www.cs.cmu.edu/afs/cs/academic/class/15740-f97/public/doc/mips-isa.pdf

And then you can use the PPSSPP disassembler to inspect the code at runtime on the PC version.

[yugisokubodai]

I started reading the 65816 around 2009 on the Google and didn't understand a single word.
I'm not a programmer. But I keep reading every year and now I can do something with the Snes and Nes.
I'm also learning Mips and it gives me great help hack PSP games.

[jonk]

I learned it from CARDIAC, back when I first got the Bell Labs CARDIAC package when I was in high school.

[koitsu]

Sorry for the long-winded reply, but it's hard to give terse answers without some surrounding details:

For 6502/65c02: in junior high, while taking a BASIC programming class (our public schools predominantly used Apple II+/IIE).  We were taught how to use some basic math to draw a circle, and HPLOT to fill it line-by-line.  But the filling felt slow to me -- I could literally watch it draw.  I asked my teacher if there was a faster way.  He handed me a copy of the Merlin manual (an Apple II assembler) and pointed me to his copy of the Apple IIE reference manual.  I ended up using the Monitor, then later the built-in mini-assembler, and finally Merlin, to write myself a 65c02-based HPLOT replacement that was substantially faster.  (This story also explains why I occasionally make mistakes when doing code for the NES; I actually learned 65c02 first, and as such I often forget that the 6502 lacks several opcodes added in the later CMOS version.  "What do you mean invalid addressing mode?! Oh right... 6502...")

For 65816: also during the late stages of junior high.  My first home personal computer was an Apple IIGS, so I got my hands on the multi-volume Apple IIGS Firmware Reference and Programming the 65816 by Ron Lichty and David Eyes from Oregon State University's library.  Since I already knew 65c02, most of this came easily.  I started with the Monitor and mini-assembler, then Merlin 16, then ORCA/M alongside GSBug.  Later in high school (1993), I was one of two members of an Apple IIGS demo/CDA group called Digital Exodus, and we did a Christmas demo highlighting some of the features of the IIGS and documenting our road trip to California for Apple Expo West.  It was also around this time I did my SNES documentation (I was so excited that the SNES used the same CPU as my IIGS).  To this day I maintain that the 65816 is one of the most fun and enjoyable processors to develop on, and especially as a stepping stone into assembly language.

For x86: in high school (1992). The school CS lab was a mix of IBM PS/2, Apple II+/IIE/IIGS, and Macintosh.  Almost all my friends were PC users, and I was really jealous of several PC features that the IIGS couldn't do decently (a highly capable text mode was one of them).  But I was really amazed and influenced by PC demos (groups like Future Crew), so I began learning 286/386 assembly in MS-DOS, using Turbo Assembler.  I was also learning Turbo Pascal at the same time in school.  Eventually I got myself a PC (late 1993/early 1994) and started doing Pascal and x86 exclusively (my TRaCER utility, VeNES emulator, and unreleased qNES emulator are some examples).  I stopped doing x86 several years later (1999?), as the instruction set and all its extensions were just too much for me (I peaked with the 486), and had finally started learning C.  These days I can barely read commonplace x86, since most of it is generated by compilers, and often uses instructions I don't recognise, or uses AT&T syntax (ugh!).

[jonk]

For 6502/65c02: in junior high, while taking a BASIC programming class (our public schools predominantly used Apple II+/IIE).  We were taught how to use some basic math to draw a circle, and HPLOT to fill it line-by-line.  But the filling felt slow to me -- I could literally watch it draw.  I asked my teacher if there was a faster way.  He handed me a copy of the Merlin manual (an Apple II assembler) and pointed me to his copy of the Apple IIE reference manual.  I ended up using the Monitor, then later the built-in mini-assembler, and finally Merlin, to write myself a 65c02-based HPLOT replacement that was substantially faster.  (This story also explains why I occasionally make mistakes when doing code for the NES; I actually learned 65c02 first, and as such I often forget that the 6502 lacks several opcodes added in the later CMOS version.  "What do you mean invalid addressing mode?! Oh right... 6502...")

I had worked on a lot of software before (including the Unix v6 kernel in 1978), but my first nationally sold software package (Winning On Wall Street) was initially written for the Apple II. At the time, the Apple II was slightly more important to business than the IBM PC was because of the early availability of Visicalc. (Keep in mind that this was 1983 and the IBM PC was out for less than 2 years.) I wrote a LOT of 6502 assembly code then.

It is interesting you mention Merlin. My son has been hacking SNES games (65816) and wanted a quick and easy way to take what he was learning using the debugger tools (BSNES+ and others) and write his own substantial extensions that would be able to assemble, link, and then auto-patch the ROM files so he could just run them without having to apply tools or otherwise go through the multi-step processes that BSNES+ or other tools still required. I located the Merlin 32 site, downloaded their assembler and linker tools and started modifying them. Those results can be found at this page, Patching SNES ROMs Directly from Assembly.

I hope to spend a little more time back on NES/SNES tools after I release the current product I'm working on.

[yugisokubodai]

Koitsu, it's nice to hear you say "65816 is one of the most fun and enjoyable processors to develop on, and especially as a stepping stone into assembly language".

I started my first computer course in 1998, that time I was learning MS Dos and Pascal at school. Since then, no progess because I chose a non-computer University. Around 2008, I found RDHN because I was finding a way to translate a Snes game. People here encouraged me to learn the 65816, though I didn't have any programming basic at the time, except some Pascal knowledge.
After spending almost 10 years reading and get helps from many people here, finally I can get what assembly really is.
Since then I'm also learning other asm like Arm and Mips, but to be honest, Snes asm is the most fun part to me. Since people used to code PlayStation games in high language so the asm debugged codes are too tedious to get me keep reading.

Actually, I read Snes debugged codes almost everywhere, everytime I can. Before sleeping, while eating, when waiting someone....

[koitsu]

It is interesting you mention Merlin. My son has been hacking SNES games (65816) and wanted a quick and easy way to take what he was learning using the debugger tools (BSNES+ and others) and write his own substantial extensions that would be able to assemble, link, and then auto-patch the ROM files so he could just run them without having to apply tools or otherwise go through the multi-step processes that BSNES+ or other tools still required. I located the Merlin 32 site, downloaded their assembler and linker tools and started modifying them. Those results can be found at this page, Patching SNES ROMs Directly from Assembly.

Oh my god, this makes me IMMENSELY happy.  I wasn't even aware of this project (Merlin 32)!  Cross-assembling 65816 on present-day systems is painful (matter of opinion, and I don't want to get off-topic, but I really dislike several aspects of ca65 while appreciate others, and WLADX's documentation is bizarre (I've complained on nesdev about this before) and old bugs in it always tainted my opinion), so to see a present-day build of something I'm familiar with from days of old is delightful.  Thank you!

I'll be sure to check out ASMPATCH as well.  Historically I've just split games up into separate PRG banks/sections and disassembled them, then analysed and hand-edited the disassembly to resemble something more manageable, tie it all together using the equivalent of PUT in Merlin syntax (for others: .incsrc, .include, etc.) or binary includes for the rest.  What you've written there would make my life a *lot* easier on romhacking projects.

[jonk]

Oh my god, this makes me IMMENSELY happy.  I wasn't even aware of this project (Merlin 32)!  Cross-assembling 65816 on present-day systems is painful (matter of opinion, and I don't want to get off-topic, but I really dislike several aspects of ca65 while appreciate others, and WLADX's documentation is bizarre (I've complained on nesdev about this before) and old bugs in it always tainted my opinion), so to see a present-day build of something I'm familiar with from days of old is delightful.  Thank you!

With Windows moving into 64-bit, and refusing to support 16-bit operation there, the utility of 16-bit applications has dropped a lot. I keep a 32-bit VM (hypervisor) available for use when I want to fire up 16-bit command line program execution. But it is a pain, regardless.

I was working at Intel (which at the time owned half of Phoenix -- the BIOS folks) when they were assembling the teams to produce 64-bit BIOS support. And I stood there arguing with the managers during a very large meeting when they were moving towards a decision to boot either 64, or 32, but not to support both 64 and 32 bit modes within the BIOS, let alone 16. In fact, the 32-bit team (who held a higher "status") just wanted to isolate their work from anything that the newbie 64-bit team did, forcing the 64-bit team's future to exist in isolation.

To me, the sad thing was that the newer 64-bit cores would support 16-bit, 32-bit, and 64-bit code execution, simultaneously, without any trouble at all. The hardware design is very, very flexible and quite good. (I was working on chipset design and testing there.) But the software folks were making a veritable mess of things by decisions they were taking.

I'm guessing that Microsoft had to pick up the pieces they were dealt and decided that they weren't going to single-handedly "fix" things, anymore. Just live with it. Which means the rest of us are living with it.

I did try and make solid arguments that day there. I was the ONLY one to push hard, though. And I was brushed off, in the end.

I'll be sure to check out ASMPATCH as well.  Historically I've just split games up into separate PRG banks/sections and disassembled them, then analysed and hand-edited the disassembly to resemble something more manageable, tie it all together using the equivalent of PUT in Merlin syntax (for others: .incsrc, .include, etc.) or binary includes for the rest.  What you've written there would make my life a *lot* easier on romhacking projects.

I expect there is a learning curve to it. I just hacked out stuff for my son, giving him what he said he wanted. Then, when he wanted more, I added that as well. Of course, I was using my own approach to designing the solutions.

I also added something he wanted, too. I wrote a bit of a disassembler for it, that works from the command line. My son would "know" a memory address in the ROM for a subroutine that was being called and he wanted a way to just say "disassemble the subroutine which starts here in the ROM." And he wanted me to "auto-figure out" where the subroutine ended, too. (Darn him.) So I wrote code to do a reasonable approximation of that. It helps him make quick work of re-writing subroutines, because he can get the assembly code source auto-generated for him, use CMD/DOS to output that into a file, use an editor on it and change the code to his liking afterwards. Saves typing time. Then he can re-assign the new subroutine to an open block of memory and patch the calls to repoint there, often leaving a small hole for other code. That hole can be added to the list of holes in my ROM description, which can then later be used for relocation of other, smaller bits, if desired.

It's actually got quite sophisticated. But I may yet spend more time on it to add more features. If you know of anything you'd like changed, or added, or would otherwise make it easier and handier, let me know.