🚀 go-pugleaf

  Added from the X.400/EARN-Gateway: Undeliverable Mail
  Notification message, may be wrong recipient

Received: from DEARN.BITNET by DFNGATE.BITNET.DBP.DE (Mailer R2.03B) with BSMTP
 id 7033; Sat, 05 Aug 89 02:51:39 EST
Received: by DEARN (Mailer R2.01) id 5210; Sat, 05 Aug 89 02:51:33 EST
Date:         Fri, 4 Aug 89 15:44:37 PDT
Reply-To:     Info-Atari16@Score.Stanford.edu
Sender:       INFO-ATARI16 Discussion <INFO-A16@DEARN>
Comments:     Warning -- original Sender: tag was
              Info-Atari16-request@SCORE.STANFORD.EDU
Comments:     Warning -- original Sender: tag was INFO-A16@MARIST
From:         Info-Atari16 Digest <Info-Atari16@SCORE.STANFORD.EDU>
Subject:      Info-Atari16 Digest V89 #366
To:           Gerhard Ahlers <AHLERS@PHYSIK.UNI-BIELEFELD.DBP.DE>

Info-Atari16 Digest   Friday, August  4, 1989   Volume 89 : Issue 366

This weeks Editor: Bill Westfield

Today's Topics:

                              evnt_keybd
                      DVT VCR Hard Drive backup
                             FOR SALE...
                           GNU Tar sources
Re: GNU-Emacs 18.51 for Atari ST (TOS) posted to comp.binaries.atari.st
                1MB piggyback details - how to [LONG]
                   Re: putchar() getchar() problem?
                        Re: Amiga vs. Atari ST
                        Re: Amiga vs. Atari ST
                   gnuemacs needed (sections 13-18)
                   Re: Mega2 hardware questions...
                          Packed executables

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

Date: 27 Jul 89 19:36:19 GMT
From: jwd@iuvax.cs.indiana.edu  (Jon Dunn)
Subject: evnt_keybd
To: info-atari16@score.stanford.edu

This may be a dumb question, but how to I convert the scan code
returned by the AES evnt_keybd() function to an ASCII code?
Thanks!

Jon Dunn
jwd@iuvax.cs.indiana.edu

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

Date:         Thu, 27 Jul 89 17:10:33 EDT
From:         Brian Holmes <BHOLMES%WAYNEST1.BITNET@Forsythe.Stanford.EDU>
Subject:      DVT VCR Hard Drive backup
To:           Atari Newsgroup <INFO-ATARI16@SCORE.STANFORD.EDU>

I received my DVT VCR HD Backup device and software yesterday.
I ordered it from Computability as advertised in START for $209.00
Currently the software only supports file backup, no image backup,
though the software could easily support it.  In START it's advertised
is as storing 8 megabits/minute which would be 1 megabyte/minute right?
I backedup my 'C' partition which contained c12meg of files and it took
35 minutes, which would average out to 333K/minute right?  They also
advertised that it stores up to 360 megabytes (per tape I'm assuming).
Using a 120 minute tape, I will only be able to store c48Megabytes/tape.
They must have been using one big tape.  They suggest using SP mode,
which is the fastest playing mode (i.e. record 2 hours/tape).  For
$209 I guess I got my money's worth, I just hope they come out with
an image backup utility.

                        Brian Holmes
                        CSC Operating Systems & Communications

SNAIL    : Wayne State University, 5925 Woodward, Detroit MI 48202 U.S.A.
BITNET   : BHOLMES@WAYNEST1
INTERNET : Brian_Holmes@UM.CC.UMICH.EDU
UUCP     : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES

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

Date: 28 Jul 89 01:00:49 GMT
From:
 brutus.cs.uiuc.edu!wuarchive!swbatl!texbell!uhnix1!uhnix2!uace0@tut.cis.ohio-st
ate.edu  (Michael B. Vederman)
Subject: FOR SALE...
To: info-atari16@score.stanford.edu

A friend is trying to sell his complete Mega 4 system.  Here is what he has:

Mega 4
Monochrom monitor
Megafile 30
Laser printer
Ultrascript + Extended font package
Spectre 128 + ROMs
Calamus
Page Stream
Time Works DTP

He would like $3600 for everything, and is hoping to get rid of everything by
July 31!!!

He is willing to break up the set.  Please give him a call if interested, day
or night.  His name is SAM, and his number is 713-493-5160.

--
for (;;)                              : Use ATARINET, send an interactive
        do_it(c_programmers);         : message such as:
                                      : Tell UH-INFO at UHUPVM1 ATARINET HELP
University Atari Computer Enthusiasts : University of Houston UACE

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

Date: 27 Jul 89 22:03:25 GMT
From: attcan!lsuc!jimomura@uunet.uu.net  (Jim Omura)
Subject: GNU Tar sources
To: info-atari16@score.stanford.edu

     I was collecting the GNU Tar source set and Part 7 apparently
didn't arrive.  Could someone contact me by mail if they have it?
Thanks.

Cheers! -- Jim O.
--
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
lsuc!jimomura
Byte Information eXchange: jimomura

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

Date: 28 Jul 89 03:26:46 GMT
From: att!chinet!saj@ucbvax.Berkeley.EDU  (Stephen Jacobs)
Subject: Re: GNU-Emacs 18.51 for Atari ST (TOS) posted to comp.binaries.atari.st
To: info-atari16@score.stanford.edu

I know, we were told not to expect much from GNU EMACS with only 1 Meg, but
after determining that it only used about 300 K text+data+bss I gave it a
shot.  Just start it, read some stuff in and push a few keys, nothing serious.
  Impressive hardly describes it.  Looks just like on the VAX, only it starts
up faster.  But I have a couple of ???-s.
  The start-up seems to crash rather than finishing normally (something about
invalid argument stringp null, as I remember).  Control Z gives a kind of
no-op (the bottom line flashes 'program terminated' ever so briefly, then
I'm back in EMACS.  And dired seems to be getting confused, probably by the
$HOME environment variable in \ form (rather than / form) which is really
there for the use of the shell, msh, rather than EMACS.
  But the program runs fast, and there's a tremendous amount there.  This is
going to be fun to explore.
   I hope the diffs from a widely available source distribution show up on
the net.
                                       Steve J.

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

Date: 27 Jul 89 13:39:44 GMT
From: mcvax!ukc!acorn!moncam!emmo@uunet.uu.net  (Dave Emmerson)
Subject: 1MB piggyback details - how to [LONG]
To: info-atari16@score.stanford.edu

Aaagh!
Is it just my imagination, or does 10% of the mail in this group really
consist of requests for details of piggy back expansions?
Perhaps if I reply, they might desist?

OK peeps, you asked for it..

First off get hold of 16 DRAMs in Dual In Line packages. These look like
the ones already fitted along the front right of your ST, if in doubt,
quote the section of the device marking which includes the number 256,
and ask for an equivalent part. There are far too many to list them all,
but basic specs are : 256K x 1 page mode DRAM, 150 nanoseconds or faster,
preferably in plastic package (cheaper!), 16 pin DIL outline.
They're not cheap, and prices vary enormously, so shop around.

Each chip has a notch at one end, to show which way up it is fitted.
With the notch uppermost, pin 1 is to the left of the notch, pin 8 is
at bottom left, pin 9 bottom right, and pin 16 top right. Armed with
this information, find pins 4 and 15 on each of your new chips in turn,
and bend them CAREFULLY through 180 degrees without breaking them off.
Bend them as close to the body of the chip as you can. These are the
RAS and CAS pins which work as chip select lines. The chips will normally
be supplied in black anti-static foam. Try to keep them there while you
bend the pins.

Now, one at a time, sit a new chip on top of one of the built-in DRAMs,
with the notch at the same end (!!) and solder each of the other 14 pairs
of pins together. Make sure the chips are accurately lined up, use only
the minimum of fine multicore solder, and watch out for 'bridges' of
solder between adjacent pairs of pins, and solder splashes on the PCB.
This takes care of all the address, data, power, and read/write_ lines.

Lastly, locate the MMU chip. This is a square, 68 pin device, U15 on
early machines, and probably the one nearest the DRAMs on all versions.
This has a pip in the middle of one side to indicate pins 1 & 68.
From the top of the board, they are numbered anticlockwise. Attach one
end of a short (300mm or so) length of thin INSULATED wire to each of
pins 18 (RAS1), 21 (CAS1LOW), and 22 (CAS1HIGH). Prototyping wire is ideal,
particularly the "solder-wrap" type sold in the UK as "Verowire" (R) for
around 5.5 pounds. Don't connect directly to the MMU, take the wires through
a suitable hole, and trace the pins to the underside of the PCB.
The wire from RAS1 should be soldered to pin 4 of ALL the new DRAMs. If you
are skilled enough to do it, a 33 ohm Resistor should be used in series as
near to the MMU as possible to dampen reflections on all 3 of these wires,
but its omission is unlikely to cause problems.
The wire from CAS1LOW should be soldered to pin 15 of the LEFTmost 8 new
DRAMs, and that from CAS1HIGH to the RIGHTmost 8.

That's it. Depending on your confidence and proficiency, it should take
about half to 2 hours. DO try to do it all in one session, and avoid
touching the chips as much as possible, they are static sensitive.
A use ful tip - DISCONNECT the power supply, and attach a lead from the
ground rail around the edge of the board to your metal watch strap. keep the
chips in their foam sitting on a bare area of the ground rail. I'ts not
a static safe workstation, but it's as near as most of you will get.

If you have a hard disk, unhook it before you first try out your handiwork!
If it doesn't work : don't blame me! If your ST runs, but still only with
0.5 MB, check for unsoldered pins, suspect duff chip(s). If it goes crazy,
check for solder shorts, check correct pins used on MMU, take it to your
nearest hardware wiz with a print of these 'destructions'.

Finally, piggybacking 1Mbit DRAMs instead of 256K for 2.5Mbytes :
This is MESSY, the pinouts don't match up well, and several pins need to
be bent through impossible angles. You will need to connect another flying
lead for the extra address from MMU pin 64 to A9 on ALL the 1M drams.
Again the 33 ohm resistor aught to be included as before.
The relevent pinouts follow, I won't go into more detail as I hold the
view that if you can't figure it out from here, you shouldn't attempt to
do it. A useful hint though, apart (perhaps) from A9 (for refresh
considerations), the address pin numbers can be swapped around anyhow
you like, ie A0 can be used as A1 etc..

Viewed from above:

256K DRAM pinout		1M DRAM pinout

       notch				notch
1  A8    	16 Vss		1  Data in 	18 Vss
2  Data in	15 CAS_		2  Write_	17 Data out
3  Write_	14 Data out	3  RAS_		16 CAS_
4  RAS_		13 A6		4  UNUSED	15 A9
5  A0		12 A3		5  A0		14 A8
6  A2		11 A4		6  A1		13 A7
7  A1		10 A5		7  A2		12 A6
8  Vcc		9  A7		8  A3		11 A5
				9  Vcc		10 A4


The above is submitted in good faith, but you use it at your own risk.
If you spot any mistakes, please post to this group first, flame me
later!

Dave E.

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

Date: 27 Jul 89 13:25:13 GMT
From: oliveb!pyramid!prls!philabs!ttidca!woodside@apple.com  (George Woodside)
Subject: Re: putchar() getchar() problem?
To: info-atari16@score.stanford.edu

In article <2829@tahoe.unr.edu> mikew@wheeler.UUCP (Mike Whitbeck) writes:
>HELP !
>I seem to get extra \r's from putchar()!!!! (or getchar()?)
>I am using MWC 3.0 to port BR's splay compression program to the
>ST. The program works fine under UNIX(SUN) and IDRIS (PE7300)
>but on the ST I get extra 0x0D's (\r) in the output!

This is speculative, but I haven't seen any other suggestions:

putchar and getchar are macros. They expand to putc(c,stdout) and getc(stdin),
respectively. Both stdin and stdout are already opened as ASCII files when your
program begins execution. The insertion of 0x0D into your data streams is
most likely due to the high level handler attempting to add a carriage return
(0x0D) when it sees a line feed (0x0A) in the stream.

You can eliminate this by opeing binary input and output files (use "rb" or
"wb" as the second parameter in the fopen() call), and use the putc and getc
calls directly with the appropriate file handle.


--
*George R. Woodside - Citicorp/TTI - Santa Monica, CA
*Path:       ..!{philabs|csun|psivax}!ttidca!woodside

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

Date: 24 Jul 89 23:03:00 GMT
From:
 mailrus!jarvis.csri.toronto.edu!dptcdc!tmsoft!masnet!canremote!david.megginson@
purdue.edu  (DAVID MEGGINSON)
Subject: Re: Amiga vs. Atari ST
To: info-atari16@score.stanford.edu

I suggest that you look at the software as well as the computer itself.
Consider Calamus and DynaCadd on the ST, and compare them to whatever is
available on the Amiga.
---
 * Via ProDoor 3.0R

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

Date: 28 Jul 89 15:43:19 GMT
From: janus!mitchell@ucbvax.Berkeley.EDU  (Evan Mitchell)
Subject: Re: Amiga vs. Atari ST
To: info-atari16@score.stanford.edu

In article <89072707200427@masnet.uucp> david.megginson@canremote.uucp (DAVID
 MEGGINSON) writes:
>I suggest that you look at the software as well as the computer itself.
>Consider Calamus and DynaCadd on the ST, and compare them to whatever is
>available on the Amiga.
>---
> * Via ProDoor 3.0R
This is true.  However, consider Professional Page (full Postscript color
seperations (4096 soon to be 16 mil)) and X-Cad.  And remember you can run
both of them at the same time, and you can add an '030 to your system (A2000
without hacking) and a math co-processor (68882) and lots of good NTSC
compatible video software available, and...

Don't kid yourself, this isn't an easy choice.  I chose to go with the company
with the least amount of vaporware...

-Evan
_______________________________________________________________________________
|  Evan Jay Mitchell                 EECS/ERL Industrial Liaison Program      |
|  mitchell@janus.berkeley.edu       University of California at Berkeley     |
|  Phone: (415) 643-6687                                                      |
|           "Think, it ain't illegal...yet!" - George Clinton                 |

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

Date: 28 Jul 89 11:51:51 GMT
From: ncrlnk!ncrcam!system!mike@uunet.uu.net  (mike)
Subject: gnuemacs needed (sections 13-18)
To: info-atari16@score.stanford.edu

I recently received the GNU emacs binaries posting.  I missed sections 13
through 18 though.  They just never showed up.  Could someone email these
to me.  Please make sure someone else has not yet sent them so I don't end
up with more than one copy.

Thnaks

mike

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

Date: 27 Jul 89 15:04:25 GMT
From: att!mtuxo!mtgzz!drutx!druwy!dlm@ucbvax.Berkeley.EDU  (Dan Moore)
Subject: Re: Mega2 hardware questions...
To: info-atari16@score.stanford.edu

in article <8907250426.AA12717@jade.berkeley.edu>, WSCART01@ULKYVX.BITNET says:
> I bought a mega2 about 4 months ago. (Yes, out of warrenty.) I've had some
> disk compatablitiy problems. Nothing big, but it seems that my RPM is a bit
> on the high end of the scale. I've adjusted drive speeds before, but I
> couldn't on the Mega2. I couldn't find a control pot for the motor. There
> was a small variable pot but it seemed to be hooked to the stepper moter.
> (I tried it anyway, but it didn't make any difference.) There was a bunch
> of resisters on the board, i'd hate to think that the speed is hard wired.
> Tell me is isn't so! (If it is, which one controls the speed?)

	Most of the better 3.5" drives use a phase lock loop to control
the drive RPM.  They are supposed to be calibrated at the factory (the
drive company's, not Atari's) and that is it.  Most of them do not have
any way to adjust the drive speed after they leave the factory.  These
are the best drives since they have very stable speeds.  It takes a lot
of extra drag (eg. pushing very hard on the disk media while spinning)
to make them change RPM.  But if they aren't correctly calibrated they
stink.

	Atari has started using some less expensive drives, belt driven
instead of direct drive, most of them do have adjustments for the drive
speed.

	You might try contacting the company that built the drive and
asking if (and how) the drive RPM can be adjusted.  Depending on which
company you may or may not get any cooperation.

>  There was a little magnet along with, i guess, a magnetic sensor. What is
> this for? (Is the drive speed, chip controled?)

	That is probably the drive speed sensor for the PLL.  If so then
there is probably nothing you can do to adjust the drive RPM.



				Dan Moore
				AT&T Bell Labs
				Denver
				dlm@druwy.ATT.COM

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

Date: 27 Jul 89 14:00:25 GMT
From: mcvax!ukc!etive!hwcs!neil@uunet.uu.net  (Neil Forsyth)
Subject: Packed executables
To: info-atari16@score.stanford.edu

With respect to the recently posted pack/unpack programs posted to the binaries
group I have thought about a few problems that might result when packing
executables:-

* How does GEMDOS feel about loading a program with a header that does not
  properly reflect the program that will be run? Even if the base-page is
  set up accordingly, GEMDOS has seen the weird one first and may have already
  set up some internal variables.

* Also when a program is loaded it is given the largest free area of memory.
  If there is not enough memory Pexec returns an error. Programs that run
  bigger than their header states will cause problems here (stack trampling,
  screen corruption, bus errors etc).

* The unpacker that is glued on to the program will have to relocate the host
  program itself. Possible future uses of the currently unused odd relocation
  values will be lost here.

* It will also break if a TOS patch ever has to modify the program before
  executing it.

Personally I am not happy with the idea. Compacting data files is fine and I
like it, but not executable programs.
I invite Atari themselves to to comment on this because they probably know of
even more horror stories that could result (and I can also ask them to post
the Pexec cookbook they promised us long ago).

+-----------------------------------------------------------------------------+
! DISCLAIMER: Unless otherwise stated, the above comments are entirely my own !
!                                                                             !
! "I think all right thinking people in this country are sick and tired of    !
! being told that ordinary decent people are fed up in this country with      !
! being sick and tired. I'm certainly not and I'm sick and tired of being     !
! told that I am!" - Monty Python                                             !
!                                                                             !
! Neil Forsyth                       JANET:  neil@uk.ac.hw.cs                 !
! Dept. of Computer Science          ARPA:   neil@cs.hw.ac.uk                 !
! Heriot-Watt University             UUCP:   ..!ukc!cs.hw.ac.uk!neil          !
! Edinburgh, Scotland, UK                                                     !

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

End of Info-Atari16 Digest
**************************
-------