IBM PC-DOS 2.10 explorations

Will Senn will.senn at gmail.com
Sun Oct 4 09:44:07 CDT 2020


On 10/3/20 11:44 AM, Chuck Guzis via cctalk wrote:
> On 10/3/20 8:38 AM, Will Senn via cctalk wrote:
>
>> Some questions I have related to the exploration:
>>
>> 1. I'm curious if there are other folks out there doing similar stuff?
>> 2. Most of the Assembly examples use DOS interrupt 21 for output. Is
>> this typical of assembly programs of the time, or did folks use other
>> methods?
>> 3. I was able to find a lot of 5150/5160 and other manuals, but I
>> couldn't find an IBM Macro Assembler 2.0 manual (there are plenty of IBM
>> Macro Assembler/2 manuals, but those are for OS/2, not DOS). Does anyone
>> know where I can find one online?
>> 4. In y'all's view, what are the significant differences between IBM
>> PC-DOS 2.10 and it's brother MS-DOS 2.x?
>> 5. I'm thinking of moving on to 3.3 at some point, in your view, what
>> are the advantages?
>> 6. I'm happy to post here, but if y'all know of a more appropriate
>> venue, please suggest it?
> 1 and 6:The folks at vcfed.org are far more involved into things PC; I
> would recommend that venue.
>
> 2.  Interrupt 21 is the most hardware-independent way to perform console
> output.  It is neither the fastest nor most flexible.   Most MSDOS
> programs needing fast or full-screen control revert to writing into
> display memory directly, which is a bit more involved, but worth the
> effort.  There are also INT 10h calls, but again, for text output, they
> can be very slow.
>
> 3.  Can't address that one--I have 1.0 and 4.0 and later in my library;
> I'm not sure if I have the "gap" ones.  MASM 1.0 was a huge mess; the
> product really didn't start to mature until 4.0.
>
> 4.  MS-DOS 2.x had numerous variations, such as that employed for the
> NEC PC98 series of machines, as well as numerous other non-IBM PC
> platforms.  As far as I know, PC-DOS was configured only to be
> compatible with IBM's own product line.
>
> 5. 3.3 was very popular in the day; one thing that it provided was a way
> to avoid some of the storage limitations of earlier versions.  It also
> introduced quite a number of API additions (see Ralf Brown's interrupt
> list for details).
>
> --Chuck

Thanks Chuck, I didn't know about vcfed. I'll head over there. Your 
points about display memory is helpful, as is the rest of your post. I 
appreciate it.

will


More information about the cctech mailing list