mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (04/30/91)
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 few bugs and missing features, it is delightful. As I use it, though, I am beginning to see the Amiga market becoming highly fractured. I've seen it run on a 68000 machine, and it is reminiscent of the Mac (SE, Plus, etc.) in terms of performance. I have a 1Meg Amiga 500 that still has 1.2 in ROM, and I suspect that there are a lot of similar machines in the universe. This is the first segment of Amigas that programmers must consider. If there are, say, 1.5 Million A500s with 1.2, .25 Million A500s with 1.3, and some future number with 2.0 (all in ROM), we programmers must at least support 1.3 and 2.0 features. This means writing two sets of routines for our programs... The A1000 is appearing as if it is not going to get much continued support, at least from Commodore, but as developers, we should still support it. The A1000 is an Amiga after all, and it should run all the programs even if hardware expansion becomes limited in the future. 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. And there was talk a while ago about Commodore coming out with a new graphics standard a while ago (the Lowell board), which again requires a different programming strategy. And what if CBM comes out with yet another standard? And then there are all the various 24-bit graphics adapters (toaster, HAM-E, DCTV, etc.) which might deserve consideration for support... 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. 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. 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). It sure looks safe to simply write CLI based applications, because they won't break as easily, but these kinds of programs aren't any better than a Unix or MS-DOS or MPW program (to a large extent). The Amiga has a decent GUI in Intuition, but even its use doesn't appear as if it is going to keep applications compatible for a long time to come... One of the first things I noticed about 2.0 is that when I run CygnusEd in a workbench window, the pull-down menus no longer line up correctly (thanks to 2.0's ability to allow me to change the default screen font). 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. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
rockwell@socrates.umd.edu (Raul Rockwell) (04/30/91)
Mike brings up an interesting point (though he didn't phrase it exactly this way): Are the Amiga 2.0 added-functionality calls (things like the new file requester) going to be available for people who develop software for 1.3/2.0 ?? [yeah, I know, pay your money and become a developer to find out... ] Raul
jap@convex.cl.msu.edu (Joe Porkka) (04/30/91)
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >I'm posting this with no intention of starting a flame war... Nor do I intend to. I'm not trying to flame you, just a difference of opinion here - take no offence please. >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 How can Apple force people to do anything? I'll tell you, read on... >primitive operations. Unfortunately, the Amiga OS is designed to allow >multiple applications to share and directly manipulate the hardware. It Actually, it provides support so most applications do not need to acess the hardware directly. It does supply a means to get at the hardware in an OS friendly way should you need to. >is quite common on the Amiga for an application to bypass the graphics ^^^^^^^^^^^ you must mean game. >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). Hm, Apple developers have only been forced to play by the rules because of the variety of AppleOS's and hardware in use. I suspect the same to happen with the Amiga. If a program has played by the rules, it will work on a A3000 with 2.0. Up until the A3000 there really wasn't any different Amiga hardware, From a programs point of view, the A1000, A500, A2000 are 99% identical. Some hardware change has already happened. Remeber how many programs (games and applications alike) broke when people started adding non-CHIP expansion memory? 1meg chip memory? HardDrives also caused (and still are) compatibility problems. So the lesson is, the more diverse the Amiga hardware in use, the better quality the software will *have* to be in order to function on all the machines. This means that programmers will have to follow the rules in the RKMs more closely. Do you have the gam MindWalker? It was written for AmigaDOS 1.0!, and yet it actually runs on a A3000, not perfectly, but it does not crash. Whoever wrote that game followed the rules, as well as they where defined in 1.0 days, and so the program still works many years later.
es1@cunixb.cc.columbia.edu (Ethan Solomita) (04/30/91)
In article <mykes.2036@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > >And there was talk a while ago about Commodore coming out with a >new graphics standard a while ago (the Lowell board), which again >requires a different programming strategy. And what if CBM comes >out with yet another standard? > >And then there are all the various 24-bit graphics adapters (toaster, >HAM-E, DCTV, etc.) which might deserve consideration for support... > What's wrong with a standard? It's not as if CBM is redefining the same standard over and over again. As to those new boards, most likely (since the Amiga market ain't that big) they'll fight it out and there'll be clear winners given a few more months. What's wierd is that in one paragraph you worry about CBM coming out with a graphics board standard and then you worry about how there are lots of standards. >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. > The Amiga market is finally maturing. Perfect observation. Of course (except in graphics boards, where we're worse) we are much more unified than they are. Two bus standards, same auto-config standard. Same CPU slot. Same Video slot. Same SCSI. Same ports on the back. One disk format (realistically). etc. etc. Not so bad I don't think. Besides, since we have a REAL operating system, not a DISK operating system, much of that is hidden from those who don't want to deal with it. >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). > Unfortunately? I think it is very fortunate. Let the programmer do what is best. If his software breaks, he'll learn. If he doesn't learn, he'll go out of business. The compatibility with 2.0 is so high that I'm convinced that most programmers were reasonable with there programming standards. As to accessing the HW directly, that's why there are semaphores and such to make that work LEGALLY. You can obtain the blitter all for yourself and break nothing. >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. > I don't understand this thing about compatibility. I'm probably missing your point, but compatibility seems to be the least of the Amiga's problems. As to using newer OS features, just check the revision number when you open a library. If it is 37 or greater, use the new features. Otherwise don't. ProWrite did it quite effectively. >-- >**************************************************** >* I want games that look like Shadow of the Beast * >* but play like Leisure Suit Larry. * >**************************************************** -- Ethan "Brain! Brain! What is Brain?"
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (05/01/91)
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >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. Well, not exactly. I feel that most people WILL upgrade to 2.0, as a matter of fact i AM developing 2.0 only applications as well as several other people. there is even a 2.0 only backup program out already called Ami-Back. I think 2.0 is such an upgrade that people that can't afford to upgrade their roms won't be able to afford my software. which means that pirates won't be able to run it :) (well there's ways around that i know.. but just wishful thinking).. but anyways, Most people will be running 2.0 i feel. it's just so dang wonderful that people would be fools not to run it. > >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). Yeah, well commodore itself is hard at work for a FULLY documented interface, they've had general rules for years, but they're trying to iron out the loopholes. the big problem is still with european programmers not having access or not being able to afford proper documentation. The mac doesn't have this problem since it's Euro sales are about Nil: :) Commodore is also at work on a Device Independant Graphics device.. great things take time.. > >It sure looks safe to simply write CLI based applications, because they >won't break as easily, but these kinds of programs aren't any better than >a Unix or MS-DOS or MPW program (to a large extent). The Amiga has a >decent GUI in Intuition, but even its use doesn't appear as if it is going >to keep applications compatible for a long time to come... One of the >first things I noticed about 2.0 is that when I run CygnusEd in a workbench >window, the pull-down menus no longer line up correctly (thanks to 2.0's >ability to allow me to change the default screen font). well, again, many of the inconsistancies you see are because of people takeing advantage of undocumented bugs (some call features) which disapear in bug fixes. also, it's long been known that the default fonts can and probably will change, so that ASDG's problem. > >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. Well, it's not too objective IMHO. you are reacting to hype generated by people that don't take time to ask the proper questions (MB?). sure, alot of software won't work under 2.0, but these are because the developers chose to take shortcuts rather than be thorough. Commodore has long warned about 99% of all the problems people are encountering now. Apple on the other hand hs consistantly changed it's specs. it says do it this way or die.. so you do it that way, then apple says, no we didn't mean THAT way.. do it this way now. (we have always been at war with etc... etc.. etc..., etc.. has always benn our ally.. very representitive of orwellian theories) Apple makes mistakes then tries to pawn them off on developers, commodore had the forethough to warn people of 99% of the compatibility problems, people just chose to ignore them. .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
espie@flamingo.Stanford.EDU (Marc Espie) (05/02/91)
In article <4766@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: >mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: [parts of a nice discussion deleted to save space] >Yeah, well commodore itself is hard at work for a FULLY documented interface, >they've had general rules for years, but they're trying to iron out the >loopholes. the big problem is still with european programmers not having >access or not being able to afford proper documentation. The mac doesn't have >this problem since it's Euro sales are about Nil: :) Commodore is also at >work on a Device Independant Graphics device.. great things take time.. > >> >>It sure looks safe to simply write CLI based applications, because they >>won't break as easily, but these kinds of programs aren't any better than >>a Unix or MS-DOS or MPW program (to a large extent). The Amiga has a >>decent GUI in Intuition, but even its use doesn't appear as if it is going >>to keep applications compatible for a long time to come... One of the >>first things I noticed about 2.0 is that when I run CygnusEd in a workbench >>window, the pull-down menus no longer line up correctly (thanks to 2.0's >>ability to allow me to change the default screen font). > >well, again, many of the inconsistancies you see are because of people takeing >advantage of undocumented bugs (some call features) which disapear in bug >fixes. also, it's long been known that the default fonts can and probably >will change, so that ASDG's problem. Warning! Gripe alert. > >> >>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. > >Well, it's not too objective IMHO. you are reacting to hype generated by >people that don't take time to ask the proper questions (MB?). sure, alot of >software won't work under 2.0, but these are because the developers chose to >take shortcuts rather than be thorough. Commodore has long warned about 99% >of all the problems people are encountering now. Apple on the other hand hs >consistantly changed it's specs. it says do it this way or die.. so you do it >that way, then apple says, no we didn't mean THAT way.. do it this way now. >(we have always been at war with etc... etc.. etc..., etc.. has always benn >our ally.. very representitive of orwellian theories) Apple makes mistakes >then tries to pawn them off on developers, commodore had the forethough to >warn people of 99% of the compatibility problems, people just chose to ignore >them. :-). Go on banging on Apple, I like that. >.--------------------------------------------------------------------------. >| UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | >| ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | >| INET: chucks@pnet51.orb.mn.org | you really think he's | >|-------------------------------------------------| moved back in?" | >| Amiga programmer at large, employment options | Lou Diamond Philips in | >| welcome, inquire within. | "The First Power". | >`--------------------------------------------------------------------------' About that font change problem, I think this is THE biggest loophole in specs. HOW WHERE PROGRAMMERS SUPPOSED TO DEDUCE FROM THE ROM KERNEL MANUAL THAT THERE WOULD BE *TWO* DISTINCT SYSTEM FONTS ? Myself, not being a professionnal developper, and having the RKM1.3, was having a hard time figuring that out. Knowing you can rely on preferences fonts is rather elusive, where do you find the font information ? For people wanting to make software run under 2.0, here are the steps I know of. - the easiest way is probably to specify the ``default'' topaz.80 in every possible field. - if you want to have a nice looking application, it is much better to deal with the default fonts. There are two such fonts, a system font, and a screen font. The system font is to be found in GfxBase->DefaultFont, the screen font is to be found in the screen you want to open: screen->Font. One bad thing about these is that one speaks graphics (struct TextFont), and the other one speaks intuition (struct TextAttr). ok, you can also find the screen font attributes in the screen rastport. Other interesting detail, the screen font is not necessarily fixed-width, the system font is... To get to that screen (for instance workbench), you can either open a window in it, or lock IBase and look for it... the big problem is, if you don't have a window opened, preferences is free to change its fonts... so you had better get to it with a probe window (LockPubScreen is of course another solution, which doesn't run under 1.3). (side-question to 2.0 developpers: is there a way to get notified when preferences wants to change its fonts, so that you can do as the workbench, close all your windows, wait for font change, and reopen them ?) ...So, some time later, you manage to get the height of the two fonts you will have to play with. Where are they used ? - menus use the screen font by default. - unless you setfont in the window rastport, the Text and IntuiText function use the system font. - any text specified in Gadgets and stuff like that uses the screen font !!! I would have expected the system font, but... live and learn. With that in mind, you can get nice looking text at the right size. Other compatibility problems: window borders and window title. The simplest way I've found around this one is the following (since GZZ windows are inefficient): - open a window as though it had no borders. - adjust all your gadget and display stuff to the window border. - resize the window, simply: Size(window, window->BorderRight + window->BorderLeft, window->BorderTop + window->BorderBottom); (for more dynamic sizing, you can compute open the window with say, xstart and ystart as a size, compute the size you need (borders not included), say xmax, ymax, and Size(w, w->BorderRight + window->BorderLeft + xmax - xstart, ...). Another compatibility issue: colors. Use variables for the ``constant'' BLACK and WHITE pen numbers (instead of hard-coding 1 and 2). If your IntuitionBase version is greater or equal to 36 (not 37... commercial 3000 have 2.02, which is 36.something), swap them. Of course, this kind of stunt needs to be tested on a 2.0 system... find a friend who has one. A last thing that can be done: use the arp.library. When 2.0 is finally available to everybody, most of your arp stuff will need only minimal changes to run under 2.0. As an example, my Lattice C includes for the file requester give a structure which is a carbon copy of the arp one, and incredibly similar calling sequences (in fact, using the arp autodocs, you can just figure out many new calls of 2.0). Of course, this kind of thing is only a stopgap measure, 2.0 availability for everybody would be much better. But with some extra-effort, much stuff, can run under 1.3 and 2.0. -- Marc (espie@flamingo.stanford.edu)
markv@kuhub.cc.ukans.edu (05/02/91)
> - the easiest way is probably to specify the ``default'' topaz.80 in every > possible field. Nice, but awfully tough to read in 640*480, much less future (ie: 2610 etc) 1000+ pixel modes. > - if you want to have a nice looking application, it is much better to deal > with the default fonts. There are two such fonts, a system font, and a screen > font. The system font is to be found in GfxBase->DefaultFont, the screen > font is to be found in the screen you want to open: screen->Font. The screen->Font can be just about anything under 2.0. As said, GfxBase can use give a proportional font. Note that even Commodore doesn't expect people to deal with completely irrational choices, like a 48 size prop font or such on a normal screen. Menu Layouts are easy with 2.0, Gadget spacing is a little tougher. I use a logical grid system and layout based on that, and with GadTools, I know my spaceing will be reasonable, buttons will contain their text. Its up to the user to pic a font that works okay with their screen size. In most cases, proportional really isn't a problem, when it is, then specify a fixed font. > (side-question to 2.0 developpers: is there a way to get notified when > preferences wants to change its fonts, so that you can do as the workbench, > close all your windows, wait for font change, and reopen them ?) Yes, open a file notification lock on the font prefs file in ENV:, then the file system will send you a message when it changes. > With that in mind, you can get nice looking text at the right size. If all else fails, explicity specify a standard font you know will work. Dont leave TextAttr fields NULL unless you CAN handle varying fonts. > Other compatibility problems: window borders and window title. The simplest > way I've found around this one is the following (since GZZ windows are > inefficient): > - open a window as though it had no borders. > - adjust all your gadget and display stuff to the window border. > - resize the window, simply: > Size(window, window->BorderRight + window->BorderLeft, window->BorderTop + > window->BorderBottom); This is a bit more of a problem. Most programmers (myself included) have been guilty of ignoring the BorderXXX fields, but they do matter and are correct in 2.0. One big gripe I have is that GadTools dont support GREL positioning. I can deal with the "window as a requester" issue, but the lack of relative support kills GadTools for things like dynamic sizable windows in editors, etc. > Another compatibility issue: colors. Use variables for the ``constant'' BLACK > and WHITE pen numbers (instead of hard-coding 1 and 2). If your IntuitionBase > version is greater or equal to 36 (not 37... commercial 3000 have 2.02, > which is 36.something), swap them. Even better is to use 1 and 2 on 1.3, and look at your Screen's DrawInfo with GetScreenDrawInfo() 2.0. That way you'll be fully compatible with any public screen (which you could end up on with the SHANGHAI flag). > Of course, this kind of thing is only a stopgap measure, 2.0 availability > for everybody would be much better. But with some extra-effort, much stuff, > can run under 1.3 and 2.0. Personally, the stuff I'm finishing will be 1.3 apps that have some 2.0 awareness to deal with color issues, fonts, etc. New stuff I'm writing will be 2.0 specific, since it isn't worth writing a GadTools compatible replacement etc just to maintain backwards compatibility for the transition period. Of course until Commodore actually releases 2.0 to the rest of the world, there is a small market indeed for the 2.0 apps. > -- > Marc (espie@flamingo.stanford.edu) -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
forgeas@swinjm.UUCP (Jean-Michel Forgeas) (05/02/91)
In article <4766@orbit.cts.com>, Erik Funkenbusch writes: > [...] the big problem is still with european programmers not having > access or not being able to afford proper documentation. How CAN you say that ? It is WRONG. In France developers have docs since 1986. (I do not say that all developers read it, but this problem is the same in the entire world :-) > [...] sure, alot of software won't work under 2.0, but these are because A lot of software WORK under 2.0. How CAN you say that a lot don't work ? > | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | -- \___/ Jean-Michel Forgeas \-/ cbmvax!cbmehq!cbmfra!swinjm!forgeas | The Software Winery -^- And, where is the universe ?
peter@cbmvax.commodore.com (Peter Cherna) (05/02/91)
In article <1991May1.213904.338@neon.Stanford.EDU> espie@flamingo.Stanford.EDU (Marc Espie) writes: >About that font change problem, I think this is THE biggest loophole in specs. >HOW WHERE PROGRAMMERS SUPPOSED TO DEDUCE FROM THE ROM KERNEL MANUAL THAT >THERE WOULD BE *TWO* DISTINCT SYSTEM FONTS ? A great many applications could not handle proportional fonts, so it became clear that GfxBase->DefaultFont had to be a monospace font. However, Intuition was quite capable of handling proportional fonts for things like screen titles, and they look much better. It would have sucked to force the titlebar font to be monospace. That is how the screen font came to be defined as "the user's preferred font", and GfxBase->DefaultFont came to be defined as "the user's preferred monospace font". >Myself, not being a professionnal developper, and having the RKM1.3, was >having a hard time figuring that out. Knowing you can rely on preferences fonts >is rather elusive, where do you find the font information ? The system has to grow. Often that means mild compatibility glitches when the system is in a "new" state. Compatibility can be returned by restoring default preferences (eg. font, screen-mode, overscan). >The system font is to be found in GfxBase->DefaultFont, the screen >font is to be found in the screen you want to open: screen->Font. If you're opening on someone else's screen (usually the Workbench), then the screen's font is not necessarily the same as the user's preferred screen font. You could open a public screen with Helvetica 27 as its font, if you like. >One bad thing about these is that one speaks graphics (struct TextFont), >and the other one speaks intuition (struct TextAttr). It's exceptionally straightforward to build a TextAttr out of a TextFont. Incidentally, both structures are graphics.library concepts. Think of a TextAttr as a font request, like a NewWindow structure is. A TextFont is an actual instance of a font, like a Window structure. >Other interesting detail, the screen font is not necessarily fixed-width, >the system font is... As I mentioned above, that's _the_ crucial detail. >To get to that screen (for instance workbench), you can either open a window in >it, or lock IBase and look for it... the big problem is, if you don't have >a window opened, preferences is free to change its fonts... so you had better >get to it with a probe window (LockPubScreen is of course another solution, >which doesn't run under 1.3). It's easy to call LockPubScreen() if you're running V36 or higher. LockPubScreen() ensures that nobody can close the screen you're trying to open on, while you make enquiries of it. If you're going to open a window based on things you've learned through LockPubScreen(), then you MUST use the {WA_PubScreen, pubsc} tag-item, to ensure that you'll open on the intended screen. Note that by setting NW_EXTENDED, you can call (old-style) OpenWindow() and still pass a tag-list, that 1.3 will ignore. >(side-question to 2.0 developpers: is there a way to get notified when >preferences wants to change its fonts, so that you can do as the workbench, >close all your windows, wait for font change, and reopen them ?) You can wait on notification for the files that cause Workbench to be reset: overscan, screenmode, screenfont. However, it's almost certainly not worth the bother, since in real use, the user isn't constantly switching these. The user typically plays with them for fun or to decide what he likes, then eventually they're not changed any more. It can end up being a fair amount of coding to be able to shut down your window, and re-open it with the previous context. Actually, now that I think about it, there's no easy way to know when the Workbench screen has re-opened! (We did consider supporting this, but it's far harder than it seems. Some of the most frightening synchronization problems I've ever seen were in this area. We used to have cases where Workbench failed to re-open when you made a change under certain rare conditions. It would have been a tremendous amount of work to get a robust, functional mechanism working for general use. Remember that with just Workbench, Intuition has only one customer to worry about, and we control the code that's in it...) >Other compatibility problems: window borders and window title. The simplest >way I've found around this one is the following (since GZZ windows are >inefficient): >- open a window as though it had no borders. >- adjust all your gadget and display stuff to the window border. >- resize the window, simply: >Size(window, window->BorderRight + window->BorderLeft, window->BorderTop + >window->BorderBottom); >(for more dynamic sizing, you can compute open the window with say, >xstart and ystart as a size, compute the size you need (borders not included), >say xmax, ymax, and Size(w, w->BorderRight + window->BorderLeft + xmax - xstart, >...). You can save yourself a lot of trouble by noting that the titlebar height can be predicted as: screen->WBorTop + screen->Font->ta_YSize + 1 The other border dimensions are compatible with the values used in 1.3, and are constant. They only vary if you stuff larger border gadgets into them. I expect that if such dimensions will ever have to change, that there will be a compatibility flag you set to request it. It really is a question of yield vs. cost. Getting the screen font into the title bar makes the system look _amazing_. Tweaking things like the height of the sizing gadget (which would be nice for interlaced screens, for example) is lower yield. > Marc (espie@flamingo.stanford.edu) Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "If all you have is a hammer, everything looks like a nail."
manes@vger.nsu.edu ((Mark D. Manes), Norfolk State University) (05/03/91)
In article <mykes.2036@amiga0.SF-Bay.ORG>, 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 > few bugs and missing features, it is delightful. As I use it, > though, I am beginning to see the Amiga market becoming highly > fractured. I've seen it run on a 68000 machine, and it is > reminiscent of the Mac (SE, Plus, etc.) in terms of performance. Funny the performance hit does not seem to great to me. In fact, in some ways it seemed as though 2.0 ran faster on my A2000 than did 1.3. Perhaps if you reduced your number of colors on your Workbench?? - What missing features?? > > I have a 1Meg Amiga 500 that still has 1.2 in ROM, and I suspect > that there are a lot of similar machines in the universe. This > is the first segment of Amigas that programmers must consider. > If there are, say, 1.5 Million A500s with 1.2, .25 Million > A500s with 1.3, and some future number with 2.0 (all in ROM), > we programmers must at least support 1.3 and 2.0 features. This > means writing two sets of routines for our programs... It is very easy to see which version of the operating system you are running under. Personally the sooner 1.3 dies the better. Those who don't want to upgrade, well, that is sad. Life goes on. I am sure that these folks who don't upgrade to 2.0 will still be happy with the games they have been playing and the new ones that come out and toss the operating system anyway 1/2 :-). Since all Commodore computers will be shipped with 2.0 in ROM in the near future, the 1.3 issue will dissappear over time. > > The A1000 is appearing as if it is not going to get much continued > support, at least from Commodore, but as developers, we should still > support it. The A1000 is an Amiga after all, and it should run all > the programs even if hardware expansion becomes limited in the future. If you were a registered developer you would know better than this. Sigh, looks like you pirated, ahh sorry, stole 2.0 to me. Which in my opinion makes your opinion seem a bit, well, less than crediable. > > 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. > > And there was talk a while ago about Commodore coming out with a > new graphics standard a while ago (the Lowell board), which again > requires a different programming strategy. And what if CBM comes > out with yet another standard? As far as I know, the U of L board has only been announced for UNIX, not for AmigaDOS. Perhaps this will change, but as of today there is no announced definition of a extension to Amiga graphics under AmigaDOS from Commodore. I kinda doubt Commodore will jump to a quick solution for upgrading Amiga graphics hardware for AmigaDOS. I suspect they will spend their efforts "rightly" on retargetable graphics libraries and perhaps a enhanced Amiga chipset. Until then, we will have to live with the 3rd party graphics solutions. This is my opinion, not based on anything other than the postings I have seen here. > > And then there are all the various 24-bit graphics adapters (toaster, > HAM-E, DCTV, etc.) which might deserve consideration for support... Each vendor will support their idea of the 24 bit solution. So far, each of the 24 bit solutions solve different problems. As long as there is a file standard between these devices, I am not sure what other support is needed by developers. Though IFF24 is not the best solution, it certainly works -- and will work for the forseeable future. > > 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. Remember, the developers, make their coins by solving problems on a particular platform. That is the basis of their income. > > 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. > > 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. 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. > > It sure looks safe to simply write CLI based applications, because they > won't break as easily, but these kinds of programs aren't any better than > a Unix or MS-DOS or MPW program (to a large extent). The Amiga has a > decent GUI in Intuition, but even its use doesn't appear as if it is going > to keep applications compatible for a long time to come... One of the > first things I noticed about 2.0 is that when I run CygnusEd in a workbench > window, the pull-down menus no longer line up correctly (thanks to 2.0's > ability to allow me to change the default screen font). CygnusEd has been updated for 2.0. Of course the shrink gadget is _still_ broken (Perry!!!!), however it works fine besides that. > > 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. Why don't you become a registered developer?? That way the people you are trying to talk to will hold the proper respect. Suppose you created BlazeMonger 16 - The final Saga, and I decide that it would not hurt you if I stole it and ran it on my system. Would you appreciate that? Would you really be interested in my comments about that? I grant that a operating system is not the same as a application or game, but Commodore has spent dollars to create 2.0. Developers have paid Commodore dollars for access to beta software, so they can provide you with better products. Why do you feel that you can just 'ignore' these things? And further, why would you think anyone would care about your visions if you can't respect the rights of others? Now if you are a registered developer and you do have 2.0 legally then ignore all that I have said. However, I believe I already flammed you before on this subject. > > -- > **************************************************** > * I want games that look like Shadow of the Beast * > * but play like Leisure Suit Larry. * > **************************************************** -mark= +--------+ ================================================== | \/ | Mark D. Manes "The Most lopsided deal since ..." | /\ \/ | manes@vger.nsu.edu | / | (804) 683-2532 "Make up your own mind! - AMIGA" +--------+ ================================================== "I protest Captain! I am not a merry man!" - Lt. Worf
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/03/91)
In article <4766@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: >mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>.. >>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. > >Well, it's not too objective IMHO. you are reacting to hype generated by >people that don't take time to ask the proper questions (MB?). sure, alot of >software won't work under 2.0, but these are because the developers chose to >.. I should mention that a great deal of attention has been paid to making 2.0 upward compatible, including some specific hacks in 2.0 to support broken 1.3 programs. 99% of the 1.3 software out there will run on 2.0 straight. This can't be said for Apple when they switched to 6.0, they'd just like you to *believe* that. What will happen when apple switches to 7.0 is anyone's guess. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/03/91)
In article <1991May1.213904.338@neon.Stanford.EDU> espie@flamingo.Stanford.EDU (Marc Espie) writes: >In article <4766@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: >>mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >[parts of a nice discussion deleted to save space] >>warn people of 99% of the compatibility problems, people just chose to ignore >>them. >:-). Go on banging on Apple, I like that. :-) >About that font change problem, I think this is THE biggest loophole in specs. >HOW WHERE PROGRAMMERS SUPPOSED TO DEDUCE FROM THE ROM KERNEL MANUAL THAT >THERE WOULD BE *TWO* DISTINCT SYSTEM FONTS ? >Myself, not being a professionnal developper, and having the RKM1.3, was >having a hard time figuring that out. Knowing you can rely on preferences fonts >is rather elusive, where do you find the font information ? Commodore has specifically mentioned the fact that if you WANT topaz 8 you should SPECIFY it as your TextFont instead of putting a NULL there to get the system default font. Either that or properly compute your rendering based on nominal text size. Those people who followed the rule will get topaz 8 under 2.0. Those people have not followed that rule will get the system default font which is no longer necessarily topaz 8. Now, obviously, the *user* wants said program to use their selected fonts, but if the program break's with a non 8 font then it's an ok hack. I've personally heard this at least 3-4 times over the last several years and believe it's even in the documentation somewhere. Of course, <grin>, I'd not paid too much attention to it until I started developing under 2.0, but it turned out to be pretty easy to upgrade the source code to handle variable fonts. >For people wanting to make software run under 2.0, here are the steps I know >of. > >- the easiest way is probably to specify the ``default'' topaz.80 in every >possible field. >- if you want to have a nice looking application, it is much better to deal >with the default fonts. There are two such fonts, a system font, and a screen >font. The system font is to be found in GfxBase->DefaultFont, the screen >font is to be found in the screen you want to open: screen->Font. >... >the system font is... >To get to that screen (for instance workbench), you can either open a window in >it, or lock IBase and look for it... the big problem is, if you don't have >a window opened, preferences is free to change its fonts... so you had better >get to it with a probe window (LockPubScreen is of course another solution, >which doesn't run under 1.3). LockPubScreen() is the best way. It's actually easier to simply check the library version of either EXEC or DOS in a conditional and USE the 2.0 calls when the program is running under 2.0 (if you are developing an application that works under both). That way you can easily delete the 1.3 code in a year. >(side-question to 2.0 developpers: is there a way to get notified when >preferences wants to change its fonts, so that you can do as the workbench, >close all your windows, wait for font change, and reopen them ?) Not yet that I know of. >... >A last thing that can be done: use the arp.library. When 2.0 is finally >available to everybody, most of your arp stuff will need only minimal changes >to run under 2.0. As an example, my Lattice C includes for the file requester >give a structure which is a carbon copy of the arp one, and incredibly similar >calling sequences (in fact, using the arp autodocs, you can just figure out >many new calls of 2.0). > >Of course, this kind of thing is only a stopgap measure, 2.0 availability >for everybody would be much better. But with some extra-effort, much stuff, >can run under 1.3 and 2.0. >-- > Marc (espie@flamingo.stanford.edu) In terms of ARP, I would *STRONGLY* suggest that people with ARP do not overwrite the 2.0 C: commands. Instead, rename your ARP commands. In fact, for the most part you may decide to throw them away entirely since the 2.0 C: command executables are tiny. If you *replace* your 2.0 C: commands with ARP commands you are guarenteed to BREAK a lot of programs you try to run, causing a lot of hassle for yourself. I for one have grown tired of all the 'bug' reports I get that turn out to be problems with ARP and I don't want to see it all get transfered to 2.0. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
peter@cbmvax.commodore.com (Peter Cherna) (05/03/91)
In article <1991May2.110934.30307@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: >The screen->Font can be just about anything under 2.0. As said, >GfxBase can use give a proportional font. The system will not put a proportional font in GfxBase->DefaultFont. You _can_ count on that being a monospace font, of some size or other. >One big gripe I have is that GadTools dont support GREL positioning. >I can deal with the "window as a requester" issue, but the lack of >relative support kills GadTools for things like dynamic sizable >windows in editors, etc. It's a pretty common enhancement request. There were some reasons why it was tricky, and so it didn't make it in. >Mark Gooderum Only... \ Good Cheer !!! Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "If all you have is a hammer, everything looks like a nail."
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/03/91)
In article <1991Apr30.133904.12649@msuinfo.cl.msu.edu> jap@convex.cl.msu.edu (Joe Porkka) writes: >mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > >>I'm posting this with no intention of starting a flame war... >Nor do I intend to. I'm not trying to flame you, just a difference >of opinion here - take no offence please. > >>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 >How can Apple force people to do anything? I'll tell you, read on... They don't publish complete hardware manuals, they don't define a specific video architecture (planar, chunky, bits per pixel, etc.). They specifically tell you that (and which) specific hardware features are likely to change. You are right, that you can make software that works for just one specific display adapter (that goes to the hardware), but it just isn't done. Apple has also radically revved their OS several times, while Commodore has only done it once (2.0). 1.3 is pretty much the same as 1.0 with a few graphics library additions and lots of bugs fixed. >>primitive operations. Unfortunately, the Amiga OS is designed to allow >>multiple applications to share and directly manipulate the hardware. It >Actually, it provides support so most applications do not need to >acess the hardware directly. It does supply a means to get at the >hardware in an OS friendly way should you need to. >>is quite common on the Amiga for an application to bypass the graphics > ^^^^^^^^^^^ you must mean game. No, I mean application. DPaint uses the blitter directly. There are other programs like BLITZ and CygnusEd that use custom drawing routines for fast text that don't rely on the OS. Any application that uses OwnBlitter() or allocates other resources (floppy drives, CIA features, etc.) are likely to break. >>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). > >Hm, Apple developers have only been forced to play by the rules >because of the variety of AppleOS's and hardware in use. > >I suspect the same to happen with the Amiga. If a program has >played by the rules, it will work on a A3000 with 2.0. >Up until the A3000 there really wasn't any different Amiga hardware, >From a programs point of view, the A1000, A500, A2000 are 99% identical. > Even with the 3000, if you don't use the OS, the machines are 100% identical. They all have CHIP RAM at the same addresses (at bootsector time), all have register compatible blitters, copper, CIA timers in the same address locations. This is why 1.3 still works on a 3000. >Some hardware change has already happened. Remeber how many programs >(games and applications alike) broke when people started adding >non-CHIP expansion memory? 1meg chip memory? >HardDrives also caused (and still are) compatibility problems. > >So the lesson is, the more diverse the Amiga hardware in use, the >better quality the software will *have* to be in order to function >on all the machines. This means that programmers will have to >follow the rules in the RKMs more closely. > Programs that follow the rules in the RKMs *exactly* are already having problems with 2.0. For example, 2.0 allows you to change the default screen and window fonts. Try changing to a 15 point font and watch menustrips get screwed up! The whole point of my posting is that there is NO way to maintain compatibility given the direction things have and are going. >Do you have the gam MindWalker? It was written for AmigaDOS 1.0!, and >yet it actually runs on a A3000, not perfectly, but it does not crash. >Whoever wrote that game followed the rules, as well as they where >defined in 1.0 days, and so the program still works many years later. MindWalker was written PRE 1.0. If you know the early history of the Amiga, (not assuming you don't :) the OS radically changed from Beta rev. to Beta rev. breaking all the software that developers were working on. Many developers ignored most of the OS to make their code stable with future Betas. Have you seen Sonix? It was called MusicCraft a long time ago. Have you tried it on an A3000? I haven't, but it is also a program that was developed PRE 1.0, and it pokes the hardware a lot more than the RKMs say you should, or at least violates the suggested methods. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
algoa@eecs.cs.pdx.edu (Gregory Bowers) (05/04/91)
jap@convex.cl.msu.edu (Joe Porkka) writes: >mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >Do you have the gam MindWalker? It was written for AmigaDOS 1.0!, and >yet it actually runs on a A3000, not perfectly, but it does not crash. >Whoever wrote that game followed the rules, as well as they where >defined in 1.0 days, and so the program still works many years later. Just the other day I talked to a guy who used to work for Commodore-Amiga just before the A1000 was released. He mentioned something about Mindwalker (he has designed a few games), and he had something to do with it, so it may be that Commodore-Amiga pushed/helped in the production of the game. My point? If that's the case it had better follow Commodore's rules, eh? Amiga is die beste! 'n IBM is 'n rekenaar? Die Mac is net 'n vrot appel! Pacific Division Champs --- Watch this space for Blazer playoff updates! Portland Trailblazers 2 Seattle SuperSonics 2 ! algoa@eecs.cs.pdx.edu Portland TrailBlazers 63-19 and in the playoffs!
baxter_a@wehi.dn.mu.oz (05/04/91)
In article <2559@pdxgate.UUCP>, algoa@eecs.cs.pdx.edu (Gregory Bowers) writes: > jap@convex.cl.msu.edu (Joe Porkka) writes: > >>mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>Do you have the gam MindWalker? It was written for AmigaDOS 1.0!, and >>yet it actually runs on a A3000, not perfectly, but it does not crash. >>Whoever wrote that game followed the rules, as well as they where >>defined in 1.0 days, and so the program still works many years later. > > Just the other day I talked to a guy who used to work for Commodore-Amiga > just before the A1000 was released. He mentioned something about Mindwalker > (he has designed a few games), and he had something to do with it, so > it may be that Commodore-Amiga pushed/helped in the production of the game. > My point? If that's the case it had better follow Commodore's rules, eh? Of course it would. Just like the first release of AmigaVision did! Regards Alan (and AmigaBASIC, and the VideoToaster, and...)
farrier@Apple.COM (Cary Farrier) (05/04/91)
In article <mykes.2104@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >They don't publish complete hardware manuals, they don't define a specific >video architecture (planar, chunky, bits per pixel, etc.). They specifically Oh they publish complete manuals, but their existence isn't advertised. For example, if you wanted to know how to access the video memory directly on a Mac II, you need to find the right document, and good luck because it's not where you think it would be. The result is the same, however; the information is not easy to come by. >tell you that (and which) specific hardware features are likely to change. >You are right, that you can make software that works for just one specific >display adapter (that goes to the hardware), but it just isn't done. Apple Most programs that need fast screen updating (animations, etc.) go directly to the video memory on _every_ Apple cpu (even Mac). The original MacPaint did this. >has also radically revved their OS several times, while Commodore has only >done it once (2.0). 1.3 is pretty much the same as 1.0 with a few graphics >library additions and lots of bugs fixed. That's true, Commodore-Amiga could be a little more aggressive in terms of system software revisions. >Programs that follow the rules in the RKMs *exactly* are already >having problems with 2.0. For example, 2.0 allows you to change >the default screen and window fonts. Try changing to a 15 point font >and watch menustrips get screwed up! The whole point of my posting is >that there is NO way to maintain compatibility given the direction >things have and are going. Well you can't protect every user from themselves completely. I don't think that is a good example of a compatiblity problem, because it is a user controlled factor. >(Sonix) pokes the hardware a lot more than the RKMs say you should I wasn't aware there was a limit. As far as most developers are concerned, if it is documented then you can use it. Now when people start reverse engineering libraries and figuring out tricks then I just say "Thou has strayed from the narrow 16/32 bit path and shall suffer the eternal torture of revisions and brimstone" :-). -- Cary
markv@kuhub.cc.ukans.edu (05/05/91)
>> As said, GfxBase can use give a proportional font. > The system will not put a proportional font in GfxBase->DefaultFont. > You _can_ count on that being a monospace font, of some size or other. Oops. Peter said what I meant. Such is the effect of typing about 1000 times slower than we think >>One big gripe I have is that GadTools dont support GREL positioning.... > It's a pretty common enhancement request. There were some reasons > why it was tricky, and so it didn't make it in. My general impression of GadTools is that as they stand now they are just plain not happy with things changing underneath them, and that includes position with GREL stuff. Are there any plans for a future release of GadTools using BOOPSI (as mentioned briefly in the DevCon notes), which would help a lot, and potentially make GadTools smaller. Also, since GadTools *doesnt* use BOOPSI, how much *other* 2.0 dependancy is there. Ie: How far would GadTools (and asl.library) be from standing on their own under 1.3. I ask because, as most of us writing software feel, its a major waste of effort to duplicate GadTools functionality (but potential suicide not to support it) for 1.3, yet with Commodore dragging their feet on 2.0 general release, its a tough marketing decision to say "2.0 only". I understand the desire to put out a stable working product, but we're rapidly coming up on a year of 2.0 to the "public" in the form of the 3000s, yet still no firm date on release to the "masses". > Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. P.S. I think I share the opinion of most of us when I say "Hurrah" to the help from and patience of all those various employees of Commodore who take the time to pay attention. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
es1@cunixb.cc.columbia.edu (Ethan Solomita) (05/05/91)
In article <mykes.2104@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > >Programs that follow the rules in the RKMs *exactly* are already >having problems with 2.0. For example, 2.0 allows you to change >the default screen and window fonts. Try changing to a 15 point font >and watch menustrips get screwed up! The whole point of my posting is >that there is NO way to maintain compatibility given the direction >things have and are going. > WRONG. Those programs used NULL for their font rather than specifically specifying Topaz, which they were told to do. Everyone assumed that it would never happen. That was their fault. -- Ethan "Brain! Brain! What is Brain?"
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/06/91)
In article <913.28202b13@vger.nsu.edu> manes@vger.nsu.edu ((Mark D. Manes), Norfolk State University) writes: >In article <mykes.2036@amiga0.SF-Bay.ORG>, 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 <poof>, 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
<DXB132@psuvm.psu.edu> (05/06/91)
In article <dillon.7299@overload.Berkeley.CA.US>, 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. > 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. > 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. > 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. > 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. :-) > * 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
chrisg@cbmvax.commodore.com (Chris Green) (05/06/91)
>>Programs that follow the rules in the RKMs *exactly* are already >>having problems with 2.0. For example, 2.0 allows you to change >>the default screen and window fonts. Try changing to a 15 point font >>and watch menustrips get screwed up! The whole point of my posting is >>that there is NO way to maintain compatibility given the direction >>things have and are going. Commodore gave out a program to change the default system font way back at the Washingotn DC DevCon, and stated that people would have to start writing their software to be font size independent. Many people followed those guidelines, and their programs work great now. Others were lazy. I don't see how you could say that ample warning wasn't given for this. -- *-------------------------------------------*---------------------------* |Chris Green - Graphics Software Engineer - chrisg@commodore.COM f | Commodore-Amiga - uunet!cbmvax!chrisg n |My opinions are my own, and do not - killyouridolssonicdeath o |necessarily represent those of my employer.- itstheendoftheworld r *-------------------------------------------*---------------------------d
ken@cbmvax.commodore.com (Ken Farinsky - CATS) (05/06/91)
In article <1991May4.195340.7179@cunixf.cc.columbia.edu> es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: >In article <mykes.2104@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>having problems with 2.0. For example, 2.0 allows you to change >>the default screen and window fonts. Try changing to a 15 point font >>and watch menustrips get screwed up! The whole point of my posting is >> > WRONG. Those programs used NULL for their font rather >than specifically specifying Topaz, which they were told to do. >Everyone assumed that it would never happen. That was their fault. Well, partly wrong. While an application can set the font for the MenuItems, it cannot set the font for the Menu. That is, items in the top menu must use the screen's title bar font. The 1.3 manual shows how to properly lay-out these items in the current font. The example is available on one of the fish disks. -- -- Ken Farinsky - CATS - (215) 431-9421 - Commodore Business Machines uucp: ken@cbmvax.commodore.com or ...{uunet,rutgers}!cbmvax!ken bix: kfarinsky
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (05/07/91)
forgeas@swinjm.UUCP (Jean-Michel Forgeas) writes: >In article <4766@orbit.cts.com>, Erik Funkenbusch writes: > >> [...] the big problem is still with european programmers not having >> access or not being able to afford proper documentation. > >How CAN you say that ? It is WRONG. In France developers have docs >since 1986. >(I do not say that all developers read it, but this problem is the >same in the entire world :-) I am speaking of most of the PD hacks and things that come from europe that peple like so much. much of them are written by kids in germany that don't know how or can't get ahold of documentation, i am NOT speaking of registered developers. > >> [...] sure, alot of software won't work under 2.0, but these are because > >A lot of software WORK under 2.0. How CAN you say that a lot don't work ? Again, like i said before, a majority of those hacks that people like DON'T work under 2.0, granted alot of them are quite bad and shouldn't be used anyways, but people are fickle > >> | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | > >-- > \___/ >Jean-Michel Forgeas \-/ >cbmvax!cbmehq!cbmfra!swinjm!forgeas | The Software Winery > -^- > And, where is the universe ? .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
es1@cunixb.cc.columbia.edu (Ethan Solomita) (05/07/91)
In article <21276@cbmvax.commodore.com> ken@cbmvax.commodore.com (Ken Farinsky - CATS) writes: >In article <1991May4.195340.7179@cunixf.cc.columbia.edu> es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: >>In article <mykes.2104@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>>having problems with 2.0. For example, 2.0 allows you to change >>>the default screen and window fonts. Try changing to a 15 point font >>>and watch menustrips get screwed up! The whole point of my posting is >>> >> WRONG. Those programs used NULL for their font rather >>than specifically specifying Topaz, which they were told to do. >>Everyone assumed that it would never happen. That was their fault. > >Well, partly wrong. While an application can set the font for the MenuItems, >it cannot set the font for the Menu. That is, items in the top menu >must use the screen's title bar font. The 1.3 manual shows how to properly >lay-out these items in the current font. The example is available on >one of the fish disks. There are 2 choices for programs (at least back in 1.3) open on WB or open on your own. It is true that you can make assumptions about the WB screen if you are using it, but most programs do open their own screen, and so set that font, right? As you said, well, partly wrong. 8-) >-- >-- >Ken Farinsky - CATS - (215) 431-9421 - Commodore Business Machines >uucp: ken@cbmvax.commodore.com or ...{uunet,rutgers}!cbmvax!ken >bix: kfarinsky -- Ethan "Brain! Brain! What is Brain?"
dltaylor@cns.SanDiego.NCR.COM (Dan Taylor) (05/07/91)
My favorite application (sort of) cheat-that-breaks is the goof at Microsoft (the wonderful folks who used a processor-reserved trap as "print screen" in MS-DOS, heh, heh, heh) who used the high byte in the Basic that Commodore supplied with 1.1. Until I tripped over that, I thought that there might be a good programmer working at Microsoft, since the interpreter was fairly usable, and modern. I should have known better. Dan Taylor /* My opinions, not NCR's. */
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (05/07/91)
As quoted from <dillon.7299@overload.Berkeley.CA.US> by dillon@overload.Berkeley.CA.US (Matthew Dillon): +--------------- | 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). +--------------- Actually, the biggest reason is that Apple didn't have multitasking in mind. The bane of MultiFinder is the dreaded "low memory global"... used by many programs because it was all that was available for a long time, and will continue to be used because (a) not all the lmg's have been changed into system calls and (b) many recent OS versions still require ones that are going to be phased out e.g. when System 7 comes out. (...two years late...) Most Mac programs don't do that much direct-to-hardware stuff, because the correct Toolbox calls are generally easier to use and are sufficiently fast. (And the majority of programs that break when a new OS release comes out are (a) games (sound familiar?) and (b) programs developed by companies that keep trying to turn the Mac into an inferior PC (Microsoft and A-T).) Apple's biggest problem is that you have to pay a couple of thousand to get a machine that has something vaguely resembling the features of the A500... and that's an *improvement* on their part. Bleeagh. (Note: Since the beginning of the year I've been toying with the idea of dumping out $1500 to upgrade my Mac SE to an SE/30. Now I'm about halfway toward spending that same amount on an A2000 instead. The other half will come when I can actually play with one and see what it's like "in person". Yeah, so with the SE/30 I'd have a faster processor... with a lot less expansion ability. And Apple's bloody attitude.) ++Brandon (P.S. Hey, C=, if you're willing to consider an upgrade offer from Mac to Amiga, you may have a buyer. :-) -- Me: Brandon S. Allbery Ham: KB8JRR/AA 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
farren@well.sf.ca.us (Mike Farren) (05/07/91)
es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: >mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>Try changing to a 15 point font and watch menustrips get screwed up! > WRONG. Those programs used NULL for their font rather >than specifically specifying Topaz, which they were told to do. >Everyone assumed that it would never happen. That was their >fault. As anyone who ever did a program expecting Topaz 8, and then running on a 60-wide Workbench (Topaz 9) found out quickly. You *still* see this idiocy show up from time to time. The only game of mine that *doesn't* work on 2.0 is Storm Across Europe, and it would appear that that is because I didn't follow the RKMs closely enough. -- Mike Farren farren@well.sf.ca.us
ken@cbmvax.commodore.com (Ken Farinsky - CATS) (05/07/91)
In article <1991May6.203420.12036@cunixf.cc.columbia.edu> es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: > There are 2 choices for programs (at least back in 1.3) >open on WB or open on your own. It is true that you can make >assumptions about the WB screen if you are using it, but most >programs do open their own screen, and so set that font, right? Too many choices, too little time... Yes, if you open your own screen you get to choose the font. I assume that most programs at least have the option of running on the workbench screen or some other public screen. -- -- Ken Farinsky - CATS - (215) 431-9421 - Commodore Business Machines uucp: ken@cbmvax.commodore.com or ...{uunet,rutgers}!cbmvax!ken bix: kfarinsky
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/08/91)
In article <91126.101931DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: >In article <dillon.7299@overload.Berkeley.CA.US>, 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
dltaylor@cns.SanDiego.NCR.COM (Dan Taylor) (05/08/91)
In <91126.101931DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: >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. ONLY hardware-specific programs, which may be zillions :-(, will have to be re-written. Programs that make all system interactions through properly implemented (discounting bugs) LIBRARY calls will still work when the LIBRARIES are device-independent, or are SELECTED at load time, depending on the hardware configuration. This makes the libraries non-trivial to update, but not application code, which is as it should be. We know that printer.device is independent, within its design parameters, which didn't include PostScript. It will not be impossible, but rather, IMHO, highly desirable, for Intuition.library, etc. to have the same level, or more, of device independence. There is a performance hit, for extra layers of indirection, but that could be eliminated by having the OS load "hardware-specific" versions of the libraries, for instance: SYS:libs/Intuition.library.<insert Zorro product code here> whenever Intuition.library was opened. I'm not sure which is better, overall, though, between the extra indirection, and the more-complicated loader. Either beats rewriting applications. I do know that rewriting the libraries, while releasing 2.0, while releasing UNIX, is probably too much for the C= staff. I would hope that some progress toward device-independent libraries would be made by 3.0(?). Dan Taylor
<DXB132@psuvm.psu.edu> (05/08/91)
In article <dillon.7415@overload.Berkeley.CA.US>, dillon@overload.Berkeley.CA.US (Matthew Dillon) says: >>> 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, Um, I meant OS/2 as in IBM OS/2, not Amiga OS 2.0. Relax. :-) -- Dan Babcock
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (05/09/91)
As quoted from <dillon.7415@overload.Berkeley.CA.US> by dillon@overload.Berkeley.CA.US (Matthew Dillon): +--------------- | 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. +--------------- Not to comment on the Amiga, but... in certain other newsgroups, that statement would risk your life: the old Multics hackers would be climbing all over you in an instant.... :-) ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/10/91)
In article <dillon.7415@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >In article <91126.101931DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: >>In article <dillon.7299@overload.Berkeley.CA.US>, 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. * ****************************************************
greg@ccwf.cc.utexas.edu (Greg Harp) (05/11/91)
In article <1991May8.234534.17793@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/AA) writes: >Not to comment on the Amiga, but... in certain other newsgroups, that >statement would risk your life: the old Multics hackers would be climbing all >over you in an instant.... :-) Gosh. There are still living Multics hackers? I thought the last of them had already died off. Those people must be OLD. :) (Hey, I had a kid make me feel old the other day, too. He seemed surprised that I had started out on 8-bit machines... Hehehehe... 'Course I was lucky enough to miss punch cards and other wonderful things like that...) Greg -- Greg Harp |"I was there to match my intellect on national TV, | against a plumber and an architect, both with a PhD." greg@ccwf.cc.utexas.edu| -- "I Lost on Jeopardy," Weird Al Yankovic
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/11/91)
In article <mykes.2432@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >In article <dillon.7415@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >> ... >> 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. Interesting statement, but past experience proves you wrong. I see nothing from Microsoft to justify the money they have spent... nothing from the IBM world at all. So far I see Windows 3.0, which I could easily write from scratch in 6 months by simply ignoring MSDOS compatibility, and OS 2.0 which I could easily write in another 6 months, or less. That's me, alone, writing something of equivalent functionality and power. So why does it take *them* so long and so much money? Commodore does a better job with fewer people in less time because those a *smart* people over there. Microsoft, IBM, and Apple have so much corporate red tape and overhead that what good programmers they have don't get to do much. Apple's the best of the lot but early design decisions show a basic failure in their control structure... somebody wasn't looking ahead far enough, and in the past 4 years they have really bogged down and gotten greedy. Bryce was multitasking PET-BASIC years before the Amiga was even a thought. >>>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. I think you have mixed up my words a bit. Just because the Amiga's OS PROVIDES resource control for direct hardware interface does mean that most programs USE that capability. In fact, very few do. The same goes with the Mac. The original argument that started all of this was somebody mentioning that Apple tries very hard to keep programmers from going to hardware. The original answer was that yes, they try, just as Commodore requests people not to go to hardware, but that doesn't mean that all programs written stay away from the hardware. Some don't, on BOTH machines. The skewing occurs due to the fact that you see many more high performance games available for the Amiga than you do for the Mac, mainly due to the Amiga's capabilities. If you ignore these custom built games for both machines what you see is that almost none of the remaining applications go to hardware -- on both machines. >> 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? OS/9 isn't a bad deal considering its goals, but I like 2.0 better, or a real UNIX (i.e. with firewalls & security which is the only major difference between Amiga OS 2.0 and UNIX). >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). I would disagree with you there ... 2.0 is almost bug free compared to 1.3 . Certainly early alphas and betas of 2.0 were buggy, that is to be expected. But the last 4 or 5 near-release (gammas?) have been almost entirely bug free, an order of magnitude more reliable than 1.3 ever was. >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...). Huh? I was talking about Windows as it is, not as it might have been. Frankly, I think Windows should never have been written and microsoft should have gone ahead and ported BSD or SVR4 to the IBM, but they didn't, and now its too late (?). >>>Why not support any resolution? Hard-coding 768x480 is not any better >>> >>>-- 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 > >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 Then perhaps I misinterpreted his point... I was under the impression that he said the Amiga did not support arbitrary resolutions when, in fact, it does right down to the hardware level. >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). If you want to be compatible with all these applications, you can set your screen and workbench fonts to Topaz 8, or simply open a PUBLIC SCREEN WITH ITS FONT SET TO TOPAZ 8. Poof, instant compatibility. An earlier point I had made was that while many developers, myself included, did not handle fonts correctly, the amount of time required to FIX these problems is minimal... a couple of minutes for me to fix DME. It just isn't a problem. You are looking for new OS revisions that are 100% compatible with previous ones... this is NOT realistic. The whole reason for having a new revision is that somebody thought of something they didn't think of before, and integrating that into an operating system is not always straight forward. Even UNIX isn't 100% compatible with previous versions... When BSD UNIX switched to 'long' file names they broke: (1) all the filesystems ... you had to dump, reformat, and restore (2) 90% of the utility programs (3) Many, Many application programs When people began to map out page 0 to catch NULL pointer indirections they broke a LOT of software. Obviously the software was buggy, it just had never shown up. Who is at fault here? >> 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. Looks like you made some bad choices at applications. Besides, they still work eh? Compatibility is one thing, forcing programs to use new features that didn't exist when they were originally written is something else. You can't honestly expect programs that were written before new features existed to utilitize those new features. After all, the programs you indicate that open hard coded screens still work, eh? >> 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? Yes. Most developers did/do. Actually, my programs open on the workbench screen in general.... take DME for example. Under 1.3 I wrote a program called MWB which worked much like public screens work today... it would force windows to open on custom specifiable screens. This is a much better solution than writing programs that open their own custom screens because in many cases the user wants several programs to run on the same screen for ease of use. >> 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). I give people more credit than that. You can't FORCE a programmer to abide by the new rules, so complaining about his programs doesn't really make any difference to Commodore -- THEY can't do anything about it. Better to complain to the programmer who wrote the program in the first place. -Matt >-- >**************************************************** >* I want games that look like Shadow of the Beast * >* but play like Leisure Suit Larry. * >**************************************************** -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
elg@elgamy.RAIDERNET.COM (Eric Lee Green) (05/12/91)
From article <mykes.2432@amiga0.SF-Bay.ORG>, by mykes@amiga0.SF-Bay.ORG (Mike Schwartz): > In article <dillon.7415@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >> 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 Uh, IBM, Microsoft etc. don't write VGA drivers (except IBM's own VGA driver for the PS/2's with VGA on the motherboard). I suspect that most companies putting out a VGA card have *ONE* programmer on staff. Commodore beats that easily :-). (And we don't know what Commodore's up to, or most people don't, at least, so how do you know how many graphics people Commodore has, anyhow? Far as you know, they could have contracted each and every one of Jez San's programmers to write a killer graphics.library that'd out-perform Starglider II :-). > 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). Just out of curiousity, which bugs are you talking about? In old WB 2.02 or 2.03? In the lastest developer release of Workbench 2.04? If the latter, remember that you're under nondisclosure, and that bugs are one of the things covered (i.e., they don't want developers running around giving the product a bad reputation, at least, not until they've squashed all the bugs, shot the programmers, and burned the ROM's!). And where's the 6 years of work behind AmigaDOS 1.3? As far as I can tell, it's identical to 1.2, except for the Workbench and Extras disks. And 1.2 probably had about the same number of programmer-hours behind it as 2.0... Commodore has staffed up somewhat since the lean days. -- Eric Lee Green (318) 984-1820 P.O. Box 92191 Lafayette, LA 70509 elg@elgamy.RAIDERNET.COM uunet!mjbtn!raider!elgamy!elg
elg@elgamy.RAIDERNET.COM (Eric Lee Green) (05/12/91)
From article <48821@ut-emx.uucp>, by greg@ccwf.cc.utexas.edu (Greg Harp): > In article <1991May8.234534.17793@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/AA) writes: >>Not to comment on the Amiga, but... in certain other newsgroups, that >>statement would risk your life: the old Multics hackers would be climbing all >>over you in an instant.... :-) > > Gosh. There are still living Multics hackers? I thought the last of them > had already died off. Those people must be OLD. :) Not necessarily. For example, as late as 1984, USL had a real live Multics system and a band of fanatics that used it. I suppose those ex-Multicians are now in their 30's, but that's hardly as many years as you credit them with :-). (I encountered Multics, too, but I hardly lay claim to being a "living Multics hacker"... knowing a bit of PL/1, playing with the IPC, and reading a couple of papers hardly qualifies one for that lofty position). -- Eric Lee Green (318) 984-1820 P.O. Box 92191 Lafayette, LA 70509 elg@elgamy.RAIDERNET.COM uunet!mjbtn!raider!elgamy!elg Looking for a job... tips, leads appreciated... inquire within...
allbery@NCoast.ORG (Brandon S. Allbery KF8NH) (05/13/91)
As quoted from <48821@ut-emx.uucp> by greg@ccwf.cc.utexas.edu (Greg Harp): +--------------- | In article <1991May8.234534.17793@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/AA) writes: | >statement would risk your life: the old Multics hackers would be climbing all | >over you in an instant.... :-) | | Gosh. There are still living Multics hackers? I thought the last of them | had already died off. Those people must be OLD. :) +--------------- They're still alive and well and heckling in the Unix newsgroups. 1/2 :-) +--------------- | (Hey, I had a kid make me feel old the other day, too. He seemed surprised | that I had started out on 8-bit machines... Hehehehe... 'Course I was | lucky enough to miss punch cards and other wonderful things like that...) +--------------- Lucky you --- I *didn't* miss out on punched cards. Ugh. ++Brandon (still looking for deals on used C64's so I can PowerUp :-) -- Me: Brandon S. Allbery Ham: KF8NH on 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kf8nh.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KF8NH @ WA8BXN.OH
peterk@cbmger.UUCP (Peter Kittel GERMANY) (05/13/91)
In article <48821@ut-emx.uucp> greg@ccwf.cc.utexas.edu (Greg Harp) writes: > >(Hey, I had a kid make me feel old the other day, too. He seemed surprised >that I had started out on 8-bit machines... Hehehehe... 'Course I was >lucky enough to miss punch cards and other wonderful things like that...) I just imagine how hard it would be to explain someone from today what a 5-channel punched tape really is... -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
s37732v@vipunen.hut.fi (Markus Juhani Aalto) (05/13/91)
>Some hardware change has already happened. Remeber how many programs >(games and applications alike) broke when people started adding >non-CHIP expansion memory? 1meg chip memory? >HardDrives also caused (and still are) compatibility problems. > >So the lesson is, the more diverse the Amiga hardware in use, the >better quality the software will *have* to be in order to function >on all the machines. This means that programmers will have to >follow the rules in the RKMs more closely. > Programs that follow the rules in the RKMs *exactly* are already having problems with 2.0. For example, 2.0 allows you to change the default screen and window fonts. Try changing to a 15 point font and watch menustrips get screwed up! The whole point of my posting is that there is NO way to maintain compatibility given the direction things have and are going. If you do everything right, you can make programs which work in both OS`s (1.3 and 2.0). For example, the program I am writing at the moment checks screens fontsize everytime it goes active. Then I check new values and compare those to old values. If they differ then I know that I have to update menus (, stringgadgets, window titlebars...). It is just little more checking, but it makes your program work in every Amiga OS. -- *********************************************************************** * Markus.Aalto@hut.fi | Only Amiga makes it possible!!!! * * s37732v@vipunen.hut.fi | * * s37732v@puukko.hut.fi | Yeah! It's a sure thing! * * maalto4@otax.hut.fi | :^) * ***********************************************************************
johnhlee@CS.Cornell.EDU (John H. Lee) (05/14/91)
In article <1219@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <48821@ut-emx.uucp> greg@ccwf.cc.utexas.edu (Greg Harp) writes: >> >>(Hey, I had a kid make me feel old the other day, too. He seemed surprised >>that I had started out on 8-bit machines... Hehehehe... 'Course I was >>lucky enough to miss punch cards and other wonderful things like that...) > >I just imagine how hard it would be to explain someone from today what >a 5-channel punched tape really is... Oooh! I used to lust after one of those tape punch/readers, attached to an ASR-33 teletype! I thought they were so neat to listen to and watch. And when you didn't need a tape anymore, it made a great streamer. Lotsa fun at the end of the semester! You know, I think I still have my first program on tape somewhere, written on one of the Lawrence Hall of Science's PDP-11... They don't make 'em like they used to. 3.5" floppies just don't make great streamers. ------------------------------------------------------------------------------- The DiskDoctor threatens the crew! Next time on AmigaDos: The Next Generation. John Lee Internet: johnhlee@cs.cornell.edu The above opinions are those of the user, and not of this machine.
jesup@cbmvax.commodore.com (Randell Jesup) (05/14/91)
In article <dillon.7191@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: > I should mention that a great deal of attention has been paid to making > 2.0 upward compatible, including some specific hacks in 2.0 to support > broken 1.3 programs. "some"... I wish. :-( We spent months (the entire team) doing nothing but. > 99% of the 1.3 software out there will run on 2.0 straight. A slight exaggeration. I'd guess more like 90% of what you'd find at, say, the King of Prussia B. Daltons' Software, including some pretty ancient and horrible games. How would I know that? Should be easy to guess... > This can't be said for Apple when they switched to 6.0, they'd just > like you to *believe* that. What will happen when apple switches to > 7.0 is anyone's guess. If they had 90% they'd be dancing in the aisles. Then again, their developers are used to making updates for every Mac OS release, as they shoot at a moving target... -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
jesup@cbmvax.commodore.com (Randell Jesup) (05/14/91)
In article <00674019691@elgamy.RAIDERNET.COM> elg@elgamy.RAIDERNET.COM (Eric Lee Green) writes: >> Gosh. There are still living Multics hackers? I thought the last of them >> had already died off. Those people must be OLD. :) >For example, as late as 1984, USL had a real live Multics system and a band >of fanatics that used it. I suppose those ex-Multicians are now in their >30's, but that's hardly as many years as you credit them with :-). Actually, you can find a lot of them hanging around Stratus (you know, the people who build hardware-based fault-tolerant systems based on Motorola processors). Stratus VOS (they also have a Unix) is written largely in PL/1 Subset G, as are many applications for it (they finally got a C compiler in '85 or maybe '86). I still have a 2 foot stack of VOS manuals, and a few ideas from it have slipped into AmigaDos (and a few more probably will). One thing I want is the "display form" ability they had in their ReadArgs()- equivalent. BTW, VOS was wordy. You may think AmigaDos commands are wordy compared to Unix. Well, VOS is the same distance further. The equivalent of "cd" was "change_current_directory". No joke. Boy, were aliases useful! -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
ipolyi@alamo.Berkeley.EDU (Harold H. Ipolyi 713-486-6444) (05/15/91)
>I just imagine how hard it would be to explain someone from today what >a 5-channel punched tape really is... or how to read bi-quinary register readouts on an IBM 650. H
kholland@hydra.unm.edu (Kiernan Holland) (05/16/91)
Sometimes I wonder if when I ask a Amiga user a question concerning the problems with something in the OS or something about the obvious problems, or his opinion, or something that is a major concern: (I wonder if ) He is 1. Too insecure to answer it, 2. Doesn't know enough about it, 3. Or too Enthusiastic that he exagerates, 4. Too mad that he cuts me down. Some of you may remember me awhile back poking down on CBM's shoulder about the new deal. (Turn in the VIC 20 anula and get a 3000 16/50 for 1800 dollars) Well,all I have to say is that I didn't mean to say that I was anti-amiga (which anyone on the local BBS's will tell you otherwise) just that I was very mad at CBM Exec's for pulling something like that on me. Now back to Programming: ---------------------- In AREXX part 10-15 of the CBM AMIGA 3000 manual, a small correction: say "Your final grade for this student is...f" is really suppost to be: say "Your final grade for this student is..."f === After taking pascal and many years of Basic, I began looking at this bit of code and said "Can this be, true programming?" This reminds me of the BABY crying program from THE C-64 short manual. Did anyone ever get it to work? === Well, anyways. 2.01 is not as compatible as I would like, but you developers should assume 2.01 before you go off saying things like OH it has to be 99% compatible. Well it isn'there in 2.01 land. And then we have the Bigot's who say "Well if they want to write code that doesn't follow the rules they diserve to die". I know, and exageration right? Well how do you think it sounds to those who poured there time into it. They are probably thinking "You know, if I started writing for Brand X I could really make a ton of money and ace these turkeys, much more I would forget about Amiga's, who needs em" We need all the help we can get, and having a sh*t *ss atitude about it will not improve the situation any. Later
tep@tots.Logicon.COM (Tom Perrine) (05/17/91)
In article <48821@ut-emx.uucp> greg@ccwf.cc.utexas.edu (Greg Harp) writes: >In article <1991May8.234534.17793@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/AA) writes: >>Not to comment on the Amiga, but... in certain other newsgroups, that >>statement would risk your life: the old Multics hackers would be climbing all >>over you in an instant.... :-) > >Gosh. There are still living Multics hackers? I thought the last of them >had already died off. Those people must be OLD. :) > >(Hey, I had a kid make me feel old the other day, too. He seemed surprised >that I had started out on 8-bit machines... Hehehehe... 'Course I was >lucky enough to miss punch cards and other wonderful things like that...) > >Greg > >-- > Greg Harp |"I was there to match my intellect on national TV, > | against a plumber and an architect, both with a PhD." >greg@ccwf.cc.utexas.edu| -- "I Lost on Jeopardy," Weird Al Yankovic Yes, there are still Multics hackers sround. We just couldn't afford the hardware for a home system ($1.5Million+), so we bought UNIX boxes and Amigas instead. I started on Multics in high school, when the Altair 8800 was "the hot box", and the Apple II was brand new, and I'll be 30 RSN, so we're not all that old. The computer industry has just been *that fast*. Repeat after me: every single *neat* thing you can do in an operating system was either already tried, and used, or tried and discarded by Multics developers :-) This does not apply to graphical user interfaces, however. :-( By the way, there was a near revolt at MIT several years ago; the faculty and staff refused to let them pull the plug on the Multics until they had a replacement for "Forum", which is the conferencing system that Usenet dreams of being someday. 0.5 tongue in cheek. Tom Perrine (tep) |Internet: tep@tots.Logicon.COM Logicon - T&TSD | UUCP: sun!suntan!tots!tep P.O. Box 85158 |GENIE: T.PERRINE San Diego CA 92138 |Voice: +1 619 455 1330 "Harried: with preschoolers" | FAX: +1 619 552 0729
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (05/18/91)
In article <1991May16.064342.16138@ariel.unm.edu> kholland@hydra.unm.edu (Kiernan Holland) writes:
Some of you may remember me awhile back poking down on CBM's shoulder about
the new deal. (Turn in the VIC 20 anula and get a 3000 16/50 for 1800
dollars)
Well,all I have to say is that I didn't mean to say that I was anti-amiga
(which anyone on the local BBS's will tell you otherwise)
just that I was very mad at CBM Exec's for pulling something like that
on me.
Ah, so you think CBM shouldn't have sales or price reductions? So, how
many A2000s do you think they'd sell at the initial offering price of
~$1900?
Well, anyways.
2.01 is not as compatible as I would like, but you developers
should assume 2.01 before you go off saying things like
OH it has to be 99% compatible. Well it isn'there in 2.01 land.
No, they should assume 2.03, with a possible fallback to 2.02. If
you're still running 2.01, you're running badly out-of-date software.
You should be able to get 2.03 from your dealer. If you can't, you
should contact CBM about your dealer.
<mike
--
I went down to the hiring fair, Mike Meyer
For to sell my labor. mwm@pa.dec.com
I noticed a maid in the very next row, decwrl!mwm
I hoped she'd be my neighbor.