Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!rex!rouge!ralph!elgamy!elg From: elg@elgamy.RAIDERNET.COM (Eric Lee Green) Newsgroups: comp.sys.amiga.programmer Subject: Re: Lemmings - a tutorial Part V (last) Message-ID: <00670212662@elgamy.RAIDERNET.COM> Date: 29 Mar 91 02:11:02 GMT References: <23788@well.sf.ca.us> <23837@well.sf.ca.us> Organization: Eric's Amiga 2000 @ Home Lines: 108 From article , by mykes@sega0.SF-Bay.ORG (Mike Schwartz): > In article <23837@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: > The Amiga operating system is not a high performance video game operating > system. BOBs are slower than what I use. Intuition takes 30% of the CPU First of all, I've never used a BOB in my entire life. When I needed high performance graphics, I did what any self-respecting Amiga programmer does -- I opened myself up my very own screen with its very own bitmap, and went straight to the hardware. Totally system legal. ObtainBlitter() and such. Of course, doing a hi-res structured drawing program is a bit different from doing a video game... most folks wouldn't try to run a drawing program on a 512K Amiga with 1 floppy. > unnecessary and way too slow. Exec tasks require a minimum of 2K of stack > each, while any game I ever do needs only 512 bytes of stack for 80 tasks > under my own kernel. Hmm. Matt Dillon has done some work on how much stack an Exec task requires. Basically, Exec tasks require a) enough stack to save the processor state, and b) enough stack to satisfy your program's need for stack. 1K stack is fine for all Amiga machines. On a 68000, 512 bytes of stack quite suffices for Exec (since a 68000 doesn't store mega-bunches of state on the stack when it recieves an interrupt). > You mention in your lecture/article stream that the OS steals 80K of > RAM (that is almost 20% of what you get on a 512K machine). Even if I > don't need that 80K for the game, I can always find something useful > to do with it (like adding instrument samples for the music driver). This is the only valid argument in your article. But why not give a choice? How about grab all the memory you can grab from the system, shut down the system in an Amiga-friendly manner (i.e., as published by Commodore in their DevCon notes), then if there STILL isn't enough memory (i.e., only 512K in the machine, *THEN* hose that remaining 80K of RAM? That is, on expanded machines the OS could be re-started when the game was suspended or etc., while only on 512K machines would you have to give up everything. > The ROM Kernel routines have many many bugs in them that you end up > programming your way around. It is not lazy to want to avoid the Huh? You don't use many ROM Kernel routines if you're doing high performance graphics on the Amiga. Basically, you go straight to the hardware. Period. But there's Amiga-friendly ways to do that. (Though those ways may not suffice for a fast-action game on a 512K Amiga). > The only thing that the OS gets for you is the ability to use hard > disks. If commodore were smart, they would make ROM routines > accessable for video games to access the hard disk when the OS is not > running. This is really what the machine needs. I'm aghast. Device drivers run as Exec tasks. They *CAN'T* be put into stand-alone ROM routines. Most device drivers rely upon having the Amiga interrupt handler structure intact, rely upon sending messages from interrupt handler to device driver, rely upon a myriad of other features of the Amiga operating system (features that you've apparently never used, but...). They simply CAN'T operate when the operating system is hosed. At least, not as they are supplied by the major hard drive controller manufacturers. If you really want, go talk to the major hard drive controller manufacturers about creating a "standard" for direct access. They're the ones responsible for providing drivers for their hard drives. Their currently supplied Exec drivers are obviously impossible, if you've nuked the machine. > Most people who program the Amiga don't have the ability (or gumption) > to write in assembler language. These are the people who I would Hmm... that's an interesting allegation. I know that I'm fairly decent in 68000 assembler (started out with Z-80's and 6502's, quite a while ago), but still prefer to mostly program in "C". Actual graphics routines that draw into the bitmap must, of course, be in assembler in any real product (I've seen some "productivity software" where I'd swear that they'd written their user interface code in interpretive BASIC, though... sigh). > call lazy. Most people who program the Amiga don't have the ability > to write their own native operating systems that outperform the ROM > Kernel, so for them the OS is the only choice. In my case, I write Hmm. I could easily write my own multitasking kernal. I've never had the need to, but I could do it. Old hat. I could even make it faster than Commodore's, by stripping out every feature not essential to my project, things like the windowing environment, generalized prioritized task queues (OS has to look at all those priority #'s to decide how to schedule things), etc. Of course, the resulting OS would be useless as a general computing environment. It's hard to find a microcomputer OS better than the Amiga's OS for a general computing environment. > Have you ever taken over the Amiga? I bet if you did, you'd change > your tune. I on the other hand have done things both ways (using the > OS and taking over), and the power you gain by taking over more than > offsets the capability to multitask your game with other programs. I'm not a games programmer, thankfully. Probably never will be, since I do not like arcade-style games and thus would be a lousy programmer of such (it is difficult to do good work in a field that you don't like, and I like doing good work). I've "taken over" other machines, and may soon be working on microprocessor-based RTU's (remote telemetry units) for the oilfield, so I'm well aquainted with low-level programming. But the Amiga's OS is one of the few things differentiating it from "mere" game machines, and it strikes me that tossing it aside is a Bad Idea if it is in any way avoidable. -- 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...