toddpw@tybalt.caltech.edu (Todd P. Whitesel) (08/22/89)
i may be wrong but i thought that the main improvement was more toolbox stuff in rom, older machines have been loading this stuff in from disk for years now (what the gs really needs is a decent caching 3.5 device driver. I'm planning to play with one if i can figure out how to program them, does a reference exist on hardware level programming of the IWM besides disassembling the rom 1 i have at home? (the hardware reference lists the registers, but that isn't really enough, unless the procedure is close to that for the disk II, which i doubt. formal request: how does one read the apple 3.5 at the hardware level? are there any in depth explanations (such as jim sather's detailed expose on the disk ][) in print anywhere? the one thing i see happening with the gs is that things are getting huge, just as they are on the mac (ask any hyperprogrammer), as well as complex. the honor system among application programs hasn't been holding out in some cases which is why the mac will do strange things if you have certain combinations of INITs, DAs, etc. the only thing most old machines have to fear should only be running out of memory due to excessive amounts of data. programs that require humungous amounts of memory just to run give me a nervous itch because i have gotten some really dinky stuff to run on my old //+ and it still runs on the gs. for example, in the space it takes to store one mac icon i wrote a 6502 terminal program that used the super serial card directly, had an interrupt driven receive buffer, and used whatever video was available via COUT. I literrally pr#3'd and BRUN MINITERM for a week until i added vt52 terminal emulation, and other nifty features, and the thing is still about only 1K. (a mac icon, by the way takes a full page of memory- 128 bytes for the icon, and 128 bytes for the select mask.) the biggest problem we face these days is that the approach apple has taken with the gs and mac toolbox calls has been entirely from a high-level language perspective, and i'm not sure that is the most efficient way to code things. but until we can invent a viable alternative (a friend of mine at college is working on a forth system for the gs, which is extremely nice for toolbox intensive stuff because forth does all its main work on the stack) we haven't got much choice. my point really is that mass data requires mass storage, but programs shouldn't be unnecessarily huge because the compiler sucks or doesn't know better (which is largely the case so it's not their fault). what i don't understand is what's so horrid about the new gs (which should be officially called the gs+, the //+ also had more rom than its predecessor) because it doesn't leave the original in the dust! (or is it just backlash at the thought of no longer owning the latest model? naw, we're above that) todd p whitesel toddpw @ tybalt.caltech.edu
dlyons@Apple.COM (David Lyons) (08/23/89)
In article <11673@cit-vax.Caltech.Edu> toddpw@tybalt.caltech.edu.UUCP (Todd P. Whitesel) writes: >[...] how does one read the apple 3.5 at the hardware level? are >there any in depth explanations (such as jim sather's detailed expose on the >disk ][) in print anywhere? As far as I know, this information isn't available from Apple. >[...] >the biggest problem we face these days is that the approach apple has taken >with the gs and mac toolbox calls has been entirely from a high-level language >perspective, and i'm not sure that is the most efficient way to code things. The toolbox has generally been designed so that it's accessible from languages like Pascal and C; I don't understand how this is a problem. What are you suggesting would be better? --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: 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.