Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 89 Issue 521
Via: UK.AC.EARN-RELAY; 16 OCT 89 11:45:47 GMT
Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 1761; Sun, 15
Oct 89 05:28:38 BS
Received: from CEARN.cern.ch by UKACRL.BITNET (Mailer X1.25) with BSMTP id
0454; Sun, 15 Oct 89 05:28:36 B
Received: by CEARN (Mailer R2.03B) id 8655; Sun, 15 Oct 89 05:28:30 GVA
Date: Sat, 14 Oct 89 15:00:10 MDT
Reply-To: INFO-ATARI16@MIL.ARMY.WSMR-SIMTEL20
Sender: INFO-ATARI16 Discussion <INFO-A16@EARN.DEARN>
Comments: Warning -- original Sender: tag was INFO-A16@MARIST
From: INFO-ATARI16-REQUEST@MIL.ARMY.WSMR-SIMTEL20
Subject: INFO-ATARI16 Digest V89 #521
Comments: To: INFO-ATARI16@WSMR-SIMTEL20.ARMY.MIL
INFO-ATARI16 Digest Sat, 14 Oct 89 Volume 89 : Issue 521
Today's Topics:
1040 ST for sale
520STFM FOR SALE (w/many xtras)
Event multi
Laser C and TOS 1.4
Laser C bugs
TOS 1.4, memory chips, T16...and the Mega2 STs
Wanted: Info on DEGAS picture compression
----------------------------------------------------------------------
Date: 13 Oct 89 05:28:56 GMT
From: att!drutx!druks!jamesc@ucbvax.Berkeley.EDU (CochraneJT)
Subject: 1040 ST for sale
I have a 1040 ST that I no longer need since I'm now
using a Mega 2. It's in good condition, runs fine
and has been very reliable. It includes the standard
double sided drive and 1 meg memory, but no monitor.
I would like $400 for it.
If you are interested or have questions about it, I can
be reached at home (most) weekday nights and on weekends at
303-449-3315
or, if you prefer, you can send me e-mail.
Jim Cochrane
jamesc@druks.ATT.COM
att!druks!jamesc
------------------------------
Date: 14 Oct 89 20:21:58 GMT
From:
gem.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!geoffs@tu
t.cis.ohio-state.edu (Geoffrey Sauerborn )
Subject: 520STFM FOR SALE (w/many xtras)
FOR SALE: Color Atari 520STFM SYSTEM w/RAM board upgrade.
(also w/PC DITTO and 5 1/4" floppy!)
(software and over 50 disks!)
$600 plus shipping.
Atari 520STFM system includes:.
Color monitor (SC1224).
EZRAM II board - 1 to 2.5 meg RAM upgrade.
Late model (only 2 years old)-(Rev.H) includes Television RF output.
External SS 400K SF354 3 1/2" floppy disk drive.
*NEW External DS/DD 360K I.B. DRIVE 5 1/4" floppy disk drive.*
TOS in ROM, Atari Basic, DR Logo., and of course GEM in ROM & mouse.
Lots of software
Utilities:
*PC DITTO*
PRINTMASTER PLUS
HIPPO WORD
ST LEDGER
Original Atari Development System Documentation & Utilities.
(plus C Compiler updated to ver 4.14 1986).
GAMES
FLIGHT SIMULATOR II (Plus east coast Scenery Disk 7).
HARRIER STRIKE MISSION (needs $5 disk replacement).
I will through in:
OVER 50 disks!!! PD or Shareware software. Archived and indexed.
includes:
UNITERM(using now),MICROEMACS 3.91/4,Compilers,Drawing...more.
HACK,LARN,RISK,MONOWARE,WHEEL OF FORTUNE,... too many to name.
3 Flip File dust cover 3.5 disk storage containers.
16 256K DRAM chips (enough for 1meg upgrade).
[ Some of these chips are flakey so they are not
included with the RAM board. I don't have a
chip tester to pick out the bad ones. Maybe it
can be done in software? ]
All items shipped in original boxes with manuals.
--
---> geoffs@brl.arpa -or- geoffs@smoke.brl.mil
--
------------------------------
Date: 14 Oct 89 09:10:54 GMT
From: agate!stew.ssl.berkeley.edu!ericco@ucbvax.Berkeley.EDU (Eric C. Olson)
Subject: Event multi
Once again I'm trying to make GEM AES do something useful. Its
now quite late, and the situation looks grim ...
Is it possible to check the state of EITHER mouse button using
event_multi? Or any other (documented) routine?
I have found that specifying 0x3 for the bstate parameter and
0x3 for the bmask parameter only matchs button chords. How do
I tell event_multi to wait for a left OR a right mouse click
(or both)?
Thanks in advance,
Eric
Eric
ericco@ssl.berkeley.edu
------------------------------
Date: 14 Oct 89 02:51:14 GMT
From:
gem.mps.ohio-state.edu!ginosko!shadooby!mailrus!jarvis.csri.toronto.edu!utgpu!w
atmath!julian!uwovax!7103_300@tut.cis.ohio-state.edu
Subject: Laser C and TOS 1.4
In article <8028@microsoft.UUCP>, w-darekm@microsoft.UUCP (Darek Mihocka)
writes:
> [ some very accurate comments on Laser ]
> ... I just
> stick to assembler for now while somebody writes a decent C compiler for
> the ST.
I agree with you on Laser; it had promise, but the buggy code generation,
incomplete library, and weird disk cache eventually caused me to give
up on it. Fortunately, there is an alternative; the GNU C Compiler. It's
a huge memory pig (you really need 2 megabytes to run it) but it produces
very good code, is ANSI compatible, and now comes with an (almost) ANSI
and Unix compatible library. And the price is right... it's free! (Source
is available too, and it's being actively supported by the Free Software
Foundation). The current version is 1.36, available from dsrgsun.ces.cwru.edu
and (I think) terminator.
--
Eric Smith
ersmith@uwovax.uwo.ca
ersmith@uwovax.bitnet
------------------------------
Date: 14 Oct 89 08:43:52 GMT
From: ubc-cs!grads.cs.ubc.ca!horsch@beaver.cs.washington.edu (Michael Horsch)
Subject: Laser C bugs
In article <8044@microsoft.UUCP> w-darekm@microsoft.UUCP (Darek Mihocka) writes:
[some gripes about Laser C... The ones I am addressing are not
edited out (how's that for being contrapositive!)]
> The C code generation has some problems when you get
>pointers to structures containing pointers, etc.
I have never had this one, and I've been messing
around a lot with objects, and structures which
contain pointers to objects, and linked lists of
trees whose nodes point to objects, and...
> What also irritates
>me is that if you have a string constant and you forget to put in the
>closing quotation marks, it crashes.
Not this either. I always forget to close qoutes. Sometimes
I forget the difference between " and '. I only get
compiler errors.
> All of these bugs have been present
>since Megamax C, I keep reporting them, and they keep ignoring them or
>telling me they're fixed. That's pissing me off to no end, because otherwise
>I like the package a lot.
Keep reporting them. I would too, if I found any. But mostly
I find my own bugs. No implication implied.
>
>The disk cache tends to mess up when you are low on RAM and compiling a
>large program (i.e. more than one module or more than a "hello world"
>skeleton).
I assume the parenthetical remark to be slightly sarcastic, but
your argument about low RAM behaviour makes sense to me (I
have a Mega2, so this is never a problem). I agree
with an earlier posting in which you suggested that
the cache be optional.
>Sure the cache is great if you're compiling off floppy, but you're not going
>to develop a large project on floppy.
Why not? The disk cache and RAM resident tools make this
completely reasonable. A little painful at the start of
a programming session (and after unrecoverable errors),
for sure, but certainly not completely unthinkable.
Especially for those (i.e. me) who (perhaps) misguidedly
purchased a machine with more RAM instead of a hard disk.
I am not a real C programmer, that is, I don't spend months
working on real projects (in fact, I'm a Prolog hacker
`by trade' :-) and my Mega2 is somewhat ignobly
reduced to a real slow terminal for most of its use)
so I consider one-floppy development adequate for my
medium sized hacks ---but only with the cache, etc.
>
>- Darek
Mike ("By trade?" --Well, it beats working for a living!)
--
Michael C. Horsch Disclaimer: I'm not thinking for anyone else but
horsch@cs.ubc.ca me; I'm having enough trouble as it is!
Dept. of Computer Science
University of British Columbia
--
If you don't waste time with your friends, you're just wasting your time.
--
------------------------------
Date: 14 OCT 89 11:32:06 CST
From: Z4648252 <Z4648252%SFAUSTIN.BITNET@ricevm1.rice.edu>
Subject: TOS 1.4, memory chips, T16...and the Mega2 STs
Can anyone shed some light preparing a Mega2 ST that has six ROM
sockets for use with the T16 and upgrading the Mega2's memory to four meg?
I've been reading conflicting data about what brand and speed memory
chips to use if one wants to use the T16. I've also been reading that
the T16 is happier if used with fast ROM, that is, copying the original
TOS 1.4 EPROM into faster EPROM chips.
Also, should the older 'Atari' blitter be replaced with the newer?
Incidentally, the 74LS373 chips have been replaced. I had problems
with Spectre until they were.
SIGH...this is a terribly worded letter. Basically, I'm only
asking:
1. What memory chips should be used for upgrading the ST2 to a ST4
if used with the T16?
2. Should the chipped TOS 1.4 be transferred to fast EPROMS to gain
maximum results from the T16?
3. Should the Atari blitter be replaced with the newer?
4. Yes, the 74LS373 chips have been replaced.
Larry Rymal: |East Texas Atari 68NNNers| <Z4648252@SFAUSTIN.BITNET>
------------------------------
Date: 14 Oct 89 20:00:49 GMT
From: pasteur!cory.Berkeley.EDU!jlemon@ucbvax.Berkeley.EDU (Jonathan Lemon)
Subject: Wanted: Info on DEGAS picture compression
In article <23086@cup.portal.com> Bob_BobR_Retelle@cup.portal.com writes:
>Wayne Schellekens asks:
>
>>Does anyone have any information as to how DEGAS compresses its
>>picture files?
>
>His file "ST Picture Formats" may be available on the ST archives, or I know
>it's available on CompuServe.. (since I uploaded it there)
>
Also right here.
ST Picture Formats
------------------
Compiled by:
Dave Baggett
(arpanet: dmb@TIS.COM)
(Please report errors or additions)
CONTRIBUTORS
Phil Blanchfield David Brooks Neil Forsyth
Ken MacLeod Darek Mihocka George Seto
Joe Smith Greg Wageman Gerry Wheeler
Introductory information
------------------------
word = 2 bytes
long = 4 bytes
palette = Hardware color palette, stored as 16 words. First word is
color register zero (background), last word is color register
15. Each word has the form:
Bit: (MSB) 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 (LSB)
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0 0 0 0 0 R2 R1 R0 0 G2 G1 G0 0 B2 B1 B0
R2 = MSB of red intensity
R0 = LSB of red intensity
G2 = MSB of green intensity
G0 = LSB of green intensity
B2 = MSB of blue intensity
B0 = LSB of blue intensity
Intensity ranges from 0 (color not present) to 7 (highest
intensity).
Example: ? red = 7, green = 3, blue = 5 ? -> 0735 (hex)
Caveat: It is wise to mask off the upper four bits of each
palette entry, since a few programs store special
information there (most notably Art Studio).
The Formats
-----------
<NEOChrome>
1 long resolution (0 = low res, 1 = medium res, 2 = high res)
16 words palette
12 bytes filename (" . ")
1 byte Left color animation limit (starting color number)
1 byte Right color animation limit (ending color number)
1 byte color rotation speed
1 byte color rotation direction
1 word color rotation duration (number of iterations)
18 longs reserved for expansion
16000 words picture data (screen memory)
-----------
32128 bytes total
<NEOChrome Animation>
NOTE: To get this feature on versions 0.9 and later select the Grabber
icon and click the right mouse button in the eye of the second R in
the word GRABBER.
1 long magic number BABEEBEA (hex) (seems to be ignored)
1 word width of sprite in bytes (always divisible by 8)
1 word height of sprite in scan lines
1 word size of sprite in bytes + 10 (!)
1 word x coordinate of sprite (must be divisible by 16) - 1
1 word y coordinate of sprite - 1
1 word number of frames
1 word animation speed (larger means slower)
1 long reserved; should be zero
--------
44 bytes total for header
? words sprite image data (words of screen memory) for each sprite,
in order
<DEGAS>
1 word resolution (0 = low res, 1 = medium res, 2 = high res)
Other bits may be used in the future; use a simple bit
test rather than checking for specific word values.
16 words palette
16000 words picture data (screen memory)
-----------
32034 bytes total
<DEGAS Elite (Uncompressed)>
1 word resolution (0 = low res, 1 = medium res, 2 = high res)
Other bits may be used in the future; use a simple bit
test rather than checking for specific word values.
16 words palette
16000 words picture data (screen memory)
4 words left color animtion limit table (starting color numbers)
4 words right color animation limit table (ending color numbers)
4 words animation channel direction flag (0 = left, 1 = off, 2 = right)
4 words animation channel delay in 1/60's of a second. [0 - 128]
-----------
32066 bytes total
<DEGAS Elite (Compressed)>
1 word resolution (same as Degas, but high order bit is set;
i.e., hex 8000 = low res, hex 8001 = medium res,
hex 8002 = high res). Other bits may be used in the
future; use a simple bit test rather than checking
for specific word values.
16 words palette
< 32000 bytes control bytes
4 words left color animtion limit table (starting color numbers)
4 words right color animation limit table (ending color numbers)
4 words animation channel direction flag (0 = left, 1 = off, 2 = right)
4 words animation channel delay in 1/60's of a second. [0 - 128]
-----------
< 32066 bytes total
Control byte meanings:
For a given control byte, x:
0 <= x <= 127 Use the next x + 1 bytes literally (no repetition)
-127 <= x <= -1 Use the next byte -x + 1 times
-128 No operation (ignore)
Compression Scheme:
Each scan line is compressed separately; i.e., all data for a given
scan line appears before any data for the next scan line. The scan lines
are specified from top to bottom (i.e., 0 is first). For each scan line,
all the data for a given bit plane appears before any data for the next
higher order bit plane.
To clarify: The first data in the file will be the data for the lowest
order bit plane of scan line zero, followed by the data for the next higher
order bit plane of scan line zero, etc., until all bit planes have been
specified for scan line zero. The next data in the file will be the data
for the lowest order bit plane of scan line one, followed by the data for
the next higher order bit plane of scan line one, etc., until all bit planes
have been specified for all scan lines.
<C.O.L.R. Object Editor Mural>
16000 words picture data (screen memory)
(palettes are stored in separate files)
-----------
32000 bytes total
<Tiny>
1 byte resolution (same as NEO, but +3 indicates rotation
information also follows)
If resolution > 2 ?
1 byte left and right color animation limits. High 4 bits
hold left (start) limit; low 4 bits hold right (end)
limit
1 byte direction and speed of color animation (negative value
indicates left, positive indicates right, absolute value
is delay in 1/60's of a second.
1 word color rotation duration (number of iterations)
?
1 word number of control bytes
1 word number of data bytes
16 words palette
3-10667 bytes control bytes
2-32000 bytes data bytes
-------------
42-32044 bytes total
Control byte meanings:
For a given control byte, x:
x < 0 Absolute value specifies the number of unique words to
take from the data section (from 1 to 127)
x = 0 1 long is taken from the control section which specifies
the number of times to repeat the next data word (from
128 to 32767)
x = 1 1 word is taken from the control section which specifies
the number of unique words to be taken from the data
section (from 128 - 32767)
x > 1 Specifies the number of times to repeat the next word
taken from the data section (from 2 to 127)
<Spectrum 512 (Uncompressed)>
80 words first scan line of picture (unused) -- should be zeroes
15920 words picture data (screen memory) for scan lines 1 through 199
9552 words 3 palettes for each scan line (the top scan line is
not included because Spectrum 512 can't display it)
-----------
51104 bytes total
<Spectrum 512 (Compressed)>
1 word 5350 (hex) ("SP")
1 word 0 (reserved for future use)
1 long length of data bit map
1 long length of color bit map
<= 32092 bytes compressed data bit map
<= 17910 bytes compressed color bit map
--------------
< 50014 bytes total
Data compression:
Compression is via a modified run length encoding (RLE) scheme. The
data map is stored as a sequence of records. Each record consists of a
header byte followed by one or more data bytes. The meaning of the header
byte is as follows:
For a given header byte, x:
0 <= x < 127 Use the next x + 1 bytes literally (no repetition)
-128 <= x < 0 Use the next byte -x + 2 times
The data appears in the following order:
1. Picture data, bit plane 0, scan lines 1 - 199
2. Picture data, bit plane 1, scan lines 1 - 199
3. Picture data, bit plane 2, scan lines 1 - 199
4. Picture data, bit plane 3, scan lines 1 - 199
Decompression of data ends when 31840 data bytes have been used.
Color map compression:
Each 16-word palette is compressed separately. There are three
palettes for each scan line (597 total). The color map is stored as a
sequence of records. Each record starts with a 1-word bit vector which
specifies which of the 16 palette entries are included in the data
following the bit vector (1 = included, 0 = not included; i.e., stays
the same). The least significant bit of the bit vector refers to
palette entry zero, while the most significant bit refers to palette
entry 15. Bit 15 must be zero, since Spectrum 512 does not use palette
entry 15. Bit 0 should also be zero, since Spectrum 512 always makes the
background color black.
The words specifying the values for the palette entries indicated in
the bit vector follow the bit vector itself, in order (0 - 15).
<Animatic Film>
1 word number of frames
16 words palette
1 word speed (0 - 99; higher value is faster)
1 word direction (0 = forwards, 1 = backwards)
1 word end action (what to do after the last frame)
0 = pause, then repeat from beginning
1 = immediately repeat from beginning
2 = reverse
1 word width of film in pixels
1 word height of film in pixels
1 word version number (major)
1 word version number (minor)
1 long magic number 27182818 (hex)
3 longs reserved (should be all zeros)
--------
32 words total for header
? words image data (words of screen memory) for each frame, in order
<MacPaint>
header ?
1 long version number (if zero, entire header is ignored)
38 * 2 longs pattern data (anyone know how to use this?)
51 longs reserved
?
< 51200 bytes compressed bitmap data
-------------
< 51716 bytes total
Bitmap compression:
The bitmap data is for a 576 pixel by 720 pixel image. The data is
stored as a sequence of records. Each record consists of a control
byte followed by one or more data bytes. The meaning of the control
byte is as follows:
For a given control byte, x:
0 < x < 127 Use the next x + 1 bytes literally (no repetition)
-128 <= x <= 0 Use the next byte -x + 1 times
There are 72 bytes per scan line. Each bit represents one pixel; 0 = white,
1 = black.
Version of Fri Sep 2 01:31:21 EDT 1988
---------------------------- >8 -------------------------------------
--
Jonathan ...ucbvax!cory!jlemon or jlemon@cory.Berkeley.EDU
------------------------------
End of INFO-ATARI16 Digest V89 Issue #521
*****************************************
