Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 89 Issue 737
=========================================================================
INFO-ATARI16 Digest Fri, 1 Dec 89 Volume 89 : Issue 737
Today's Topics:
Apple roms.
HD Floppies
MX2Net question
PC DITTO HELP (PLEEEEEEEEAAAAAAAAAAASSSSSSSSSSEEEEEEEEEEEEEEE)
Shareware macs and international parochialism.
STE vs ST Shifter
tos 1.4 problem?
Video pointer
What Kermit/UNITERM bugs?
----------------------------------------------------------------------
Date: Fri, 1 Dec 89 16:54 GMT
From: Jan Ameij <AMEIJ%vax.oxford.ac.uk@NSFnet-Relay.AC.UK>
Subject: Apple roms.
If Apple let people copy roms so that Mac emulators were cheap, what would
happen to Apple, someone asks? Well, they might produce their hardware at
a reasonable price, instead of the current ludicrous ones...
Anyone notice the collossal damage done to IBM by the availability of MS-DOS?
Love, Jan
------------------------------
Date: Fri, 1 Dec 89 12:19:08 GMT
From: R.D.Chafer%sysc.salford.ac.uk@NSFnet-Relay.AC.UK
Subject: HD Floppies
Message-ID: < 1 Dec 89 12:19:08 A10024@UK.AC.SALF.C>
If you double the clock speed of the floppy controller to 16MHz and it
is only designed to run at 10MHz, aren't you going to seriously shorten
the chips life?
=========================================================================
From: Robert Chafer
Computing Centre Telephone: +44 61 736 5843 x 672 or x7328,
University of Salford,
Salford M5 4WT
UK
E-mail:
JANET: chafer @ uk.ac.salford.sysc
ARPANET: chafer%uk.ac.salford.sysc @ nss.cs.ucl.ac.uk
BITNET: chafer%uk.ac.salford.sysc @ uk.ac
or chafer%uk.ac.salford.sysc%ukacrl.bitnet @ cunyvm.cuny.edu
------------------------------
Date: 1 Dec 89 15:57:56 GMT
From:
mailrus!wuarchive!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!watserv1!watcgl!e
lectro!carlo@tut.cis.ohio-state.edu (Carlo Sgro)
Subject: MX2Net question
Message-ID: <1218@electro.UUCP>
I have tried to network two 1040's together through the MIDI port using the
background networking program that comes with the MX2 multitasking kernel
package. The results were so bad (10+ minutes to load Word Perfect; 1 minute
to get a directory of the other ST's hard drive or floppy drive) that I
can't believe that I've got everything configured correctly. Does anyone
use this program successfully with acceptible results? What is going wrong?
Is this really the way this program works? Please reply by E-mail and I'll
summarize if there is interest.
--
Carlo Sgro Vote for your favorite .signature!
watmath!watcgl!electro!carlo Call 1-900-GOODONE ($2 on your phone bill).
------------------------------
Date: Fri, 01 Dec 89 16:24:49 GMT
From: Mark Powell <SA44%liverpool.ac.uk@NSFnet-Relay.AC.UK>
Subject: PC DITTO HELP (PLEEEEEEEEAAAAAAAAAAASSSSSSSSSSEEEEEEEEEEEEEEE)
I purchased PC DITTO 1 from a friend some weeks back. I would like to access
all three of my available hard disk partitions, which are c:, d: and e: in TOS.
This is done with the device driver PC_HDH.SYS (or something like that!)
However, the instruction file on disk HARDDISK.DOC is corrupt so I can't
find out exactly what line to put in my CONFIG.SYS on my boot system disk.
Can someone please help me, to access my three partitions????
Mark Powell
ARPA sa44%liv.ac.uk@nsfnet-relay.ac.uk
UUCP ...!mcvax!ukc!liv.ac.uk!sa44
------------------------------
Date: Fri, 1 Dec 89 12:02 GMT
From: Jan Ameij <AMEIJ%vax.oxford.ac.uk@NSFnet-Relay.AC.UK>
Subject: Shareware macs and international parochialism.
It seems to me that many of the people who oppose this development think
of the Atari world as the USA only, whereas most of it is here in Europe.
I have not yet seen ads for GCR here, just as Neodesk, for example, has only
just become available here. Commercial software takes longer to travel around,
if it makes it at all, so a European shareware product makes a lot of sense
for us. Of course, if GCR is so good, it will presumably sweep aside any
shareware equivalent as soon as it is sold here...
I have no desire for a MAC emulator myself, as, frankly, I think MACs are best
used as door stops or lump anchors.
Cuddles,
Jan Ameij
------------------------------
Date: 1 Dec 89 18:58:35 GMT
From: uokmax!cbdougla@apple.com (Collin Broadrick Douglas)
Subject: STE vs ST Shifter
Message-ID: <1989Dec1.183920.12339@uokmax.ecn.uoknor.edu>
In article <20157@pasteur.Berkeley.EDU> soohoo@cory.Berkeley.EDU (Ken "nmi"
Soohoo) writes:
>There's been quite a few ponderings in the last few days about the
>possiblity of an STE shifter that's pin-pin compadible with the
>ST shifter -- I just wanna add my $0.02 ;-)
>
>The STE shifter outputs 4 bits of color per gun, which means that
>the DACs required to go to your video are gonna be different, no?
>It would mean Atari would have to lay out another chip that's
>an ST replacement shifter w/o the extra color bit... Seems kinda
>pointless for them, lots of R&D $$, little return, plus they'd
>need lots of packages to hit all the shifter versions out there...
>
>Sigh, that's the way it seemed to me, not likely to be an ST STE
>shifter out any time soon...
>
>
>--Kenneth "kens" Soohoo (soohoo@cory.Berkeley.Edu)
> Atari Hacker (Atari's Hacker...)
> "It could be worse, you could get hit by a bus..."
> My opinions are my OWN, _not_ necessarily Atari's. But "hey", who knows?
Except for one thing. In Medium res the Atari get 16 colors per screen. I
may be stupid but doesn't this already mean that the shifter has to output
4 bits (4 bits = 16 colors)? All they would have to change is the total
number of colors available (from 512 to 4096). And that is just the
difference
of having more shades of the same colors. The primary colors (Red, Green
A
just my $.02 worth.
Collin Douglas
cbdougla@uokmax.ecn.uoknor.edu
and Blue) each with 16 shades gives a total of 4096 colors (16~3).
------------------------------
Date: 1 Dec 89 16:13:29 GMT
From:
mailrus!shadooby!samsung!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!watserv1!w
atcgl!electro!ignac@tut.cis.ohio-state.edu (Ignac Kolenko)
Subject: tos 1.4 problem?
Message-ID: <1219@electro.UUCP>
In article <1836@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
>ignac@electro.UUCP (Ignac Kolenko) writes:
>> Fwrite (wHandle, 0x20000L, (char *)0xC00000L);
>
>Sorry, guy, the ST can only DMA from ST memory. You can't do DMA from
>ROM, either. You'll have to copy from the special memory to real
>memory, then write that to disk. If you're using Fwrite it can't be
>that time critical...
>
thanx for the quick reply. that's all i wanted to know. after the above
code didn't work, the first thing i tried was copying that memory range
into main memory, and then fwriting. just wanted to check if it was something
we screwed up in designing the co-processor card.
a further question: does that mean that with any of these
hi-res displays that are available (ie: 1024 by 1024 type monochrome
display, etc) you cannot save out the screen memory directly to hard
disk?? does that mean that you are forced to always copy the screen
image into main memory, and then save it out??
a further further question: does anyone out there actually own one
of these hi-res mono displays???? if so, how do you like it??
--
=====Ignac A. Kolenko (The Ig) watmath!watcgl!electro!ignac=====
co-author of QuickST, and the entire line of Quick Shareware!!!!
"I don't care if I don't win, 'cause I don't care if I fail"
from 'Youth Of Today' by SUBURBAN DISTORTION
------------------------------
Date: 1 Dec 89 17:26:19 GMT
From: shlump.nac.dec.com!hiatus.dec.com!norge.dec.com!chad@decuac.dec.com
Subject: Video pointer
Message-ID: <1735@hiatus.dec.com>
RE: Atari dispersing info "free" about the ST(e) etc.
Remember on the 8bits the book "DE RE ATARI"?? And the OS guide and hardware
guide that were available (don't remember the names -- the loose leaf ones)???
Why can't Atari do or condone something like that for the STe and other 68k
products for the average Joe to use. Those above mentioned resources were what
got me really interested in Atari -- a lowly high school kid could learn
all about
how to make a computer do neato stuff. And I didn't have to become a
registered
developer, pay too much money, etc.
Chad
DEC has no opinions!
-------------------------
------------------------------
Date: 1 Dec 89 17:30:29 GMT
From:
cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!watserv1!watcgl!jmberkley@tut.cis.o
hio-state.edu (J. Michael Berkley)
Subject: What Kermit/UNITERM bugs?
Message-ID: <JMBERKLEY.89Dec1123029@watnext.waterloo.edu>
> On 30 Nov 89 19:26:00 GMT, 01659@AECLCR.BITNET (Greg Csullog) said:
GC> The ONLY Kermit I trust is UNITERM's so WHAT problems are there?
I too like and trust Uniterm, but there is a small, subtle bug in the
8th bit quoting negotiation. Here is a copy of the message I tried to
send to Simon Poole:
---------------------------------------------------------------------------
Date: Mon, 31 Jul 89 13:03:36 EST
From: jmberkley
Subject: Uniterm Kermit and 8th bit quoting negotiation
I'm having trouble with Uniterm and 8th bit quoting. When Uniterm and
Ckermit negotiate, the transfer does not correctly go into 8th bit
quoting. I asked Frank da Cruz for advice and debugging assistance.
A summary of his reply is printed below.
The problem seems to be that Uniterm says '&' for 8th bit quoting, and
Ckermit replies with 'Y' (meaning yes I'll do it). But Uniterm takes
the 'Y' to be the 8th bit quoting character (!). The 'Y' reply by
Ckermit is documented in the kermit protocol manual from Columbia.
If I set the 8th bit quoting character to be 'Y' in Uniterm, then 8th
bit quoting is properly and successfully performed.
I am using the latest version of Uniterm from cs.orst.edu (sorry, but
I cannot remember the version number right now) and Ckermit 4F(085).
Thank you
Mike Berkley, University of Waterloo
PAMI Lab
jmberkley@watnext.waterloo.edu
?utai,uunet?!watmath!watnext!jmberkley
-------------------------------------------------------------------------
On Wed, 19 Jul 1989 12:44:01 EDT,Frank da Cruz
<fdc@watsun.cc.columbia.edu> said:
FdC> I checked 8th bit quoting between C-Kermit 4F(085) and MS-Kermit
FdC> 2.32/A. These two function perfectly together -- 8th-bit
FdC> prefixing is negotiated correctly, and binary files are uploaded
FdC> from the PC to Unix correctly.
FdC> I looked at the packet log. There are only a few "&" characters
FdC> inside the data packets (well under 50), whereas the file is
FdC> about 14K long. In an average binary file, you would expect to
FdC> find 50% of the characters with their 8th bits on, in this case
FdC> about 7000. This would indicate to me that Uniterm is not doing
FdC> 8th-bit quoting.
FdC> It appears that although Uniterm is putting the right things
FdC> about negotiating 8th-bit-prefixing in its S-packet, that it is
FdC> not following through with this during the data transfer. The
FdC> protocol says that if one side says "&" (as Uniterm did) and the
FdC> other side says "Y" (yes, as C-Kermit did), then 8th-bit
FdC> prefixing will be used. Apparently, it was not.
------------------------------
End of INFO-ATARI16 Digest V89 Issue #737
*****************************************
