Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.programmer Subject: Re: Mike Farren Tutorial. Message-ID: Date: 30 Mar 91 19:23:11 GMT References: <20115@cbmvax.commodore.com> <1991Mar27.012717.11541@starnet.uucp> <1998@aldebaran.cs.nps.navy.mil> <1991Mar27.175514.25590@cunixf.cc.columbia.edu> <20198@cbmvax.commodore.com> Organization: Not an Organization Lines: 73 In article <20198@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>I have been lobbying Commodore to solve the problem. The problem is not with >>the developers, but with the OS. What I suggest CBM does is to provide entry >>points in Exec for software that takes over the machine to access both the >>floppy drives and the hard disks. It is easy enough for them to do for 2.0 >>before it goes to ROM. This whole argument is dumb. You can EASILY write games that run under the OS. What do you do? you simply lockout intuition, setting the input.device priority to -60 will do the trick nicely. Suddenly, the OS isn't using jack of the CPU and your game can set up its own screens via the graphics.library and manipulate screens directly, even use the blitter, copper, and other OS resources. graphics.library is still fully available. The nice thing about the above method is that you can still use intuition if you need to, for initial setup for example... to open up the screen and set up the initial layers (if you intend to use layers). But during game play the whole business gets 0 cpu. > "easily"???? Their drivers depend HEAVILY on the system being >fully up and available. For example, an A590 with SCSI and IDE(xt) drives >has 3 tasks running, passing messages back and forth. Rewriting that >to not use exec would require taking one of our (few, and VERY busy) >programmers and having him devote 3-6 months to it (plus QA time, etc). >You think every 3rd-party is going to spend that sort of money? ($20-50,000, >depending on overhead, programmer experience, how long it takes.) > > And we haven't even discussed filesystems. being able to read/write >the disk doesn't help, you need to read/write files on the disk. This means >we'd have to rewrite the filesystem to work in this funny mode. This might >be completed in 3-6 months (assuming we had a spare programmer (the current >FS programmer is busy with another long-term project), but would require a >LOT of QA time, and would require 15-25K of rom. We're tight enough that we >fight for 1K. > > Just because you ask for it doesn't mean it feasible, practical or >sensible. The amiga does have an OS, and as the line changes over the coming >years, using the OS will help insulate you from hardware changes. It is not >a game machine - if it was, there'd be no rom, no disk drive (cartridge), and >maybe no keyboard. It's a computer that happens to also be able to run >really good games. We won't cripple our future and hamstring our OS just >for games that take over the machine. > >-- >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup >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") ;-) I agree with Randell completely, all these idiot game writers insist on taking over the machine when, in fact, they do not have to. My solution alone (simply reduce the task priority of CPU hogging tasks) guarentees a game the CPU when it needs it, yet still allows said game to use DOS & intuition when/if it needs to. It just isn't a problem. This goes down with idiots who make direct ROM calls, assume absolute RAM locations (other than 4), and design hardware without using bypass capacitors :-) -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA