SHBOUM@MACALSTR.EDU (01/12/91)
Hello Apple II users!!! I recently joined the dicussion group and I'm quite happy to see all the great talent here that is working hard for the apple II - something that you don't see much of anymore. :-( For the record, I've been using Apple II Computers for over 9 years now and have not regretted it yet even despite Apple's wonderful "we're there when you need a mac, err.. us" support... Just to get things started, I'd like to make a couple of comments about a few messages recently posted... First, Jawaid Bazyar wrote > First of all, xmodem and ymodem are NOT supposed to work over 7-bit >lines. It says so in the X/YModem specification documents provided [...] >If you can download Xmodem over a 7e1 line with ANY program I'd like to >see it. I believe that there are hybirds of Xmodem to work over 7 bit lines. However, in refrence for the Apple II, none of the programs that I have used can handle it. But Mousetalk might be able to handle it. I've never used it, but as I have understood, the United Software products specialized in the Xmodem protocol. As far as term programs go, I have been quite happy with my Proterm. Verison 2.1's Zmodem was a total joke, however, 2.2 has worked much better. And Andy Tefft, if you think Proterm crashes too much, try using a Mac for a couple of weeks... While downloading with Zterm for the Mac is nice, I've been having serious problems with its word wrap. It wants to start each line at the 80th column on the previous line. So while downloads are nice, you can't read the screen... Secondly, Nagendra Mishr wrote >The problem reveals itself when I have an archeive or close an archeive and >exit from shrinkitGS. The Computer crashes with some could not load tools >error. The problem that I have in TML II some message about the control >manager. Sounds like you've got an incomplete copy of System Version 5.0.3 or a version that really isn't 5.0.3 {I thought I had 5.0.2 until I tried running Shrinkit GS 1.03 for the first time...} Perhaps you missed some of the tools or something. Thirdly Doug Gwyn writes >It's not a matter of laziness, but of effective use of one's limited >lifespan. When I can produce (AND MAINTAIN, an important point) dozens >of applications for use on a wide variety of systems using a HLL in the >same time that I could produce fewer, less maintainable applcations on a >single platform, what would you think I ought to choose? Well are you interested in quality or quantinty? Sure you could write lots of programs for lots of computers using C, but would those programs really take advantage of that computer's resources? And if you did want your programs to utilize the system that its on, thats a lot of informtation that you'd have to learn. Hey C is awesome, and you're right, teachers have gone way overboard in praising the power of C, but you shouldn't say that its better to produce programs for lots of systems at once either. If you need to have a program for lots of systems, then C is great, however, if you need all the speed the computer can muster or utilize the resources to its fullest {almost always the case for the IIGS} then its better to use assembly. Finally, I've got a stupid questions to ask, but it needs to be asked... If I have a 1600K Ram Disk, How can I install GS/OS on to it so I can boot from it? I've copied the files and even tried installing it but when I try booting from Ram Disk, the computer says "Not a startup device." Thanks... Hal +-----------------------------------------------------------------------------+ | Hal Bouma Send mail to IN%"SHBOUM@MACALSTR.EDU | +-----------------------------------------------------------------------------+
dcw@lcs.mit.edu (David C. Whitney) (01/13/91)
In article <D6CC175AA07F005982@MACALSTR.EDU> SHBOUM@MACALSTR.EDU writes: >Finally, I've got a stupid questions to ask, but it needs to be asked... If I >have a 1600K Ram Disk, How can I install GS/OS on to it so I can boot from it? >I've copied the files and even tried installing it but when I try booting >from Ram Disk, the computer says "Not a startup device." > >Thanks... > Hal You have to actually format the RAM disk. Just creating it does not put boot block on it. Boot the finder, ERASE the RAM disk (This will put boot block on it), and then use the installer to put GS/OS on it (don't just drag the files over). -- Dave Whitney Computer Science MIT 1990 | I wrote Z-Link and BinSCII. Send me bug dcw@lcs.mit.edu dcw@mit.edu | reports. I still need a job. Send me offers. "The price of freedom is eternal vigilance" --Binky (aka Matt Groening)
gwyn@smoke.brl.mil (Doug Gwyn) (01/13/91)
In article <D6CC175AA07F005982@MACALSTR.EDU> SHBOUM@MACALSTR.EDU writes: >>It's not a matter of laziness, but of effective use of one's limited >>lifespan. When I can produce (AND MAINTAIN, an important point) dozens >>of applications for use on a wide variety of systems using a HLL in the >>same time that I could produce fewer, less maintainable applcations on a >>single platform, what would you think I ought to choose? > Well are you interested in quality or quantinty? Sure you could write >lots of programs for lots of computers using C, but would those programs >really take advantage of that computer's resources? First of all, if an application does what is wanted, who cares whether or not it exploits system-specific features that are not needed to get the job done? Also, even for classes of applications that require system features that may not be available universally, for example an interactive painting program, normally only a small portion of the overall system need be specific to a particular platform. For example, the BRL-CAD package includes interactive 3-D solid modeling tools and frame-buffer utilities, with support for a wide variety of disparate vendor hardware, yet it is entirely implemented in C (some portions are specific to the hardware, but because of modular design, a variety of choices are available and more can be added). To port, for example, the frame-buffer utilities to my IIGS, the main task I would have to do would be to implement a small library of functions conforming to a certain generic interface specification, and link that with the applications. The implementation of the library may use a few asm{...} sections if necessary to improve display speed, but only after it proves to be a bottleneck (which it might not, it's hard to say in advance). Note that if the entire suite of tools had been coded in some assembly language (which we were not stupid enough to do), porting to the variety of platforms that are now supported would have been utterly out of the question. In 1978 the small software house that I then worked for released what was definitely the spiffiest interactive graphics system for facilities management and architectural purposes then available. It utilized a Unibus-master display processor, function buttons, digitizing tablet, etc. Practically the whole package, apart from the vendor's operating system, had been implemented in Fortran. Certain critical portions involving manipulation of the memory management unit and low-level support for dynamic memory allocation involved a modest amount of assembly-language code. The Fortran code exploited vendor extensions for boolean operations on integers, to pack and unpack data fields; otherwise, it was highly portable, so that when the time came to use a different graphics technology, porting involved vastly less work than would have been required had the system been written entirely in assembler. Performance was also extremely good. Today one would use C rather than Fortran, but otherwise this approach is still recommended.
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (01/13/91)
gwyn@smoke.brl.mil (Doug Gwyn) writes: > To port, for example, the frame-buffer utilities to >my IIGS, the main task I would have to do would be to implement a small >library of functions conforming to a certain generic interface >specification, and link that with the applications. The implementation >of the library may use a few asm{...} sections if necessary to improve >display speed, but only after it proves to be a bottleneck (which it Hear hear! I've had lots of success doing just this with Orca/C. Lord High Giffer, for example is entirely in Orca/C except for the actual raster decompression and the screen display loops. Todd Whitesel toddpw @ tybalt.caltech.edu
taob@pnet91.cts.com (Brian Tao) (01/14/91)
> You have to actually format the RAM disk. Just creating it does > not put boot block on it. Boot the finder, ERASE the RAM disk > (This will put boot block on it), and then use the installer to > put GS/OS on it (don't just drag the files over). Why can't you just drag the ProDOS and System folders into the RAMdisk from the Finder? The installer is a big pain to use. Brian T. Tao {taob@pnet91.cts.com} || Computer guru? Someone who got University of Metro Toronto || their computer a couple of weeks Scarberia, ON, MIC 3A8 *B-) || before you did. (Alvin Toffler)
ifar355@ccwf.cc.utexas.edu (David H. Huang) (01/16/91)
In article <384@generic.UUCP> taob@pnet91.cts.com (Brian Tao) writes: >> You have to actually format the RAM disk. Just creating it does >> not put boot block on it. Boot the finder, ERASE the RAM disk >> (This will put boot block on it), and then use the installer to >> put GS/OS on it (don't just drag the files over). > > Why can't you just drag the ProDOS and System folders into the RAMdisk >from the Finder? The installer is a big pain to use. To tell the truth, I have never used the Installer to install system software (or anything else, for that matter). I only have one 3.5 drive, and unlike the finder, it loads one file at a time. I tried it once, and gave up after swapping disks 15 times. I just use GS/OS TN #1 and the Finder to see what I need. So, if you know what files you need, use the Finder to do the copying. Of course, if it doesn't work, you didn't hear this from me... -- David Huang | Internet: ifar355@ccwf.cc.utexas.edu | "My ganglion is stuck in UUCP: ...!ut-emx!ccwf.cc.utexas.edu!ifar355 | a piece of chewing gum!" America Online: DrWho29 |
SHBOUM@MACALSTR.EDU (01/16/91)
On Jan. 13, Doug Gwyn writes: >>>It's not a matter of laziness, but of effective use of one's limited >>>lifespan. When I can produce (AND MAINTAIN, an important point) dozens >>>of applications for use on a wide variety of systems using a HLL in the >>>same time that I could produce fewer, less maintainable applcations on a >>>single platform, what would you think I ought to choose? >> Well are you interested in quality or quantinty? Sure you could write >>lots of programs for lots of computers using C, but would those programs >>really take advantage of that computer's resources? >First of all, if an application does what is wanted, who cares whether >or not it exploits system-specific features that are not needed to get >the job done? Well unfortunatly, this "Well who cares? it works..." attitude exists in the world today, expecially in the business market. For example, many of Cray Computer's best customers buy the new compiler that Cray publishes each year. Cray spends tons of money to develope the optimization routines in the compiler. Yet, because the businesses don't want ANYTHING to change the code, they turn the optimizers OFF because its no longer the "correct code" and they don't want to risk it. Sure the application works, but it is SLOWER... I don't know about you, but I know that speed is an important issue for me and others. Thats why I still like Appleworks over nearly anything the Mac has because for speed, Text stomps GUIs any day. {Within limits} So lets say you port a program over to my computer that doesn't take advantage of my built in Co-Processor thus taking possibly TWICE as long as it should. I think that this is an important issue. Hey it works, but are you happy? NO.... Or another example. Mathematica is a wonderful math program. However, to improve portability much of the output is still done in a text format such as Sin (0) ------- Cos (0) Hey, its the answer, but dude, I've also got a Color Next right here in front of me, and gee I'd really like to have it in nice pretty graphics so that I can print it out and hand it in for class. Sure it works, are you 100% Satisfied??? NO.... The point is that WE the users CARE. If we didn't, we wouldn't have minded that Appleworks GS once took over 7 minutes to load from the disk drive. A basic notion of the human race is to improve... Not to stop and say "well it works..." Hell, we'd still be living in the trees and eating animals raw with that attitude. Because we are paying money for these programs, we want the best program money can buy. So if you come out with a program that does a fair job, well hey, who cares? IT WORKS. Is that it? No!!! People complain and another programmer comes along and says, "HEY, I CAN DO BETTER THAN THAT." And writes an improved program. People buy that program and you end up on the short end. And by porting programs though using C or FORTRAN, or whatever, it becomes much more difficult to tailor it for each system. Sure you can make patches to the code, but the amount of information that you have to learn about each system becomes staggering. I'm not against porting programs. Its great for businesses and multi-platform systems, but there are potentially serious drawbacks with it. The most damaging are those who do port with the attitude "Well it works..." because it produces a second rate program... | Hal Bouma | Working on a .sig! | Macalester College | | Mail to SHBOUM@MACALSTR.EDU | | H.BOUMA on GEnie |
gwyn@smoke.brl.mil (Doug Gwyn) (01/17/91)
In article <D39C0AB97EFF008714@MACALSTR.EDU> SHBOUM@MACALSTR.EDU writes: >On Jan. 13, Doug Gwyn writes: >>First of all, if an application does what is wanted, who cares whether >>or not it exploits system-specific features that are not needed to get >>the job done? > Well unfortunatly, this "Well who cares? it works..." attitude ... That wasn't waht I said! If an application does not satisy your requirements, then it might still "work" but it doesn't meet the criterion I mentioned. You even gave the example of using a text-screen program because it was faster than one using the graphics screen. If that is a legitimate concern for you, then it makes a good example of not exploiting system-specific features just because they're there. > And by porting programs though using C or FORTRAN, or whatever, it >becomes much more difficult to tailor it for each system. Sure you can make >patches to the code, but the amount of information that you have to learn about >each system becomes staggering. The amount you have to learn about a system to take advantage of system- specific features is not increased by having the bulk of the application coded in a high-level language. If anything, it's slightly reduced. Certainly the amount of effort to port the code is far less, assuming that it was well engineered to start with.