glennw (08/20/82)
>From uucps Wed Aug 18 21:40:50 1982 >From uucpa Wed Aug 18 21:36:58 1982 remote from mhuxa >From jms Wed Aug 18 19:49:43 1982 remote from mhuxt >From uucp Wed Aug 18 16:48:41 1982 remote from eagle >From floyd!cmcl2!philabs!sdcsvax!vicki Wed Aug 18 16:43:36 1982 remote from harpo Date: Wed Aug 18 16:31:02 1982 To: philabs!cmcl2!floyd!harpo!eagle!mhuxt!mhuxa!mhuxh!glennw Subject: here comes what I have so far... >From nprdc!INFO-PC@USC-ISIB Mon Aug 16 05:21:30 1982 Mlfl-from: ARPAnet host usc-isib rcvd at Thu Aug 12 00:21:39 1982 Date: 12 Aug 1982 0020-PDT From: INFO-PC <INFO-PC at USC-ISIB> Subject: Welcome to INFO-PC To: sdcsvax!vicki at NPRDC Sorry about the mixup. /Dick Welcome to Info-PC Info-PC is a forum for discussion of the IBM Personal Computer and related 8086/8088/PC-DOS/CPM-86 micro-computers. Info-PC provides a way for interested members of the ARPANET community to compare notes, ask questions, and share insights about these machines. Messages are collected into digests and distributed as the volume of mail dictates. Messages to the list should be addressed to Info-PC at ISIB. All requests to be added to or deleted from the list, problems, etc. should be sent to Info-PC-REQUEST at ISIB. Old digests are archived in <INFO-PC>digests-august-82 and so on. A library of free software is maintained in [ISIB]<INFO-PC>. A list of available programs is in <INFO-PC>PROGRAM-LIBRARY.LIST. These files may be ftp'ed from ISIB by logging in to FTP with username ANONYMOUS, password GUEST. To donate a program to the library, send a description of the program along with a copy of the source code to INFO-PC-REQUEST. /Dick Gillmann (GILLMANN at USC-ECL) ------- >From nprdc!INFO-PC@USC-ISIB Mon Aug 16 05:30:40 1982 Mlfl-from: ARPAnet host usc-isib rcvd at Sun Aug 15 10:41:39 1982 Date: 12 Aug 1982 0057-PDT From: INFO-PC <INFO-PC at USC-ISIB> Subject: Info-PC Digest V1 #5 To: Info-PC: ; Info-PC Digest Thursday, 12 August 1982 Volume 1 : Issue 5 Today's Topics: Siggraph Standard on PC's Bay Area IBM PC Club Communication and File Transfer ---------------------------------------------------------------------- Date: 9 Aug 1982 1335-PDT From: KUSHNER at SRI-AI Subject: Siggraph Standard on PC's To: info-pc at USC-ISIB Does anyone know of any attempts to implement the Siggraph standard system on personal computers, e.g. on CP/M? If not, would anyone with an IBM PC be interested in helping on building one? We may also be interested in bringing up a color interface within the main system. ------------------------------ Date: 10 Aug 1982 1132-PDT From: Tony Fanning <FANNING at SRI-KL> Subject: Bay Area IBM PC Club To: info-pc at USC-ISIB For those who live in the S.F. Bay area: I've just heard about a club which has 50-100 members, is dedicated to the IBM PC only, and meets monthly. I haven't gone to any meetings yet, but intend to this Wednesday--and will inform INFO-PC if anyone is interested in details. SVCC (Silicon Valley Computer Club) Meets every 2nd Wednesday of the month DYSAN Auditorium (that's the manufacturer's place) Great America Industrial Park Santa Clara (that's the best I have for an address so far) ---Tony ------------------------------ Date: 11 Aug 1982 0140-PDT Sender: BILLW at SRI-KL Subject: Communication and File Transfer From: BILLW at SRI-KL To: INFO-PC at ISIB Framing errors might occur at high transmission speeds if the IBM is expecting 2 stop bits, and the remote host is only sending 1. (normally, the time between characters would act as extra stop bits.) I don't think I've had any problems of this sort with my assembly language routine (I set it up for 8 data bits, no parity, 1 stop bit), but then I don't check for errors anyway, so maybe.... On large computers, it can be very ineffecient to do input and output a single character at a time, so I use a jsys that inputs all 128 characters in a block (still at 9600 baud, however). This however, necesitates using a block timeout rather than a per character timeout. When uploading files to our KL-10 at 9600 baud, a couple of characters are occasionally lost (TOPS-20 TTY buffers are like 96 characters long, and sometimes characters dont get transferred to my own user space QUITE fast enough). Well, I got tired of having the transfer zip along until a character was lost, and then sit there for ten seconds (almost 10K chars worth !) waiting for a timeout to occur. So I made the timeout time dependent on the baud rate, with a minimum of 1.5 seconds to allow for human reaction time during testing. I was puzzled when my simple minded download to the IBM PC didn't work from the KL at 9600 baud, but I assumed that that was just too fast for BASIC to handle, and decided I'd have to write part of the program in assembly language. Then, while working on the upload part, it became apparent that the BASIC COMM port is interupt driven, with a 256 (default size) FIFO buffer, so it SHOULD be big enough. So I put in the appropriate print statement to see what was really happening. Timeouts were occuring (on the KL end)! This caused my simple minded program to get very confused. Did you know that it will take IBM BASIC >1.5 seconds to sift though the input buffer to find a specific character? I increased the minimum timeout on the KL end to 3 seconds, and all the problems have apparently gone away. How easy to forget that micros can take a long time to write stuff to a floppy, and that is what the timeout is for, rather than just to cover transmission time... Bill W ------------------------------ End of Info-PC Digest ********************* ------- >From nprdc!INFO-PC@USC-ISIB Mon Aug 16 05:45:18 1982 Mlfl-from: ARPAnet host usc-isib rcvd at Sun Aug 15 10:45:36 1982 Date: 14 Aug 1982 1654-PDT From: Dick Gillmann <Gillmann at USC-ECL> Subject: Info-PC Digest V1 #7 Sender: INFO-PC at USC-ISIB To: Info-PC: ; Info-PC Digest Saturday, 14 August 1982 Volume 1 : Issue 7 Today's Topics: Monitor Swap Program and 80 column color (2 msgs) IBM Pascal, MACRO, and all that stuff D/A Converters Qunix & IBM Pascal: mediocre Lattice C compiler for the IBM P.C. ---------------------------------------------------------------------- Date: 13 Aug 1982 2106-PDT Sender: BILLW at SRI-KL Subject: Program for release and 80 column color. From: William "Chops" Westfield <BillW@SRI-KL> To: Info-PC at ISIB If any of you have both color and monochrome displays in your IBMPCs, you may be interested in the program SRI-KL:<BILLW>SWAP.A86, which switches back and forth between them. Although it is written in a funny assembler format used by a cross assembler I run under unix, it is short enough that conversion should be easy. There is also a SWAP.HEX file, if that is any help. On a somewhat related note, I was surprised when running a program I wrote for the monochrome display using high intensity characters turned out to type green character on the color display. I thought you weren't supposed to get colors in 80 column mode on the color card? they are even legible (on an Amdek color II monitor). Perhaps SWAP sets the bits in a different manner than BASIC normally does, perhaps I just misunderstood. Ah well.... Enjoy BillW ------------------------------ Date: 14 Aug 1982 1622-PDT From: Dick Gillmann <Gillmann at USC-ECL> Subject: Re: Program for release and 80 column color. Sender: INFO-PC at USC-ISIB To: BillW at SRI-KL, INFO-PC Thanks for the SWAP program. I've copied it to the INFO-PC program library. The reason for the green characters in the RGB monitor is that the little BIOS note "color burst is not enabled" applies only to the composite video output. /Dick ------------------------------ Date: 14 Aug 82 1:55:49-EDT (Sat) From: R Dennis Rockwell <dennis.duke@UDel-Relay> To: info-pc at Usc-Isib Subject: IBM Pascal, MACRO, and all that stuff For a little background, I've been a UNIX hacker for several years; a thorough convert to C and program simplicity in general. This colors my feelings, as you will see later. I've been using the IBM Pascal compiler and the Macro assembler for several months now (I started as soon as I got enough memory to run the suckers). At first, I was learning Pascal and I hated it. As I learned more, and discovered what Pascal was good for (toy programs, mostly), I got more used to it. One of my first awful discoveries was that it is impossible to write a Pascal program smaller than 16K. In fact, if you use write or writeln, it is impossible to make a program smaller than 20K. This is because the library routines are lumped together into large pieces, instead of being lots of little chunks that only get loaded if you really needed them. My major objection was (and still is) that there are NO, repeat NO, libraries supplied except for runtime support of Pascal built-in features (if you call them that). At least UCSD Pascal (which otherwise sucks -- more later) provides enough software support to do cursor addressing (albeit nowhere near what the BIOS supports) and turtlegraphics. My first effort in MACRO was writing inkey (ala BASIC). Before that, there was no way AT ALL to use any of the non-typewriter keys (a great lack, and a source of my early frustration), including ALT-anything, the arrow keys, and the function keys (40 of them!). Next thing was writing cursor addressing support routines (mostly just hooks into the BIOS calls -- they're very complete). I also wrote hooks into the graphics BIOS calls, including good ways to use a dual-monitor system. I can switch back & forth easily. About this time I got annoyed about having to remember which registers I'd need to save and restore, and where the arguments were hiding, so I started on a macro package which would handle all these things for me. That's finished (or at least workable) and I have a compatible set for FORTRAN (ugh), so I can use my routines with either compiler. However, due to several deficiencies with the assembler, it takes about 10 minutes to assemble a 3000 byte (heavily commented) assembler file. Granted, this is because the save and restore macros are 50 and 30 lines respectively, but they're that way because there's no way to have a macro build another macro (i.e., build a list of pop instructions in reverse order from the pushes). I have to resort to making a bitmap of the registers I want saved, then saving them (to save them in bitmap order), then scanning the bitmap the other way around to pop them back again. Along the way I discovered that using EXITM (break to you C users) inside an if causes a warning diagnostic (Open conditionals). In making it easy to access passed parameters, it turns out that the EQU directive and the = directive are very different, although they're presented quite similarly in the documentation. You can EQU a complete address expression (i.e., table[bp+si]), but you can't redefine the symbol ever again. With =, however, you can infinitely redefine a symbol, but all you can define it to be is a numerical constant. Period. The obvious thing to do for parameter accessing is to define arg1 to be 8[bp], say. But then you can't use arg1 as a parameter name anymore. So, you define arg1 to be 8 and use it like this: arg1[bp]. Granted, that's sort of small stuff, but it's aggravating to find something done halfway. As for UCSD Pascal, don't even attempt it unless you only write toy programs. Especially don't try it if you need to do something requiring assembler hooks. It is NOT POSSIBLE to define a segment. At all. This means that you cannot define symbolic offsets, types, or any of those good things, to, for instance, poke into low memory (a necessity for my work). Also, the operating system that underlies the P-system shows entirely too much of its RT-11 heritage; you generally have to compress the contiguously- allocated disk several times a day; the system itself takes up an entire disk which you can't practically remove (it pages pieces of P-code in and off this; since it can't be persuaded to use more that 64K of memory, this is a real drawback). The compiler itself has to reside on another disk. And, it can't handle double-sided drives (which DOS can) (DOS 1.1, at least). Now for the brownie points! I found the Pascal compiler to be a good compiler in general; the documentation (especially considering I was learning Pascal out of it) is of good quality, and tells you most of what you need to know. I especially like the separate compilation features. It makes fair code, unless you've allocated a record with new, in which case it calls a range-checking subroutine at least once every statement (this can be turned off). The assembler seems to be able to do just about everything you need to do in order to use machine language effectively; there's a very nice STRUCture definition pseudo-op (using which you can do such things as [di].fieldname) and an automatic way of defining bitfields which generates masks and shift counts for you. Of course, I have complaints about the machine language itself (like you can't multiply or divide by a constant [immediate mode]), but there's absolutely no hope for that. (except literals? /Dick) The documentation is also good here, giving a complete rundown on all the instructions, and the addressing modes available. ------------------------------ Date: 14 August 1982 12:32 edt From: Walters.SoftArts at MIT-MULTICS Subject: D/A converters To: INFO-PC at USC-ISIB I am looking for a D/A converter card for the PC. It must have at least two channels. It would be nice to have 12 bits and a conversion time under 10 microseconds. Does anyone have any recommendations? ------------------------------ Date: 14 August 1982 1545-edt From: Brian N. Hess <Hess.Unicorn at MIT-MULTICS> Subject: Qunix & IBM Pascal: mediocre To: INFO-PC at USC-ISIB We at Mark of the Unicorn got Qunix when it first came out, and have been watching the updates ever since. I say watching because it just isn't good enough to really use full-time. The C compiler is O.K., but not spectacular. It works. The operating system is not really Unix -- the commands vary a little bit, and the file/directory structure is messed-up. The screen editor is O.K., but it's not like any of the ones you usually see on Unix systems. And without some sort of disk drive searching, it's frustrating to use since the command set which you want to access in Unix is so large, it's spread across two disk drives. This can be corrected if you have a Davong hard disk, which they claim to support. All of this is not really terrible; what you see here is me just complaining that "it's not exactly like Unix". But for an operating system which has no applications to run on it, no compatibility with DOS, either to get files or to port back compiled C programs, what more is there to look for than being an exact Unix copy? Some folks at The Architecture Machine Group at MIT got the IBM Pascal compiler when it first came out, and have been severely disappointed with it. Yes, it compiles most Pascal programs, but requires that you pass all three disks in and out of one drive, while leaving your program in the other drive. They gave up on it. Someone there said that the UCSD system was better, but I cannot verify just how bad the IBM one was nor how good the UCSD one is. The one good thing about the IBM Pascal is that you don't have to license the P-system to transport your applications to another machine. To sum up: They both work, and work acceptably. But not superbly. Brian ------------------------------ Date: 14 August 1982 1604-edt From: Brian N. Hess <Hess.Unicorn at MIT-MULTICS> Subject: Lattice C compiler for the IBM P.C. To: Info-PC at USC-ISIB To cheer up after that last message, here's some good news. The Lattice C compiler for the IBM P.C. is very good. It too is a little large, so I recommend having a pair of double-sided disk drives to try any serious applications, but it's possible to run on just singles, as we did for a little while. It has only a few bugs in it, but they are all possible to program around, and in general is of very high quality for a Version 1.0 product. Steeply priced from Lifeboat at $500. I assume that prices will drop drastically when Microsoft releases their C compiler with the "bridge-DOS" version which starts to take you from DOS to Xenix. Just talked to George _________ (sorry, don't remember his last name) at Computer Innovations, the C-86 folks. He claims to be optimizing his first works down so they match size and speed with the best of the C compilers and to have a linker for MS-DOS, even though the product runs on CP/M-86. Anybody used CP/M-86 on the P.C.? Good reports? Bad reports? For a vaguely informative comparison of MS-DOS to CP/M-86, look in the recent issue of Digital Design. They compare basic operating system features as well as utilities (and mention the few utilities of MS-DOS that IBM left out when producing their version). Brian ------------------------------ End of Info-PC Digest ********************* -------