Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.programmer Subject: Re: 2.0 Compatibility Message-ID: Date: 7 May 91 21:40:24 GMT References: <913.28202b13@vger.nsu.edu> <91126.101931DXB132@psuvm.psu.edu> Organization: Not an Organization Lines: 176 In article <91126.101931DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: >In article , dillon@overload.Berkeley.CA.US >(Matthew Dillon) says: > >> Frankly, I think it is little short of amazing that SO MANY programs >> that go DIRECT TO HARDWARE still work... generally because the majority > >The hardware hasn't changed. It would be amazing if things didn't work. It's changed more than you realize, it's just relatively transparent to the programmer. For example, the blitter has been extended to handle larger blits, requiring some new control registers. New video modes have been added, even a few new chips in the A3000. Of course, the basic stuff is still there... but unlike IBM-PC programs, most Amiga programs don't touch the hardware directly nor do they need to. On an IBM-PC you don't have a choice, it's go to the hardware or bust. >> when they go direct to hardware. That alone does wonders for >> compatibility and portability. > >Not really. It ensures that multitasking works properly...doing >a proper OwnBlitter or whatever doesn't help a person with XYZ Corp. >video card however. You missed the point. Try rereading the paragraph. My point was that a multi-tasking paradigm alone will cause programmers to write programs using acceptable methods and NOT make stupid assumptions about the location and placement and usage of various resources. On a MAC or IBM you see programmers making wild assumptions about the location and usage of resources simply because they *know* they can get away with it since their program is the only one running, eh? This is one reason why Windows is so broken (having to support such programs which actually make up a MAJORITY in the PC market), and MSDOS has not had any meaningful upgrade for 10 years beyond adding directories and extending HD partition maximums (which took a whole new release). The MAC has similar problems, though not as great due to better hardware independance. The main problem is the operating system itself, which was never designed with expansion in mind. Multifinder has to do some major handholding to work at all, and if you can call it multitasking it's only *barely* multitasking, not even preemptive and jerky as all you-know-where. Certainly you can't do anything like I do on my amiga ... not only running multiple apps, but also running a file server for another amiga and a UNIX compatible cron that maintains other subsystems, such as AmigaUUCP, with which I am communicating this article, automatic backing up of daily work as well... all automatically and without interfering with ANYTHING else going on. After all, it doesn't make sense to have 8 serial ports and all of that screen real estate if you can't USE it all at once. >> Thank your favorite deity that *WE* don't have to worry about having >> to write specific drivers for a myrid of different peripherals. On >> the Amiga, they all use STANDARD interfaces. > >Oh really, then why is Commodore's own gfx card not supported under >the OS? (at the moment). Literally zillions of program will require >updates to support device independent graphics. The OS calls are relatively device independant, actually. It's just that, currently, they are implemented for only the Amiga's hardware. About the only thing that isn't device independant is the copper, and that is a distinct subsection of the library. Most people never touch the copper. The Amiga is notably weak in the area of external graphics cards, even Commodore's own, but it's mainly because Commodore has yet to undertake the task of revamping the graphics subsystem to support third-party hooks. There actually isn't much to it, even the blitter can be emulated, but it's a lot of work to get up to speed on. Fortunately the graphics.library program interface calls are, except for the copper, nearly device independant. The only thing one might want to require is that the bitplane method be used for third party hardware. This imposes nearly nothing on would be third party board makers. Apple on the otherhand shot itself in the foot by specifying both bitmap and bytemap for its graphics standard... so much so that even with graphics accellerators the display is still slow, with no easy means of optimization. >> go direct to hardware for everything, which is WHY they need all those >> drivers. Even their VGA standard isn't a standard -- applications still >> need to pack separate drivers for every VGA board in existance. > >Is the Amiga any different in this area? Not at the moment. Because there is >always the built-in graphics standard to fall back on, it's not considered >a big deal. Gee, a built-in graphics standard... what a novel idea! One that has the capability to handle any resolution, screen depth, and though only 12 bits/pixel now would be a relatively easy extension to increase. So why don't the PC app writers use the supposed VGA and driver standard for VGA and other cards? Because they are slow, buggy, and vary too much across card manufacturers. Oh, and by the way, other resolutions use entirely different 'standards' that are also slow, buggy, and vary too much between card manufacturers. >> developer's to adhere to strict use of the OS. Easily as many Apple >> programs go direct to the hardware as Amiga programs, with the >> exception that they generally don't have multitasking in mind (you >> wonder why so many programs break under MultiFinder, this is one of the >> reasons). > >This can't be true because of the extreme degree of compatibility that >Amax-II exhibits. Certainly not true if you count Amiga games. :-) ?? >> good job in this department for 2.0). Take a look at IBM's mainframes. >> The code is incredibly bloated now because they insist on maintaining >> compatibility all the back to day 1... it keeps the OS in the stoneage. > >Sounds like OS/2, if you've been following that. :-) It seems to me that you have gotten in the habit of refuting everything I say even if you have to resort to lying to do it. I don't suppose you've ever *programmed* for 2.0, eh? 2.0 is solid compared to 1.3, Commodore is certainly not backing away from necessary changes. Every aspect of the OS is easily extensible owing to the dynamic nature of shared libraries, something no other operating system has exploited except, perhaps, UNIX. You do understand what I'm talking about, don't you? You know, the whole MSDOS/Windows/OS-2 argument ? The part about corporate thumb wrestling getting in the way of any real progress? In the case of MSDOS/Windows the fact that what little OS there is is married so closely to the hardware that it's nearly impossible to emulate multitasking, even WITH an MMU... little problems in the MSDOS world like that. And OS/2 .. A joint venture by IBM and Microsoft that directly competes with Microsoft's Windows 3.0 and which IBM insisted, up till recently, had to be compatible with broken 286's. What a mess... and all the while UNIX already offers as much if not a better set of capabilities then OS/2 ever will. >> * That screen dimensions can be larger than 640x400 (i.e. overscan) > >> * That the workbench may have more than 2 bit planes. > >Why not support any resolution? Hard-coding 768x480 is not any better >than hard-coding 640 by 400. Again, zillions of program assumes things >like this...and will break when the system changes *for real* -- even if >written in what is considered the "proper" way. What is considered >correct programming can, and should change from time to time! > >-- Dan Babcock Dan, you really don't know anything about the Amiga, do you? Nobody but game programmers hardcode screen resolutions any more, but you can if you want. In fact, you can ask Intuition to open a screen of ANY dimensions all the way up to the maximum for the requested screen mode (e.g. NTSC, NTSC interlace, 15/30KHz horiz. retrace, etc, etc, etc...). Hell, you can open a 16 bit wide and 50 bit tall screen if you wanted! Hardcoding screen resolutions in applications went out of style 2+ years ago on the Amiga. Under 1.3 you can ask intuition about basic screen dimension maximums and intuit available modes from graphics.library flags. Under 2.0 you can ask intuition about available screen modes and resolutions in a general fashion, then open the one you want. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA