AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (07/04/88)
NOTE--we lost 1 day's mail here [Friday, July 1st's mail]...if you send me something & I didn't respond, send again! --Dave Lyons >Date: Tue, 28 Jun 88 06:17:31 GMT >Reply-To: Info-Apple@BRL.ARPA >From: Sean Kamath <tektronix!reed!kamath@ucbvax.berkeley.edu> >Then I claim the only implementation that will speed it up is mass >hardware upgrades, like coprocessors and a dedicated video CPU, as >well as DMA disk access, with intelligent caching. . . Wait a >minute. . . How sure are you? Think hard...what could they do just *in software* to speed up different parts of the system, perhaps dramatically? >How about allowing the user to expand his/her usable RAM to up to 12 >Meg, and saving 4 meg for ROM? Actually,I'm really coming close to >biting my own ass off here, I don't know exactly how it's reserved. >I'm sure gobs o' space go to the video firmware (by way of screen >buffers, etc.). Just how much of the "reserved" ROM is unused? It >seems to me that only about 2-4 megs should *ever* be actual ROM. . . Out of 256 64K banks (total of 16 Megs address space), $00-$7F is for RAM [8 megs], $E0 and $E1 are for slow RAM, $FE and $FF are ROM [128K], $F8-$FD are "reserved for ROM" [384K]. $F0-$F7 [1 meg] is reserved for a ROMdisk. The remaining areas ($80-$DF, $E2-$EF) are simply "reserved," and I don't think they are even decoded by the chips on the current motherboard. You still haven't said what you want to see in ROM! (Adding even *more* space for RAM will encourage developers to write even Bigger programs that *require* that extra RAM!) >>I don't normally *use* the Launcher...I use Davex. The Launcher >>isn't even slow--just LOADING THE RAM TOOLS is slow. And if you >>have been running other desktop-based software, they will already be >>loaded & you can zip in & out of the Launcher and Finder pretty >>quickly. >Pretty quickly compared to what? Compared to running the first desktop application after boot, when the RAM-based toolsets have not yet been loaded from disk. Once they're loaded, you can quit to the Finder of Launcher in just a couple of seconds. (Of course, then the Finder has to go hunting for icon files & things to put on the desktop...depending on how many drives, icon files, and icons left lying on the desktop there are, the Finder can still be slow.) >Until the graphics environment becomes faster than the text >environment, I will probably use the text environment. It's not reasonable to expect a graphics environment to *ever* be faster than the text environment--but eventually it will be fast enough not to be annoying. >>TML Pascal: >> SFGetFile(120, 35, 'Open what Icon file:', @MyFilter, >> TypeListRecPtr(nil), myReply); >> >>APW C (looks almost the same!): >> SFGetFile(120, 35, "Open what Icon file:", MyFilter, >> (TypeListRecPtr) NIL, &myReply); >Uh, Dave, if @ takes the address of the funct, then you ought to have >a '&' before the MyFilter above. . . In C, the name of a function *is* its address, and putting an "&" in front of it will give a warning or an error. >[...] it's a little weird that you have to address MyFilter, but not >myReply, yet in C you send the address of myReply, obviously for >modification my SFGetFile. [...] Either I don't get it, or you >haven't fully explained everything (such as data types and specs for >the calls. . . ). (Or both!) I should have mentioned that the myReply record is declared as a VAR parameter in the Pascal declaration of SFGetFile. It could equally well have been declared as a value parameter, in which case a "@" would be needed before it in the actual parameter list. (In C, everything is passed by value [given that the name of an array stands for its address, etc.], so you never have to refer to a declaration to decide how a parameter is going to be passed.) >>How much stack space is used? I really don't care [...] >Well, don't you thing you ought to care? I mean, suppose you use up your >entire bank of stack space? With today's current recusive wonder-routines... Maybe, but I would find out if was overflowing my allotted area...something would crash pretty shortly. The 8K stack you get by default in TML Pascal is plenty, and there's no heavy recursion in the toolsets...just lots of tools calling other tools, but generally in a hierarchy: Window Mgr calls Dialog Mgr calls Control Mgr calls QuickDraw, for example, and lots of things call the memory manager and the event manager. But when you get down to the "bottom", the buck stops there (at QuickDraw, Memory Mgr, MiscTools, Event Mgr, IntMath, TextTools). >And if you plan on getting really serious, you get an Apollo or Sun >workstation. If you recall my *original* point, it was that given >the size of code generated, time involved, and ease of use *from >assembly*, it just doesn't cut it! Include compile time! Geez, we >are really talking Apples and Oranges here! I don't even *want* to do user-interface sorts of things from Assembly--why should I, considering it will take longer to write, generate about the same amount of code, and take LONGER to assemble! (TML Pascal stand-alone compiles several times faster than the APW Assembler, since TML can compile & link in RAM, and since the APW Linker is *incredibly* slow!) >>How much *code* is generated I can answer: [...] >>Total=41 >Ha! that's a 1300% increase it space! Gaaaaaa.a. . .a., Or a 38-BYTE increase in space, depending on how you look at it. 38 bytes seems a reasonable price to pay to get an interactive interface rather than a place to guess at the names of your files. >Again, David, the discussion was not concerning functionality, or >"correctness" of code, or anything related to that. It was on >"hacking" and the user_interface. We exSCUUUse me for Changeing the Topic a little. >I maintain that as a programmer, it is, and always be, easier for me >in a low level language to dispense with the user interface as best I >can (making truely cryptic prompts such a "1:" or "in", and not a >little window showing me all the choices, and a nice message [...] >and get to the actual work at hand. When that is done, then I can go >back and get to work on a nice user interface. I think you're underestimating the effect that user interface design has on the structure of the whole program--I can't imagine saving any time by going *back* to add a desktop inteface to something. Might as well put it in in the first place and save time. Most of the necessary code can be stolen from a previous project & then polished up for the new application at your convenience. >>On the contrary! Standardization isn't the problem at all. >>[example of customization] >Standardization supposedly guarantees that you always get the same thing >when the same type of event occurs. And I can just see me sitting at your >GS, and trying to figure out just exaclty *how* to use your fileselector! >:-) Well, we would just *disable* my customized patch if you didn't like it. (Actually, my example just *added* a feature to the existing standard, so you could just ignore it and use what you were used to.) >PS, for anyone who didn't see it in Open-Apple this month, Dave got >prominent mention by Tom [Weishaar] this month. Congrats on getting >Roger Wagner to publish your NDA thingie! :-) Thanks! (It's a *CDA* thing...loads those Classic Desk Accessories under ProDOS 8.) Now, if I could just get Tom to say something nice about *Davex*.... >UUCP: {decvax allegra ucbcad ucbvax hplabs ihnp4}!tektronix!reed!kamath >CSNET: reed!kamath@Tektronix.CSNET || BITNET: reed!kamath@PSUVAX1.BITNET >ARPA: reed!kamath@PSUVAX1.CS.PSU.EDU >US Snail: 3934 SE Boise, Portland, OR 97202-3126 (I hate 4 line .sigs!) --David A. Lyons a.k.a. DAL Systems PO Box 287 | North Liberty, IA 52317 BITNET: AWCTTYPA@UIAMVS CompuServe: 72177,3233 GEnie mail: D.LYONS2