Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!orion.oac.uci.edu!uci-ics!jarthur!spectre.ccsf.caltech.edu!tybalt.caltech.edu!toddpw From: toddpw@tybalt.caltech.edu (Todd P. Whitesel) Newsgroups: comp.sys.apple Subject: Re: The Apple IIf Message-ID: <1990Feb24.064029.4450@spectre.ccsf.caltech.edu> Date: 24 Feb 90 06:40:29 GMT References: <900222.14492460.054933@UWEC.CP6> Sender: news@spectre.ccsf.caltech.edu Organization: California Institute of Technology Lines: 85 To All: thanks very much for your comments, I am answering them and will be rewriting the paper appropriately, and a heck of a lot more clearly... current plans are to FED EX it to Sculley so that it arrives Monday morning, hopefully before the Apple // Developers Association arrives. With any luck I can get them a copy of the new paper (they should already have the one you read) before monday as well. If any of them read this, please mail me, so I can get it to you electronically. Apple people who are attending the meeting also please mail me. I want to make sure the next paper gets there because it will take into account the most recent MacWeek, and provide a much more focused agenda for Apple's low end, which is hurting real bad and needs action FAST while the market can still forgive. nagendra@bucsf.bu.edu (nagendra mishr) writes: >the iif needs a good internal fan. Seems trivial, but I'd hate to have to >get rid of my kensington and look for another fan and surge system. That was in there, I want a real fan, slow, wide-bladed, and therefore real quiet, and with decent airflow. The //gs was the first real airflow experiment and it didn't work that well. The //cx case is really nice and I think we should use a modified version of it. >Making it a portable would also be nice. give it the a batarry backup rom >disk like the Tandy's. I know the Tandy's really suck, but the idea of DOS >on rom is a good idea. Booting from a rom disk would probably eliminate >needing a second floppy drive. Most of us who will use a //f won't care about portability that much. I think a more ideal portable is a //c+ which uses all static RAM (it only needs four to get 128K, and an expander would be a good option) and runs fast w/out cache because if you use all static rams, you can run around 3.58 Mhz already. Such a machine would be perfect if it then had AppleWorks 3.0 in ROM, in a SIMM or maybe just in sockets so you can burn in new versions as they come out. The portable appleworks could be modified to run out of ROM (this might be hard, i really don't know) but should definately support a stopped clock low power modes which comes back on a keypress. (the 65c02 supports a stopped clock with a STP instruction.) Such a machine would be cheap enough to compete with low end DOS portables, and would probably do very well, especially if the keyboard is quiet enough to take notes on in a small room with one speaker. The Mac Portable's keyboard is too loud for this purpose, which is a real shame because notes-taking is a great use for a portable machine. It's even nicer if you can take Ultima V in the car with you... >Here's an idea. I don't know how it would far in applicativity, but >how about somehow having a configure option on the system disk which you >would let you tell the system exactly what you wanted to have installed in >the system. Once this is done, the system copies the memory image onto >disk. This way, when you boot up, you the system fast loads the memory >image into memory and you're up and running in a very short amount of time. This is a hell of a good idea. I used to do something like this with a RAMdisk image of Appleworks. I wrote the block copy routines myself. Once they make Installer usable (with one 3.5 that is), they should add this. The main slow down with the present O/S is that the cache and file system do not optimize for ProDOS' filing structure. >I read in the specs of the 3.5 diskdrive, that it is capibable of transfering >info at a rate of about 60K per second. I'm not sure about how well the >computer can respond to this kind of speed, but maybe it can be optimized >for faster loading. The peak transfer rate is about 60K, true, but in practice you get much less because of formatting information, GCR encoding (necessary, and more efficient than IBM drives' MFM encoding), and track seeks. <- Major time waster. The fastest Apple 3.5 performance I have seen yet is Photonix disk reads, which take about 25 seconds to read the whole floppy, an average transfer rate of 32K per second. >I don't want any flames, but let's try to be constructive here. If the >guys at Apple want, they can really put out a good functional system. If there are people like you at Apple then there is still hope. >Showing that there is still room for concerete imporvement without much >risk will get them going in bettering our situation. This is what my rewrite is designed solely to do. I'm going to kill most of the speculation and list things much more efficently. I like to read my own writing too much. Todd Whitesel toddpw @ tybalt.caltech.edu