Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!rutgers!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.hardware Subject: Re: Hardware Idiots ? Message-ID: <21889@cbmvax.commodore.com> Date: 24 May 91 16:32:22 GMT References: <1991May22.193016.12202@lynx.CS.ORST.EDU> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 60 In article <1991May22.193016.12202@lynx.CS.ORST.EDU> rudolpe@jacobs.CS.ORST.EDU (Eric Hans Rudolph) writes: >I am programming the game BattleZone for the Amiga. I have the whole thing >written in Lattice C and it is slow, even optimized. With 5 or so tanks on >the screen and n missiles, and full 20 object rotations, it gets bogged >down. Before blaming speed problems on the speed of system functions, check out your code. Would it be fast enough in assembler? Is it actually an algorithm problem -- you can make a bad algorithm go faster by working at it, but it's much better to start with a good one in the first place. >Now if I go in and mess around with hardware registers and blitter stuff, >I will be pretty much machine dependant on some things. I hear tell that the >people who do this are idiots. I don't really see a way around it. I'm probably the one who used the term "idiots", and it certainly doesn't apply to anyone who bangs the bits on these systems. I meant it specifically to apply to the people who go directly to the hardware for absolutely no good reason, other than the fact that they don't like the way the OS does a thing, or they think the Amiga is some big C64. Or they're just plain lazy. Or they worry about what happens when the user is running other tasks, which isn't even rightly their concern. >For the conversion, I am using system calls like AllocMem and AllocRaster, >but as for the blitter line drawing routines, it's all machine register >"poking". Can someone clarify me on what people hate about hardware register >software hacking? Your program won't work on systems without those registers. That's the problem. System software like graphics.library is here specifically to isolate the program from the underlying hardware. You can do blits and other hardware related functions via function calls. Those functions guarantee a couple of things. They assure that the blitter gets called properly, that unused bits don't get clobbered, and that, even if the blitter were to vanish (the A2410 board, for instance, doesn't have an Amiga blitter) your program might still work when retargetable graphics comes along. Or some future Amiga chipset that has a few minor but important differences you couldn't forsee when you wrote your code. You also have to realize that Commodore can't just say "they break" to programs that go to the hardware, if there are too many. The software base has to be supported as much as possible. If too many people break the rules, those rules sometimes have to change to accomodate these lawbreakers. That's the one reason 2.0 ROMs aren't out yet. If a significant percentage of the software base puts strong restrictions on the Amiga's hardware memory map, then that may have to be painfully preserved in the future. That may mean MONTHS of extra testing and possible redesigned to take into account things that are acting in a way Commodore has warned against. Sure, it's Commodore's right to break these things, but market realities limit the percentage of software you can get away with breaking. Bottom line is, if everyone goes to the hardware and does other nasty things, we have to ensure compatibility at the hardware level out of market pressures. That WILL delay future hardware, and may also cripple that hardware in some ways. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.