Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 89 Issue 714
=========================================================================
INFO-ATARI16 Digest Tue, 28 Nov 89 Volume 89 : Issue 714
Today's Topics:
Blitter disappointment (was: Time to create comp.sys.atari.flames)
Comments on STE -- (un)known facts
Converter Programm HPGL to .IMG for ST available ?
File transferring...
Rainbow TOS ROMs (AGAIN!)
SOUND CDED RUNNING ON SPECTRE
----------------------------------------------------------------------
Date: 27 Nov 89 19:01:56 GMT
From: fox!portal!atari!kbad@apple.com (Ken Badertscher)
Subject: Blitter disappointment (was: Time to create comp.sys.atari.flames)
pa1329@sdcc13.ucsd.edu (pa1329) writes:
| Hmmm,. I wonder why is the Atari blitter so ineffective.
"Ineffective" is a pretty strong word. As has been mentioned, software
speeder-uppers like TurboST and QuickST give a dramatic speed
improvement because they solve the real bottleneck: software overhead.
The BLiTTER chip does what it was designed to do very well. That is,
BitBlt operations are sped up tremendously. A large part of the
graphics processing being done by many ST's is TEXT bit block transfer
operations. As has been demonstrated by Wayne Buckholt and Darek
Mihocka, it is possible, given room, to speed these up significantly.
Fast, resolution specific blit dispatching and code combined with
the BLiTTER chip is phenomenal.
As an aside, I should point out that our VDI guy has put a lot of work
into the blit code for the TT, and it's pretty phenomenal _without_
hardware assist. One other thing that will give a noticeable improvement
is the lack of Line F compression in STE and TT ROMs. The Line F
compression adds a bit of overhead to AES operations, and desktop/window/
dialog operations are noticeably sped up when the compression is gone.
| Its speed is no where comparable to the Amiga's blitter.
As I said above, I think the real problem is a software bottleneck. If
it were possible to put the Ami blitter in ST's, you'd probably get
similar results - albeit with a chip more powerful in terms of variety
of operations.
--
||| Ken Badertscher (ames!atari!kbad)
||| Atari R&D System Software Engine
/ | \ #include <disclaimer>
------------------------------
Date: 27 Nov 89 21:45:17 GMT
From: fox!portal!atari!apratt@apple.com (Allan Pratt)
Subject: Comments on STE -- (un)known facts
daniel@pkmab.se (Daniel Deimert) writes:
>mitsolid@acf5.NYU.EDU (Thanasis Mitsolides) writes:
>>>What it has
>>> [...deleted...]
>>
>>How much memory? What kind of a monitor? What resolution?
>>And what is the price? Just curious.
>1 Mb of memory in the 1040 STE, as I said it's is a slightly modified
>1040 ST.
>The same monitors as before. And as far as I can tell there's no change
>in resolution either [...]
The changes in video are as follows:
The color palette has 4096 colors, not the ST's 512. That's
four bits each for red, green, and blue. You still get the same number
onscreen at a time (4 or 16) but the shades can be finer, and you
can get 16 true grey levels.
The video address can be changed on a line-by-line basis.
This makes split-screen stuff really easy.
The video memory buffer can be larger than the screen.
The screen then becomes a "window" onto this larger canvas.
The video can start on any word boundary.
Each line can be delayed by any number of bits.
What this all adds up to is horizontal and vertical scrolling by bits,
and split-screen effects which are effortless and not memory- or
time-consuming. You can, for instance, load a large "landscape" into
memory, like a whole Gauntlet level, and slide the "window" around by
individual pixels, taking ZERO TIME rather than the huge time required
to move the memory around. In addition, you can have the static
(non-scrolling) part like the scores at the top or bottom: it won't
have to be moved around, copied, or anything.
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
------------------------------
Date: Tue, 28 Nov 89 14:51:19 CET
From: "Konrad Blum,Dept.Phys.,Univ.Oldenburg,FRG"
<013352%DOLUNI1.BITNET@CUNYVM.CUNY.EDU>
Subject: Converter Programm HPGL to .IMG for ST available ?
Does anyone know about a program which converts HPGL (plotter) files
to pixel oriented files with .IMG format?
Please e-mail directly to my bitnet.address
Yours
-KB
======================================================================
I Konrad Blum c/o: I
I <013352$DOLUNI1.BITNET> Renewable Energy Group I
I phone: +49/441/798 3212 Department of Physics I
I 3544 UNIVERSITY of OLDENBURG I
I fax: +49/441/798 4259 P.O.BOX 2503 I
I 3000 D-2900 OLDENBURG I
I telex: 25 655 unol d Fed. Rep. of Germany I
I I
**********************************************************************
* International Association of Solar Energy Education - IASEE *
* Editor of the Quaterly IASEE-Newsletter *
**********************************************************************
------------------------------
Date: 27 Nov 89 20:43:34 GMT
From: thelake!steve@UMN-CS.CS.UMN.EDU (Steve Yelvington)
Subject: File transferring...
In article <9806@saturn.ucsc.edu>,
dstr012@ucscg.UCSC.EDU (10003012) writes ...
>Hello,
> Does anyone out there know of or use a background uploading/downloading
>program that is either shareware or public domain. I get on the net and
>download ALOT of things and it takes incredible amounts of time with a
>1200 baud modem and background downloading would really be great. Thanks
>in advance for any help.
>
> Roman Baker
> dstr012@UCSCG.UCSC.EDU
A "crippleware" program called STALKER was distributed on this network
many months ago; it may be available at the archive sites. The demo
version was limited to uploading (from you to a remote computer). To get
downloading capabilities, you had to send money to the programmer.
It looked pretty good. However, the background operation was based on
GEM pseudomultitasking. This means that any non-AES operations will bring
the background task to a screeching halt. For example, I could upload to a
BBS quiet easily while running GEM First Word, but as soon as I fired up
MicroEMACS, a compiler, or even a command shell, the system halted because
the foreground task had issued a blocking GEMdos system call (typically
Bconin or Cconin). Well-written GEM programs are supposed to do most of
their work by calling the Event Manager, which allows the background
process to have a crack at the system as needed, but most of the software
I use is non-GEM.
STALKER is a desk accessory, with all the limitations that accrue thereto.
As I recall, the size of the file to be transferred was limited by a static
buffer. The reason for this is that a GEM DA doesn't own any file handles;
they belong to the foreground task, as far as the operating system knows.
When a foreground task terminates, all files are closed and handles are
released. This is death to the DA if it is writing periodically to an open
file. Most DAs deal with the problem by doing only a single disk write.
I think the more appropriate solution would be to maintain an internal
record of the file pointer, and to Fopen/Fseek/Fwrite/Ftell/Fclose each
time the DA's own data buffer gets full. (This does leave the door open to
a horrible mess if the user or another program touches the file or even
changes a disk, but that's life.)
I think Eidersoft has marketed a commercial background file-transfer
utility, but I have not seen it advertised in a long time.
I would like to see someone write a generic background file-transfer
utility with a well-documented interface that could receive instructions
from other programs using the GEM AES message-passing facility. Any
volunteers? I'd love to do it myself, but I'm sort of tied up with some
other stuff at the moment.
Of course, if Dave Beckemeyer releases RTX as he has hinted, the whole
issue could become moot -- a program could spin off a real background file
transfer process and not have to worry about living under the Event
Manager's thumb.
-- Steve Yelvington, up at the lake in Minnesota
... pwcs.StPaul.GOV!stag!thelake!steve (UUCP)
------------------------------
Date: 28 Nov 89 00:12:12 GMT
From: fox!portal!atari!kbad@apple.com (Ken Badertscher)
Subject: Rainbow TOS ROMs (AGAIN!)
ignac@electro.UUCP (Ignac Kolenko) writes:
| can you tell us with any great certainty if you will accept a trade from the
| 6 eprom set to the 2 rom set with no additional cost?????
I can't tell you with any certainty, but I can certainly offer my opinion.
It is my opinion that Atari will NOT accept trades. Why did you buy the
6 chip set in the first place if you don't feel you can use them?
| if we here at electrohome don't have to butcher our motherboard [...]
The modification to install 6 ROM chips in a machine currently using 2 ROMs
is in no way a butcher job. It is a simple, clean modification, which was
part of the original design of the machines when they went from 6 chips to 2.
It does, however, require some electronics and soldering experience.
| the 6 eproms make the atari feel like its a cheap clone of the real thing.
I can't believe what I'm reading here. EPROMs were made available due to
popular demand. Very few sets of EPROMs were sold: around 150, I'm told.
As soon as OTP's were available, _they_ were sold instead, and likewise
with masked ROMs.
If the "cheap clone" statement was intended to be a joke, it's a bad
joke. In case you can't tell, this is an extremely sensitive issue with
me personally, because I personally worked very hard to make the
Rainbow TOS ROMs available to developers and to the general public.
I am truly appreciative of all the Emails of thanks that I've gotten.
I also truly take complaints very seriously.
--
||| Ken Badertscher (ames!atari!kbad)
||| Atari R&D System Software Engine
/ | \ #include <disclaimer>
------------------------------
Date: 28 Nov 89 09:57:59 GMT
From: shlump.nac.dec.com!wldwst.enet.dec.com@decwrl.dec.com (Ron van Zuylen)
Subject: SOUND CDED RUNNING ON SPECTRE
In article <8911280804.AA19421@ucbvax.Berkeley.EDU>, MAXG@SUVM.BITNET writes:
>Well I've finally taken the plunge and started playing with sound on
>Spectre1.9. I'm using system 6.0.2, since this is what an informed
>source recommended I use on my MacSE. The problem I am having is as
>follows: When I get the control panel from the apple menu, I do not see
>the sound cdev in the left hand window (for that matter, I don't see the
>start-up device icon, either). I have the correct versions of the
>control panel and the sound cdev (because they are the same ones I'm
>using on my SE, and I have access to them on that machine's control
>panel). Does anyone have any ideas? I don't think this has anything to
>do with sound on the Spectre, because I haven't even gotten to hearing
>the actual sound yet...or--is it the case that Spectre doesn't actually
>support Apple's Sound cdev, and I need to get another?
>Well, as usual...thanks in advance for any replies...post here or email
>directly to me at: maxg@suvm (bitnet) or ggreenbe@rodan.acs.syr.edu
>(internet).
>---Gerry
Spectre (as of 2.3) does not support the new Sound Manager routines Apple added
in System Tools 6.0.2 and above. Yell at Dave Small. :-) The Sound Master
CDEV works, however, since it doesn't use the new Sound Manager.
The Sound CDEV (and the World CDEV, too) will not show up unless the system has
extended parameter RAM. It stores the settings in there. The Spectre has
neither extended nor standard "battery backed-up" parameter RAM. Only the Mac
Plus and up has extended PRAM. A hack, "Disk Param", will simulate the normal
PRAM by saving it as a disk file. The extended PRAM can be simulated with
another hack, XPRAM, which was originally written for 512KE owners. Eventually,
some nice Mac programmer will write one slick INIT just for Spectre owners (or
Mac owners with dead PRAM). :-)
Also, if you press ALTERNATE and the "+" key on the numeric keypad, the system
will think you are a Macintosh Plus (which, it assumes, must have extended
PRAM). NOTE: For some reason, it doesn't completely think you are a Plus if
you are running System Tools 6.0.4. It normally thinks you are a 512KE.
Ron S. van Zuylen + rvanzuylen%wldwst.enet@decwrl.dec.com
Digital Equipment Corporation + decwrl!wldwst.enet!rvanzuylen
Cupertino, California USA
------------------------------
End of INFO-ATARI16 Digest V89 Issue #714
*****************************************
