Newsgroups: comp.sys.amiga.advocacy
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!kessner!david
From: david@kessner.denver.co.us (David Kessner)
Subject: Re: 8-bit death
Message-ID: <1991May9.045705.797@kessner.denver.co.us>
Organization: Kessner, Inc.
References: <2945.tnews@templar.actrix.gen.nz> <1991May7.090333.1449@kessner.denver.co.us> <3335.tnews@templar.actrix.gen.nz>
Date: Thu, 9 May 91 04:57:05 GMT

In article <3335.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:

>> >    When one calls an MS-DOS "interrupt" (haw, reminds me of the C= 64),
>> >    That's a fundamental part of the OS that is only 8 bits.
>> The 68000, 68030 (not sure of the 040), 386, etc all offer 256 different 
>> intterupts (READ: 8 bits).  The C-64 (and the 6502/6510) had _THREE_, and
>
>    So? I meant the way you call the OS. In the C= 64 it involved either
>    ROM jumping or using fixed tables of vectors into the ROMs. In the
>    PClone, it appears to involve using fixed tables of vectors into the
>    ROMs.
>
>    I could be wrong here. Is there some other decent way to call an
>    MS-DOS function besides using that vector table? All I ever see is
>    the int86() etc functions in Microsoft C.

Hmmm.  The vector table that you refer to is not 'fixed'.  It is a relatively
simple matter to make a 'third-party' replacement for these functions-- 
Unlike the C-64, where you had to copy the ROM at F000-FFFF into RAM, wedge in
the new routine, switch out the RAM, then hope to God that no-one is going
to use that area of RAM.

Anyway, your right.  That intterupt table is used to call OS functions.
Actually, those 256 intterupts are usually thought of as hardware 
intterupts, but it is a relatively simple matter to cause a SOFTWARE
intterupt-- and that is just what we do.

In reality, I don't think that this is any better or worse than using a
traditional jump table.  It is, however, better than the Atari ST's 
version where it makes OS calls by causing a CPU exceptions (like using
a non-existant opcodes).

Normally, the OS calls are done in assembly, where it is very simple to load
the registers and do an 'int ??' instruction.   Emulating this in C is
clumsy at best.  In the past two years I've written about 1500-2000
pages of code on the PC.  In that, I've called OS functions about 50
times-- and used the int86() function about four times.  I've found that
any set of routines that uses a lot of 'int' calls can benifit greatly
from a rewrite in assembly-- and I question any programmer that doesn't
do this.  

>> In short:  So?  This is supposed to be a problem?
>
>    No (not any more than any other MS-DOS feature, anyhow. Sharing
>    interrupts strikes me as being reminiscent of the C= 64 as well,
>    and also seems like a pain in the a). This is supposed to be an
>    example of why MS-DOS is a puny OS, therefore 8-bit (hm, doesn't
>    the '-' in 8-bit mean "or less"? :).

I understand Dave Haynie's explanation for shared intterupts in todays
32 bit CPU's-- but I too think it is a little old-fashoned.  You have
256 intterupts, use them!  You cannot possibly have over 256 hardware
intterups, perhapse 30-50 max, so there is no danger of using them all
up...  Hell, I memory serves me, it has about 50 unused intterupts-- and
it's using them for OS calls at that!


David Kessner - david@kessner.denver.co.us            | do {
1135 Fairfax, Denver CO  80220  (303) 377-1801 (p.m.) |    . . .
If you cant flame MS-DOS, who can you flame?          |    } while( jones);
-- 
David Kessner - david@kessner.denver.co.us            | do {
1135 Fairfax, Denver CO  80220  (303) 377-1801 (p.m.) |    . . .
If you cant flame MS-DOS, who can you flame?          |    } while( jones);
