Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Info-PC Digest V2 #9

3 views
Skip to first unread message

INFO-PC@usc-isib

unread,
Feb 15, 1983, 2:25:16 AM2/15/83
to
From: Dick Gillmann <INFO-PC@USC-ISIB>

Info-PC Digest Friday, 11 February 1983 Volume 2 : Issue 9

Today's Topics:

Microsoft Flight Simulator
Basic Compiler Bug
C Language and Pointers (3 msgs)
HERCULES Graphics Card (2 msgs)
Mailing List Program
The Dangers of Coffee
PC Uses for the Handicapped
Assembly Language MODEM7
Aparrat Memory Board

----------------------------------------------------------------------

Date: 8 Feb 83 07:40:33 EST
From: SHOLAR@CMU-CS-C
Subject: Re: Microsoft Flight Simulator
To: INFO-PC@USC-ISIB

The Microsoft Flight Simulator seems to do a remarkable job of
simulating a Cessna 182. If you ignore the window display and look at
the instruments, it seems to behave much like the GAT I use once in a
while. In VFR flight, it lacks a bit of realism because you must
manipulate the keyboard in order to look out of the windows at
different angles -- you can't easily turn your head, in other words.

I can only compare it to the GAT and a C-152, and find that it doesn't
do too badly. A flight instructor friend tried it, and with only 30
seconds of familiarization with the controls, he seemed to feel right
at home.

Well worth the $50.

Bill

------------------------------

Date: 7 Feb 83 10:06:06-PST (Mon)
To: info-pc@isib
From: harpo!floyd!vax135!cornell!roger (Roger Hoover)@Berkeley.arpa
Subject: Basic Compiler Bug

Has anyone else had the IBM Basic compiler give the error

Internal error -- String space corrupt

when another error (trapped or untrapped) was encountered? The
problem was noticed on several large chained segments using the run
time library.

------------------------------

Date: 8 February 1983 2217-mst
From: Paul Schauble <Schauble @ M.PCO.LISD.HIS>
Subject: C Language and Pointers
To: Info-PC @ USC-ISIB

Pardon me for responding this way, but you have stepped on one of my
very sore toes.

Subject: Re: Optimized C86 C Compiler
From: Billy <BRACKENRIDGE@USC-ISIB>

Would you explain to me how Computer Innovations can support 20-bit
address space and still maintain compatibility with any other C
language? It is fundamental to C that integers and pointers be the
same size. I can't see any way out of this dilemma except the
approach taken by Lattice. You just ain't going to have a 32-bit C on
the 8086 until Intel announces a 32-bit successor to the 8086/8.

Wrong! Wrong! Wrong!

"5.6 Pointers are not integers

You may notice in older C programs a rather cavalier attitude toward
copying pointers. It has generally been true that on most machines a
pointer may be assigned to an integer and back again without changing
it; no scaling or conversion takes place, and no bits are lost.
Regrettably, this has led to the taking of liberties with routines
that return pointers which are then merely passed to other routines --
the requisite pointer declarations are often left out...

This will work on many machines, since the default type for functions
is <int> and <int> and pointer can usually be safely assigned back and
forth. Nevertheless this kind of code is inherently risky, for it
depends on details of implementation and machine architecture which
may not hold for the particular compiler you use. It's wiser to be
complete in all declarations. (The program <lint> will warn of such
constructions, in case they creep in inadvertently.)"

"The C Programming Language"
Kernighan & Ritchie

Notice that this was written in 1978. The equivalence happened to hold
for the PDP-11, by accident. The authors acknowledge that it works,
but is not proper use of the language. As C has been implemented on
more and more machines, the ability to use the equivalence has been
less and less.

I am currently working with C on three machines. Of those, the
equivalence between pointers and ints holds on one, fails on another,
and probably (I haven't seen the compiler yet) on the third. One out
of three.

Having recently spent time trying to get Unix to run on a machine
where the equivalence did NOT hold, I feel that code that depends on
this "feature" is inherently brain-damaged.

Paul

------------------------------

Date: 10 Feb 83 08:31:51 PST (Thu)
From: npois!inuxd!stevens@Berkeley
Subject: C Language and Pointers
To: INFO-PC@ISIB

It certainly is NOT fundamental to the C language that integers and
pointers be the same size. It may be true of most implementations,
but it was never guaranteed in the C Bible (Kernighan & Ritchie).
Programs that do weird things like store pointers into integers are
NON-PORTABLE.

-- Scott Stevens
-- npois!inuxd!stevens@berkeley

------------------------------

Date: 11 Feb 1983 2303-PST
Subject: C Language and Pointers
From: Dick Gillmann <GILLMANN@USC-ISIB>
To: Info-PC
cc: Brackenridge

Paul and Scott,

I must begin by saying that I'm not a C programmer. I read Kernighan
and Ritchie's book on the language and I'm eager to try it on my PC
(I've been writing in assembly language). To my amazement, I was
unable to find a compiler that supported 20-bit addresses.

This mystifies me. Why should I have to live in 64K? Not supporting
the 20-bit address space seems like a major flaw. In fact, now that
memory is so cheap, 20 bits seems rather limited.

It's certainly true that writing programs that depend on coincidences
of representation is bad practice. So why don't C compilers support
20-bit addresses as a matter of course?

/Dick

------------------------------

Date: 7 Feb 83 9:05:16-PST (Mon)
To: info-pc@isib
From: teklabs!kei...@Berkeley.arpa
Subject: HERCULES Graphics Card

Responses to:

"Why not just purchase the IBM monochrome card? The monochrome card
works fine with monochrome monitors. The color card is awful with
monochrome monitors. The Amdek 310 (A?) I saw was as good as the IBM
monochrome monitor; the 310 was the display for the Columbia IBM PC
look-alike."

First, I find it difficult to believe that the IBM monochrome card
will drive a standard (i.e. b&w version of NTSC rate video) monitor,
because the IBM monochrome H-rate is 18.4 kHz (cf. 15.75 kHz for
standard) and its V-rate is 50 Hz (cf 60). But I haven't tried it yet
- I will this afternoon and if it DOES work I'll let you know.

Second, I tried out the Hercules card and found it deficient for my
used in its lack of compatibility with existing software. The only
patch sent with it is to the BASIC interpreter; AND it only works with
hi-res graphics (i.e. BASIC's SCREEN 2). So you can toss your
compiled code out the window, and a lot of games (which use low-res,
SCREEN 1) don't work. I called Hercules and they said they are going
to supply additions to the BASIC compiler to improve compatibility,
but what I THINK (but am not sure) they need to do is to supply a
replacement BIOS ROM so that (almost?) everything will work with it.

Enlightening criticisms/additions are welcomed.

Keith Ericson

------------------------------

Date: 10 Feb 1983 0946-PST
Subject: Re: HERCULES Graphics Card
From: Randy Cole <COLE@USC-ISIB>
To: teklabs!keithe@UCB-VAX, info-pc

Keith:

I believe your doubts about the IBM monochrome card driving a standard
15.75 kHz monitor are correct. However, my understanding is that the
Amdek V310 monitor was designed (modified) to use the 18.4 kHz scan
rate put out by the IBM monochrome board and is sold as a cheap
alternative to the IBM monitor.

Your comments on the Hercules card are very interesting. The lack of
software is perhaps less drastic in the cases of languages like
Pascal, Fortran, etc., which have no graphics primitives built in. I
don't think a new ROM would be necessary to make such a card respond
correctly to any BIOS call. What would be necessary would be to
rewrite the graphics primitives and replicate any other code that used
the same software interrupt vector, put that code into memory and
protect it from being clobbered, and redirect the interrupt vector.

Question: When in text mode, are the characters put out by the
Hercules card identical to the higher-resolution characters the IBM
monochrome card puts out, or are they 5x7 characters like the
color/graphics card puts out?

Randy Cole

------------------------------

Date: Thu 3 Feb 83 08:35:52-PST
From: Hellmut Golde <GOLDE@WASHINGTON>
Subject: Mailing List Program
To: gillmann@USC-ISIB

I have used PC-File from Dick Button in Bellevue; it is one of the
Freeware programs. I find it simple to use, good to maintain mailing
lists, and inexpensive. ($25 or $35). Jim Button, P.O. Box 5786,
Bellevue, WA 98006. Just drop him a note and he will send you a
floppy, I think.

--Hellmut Golde

------------------------------

Date: 10 Feb 83 18:09:55-EST (Thu)
From: D. J. Farber <farber@udel-relay>
Subject: The Dangers of Coffee
To: info-pc@isib

I can report that PC keyboards are badly affected by coffee. Also
diskettes do not work when they have been soaked with coffee.

Dave

------------------------------

Date: Fri 11 Feb 83 10:59:49-PST
From: Guillermo A. Loyola <CSL.La...@SU-SCORE.ARPA>
Subject: PC Uses for the Handicapped
To: inf...@USC-ISIB.ARPA
cc: human...@RUTGERS.ARPA

I'd like to hear from anybody doing work in the area of Personal
Computer uses by handicapped persons. We have a coworker with
cerebral palsy. Some software has been written for him using a speech
synthesizer but a lot more is needed. The guy who wrote the software
(who has no access to the net, but I can set up the contacts) would
really like to start a dialog with people working in this area.

Please replay to me directly with a U.S. Mail address and/or phone
number. Thanks.

Guillermo.

------------------------------

Date: 11 Feb 1983 1223-PST
Subject: Assembly Language MODEM7
From: LEVYAL at USC-ISI
To: info-pc at ISIB

I once ran across a MODEM7 for the PC but can no longer locate it. I
would appreciate any help. Need it in assembly language. Thanks,

Allan

------------------------------

Date: 11 Feb 1983 22:35:11 EST (Friday)
From: Martin Schoffstall <schoff at BBN-UNIX>
Subject: Aparrat Memory Board
To: info-pc at isib

Being cheap, and also having about 30 64K Intel RAMs on hand, I
ordered the Aparrat memory board with 64K installed and have now
received it in Boston for $153.

Included in the price is their pseudo disk software that allows you to
implement a disk in memory in 64K * N (N=1 to 5) user selectable
increments as drive D.

They both work well except for some flakiness described below:

With the board stuffed with 256K of RAM and all the proper switches
set both on the system board and the RAM board at boot up the
following memory errors showed up after four different boots

3caa201
3cf9201
3caa201
3ca0201

Not very consistent! Being a software person, I ignored it and used
some canned software like 123 etc. for about an hour. I then booted
the system three more times and guess what? NOTHING. Just a normal
boot to DOS. Any ideas? How about cold memory chips!?

schoff at bbn-unix

------------------------------

End of Info-PC Digest
******************************
-------

0 new messages