Interestingly enough, I also bought a86/D86, and have found it to be the
best assembler/disassembler I've ever found for dos. I ran across it
after (mostly) trying to use debug for things, so it was a welcome
relief. I still use it when working on dos things, which admittedly
isn't very often these days, but at least it still works, and still does
what's needed.
Of course, take this with a grain of salt, since I'm an intermediate asm
programmer (at best), and it takes me many hours to get anything
complicated untangled when looking at asm code, which is why I don't use
it much, but there's sometimes when nothing else can do the job as well,
so <shrug>
Masm, Tasm, and others all have their own syntax which confuses me more
than helping. I find debug and A86 fairly straightforward, which is why
I still like those methods when working with asm code.
On 7/1/2022 11:58 AM, Bret Johnson wrote:
Santiago:
I agree pretty much with ECM. The best way to learn is to look at the code
someone else has written and try to understand it. Unfortunately, most ASM
coders aren't very good at comments/documentation, and you really need the
comments to help you figure things out. Looking at uncommented code doesn't
seem to help me very much -- I need to try and figure out how the coder was
thinking, not just the result of the thinking.
I put LOTS of comments in my code -- I'm sure at least some people think too many. Almost every line of the source has
a comment, and each "subroutine" has a comment header similar to what ECM has (but my "style" is
different than ECM's). The comment header includes details about what the subroutine does, its inputs and outputs, and
what it may change. The header MAY also include the "context" of when and where the subroutine should get
used, and why the subroutine even exists at all (especially if it is there to address some "special"
situation). For example, most of my programs are TSR's and in the most recent versions I'm working on the programs can
use different kinds of memory: conventional, upper, Expanded (EMS), and/or Extended (XMS, which I access through a DOS
Protected Mode Services or DPMS server). I have comments to try and explain why I do something that requires a special
consideration for one of the different types of memory. An example of this would be that you NEVER want a stack to use
Expanded memory, so sections of the code related to the stack need to take that into account and should make some
comment about it.
When I first started (a LONG time ago), modern assemblers like NASM & FASM didn't exist,
and I didn't like MASM (though it was and still is kind of "the standard" I find it
confusing), so I ended up buying A86/A386 from Eric Isaacson. Unfortunately, Eric hasn't
updated those in a long time and it's not possible to do large projects with them because
they don't take advantage of extended or expanded memory. I've since switched to NASM, but I
think FASM is also pretty good, and they're both free (unlike A86/A386).
I've got a couple of books, but really the only "fixed" resource I use is Ralf
Brown's Interrupt List (RBIL). I've found looking at other people's actual production
code is the best way to learn things.
I also think the best way to get started is to actually write a small but
useful program from scratch -- a program that you will actually use when you
get done. Don't make it try to do too much -- just something relatively
simple. The very first program I wrote was a simple version of JOYKEYS, a
program that allows you to use a Joystick with almost any DOS program. The
first version was pretty basic, and it's changed a lot over the decades
compared to how it started. There are lots of things you need to understand
(memory, I/O, Interrupts, BIOS, DOS, etc.) to even write a simple program. The
ASM part of it, while pretty complicated, is not the hard part. The hard part
is figuring out WHY you do (or don't do) certain things.
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
