S707503@UWEC.BITNET (MARK RINECK) (02/23/90)
Umm...some of the things mentioned in that paper sound an awful lot like something close to a MacIntosh. Of course, there are some Amiga-like things in there, too. (the DMA and co-processor/blitter ideas) I would find it hard to blend any of the Amiga's screwy architecture into a new GS...the new GS mentioned is something like a Macintosh that is 8/16 bit based instead of 16/32 bit. I like all the ideas presented, but how about compatibility with ROM 1-3 (even though even ROM 1,2 and 3 aren't exactly perfectly compatible!)? Some things that might have been missed: Math Co-processor: How about a math co-processor to go along with the 65816? A 65716 (or some other great number...that number is fictional.)? This follows the co-processor/Amiga style. How about a multiple-format 3.5" drive? (This is pretty far-fetched.) A drive that can read/write Unidisk, GS, Mac and FDHD formats...and why not throw in MS-DOS, too...maybe a semi-intelligent drive/controller in the style of the old Commodore 1541 drives...but not that slow. Other than that, I like it. Now, if Commodore/Amiga would just give the 500/2000 some nice GS/Mac styling... Markie S707503@UWEC.BITNET University of Wisconsin-Eau Claire Mark Rineck
UN027265@WVNVAXA.WVNET.EDU (Eric Krichbaum) (02/23/90)
Re: your comment on coprocessors, there are several available for the GS.
The 68882 FPE (Floating Point Excellerator) is a good choice and I believe
that I have heard of one called FastMath.
Tidbits of information,
Eric
* The palindrom of BOLTON is NOTLOB... Monty Python (The Parrot Sketch) *
* Reality Sucks. Robin Williams *
* I think the problem was that there was a Stonehenge momument on stage... *
* in danger of being crushed by a dwarf. You figure it out. *nagendra@bucsf.bu.edu (nagendra mishr) (02/24/90)
One thing I think you are all forgeting 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. 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. 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. 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. 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. Showing that there is still room for concerete imporvement without much risk will get them going in bettering our situation. nagendra
wilken@plains.UUCP (Scott Wilken) (02/24/90)
In article <9002230158.AA00638@apple.com> UN027265@WVNVAXA.WVNET.EDU (Eric Krichbaum) writes: >Re: your comment on coprocessors, there are several available for the GS. > >The 68882 FPE (Floating Point Excellerator) is a good choice and I believe >that I have heard of one called FastMath. You mean Floating Point Engine. I think you were just misspelling accellerator :) (SARCASM: No Flames please....) At any rate, now you have the correct name of the device if you decide to purchase it in the future.. Scott -- Internet: wilken@plains.nodak.edu America Online: Wilken UUCP: ..!uunet!plains!wilken GEnie: S.WILKEN1 BITNET: WILKEN@PLAINS Delphi: SWilken
cs122aw@ux1.cso.uiuc.edu (Scott Alfter) (02/24/90)
In article <NAGENDRA.90Feb23124032@bucsf.bu.edu> nagendra@bucsf.bu.edu (nagendra mishr) writes: >One thing I think you are all forgeting > >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. Indeed. I don't know about the GS, as far as heat buildup goes, but I have a IIe on the way to becoming "optioned out," with five of eight slots filled. Things were getting a bit toasty in the case, so I decided to stick a fan under the keyboard, where it can blow air out through the bottom of the case. I'd imagine that the increased circuit complexity of a "IIf" would generate enough heat without any cards installed that a fan would become a "must." >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. > >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. Here's an idea for getting the system disk into memory: make an EEPROMdisk. The hardware (basically an EPROM burner, with extra circuits for erasing EEPROMs and selecting between the several EEPROM chips) could be built into the computer easily enough. When you figure out how you want your system set up, push a button and you burn a system disk into the EEPROMs. If you change your mind (or get a new system, as happens semi-frequently with Apple), push another button to erase the EEPROMs and start over again. EEPROMs have several points in their favor: they don't require continuous power like SRAMs, and they can be erased electrically, instead of by using ultraviolet radiation as with ordinary EPROMs. Scott Alfter------------------------------------------------------------------- Internet: cs122aw@ux1.cso.uiuc.edu _/_ Apple II: the power to be your best! alfter@mrcnext.cso.uiuc.edu/ v \ saa33413@uxa.cso.uiuc.edu ( ( A keyboard--how quaint! Bitnet: free0066@uiucvmd.bitnet \_^_/ --M. Scott, STIV
dcw@lcs.mit.edu (David C. Whitney) (02/24/90)
In article <NAGENDRA.90Feb23124032@bucsf.bu.edu> nagendra@bucsf.bu.edu (nagendra mishr) writes: >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 actually not a new idea. Symbolics Lisp Machines have a feature where one loads all the systems he wants into memory, configures things as he likes and then saves the virtual memory in a world-load file. The next time you boot, everything is exactly as you left it. It consumes disk space like you can't imagine, and getting things set up just right is a pain. It DOES save a lot of boot time if you have to load 18 different systems... I used a similar method when creating a package for the // some years ago. I used RWTS to save all of memory out to the disk and then twiddled the DOS loader to load in oodles of pages instead of just the 9 or 10 needed for DOS 3.3. It loads up mighty fast. Most automatic software crackers (such as the Copy Master II or Wildcard) do this as well. You push the button and then insert a blank disk. It saves all the memory and the current PC to the disk. You boot the disk and it starts up right where you pushed the button. (whew!) -- Dave Whitney dcw@sun-bear.lcs.mit.edu ...!mit-eddie!sun-bear!dcw dcw@athena.mit.edu My employer pays me well. This, however, does not mean he agrees with me. I wrote Z-Link & BinSCII. Send me bug reports. I use a //GS. Send me Tech Info.
UN027265@WVNVAXA.WVNET.EDU (Eric Krichbaum) (02/24/90)
Thanks for the sarcasm scott.
I stand corrected.
Humbly,
Ericdcw@lcs.mit.edu (David C. Whitney) (02/24/90)
In article <1990Feb23.190539.18534@ux1.cso.uiuc.edu> cs122aw@ux1.cso.uiuc.edu (Scott Alfter) writes: >EEPROMs have several >points in their favor: they don't require continuous power like SRAMs, and >they can be erased electrically, instead of by using ultraviolet radiation as >with ordinary EPROMs. > They have a big lose - they have a small finite lifetime. About 100-200 burnings. They are also quite slow. Much slower than RAMs or ROMs. The only thing you want in EEPROM are small strings that won't change very often (like, uh, um, the name of a laserwriter? Yeah!). -- Dave Whitney dcw@sun-bear.lcs.mit.edu ...!mit-eddie!sun-bear!dcw dcw@athena.mit.edu My employer pays me well. This, however, does not mean he agrees with me. I wrote Z-Link & BinSCII. Send me bug reports. I use a //GS. Send me Tech Info.
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (02/24/90)
S707503@UWEC.BITNET (MARK RINECK) writes: >Umm...some of the things mentioned in that paper sound an awful lot like >something close to a MacIntosh. Of course, there are some Amiga-like >things in there, too. (the DMA and co-processor/blitter ideas) I would DMA and coproc/blitter are good ideas in any computer, and they are extremely cheap to do once you have the custom chip capability that Apple has. >find it hard to blend any of the Amiga's screwy architecture into a >new GS...the new GS mentioned is something like a Macintosh that is >8/16 bit based instead of 16/32 bit. I like all the ideas presented, The original Amiga architecture (pre-2000) was pretty durn clean, you had chip ram which was like the //gs standard RAM except the Amiga guys handled it much better. The //gs is largely a //e on steroids because of the Mega //, which is an overrated and inappropriate compatibility box. It takes a good amount of schematic knowhow (and not just a little inside info) to figure out why this is true, but I can prove it with an oscilloscope and a few hours. >but how about compatibility with ROM 1-3 (even though even ROM 1,2 and >3 aren't exactly perfectly compatible!)? That's no problem, Since the firmware, BASIC, and monitor take up little space next to the toolbox, which will of course also be there. This machine could be called the //gs+ or ROM 4 or something, but I think a completely new (and much better!) custom chip set (that's what really makes the machine, along with the internal peripherals) deserves its own letter. I chose F to stand for Fast, Fixed, Flexible, and (hopefully) Future. Before anyone worries, this new machine would be very //gs compatibile, because the //gs architecture itself is still really simple (hey, it's an Apple //) and it is only the implementation working around the Mega // that produces all this redundancy and extra logic. >Math Co-processor: How about a math co-processor to go along with the >65816? A 65716 (or some other great number...that number is fictional.)? >This follows the co-processor/Amiga style. Have nothing against the idea. Except no such coprocessor exists yet, and WDC plans to put a RISC FPU on chip when they make the 65832. If they make it. About the only way the 65832 will ever see daylight is if Apple says, "we'd like to buy it" and signs a contract with them. The chip's features look really promising if Mensch can design it the way he wants to. But until then, we have the Floating Point Engine (standard slot 68881/2 card). >How about a multiple-format 3.5" drive? (This is pretty far-fetched.) >A drive that can read/write Unidisk, GS, Mac and FDHD formats...and why >not throw in MS-DOS, too...maybe a semi-intelligent drive/controller >in the style of the old Commodore 1541 drives...but not that slow. The FDHD already reads every 3.5 format that holds 1 Mb and under. A disk controller for the present //gs Disk Port exists, it was developed for the Apple //c+, and will probably go into the next Mac as well. Bravo to Apple for much a much needed floppy coprocessor. >Other than that, I like it. Now, if Commodore/Amiga would just give the >500/2000 some nice GS/Mac styling... No comment :) Todd Whitesel toddpw @ tybalt.caltech.edu
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (02/24/90)
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
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (02/24/90)
cs122aw@ux1.cso.uiuc.edu (Scott Alfter) writes: >imagine that the increased circuit complexity of a "IIf" would generate enough >heat without any cards installed that a fan would become a "must." Well, most of the complexity would be in the chip set, and those run pretty cool from what I hear, except at high frequencies, which we will have to deal with. A built in fan is a simple must these days, period. I figure that a fan sucking in the front, over the motherboard and between the slots, and out the back would do just fine. That's almost a direct quote from the //f paper; did you read it real late or just skim it or something? Or my prose just sucks for clarity. (I can believe that.) >Here's an idea for getting the system disk into memory: make an EEPROMdisk. I said almost that. EEPROMS are nice, but they are too darned expensive to make a system disk out of. You can buy 128K EPROMs for $20 apiece from JameCo, so a 1 meg boot disk would take eight chips or ~$160. Use one 2864 EEPROM as your directory blocks and pointers to overwritten stuff, and treat the thing like a WORM disk. Writing files should be done by a special installer that takes care of figuring out which blocks have been overwritten and alerting the ROM disk driver to it. 12V EPROMs are much more common and can be programmed by using a simple transistor switch to the +12V supply. When you have exhausted your free space, you will probably just back up to floppy and then erase them all. More sophisiticated things could be done but that's for third parties. There should be two ROM slots, one for Bank $Fx ROM, maybe an official ROM SIMM from Apple, and another for the EPROM disk. All the address/data latches and counters (this is a slinky type remember) could go on card, they are just PALs anyway. This way the card is a cheap as it can be, and the motherboard is still pretty cheap with the extra cost kept to the slot and all its wires plus a few chip selects. Todd Whitesel toddpw @ tybalt.caltech.edu
throoph@jacobs.CS.ORST.EDU (Henry Throop) (02/24/90)
In article <1990Feb23.190539.18534@ux1.cso.uiuc.edu> cs122aw@ux1.cso.uiuc.edu (Scott Alfter) writes: <In article <NAGENDRA.90Feb23124032@bucsf.bu.edu> nagendra@bucsf.bu.edu (nagendra mishr) writes: < <>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. < You can do this yourself if you have 2MB or so of RAM by putting the system on the RAM disk and then using Copy II+ (v 7.1 and previous) or another program to copy the RAM disk image to a floppy. Restore this, boot from teh RAM disk, and you may have saved yourself a second or two off booting the floppy directly. >Here's an idea for getting the system disk into memory: make an EEPROMdisk. [...] >another button to erase the EEPROMs and start over again. EEPROMs have several >points in their favor: they don't require continuous power like SRAMs, and >they can be erased electrically, instead of by using ultraviolet radiation as >with ordinary EPROMs. Yes, but they also have several points against them; namely - cost and availibility. Last time I checked, there was only one place I found that had 28256's (32k x 8, I think?), and it would have cost about $600 for four of them (128K) to put on my AST Ramstak+. I _think_ they're pretty slow, too - 200 ns or so. >Scott Alfter------------------------------------------------------------------- Henry --- Henry Throop Internet: throoph@jacobs.cs.orst.edu
dlyons@Apple.COM (David A. Lyons) (02/25/90)
In article <16217@orstcs.CS.ORST.EDU> throoph@jacobs.CS.ORST.EDU.UUCP (Henry Throop) writes: [somebody else suggests taking a snapshot of all important areas of RAM & later restoring them, as a means of booting the system quickly] >You can do this yourself if you have 2MB or so of RAM by putting the system >on the RAM disk and then using Copy II+ (v 7.1 and previous) or another >program to copy the RAM disk image to a floppy. Restore this, boot from >teh RAM disk, and you may have saved yourself a second or two off booting >the floppy directly. I don't think that's what the original poster was suggesting. If you boot from a RAM disk you still go through a normal boot, with lots of pieces of the system being processed by the Loader to whatever addresses are available when the system asks the memory manager for some memory, etc. That's very different from loaing memory from a snapshot, skipping all that processing that got the stuff there originally. 'course, there would be other problems: you can only load that image on a system with identical hardware, and you need to have a way to get all the hardware back in a state identical to what it was when the snapshot was taken. -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II Developer Technical Support | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
bh@pro-lep.cts.com (Brian Hicks) (02/25/90)
In-Reply-To: message from throoph@jacobs.CS.ORST.EDU >>points in their favor: they don't require continuous power like SRAMs, and >>they can be erased electrically, instead of by using ultraviolet radiation as >>with ordinary EPROMs. >Yes, but they also have several points against them; namely - cost and >availibility. Last time I checked, there was only one place I found that >had 28256's (32k x 8, I think?), and it would have cost about $600 for four >of them (128K) to put on my AST Ramstak+. I _think_ they're pretty slow, too >200 ns or so. Are you guys talking about Flash RAM? I hear that the IBM world is starting to use these and was wondering if you knew anything about it. Thanx. bh _____ UUCP: crash!pro-lep!bh ARPA: crash!pro-lep!bh@nosc.mil INET: bh@pro-lep.cts.com
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (02/27/90)
[ somebody wrote, about EEPROMS ] >>Yes, but they also have several points against them; namely - cost and >>availibility. Last time I checked, there was only one place I found that >>had 28256's (32k x 8, I think?), and it would have cost about $600 for four >>of them (128K) to put on my AST Ramstak+. I _think_ they're pretty slow, too >>200 ns or so. 200ns is fast for EPROMs and EEPROMs. If you want them faster it costs big time and as long as you are using them as a solid state disk they really don't need to have an awesome access time anyway. Even if they were as slow as 300 ns, you could still run them in excess of 2 mhz which is more than fast enough for a disk drive if you are using DMA to read it. (The 65816 block move is not too shabby either.) The resulting disk would be as fast as your GS ramdisk, and if DMA was used (why doesn't anyone make a DMA based standard slot RAMdisk using slow SIMMs or something? it's not hard and it's real cheap.) then you could get around a Megabyte per second which is fast enough to make the system loader the bottleneck and not the smartport driver. Who here would buy a card that could give you a 1 megabyte RAMdisk at 1 Megabyte per second into and out of the GS? I bet I could cook up wire wrap plans for one that would cost less than $200 total parts cost, with the prototype board and the RAMs being the major cost. Todd Whitesel toddpw @ tybalt.caltech.edu
dcw@lcs.mit.edu (David C. Whitney) (02/27/90)
In article <1990Feb27.032627.16301@spectre.ccsf.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: >[ somebody wrote, about EEPROMS ] > >>> (128K) to put on my AST Ramstak+. I _think_ they're pretty slow, too >>>200 ns or so. > >200ns is fast for EPROMs and EEPROMs. If you want them faster it costs big time >and as long as you are using them as a solid state disk they really don't need >to have an awesome access time anyway. I don't know about reading times, but I do know that EEPROMS are slow as hell for writing. It takes about 5 minutes to burn a 64k ROM. Ever try to rename a laserwriter? It takes forever! Setting up a system disk could take an hour or more. Sure, you do it once, but you do it again for dropping in new NDAs, updating icon files, etc. In other words, you'll always be twiddling the system disk, and it'll be SLOW. We'd be better off off with a SCSI interface to a big board with a pile of SIMM slots on it. A SCSI ram disk. Upgradeable at your leisure (and as RAM prices drop). Fragmentation becomes a non-issue (unless you like counting microseconds). No noise (I mean that chatter of thrashing read-write heads). A year ago this would be laughed away as too expensive. RAM is about twice as expensive now as hard disks were two years ago (yeah, a bad comparison). I estimate that in a year or two RAM prices for small amounts will cost roughly the same as the same amount of magnetic memory. >Todd Whitesel >toddpw @ tybalt.caltech.edu -- Dave Whitney dcw@sun-bear.lcs.mit.edu ...!mit-eddie!sun-bear!dcw dcw@athena.mit.edu My employer pays me well. This, however, does not mean he agrees with me. I wrote Z-Link & BinSCII. Send me bug reports. I use a //GS. Send me Tech Info.
rkh@mtune.ATT.COM (Robert Halloran) (02/27/90)
In article <1990Feb27.044441.8715@mintaka.lcs.mit.edu> dcw@lcs.mit.edu (David C. Whitney) writes: >We'd be better off off with a SCSI interface to a big board with a >pile of SIMM slots on it. A SCSI ram disk. Upgradeable at your leisure >(and as RAM prices drop). Fragmentation becomes a non-issue (unless >you like counting microseconds). No noise (I mean that chatter of >thrashing read-write heads). A year ago this would be laughed away as >too expensive. RAM is about twice as expensive now as hard disks were >two years ago (yeah, a bad comparison). I estimate that in a year or >two RAM prices for small amounts will cost roughly the same as the >same amount of magnetic memory. The beast basically exists now. I got an ad from Newer Technology in Wichita KS offering a 'DART' SCSI-interface RAM disk in a 3.5" form factor. Base cost with 2 Mb is $1600, and accepts up to 16 Mb in the basic package. A second 16 Mb plane, unpopulated, is $350. It accepts standard Mac X8 SIMMs, so pumping it up to 16 Mb wouldn't be that horrible. Bob Halloran ========================================================================= UUCP: att!mtune!rkh Internet: rkh@mtune.ATT.COM Disclaimer: If you think AT&T would have ME as a spokesman, you're crazed. Quote: "Remember, kids, if some weirdo in a blue suit offers you some DOS, JUST SAY NO!!!"
greyelf@wpi.wpi.edu (Michael J Pender) (02/28/90)
In article <1990Feb27.032627.16301@spectre.ccsf.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: >The resulting disk would be as fast as your GS ramdisk, and if DMA was used >(why doesn't anyone make a DMA based standard slot RAMdisk using slow SIMMs >or something? it's not hard and it's real cheap.) then you could get around >a Megabyte per second which is fast enough to make the system loader the >bottleneck and not the smartport driver. Does the IIgs include/support any DMA controllers at this point? If not, why? If so, for what operations? Memory to memory still takes seven clock cycles, it could be reduced to two. How about making a floating point coprocessor a standard part of the package? Does the FPE require a visible slot? --- Michael J Pender Jr Box 1942 c/o W.P.I. W.O.S. is not dead. greyelf@wpi.bitnet 100 Institute Rd. ...its time to get started, greyelf@wpi.wpi.edu Worcester, Ma 01609 there is much to be done. If my next computer isn't a IIgs, it won't be an apple... Me.
gwyn@smoke.BRL.MIL (Doug Gwyn) (02/28/90)
In article <9227@wpi.wpi.edu> greyelf@wpi.wpi.edu (Michael J Pender) writes: >Does the IIgs include/support any DMA controllers at this point? Yes, DMA support has always been part of the Apple II bus design. One of the video digitizers used it, for example, as have some disk controller interfaces. (Nothing sold by Apple though, so far as I know.) >How about making a floating point coprocessor a standard part of the >package? Does the FPE require a visible slot? While the iS FPE does require a peripheral-bus slot, a built-in FPP could presumably take advantage of the COP instruction of the CPU to "escape" out to the FPP or to trap to a floating-point emulator on systems with no FPP installed. Unfortunately this might require changes to the ORCA desktop debugging environment, which uses COP.
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (02/28/90)
dcw@lcs.mit.edu (David C. Whitney) writes: >I don't know about reading times, but I do know that EEPROMS are slow >as hell for writing. It takes about 5 minutes to burn a 64k ROM. Ever I contend that the amount of writing you will do in normal operation will be nowhere near enough to make the speed a problem. I don't care how slow the write is, I lock my system disk most of the time anyway and booting speed is my major concern. >We'd be better off off with a SCSI interface to a big board with a >pile of SIMM slots on it. A SCSI ram disk. Upgradeable at your leisure >(and as RAM prices drop). Fragmentation becomes a non-issue (unless I heartily agree. And with 150 ns DRAMs you could easily page mode them at 4 MB/sec which is -- guess what -- synchronous SCSI, supported (so I hear) by the new SCSI DMA card! There actually are solid state SCSI disks out there but they all seem to think that you want 20 megs or more so they are mondo expensive. I just want 1 meg or so for my boot disk, I can use floppies for everything else because it is then reasonable to swap application and data disks which is not much of a problem. Todd Whitesel toddpw @ tybalt.caltech.edu
rlw@ttardis.UUCP (Ron Wilson) (03/10/90)
In article <1990Feb27.044441.8715@mintaka.lcs.mit.edu>, dcw@lcs.mit.edu (David C. Whitney) writes: >In article <1990Feb27.032627.16301@spectre.ccsf.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: >>[ somebody wrote, about EEPROMS ] >> >>>> (128K) to put on my AST Ramstak+. I _think_ they're pretty slow, too >>>>200 ns or so. >> >>200ns is fast for EPROMs and EEPROMs. If you want them faster it costs big time >>and as long as you are using them as a solid state disk they really don't need >>to have an awesome access time anyway. > >I don't know about reading times, but I do know that EEPROMS are slow >as hell for writing. It takes about 5 minutes to burn a 64k ROM. Ever >try to rename a laserwriter? It takes forever! Setting up a system ... > >We'd be better off off with a SCSI interface to a big board with a >pile of SIMM slots on it. A SCSI ram disk. Upgradeable at your leisure >(and as RAM prices drop). Fragmentation becomes a non-issue (unless >you like counting microseconds). No noise (I mean that chatter of >thrashing read-write heads). A year ago this would be laughed away as >too expensive. RAM is about twice as expensive now as hard disks were >two years ago (yeah, a bad comparison). I estimate that in a year or >two RAM prices for small amounts will cost roughly the same as the >same amount of magnetic memory. > >Dave Whitney Actually, several years ago, some company actually marketed such an outboard RAM disk device (non SCSI, though) for the Apple II computers. I don't remember what the price was. But, as I recall, it didn't sell well. Another product I saw was a bubble memory disk emulator - but that didn't last either.