Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.programmer Subject: Re: 2.0 Compatibility Message-ID: Date: 5 May 91 21:46:35 GMT References: <913.28202b13@vger.nsu.edu> Organization: Not an Organization Lines: 272 In article <913.28202b13@vger.nsu.edu> manes@vger.nsu.edu ((Mark D. Manes), Norfolk State University) writes: >In article , mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >> I'm posting this with no intention of starting a flame war... >> >> I've been using 2.0 for a couple of weeks now, and despite a >>... This whole argument is ridiculous. Apple is hardly a saint and as much if not MORE mac software breaks when they do an OS revision than Amiga software breaks when Commodore does one (speaking from a developer's point of view bashing on 2.0). If it comes to a choice between stagnation and progress I'll pick progress thank you. What do you want us to do, freeze the OS forever? That's the ultimate compatibility and look where it got the IBM-PC people. Frankly, I think it is little short of amazing that SO MANY programs that go DIRECT TO HARDWARE still work... generally because the majority of non-game programmers stick to the appropriate resource allocation calls and restrictions. The Amiga's OS, at least, HAS these calls and is built for multitasking, which apart from the fact that it is multitasking tends to put programmers into a different frame of mind when they write programs... like not assuming the whole machine is their's to play with, for example, and allocating the proper resources when they go direct to hardware. That alone does wonders for compatibility and portability. When it comes right down to it, companies that sell software that doesn't work under 2.0 do not have to do much to find and fix the bugs in their software, and release an update. >> The A2000s should definately be upgraded to 2.0, so we see another >> class of machine to support. And there is the 3000, too, which has >> subtle differences in hardware which can (and possibly should) be >> taken advantage of. > >All Amiga's should upgrade to 2.0. > >The differences in the A3000 hardware has little to do with 2.0. If you follow the rules you will not even notice the differences. I can think of only two instances where an application following the rules breaks under 2.0, and it was something relatively obscure. >> Slowly but surely, the Amiga has gone from a machine that had a finite >> set of standard features to deal with to one that is going to be as >> varied as the PC is. With the PC, there are several graphics adapters, >> mouse devices, audio peripherals, operating systems, etc., that an >> applications programmer has to write almost as much device support >> code as application specific code. > >Can you give a solid example of this? Or is this your vision of the >future? And if it is your vision, what could Commodore do to keep your >future from becomming a reality? Further, would the 3rd parties who >develop hardware/software solutions appreacite Commodore's fix? > >That is called 'growth'. It is not bad. The Amiga really has not >diverged that much, nor do I think it will in the future. 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. Generally, comparing anything with an IBM-PC is foolish. MSDOS isn't an operating system and there is no such thing as a real standard related to it. Any real program written for the IBM-PC basically has to 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. >> I do like the new and powerful features that can be added to the >> Amiga, but I wonder how cost effective it is, for example, to write >> a 2.0 only application. How possible is it to make software that is >> going to be compatible for a long time to come? As good as 2.0 and >> the rest of the addons are, I am concerned that it will be a long time >> before we see developer support for most of it. I know it is currently >> possible to just stick to 1.3 calls and still support 2.0, but there isn't >> much good in all the great things that have been added if they aren't used. > >Time corrects these things. And it's a dumb argument anyway, is the above (>>) person saying that we should freeze the OS forever? No way! But as I say, 99.9% of all properly written software WILL BE COMPATIBLE. >> The Macintosh family of computers has been successful because Apple has >> forced people to adhere strictly to the use of the OS for even the most >> primitive operations. Unfortunately, the Amiga OS is designed to allow >> multiple applications to share and directly manipulate the hardware. It >> is quite common on the Amiga for an application to bypass the graphics >> library and use the blitter (directly) or the cpu to render directly into >> bitplanes. All these applications won't work on a radically different >> display device (such as the lowell one). > >What "application" do you konw that does this? I "know" games do this >all the time, but games are not applications. There is a difference. While the vast majority of applications use OS calls, a few applications do indeed go directly to the blitter. And do you know what? IT WORKS. Do you know why? BECAUSE THE APPLICATIONS WERE WRITTEN WITH MULTITASKING IN MIND AND MAKE THE PROPER RESOURCE ALLOCATION CALLS. The Macintosh's success has NOTHING to do with Apple's attempt to force 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). For a while Apple was telling everyone that all program's name's had to start with 'Mac'... maybe they still do. It is interesting to note that Apple told developer's not to assume they could use the high byte of a pointer for auxillary storage, then went ahead and used that all the time in their OS code, meaning that you couldn't add any kind of accellerator board to the machine for years. They spent a lot of timing cleaning that up, and is one reason why their OS goes through such major changes... they have to fix things they didn't do right the first time. So what did developer's do? They see the OS doing it and assume that they can to, and , major number of broken programs when you stuck in a faster processor. It got so bad that I believe Apple even began using the MMU in an attempt to map out the problem, restricting the address space to a great degree. I think they've gotten rid of that for 7.0 but not being an Apple developer, I don't know. With the Amiga, commodore told developer's not use the high byte of the pointer and you know what? Most developer's didn't. I can remember an instance of only two or three applications that broke when people started hacking in 68020's. One of the reasons you can stick a 68040 in the machine under 2.0 is that people were sticking 68030's in machines under 1.3 way before the first lines of the A3000 were drawn. In terms of compatibility, game programmers have been hurt the worst because they generally make very foolish assumptions based on their earlier days with 8 bit's ... self modifying code, for example, doesn't work with a cache. Some European game programmers go direct to ROM instead of through the library interface... the most idiotic thing I've ever heard of in my life! Other's make assumptions about the location of the VBR. Still other's hardwire the RAM location of the exec.library base, which is also idiotic and guranteed to break. The most common things they do is assume RAM exists in certain places -- that CHIP ram will always be mapped in low memory, for example. When kept to a bare-minimum configuration this generally works, but isn't a good idea in the long run, though with the advent of the MMU it isn't likely to cause problems in the future. Worse is the fact that such games generally ignore the memory allocation subsystem so, essentially, they only work when you boot them. I for one do not buy such games myself -- I generally only buy those games that multitask on my machine. You can neither protect a system from these kinds of abuses, Amiga or Mac, nor can you blame a system simply because a few programmers don't go by the rules. You can't even advocate that the OS maintain compatibility with broken software (though Commodore is doing a damn 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. -- Now, to be fair, there have been a few genuine compatibility problems between 1.3 and 2.0. * The least of these problems is the fact that the screen font can now be proportional, though strictly speaking if programmers went strictly by the book it wouldn't have been a problem -- i.e. if they had specified a specific font to use instead of NULL for the default. This was a necessary change along with the new-look pen changes. The new look plus the proportional fonts make the 2.0 workbench look VERY professional and more pleasing to the eye. * Of more import, the C: commands, shell and scripting language have undergone some major improvements. * A few obscure things were necessarily broken -- mainly assumptions made by programmers due to lack of good documentation. * At most a couple of well documented things have changed, the majority have not. For example, under 2.0 GetScreenData() is obsolete but to support 1.3 GetScreenData() it is not only there, it will modify the returned screen structure to LOOK like a 1.3 screen under the assumption that only 1.3 written programs will call it. * The 2.0 timer.device uses a different cia timer for efficiency, but also has code in it to switch back if an application requests said timer via resources. Of course, any application or game that doesn't bother to make resource requests is going to break... they deserve it too. Most apps do the right thing. Many could-be problems NEVER materialized due to third party accellerators and other boards available under 1.2 and 1.3 * That screen dimensions can be larger than 640x400 (i.e. overscan) * That the workbench may have more than 2 bit planes. * That the system may have more than 512K of CHIP memory (2MB on the A3000) (believe it or not a 1.1 -> 1.2 compatibility problem was that some programs assumed there was no fast memory at all!) * That the system's address space has always been 32 bits, not 24, from a program's perspective. * That the system may contain more than 16MB of memory. * Nobody went direct to hardware for hard drive, SCSI, etc... access due to the large number of HD cards/drivers available. * Except for a few debug programs like Enforcer, and a few MIDI applications, nobody goes direct to the serial port due to the several multi-serial cards available. (Another good reason is that the Amiga's serial.device does 99% of what you want, unlike, say, MSDOS, which does 0%). >Further, not locking programmers into a religion is "good" not "bad". >Shame on you for thinking different. ;-) I refer you to to my >previous comments on the U of L board. >> This is not a lament, but a objective view of what looks like is going on. >> It would be ideal to be able to rely on the OS for future compatibility, >> but there are going to be a zillion gotchas that we are going to have to >> deal with from now on (for each new hardware and OS platform). The Amiga >> is becoming like the Mac in that when the hardware/software changes, those >> who get the improvements will have to upgrade their software to gain full >> compatibility. This simply isn't true. There are not a zillion gotchas. What few gotcha's I have found in the progams I've written take maybe a few minutes to fix, and so far NONE crashed under 2.0 when I first ran them. For example, DME's only two gotchas were that it cleared the repeat flag in the intuition message, and hardwired menu construction constants. 2.0 Uses this flag to track the number of buffered key repeats to allow (default 5), which greatly enhances the capability of the repeat key (you can't build up a hundred keystrokes before the program gets to them, for example). The result if DME's clearing of this bit was that key-repeat would stop working in that particular window after a short while. As for menu's, I assumed topaz-8 instead of checking the screen font. It took about 5 seconds to fix the first problem, and 2 minutes to fix the second problem. DMouse's only gotcha had to do with mouse blanking. I went direct to the copper list on earlier versions of DMouse and this broke under 2.0 (admittedly, I was doing something entirely illegal). By the time 2.0 had come out I had already stuck a check in the code to not attempt to blank the mouse if the copper list was not as expected. After some discussion somebody came up with the bright idea, and I kick myself for not thinking of it, of simply turning off sprite DMA to blank the mouse. Entirely compatible and documented. Works great! And if it ever breaks in the future you simply turn off that particular feature. >Why don't you become a registered developer?? That way the people you >are trying to talk to will hold the proper respect. I second that. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA