Copy Link
Add to Bookmark
Report

Info-Atari16 Digest Vol. 89 Issue 785

eZine's profile picture
Published in 
Info Atari16 Digest
 · 5 years ago

  

=========================================================================

INFO-ATARI16 Digest Sun, 10 Dec 89 Volume 89 : Issue 785

Today's Topics:
Lattice C v5
Shareware Mac
SIGNOFF INFO-ATARI16
Still searching...
What Kermit/UNITERM bugs?
Word Writer format company
----------------------------------------------------------------------

Date: 5 Dec 89 04:48:05 GMT
From: pacbell!pbhya!dbsuther@ames.arc.nasa.gov (Daniel B. Suthers)
Subject: Lattice C v5
Message-ID: <31162@pbhya.PacBell.COM>

In article <8911301233.aa02350@benjamin.Cs.Bham.AC.UK>
RiddCJ@computer-science.birmingham.ac.UK (Chris Ridd) writes:
>
> The reason Metacomco hasn't announced any updates to Lattice C (or any of
>their stuff), is because ... they have quit the software market. I believe
>the owner now runs a hotel :-(
> HiSoft have taken over Lattice C - v5
[ text deleted ]
>I'm not sure, but I think you can upgrade from MCC v3 to HiSoft v5 at a cost.


Is there any confirmation on this rummor?
I have spent a lot of time getting Lattice to be relatively bug free, and don't
wish to switch compilers now.

Does anyone have the address for HiSoft? Are they American, or de we have
to put up with the six week trans atlantic mail delay?

Last question: is HiSoft V5 an upgrade to lattice, or just a replacement? The
difference is obvious to those who have extensive private code libraries.


-------------------------------------------------------------------------------
Dan Suthers, Analyst, Pacific Bell
uucp: ?backbone?!pacbell!pbeos!dbsuther
-------------------------------------------------------------------------------
Youth's a difficult time, and it gets harder the longer you try to draw it out.
-------------------------------------------------------------------------------

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

Date: 9 Dec 89 23:42:25 GMT
From: well!dsmall@apple.com (David Small)
Subject: Shareware Mac
Message-ID: <14883@well.UUCP>

Hmmm .. shareware Aladin, eh?

I'm also surprised to hear that I've been quoted as saying anything
negative about Aladin. The only thing I recall was a comparison between it
and Spectre 128, and that is an apples-and-oranges comparison (no pun meant).
I use the 128K ROMs, and get the benefits of that; Aladin uses the 64's, and
gets the bugs in those. For those that don't know, the reason Spectre runs
all the Mac programs that Aladin can't has nothing to do with our relative
programming skill, etc; it's just the 64K ROMs are obsolete and much software
doesn't run on them.

I'll say it again -- while the makers of Aladin and I had different
ideas about how things should be done, I feel the Aladin was implemented quite
well according to their vision. I don't happen to agree with the vision, but
I can agree with the competence, ok?

Since both the MagicSac 6.1 and Aladin 3.0 use 64K ROMs, it is at
least fair to compare them. Both have strong and weak points. The Aladin does
a superior job with serial ports (SERD) by far! The Magic Sac doesn't
require a patcher program to "fix up" Mac programs before running them.
And so forth and so on ... by the time you end up comparing strong and weak
points, I think they come out equal -overall-, more or less.

The Magic Sac at one time sold for $149. The price declined to
$79, then to $49, in ads in START magazine. I am repeatedly told that the
unitit now offered at $40, $20, or free with purchase of Translator.
Essentially, that's the U.S. market for a 64K ROM based Mac emulator.
And it's my opinion that the Aladin-shareware will meet much the same
response, alas.

It's too easy to slip into the "features trap", when in reality both
Magic Sac and Aladin are "icing" on the ROM "cake". The truth is, using
64K ROMs automatically breaks a large amount of Mac software. Even Apple
doesn't support them anymore; they gave up fixing bugs on bugs. Very
quickly, Hypercard, Quark X-Press, MacWrite 5 & II, MacPaint 2, MultiFinder,
Systems & Finders past Finder 5.3 / System 3.2 (obsolete in anyone's book;
we're at Finder 6.1 / System 6.0.4 now), CDEV's, Adobe Illustrator, Aldus
Freehand ... well, I could fill up a few pages with this, but I think I've
made my point. Apple and its developers have abandoned the 1983 64K ROMs,
and with good reason.

These programs are what make a Mac into a useful tool that people are
wiling to spend money for. To me, it is irrelevant that Aladin does a nicer
job on the serial port, or RESET button, or whatever, if it won't run the
software I want to run. The icing on the cake doesn't matter, be it Magic Sac,
Aladin, or chocolate.

At the moment, I feel the state of the art in Mac emulation, on both
Amiga and ST, is a 128K ROM emulator that is capable of directly read/writing
Mac disks. Things have progressed a long way since the original 64K ROM
emulators debuted in 1986.

I do hope that if this product is made availabl as shareware, that
people do not expect it to do what Spectre / AMAX can -- and thus end up
turned off to the newer products.

As for Apple, I've always been square with them, and they've
treated me with the same courtesy. There's nothing to tell there that hasn't
been told sixty times -- we agreed not to name the product MacCartridge and
not to sell Mac ROMs. (Now, if you want to look at something *interesting*,
delve into the court documents surrounding the origins on the Microsoft-Apple
look&feel lawsuit; Data Pacific's name is all over them. I think they are
online on BIX; at least, I was sent them from there.)

If I may ask -- can the story of the development of Aladin be told?
I remember the name Mathias Greve, and something about two brothers who
did the original product; I'm not familiar with the shareware offerer's
name. I'd like to hear it if you'd care to tell it.

Again, if you'll check through several interviews and articles,
you'll find I have said good things about Aladin -- and that I've maintained
that comparing 64K ROMs to 128K ROMs is unfair. And I thought doing sound
through the parallel port was really a neat idea; the overhead of doing it
through the sound chip was pretty hairy.

Anyway, I guess that's my comment on the "shareware Mac". Please,
be very careful, for your own sakes, that Apple is aware that you're not
putting ROMs on disk and don't allow EPROMS. And be very very careful of
"derivative work" issues surrounding patching software to run on the Aladin,
ok? There's some real minefields there to be cautious of.

If any of the makers of Aladin ever make it to Denver, please
give me a call, okay? Let's go get a beer.


-- thanks, Dave Small / "I drink Foster's, personally / Gadgets

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

Date: Sat, 9 Dec 89 18:21 N
From: "Antonin, TU Vienna, T.+222/58801/3612"
<SPRINZL%EGH780.UNA.AT@CUNYVM.CUNY.EDU>
Subject: SIGNOFF INFO-ATARI16

SIGNOFF INFO-ATARI16

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

Date: 10 Dec 89 08:17:15 GMT
From: clubok@husc4.harvard.edu (Ken "The Snake" Clubok)
Subject: Still searching...
Message-ID: <3387@husc6.harvard.edu>

Ken B. says:
>A side effect of having strong support for professional programmers is
>that end users get supported as well. More books get written by the
>professionals, making more information available to the hobbyist than
>the computer maker can hope to provide. A broader base of technically
>competent people exist to answer the questions of hobbyist programmers.
>All these programmers will be happy because they can get their
>questions answered and they can solve their problems without having to
>stumble around in the dark too much.
>--
Sorry Ken, but I can't accept this. Mostly, I've avoided getting
involved with the flame wars against Atari, since a lot of the comments
have been overly negative if not inaccurate. Also, I really appreciate
your taking the time to participate in the net, and the other Atari
employees as well. But this last comment of yours makes no sense when
you consider that developers must sign a non-disclosure agreement that
prevents developers from legally releasing a good deal of important
information contained in the developers' kit. It seems as if Atari is
intentionally trying to restrict the flow of information, although I
could hardly guess why. Before I can believe that Atari intends for
developers to take its role in educating the hobbyist, it will have to
change this unexplicable policy.
> ||| Ken Badertscher (ames!atari!kbad)
> ||| Atari R&D System Software Engine
> / | \ #include <disclaimer>

Ken Clubok
Clubok@husc4.bitnet
Clubok@husc4.harvard.edu

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

Date: 5 Dec 89 05:11:43 GMT
From: pacbell!pbhya!dbsuther@ames.arc.nasa.gov (Daniel B. Suthers)
Subject: What Kermit/UNITERM bugs?
Message-ID: <31163@pbhya.PacBell.COM>

In article <89337.135453SML108@PSUVM.BITNET> SML108@PSUVM.BITNET writes:
>On the subject of kermits and ST's...
>
>I also use the Uniterm Kermit to transfer to and from my ST. it works fine wit
>h VAX computer systems, however weird, VERY WEIRD stuff happens with Unix sys-
>tems, both System V and 4.3bsd. It works fine transferring text files, but
>gives a potpourri of errors with binary files. This DOES NOT HAPPEN ON VAXES!

I have no idea why it eventually works with the retries set high enough, but
I have found that some UNIX kermits default to binary, and some to text. It
becomes important to specify [binay/text] on BOTH ends to get a valid transfer.

Some of the unix ports don't always switch properly between 7 and 8 bit modes
either. It's always best to match up before starting the transfer; after all
it is PD software and no-one is playing gaurdian.


-------------------------------------------------------------------------------
Dan Suthers, Analyst, Pacific Bell
uucp: ?backbone?!pacbell!pbeos!dbsuther
-------------------------------------------------------------------------------
Youth's a difficult time, and it gets harder the longer you try to draw it out.
-------------------------------------------------------------------------------

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

Date: 10 Dec 89 02:21:46 GMT
From: rex!samsung!cs.utexas.edu!natinst!rpp386!mark@ames.arc.nasa.gov (Mark
Lehmann)
Subject: Word Writer format company
Message-ID: <17426@rpp386.cactus.org>

In article <7941@cs.yale.edu> fischer-michael@cs.yale.edu (Michael Fischer)
writes:
>In article <227@trwrb.UUCP>, gibson@trwrb.UUCP (Greg Gibson) writes:
>> I use Word Writer because it has a spell check and thesaurus. However, I
>> can not get the paragraph format command to work. Does any know how to
>> make the Word Writer paragraph format command to work? I think anyone
>> selling a word processor without a properly working format command should
>> be jailed for fraud.
>>
>> Thank You,
>> Gregory Gibson

Because of this very reason, I wrote a C program to analyze regular text
files and determine where the paragraphs end and then convert the text file
into a Word Writer (also First Word) file. I can send it to anyone who
wants it. It is just a short C program (written in Laser C, but ports to
UNIX, so should be able to port to any C language for the ST).

I don't have my code available now (just reformated the hard drive for
MINIX, and the Laser C code is backed up on floppy) but from memory, I
think that all blank spaces (ASCII 32) gets converted to ASCII character
30. There is a ASCII character 30 before every newline (ASCII 10). And
the end of a paragraph has no ASCII 30 before the newline.

Kind of an interesting format. When the Word Writer format is displayed
all the blank spaces will appear to have disappeared, but really, they are
just represented as ASCII character 30, which doesn't show up on the Atari
ST screen (at least it doesn't in TOS/GEM).

Mark Lehmann
--
+------------------------------------+-----------------------------------+
| Mark Lehmann | |
| mark@rpp386.cactus.org | |
| ?bigtex|texbell?!rpp386!mark | |

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

End of INFO-ATARI16 Digest V89 Issue #785
*****************************************

← 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