Mailer@ECLA.USC.EDU (The Mailer Daemon) (05/16/87)
Message undelivered after 1 day -- will try for another 2 days: *PS:<BBOARD>INFO-ATARI.TXT@GUMBY.#DECnet: Cannot connect to host ------------ Received: from SCORE.STANFORD.EDU by ECLA.USC.EDU; Thu 14 May 87 15:44:12-PDT Date: Thu 14 May 87 09:34:32 PDT Subject: Info-Atari16 Digest V87 #212 From: Info-Atari16 Digest <Info-Atari16@Score.Stanford.EDU> Errors-to: Info-Atari16-request@Score.Stanford.EDU Maint-Path: Info-Atari16-request@Score.Stanford.EDU To: Info-Atari16 Distribution List: ; Reply-to: Info-Atari16@Score.Stanford.edu -------
Mailer@ECLA.USC.EDU.UUCP (05/17/87)
Message undelivered after 2 days -- will try for another 1 day: *PS:<BBOARD>INFO-ATARI.TXT@GUMBY.#DECnet: Cannot connect to host ------------ Received: from SCORE.STANFORD.EDU by ECLA.USC.EDU; Thu 14 May 87 15:44:12-PDT Date: Thu 14 May 87 09:34:32 PDT Subject: Info-Atari16 Digest V87 #212 From: Info-Atari16 Digest <Info-Atari16@Score.Stanford.EDU> Errors-to: Info-Atari16-request@Score.Stanford.EDU Maint-Path: Info-Atari16-request@Score.Stanford.EDU To: Info-Atari16 Distribution List: ; Reply-to: Info-Atari16@Score.Stanford.edu -------
Mailer@ECLA.USC.EDU (The Mailer Daemon) (05/18/87)
Message undeliverable and dequeued after 3 days:
*PS:<BBOARD>INFO-ATARI.TXT@GUMBY.#DECnet: Cannot connect to host
------------
Received: from SCORE.STANFORD.EDU by ECLA.USC.EDU; Thu 14 May 87 15:44:12-PDT
Date: Thu 14 May 87 09:34:32 PDT
Subject: Info-Atari16 Digest V87 #212
From: Info-Atari16 Digest <Info-Atari16@Score.Stanford.EDU>
Errors-to: Info-Atari16-request@Score.Stanford.EDU
Maint-Path: Info-Atari16-request@Score.Stanford.EDU
To: Info-Atari16 Distribution List: ;
Reply-to: Info-Atari16@Score.Stanford.edu
Info-Atari16 Digest Thursday, May 14, 1987 Volume 87 : Issue 212
This weeks Editor: Bill Westfield
Today's Topics:
Re: FOLDRxxx.PRG and ROM-TOS versions
Re: Bad floppies
curses V1.1 and some raving ...
Re: Megamax inline assembly woes (solution)
Re: Bug report: 'The Russian Doll' sp. nova (?)
Re: New Control Panel...
Re: Interactive fiction
Microsoft WRITE; D.R. WRITE & PAINT
Better Windows? (LONG)
Re: MWC compiler 2.0
----------------------------------------------------------------------
Date: 11 May 87 14:56:19 GMT
From: ihnp4!ihuxz!burris@ucbvax.Berkeley.EDU (Burris)
Subject: Re: FOLDRxxx.PRG and ROM-TOS versions
To: info-atari16@score.stanford.edu
In article <724@atari.UUCP>, dyer@atari.UUCP (Landon Dyer) writes:
> The <expletive inserted> who pirated FOLDRxxx.PRG from Atari neglected
> to include three other files intended to be distributed with the
> software. (There are three programs, plus one file containing
> documentation which carefully explains just what the limitations of
> the folder adder are).
>
I would like to know when we can expect a supported (or at least
official) version of FOLDRxxx.PRG. I would also like to know if it really
fixes the 40 folder problem (bug?) or if it just takes up memory space.
I would gladly pay a modest fee for a version that I know works.
Should I expect this to happen or should I begin using GEMBOOT.PRG?
Dave Burris
ihnp4!ihuxz!burris
------------------------------
Date: 11 May 87 20:44:22 GMT
From: cmcmanis@sun.com (Chuck McManis)
Subject: Re: Bad floppies
To: info-atari16@score.stanford.edu
In article <952@viper.UUCP>, john@viper.UUCP (John Stanley) writes:
> ... (It doesn't hurt that I've located
> a local source that sells SS Sonys for $14.50 per box of 10... :)
> John Stanley (john@viper.UUCP)
One Hour Photo in the San Francisco Bay area sells *Double* sided Sonys
for 14.50 for a box of 10. So the point kinda becomes moot. The whole
SS/DS debate rages on and off every year and everyone decides to make
up their own minds in the matter. My only comment is that the incremental
cost of DS disks is not enough to discourage use. As the IBM PS/2 stuff
gears up the difference in price will eventually erode to near zero.
--
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses. But you knew that, didn't you.
------------------------------
Date: 11 May 87 17:05:31 GMT
From: mcvax!nikhefh!u13@seismo.css.gov (Rene van 't Veen)
Subject: curses V1.1 and some raving ...
To: info-atari16@score.stanford.edu
I just finished sending curses release V1.1. It now works on all compilers
I could get hold of.
Some of you may have noticed some funny looking comments in my source,
like /* #[wrefresh: . or /* #]wrefresh: . Do not just think I have a
really weird way of making my comments. These are signals to the editor
I'm beta-testing. It makes it recognize things called 'folds', which come in
very handy while programming or writing documentation. I go into the
editor press F6 and voila all I see is one line saying ###curses: etc ...
I open it and just fix the modules I'm interested in, without having to
perform huge scrolls etc ... Furthermore it is a great way of structuring
things, when the language itselfs requires no structure. Once you've used
you just can't do without. The editor itself beats the shit out of any other
editor ( imagine doing 1200 replaces in a 200K file in little over a second :-)
Somebody wanted the VAX/EDT editor, well the screen part of such an
editor is in curses, you would just have to write the editor proper ..:-)
Still open to any suggestions etc ...
--- Rene.
--
-----------------------------------------------------------------------------
R. van 't Veen .. mcvax!nikhefh!u13. All opinions are my own.
------------------------------
Date: 11 May 87 09:07:20 GMT
From: mcvax!nikhefh!gert@seismo.css.gov (Gert Poletiek)
Subject: Re: Megamax inline assembly woes (solution)
To: info-atari16@score.stanford.edu
In article <1959@ihuxy.ATT.COM> nowlin@ihuxy.ATT.COM (Jerry Nowlin) writes:
>In article <270@nikhefh.UUCP>, gert@nikhefh.UUCP (Gert Poletiek) writes:
>>
>> The Mark Williams package is far better, it implements K&R to the full,
>> and the extensions like struct assignment, structs as function arguments,
>> functions returning structs, enumerated type. The only thing it lacks is
>> an in line assembly implementation like Megamax.
>>
>>
>> Gert Poletiek
>
>I have Megamax and while I haven't tried it yet the manual says that
>structure assignment and passing by value are supported. What else did
>you think was left out of Megamax? I have the devkit, Lattice and Megamax
>and wouldn't trade Megamax for both of the others put together.
>
>Jerry Nowlin
>(...!ihnp4!ihuxy!nowlin)
I own the Lattice and Megamax compilers, used the devkit at work, and copied
Mark Williams 2.01 from a friend to try it out. Now I'm looking for the fastest
way to get MWC officially (if that's the word).
Some of the things that Mark Williams will compile and Megamax will not:
Passing a structure to a function:
function ( var )
struct x var; /* notice the absence of the '*var' !! */
{
...
}
Function returning a structure:
struct x
function ( ... )
{
struct x x;
....
return ( x ); /* return a structure !! */
}
Declaring variables both at the top of a function and in a loop:
function ( ... )
{
int x, y, z;
....
while ( condition ) {
register char *cp; /* <<< megamax won't allow this */
}
}
All of these things are not in the 'C programming language' by K&R, but they
are additions made to the C language by K&R and are (as far as I know)
documented for the first time in the Unix Programmer's Manual for version 7
Unix from Bell.
It may be that these things are not really needed, but they make life a lot
easier (sometimes).
Now for the bugs in the Megamax package:
- the optimizer will crash if you reference a label in assembly (inside a C
function) but forget to declare it
- sometimes the linker garbles a module taken from a library.
- the librarian will crash if you try to create a library with more than
about 115 modules in it.
- the megamax guys don't know what initialized data is.
- the resource generator crashes on complex object trees.
- the resource generator does not allow you to create 'UserProc' objects
These bugs in Megamax, and the fact that the Mark Williams package is very
complete, make me choose for Mark Williams-C.
Gert Poletiek
------------------------------
Date: 11 May 87 19:12:54 GMT
From: dayton!viper!john@RUTGERS.EDU (John Stanley)
Subject: Re: Bug report: 'The Russian Doll' sp. nova (?)
To: info-atari16@score.stanford.edu
In article <8705081618.AA15013@ucbvax.Berkeley.EDU> 051332@UOTTAWA.BITNET writes:
>The disks:
>SSDD Maxels formatted to DSDD with David Small & Dan Moore's TWISTER
>with the net mods (82 tracks)
The problem is with the original version of TWISTER. If you swap a
twister formatted disk for another twister formatted disk, the desktop
has problems detecting the change. The example you gave of clicking
on a folder and having the same directory appear is a symptom. (Note:
if you click on the folder a second time, the desktop will correctly
open the folder and all is fine...) The problems you are having are
partialy in the TWISTER and partialy your own falt for using the short
cuts you were using,, (Although you would have found things to work
differently if you were not using TWISTER disks so it's not really
your falt :)
The solution is to run-not-walk to your local CI$ node and check in
the atari16 conference in the utilitys (I think) file area. There you
will find a new version (Version 1.1) of twister called TWISTE.PRG.
This version solves the problems in the original version. I've been
using it for a couple of weeks and am -very- happy with the results.
PS: I'd love to send the upgrade via the net, but I can't because
the program is copyrited so please don't ask... (I imagine there will
be an upgrade sent out in a future issue of the magazine, but I don't
know for sure. They placed it on CompuServe as a courtesy to readers
who were having problems, but with the stipulation that it not be
distributed thru any other media...)
---
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
------------------------------
Date: 11 May 87 19:45:34 GMT
From: dayton!viper!john@RUTGERS.EDU (John Stanley)
Subject: Re: New Control Panel...
To: info-atari16@score.stanford.edu
In article <870510005754.00000548.AJNB.MA@UMass> Flash@UMASS.BITNET (Rick Flashman) writes:
>What I would really like to see, would be a new enhanced control
>panel.
>
>These are some of the things I believe it should have:
While I like most of your ideas, I really don't see why you'd want
many of them taking up ram space all the time. I save accessory
slots for the things I use often. If you use these things all the
time, so be it, but I'd suspect most peole would prefer to use
AUTO folder programs (many exist to set the things you want in the
control panel) to set up the configuration they use the most and run
programs when they need to change things.
>4. Corner clock. Simmilar to ALARM CLOCK.ACC which works ANYWHERE and
> DOES update every second.
This already exists as a program I wrote called JCLOCK. I'm working
on an update and when it's finished, I'll send it to Turner. It has
the advantage of being a TSR (terminate stay resident) instead of a
accessory so it doesn't take up desk slots. It also runs in any and
all prgs (it doesn't rely on GEM psudo-multitasking) and it can be
switched on or off at any time with a special keystroke...
>9. Automatic setting of both SYSTEM and KEYBOARD clock when time is
> changed.
I've considered putting this in as a side effect of JCLOCK (would be
pretty simple to do) but I wasn't sure if there were any programs
which rely on the ability to change one while leaving the other alone.
If anyone has an opinion on this last item, please feel free to
comment....
---
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
------------------------------
Date: 11 May 87 23:41:24 GMT
From: husc7!hadeishi@husc6.harvard.edu (Mitsuharu Hadeishi)
Subject: Re: Interactive fiction
To: info-atari16@score.stanford.edu
Re: Interactive Fiction
In the last issue of BYTE magazine a LISP-like interactive
fiction authoring system was described. The listing is in C and is
available on BIX. Anyone with a BIX account like to download it and
post it to some newsgroup that we all have access to? I for one wouldn't
mind porting the thing to the Amiga, and I'm sure others would enjoy porting
it to their respective systems. Since it is written totally in C it
should be relatively easy to port to any C-equipped system. I presume
the author wrote it on a IBM-PC so there may be PC-specific code which
would clearly have to be modified; hopefully not. It looks VERY nice; it
supports "verb noun preposition noun", conjunctions (as in "verb noun
and noun preposition noun", where "noun" can be things like "the big
red book" and so on. I've written such a system in AmigaBasic which
has a similar level of parser complexity, but of course the LISP syntax
makes the adventure system much nicer; in particular you specify rooms
by name, objects can have arbitraily long property lists, and objects
can have different sets of properties (i.e., not all objects have to
have all of the possible properties) and so on. Very nice.
-Mitsu
------------------------------
Date: Mon, 11 May 87 20:42:05 PDT
From: <UASST4%MCMVM1.BITNET@forsythe.stanford.edu>
To: info-atari16@score.stanford.edu
Date: Mon, 11 May 87 21:58:29 LCL
To: info-atari16@score.STANFORD
From: UASST4@MCMVM1
Date: 11 May 1987, 21:57:48 LCL
From: UASST4 at MCMVM1
To: INFO-ATARI16 at SCORE
test
------------------------------
Date: 11 May 87 03:36:22 GMT
From: oliveb!pyramid!prls!philabs!sbcs!sbstaff2!lean@ames.arpa (Lean L. Loh)
Subject: Microsoft WRITE; D.R. WRITE & PAINT
To: info-atari16@score.stanford.edu
Does anyone know the status of the above mentioned software? A friend of
my friend (who's in France) claims to have Microsoft's WRITE and
Digital Research's Write.prg Paint.prg and Gem Paint. Are these available
in the States ?
--
CSNET: lean@sbcs.csnet
ARPA: lean%suny-sb.csnet@csnet-relay.arpa
UUCP: {allegra, hocsd, philabs, ogcvax}!sbcs!lean
------------------------------
Date: 12 May 87 04:58:47 GMT
From: bloom-beacon!chekmate@husc6.harvard.edu (Adam Kao)
Subject: Better Windows? (LONG)
To: info-atari16@score.stanford.edu
I've been thinking for a long time about the ideal user interface on a
graphics-intensive computer. The window and icon system popularized
on the Mac seems to me a step in the right direction, but I still have
reservations. Some of my major concerns:
- most icon systems put too much emphasis on graphics for my
taste. Text has it's own special advantages:
- input speed (if you're a touch typist)
- output speed
- flexibility (e.g. moving around a tree directory structure)
I'm not saying text is king; I just think we need some balance.
- the windowing concept doesn't seem to be efficient; there
are lots of things the user can do that he doesn't need, and
these extra features take a lot of compute power. I'm sure
we've all seen novice users spend half an hour resizing windows
and shuffling them around.
- What use is a window that is half-hidden? Why would
anyone want to see only the left half of a document?
If the right half is unnecessary, why show the
document at all? Microsoft's tiling system doesn't
have this problem, but it isn't intuitive enough.
- Do we need to move windows arbitrarily like pieces
of paper? What difference does it make whether a
window is a few pixels to the left or right?
- At the same time, current window systems don't really
use the potential of these machines. These computers can
simulate arbitrary universes; we confine them to a mildly
mutated desktop. I guess I am attacking the desktop
metaphor; just because it's familiar doesn't mean it's good.
I think a good user interface ought to concentrate the available power
on productive, often used functions (like a RISC chip :-)). One
shouldn't spend programmer time and computer time adding bells and
whistles that let the user do useless things. Of course we also need
a system that is "intuitively obvious", and these requirements often
conflict. In essence, I'm posing some open questions; what features
belong in this kind of system? For example, I often hear windows
described as independent terminals - why not endow them with all the
capabilities of the physical terminal (window recursion)? Is this
useful? If there is an ideal window arrangement for certain
applications, do we need to let the user mouse around trying to find
it? What kind of metaphor should we use, if not the desktop? Is
a real-world metaphor necessary?
The fundamental question is, how can we make the important stuff
available at the right time, without cluttering the display with
leftovers and without forcing the user to clean up after us?
I realize I've been long-winded, but I feel that the hardware is just
sitting there begging to be used, and when the software catches up
we're really gonna see what these damn machines can do.
Adam
------------------------------
Date: 10 May 87 17:49:30 GMT
From: ritcv!rocksvax!rocksanne!sunybcs!cald80!dgy@cs.rochester.edu (dgy)
Subject: Re: MWC compiler 2.0
To: info-atari16@score.stanford.edu
From uucp Sat May 9 18:15:10 1987
Status: R
I was also getting bombs with MWC 2.0, and after doing some experimenting
I found that if you have a large RAMdisk installed, the compiler will
run out of memory, hence the bombs. I reworked my RAMdisk to be 100K
smaller and the problem was solved, but on occasion I find that when
compiling something _really_ big, I need to do it entirely from floppy
with no RAMdisk at all. BTW, I'm running a 1040 with only the built-in
floppy.
If you are running on an unmodified 520, try upping the memory to 1 meg.
Or, a cheaper solution would be to break your program down into smaller
piece, compile 'em separately, and link 'em together when done.
Dave Yearke
Sigma Systems Technology, Inc.
seismo!kitty!sunybcs!cald80!sigmast!dgy
decvax!sunybcs!cald80!sigmast!dgy
------------------------------
End of Info-Atari16 Digest
**************************
-------
-------