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);