Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!ames!ucbcad!ucbvax!fingate.BITNET!MAILER-DAEMON
From: MAILER-DAEMON@fingate.BITNET (Mail Delivery Subsystem)
Newsgroups: comp.sys.atari.st
Subject: Returned mail: unknown mailer error 1
Message-ID: <8612310110.AA02235@ucbvax.Berkeley.EDU>
Date: Tue, 30-Dec-86 22:43:18 EST
Article-I.D.: ucbvax.8612310110.AA02235
Posted: Tue Dec 30 22:43:18 1986
Date-Received: Wed, 31-Dec-86 03:46:10 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 411


   ----- Transcript of session follows -----
sh: /usr/lib/news/recnews: not found
554 "|/usr/lib/news/recnews sfnet.atari16"... unknown mailer error 1

   ----- Unsent message follows -----
Received: by santra.UUCP (5.51/6.1.TeKoLa)
        id AA01739; Tue, 30 Dec 86 15:24:04 +0200
From: 
Message-Id: <8612301324.AA01739@santra.UUCP>
Received: by fingate Tue Dec 30 15:23:58
        from MAILER@FINHUTC.BITNET via rscs.
To: , 
Original-From:          Info-Atari16 Digest 
Received: by FINHUTC (Mailer X1.23b) id 1635; Tue, 30 Dec 86 15:14:58 FIN
Date:         Fri 26 Dec 86 17:51:20 PST
Reply-To: Info-Atari16@Score.Stanford.edu
Sender: Atari ST users forum 
Comments: To: "Distribution List: ;" 
Subject:      Info-Atari16 Digest V86 #62
              Jouko Yl{lahti 

Info-Atari16 Digest   Friday, December 26, 1986   Volume 86 : Issue 62

This weeks Editor: Bill Westfield

Today's Topics:

               Re: Re: A challenge to you disk experts
               Re: Re: A challenge to you disk experts
                         Re: Drawing programs
                 Re: "C" on Atari looks pretty wierd
                           Re: RE: uudecode
                         Mac Emulator (idea!)
                          1 MB Upgrade Board
                             Re: AUTOCOPY

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

Date: 23 Dec 86 19:39:53 GMT
From: imagen!atari!apratt@ucbvax.Berkeley.EDU  (Allan Pratt)
Subject: Re: Re: A challenge to you disk experts
To: info-atari16@score.stanford.edu

> What I would like is to take a SS disk, say "open, sesame" and end up with
> a normal DS disk, that may be used anytime without loading any special
> drivers, just like standard SS and DS disks may be mixed in a session.

The only way I can think of to say, "open, sesame" on an SS disk is to
write a program which would (A) format the second side, (B) compact
the data from its current, all-on-one-side format to the DS
alternating-sides format, and (C) diddle with the boot sector to
inform the system that this is a DS disk.  That would take
considerable head movement (which I take it you want to avoid) but
could be done, and would only need to be done once per disk.  The
formats are just too different to allow some simple changes to make it
all work out.

> Hint for making AUTOCOPY (current version) work as fast as it can:
> Put the files to be copied close to the beginning of the disk (simply
> by writing them on the disk first, then the rest of the files...).
> Write them to the disk in the order they are to be copied.

The first suggestion is good: it will minimize the distance from the
directory and FAT to the data.  However, the second doesn't matter.
The head-seek distance is conserved no matter what permutation of
those files you use (provided they are all contiguous and the first
files on the disk).

The thing which will speed up your copy operation the most is a
disk-block caching program like Beckmeyer's hard-disk accelerator.  If
it could be instructed to cache the blocks in the FAT and root
directory, you would only have to read them once for the first file,
and the directory searches involved in opening the subsequent files,
as well as the FAT hits to determine where they are, would be done
without any disk head movement at all.  In that case, it really would
pay to copy the files to the disk in the order they're to be copied to
RAM, because then the head would march across the disk in one
direction, until all the files were copied.

The reason people don't write block-caching programs for floppies is
that they can be asynchronously dismounted: you can pop the disk at
any time.  When you do that, you have to invalidate your cache.  But
to determine that this has been done, you have to ask about media
change.  Sometimes the routine which determines media change has to
hit the disk, to check its serial number (that is, when the state it
"maybe media has changed").  Hitting the disk undoes all the benefit
of having a cache in the first place.  Therefore, people don't write
such caching programs, and you are out of luck.

Finally, the way to read lots of disk blocks without stopping is to use
a large buffer and the GEMDOS system call Rwabs.  The Fread call uses
this to get its blocks.  You shouldn't have to touch it.  If you are
using the runtime library (GEMLIB's fread call), this explains your
troubles.  Also, you mentioned using a 27K buffer.  Why not use a
buffer as large as you can (whatever's left after your ramdisk and
copy program have started)?  You can find out how big it is, and
where it is, by examining your own basepage.

Finally, consider the time you have spent worrying about this.  You
will not make up that much time in saved disk accesses.  Moreover,
head seeking is exactly what disk drives are made to do -- I wouldn't
worry about the wear and tear, especially if you have preventive
maintenance done occasionally -- make sure no screws are loose, speed
is within spec, etc.  Things like that, and head wear, will cause
failures long before your stepper motor gives out.

| Opinions expressed above do not necessarily  |  -- Allan Pratt, Atari Corp.
| reflect those of Atari Corp. or anyone else. |     ...lll-lcc!atari!apratt

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

Date: 24 Dec 86 04:06:36 GMT
From: braner@tcgould.tn.cornell.edu  (braner)
Subject: Re: Re: A challenge to you disk experts
To: info-atari16@score.stanford.edu

Thanks to Allan for the expert advice.

My goal is not to minimize disk head movement, but to minimize disk use.
Period. Unnecessary head movement causes longer disk-turning periods -->
more disk (and head) wear (and more waiting time).

I used a 27K buffer for disk read in AUTOCOPY since the speed does not
increase significantly for larger buffers.  (Indeed, the speed is almost
up to its max with 9K!)   There I used Fread() to read into the buffer.

In AUTODISK (recently posted) I used Rwabs(), as Allen suggested.  The whole
idea behind AUTODISK is that I copy the whole disk as a block, starting with
reading the boot sector and FAT, so I know how much to read on without
re-reading anything.

I very much wish I had a good disk-cache program.  That would eliminate
not only the need for dirty tricks like AUTODISK, but also (with a BIG
cache) the need for a RAMdisk!  The problem of handling disk-swappings
(by the user, with no warning) is serious, but not insurmountable.
For example, one could write a cache program that would keep track of
the disk things came off of (not just sectors and drives), and would NOT
delay WRITING of data to the physical disk.  The former feature would allow
handling data from two or more disks with one drive and no extra swapping,
and the latter would avoid writing on the wrong disk and also after-the-fact
reporting of write errors (common on floppies...).  If the user does not
swap disks too often, the program would not need to check the disk ID very
often, and GREAT increases in disk throughput would become possible!!
If I had the time for a large project like that, a GOOD disk-cache program
would be my very first choice!  Anybody out there up to it?

Of course I've spent time on AUTOCOPY and AUTODISK, perhaps more than I'd
ever regain from them.  But EVERYBODY can now use them for free!  It's
part of my share in the great world of Public Domain Software.

- Moshe Braner

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

Date: 18 Dec 86 16:06:30 GMT
From: meccts!meccsd!mecc!zeke!todd@rutgers.rutgers.edu  (Todd Burkey)
Subject: Re: Drawing programs
To: info-atari16@score.stanford.edu

Having owned a mac for years and after transforming it into a MacPaperweight
when I bought my ST in mid '85, I think I can give at least a little insight
into the drafting programs at least. First, it is really important not to
confuse painting programs with drafting ones. Macpaint on the mac is in the
same category as NEO, DEGAS, and N-Vision on the ST (although feature wise,
NEO .9 or 1.0 will wipe away macpaint...) 2-D drafting programs on the other
hand include programs like MacDraw and First Cadd, Drafix, and Easydraw on
the ST. I would say that feature for feature, MacDraw and the new Easydraw
are very similar. Easydraw is a little faster and fully utilizes both
buttons on the ST, simplifying the user interface. I have used Easydraw for
overheads and simple schematic drawings and was very satisfied with the
quality of the printouts on my Epson printer (I also have Macdraw on my
Magic Sac and guess what! It runs faster than a Mac+ and it gives you the
full screen for workspace...and I got a MacIntosh addict to admit that!).

More similar to Draft on the Mac are First Cadd and Drafix. First Cadd is
basically the IBM PC version of Generic Cadd ported to the ST with some
enhancements. Notable improvements are the speed (much faster than the AT
version of GC) and some of the GC 2.0 features were added. The important
features (to me) that First Cadd provides include: 1) component storing,
scaling, and placement, 2) truely redefinable grids, 3) edittable text fonts
(standard set is optimized for a pen plotter), 4) many printer drivers (>100
are included with the package, 5) user definable menus, 6) distance,
perimeter, and volume measurement capability, 7) a very well written manual,
and 8) enough commands to allow me to create any arc, ellipsoid, curvefit
line, etc that I care to make. And it is only 49.95 retail. Drafix I saw
when I was out at Comdex, but to be truthful I didn't look at it very
closely after I saw the $295 dealer price. For those with access to the PC
world, it is a direct port of Drafix from the PC and seemed to have most of
the features of Autocad and Generic Cadd 2.0. If anyone does buy drafix, let
me know it if was worth it.

One product I haven't mentioned yet is Graphics Artist. All I have seen of
this program so far is the demo disk I got from Atari. The program looks
like a combination of a drafting package and a paint program. I
probably would have purchased it by now if it wasn't for their poor ads I
see in Antic. As a graphics artist friend of mine mentioned..."If you are
putting an ad together about a product that is such a great graphics
program, why put out an ad that looks like it was done by hand and by an
inexperienced artist at that." Kind of like getting a completely handwritten
letter from a Printer company describing their product in detail...

   -Todd Burkey
   ...!mecc!zeke!todd

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

Date: 24 Dec 86 19:50:09 GMT
From: voder!kontron!stephan@ucbvax.Berkeley.EDU  (Stephan W. Wendl)
Subject: Re: "C" on Atari looks pretty wierd
To: info-atari16@score.stanford.edu

> Xref: kontron comp.sys.atari.st:478 comp.lang.c:489
>
> Do Atari C compilers really accept these?  What do they do?
>
> Also, the library routines used are almost totally bonkers.  E.g.
> to open a file they use Fopen rather than fopen.  To read it's Fread.
> To scan a directory it's Fsfirst and Fsnext rather than opendir and
> readdir.  For malloc/free they even use Malloc/Mfree!  What was wrong
> with the old names, did they make software too easy to port?


I don't know about the '//' but the line behind references gem calls.

About the library routines: apearently there quite some bugs in the
lib functions and one way to get arround is to use macros which just
convert into trap calls.  That effectivly makes the program work and
quite shorter in codesize.

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

Date: 23 Dec 86 10:27:41 GMT
From: mcvax!ukc!dcl-cs!bath63!pes@seismo.css.gov  (Paul Smee)
Subject: Re: RE: uudecode
To: info-atari16@score.stanford.edu

Caught it.  It's none of the above, but rather one of (a) some version of
uuencode or (b) some beknighted gateway or comms implementation.

The character causing problems (in uuencoded UNITERM) is the tilde, or
twiddle, (or ~) character.  Some uuencoded programs contain twiddles.
Some uudecodes (e.g. mine) will handle twiddles.  However, twiddle **IS NOT**
in the 'official' UUENCODE character set.

From a look at the files, it appears that the twiddles are replacing caret,
or hat, or not (or ^) characters.  (Note that twiddle is ASCII 176 octal,
and hat is 136 octal.)

So, it looks like the answer is (a) if you're having uudecode problems,
check to see if there are twiddles in the file, and if so, turn them into
hats; and (b) to solve the new problem, of which UUENCODE generates files
containing twiddles, or possibly, which machine changes hats to twiddles
as the files get transmitted through...

Thanks to Leila Burrell-Davis at Sussex for her help in chasing this...

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

Date: 24 Dec 86 02:12:12 GMT
From: mcvax!botter!ark!Patrick@seismo.css.gov  (Patrick van Kleef)
Subject: Mac Emulator (idea!)
To: info-atari16@score.stanford.edu

Just an idea:

The most frequent error that occurs using the Mac Emulator, is a
bus error. This happens when programs start writing at locations they're
not allowed to on the Atari ST. Usually it means the software wasn't
'perfect', not in accordance with the Apple Programming Guidelines.

People tell me there is a way of preventing bus errors on the ST. This
type of error is generated by one line of the Glue chip, the so called
BERR line.

Now what if we disconnected that line? In theory bus errors would be
impossible. Would it affect 'normal programs'? Will more Macintosh programs
run? Is there anyone who can figure this out?

Dave Small writes, the most frequent error is the bus error that occurs when
Mac programs write at location 0, Ram at the Mac, Rom at the ST. This action
has -as far as I know- no effect on the working of a program on the Mac. But
on the ST, a bus error occurs and the program fails to run. Would a switch,
that disconnects the BERR line on the Glue have the same effect as on the
Mac. Namely that programs run without further failure? I think it would
increase the amount of good working Mac software a lot.

As I'm too much of a kludge concerning hardware (and software too, for that
matter), I'd like the opinion of some experts. Moshe, do you have any idea?

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

Date: 24 Dec 86 15:52:46 GMT
From: kodak!ektools!bruce@rochester.arpa  (Bruce D. Nelson )
Subject: 1 MB Upgrade Board
To: info-atari16@score.stanford.edu

I recently installed the ram upgrade board from Diverse Data Products
(1805 Northeast 164 St., N. Miamai Beach, FL 33162, 305-940-0458).

The installation went reasonably easy except for a few problems I ran into
at the end. The steps are basically:
1) Get to the mother board.
2) Remove the capacitors on either side of U30.
3) Place a clip over U30 (which gets the address signals to their board).
4) Remove the video shifter, insert their socket, and place the shifter in it.
5) Solder 3 wires to 3 lands under the MMU.
6) Put the computer back together.

Steps 1-6 took me about 20 minutes. Much more enjoyable than piggybacking the
ram chips and soldering over 250 connections per the "original" upgrade.

The problems I ran into were:

1) The socket that goes between the video shifter and the original
socket sits a little bit high and the shield over the shifter doesn't
fit. I had to cut off about 1 mm of each lead of their socket.

2) The tape they used on the back of their pc board still let some of
the pins of their components pop through. When reassembling the
shield, the pressure on the board popped some of the pins through so
they shorted something.  Fortunately :-) it didn't cream the ST. I had
to put some thick foam tape under the board.

3) The fit of the board under the shield is very tricky. The instructions,
which are otherwise quite clear, don't give a hint on how to make it fit.
took a lot of trial and error to get it to fit under the shield.

Due to the problems I ran into, it took about 4 hours to get it right. But a
friend of mine who did it after I gave him the above info did it in about
1 1/2 hours (he also had trouble due to problem #3).

However, when it was all done, the results were worth all the trouble. As I
said, I think it was still easier than 256+ solder connections.

I have no connection to Diverse Data Products, and the opinions expressed are
my own and do not necessarily reflect those of my employer.

Bruce D. Nelson
Product Line Systems

USPS:   EASTMAN KODAK CO., Dept. 407, 901 Elmgrove Rd., Rochester, NY 14650
VOICE:  716 726-7890
UUCP:   {allegra, seismo}!rochester!kodak!ektools!bruce
ARPA:   kodak!ektools!bruce@rochester.ARPA

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

Date: 24 Dec 86 18:56:20 GMT
From: clyde!watmath!watnot!water!ljdickey@rutgers.rutgers.edu  (Lee Dickey)
Subject: Re: AUTOCOPY
To: info-atari16@score.stanford.edu

In article <674@bath63.ux63.bath.ac.uk>, pes@bath63.ux63.bath.ac.uk (Paul Smee)
 writes:

> The advantage of using ` is that (not being a space) it won't get stripped
> from the ends of lines....

> So, in summary, if you get a uuencoded file containing `s, turn them all
> into space chars.

I think that this is a dangerous suggestion, because some ASCII to EBCDIC
conversions get the caret (^), the grave accent (`) and the tilde (~) mixed
up.  I saw some files pass this way with lots of grave accents that had
started life as carets.

There are other solutions to the problem of blanks at the end of lines.

  (1)    If the lines are truncated, put some blanks in yourself.
    It seems to matter not if you put in too many blanks.
    For example, this worked for me:
        "g/^M/s/$/       /"
    My uudecode program was not upset by the extra blanks
    that I put in at the end of the lines, and it got
    everything right.

  (2)    Put in some terminator at the end of every line before you
    transmit it.  Someone recently sent a file with an "a" at
    the end of every full line.  (A full line is one that
    starts with an "M" and has at least 61 chars in it.)
    I made two copies of this file, one with the "a" and
    one without, by doing something like this:
        "g/^M/s/a$//"
    The uudecode program produced the same result from both
    encoded files.


Neither of these solves the problem of multiple blanks being turned
to tab characters.  Are there any mailers that do this?
Perhaps a text editor might do that, maybe, but no file handlers, please.

Please do not deliberately introduce files with these non-UUencode
characters in them.  If you do, then the errors of conversion that I
mentioned above can not be corrected.

The solutions that you found may be fine for you to get around whatever
problems your text editor may have.  If they are, use them.  Locally.

But please keep them local and do not introduce them onto the net.

  Prof. L. J. Dickey, Faculty of Mathematics, University of Waterloo.
    ljdickey@water.UUCP    ljdickey%water@waterloo.CSNET
     ljdickey%water%waterloo.csnet@csnet-relay.ARPA
    ljdickey@watdcs.BITNET

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

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