Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!comp.vuw.ac.nz!actrix!templar!jbickers
From: jbickers@templar.actrix.gen.nz (John Bickers)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: 8-bit death
Message-ID: <3479.tnews@templar.actrix.gen.nz>
Date: 9 May 91 09:56:26 GMT
References: <2945.tnews@templar.actrix.gen.nz> <1991May7.090333.1449@kessner.denver.co.us> <3335.tnews@templar.actrix.gen.nz> <1991May9.045705.797@kessner.denver.co.us>
Organization: TAP, NZAmigaUG.
Lines: 72

Quoted from <1991May9.045705.797@kessner.denver.co.us> by david@kessner.denver.co.us (David Kessner):
> In article <3335.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:

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

> Hmmm.  The vector table that you refer to is not 'fixed'.  It is a relatively

    Same place in memory, isn't it? Yet another case of minor
    obfuscation...

> simple matter to make a 'third-party' replacement for these functions-- 

    Sure. As far as MS-DOS goes, I think some of the hacks and kludges
    fitted onto it are rather slick. Like Btrieve, the Novell database
    "library" thing.

    Shows the lengths people will go to when the market is a decent
    size.

> 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

    So it's true. Well well well. How depressing for ST programmers.

> 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

    Bit over a year and a half for me. I've called OS functions lots of
    times, and used int86() and co. quite often. Mostly to diddle with
    the time and system info, come to think of it, so I don't do
    complicated things with it.

> from a rewrite in assembly-- and I question any programmer that doesn't
> do this.  

    Fine. In my view, they don't pay me enough to think about Intel
    assembler to MS-DOS. It's a judgement thing, I guess. I don't have
    that level of OS stuff in any hot spots. I'd also be mildly surprised
    if Microsoft doesn't inline the int86()-type functions, like SAS does
    Amiga library functions, though I've never checked.

> >    No (not any more than any other MS-DOS feature, anyhow. Sharing
> >    interrupts strikes me as being reminiscent of the C= 64 as well,

> 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

    Uh, I don't have a problem with sharing interrupts per se - the
    thing is _how_ you share the interrupts. Consider chaining into
    an MS-DOS interrupt with adding an interrupt handler to the system
    on the Amiga. The latter is about as slick a procedure as I could
    wish for. The former is reminiscient of the C= 64.

> up...  Hell, I memory serves me, it has about 50 unused intterupts-- and
> it's using them for OS calls at that!

    I don't believe there's any standard way to arbitrate who gets what
    interrupts, is there? I have a (very useful) list on MS-DOS
    interrupts, that indicates various products have standard interrupts
    they chain into, rather than trying to locate a "next free interrupt"
    and using that.

    Having some sort of handle on allocation and deallocation of
    interrupts would make it a marginally more respectable system,
    IMHO. Named interrupts, like the Ami's named ports, or something.

> David Kessner - david@kessner.denver.co.us            | do {
--
*** John Bickers, TAP, NZAmigaUG.        jbickers@templar.actrix.gen.nz ***
***         "Endless variations, make it all seem new" - Devo.          ***