Re: [Freedos-user] DOS Fonts
Hi, On Wed, Jun 15, 2022 at 12:32 PM Daniel wrote: > > Is anyone familiar with how DOS fonts work? > > There are some .com files that will change the original font with another and > ya can create your own. I created a TI-99/4aA font to use. > > So how does it work? Is the hardware font cached and the cache is changed? > Some programs will revert back to the original font when exiting back to DOS. > > Is there a location where one can read/write the font information? Take a look here (and see Terminus as a good example): * https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/fonts/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS ASM Resources
That's a great suggestion! Way back in the day, before I had internet, my local library was an excellent resource to begin learning. :) Sent with [Proton Mail](https://proton.me/) secure email. --- Original Message --- On Saturday, July 2nd, 2022 at 7:01 PM, Daniel wrote: > If ya have a library, ya can try lookin there. Usin our library here I found > some good books to go through. Advanced MSDOS Programming, From BASIC to > 8086/8088 Assembly Language. There are other books I am waitin on. I also > have other books I collected over the years. I hope this is a good suggestion. > > On Sat, Jul 2, 2022 at 14:02 > wrote: > >> Send Freedos-user mailing list submissions to >> freedos-user@lists.sourceforge.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.sourceforge.net/lists/listinfo/freedos-user >> or, via email, send a message with subject or body 'help' to >> freedos-user-requ...@lists.sourceforge.net >> >> You can reach the person managing the list at >> freedos-user-ow...@lists.sourceforge.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Freedos-user digest..." >> >> Today's Topics: >> >> 1. Re: DOS ASM resources (Ben Collver) >> 2. Re: DOS ASM resources (Travis Siegel) >> 3. Re: DOS ASM resources (Santiago Almenara) >> >> -- >> >> Message: 1 >> Date: Sat, 2 Jul 2022 13:12:03 + >> From: Ben Collver >> To: "freedos-user@lists.sourceforge.net" >> >> Subject: Re: [Freedos-user] DOS ASM resources >> Message-ID: >> >> >> Content-Type: text/plain; charset="iso-8859-1" >> >> I made a mistake pasting a URL into my last post. >> >> OLD: http://ref.x86asm.net/coder32.htmlhttp://www.eji.com/a86/ >> NEW: http://ref.x86asm.net/coder32.html >> >> -- >> >> Message: 2 >> Date: Sat, 2 Jul 2022 13:37:01 -0400 >> From: Travis Siegel >> To: "Discussion and general questions about FreeDOS." >> , Bret Johnson >> Subject: Re: [Freedos-user] DOS ASM resources >> Message-ID: >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> 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 >> >> 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
[Freedos-user] DOS ASM Resources
If ya have a library, ya can try lookin there. Usin our library here I found some good books to go through. Advanced MSDOS Programming, From BASIC to 8086/8088 Assembly Language. There are other books I am waitin on. I also have other books I collected over the years. I hope this is a good suggestion. On Sat, Jul 2, 2022 at 14:02 wrote: > Send Freedos-user mailing list submissions to > freedos-user@lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/freedos-user > or, via email, send a message with subject or body 'help' to > freedos-user-requ...@lists.sourceforge.net > > You can reach the person managing the list at > freedos-user-ow...@lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freedos-user digest..." > > > Today's Topics: > >1. Re: DOS ASM resources (Ben Collver) >2. Re: DOS ASM resources (Travis Siegel) >3. Re: DOS ASM resources (Santiago Almenara) > > > -- > > Message: 1 > Date: Sat, 2 Jul 2022 13:12:03 + > From: Ben Collver > To: "freedos-user@lists.sourceforge.net" > > Subject: Re: [Freedos-user] DOS ASM resources > Message-ID: > < > sn6pr1901mb204624854f6bc374a92bcb...@sn6pr1901mb2046.namprd19.prod.outlook.com > > > > Content-Type: text/plain; charset="iso-8859-1" > > I made a mistake pasting a URL into my last post. > > OLD: http://ref.x86asm.net/coder32.htmlhttp://www.eji.com/a86/ > NEW: http://ref.x86asm.net/coder32.html > > > -- > > Message: 2 > Date: Sat, 2 Jul 2022 13:37:01 -0400 > From: Travis Siegel > To: "Discussion and general questions about FreeDOS." > , Bret Johnson < > bretj...@juno.com> > Subject: Re: [Freedos-user] DOS ASM resources > Message-ID: > Content-Type: text/plain; charset=UTF-8; format=flowed > > 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 > > 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
Re: [Freedos-user] DOS ASM resources
Thank you for the answers. I've been following all the links you've sent I'll also follow the advice and try to understand some project like DOSLFN. (source code is only 220k) Santiago El jue, 30 jun 2022 a la(s) 13:19, C. Masloch (pus...@ulukai.org) escribió: > On at 2022-06-30 10:00 -0500, Santiago Almenara wrote: > > Hello! > > > > What book or webpage do you recommend to learn some DOS assembler? > > > > Thanks in advance > > > > Santiago > > I learned primarily using these methods: > > 1. Read existing code and try to understand it. Even better, start with > higher-level commentary about code if you can find any. Some > applications' manuals are good for this, eg DOSLFN. > > 2. Have an english-language instruction set reference handy. I used the > one included with older NASM versions, which I subsequently forked when > it was dropped from NASM. [1] > > 3. Likewise, refer to the Interrupt List for reference as to what a > particular interrupt service does. Apart from some modern extensions it > is fairly complete. It can be found in plain-text files (split across a > lot of them, you can concatenate them to receive a single file) on Ralf > Brown's pages [2] and can be accessed online, page per page, hosted by > several different websites such as fd.lod.bz [3]. > > 4. Try out things in a debugger if unsure, such as when unclear about > what a particular instruction does, or to trace an existing program and > try to improve your understanding of its workings. My main project is > lDebug (with a small "L"), a debugger with a command line interface > that's based on FreeDOS Debug. [4] > > 5. You can also read some of the books that have been written about DOS. > At home I have the following print books: "FreeDOS Kernel", "DOS > Internals", "Undocumented DOS (Second Edition)" (UDOS), "Dissecting > DOS", "Extending DOS", "Advanced MS-DOS Programming", "Writing MS-DOS > Device Drivers", and a german "DR DOS 6.0" manual. UDOS and the DR DOS > manual are probably the best among these. > > Finally, I wrote a document called Assembly Comments Explained: Guide > for Advanced Learning and Style [5]. It is intended to clarify > conventions in my assembly language sources in particular. > > Regards, > ecm > > > [1]: https://pushbx.org/ecm/doc/insref.htm > [2]: http://www.cs.cmu.edu/~ralf/files.html > [3]: https://fd.lod.bz/rbil/index.html > [4]: https://pushbx.org/ecm/web/#projects-ldebug > [5]: https://pushbx.org/ecm/doc/acegals.htm > > > ___ > 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
Re: [Freedos-user] DOS ASM resources
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 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
Re: [Freedos-user] DOS ASM resources
I made a mistake pasting a URL into my last post. OLD: http://ref.x86asm.net/coder32.htmlhttp://www.eji.com/a86/ NEW: http://ref.x86asm.net/coder32.html ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS ASM resources
...somehow those two URL's got fused together:
http://ref.x86asm.net/coder32.html
http://www.eji.com/a86/
Frank
On 2 Jul 2022 at 15:08, Bryan Kilgallin wrote:
> Ben:
>
> > http://ref.x86asm.net/coder32.htmlhttp://www.eji.com/a86/
>
> {Not Found
>
> The requested URL was not found on this server.}
> --
> members.iinet.net.au/~kilgallin/
>
>
> ___
> 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
[Freedos-user] Software Freedom Conservancy quits GitHub
"In so doing, they claim, the company has convinced FOSS developers to contribute to the development of a proprietary service that exploits FOSS." https://www.theregister.com/2022/06/30/software_freedom_conservancy_quits_github/ -- members.iinet.net.au/~kilgallin/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
