Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!udel!mmdf From: wzg91@ttacs1.ttu.edu (BROWN, KEVIN) Newsgroups: comp.sys.amiga Subject: Questions and suggestions.... Message-ID: <13850@louie.udel.EDU> Date: 24 Apr 89 13:07:44 GMT Sender: mmdf@udel.EDU Lines: 123 A couple of questions: Firstly, being a poor college student, I would like to expand my system in the least expensive way possible. Additionally, I would like to make my expansion means as flexible as possible, so that I can add on more goodies as I (somehow) acquire the $$$$. The least expensive means in the long term seems to be to acquire a card cage that will allow me to use B2000 cards, and then to acquire the appropriate cards. Well, unfortunately someone posted on the net recently that the current expansion cages were relatively unreliable. Being semi-hardware oriented, however, it may be possible for me to build my own. I have acquired the A1000 expansion specs and within it resides the plans to build a 5-slot Zorro-1 (100 pin) expansion chassis. This I could do relatively easily, for a reasonable price (price of parts + PAL programming fees), but am I correct in stating that Zorro-1 and B2000 (I think it's called "Zorro-2") expansion protocols are different? If so, I need to know in what way! I need to know what connectors to use for the slots, what the pinout of the slots are, and whether there are any timing and protocol differences between the two expansion methods. Dave, any comments?? Under normal circumstances I would buy the A500/2000 hardware manual, but that's an extra $40 that I'd rather not spend if I can avoid it, since once I have the specs I can probably complete this project without too much trouble. Secondly, I've read posts by several people regarding the Konica 10 meg removable Winchester drive, and needless to say I'm quite enticed. However, I can't seem to find any reference to this beast in any of the magazines that I've read (AmigaWorld, Transactor, Amazing Computing, etc.), so I have no idea what kind of prices I'd be looking at for it, nor what kind of performance I could expect out of it, or even where to acquire it! Anybody out there have any concrete figures on this? I'm looking for average seek time, average data transfer rates (preferably on several different configurations), MTBF, power consumption, use with FFS (if possible), autobooting, problems (and praise) with its use with different controllers, and, of course, price. Please e-mail this info to me as it would probably soak up too much bandwidth on the net. If everyone would like, I'll be happy to post a summary after I've gotten a reasonable number of responses. Thirdly, have any of you noticed that just about every micro-based system out there (UN*X boxes excluded) use some kind of menu-driven windowed shell for their compilers? IBM (ugh) has Microsoft (ugh :-) and Borland, both with menu-based shells, the Atari ST has Lazer C, OSS Pascal, and HiSoft Professional Basic, each with its own windowed shell, and EVERYTHING on the MacIntosh is done via the window interface. And what do we Amigans have?? THE CLI!!!! I'll grant you that the CLI is useful for some things, but most of the development cycle seems to involve editing, compiling, linking, and running. While "make" removes a lot of the hassles, it seems that a windowed shell would make for a much nicer environment. That being the case, I'm seriously considering writing such a beast. Features would include completely customizable compiler invokation commands, customizable compiler switches (both of which can be saved in configuration files so that the shell would be useful for just about any compiler out there), the ability to invoke "make", standard input/output from its window (scrollable so that you can review error messages and the like), and multitasking of commands (i.e., you can invoke your compiler with your editor up, all by selecting one menu item). There are two problems that immediately come to mind. The first is simply a technical problem: how do I tell the things that I invoke that STDIN and STDOUT refer to my window? As I understand it these are global BCPL variables, which would make this extremely painful to do. I'd prefer to spawn a process, but this makes me think that I might have to LoadSeg() everything, set up the Exec and Dos structures, and AddTask (or equivalent), etc., by hand....yech.... Anyone have any ideas about this? I'd prefer not to set things up such that the program simply adds a menu-strip to someone's CLI, since I want to be able to invoke this thing from Workbench (or Browser, which I happen to like a LOT better. Good job, Peter!). Any ideas? That's the easy part. The HARD part is setting things up so that it would be possible to intercept/trap/save compiler errors so that the editor could go directly to the error in the source code. Wish there were some sort of standard error reporting system to make this easier...sigh... Any of you ever use LSE under VMS? That's the sort of thing I'm talking about here... Let me know what you guys think of my idea (if it's completely ludicrous and I shouldn't waste my time, by all means tell me!), and e-mail me any suggestions you might have for features to add to this thing. I want the Amiga to have the nicest programming environment possible, and I think it's got the best resources around to give that to us, but nobody's taken advantage of that yet. And one more thing, this time a suggestion: how many of you are TIRED of dealing with that STUPID BCPL interfact to DOS? I haven't done much programming (except for stdio-type C), so I haven't messed with it yet, but the very idea sickens me. So my suggestion is this: why not have a library out there, called, say, "cdos.library", which would implement ALL the DOS functions using the C interface conventions (REAL pointers instead of these bogus BPTRs, null-terminated strings, etc) for both input and output? At first it would be a disk-resident library that simply calls the (groan) BCPL dos.library and converts the output to C convention. Developers would then have the choice of using the BCPL library (dos.library), the C library (cdos.library), or even both! Then, as the operating system matures and people (hopefully) stop using dos.library, cdos.library could take its place in the ROMs and dos.library made disk-resident and eventually phased out of existence (which is where it should have been all along). Again, please e-mail the responses unless you think it would be of general interest to the net...many thanks!! Kevin Brown Internet: wzg91@ttacs1.ttu.edu or c8u00@ttacs1.ttu.edu Bitnet: WZG91@TTACS1 or C8U00@TTACS1 Snail: 404 Gaston Hall Texas Tech University Lubbock, TX 79406 Voice: (806)742-4375 Disclaimer? I don't need any disclaimer...everything I say is right!