Copy Link
Add to Bookmark
Report

Info-Atari16 Digest Vol. 90 Issue 522

eZine's profile picture
Published in 
Info Atari16 Digest
 · 26 Apr 2019

  

INFO-ATARI16 Digest Mon, 7 May 90 Volume 90 : Issue 522

Today's Topics:
Bob Brodie in Rochester (mini-review), and TT talk
C++ for the ST?
C Packages
format program
How to do a cold boot.
Input/Output redirection with Pexec() (2 msgs)
Phantom
poolfix3, poolfix4; naming conventions.
Problems With BMS-100 & 520ST...
Revolver again
Zmodem and the ST...
----------------------------------------------------------------------

Date: 3 May 90 02:50:15 GMT
From: usc!samsung!dali!ogicse!uidaho!tribe@ucsd.edu
Subject: Bob Brodie in Rochester (mini-review), and TT talk
Message-ID: <1990May3.025015.7312@groucho>

In article <1837@fredonia.UUCP> fredonia!sale5312@cs.buffalo.edu (Marty Saletta)
writes:
> Mr. Brodie also mentioned that Atari feels that the 130XE is no longer
>a "power without the price" computer, and will phase-out the 8-bits....

The demise of the 8-bits has been soundly thrashed out on all possible forums,
yet, what of the brave souls who bought XE-GS's? How long will Atari continue
XE-GS cartridge development/production? Just their fault for not buying a
nintendo? :-P

--
Duane Tribe, Computer Science, University of Idaho, Moscow, ID USA
tribe@ted.cs.uidaho.edu

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

Date: 7 May 90 13:33:13 GMT
From: m2c!seqp4!markr@husc6.harvard.edu (Mark Roddy)
Subject: C++ for the ST?
Message-ID: <492@seqp4.UUCP>

Yes there is. Tim Onders (onders@harvard.uucp) has
made available the GNU port to the ST.

An almost complete minimal system was uploaded to CIS :-$,
(no gas Tim.) And I can testify that:

cout << "Hello C++ World\n";

works.

In addition, Tim will real mail you the complete ST
distribution of the GNU stuff for $35US. Contact him
via e-mail for more information.

And just when I was ready to junk the puppy someone ports
something worthwhile to it!

--
-Mark Roddy
seqp4!markr@m2c.org
m2c!seqp4!markr

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

Date: 6 May 90 20:22:31 GMT
From: umigw!umiami!dnd15j9z@handies.ucar.edu (Frank Rachel)
Subject: C Packages
Message-ID: <6304.26444f47@umiami.miami.edu>

I am currently learning C, and would like to buy a good C package for the
St, so basically, what is available, and what is best?

Should I wait for Turbo C in English? (Is it even coming?) I have Sozobon,
but I would like a commercial package for the manual and stuff..

Any comments appreciated. EMAIL please..

-Frank

---------------------------------------------------------------------------
Frank Rachel | Internet:Dnd15j9z@Umiami.Miami.edu | University Of Miami
---------------------------------------------------------------------------

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

Date: 7 May 90 23:40:55 GMT
From: mcgill-vision!quiche!calvin!depeche@bloom-beacon.mit.edu (Sam Alan EZUST)
Subject: format program
Message-ID: <3357@calvin.cs.mcgill.ca>

I use Pcommand and gulam frequently, and hate having to leave
the shells to go to the desktop whenever I want to format.
So I decided to start writing a program which works like the
pc formatter, i.e.

format a: /s2 will format a: for double-sided disks.

I am using the example from Laser C which formats disks (pg451 of the
manual) Here is my problem:

I also want to be able to format 10 sectors/track. Unfortunately, the
procedure which writes boot sectors, Protobt, has 4 possible disk
types, none of which are 10sectors/track.

Also, how come the procedure which writes bootsectors to the disk
first writes 0'd buffer to track 0, if presumably, the procedure
is being called right after a format??

And for double-sided disks, isn't it necessary to zero the second
side of track 0 as well [if it is necessary to do the first side].

Oh well. Also, if I am re-inventing the wheel, and you happen to have
done it already, could you send it to me?

--
|S. Alan Ezust | depeche@calvin.cs.mcgill.ca|
|McGill University School of Computer Science | Montreal, Quebec, Canada |
|---------------------------------------------------------------------------|
| "The mind is a terrible thing...." |

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

Date: 7 May 90 22:54:37 GMT
From: dino!ux1.cso.uiuc.edu!cs325ec@uunet.uu.net (Gregory Lemperle-Kerr)
Subject: How to do a cold boot.
Message-ID: <1990May7.225437.26474@ux1.cso.uiuc.edu>

Could someone post C or assembly code on how to do a cold boot?

(TOS 1.4, Atari1040 if that's pertinent)

Thanks in advance.

-- Greg

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

Date: 7 May 90 22:57:12 GMT
From:
swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!cs325ec@u
csd.edu (Gregory Lemperle-Kerr)
Subject: Input/Output redirection with Pexec()
Message-ID: <1990May7.225712.26820@ux1.cso.uiuc.edu>

adp1@csug.cs.reading.ac.uk (Andrew Pollard) writes:

>Hello,
> Please could anyone tell me how to redirect standard input and output before
>a program is Pexec'ed. As far as I can tell, as soon as the program is started,
>it resets its standard channels. I am trying to write a simple command shell.

Can't one just replace the gemdos trap vector with an address of one's own
routine? Check if it is a output call and buffer or save the output to
a file.

-- Greg

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

Date: 7 May 90 15:57:42 GMT
From: mcsun!ukc!reading!csug.cs.reading.ac.uk!adp1@uunet.uu.net (Andrew
Pollard)
Subject: Input/Output redirection with Pexec()
Message-ID: <2330@onion.reading.ac.uk>

Hello,
Please could anyone tell me how to redirect standard input and output before
a program is Pexec'ed. As far as I can tell, as soon as the program is started,
it resets its standard channels. I am trying to write a simple command shell.

Thanks,
Andrew

================================================================================
| Andrew Pollard | adp1@uk.ac.reading.cs.csug |
| Dept of Computer Science | adp1%uk.ac.reading.cs.csug@uk.ac.nsfnet-relay |
| Reading University | |
| England | |
================================================================================

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

Date: 7 May 90 18:00:00 GMT
From:
swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!dkuug!imada!micro@ucsd.edu
(Claus Pedersen)
Subject: Phantom
Message-ID: <751@imada.dk>

We hear about the Phantom all the time, at first I didn`t believe in
`it`... (for a year or so) and then it stroke me in Tempus.

I were able to have `it` for 3 hours (moving the mouse really speeds
things up).

Ok I were able to quit Tempus, returned to the desktop and every thing
still were acted very slow (clicking and moving the mouse simultaneously is
kind of tricky...).

But now to the interesting parts, disconnecting the keyboard on my
MEGA (and thereby Reseting the keyboard cpu) did not affect the phantom,
notice that pressing the reset botton on an MEGA does not reset the keyboard
cpu...

More interesting things, starting new GEM programs did not affect the
phantom either...

BUT NOTICE - starting a non GEM program momentally stopped the phantom.
I started BUG - the debugger from the turbo C package, and everything
was as nothing had happened. I looked after suspicious code on the system
vectores (viruses) but I were not able to find anything.
When returning to the desktop the phantom were there again...

Then I killed the phantom, it`s easy - just press CTRL-ALT-DELETE and off
he goes... (or the little botton at the back called RESET).

Where does this leave us ?
- Not hardware (surely not the keyboard).
- Not in the TOS (Bug uses Gemdos, Bios, Xbios).
- Could be in GEM somewhere (I had a drawing program running too -
so it could not be in the VDI)
+ this leaves us with the AES...
- what about the dispatcher (evnt_xx calls) ??

I guess this problem is for the people at Atari to fix...


- Klaus (micro@imada.dk).

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

Date: 7 May 90 16:32:43 GMT
From: mcsun!unido!fauern!fauern!csbrod@uunet.uu.net (Claus Brod )
Subject: poolfix3, poolfix4; naming conventions.
Message-ID: <2709@medusa.informatik.uni-erlangen.de>

Dear Mr Pratt,

since I don't have regular access to Usenet, this letter might be somewhat
late. People have told me about your reactions towards my version of POOLFIX,
and I would like to add some comments.

You're right, naming my POOLFIX version "POOLFIX4" was foolish. I've
changed that quite a while ago; unfortunately, Chris posted POOLFIX4
before I renamed it to POOLF_CB (just a suggestion, I've not settled
yet about the final naming). So if this is your only problem with it -
it's been solved. Sorry.

I always thought ATARI had an interest to spread TOS bug fixes as widely
and as fast as possible. Everyone owns FOLDRxxx, for example, and ATARI
doesn't moan about it - though not everyone has bought an original
ATARI hard disk. I didn't want to infringe any copyrights, as you
supposed, I have always stated very clearly in the POOLF_CB readme file
that this program was originally written by you, that I didn't claim
any rights on it, and that I only improved it a bit.

You also felt unhappy about me possibly being a malicious hacker spreading
dangerous code under the hood of an original ATARI program's name. POOLF_CB
and POOLFIX4 are no Trojan horses, and I've invested much time and effort
to verify that it works properly. I've sent POOLF_CB to ATARI Germany
hoping that it might find it's way to you. I didn't wait for your
approval, true, and I regret this, but I had my reasons: People found
out that POOLFIX3 (your version) didn't work when my hard disk driver
was running, and soon there were rumours that my driver was faulty. This,
however, isn't true, but it started to damage my reputation among European
users. I didn't like that, so I sat down to find out more about it,
disassembled POOLFIX3, found out why things went wrong, and patched it.
Some friends needed this version badly, and so I gave it to them, and I
even allowed Chris overhastedly to spread it via Usenet because I felt
strong demand for it.

Another point: You were in doubt whether it's worthwhile to optimize
the POOLFIX code in order to obtain a smaller program. Well, I think
it is. (This isn't much of a surprise for you, I know.) True, it will
save you just a few bytes, but if ATARI had done a little-bitzy-eenie-
weenie bit of optimization in their ROM code it would have been possible
to include GDOS into the TOS ROMs. (When the ST appeared here, ATARI
officials always said that GDOS was published separately because it
didn't fit into the ROMs.) Think of all the trouble this would have
saved us: Thousands of proprietary printer drivers and hundreds of
GDOS incompatible programs. It also would have improved the reputation
of ATARI's implementation of GEM. If you don't believe me you can
squeeze GDOS into the 192 KB ROMs, ask our German hackers for a version
of their improved TOSses. (Besides: I recently did a bit of optimization
on the current German GDOS version, AMCGDOS, and it lost some 2 KB in
size out of nearly 8 KB. Don't worry, I won't spread it, I'm just
using it for my own ST - only the author of AMCGDOS received a copy.)
Some of those hackers mentioned above saved so much code that it became
possible to include a new Macish DESKTOP, new window features, a complete
hard disk driver, and, last but not least, GDOS. Needless to say that
they also squeezed TOS 1.6 into 192 KB ROMs. Don't panic, since ATARI
doesn't seem to want outside improvements for TOS, they won't spread
it. Some of them, however, have written long and detailled letters to
ATARI about ways of optimizing TOS, and apparently there has been no
reaction. (The bug patched by POOLFIX, for example, has been known
here since the 8-8-88 beta version of TOS 1.4, and it has been
reported to ATARI before the end of the beta test phase.)

POOLFIX will find it's way into thousands of AUTO folders, so it will
cost most of us some of our precious RAM. Yes, I think it's worthwhile
investing some effort in it.

I will stop optimizing POOLFIX and copying it to my friends who beg for
it if you want me to. But then, I'd like to ask YOU for an official
POOLFIX4 version from you that doesn't collide with my hard disk
driver and numerous AUTO folder programs any more, so that I can
stop wasting time telling readers twice a day that my driver is OK,
and that the problem lies in POOLFIX3, and they should use POOLF_CB
if they can get it anywhere, but no, I won't copy it because ATARI
doesn't want me to, or they should delete POOLFIX3 from their AUTO
folder or use another hard disk driver. Please!

I strongly hope we will come to a good compromise that satisfies the
needs of all ST users. Apart from that, I really appreciate that you
follow this discussion and comment on selected items. It has been
a great help for us here in Germany. Keep it up!

Sincerely,

Claus "all-time optimizer" Brod

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

Date: 7 May 90 20:27:03 GMT
From: dinghy.cis.ohio-state.edu!mowgli@tut.cis.ohio-state.edu (Mowgli Assor)
Subject: Problems With BMS-100 & 520ST...
Message-ID: <80180@tut.cis.ohio-state.edu>

I've been having major problems with my ST lately. The system is a 520ST,
Z-RAM 2.5M upgrade, BMS-100 HD I/F, & 2 20Meg HDs. The first HD has part-
itions C, D, E, & F (5M each). The second HD has partitions G (2M), H (3M),
& I (15M). And, the RAMDisk is partition J.

The problem is, when I boot with my HD on (using the HD boot disk), the system
runs things off both the floppy drive (A) & the 1st HD partition (C). It also
copies a whole bunch of files from partition C to the RAMDisk (J). Then, when
I get to the desktop, NO ICONS show up at all! This has lead me to the conclu-
sion that the primary FAT is in la-la-land. The files copy from the HD to the
RAMDisk properly, so I know the HD is still there SOMEWHERE.

So, does anyone have any other theories as to what has happened? And, more
importantly, can anyone point me to tools which will perhaps resurrect the FAT,
so that I don't have to reformat my HD to use it again?

Thanks, <Mowgli>
-=-
Address: mowgli@puffer.cis.ohio-state.edu (Mowgli Assor in real life)
Or: mowgli@cis.ohio-state.edu, mowgli@osu-20.ircc.ohio-state.edu
The 2 precepts of Semi-Divinity: (1) Mind Thine Own Business.
(2) Don't Worry About It.

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

Date: 7 May 90 23:43:35 GMT
From: mcgill-vision!quiche!calvin!depeche@bloom-beacon.mit.edu (Sam Alan EZUST)
Subject: Revolver again
Message-ID: <3358@calvin.cs.mcgill.ca>

Sigh.. I just called E. Arthur Brown to order Revolver, and the
guy said that he thinks Intersect is going under, based on the
fact that he doesn't have any copies of Revolver.

Can anyone confirm or deny this rumour please? If Intersect
is dropping support for Revolver, what should I get instead?

If there is someone in Florida who wouldn't mind calling them
and interrogating them for me, their number is 813-923-8774.

--
|S. Alan Ezust | depeche@calvin.cs.mcgill.ca|
|McGill University School of Computer Science | Montreal, Quebec, Canada |
|---------------------------------------------------------------------------|
| "The mind is a terrible thing...." |

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

Date: 7 May 90 02:52:34 GMT
From: cca.ucsf.edu!wet!logic@cgl.ucsf.edu (Henry Kwan)
Subject: Zmodem and the ST...
Message-ID: <1196@wet.UUCP>

Is there a terminal program out there which has a good implementation of
Zmodem? I'm currently using ZMDM v1.85, which gives fairly good throughput
on downloads (
correctly on uploads (
but they don't even seem to work at all. I thought that the Mac terminal
situation was bad but recently with Zterm, MP III, and WK, they have at
least three programs with good Zmodem whereas we don't have any (that I've
found). Anybody have any good ideas or tips?

--
Henry Kwan | AppleLink: D0690
FWB, Inc. | CompuServe: 71320,1034
2040 Polk St. Ste 215 | Internet: claris!wet!logic@ames.arc.nasa.gov
San Francisco, CA 94109 | UUCP:

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

End of INFO-ATARI16 Digest V90 Issue #522
*****************************************

← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT