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: Mike Farren Tutorial. Message-ID: <00670283123@elgamy.RAIDERNET.COM> Date: 29 Mar 91 21:45:23 GMT References: <20115@cbmvax.commodore.com> <1991Mar27.012717.11541@starnet.uucp> <1998@aldebaran.cs.nps.navy.mil> <1991Mar27.175514.25590@cunixf.cc.columbia.edu> Organization: Eric's Amiga 2000 @ Home Lines: 48 From article , by mykes@amiga0.SF-Bay.ORG (Mike Schwartz): > 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. Except that everybody's hard disk device drivers require that Exec be up and running. They simply WILL NOT WORK unless Exec is up and running, because they depend on the interrupt system, the message passing system and the ability to run as a separate task. > The problem with hard disk support is that it REQUIRES the OS. Since all hard > disk controllers have ROM on them, the controllers could easily provide the software > routines needed to directly access the hard disk. Commodore should provide routines > in Exec that allow AmigaDos access to the hard disk through this mechanism. Single Excuse me, but this shows extreme ignorance of how the internals of the OS work. The actual dos.library was designed around the message-passing system... calls like Read() and Write() do not actually exist, all that happens is that the dos.library wraps up the request into a message packet and ships it off to the appropriate filesystem handler for the device in question. IT CANNOT WORK IF EXEC IS BOMBED!!! Period! The design of dos.library and the filesystem handlers is built around the message passing system, and you'd have to re-write them from scratch to make them work in a single-tasking non-Exec mode. It's like taking a Toyota Van, and trying to modify it to be a Toyota MR-2 sports car... you simply cannot do it. The beasts are too different. You'd have to re-do it from scratch (like Toyota did). So far, we've established that a) you don't know how AmigaDOS works, b) you haven't read the DevCon notes, especially the ones on how to hose the system such that it'd be recoverable, c)... do you even own a copy of the Rom Kernal manuals? You may be a great games programmer, but I get the impression that you don't know a whole lot about the Amiga's OS besides how to hose it. Times when you've said things like, "Exec needs 2K stacks minimum per task" are perfect proof of that... Exec *DOES* need more stack than your program needs for its own purposes, but that's only because when task switch time comes around your task's registers, 68010/68020 processor state, etc., are shoved onto the local stack. That data has to be stored *SOMEWHERE*, and if it's not stored onto the stack, it'll have to be stored in the task control structure somewhere. And 2K is a gross overestimate. -- 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...