ASM6 101 ?

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
seandon4
Posts: 4
Joined: Thu Nov 24, 2016 12:02 pm

ASM6 101 ?

Post by seandon4 »

Hi All:

I am new to NES development, and I'm also new to 6502 assembly. I've been checking out the samples here http://nespowerpak.com/nesasm/ (NESASM) and here http://hackipedia.org/Platform/Nintendo ... ES101.html (P65).

But ASM6 seems more popular (or at least historically it has been). There has been mention of a tutorial here http://home.comcast.net/~olimar/NES/NES101_asm6.zip on various threads, but that link no longer works.

Is the NES 101 ASM6 file still available anywhere?

On the other hand, if ASM6 has fallen out of favor/support, then which assembler should I focus my time on learning instead?

Thank you in advance
Regards
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: ASM6 101 ?

Post by koitsu »

Take your pick: https://wiki.nesdev.com/w/index.php/Tools#Assemblers

The generally used assemblers by folks here on this forum are (in no particular order) asm6, cc65/ca65, and nesasm.

I dug around for a copy of NES101_asm6.zip. Sadly I cannot find it anywhere on the Internet (there are only 3 or 4 mentions of it total, most being here on the forum). If someone on EFnet IRC #nesdev can ask loopy sometime for it, or for a link to it, that would be great.

You should be able to learn 6502 using any assembler. The complications arise from syntactical differences (ex. getting low vs. high byte of a location/label/address), macro names/syntax, built-in functions names/behaviours, etc.. When asking for help, be sure to specify what assembler you're using and what version of the assembler (nesasm 2.x can different from nesasm 3.x, for example).

You can try following the Nerdy Nights tutorial (uses nesasm, but again, if you're learning the CPU architecture it only matters slightly): http://nintendoage.com/pub/faq/NA/index ... s_out.html

Do you have any programming experience (in any PL), or any development experience (for any system/architecture)? If neither, you may find the NES extremely tedious/annoying as a starting point (the PPU is a particularly complex beast -- good example of what I mean). IMO, the Apple IIE (though 65C02 (has more opcodes)) is a better starting platform, especially because you can start with Applesoft BASIC as a "gateway" into programming and then learn the 65xx architecture by using the built-in-to-ROM mini-assembler.

If all you want to do is "make cute/near games with pixel graphics", I would suggest the PICO-8 instead. Consoles (which are in essence "embedded devices") generally do not provide a "user-friendly" interface or way of learning when compared to, say, that of a home computer.. I happen to consider the NES one of the more complicated consoles.
Last edited by koitsu on Fri Nov 25, 2016 1:32 am, edited 1 time in total.
User avatar
freem
Posts: 176
Joined: Mon Oct 01, 2012 3:47 pm
Location: freemland (NTSC-U)
Contact:

Re: ASM6 101 ?

Post by freem »

At some point, loopy's NES stuff was moved to http://3dscapture.com/NES/

While this file isn't listed on the main page, it still appears to exist.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: ASM6 101 ?

Post by FrankenGraphics »

I'm still in the process of learning-by-doing. This is my experience:

I think asm6 is good for beginners because you
-don't have to fiddle with nesasm's .bank format or different syntaxes between v2 and 3.
-easy/quick to use. just drop the .c and .exe in your project folder and drag your source to the .exe. it will assemble!
-kind of the same point as above: doesn't require you knowing how to set up a specific environment (such as the case of ca65).
-syntax accepts a variety of styles for writing directives, macros, etc.
-the readme is down to earth and worth consulting
-there's a fully compatible disassembler; which is a great learning tool further down the road.

Depending on your learning style, it may also be good or bad because
-It forces you to rewrite the examples in nesasm based tutorials like nerdy nights, at least a little. It's unconvenient at first but i think it's a good first excersise.

If you prefer adding C (or even BASIC, i guess) to your code, then there's alternatives.
seandon4
Posts: 4
Joined: Thu Nov 24, 2016 12:02 pm

Re: ASM6 101 ?

Post by seandon4 »

Thank you all for the prompt and good replies.

Yes I forgot to mention that I'm an experienced programmer, including C and various higher level languages as well, but I never really learned any assemblers.

I was also looking into Apple II, C64, Atari (also Gameboy and ColecoVision, which I think is Z80 not 6502); but the NES seemed to have the bigger development community with more working sample code and tutorials around from what I could find and an active forum. I was finding the C64 tutorials to be outdated and non functional and the Atari samples (not many of them) to be somewhat cryptic, but alas I'm still new.

I was enjoying the easy6502 (6502asm) online assembler (https://skilldrick.github.io/easy6502/) and wanted to see if I can get some of that to work on an actual platform with reasonably well documented and hopefully intelligible/organized code.

I have not heard of the PICO 8 though; I will check that out also.

The ASM 6 101 link @ 3dscapture works. Thanks!
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: ASM6 101 ?

Post by FrankenGraphics »

I was also looking into Apple II, C64, Atari (also Gameboy and ColecoVision, which I think is Z80 not 6502); but the NES seemed to have the bigger development community with more working sample code and tutorials around from what I could find and an active forum. I was finding the C64 tutorials to be outdated and non functional and the Atari samples (not many of them) to be somewhat cryptic, but alas I'm still new.
Some parts may not be relevant to this day, but there's a vast library of books on ML programming for the Commodore family of computers. Some specific, some general, some really good (i would recommend a glance or two over selected chapters in Machine Language for Beginners by Richard Mansfield and Machine Language for Commodore 64 and other Commodore computers by Jim Butterfield).
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: ASM6 101 ?

Post by koitsu »

seandon4 wrote:I was enjoying the easy6502 (6502asm) online assembler (https://skilldrick.github.io/easy6502/) and wanted to see if I can get some of that to work on an actual platform with reasonably well documented and hopefully intelligible/organized code.
This is actually a great tool for "simple 6502 learning" or "simple 6502 testing" (purely about the CPU architecture), with an "easy way to draw pixels": RAM locations $0200 to $05FF in easy6502 are mapped to pixels in its little display. The NES is not that easy, and doesn't work in pixels. That said, I myself even use easy6502 to test some general behaviours or ideas in 6502. It's cool/convenient for simple things, but annoying for complex things (the web is not well-suited for the latter).

I should note (this is a matter of opinion and SHOULD NOT dampen your efforts or dishearten you!) that just because, quote, "the NES seemed to have the bigger development community with more working sample code and tutorials around" does not mean it's a better starting platform for learning assembly. Just because there's tons of code floating around doesn't mean looking at it is going to teach you the system, nor the CPU architecture. The reason I advocate the Apple II series is because it has an "interface" that can get you information about what the system is doing, right out of the box, and Applesoft BASIC acts as a good stepping stone (you can write assembly routines that you can run directly from BASIC -- this is originally how I learned 6502/65c02)).

There's no way to do this on the NES because there's no "interface" -- this is where the system even deviates from commonplace embedded devices today (ex. Arduino, Raspberry Pi, and even some PIC chips with debugger setups). The closest there is would be, say, the debugger in FCEUX, but if you're using that you already have to understand the architecture a bit -- not to mention you already have to know how to get a .nes file assembled + working properly. You aren't going to see error messages or easy-to-understand signs that something went amiss; for example, since you know C, you aren't going to experience, say, a null pointer exception or a segfault due to out-of-bounds access.

On the other hand, the 65xx series is actually one of the "simplest" CPU architectures there is (I still maintain it's one of the most logical/easiest to understand, and it's fun), and makes for a good low-level learning starting point. I just don't know if the NES is the right platform for starting.

With regards to getting a .nes file up and going, in my opinion, asm6 is the quickest/easiest assembler to accomplish this. cc65/ca65 will require you understand its linker configuration template (Tepples has pre-made some and they're great, but if you look at them you're going to go "huh?"), but is an assembler/suite better intended (IMO) for complex/larger projects. asm6 and nesasm, I think, make for better starting tools.

Start by understanding some CPU instructions, and understanding its vectors (specifically RESET, but understanding the premise behind the NMI and IRQ vectors is helpful too). See if you can get a .nes file assembled and running in FCEUX (you can use the debugger there to see if the first instruction of you code gets run or not upon power-on). Nerdy Nights goes through most of this -- though it uses nesasm, it doesn't really matter, because the information you're learning is universal regardless of assembler.

A footnote reminder, once again: all of this is a matter of opinion and SHOULD NOT dampen your efforts or dishearten you!
seandon4
Posts: 4
Joined: Thu Nov 24, 2016 12:02 pm

Re: ASM6 101 ?

Post by seandon4 »

The reason I advocate the Apple II series is because it has an "interface" that can get you information about what the system is doing, right out of the box, and Applesoft BASIC acts as a good stepping stone (you can write assembly routines that you can run directly from BASIC -- this is originally how I learned 6502/65c02)).
From those who replied, all good advice. Thank you. I'm totally open to starting with Apple II or C64 if it is easier. I did not know I could do assembler in Apple II BASIC, so I'll give that a try as well. I would in fact prefer to start with a platform where I could plot pixels (maybe even print out text) if possible.

I understand there's also the Z80, 68000, and the MIPS assemblers out there as well, but those seem to get progressively more sophisticated with longer instructions sets, etc.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: ASM6 101 ?

Post by koitsu »

seandon4 wrote:I did not know I could do assembler in Apple II BASIC, so I'll give that a try as well.
Okay, it seems I've opened a can of worms. I'll try to just cover as much as I can in a couple hours of writing. (And before you do/try any of this, I suggest maybe jumping to the end of my post, as I kind of backtrack on my own recommendation and say maybe doing NES stuff with present-day emulators and tools is easier)

On the Apple II there are 2 main BASICs available: the built-in ROM BASIC that comes with the system is called Integer BASIC (written by Steve Wozniak), and another is called Applesoft BASIC (done by a couple people who were at Microsoft). Refer to Wikipedia as well on both BASICs for a history of what's what. The BASIC you choose matters: they have more differences than similarities. Here's a primer on Applesoft BASIC.

This is further made complicated by the fact that there are two different DOSes (disk operating systems -- do not confuse this with "DOS for the PC"!): DOS (a.k.a. Apple DOS) and ProDOS. For Apple DOS, DOS 3.3 was the most common. Each of these *also* has a set of commands that can be used -- and there are a few of them that are important for writing assembly on the Apple II. But back to BASIC:

If you review both of the above list of commands for each respective BASIC, you should note that there isn't some "magic way" to write assembly: because BASIC isn't assembly. Instead, the Apple II's ROM provides a built-in debugger (called the "System Monitor" or often just "Monitor" -- yes really. Do not confuse this with, say, a CRT or LCD display!) and mini-assembler.

The common way to get in/out of the System Monitor through either BASIC is to do CALL -151 (CALL is what you also use to run machine language/binary code in memory -- i.e. your assembled programs can be run through BASIC via CALL). The address -151 is actually just a signed 16-bit value of the value/address $FF69 or 65385 decimal; you could do CALL 65385 and accomplish the same, but -151 is easier to remember/shorter.

The Monitor is a bit complicated and cryptic (here's another reference), but you need to remember what time/year/era this was made. The Monitor has a * for a prompt. Depending on what Apple II system you're on (I forget which one introduced what, but I'm referring to II vs. II+ vs. IIC vs. IIE vs. IIGS), you can use the ! command to enter the mini-assembler, otherwise FF90G (the G means Go (i.e. execute)). When writing assembly code on the Apple II in the mini-assembler, you go back and forth between the mini-assembler and the Monitor regularly. The Monitor can give you a disassembly of something in memory (1000L would start disassembling what's at address $1000 onward (the L means List)), or display CPU registers (Ctrl-E). I think there's a Youtube video of someone showing off the Monitor at some point, and I've done one myself to test certain BRK opcode behaviour for nesdev (what you see in my YT video is on an Apple IIGS, so the way I got to the Monitor is different -- I could've done it the above way though, as the IIGS is backwards-compatible with the older II series. Also, my YT video does have some IIGS/65816 CPU-isms in it, so it won't be what you'd exactly see on an Apple II).

Once you're in the mini-assembler, you'll have a ! prompt. From here, you can actually write assembly code. The way you use this is a little different than, say, writing code in a text editor, but the overall premise is the same. You can write code by doing something like: 1000: LDA #$A1. This would put the assembled instruction lda #$a9 into memory locations $1000 and $1001 ($1000 would be $A9 (opcode), and $1001 would be $A1 (operand value)). You could continue with the next instruction by entering <space>STA $C000 -- the preceding space means "continue from where I last left off assembling", otherwise you have to specify the address every time (yes, you had to keep track of this in your head or on paper!), e.g. 1002: STA $C000. All the addresses shown in the mini-assembler are in hexadecimal; so things like STA $C000 will end up being shown as STA C000. You get the premise, I hope. To get out of the mini-assembler and back into the Monitor, you simply hit Enter at the ! prompt.

To get out of the Monitor and back into BASIC/DOS/ProDOS, you would do 3D0G. Some of the links I provided go into what this does; there are, for lack of better wording, "magic memory locations" on the Apple II that do things for you. The Apple II ROM is remarkably versatile and gives you a lot of control and ability while offering built-in routines you can use from assembly programs or from BASIC that do stuff. Oh, in BASIC PEEK means "get something from raw memory[/tt] and POKE means "write something to raw memory[/tt].Here's a list -- it's badly formatted and very confusing, I know, and I KNOW there is a better-organised list but it's 0450 in the morning and I'm getting tired writing this -- ah wait, here it is (the ones that are described as "useful CALLs" are most helpful). You'll see me use some "special" ones to output things like hexadecimal values (in ASCII) in my YT video.

The next complication comes from what DOS (disk operating system -- yes, like "old MS-DOS for the PC" except for the Apple II) you use. The two common ones on the Apple II are DOS 3.3 and ProDOS. Refer to Section 3 in this FAQ for a command listing (there are other resources online that are more verbose). I myself have limited experience with DOS 3.3 (I did most of my programming on the non-IIGS Apple II series using ProDOS), but you'll see that those DOSes offer commands like BLOAD, BSAVE, BRUN to "run binary files": now we're getting somewhere. ProDOS also has a "BASIC extender" (BASIC.SYSTEM) that provides even more commands, but let's not get lost.

So, putting it all together (using the methodology I myself would): you'd boot a disk with ProDOS + BASIC.SYSTEM on it, and be dropped into Applesoft BASIC. You'd then go into the Monitor, into the mini-assembler, and begin writing some code at a memory location that is available for use. Here's a memory map -- there are safe regions that don't conflict with I/O ports, graphics, the BASIC interpreters, ProDOS, ROM stuff, or the Monitor. When you finish -- and hopefully you've kept track of the SIZE of your assembly program (in bytes!), you go back to the BASIC interpreter and do BSAVE FILENAME,A$xxxx,L$yyyy where xxxx is the hexadecimal address of where your program starts, and yyyy is the length (in hexadecimal) of your program. You could also use something like BSAVE FILENAME,A$xxxx,Lyyyy (yyyy in that case would be decimal, not hex -- note the lack of $ prefix), I believe. The next time you wanted to load this program into memory, you would do BLOAD FILENAME,A$xxxx (to load it off disk, starting at address xxxx in hexadecimal). This is explained here (again badly formatted).

Note: do not confuse LOAD vs. BLOAD, or SAVE vs. BSAVE. LOAD/SAVE are for BASIC programs, while BLOAD/BSAVE "save raw memory to a file". The "B" stands for Binary.

I wonder if anyone's written all that up in decades. Hmm. It's a dying art of sorts, I think. As I went over it all in my head and described the process to you, I started laughing -- I realise the above is paraphrased and trying to encompass a few years of my youth into a single forum post, talking about a system and environment that nobody uses any more. This made me laugh because I thought "sheesh... you know, maybe just using a 6502 cross assembler like asm6/nesasm on a PC in Windows, and then loading a .nes file in FCEUX, and learning how to use the debugger, is easier. Or hell, maybe it's just as cryptic/annoying as the Apple II was." Yeah, I'm starting to think that might be easier -- it just happens to be nothing like, say, writing a C program + compiling/linking it + getting your executable + running it and getting output on-screen using printf("Hello world\n");.

Yeah, I'd say start with the Nerdy Nights tutorial... :-)

The equivalent of a "HELLO WORLD" in 6502 on the Apple II, using a built-in ROM routine for printing text, and intended for the mini-assembler, would be this (including the prompts to help indicate what's going on/where you are, and I hard-coded/calculated the addresses to make it easier to understand):

Code: Select all

*!

!1000: LDX #0
!1002: LDA $1020,X
!1005: BEQ $1010
!1007: EOR #$80
!1009: JSR $FDED
!100C: INX
!100D: JMP $1002
!1010: RTS
!

*1020:48 45 4C 4C 4F 20 57 4F 52 4C 44 0D 00

*1000G
HELLO WORLD

*
- The "magic EOR #$80 is because of the Apple II text memory format: for non-inverted, non-flashing text, the uppercase ASCII table starts at $C0, not $40 like on PCs. Thus, the MSB effectively defines whether or not the character is "normal" or not; the EOR #$80 quickly sets bit 7
- The raw value $0D is a carriage return (Apples and Macs use CR for line endings, unlike BSD/Linux which uses LF or PCs that use CR+LF)
- The raw value $00 I use as an end-of-string marker (i.e. C-style strings; I never liked Pascal-style strings, despite coding in Pascal).
- The final RTS is how I get back to the Monitor **specifically in this context**. It's the Return To Subroutine opcode (normally used to get out of a JSR), but because the last value on the stack when program runs is the return address of the Monitor entry vector, RTS gets me back. If I had run this code from BASIC via CALL 4096 (rather than from the Monitor itself), it would have returned me to the BASIC interpreter.

And yes, I did test it (see screenshot) on a IIGS, but you get the premise. :-) PRINT "HELLO WORLD" in Applesoft BASIC would have done the same thing.
Attachments
screenshot.png
seandon4
Posts: 4
Joined: Thu Nov 24, 2016 12:02 pm

Re: ASM6 101 ?

Post by seandon4 »

Awesome post @koitsu. Thanks. I downloaded AppleWin (I happen to be on windows at the moment) and was able to kick off CALL -151.

I wonder if the C64 had something similar (a mini assembler.) I see people use TASM for C64 but I haven't had luck getting a TASM disk to work on VICE.

Anyway, in terms of NES, perhaps I can bring some knowledge of Apple II/6502 back to the NES platform in the distant future as well.

Thanks again.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: ASM6 101 ?

Post by Dwedit »

NES isn't that bad, it's just that there are certain things your program has to do, then everything gets written in 6502 ASM.

The rough outline of what a NES game has to do:
* Load an initial image into the nametables and attribute tables
* Update rows and columns of the nametables and attribute tables as you scroll (compare an old camera position to a new camera position)
* Run game logic on your game objects
* Render your game objects into entries in the OAM (sprite table).

Then your Vblank code:
* Blast out the sprite table with DMA
* Blast out the nametable changes
* Set the scroll registers
* If you have nothing better to do (no raster effects or anything), call the update music code here.

The "what" you do is pretty much the same. The "how" you do it varies from game to game, and that's the code that you have to write.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
tomaitheous
Posts: 592
Joined: Thu Aug 28, 2008 1:17 am
Contact:

Re: ASM6 101 ?

Post by tomaitheous »

I think going with another 6502 platform just to learn about the 6502.. is really a waste of time. The Basics of the 6502 are the least of your problems. Learning any processor itself is fairly easier; it's the surrounding hardware that really complicates things. And the NES isn't exactly a "clean" design. When it comes to video, audio, and mappers (like bus conflict, etc) - there are a lot of little things you need to keep track of.

I say learn 6502 on the target platform you are planning to write software for. You'll learn both the processor and the hardware at the same time. As for the assembler - pick whatever has the most examples/tutorials. Maybe save ca65 for last because of its complexity, but once you feel comfortable enough, you can move on to it later. So don't worry about if nesasm or whatever assembler doesn't do this or that. Just start somewhere. This is how we all learned. Post questions in the newbie section when you get stuck, etc. Don't sweat the details before you've even started. Just remember not to get too attached to one assembler - is all.

If you really want to ease into 6502 side first.. then try out easy 6502: http://skilldrick.github.io/easy6502/ It's a web interface emulator for learning 6502 - non hardware specific.
__________________________
http://pcedev.wordpress.com
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: ASM6 101 ?

Post by tokumaru »

tomaitheous wrote:I think going with another 6502 platform just to learn about the 6502.. is really a waste of time.
I'm of the same opinion. If it's not a machine you have any sort of connection with, that you have no intentions of working with in the long run, no matter how straightforward it is to code for, you'll be wasting time with things that don't directly contribute to your long term goals.
The Basics of the 6502 are the least of your problems. Learning any processor itself is fairly easier; it's the surrounding hardware that really complicates things.
And even that is still a very small portion of what makes a game. You usually get most of the hardware stuff out of the way pretty early in development, if you build a proper framework for your projects. I believe that about 90% of the development of a game is spent on logic and content. Hardware interactions should be abstracted away by the game's engine.
I say learn 6502 on the target platform you are planning to write software for. You'll learn both the processor and the hardware at the same time.
While I think this is better than targeting some random unrelated platform, absolute newbies may get confused when learning these 2 things at the same time. I know I did when I first tried (and failed) to learn 6502. I had no idea what was part of the CPU's language and what was specific to the NES' architecture.

For me, what worked was to study the CPU isolated from everything else. I used Michal Kowalski's 6502 simulator to test every single instruction to make sure I understood the basic documentation. Then I started combining instructions to make small functions for various purposes, such as clearing memory, copying data, multiplying values, and so on. I never used any of the I/O stuff, I only watched the memory and the CPU status to verify that everything was going as planned. Once I had a decent grasp of the CPU I decided to target the NES. My first programs might not have been the most efficient or well coded, but I was familiar enough with the CPU to be able to "talk" to the NES without making huge mistakes.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: ASM6 101 ?

Post by Pokun »

I'm not an experienced programmer. I'm a layman with some experience in C/C++ and BASIC that I learned mostly by myself and the basics in high school. I started 6502 with the NES and the Nerdy Nights tutorial. While it took a good while before I had grasped enough of both 6502 and the NES hardware to be able to go on on my own, it ceirtainly turned out to work out well in the end. Maybe practicing the basics of 6502 on an Apple II is good practice to make you a better programmer though. No matter what path you take, it's gonna take some time before you will be able to start make something more interesting, so just be brave.

Asm6 isn't outdated or anything, it's still the preferable assembler of many people here (as well as ca65). Loopy is still active although I don't think he had much reasons to make any upates to asm6 as it works well with current systems. I hope for 65816 and 65C02 support someday though.
Although Nerdy Nights uses Nesasm, it shouldn't be hard to move over to asm6 if you start with Nesasm. All the Nerdy Nights tutorial weeks have been converted to asm6 syntax and can be downloaded from somewhere here on the forum.
the NES seemed to have the bigger development community with more working sample code and tutorials around from what I could find and an active forum. I was finding the C64 tutorials to be outdated and non functional and the Atari samples (not many of them) to be somewhat cryptic, but alas I'm still new.
Yes, Nerdy Nights tutorial, this forum and its wiki are all a big part of my success in learning to program for the NES so easily. No other old retro console has a homebrew scene that comes even close to what the NES has (except for maybe the Mega Drive homebrew scene). We are quite spoiled with this big wealth of knowledge that gets updated everyday.
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: ASM6 101 ?

Post by Drag »

I'm chiming in for dasm, which is what I've used for everything nes development related. (Pointing it out here because it was mistakenly put under the disassemblers section likely since its name is "dasm", but it is indeed an assembler)
Post Reply