Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!sdd.hp.com!mips!daver!ditka!zorch!amiga0!mykes From: mykes@amiga0.SF-Bay.ORG (Mike Schwartz) Newsgroups: comp.sys.amiga.programmer Subject: Re: 2.0 Compatibility Message-ID: Date: 10 May 91 09:37:58 GMT References: <913.28202b13@vger.nsu.edu> <91126.101931DXB132@psuvm.psu.edu> Organization: Amiga makes it possible Lines: 294 In article dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >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. > This is entirely correct. The hardware is a superset of the original chipset. However, if you ignore the extra goodies, it is still the same hardware, as far as going to the metal goes. >>> 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. > No matter what paradigm you want to talk about, if the hardware moves or changes radically, which we should expect at some point in the future, programs that use the "friendly" OS routines (like OwnBlitter()) are going to break. And even if programs use graphics.library and intuition only, a chunky pixel format is going to require either slow software to convert all your bitmaps, IFF graphics, Image structure data, etc. from planar to chunky. Maybe we better pray for a hardware solution (like the bridgeboard uses). No matter how you want to slice and dice it (no pun intended), the programs that I need to upgrade (I'm looking at at least 10 different professional/commercial applications) don't even go to the hardware. > 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). > You are really out of touch. Macintosh programs DON'T go directly to the hardware, since there are too many flavors of macintosh these days. Macintosh programs use a routine called CopyBits() to do all screen rendering which allows the software to work on the wide variety of graphics adapters, including 4Kx4K 256 color displays, multiple monitors on the same system, 3rd party display adapters, etc. And on the PC, there is a VGA and EGA BIOS supplied by the hardware manufacturers. The PC has the exact same problem that the Amiga does: the OS routines are too general purpose (and therefore too slow) to get the most performance from the machine so programmers bang the metal. > 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. > > There is a kludgy solution to any problem Apple and PC programmers WANT to solve. They've constantly proven it over the years. >>> 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. > Again, OwnBlitter() is not device independant, especially when the software follows the call by storing to blitter registers. Yeah, the MMU on the vast minority of machines might handle this issue, but it isn't even possible with a 68000 machine. > > 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. > The Amiga is NOT weak in the area of external graphics cards. There are several 24 bit options, and the Lowell board is kick-butt quality. Is CBM really going to revamp the graphics subsystem to support third-party hooks or are they going to require major rewrites to everyone's programs to deal with some new device independant library? > 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. > Apple shot itself in the foot with a poor bus standard, period. I can't wait to see how ugly ScrollRaster() looks when working on 24 bitplanes. >>> 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. > Don't expect better from Commodore. They have fewer people in house than IBM, Microsoft, Intel, Compaq and the rest. They have fewer people than Apple. How about R&D? Compaq alone just spent like $200 million on SGI stock and R&D, and this was pocket change to them and would certainly be considered an outstanding net profit for CBM. >>> 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. :-) > > ?? > Translation: If Mac programs go directly to the hardware, they wouldn't work on the Amiga running AMax. So far, I've only found a couple of PD terminal programs that DON'T work. Amiga games that use the OS are in for serious problems. >>> 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. How about OS/9? > Come on Matt, you don't have to get frustrated if people don't see eye to eye with you. Everyone who reads this group loves the Amiga just as much as you. Is yours the only valid view of things? How is Dan's joke above refuting anything you are saying (your response appears as if you think it does). Looks to me like if he's refuting anything, it's your refuting :) And 1.3 has almost 6 years of work behind it while 2.0 has a lot less. I've seen more bugs in 2.0 than I ever saw in 1.3, especially when running 1.3 applications (NOT GAMES). > 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. > It's been my opinion for years that Microsoft should have built Windows around Xenix. But Dan makes a joke and you ramble on about issues that belong in .advocacy (AMiga is better than IBM and so is Unix...). >>> * 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! > Dan knows more about the Amiga than you give him credit for. He must actually use commercial Amiga applications because what he sees is absolutely correct. What I see is too many APPLICATIONS making STUPID ASSUMPTIONS (in your words) about the size of the screen. PowerWindows alone is probably used by soooo many developers, and its use under 1.3 encourages poor quality 2.0 programs. How many programs can you name that actually specify a screen font or look at the default screen resolution and deal with it properly? I can name 2: CygnusEd (has no problems with menus when running on the Workbench) and DPaint III (which doesn't let me use a 320x200 screen when I want to if my defaults are bigger than 640x400 or 640x200). I got PowerWindows 1.0, 2.0, and 2.5. Nowhere along the way did they anticipate the problems that the 2.0 ROMs have brought. Apparently, their customers (i.e. applications developers) never bothered to point out to them the error of their ways (like generating a NULL default font for screens). > Hardcoding screen resolutions in applications went out of style 2+ > years ago on the Amiga. > So as Dan would say, the programming rules changed 2+ years ago? I don't agree with you (sorry) because 99% of the APPLICATIONS I bought over the last 2+ years do indeed open hard coded sized screens. > Under 1.3 you can ask intuition about basic screen dimension maximums > and intuit available modes from graphics.library flags. > One can, but few did. Did you? > Under 2.0 you can ask intuition about available screen modes and > resolutions in a general fashion, then open the one you want. > If people bother to (which I hope they do). > -Matt > >-- > > Matthew Dillon dillon@Overload.Berkeley.CA.US > 891 Regal Rd. uunet.uu.net!overload!dillon > Berkeley, Ca. 94708 > USA -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************