Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 90 Issue 086
=========================================================================
INFO-ATARI16 Digest Tue, 23 Jan 90 Volume 90 : Issue 86
Today's Topics:
ARC 6.02 bugs
dissassembly
GNU/Sozobon C question
Mac ROMS
Need Hard Disk Wisdom
writing "tee" for the ST
----------------------------------------------------------------------
Date: 22 Jan 90 21:17:19 GMT
From: ucsdhub!hp-sdd!hp-pcd!hplsla!andyc@ucsd.edu (Andy Cassino)
Subject: ARC 6.02 bugs
Message-ID: <5440098@hplsla.HP.COM>
|
| It turns out that I can not get ARC 6.02 to work with any of the graphical
| shells I have for ARC (ARCSHELL, ARCGSH21, UNARC). All of them produce either
| two or four bombs (it keeps changing) when they go to execute ARC. The older
| version of ARC (v5.21b I think) runs fine with all of these shells.
|
| Has anyone else had trouble with ARC V6.02 running under these shells? I
| assume it is working for most people since no one else has mentioned the
| problem.
|
| ----------
I'm using ARCSHELL 2.1 with ARC 6.02 with no trouble under TOS 1.4. There is
supposed to be ARCSHELL 2.1b out now to rectify some bug or another with
ARC 6.02, but I haven't seen the bug nor do I have v2.1b....
Disclaimer: The opinions expressed herein are those solely of the author,
who has no pecuniary interest in the companies, products,
or publications mentioned above.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Andy Cassino %
% uucp: hplabs!hplsla!andyc domain: andyc%hplsla@hplabs.hp.com %
% Hewlett-Packard Lake Stevens Instrument Division %
% 8600 Soper Hill Road Everett, WA 98205-1298 %
% (206) 335-2211 %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
------------------------------
Date: 23 Jan 90 17:04:23 GMT
From: voder!pyramid!athertn!alex@ucbvax.Berkeley.EDU (Alex Leavens)
Subject: dissassembly
Message-ID: <17035@laurel.athertn.Atherton.COM>
Daniel Glasser writes:
>In my honest opinion, biased as it may be, the MWC manual is the single
>best volume for programming the ST published to date. It needs revision,
>bugfixing, and maybe some other tweeking (new GEM examples, etc.) and
>the compiler should be updated, but it is still a very good package at a
>good price.
Seconded. Whenever I'm writing GEM code, the first thing I look in
is the MW manual. If I can't find it there, I look in the HitchHiker's
Guide, or somewhere else. But I can usually find it in MW. It's
really good.
--
|-------------------------------------------------------------------------|
|--alex | alex@Atherton.COM | Caution! Falling Opinions, next 6 miles |
| Now who are you gonna believe--me, or your own lyin' eyes? |
|-------------------------------------------------------------------------|
------------------------------
Date: 23 Jan 90 19:34:36 GMT
From:
zaphod.mps.ohio-state.edu!uwm.edu!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!w
atserv1!watdragon!tiger!swklassen@tut.cis.ohio-state.edu (Steven W. Klassen)
Subject: GNU/Sozobon C question
Message-ID: <20086@watdragon.waterloo.edu>
In article <894@per2.UUCP> dag@per2.UUCP (Daniel A. Glasser) writes:
>A large part of the speed "problems" that the MWC compiler has is because of
>this history. A version (built from the same sources) ran on a PDP-11 as
>a cross compiler until version 3. The PDP-11 has only 64k of virtual
>address space. The compiler, therefore, uses disk files to store intermediate
>code and chains between programs to do various stages of compilation.
>The advantage to this is that the MWC compiler can run effectively in systems
>with limited memory (512k with DAs loaded) and can handle programs larger than
>available memory. I've linked an 800k program on a 520 with MWC.
The speed problem can be minimized through the use of the ram-disk
(if you have the memory for it - ie. at least a 1040). A very nice
ram disk is included in the MWC package. The 'disk' files used for
intermediate code and stuff are then written in the ram disk, ie. almost
as fast as using main memory directly (there may be some overhead in
the maintenance of the ram disk but it likely isn't too bad). Multiple
passes through the data is very slow on a disk but not bad at all on
a ram disk.
I must admit, however, that I haven't made any comparisons between
compile speed of different compilers. I consider that issue to
be of lower priority than run speed (ie. I will put up with slower
compile times if I get better run times as a result.).
Steven W. Klassen +-----------------------------+
Computer Science Major | Support the poor...buy fur! |
University of Waterloo +-----------------------------+
------------------------------
Date: 22 Jan 90 16:56:07 GMT
From: njsmu!telesci!cciolori@princeton.edu (Christopher Ciolorito)
Subject: Mac ROMS
Message-ID: <938@telesci.UUCP>
Perhaps this is a silly question, but I will ask it anyway.
Everyone knows that the ST can mimic the Mac with the right hardware,
software, and of course the Mac ROMS.
In addition, a message had been posted which indicated that the new
TT machine would allow the ST to run Mac software at high speed,
which could give apple some stiff competition if Atari took advan-
tage of this, and made the public aware that this software/hardware
exists.
A great ad campaign would tell potential buyers that the Atari, in
addition to running its own software, could also run IBM, and Mac
stuff too!
....then I got to thinking...let's say that Atari did begin take
advantage of this oppurtunity, and in fact were hurting Mac II sales.
Couldn't Apple just say FORGET IT and NO LONGER SELL anyone Mac
ROMs? Or would it be more profitable to allow Atarians to continue
to buy them? I mean, they are making money when people buy them,
although I am sure they would rather be selling THIER computers
along with them.
Just a thought...what does everyone think?
Chris
------------------------------
Date: Tue, 23 Jan 90 10:27:54 -0900
From: <FNDDR%ALASKA.BITNET@CUNYVM.CUNY.EDU>
Subject: Need Hard Disk Wisdom
In <7500012@m.cs.uiuc.edu>, totty@cs.uiuc.edu writes:
> I'm sure this subject has been covered many times, but I
> haven't been reading this group for a long time. I am
> interested in obtaining info from anyone about building
> hard disks fro the ST. Advice on interfacing, drive/controller
> recommendations, power supply choices, cases, and difficulties
> about the ST. Please email to me if the subject has been beaten
> to death.
Not beaten to death recently, I think.
I've built three 60 MB drives using the BMS-200 kits from E. Arthur Brown.
EABCo sells the BMS host adapter, case, and power supply...you buy the
drive elsewhere. I bought ST-277N drives from Hard Drives International
(they advertise in Computer Shopper and Byte).
It takes less than an hour to put the drive together and install it, if
you follow EABCo's somewhat sparse instructions correctly. Construction
consists of attaching the DMA cable, a ribbon cable, two power supply
connectors, and mounting the drive and host adapter in the case. The
BMS software has a nice boot-holdoff feature that waits until the drive
spins up before starting the boot process, so you don't have to power up
the drive and ST separately. Other than that, the BMS software is pretty
basic. There's a battery-backed clock on the host adapter which can be
read from a program in the auto folder. Some considerations:
1. The cost of everything plus shipping is much cheaper than comparable
drives from Supra or Atari, but there are other options, such as ICD
and Toad Systems, which are in the same price range as BMS.
2. Two of the drives worked fine the first time, but a third had a flakey hard
drive which sort of worked for a few weeks, then died. HDI replaced it,
but I found arranging the replacement very annoying. Calling HDI's
support line seems to involve a mandatory wait of 20-30 minutes on hold,
and it isn't an 800 number. It also took them a month to come up with
a replacement, compared to two days to ship the original. In contrast,
both EABCo and BMS were very helpful and responsive in diagnosing the
problem.
3. The BMS software is very basic, limited to 4 partitions @ 16 MB. The
EABCo version simplifies the BMS package by supplying special setup
programs for Seagate SCSI drives ONLY; they omit "confusing" information
about setting up other types of drives. If you want to use another brand
of drive, you should buy the BMS-200 directly from BMS. BMS suggests using
Atari's hard disk software if you want bigger or more partitions...
apparently they aren't planning to support those options anytime soon.
4. With the EABCo setup, there is a spare power supply connection. You should
be able to add a second SCSI hard drive for the price of the drive, a
SCSI ribbon cable, and a second case (no room in the first case due to
the host adapter). How you could get the power and SCSI cables to the
second drive is left as an exercise for the ambitious.
The main advantage of the SCSI solution is ease of upgrade. You can buy a
small SCSI drive and replace it with a big one later, and you have a good
chance of selling the original in the pc/mac marketplace. I think that the
BMS system from EABCo is a reasonable choice, particularly if you enjoy
tinkering, but check out ICD and Toad options as well.
Good luck,
Don Rice
FNDDR@ALASKA.bitnet
Notes:
EABCo = E Arthur Brown Co, 612-762-8847
BMS = Berkeley Micro Systems, 415-547-2191
HDI = Hard Drives International, 800-234-DISK
ICD, Toad: look them up in your favorite ST mag
------------------------------
Date: 23 Jan 90 18:08:06 GMT
From: mcgill-vision!quiche!calvin!depeche@BLOOM-BEACON.MIT.EDU (Sam Alan EZUST)
Subject: writing "tee" for the ST
Message-ID: <2027@calvin.cs.mcgill.ca>
I asked this question a little while ago and got some responses from
people who had good intentions but not enough facts about how to solve
the problem...
How hard could it be to get a program to send all its output to
the a file or the printer WITHOUT changing the screen output?
i.e. I'd like to direct output to a file but I also want to see what it
is on the screen, so I can run interactive programs and save all the output.
This would be easy if there was a shell which supported pipes, but contrary
to popular belief, GULAM does not support such, and neither does
mwc shell (it simply redirects the output of one program until it is
finished, and then runs the second taking the file it created before
and redirects the input of it to this file.) A real pipe needs multitasking,
I guess.
Do standard output calls use a system call to print characters on the screen?
if so , perhaps changing the vector for that call to another routine
which first sends the character to the printer and then calls the
original system call would do the trick.
I am a novice in this area of system programming - I only know the theory.
Has anyone actually done something like this?
--
S. Alan Ezust depeche@calvin.cs.mcgill.ca
McGill University School of Computer Science - Montreal, Quebec, Canada
If pro is the opposite of con, what's the opposite of progress?
------------------------------
End of INFO-ATARI16 Digest V90 Issue #86
****************************************
