glennw (08/20/82)
>From uucp Thu Aug 19 03:21:51 1982 >From uucps Thu Aug 19 03:13:39 1982 remote from mhuxa >From uucp Thu Aug 19 03:02:24 1982 remote from mhuxt >From uucp Thu Aug 19 02:54:13 1982 remote from eagle >From floyd!cmcl2!philabs!sdcsvax!vicki Thu Aug 19 02:43:42 1982 remote from harpo Date: Wed Aug 18 23:29:57 1982 To: philabs!cmcl2!floyd!harpo!eagle!mhuxt!mhuxa!mhuxh!glennw 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 ********************* -------