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 ************************** -------