Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!rphroy!caen!hellgate.utah.edu!csn!ub!dsinc!bagate!cbmvax!jesup From: jesup@cbmvax.commodore.com (Randell Jesup) Newsgroups: comp.sys.amiga.programmer Subject: Re: Mike Farren Tutorial. Message-ID: <20214@cbmvax.commodore.com> Date: 31 Mar 91 07:27:12 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> Reply-To: jesup@cbmvax.commodore.com (Randell Jesup) Organization: Commodore, West Chester, PA Lines: 151 In article mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >In article <20198@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >> "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.) > >I programmed a custom 68000 box with a SCSI interface on it. The interface >is trivial to write a driver for. Not "trivial" if you want to handle all the tricky edge-cases (like the reselection issues, where what the chip does varies by chip rev, and the state of the chip is undefined). > All the manufacturers need to provide is >the abililty for the proposed new ROM routines to read/write sectors. It doesn't >require multitaskin or any OS to read/write sectors from the hard disk. Yes, >GVP and other manufacturers are going to have to put extra code in their ROMs >to support this simplistic form of access. My GVP manual describes all of the >routines that their harddisk.device provides. All they need to do is to make >the lowest level routines of that device public. You are exaggerating the >requirements. At some point in every disk device (floppy or hard disk) you >have to read and write sectors. This is the only capability that is needed. Sure. And they all need interrupt handlers, and are often coded to require memory allocations, multiple tasks (the A590/A2091/A3000 driver consists of 2 or 3 tasks (depending)), lots of exec functions, etc. They would have to rewrite their driver (not from scratch, but it would require an engineer for several months at a guess to get it done, tested, and stable). Then there's QA issues, and field upgrades, etc. >> 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. > >You published source code in 'C' in AmigaMail that parses AmigaDos sectors on >disk. It did not look like 25K of code. You are going to need the "takeover" >programs to provide you with RAM buffer addresses to read the sectors into. >If worse came to worse, I would be happy to call a routine in the ROM that would >decompress the appropriate routines into RAM somewhere. You can save space that >way. Parsing sectors on disk is nothing like what a filesystem does. You aren't listening to what I'm saying. (And I was being optimistic on the time required.) >By the way, how much of the ROM is still in 'C'? If it weren't in 'C', you would >save lots of K. Maybe 60% (rough guess). So, you magically can provide an extra 10 top-notch programmers 2-3 years ago, plus another 10 or 20 QA people a year or two ago? Sure, some stuff gets downcoded when we need the space or speed. Most of the low-level stuff has been in ASM since the beginning. Yes, there's space we could get back. In places where it makes sense, we do. Remember, we have to maintain this code (unlike most game code, which is mainly write- once - often even sequels are 100% new code). For example, most of intuition and almost all of gadtools is in C. This will be VERY useful when 2.2 or 3.0 or whatever comes along. Also, every time the compilers get better we benefit. 5.10a saved us many K over greenhills in 2.0 (some things are still in greenhills, like intuition, because the risk and time in moving it over was greater than the benefit). >> Said single-tasking computers either don't have an OS, only a program >>loader (MSDOS), so it's already done, or they only support one filesystem >>and one drive interface (Mac) - and do people really take over the Mac and >>then access the harddrives? I assume the ST is similar to one or both of >>those. > >Atari publishes all the technical information required to access their hard disks >through their DMA controller (which is built in to every ST). 1) ST is single-tasking, 2) there is only 1 (normal) interface, as is expected in an unexpandable machine. It hits both my points. >Single tasking computers (i.e. PCs) support a wide variety of hard disks/controllers >with little effort. All we need is the ability to OPEN/READ/WRITE/CLOSE files >on hard disk. We don't need multiple tasks to be able to access the files at >the same time. We don't need Locks. You don't need DosPackets or any of the >rest of the "junk" that the OS demands (and rightly so). Here is a simple >explanation of the process of using hard disk without the OS: The more "junk" you throw out the bigger the job of writing a single- tasking FS is. The PC clones support HDs via drivers that emulate old st506 drive controllers. The routines are callable in "take-over" games since there is no such thing on the PC as NOT taking over. MSDOS is a program- loader, not an OS. >5) I can then call Open() to open an AmigaDos file (who cares about other > file systems). I will tell your routines where the controller's ROM > routines are located (I saved them before I took over). I care. More and more users will care. Note that we now support booting off ANY fifesystem (via rigid disk blocks). You can boot off an MSDOS filesystem if you want, of a Unix Berkeley FFS, or a Sys V UFS, etc, etc. You can even boot off a network filesystem (certainly you might want to save your high score on the server so everyone can have a common high-score file - I do this now in NetHack.) >Compare the A500 with the lowest-end Mac. The classic has the ability to run >a significant part of the business applications (it has 1Meg of RAM and separate >memory for screen). Oh boy, 21888 whole bytes. (And last I checked in the Apple docs, the screen memory comes out of your 1Meg.) And of course an a500 can have 1Meg EASILY, and CHEAPLY. Plus a 500 can be expanded (again, easily) to do most (though not quite all) things that higher-end amigas can do. Have you ever programmed games on a Mac? They're far more picky about people trying to take over machines than we are. >I submit that you won't be crippling your OS by adding the additional functionality >of hard disk access. You will only be making all these screamers on the net >happy because software written for the A500 will support more features of the >(far fewer) workstation class machines. I don't see how this suggestion cripple's >your future or Hamstring your OS. I see little added engineering cost involved >for you and your 3rd party hard disk manufacturers. If we added everything you want (and it's NOT by any means cheap - we could be talking many hundreds of thousands of dollars, and even then would only be available on machines with whatever the new version of the rom was) we'd be stuck trying to find ways to upgrade the hardware/software a bit down the road. It's bad enough as it is, this would make it much worse. Oh, and please tell us which part of the OS we should remove to fit your stuff in. One of the purposes of an OS is to insulate you from hardware differences. This is the sort of thing that killed the 64. There was NO way to upgrade the hardware without breaking 99% of the programs out there. You can't even change a byte or two in the rom safely. I've had enough. You're obviously interested in pure game machines, which the Amiga is not. Perhaps we'll build a pure game machine again someday (like the 64) where you can hack around to your hearts content. But it won't be an Amiga. Even CDTV has the ability to upgrade the hardware, and if you go around the back of the OS and program around the rules of accessing the hardware, you may well find yourself in trouble there too. The hardware can change, the software can change (it has flash-eproms). If you want to ask programming questions, fine. If you want to spout off about how wonderful taking over the machine is, do it elsewhere. -- 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") ;-)