Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 91 Issue 358
Info-Atari16 Digest Thu, 27 Jun 91 Volume 91 : Issue 358
Today's Topics:
Amiga is better then what??? (2 msgs)
For Sale (UK Only)
Info-Atari16 Digest V91 #357
UPDATE: Atari ST Parting out Sale!
Usenet access...
Was: How is Atari doing in Europe?
What archiving format?
Welcome to the Info-Atari16 Digest. The configuration for the automatic
cross-posting to/from Usenet is getting closer, but still getting thrashed
out. Please send notifications about broken digests or bogus messages
to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU.
Please send requests for un/subscription and other administrivia to
Info-Atari16-Request, *NOT* Info-Atari16. Requests that go to the list
instead of the moderators are likely to be lost or ignored.
If you want to unsubscribe, and you're receiving the digest indirectly
from someplace (usually a BITNET host) that redistributes it, please
contact the redistributor, not us.
----------------------------------------------------------------------
Date: 27 Jun 91 18:46:31 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!think.com!mintaka!geech.gnu.ai.mit.edu!
rjc@arizona.edu (Ray Cromwell)
Subject: Amiga is better then what???
To: Info-Atari16@naucse.cse.nau.edu
In article <1991Jun26.192356.26253@informatik.uni-erlangen.de>
csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes:
>don@chopin.udel.edu (Donald R Lloyd) writes:
>
>> I can get a 24-bit card for $299 (list). It takes advantage of the Amiga's
>>built-in coprocessors. For about $100 more I can get one that also includes
>>a slow-scan video digitizer. This one (DCTV) has been demoed at shows paging
>>full-motion, full-color video off a HD and displaying it through this advice
in
>>real time (Watched a few minutes of Back to the Future III...)
>
>A 24-bit card with complete screen drivers for all the applications you have?
>I doubt that.
Why on earth would you run a word processor or shell in 24bits? EVen if
the Amiga had 24bit graphics built in I wouldn't run my Workbench on it
because it would slow down ALL screen rendering to a sluggish
halt without a something like a 34010 onboard. Instead, I'd have
the Word processor and GUI set to 8 or 16 colors (3d look) and the paint
program on another screen set to 24bit. All the current Amiga graphic
cards work with the OS because they are still using the custom chips
for their tricks. HAM-E and DCTV work with all paint programs and all
displayer programs. (even things like AmigaVision authorware)
>> Besides, if you have a problem with your 500, you FedEx it back to
>>Commodore (at CBM's expense) & it's promptly replaced or repaired & sent back.
>>If your 2000, 2500, or 3000 go bad, and your warranty is still valid (1 year
>>warranty on all models, w/option to purchase an extension), Commodore sends
>>someone to your home to fix it there.
>
>You must be kidding. At least here in Germany, nobody cares when your A2000
>breaks down. Especially Commodore won't care.
In the US FedEx will come to your house, pick up your computer, and
repair it quickly. For A3000's someone comes to your house (onsite
repair). What other countries do is different since each Commodore
sub-company has different policies. Does Atari even exist in the US?
>> I've seen the so-called blitter on an ST. I was not impressed. The
>
>You have probably seen the desktop build up windows with and without a
>blitter, using TOS 1.02. This means you ain't seen nothing yet.
>Blitter support in TOS is not as it could be, and in general one
>is tempted to say that Blitters Are Not Important. You can speed up
>graphics a lot more by software.
A blitter helps out alot if you only have a 68000/20.
>>Amiga's blitter performs most operations about as fast as a 14 MHz 68020
>>(according to Dave Haynie, a CBM hardware guy who frequents c.s.amiga.*).
>
>The ST blitter won't stand much behind in these terms. It's just that
>the Amiga OS and architecture much more relies on the fact that there
>is something like a blitter and therefore uses it much more than TOS.
Yes, it's better integrated on the Amiga, and shared nicely as is
alll resources on the Amiga.
>> Of course, for about $10 (probably less) you can pop a 68010 into your
>>Amiga & make up for that difference. Unless Atari has finally released a
>>non-TT TOS version that supports 680(1+)0 chips, ST owners don't have this
>>option.
>
>TOS 1.06, TOS 2.05, TOS 3.01 and TOS 3.05 support the 68010. Nevertheless,
>you won't gain much from a 68010, as experiments have shown.
And the ST doesn't gain much from running at a _slightly_ faster
processor speed.
>> In what way are they more complete? Do they include a shell environment
>>as well as a GUI? Do they support multiple simultaneous screens of different
>>depths, resolutions, and pallettes? (Can the ST even change resolutions yet
>>without a reboot?) Shared libraries & interprocess communication? (Oops!
>>No need... no multitasking! Sorry.)
>
>Sigh. We've had cooperative multitasking from the start. Applications
>and accessories can send messages to each other. And I don't think the
>Workbench is much of a real GUI - not before Kick 2.0, at least.
Intuition is the GUI, workbench is the file/finder system (e.g. like
Finder on the Mac). I never used workbench before 2.0, but I haven't seen
many Atari users who used GEM either. GEM doesn't look too hot on that
lo-res screen.
>> Workbench is just as easy to use as any most other GUIs. Double click
>>the icon & away you go...
>
>Just try to view all files in a folder with the standard workbench.
>You won't get them. Instead, you have to confine yourself to a command
>shell. That's not the way GUIs were meant to work.
You do in 2.0. There are _numerous_ workbench replacements/enhancements
out there. But 2.0 beats the pants off all of them. (2.0 kicks the
stuffings out of GEM too)
>>CLI(1):artm
>>CLI(2):iprefs
>>CpuBlit V1.00
>>AssignX
>>FaccII
>>ForFacc
>>RexxMaster
>>CLI(4):c:snap
>>CygnusEd
>>CLI(3):loadwb
>>jr-comm
>>DMouse
>>Virus_Checker
>>jrcomm-clock
>>SD
>
>If you look at this list closely, you'll realise that most of the
>processes mentioned are equivalents of TSRs. CpuBlit is a text output
>speeder (BTW, interesting to know that you're using CpuBlit while
>you're claiming that your blitter is much faster than a ST blitter).
That's because the poster probably has an A3000 with a 68030. CPUBlit
ONLY gives a speed increase on the maximum resolution screens and only
for things like text rendering. It would slow down massively trying to do what
the blitter does (like combine 3 DMA channels of data using one of the
256 logic operations, plus masking ans shifting, and filling the pattern.)
The key phrase here is "parallel processing". Letting the blitter
do something takes the load off the CPU.
>DMouse is a screen saver/mouse speeder package. Virus_Checker is also
>of the TSR type. If you think about it, you'll see that the list
>above was no good example for real multitasking. When working with
>my ST/TT, I have at least that many processes and resident programs in
>my computer.
But TSR's don't share the CPU, one of them runs until it completes
it processing and then the next one does. The more of them you have
running in an interupt/os patch routine the more sluggish the computer
will get. You should never hog interupts. TSR's on the Amiga under 2.0
are done using commodities.exchange which allows you to set up handlers in
the input.device that watch for certain hot-keys/events. While they are
waiting, they are taking ZERO cpu time.
How about what I am doing now? Right now I have a terminal loaded,
in the background I have lharc unarcing some gif pictures I downloaded
earlier which are passing the output names to a script which runs them through
GIF->IFF. Meanwhile, I have 2 shells open and one of them is running
a corewars simulator which is battling two programs (mice vs mortar).
In addition to this, I am getting no visible slow down on my terminal
which is running at 19,200 baud on a USR HST.
>Don't get me wrong:
>I don't question the usefulness of preemptive multitasking. It's just
>that you gave a bad example of your usage of this feature.
>
>> How is this superior to the Amiga's 4 channel 8 bit stereo sound? (8 bit
>>on all 4 channels, not just 2 of them). There's even software (Octaplayer?)
>>that supposedly pushes out 8 voices. Of course, unlike the ST, the Amiga's
>>sound is driven by yet another coprocessor, so it takes almost 0 CPU time to
>>play a musical score or a digitized sound (as a background process in your
>>multitasking environment, while you work on something else).
>
>I couldn't care less if my computer has 3 or 4 digital voices. It just
>doesn't matter. If you're making professional music, you can't make use
>of the home-computer bleep-style digital channels the STe and Amiga
Amiga channels don't bleep. They have 4 DMA channels to themselves,
8 bit sound, 4khz to 28khz. You can change the sampling rate on demand
and can attach DMA channel to have one channel module the volume and
frequency of the other (allows you to get synthesis effects)
>offer; instead, you will use MIDI devices (that's why the ST has a
>MIDI port built-in). If you're running standard applications, you don't need
>sound except the occasional beep when you've done something wrong.
Except when you run things like Amigavision or hypertext/authorware
applications where you want to combine animations with digitized sound.
For CDTV it's a nice addition, along with it's 16bit sound and it's MIDI
port.
>For your information: The STe/TT digital sound chip has an own DMA
>channel, just like the Amiga.
But does it have DMA for each channel? Can you change the DMA rate?
I heard the STe's DMA sound is fixed at one frequency/sampling rate and
can't change it.
>> Applied Engineering and Commodore both make Ami HD drives. The problem
>>with HD drives on the Amiga is that the floppies are controlled by a
coprocessor
>>(yes, another one!) that allows me to do things like formatting a floppy
(which
>>I'm doing now via the SD process listed above) with little loss of CPU time.
>>This coprocessor, though, cannot handle the throughput speeds of high density
>>drives (twice that of the older drives), so workarounds have had to be found.
>
>To my knowledge, there is no HD drive for the Amiga that handles standard
>MFM disks. A real pain when shuffling data to a PC.
The new HD drive on the A3000 has 3 modes. 880k, 1.44mb, and 1.76mb.
1.44mb mode was the main reason for making it. You can also buy
$200 SCSI floppy drives.
>> No? Why not? That .86 MHz doesn't make much of a difference...
especially
>>if the ST also has to use the CPU to do I/O and/or graphics stuff at the same
>>time. Oops! Forgot again... no multitasking. Never mind.
>
>See above. The floppy controller and the ACSI bus have an own DMA channel.
>In the TT, there is a second SCSI DMA channel.
The A3000 has 32-bit for it's harddrive , and it normally gets
xfer rates of up to 2mb/second (and this only eats 5% of the CPU time
while doing it.) The Amiga has over 25 DMA channels. The A3000 now has
8 integrated custom chips to handle them.
>> If I remember the TT specs correctly, the only grahics mode the TT has
>>that can outdo a stock Amiga 3000 (or any other model, if it weren't for the
>>flicker in interlace mode on <3000 Amigas) is the 1024x960 mono mode which
>>needs a special monitor. With the CBM A2024 monitor or Moniterm Viking, any
>>amiga can do 1008x800 (1008x1024 in PAL mode) mono.
>
>1280x960. 72 Hz. Without a special graphic card. IMHO, a big advantage and
>one of the reason why I bought a TT.
(A2024) 1024x1024 PAL on the Amiga without a graphic card, just need a nice
monitor. (The 1024x1024 also has 4 grey colors for the 3d GUI look)
With Commodore's A2410 you get up to 1024x1024 with 256 colors out of
16.7 million.
>----------------------------------------------------------------------
>Claus Brod, Am Felsenkeller 2, Things. Take. Time.
>D-8772 Marktheidenfeld, Germany (Piet Hein)
>csbrod@medusa.informatik.uni-erlangen.de
>Claus_Brod@wue.maus.de
>----------------------------------------------------------------------
--
/ INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \
| INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.|
\ UUCP:uunet!tnc!m0023 * /
------------------------------
Date: 27 Jun 91 20:01:27 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!usc!samsung!sol.ctr.columbia.edu!ira.uka.de!fauern
!faui43.informatik.uni-erlangen.de!csbrod@arizona.edu (Claus Brod)
Subject: Amiga is better then what???
To: Info-Atari16@naucse.cse.nau.edu
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes:
> Why on earth would you run a word processor or shell in 24bits? EVen if
>the Amiga had 24bit graphics built in I wouldn't run my Workbench on it
>because it would slow down ALL screen rendering to a sluggish
>halt without a something like a 34010 onboard. Instead, I'd have
>the Word processor and GUI set to 8 or 16 colors (3d look) and the paint
>program on another screen set to 24bit. All the current Amiga graphic
>cards work with the OS because they are still using the custom chips
>for their tricks. HAM-E and DCTV work with all paint programs and all
>displayer programs. (even things like AmigaVision authorware)
I was alluding to the fact that there is no real gfx standard for
the Amiga right now. Much like the situation in the PC world. I think
having a general scheme for implementing graphic card drivers is a
definitive plus for an OS - the ST's VDI allows just this.
> In the US FedEx will come to your house, pick up your computer, and
>repair it quickly. For A3000's someone comes to your house (onsite
>repair). What other countries do is different since each Commodore
>sub-company has different policies. Does Atari even exist in the US?
Admittedly, this is good service. No doubt about that. I'm
impressed.
> And the ST doesn't gain much from running at a _slightly_ faster
>processor speed.
I didn't claim that. But remember that it's not only the 10% clock
difference that makes CPU-intensive jobs on the Amiga slower. You must
take the video hardware into account which costs additional cycles.
> Intuition is the GUI, workbench is the file/finder system (e.g. like
>Finder on the Mac). I never used workbench before 2.0, but I haven't seen
>many Atari users who used GEM either. GEM doesn't look too hot on that
>lo-res screen.
Who uses lo-res? Gamesters - but not me.
> You do in 2.0. There are _numerous_ workbench replacements/enhancements
>out there. But 2.0 beats the pants off all of them. (2.0 kicks the
>stuffings out of GEM too)
The new workbench is clearly better. But we were discussing the former
version and the philosophy behind it.
> That's because the poster probably has an A3000 with a 68030. CPUBlit
>ONLY gives a speed increase on the maximum resolution screens and only
>for things like text rendering. It would slow down massively trying to do what
>the blitter does (like combine 3 DMA channels of data using one of the
>256 logic operations, plus masking ans shifting, and filling the pattern.)
I know, I've read the CpuBlit docs.
>The key phrase here is "parallel processing". Letting the blitter
>do something takes the load off the CPU.
Right you are. I didn't like the fact that the original poster
overemphasized the importance of a blitter in general. I don't
question that it's useful - but it's not what makes or breaks a
computer.
> How about what I am doing now? Right now I have a terminal loaded,
>in the background I have lharc unarcing some gif pictures I downloaded
>earlier which are passing the output names to a script which runs them through
>GIF->IFF. Meanwhile, I have 2 shells open and one of them is running
>a corewars simulator which is battling two programs (mice vs mortar).
>In addition to this, I am getting no visible slow down on my terminal
>which is running at 19,200 baud on a USR HST.
Likewise, I didn't say multitasking is a no-no. I would like to have
it here (besides: I can have it on my machine, though not officially
by Atari). The original poster just gave a bad example for its usage.
> Amiga channels don't bleep. They have 4 DMA channels to themselves,
>8 bit sound, 4khz to 28khz. You can change the sampling rate on demand
>and can attach DMA channel to have one channel module the volume and
>frequency of the other (allows you to get synthesis effects)
I know all this. I've read the hardware manuals. The new STe/TT
sound hardware is similar in may respects - but it still bleeps,
just like the Amiga does. At least when you're talking about
professional music!
> Except when you run things like Amigavision or hypertext/authorware
>applications where you want to combine animations with digitized sound.
>For CDTV it's a nice addition, along with it's 16bit sound and it's MIDI
>port.
It's _nice_ to have it, I agree upon that. But I don't need it. That's
why I bought the ST and the TT instead of an Amiga.
> But does it have DMA for each channel? Can you change the DMA rate?
>I heard the STe's DMA sound is fixed at one frequency/sampling rate and
>can't change it.
That's wrong. I didn't delve into the details yet, but I'm sure there
is more than just one sampling rate.
> The new HD drive on the A3000 has 3 modes. 880k, 1.44mb, and 1.76mb.
>1.44mb mode was the main reason for making it. You can also buy
>$200 SCSI floppy drives.
Does it format standard MFM format so that every PC can read it?
> The A3000 has 32-bit for it's harddrive , and it normally gets
>xfer rates of up to 2mb/second (and this only eats 5% of the CPU time
>while doing it.) The Amiga has over 25 DMA channels. The A3000 now has
>8 integrated custom chips to handle them.
We know all that. What do you want to prove by that?
>(A2024) 1024x1024 PAL on the Amiga without a graphic card, just need a nice
>monitor. (The 1024x1024 also has 4 grey colors for the 3d GUI look)
From what I've heard, the 2024 is a monitor with special hardware
integrated in it that buffers screen frames and displays them at
quadruple the speed the Amiga sends it. This way, the Amiga sends
a forth of the whole screen in every screen frame, and the monitor
composes the complete picture. This means you have a real refresh rate
of 50Hz/4 or 60Hz/4. Not exactly what I would call "without a
graphic card".
>With Commodore's A2410 you get up to 1024x1024 with 256 colors out of
>16.7 million.
Is it available?
----------------------------------------------------------------------
Claus Brod, Am Felsenkeller 2, Things. Take. Time.
D-8772 Marktheidenfeld, Germany (Piet Hein)
csbrod@medusa.informatik.uni-erlangen.de
Claus_Brod@wue.maus.de
----------------------------------------------------------------------
------------------------------
Date: 27 Jun 91 13:56:13 GMT
From: infonode!ingr!nijmeg!swindon!st_nik!nik@uunet.uu.net (Ashley Buss x4382)
Subject: For Sale (UK Only)
To: Info-Atari16@naucse.cse.nau.edu
Apologies for worldwide distribution, but are newsfeed is a leaf
on an American tree, but on with the message :-
1040 STFM with 80 MB hard drive and Supra interface enclosed in the Tower box
with SM 125 mono display. The following software is included Timeworks DTP,
Harlekin, Devpac 2, Personal Finance Manager, Wordwriter, Hisoft C etc
price 550 pounds
Home phone number 0793 (Swindon) 831416
Work phone number 0793 (swindon) 619999 x 4382
--
|--------------------------------------------------|
| Ashley Buss Mail : a_buss@swindon.ingr.com |
|--------------------------------------------------|
------------------------------
Date: Thu, 27 Jun 91 13:34:43 CDT
From: Mike Dorman <MDORMAN1@UA1VM.UA.EDU>
Subject: Info-Atari16 Digest V91 #357
To: Atari List <Info-Atari16@naucse.cse.nau.edu>
On Thu, 27 Jun 91 08:00:14 MST Info-Atari16 said:
> Are there any developers out there that would be willing to post copies
>of the documentation for the exended TT ROM routines? I only ask because I am
>a hobby-programmer, and if I can't have documentation for these extensions, it
>might be a wee bit difficult to use them, and that would be a shame after
>giving Atari my hard earned cash for this excellent but overpriced machine.
Well, the bad news is, the information you request is probably covered by a
non-disclosure agreement.
The good news is that ++jrb's bindings for GNU C have support for all the new
functions.
If you get those, you should be able to tell how to call any particular
functions (and the names are reasonably self-explanitory, and similar to the
ST bindings they resemble), and you could probably get away with requestion
specific information here--like stuff about just what Mxalloc does, things
like that.
Mike.
-------------------------------------------------------------------------------
: Michael Alan Dorman : :
: MDORMAN1@UA1VM.UA.EDU : Hobbies are things people do when they should be :
: BIX: syssupport : sleeping. --M.A.D. :
: GEnie: M.DORMAN2 : :
: PostalNet: : :
: Box 8068 : Stonehenge was built by two drunks with no :
: Tuscaloosa, AL : witnesses. --P.S.McGhee :
: 35486 : :
-------------------------------------------------------------------------------
------------------------------
Date: 27 Jun 91 16:52:54 GMT
From: sae!malay@uunet.uu.net (Bob Malay)
Subject: UPDATE: Atari ST Parting out Sale!
To: Info-Atari16@naucse.cse.nau.edu
|> $35 CAD 3D 2.0 w/ CyberMate and Architect Design Disk
|> Please make all offers/inquiries to crouland@gmuvax2.gmu.edu
I want this!
Robert M. Malay
HCR 61 Box 464
Sumerduck, VA 22742
(703)439-1105
Thanks
Bob Malay
------------------------------
Date: Thu, 27 Jun 91 13:46:17 CDT
From: Mike Dorman <MDORMAN1@UA1VM.UA.EDU>
Subject: Usenet access...
To: Atari List <INFO-ATARI16@naucse.cse.nau.edu>
Could anyone please provide me with clear, complete instructions on how
to get Usenet or UUCP access? I need instructions for everyting--what
software to use, what sort of dial up access to what I'd need, how to set
stuff up. I would like to do this from my Atari (currently, I have only
1200 baud, but if this goes through, this will no doubt change), as I'd like
to have direct access to this list instead of just getting Digests. I'd also
like access to c.s.a.s.t (or whatever the *techie* branch is...)
I'd appreciate any help you could give me--accessing this list from the
mainframe at work is a pain, one I would really like to relieve. :
Mike.
-------------------------------------------------------------------------------
: Michael Alan Dorman : :
: MDORMAN1@UA1VM.UA.EDU : Hobbies are things people do when they should be :
: BIX: syssupport : sleeping. --M.A.D. :
: GEnie: M.DORMAN2 : :
: PostalNet: : :
: Box 8068 : Stonehenge was built by two drunks with no :
: Tuscaloosa, AL : witnesses. --P.S.McGhee :
: 35486 : :
-------------------------------------------------------------------------------
------------------------------
Date: 27 Jun 91 17:18:31 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!sol.ctr.columbia.edu!ira.u
ka.de!fauern!faui43.informatik.uni-erlangen.de!csbrod@arizona.edu (Claus Brod)
Subject: Was: How is Atari doing in Europe?
To: Info-Atari16@naucse.cse.nau.edu
adamd@rhi.hi.is (Adam David) writes:
>Yes, I've used this. Trouble is, I want to be working with non-GEM and GEM
>programs. On a 68000 there is not _very_ much available memory space. Because
>there is (almost) no distinction made between user and supervisor spaces
>and because code=data space, it is not possible to get a full 16 MB of user
>RAM. Therefore the ROM and RAM must compete for available address ranges.
>When GEM is running, there is space taken by the GEM variables and data
>structures. So far it has not been possible to deinitialise GEM and reclaim
>this space without a reset. If GEM is in ROM, the space taken by the GEM code
>cannot be reclaimed either. 256k might not be considered very much memory
>any more but it's enough for one more full-blown application process or
>for one of the non-GEM applications to handle more data in memory at once.
Much more address range is "wasted" by the generous hardware register
assignments. No, I don't think this is a serious restriction. At least,
I don't know a single application that would run on a 1 MB ST without
GEM and doesn't because GEM installs its own data areas. It wouldn't be
bad to reclaim the space GEM allocated for itself, but I think there are
lots of other, more important things in TOS that should be improved
before this.
>>The current TOS versions cannot handle a physical sector size of 1024
>>bytes. It's not unreasonable to suppose that this won't ever find its
>>way into TOS again due to compatibility problems.
>Conceptually there is the same problem with supporting HD floppies.
>In the one case it can be fixed in hardware, in the other case it needs
>a software fix. In either case the newer format cannot be used by the
>older machine without modification.
The difference is: DOS machines won't understand 1024-byte-sectors.
And file system compatibility has always been of some importance
for Atari, as it seems.
>>As I stated a while ago, I tested a third-party floppy driver some time
>>ago which offered 1024-bytes-per-sector support.
>Is this available anywhere? I simply don't have the time right now to write
>my own floppy driver, but would like to move to this format.
Not yet - as far as I know. I don't know what the author did with it.
>Yes, and some parts of the assembler generated code will need to be protected
>from the optimiser. Even in 1.62 there are software timing loops. There might
>also be certain race conditions which must be avoided.
Even TOS 3.01 seems to have timing loops. When moving TOS 3.01 to TT-RAM,
thus speeding it up by 20 to 40 percent, sometimes you get problems
when reading and writing HD disks ("data corrupted" alerts and the like).
I think this is due to some tight timing loops that break in the fast
part of RAM.
>About a possible RAM-based GEM. Is it not reasonable to have a GEM which
>allocates its data memory somewhere other than below the TPA base address?
>This would seem to offer more flexibility in initialising and removing GEM
>(maybe several times) during the same work session.
Most of the memory GEM uses is malloc()'ed just like any other memory block.
----------------------------------------------------------------------
Claus Brod, Am Felsenkeller 2, Things. Take. Time.
D-8772 Marktheidenfeld, Germany (Piet Hein)
csbrod@medusa.informatik.uni-erlangen.de
Claus_Brod@wue.maus.de
----------------------------------------------------------------------
------------------------------
Date: 27 Jun 91 13:24:43 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!cs.umn.edu!simvax.labmed.u
mn.edu!davidli@arizona.edu
Subject: What archiving format?
To: Info-Atari16@naucse.cse.nau.edu
In article <3580@laura.UUCP>, klute@tommy.informatik.uni-dortmund.de (Rainer
Klute) writes:
> Using LHarc of whatever
> version could only under the following conditions be tolerated:
Add to Rainer's list:
- The source code and executable code should be Public Domain (ie. no calls
for Shareware fees involved)
One of the reasons I despise most of the LHarc versions is that their authors
are trying to make a buck while they introduce incompatibilities. (The author
of xlharc 1.2 excluded from this list...)
--
David Paschall-Zimbel davidli@simvax.labmed.umn.edu
------------------------------
End of Info-Atari16 Digest
******************************
