wzg91@ttacs1.ttu.edu (BROWN, KEVIN) (04/24/89)
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!
wzg91@ttacs1.ttu.edu (BROWN, KEVIN) (04/27/89)
In article <13850@louie.udel.EDU>, BROWN, KEVIN writes: >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 $$$$. > >... Since I posted this message, I have received one reply, and that a couple of days ago. I've seen nothing regarding this on the newsgroup(s) itself. Did I break some sort of network protocol in the message? I realize it was rather lengthy... Under normal conditions I would not be so concerned about this, but my account(s) die in a couple of weeks. To summarize my previous questions: 1. I have the A1000 Expansion Specs, and contained therein are the plans for an A1000 card cage, using (I believe) the Zorro-I spec. Does anyone know the differences between the Zorro-I and Zorro-II specs (timing and signal layout, etc)? My goal is to build an expansion system that will allow me to use B2000 cards, and if there is interest, make the plans publicly available (a la LUCAS) so that others may do the same at relatively little expense. 2. I've seen a few postings on the net about the Konica 10-meg removable drive and am intrigued, but would like some detailed information about it (like seek times, data transfer rates and compatibility with various controllers, price, and reliability, and anything else you might want to mention :-)... 3. I've seen windowed, menu-driven shells for almost all the compilers for other computer systems, namely IBM (All the Borland and Microsoft stuff, save BASIC), Mac (*everything*), and Atari ST (HiSoft Basic, Lazer C, OSS Pascal). It seems that the Amiga is the only system in its class that lacks this. I would be interested in writing such a shell for the Amiga (customizable so you can use it with any cli-based compiler, editor, and make facility), but need to know if there would be any interest in such a thing. Also, if there is interest in such a shell, then I need to know how to get my window to be considered stdin, stdout, and stderr by anything I happen to invoke (I want to be able to invoke the shell from workbench or CLI). 4. How difficult would it be to write a run-time library that would act as an interface between C programs and dos.library? Currently, dos.library expects a lot of BCPL constructs, and returns same, and while I haven't done extensive programming with it, it seems rather silly that Amiga programmers are constrained to use it when everything else in the system conforms to C calling conventions. I was thinking that perhaps the new runtime library (cdos.library) could eventually replace dos.library in the ROMs so as to provide a consistent programming interface. Any comments on this, guys?? As far as the above goes, please email responses unless you feel it would be of general interest to the net, but if the mail bounces then PLEASE post to the net! Many thanks! Kevin Brown Internet: wzg91@ttacs1.ttu.edu or c8u00@ttacs1.ttu.edu Bitnet: WZG91@TTACS1 or C8U00@TTACS1 Snailnet: 404 Gaston Hall Texas Tech University Lubbock, TX 79406 Voicenet: (806)742-4375