Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 91 Issue 319
Info-Atari16 Digest Thu, 6 Jun 91 Volume 91 : Issue 319
Today's Topics:
Atari TT
Autobooting Drive C
Black Cauldron Wanted!
Color monitor replacement?
FSM-GDOS...When? How?
GIF decompressor in GFA Basic 3.0 (not a viewer)
Hard-drive on a 520ST? (2 msgs)
Man w/ pipe (2 msgs)
More than 4 Meg ?? (2 msgs)
Neophyte question: what's Blitter?
Re: Man w/ pipe
XOR (Was RE: More than 4 Meg?)
Welcome to the Info-Atari16 Digest. The configuration for the automatic
cross-posting to/from Usenet is getting closer, but still getting thrashed
out. Please send notifications about broken digests or bogus messages
to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU.
Please send requests for un/subscription and other administrivia to
Info-Atari16-Request, *NOT* Info-Atari16. Requests that go to the list
instead of the moderators are likely to be lost or ignored.
If you want to unsubscribe, and you're receiving the digest indirectly
from someplace (usually a BITNET host) that redistributes it, please
contact the redistributor, not us.
----------------------------------------------------------------------
Date: 5 Jun 91 09:57:34 GMT
From: mcsun!hp4nl!star.cs.vu.nl!hvaalde@uunet.uu.net (Aalderen van Harold)
Subject: Atari TT
To: Info-Atari16@naucse.cse.nau.edu
apratt@atari.UUCP (Allan Pratt) writes:
>You can buy a 2MB ST RAM add-on card, for a total of 4MB of ST RAM. There
>may one day be an 8MB ST RAM add-on card, resulting in a total of 10MB
>of ST RAM.
>You can buy a 4MB TT RAM add-on card. It may be that, with some work, you
>can make this address 16MB of TT RAM. In future (now?) you can buy 16MB of
>TT RAM from Atari -- I'm just not sure.
Since where on the subject now. Is there a legal way to find out
the begin and end adresses of the ST-RAM and the same for TT_RAM
And for the ROM?
I want to write a routine that as some 32 bit number as input and
assuming that it is an address it determines if it is ROM, ST_RAM or TT_RAM
or just JUNK and if it lies in the system part of RAM or in the TPA part.
any info appreciated?
Harold van Aalderen (hvaalde@cs.vu.nl)
------------------------------
Date: 7 Jun 91 03:01:21 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!spool.mu.edu!agate!darkstar!ucscb.UCS
C.EDU!rome@arizona.edu (60380000)
Subject: Autobooting Drive C
To: Info-Atari16@naucse.cse.nau.edu
I am borrowing my friend's Mega 2 for the summer and he has an SHS205 hard
drive attatched. When I got it, it would boot all of the stuff in the
AUTO folder on the C partition (actually, that was the only thing that
it would boot, it would not read a floppy at bootup!) I seemed to have
messed something up and now it will not boot off the hard drive, I have to
boot off a floppy and with all of the utilities, it takes forever. Does
anyone know how I can fix the C partition to autoboot again???????
Thanks,
Roman Baker
------------------------------
Date: 6 Jun 91 15:14:39 GMT
From: aurs01!whitcomb@uunet.uu.net (Jonathan Whitcomb)
Subject: Black Cauldron Wanted!
To: Info-Atari16@naucse.cse.nau.edu
Does anyone have a copy of the game Black Cauldron that
they wish to unload, or know where I can still purchase
a copy? I've just started re-reading the Prydain
Chronicles by Lloyd Alexander, and thought it would be
fun to play the game after reading the book.
Thanks!
**********************************************************************
Jonathan Whitcomb UUCP: <whitcomb%aurgate@mcnc.org>
Alcatel Network Systems, Raleigh, NC Delphi: JBWHIT
------------------------------
Date: 6 Jun 91 17:28:35 GMT
From: noao!asuvax!ncar!elroy.jpl.nasa.gov!wciu!abode!scale@arizona.edu (Luis
Outumuro)
Subject: Color monitor replacement?
To: Info-Atari16@naucse.cse.nau.edu
Hi David,
$230 is a very fair price for a brand new monitor! By all
means, get the new monitor. Bye.............
Luis
------------------------------
Date: 6 Jun 91 20:03:36 GMT
From: tempest.Berkeley.EDU!kawakami@ucbvax.berkeley.edu (John Kawakami)
Subject: FSM-GDOS...When? How?
To: Info-Atari16@naucse.cse.nau.edu
In article <1991May31.191105.13736@lonex.radc.af.mil> longj@lonex.radc.af.mil
(Jeffrey K. Long) writes:
>Questions:
>1) When will it be relesed ?
According to a letter from Goldleaf, there is less than two weeks before
it is released. Seems that Goldlead is just itching to send it out ASAP
(after all, they have possibly the only FSM-ready program on the market,
thus the new GDOS is a selling point.)
>2) Who will handle distribution (Atari Directly, or through dealers, mail
> order, ...)?
Probably all channels. I would hope that they distribute it in addition
to the old GDOS (in software packages.)
>3) What will it cost, and will it include (as I have heard rumoured) drivers
> for most printers including the HP DeskJet (original version)?
Cost? Beats me. It's supposed to include a DJ driver, as well as an HP
Laserjet driver and Epson drivers. They'd be stupid to drop any drivers
in the package.
>4) Can I get it now by buying Goldeaf's Wordflair II?
No. They are going to charge cost plus shipping and handling when they
sell FSM.
>----------------------------------------------------------------------------
>Capt Jeff Long Rome Laboratories, Griffiss AFB, NY
>longj@lonex.radc.af.mil (preferred) Network Design Laboratory
>jlong@cassiopeia.radc.af.mil (315)330-7751 or (DSN)587-7751
John Kawakami kawakami@ocf.berkeley.edu
ucbvax!ocf.berkeley.edu!kawakami
------------------------------
Date: 6 Jun 91 23:31:06 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio
-state.edu!linac!uwm.edu!spool.mu.edu!cs.umn.edu!uc!noc.MR.NET!ns!ns!logajan@ar
izona.edu (John Logajan)
Subject: GIF decompressor in GFA Basic 3.0 (not a viewer)
To: Info-Atari16@naucse.cse.nau.edu
REM This GFA Basic 3.0 program unpacks the images in GIF files, creating RGB
REM color tables, and an uncompressed image array. Each byte in the image
REM array points into the intensity values in the RGB color tables. This means
REM the image can contain only 256 different colors, but those colors can be
REM selected from a palette of 16.7 million.
REM
REM *THIS IS NOT A COMPLETE PROGRAM* It does not display the GIF images.
REM I leave that up to you to figure out how to do. Good luck. By the way,
REM this is pretty slow. It does run much faster if compiled.
REM
REM Totally original code by John Logajan, June 6, 1991. I don't know what
REM legal status it has, as CompuServe owns GIF, and I've heard rumors that
REM the owners of the LZW compression routines aren't happy with CompuServe.
REM If it was up to me, this code would be released into the public domain.
REM
INPUT "Filename: ",a$
OPEN "I",#1,a$
DIM pcl|(260),prep&(4097),scar|(4097),temp|(4097)
pcp%=VARPTR(pcl|(0))
sig$=""
version$=""
FOR j&=1 TO 3
sig$=sig$+CHR$(INP(#1))
NEXT j&
FOR j&=1 TO 3
version$=version$+CHR$(INP(#1))
NEXT j&
IF sig$="GIF" ! Check for GIF signature.
swidth&=INP(#1)+INP(#1)*256 ! Some sort of screen size
sheight&=INP(#1)+INP(#1)*256 ! neither of which I use.
tmp|=INP(#1)
global!=BTST(tmp|,7) ! Check for Global Color Map.
gpixel&=(tmp| AND 7)+1 ! Global bits per pixel.
gcolres&=(SHR|(tmp|,4) AND 7)+1 ! Color range. I don't use.
gbackground&=INP(#1) ! Background color. I don't use.
tmp|=INP(#1)
IF global! ! We have a Global Color Map.
crange&=SHL(1,gpixel&) ! Color range.
pixel&=gpixel& ! Bits per pixel.
DIM r|(crange&),g|(crange&),b|(crange&) ! RGB color map reserved.
FOR j&=0 TO crange&-1 ! Go gety the map RGB values.
r|(j&)=INP(#1)
g|(j&)=INP(#1)
b|(j&)=INP(#1)
NEXT j&
ENDIF
REPEAT ! Main Image(s) Loop
sep|=INP(#1)
IF sep|=&H21 ! Throw away any Extension Blocks
tmp|=INP(#1)
DO
bc|=INP(#1)
EXIT IF bc|=0
FOR j&=1 TO bc|
tmp|=INP(#1)
NEXT j&
LOOP
sep|=INP(#1)
ENDIF
IF sep|=&H2C ! Look for Image Descriptor Start
offleft&=INP(#1)+INP(#1)*256 ! Some sort of offset, I don't use.
offtop&=INP(#1)+INP(#1)*256 ! I don't use.
width&=INP(#1)+INP(#1)*256 ! Image width (pixels)
height&=INP(#1)+INP(#1)*256 ! Image height (pixels)
imglen%=width&*height& ! Total pixels in the image.
DIM pic|(imglen%+256) ! Reserve image space + spare room.
pici%=0
tmp|=INP(#1)
uselocal!=BTST(tmp|,7) ! Look for Local Color Map
interlace!=BTST(tmp|,6) ! See if image is interlaced.
lpixel&=(tmp| AND 7)+1 ! Local bits per pixel.
pass|=0
hline&=0
vcol&=0
lstep&=8
IF uselocal! ! We have a Local Color Map
crange&=SHL(1,lpixel&) ! Color range
pixel&=lpixel& ! Bits per pixel
IF NOT global!
DIM r|(crange&),g|(crange&),b|(crange&) ! Reserve room for color map.
ENDIF
FOR j&=0 TO crange&-1 ! Go fill local color map.
r|(j&)=INP(#1)
g|(j&)=INP(#1)
b|(j&)=INP(#1)
NEXT j&
ENDIF
PRINT crange&;" colors."
PRINT width&;" * ";height&
REM
REM This is the LZW decompresser
REM
initcodesize&=INP(#1) ! How many bits in first code.
clearcode&=SHL(1,initcodesize&) ! Now we know the clear code.
eofcode&=clearcode&+1 ! Now we know the eof code.
firstfree&=clearcode&+2 ! Where to put first incoming code.
FOR j&=0 TO clearcode&-1 ! We put roots into string table.
REM Prep&() entries point to the previous character
prep&(j&)=5000 ! Are roots so we make them too big.
REM scar|() entries are the actual string value at that point
scar|(j&)=j&
NEXT j&
INC initcodesize&
cbp&=0
cpt&=0
lpt&=0
GOSUB codeclear ! Let's get started.
REPEAT ! Do a whole compressed image.
GOSUB getcode ! Get a code.
IF code&=clearcode& ! Always test it for clear code.
GOSUB codeclear
ELSE
IF code&<freecode& ! We have this code.
GOSUB codeout ! Expand it.
prep&(freecode&)=oldcode& ! And save it as next code,
scar|(freecode&)=pscar| ! appending current character.
ELSE ! We don't have this code.
prep&(freecode&)=oldcode& ! So, save it,
scar|(freecode&)=pscar| ! appending previous first character.
GOSUB codeout ! Expand it.
ENDIF
INC freecode& ! Get ready for next.
oldcode&=code& ! Remember last code.
IF freecode&>=maxcode& ! Look out for variable sized codes.
IF codesize&<12 ! Don't go over 12bit limit.
INC codesize& ! Adjust code size up one bit.
maxcode&=SHL(1,codesize&)
readmask&=maxcode&-1
ENDIF
ENDIF
ENDIF
UNTIL code&=eofcode& ! We're out'a here.
sep|=INP(#1)
ENDIF
UNTIL sep|=&H3B ! Look for GIF Terminator
REM
PRINT "Your code goes here."
REM
REM pic|() contains image, one byte per pixel -- pointing into RGB maps.
REM The image data in pic|() is left to right, top to bottom
REM i.e. The first 640 bytes of a 640 pixel wide image make up the first
REM horizontal line, the next 640 bytes make up the second line...
REM width& = number of horizontal pixels (bytes)
REM height& = number of vertical pixels (bytes)
REM r|() contains the red level values 0-255 intensities.
REM g|() contains the green level values 0-255 intensities.
REM b|() contains the blue level values 0-255 intensities.
REM crange& = the number of entries in each color map.
REM
REM Have fun.
REM
ELSE
PRINT "Not a GIF file."
ENDIF
END
PROCEDURE getcode
REM This routine extracts code bits out of a very long bit stream.
REM cpt&=current byte in the buffer block
REM cbp&=current start bit in the byte
REM codesize&=current code bit width
REM lpt&=last byte in the buffer block
sumb&=codesize&+cbp&
smo%=lpt&-cpt&
REM A 10 bit code can span 3 bytes, so there are many cases to handle.
IF sumb&<=8
IF smo%<1
GOSUB getblock
ENDIF
code&=SHR&(pcl|(cpt&),cbp&) AND readmask&
IF sumb&=8
INC cpt&
cbp&=0
ELSE
cbp&=sumb&
ENDIF
ELSE
IF sumb&<=16
IF smo%<2
GOSUB getblock
ENDIF
code&=SHR&(pcl|(cpt&),cbp&) OR SHL&(pcl|(cpt&+1),8-cbp&) AND readmask&
IF sumb&=16
ADD cpt&,2
cbp&=0
ELSE
INC cpt&
cbp&=sumb&-8
ENDIF
ELSE
IF smo%<3
GOSUB getblock
ENDIF
code&=SHR&(pcl|(cpt&),cbp&) OR SHL&(pcl|(cpt&+1),8-cbp&) OR
SHL&(pcl|(cpt&+2),16-cbp&) AND readmask&
REM
REM Just in case that line gets truncated in transit, here it is:
REM code&=SHR&(pcl|(cpt&),cbp&) OR SHL&(pcl|(cpt&+1),8-cbp&)
REM OR SHL&(pcl|(cpt&+2),16-cbp&) AND readmask&
REM
ADD cpt&,2
cbp&=sumb&-16
ENDIF
ENDIF
RETURN
PROCEDURE getblock
REM The image date is broken up in blocks less than 256 bytes long in the
REM GIF file. I get one of those blocks whenever I am running short.
smo2&=0
WHILE cpt&<>lpt& ! Move any as yet unused bytes from previous
pcl|(smo2&)=pcl|(cpt&) ! block up to front.
INC smo2&
INC cpt&
WEND
cpt&=0
bc|=INP(#1)
lpt&=bc|+smo%
IF bc|<>0 ! And then stick the new block on behind.
BGET #1,pcp%+smo%,bc|
ENDIF
RETURN
PROCEDURE codeclear
REM This clears the code table. It does this right away, and every 4096
REM codes sent thereafter -- and sometimes sooner.
freecode&=firstfree&
codesize&=initcodesize&
maxcode&=SHL(1,codesize&)
readmask&=maxcode&-1
REPEAT
GOSUB getcode
UNTIL code&<>clearcode&
GOSUB codeout ! We always send the first code out right
oldcode&=code& ! away after a code clear.
RETURN
PROCEDURE codeout
REM This routine expands the code into real image data.
oz&=-1
ooz&=code&
REPEAT ! I have to extract the string backwards
INC oz&
temp|(oz&)=scar|(ooz&)
ooz&=prep&(ooz&)
UNTIL ooz&=5000
pscar|=temp|(oz&)
IF interlace! ! A nitwit interlaced image. Bleech.
FOR ooz&=oz& TO 0 STEP -1 ! Take the backward string and put it into
IF vcol&=width& ! the picture image, forwards.
vcol&=0
hline&=hline&+lstep& ! Set up the crazy interlace cases.
IF hline&>=height&
INC pass|
IF pass|=1
lstep&=8
hline&=4
ENDIF
IF pass|=2
lstep&=4
hline&=2
ENDIF
IF pass|=3
lstep&=2
hline&=1
ENDIF
IF pass|=4
hline&=height&
ENDIF
ENDIF
pici%=hline&*width& ! I've figured out where it goes.
ENDIF
pic|(pici%)=g|(temp|(ooz&)) ! Now I finally put it there.
INC pici%
INC vcol&
NEXT ooz&
ELSE ! Ah, a seqential image.
FOR ooz&=oz& TO 0 STEP -1 ! Take the backward string and put it
pic|(pici%)=g|(temp|(ooz&)) ! into the picture image, forwards.
INC pici%
NEXT ooz&
ENDIF
RETURN
--
- John Logajan @ Network Systems; 7600 Boone Ave; Brooklyn Park, MN 55428
- logajan@ns.network.com, 612-424-4888, Fax 612-424-2853
------------------------------
Date: 6 Jun 91 16:47:15 GMT
From:
noao!asuvax!ncar!elroy.jpl.nasa.gov!sdd.hp.com!uakari.primate.wisc.edu!crdgw1!g
ecrdvm1!syspmzt@arizona.edu
Subject: Hard-drive on a 520ST?
To: Info-Atari16@naucse.cse.nau.edu
In article <1991Jun5.181758.4095@murdoch.acc.Virginia.EDU>,
lch3e@holmes.acc.Virginia.EDU (Lauren C. Howard) says:
>
>Can a hard-drive (spec. Megafile 30) be used with a stock 520ST?
>Will there be enough memory left to run WordPerfect? Timeworks DTP?
>
>Why are the Megafile 30's being sold off so cheap right now? I know
>they're discontinued; but is there anything wrong with them? Are
>they upgradeable?
>
I can't answer most of the questions, but having been in the market for
a hard drive recently, I can tell you that every dealer I've talked to
about the Megafile 30 has had the same response: "They're really slow.
Most of my customers can't deal with anything this slow."
Mind that they're dealers with non-Atari drives to sell, but it became
the expected response whenever I talked to one of them. I found a
49M 28ns drive from Carter Graphics for $414 that I'm waiting for now.
Atari's Megafile was $365 at most places that would touch them. Seemed
like a simple choice to me.
Phil Z
------------------------------
Date: 6 Jun 91 17:55:07 GMT
From: noao!asuvax!ncar!elroy.jpl.nasa.gov!wciu!abode!scale@arizona.edu (Luis
Outumuro)
Subject: Hard-drive on a 520ST?
To: Info-Atari16@naucse.cse.nau.edu
Hi Lauren,
Yes, a hard drive such as the Megafile 30 can be used with a
"stock" 520ST, although I doubt there would be enough memory left to run
either WordPerfect or Publisher ST. You could however run the likes of
WordWriter and Publishing Partner. Having a hard drive connected to a 512k ST
really restricts which programs you can use; this would be an excellent time to
upgrade your computer.
Megafiles are so cheap now, because hard drive prices are at an
all-time low; and this is industry wide (not just Atari). There is nothing
wrong with the Megafile 30's; low OEM prices of the mechanism and market
competition allow the price to be low. Yes, the Megafile 30's are upgradeable;
one of the most popular replacement mechanisms for the Megafile 30 is the
Mitsubishi MR535. The MR535 (when connected to a RLL controller, like the
Megafile 30 has) is a 65m, 25ms hard drive; it simply plugs and mounts in the
same place as the Megafile 30's Seagate ST238R mechanism, although you will
need different software to format and partition the drive with (such as Supra's
Hard Drive Utilities, Diamond Cache would be nice too). I hope this helps,
take care. Bye................
Luis
------------------------------
Date: 6 Jun 91 18:54:48 GMT
From: noao!ncar!gatech!prism!mailer.cc.fsu.edu!nu!boyd@arizona.edu (Mickey Boyd)
Subject: Man w/ pipe
To: Info-Atari16@naucse.cse.nau.edu
In article <1991Jun6.131017.12110@ira.uka.de>, S_DINGLER@iravcl.ira.uka.de (|S|
Florian Dingler) writes:
>Hi folks!
>
>I wonder if anyone knows who the man smoking a pipe is. You know, the one you
>find in the ATARI-ST charset with the codes 28-31 or so. Is he just a little
>joke or a special person or what ?
>Please write followups, no mail.
Bob, from the Church of the Subgenius. Consult your weirdest bookstore for
details.
--
---------------------------------+-------------------------------------
Mickey R. Boyd | "Kirk to Enterprise. All clear
FSU Computer Science | down here. Beam down
Technical Support Group | yeoman Rand and a six-pack . ."
email: boyd@fsucs.cs.fsu.edu |
---------------------------------+-------------------------------------
------------------------------
Date: 6 Jun 91 21:16:57 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!rpi!news-server.
csri.toronto.edu!utgpu!watserv1!roulston@arizona.edu (James Parker)
Subject: Man w/ pipe
To: Info-Atari16@naucse.cse.nau.edu
In article <1991Jun6.161545.14157@rice.edu> bemo@spacsun.rice.edu (Brian D.
Moore) writes:
>In article <1991Jun6.131017.12110@ira.uka.de>, S_DINGLER@iravcl.ira.uka.de (|S|
Florian Dingler) writes:
>|> Hi folks!
>|>
>|> I wonder if anyone knows who the man smoking a pipe is. You know, the one
you
>|> find in the ATARI-ST charset with the codes 28-31 or so. Is he just a little
>|> joke or a special person or what ?
>|> Please write followups, no mail.
>
> Hey buddy, that's Bob Dobbs, leader of the Church of the Sub-Genius.
>Slack off! Quit your job! Send your money to Bob!!
>
So, how do get a look at the Atari character set anyway?
Please send em the necessary slack.
thanx
james
------------------------------
Date: 7 Jun 91 00:42:15 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!pacbell.com!iggy.GW.Vitalink.COM!lll-
winken!taco!taco.cc!twmanino@arizona.edu (TONY W MANINO)
Subject: More than 4 Meg ??
To: Info-Atari16@naucse.cse.nau.edu
>>Nope. TOS 1.6 has a screwed up memory sizer that assumes that if two banks of
>>RAM exist then both banks are the same size. I don't know if this is a bug
>>in the true sense or malicious crippling but it is sad.
>>
>>BTW, a bank is two SIMMs since memory access is on a word basis.
>>
>> 512K = 2 x 256K SIMMs
>> 1Mb = 4 x 256K SIMMs
>> 2Mb = 2 x 1Mb SIMMs
>> 2.5Mb = 2 x 1Mb SIMMs + 2 x 256K SIMMs (Not with TOS 1.6)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>I heard this works on TOS 1.6 if you put the 256k SIMMs as the first bank
>and the 1M SIMMs as the second bank. But I could be wrong. If you're
>having trouble, though, it's trivial to try it the other way.
>> 4Mb = 4 x 1Mb SIMMs
There's a file at atari.archive that fixes the 2.5 meg problem... It's called
SIMMFIX.
You put it in your auto folder. It reprograms the MMU, then does a warmstart.
I get 2 bombs on the first boot attempt, but when the machine resets, it does
just fine. Any subsequent warmstarts just boot right up.
Be sure to read the instructions....
Hope this helps,
Tony
twmanino@eos.ncsu.edu
------------------------------
Date: 6 Jun 91 15:16:54 GMT
From: mcsun!ukc!mucs!els!camm@uunet.uu.net (Ian Camm)
Subject: More than 4 Meg ??
To: Info-Atari16@naucse.cse.nau.edu
In article <1991Jun5.222630.24777@jato.jpl.nasa.gov> vsnyder@jato.Jpl.Nasa.Gov
(Van Snyder) writes:
>In article <3153@odin.cs.hw.ac.uk> neil@cs.hw.ac.uk (Neil Forsyth) writes:
>>In article <1991Jun4.112631.10649@cs.nott.ac.uk> dpg@cs.nott.ac.uk
>>(Dave Gymer) writes:
>>> ... I believe, that the MMU in the STe can
>>>only handle .25 and 1 meg SIPPS/SIMMS, and these are arranged in two banks,
>>>which must contain the same amount (hence, memory configurations can only
>>>be .5 meg, 1 meg, 2 meg, 2.5 meg, and 4 meg). I too have a four meg STe.
>> ~~~~~~~
>>
>>Nope. TOS 1.6 has a screwed up memory sizer that assumes that if two banks of
>>RAM exist then both banks are the same size. I don't know if this is a bug
>>in the true sense or malicious crippling but it is sad.
>>
>>BTW, a bank is two SIMMs since memory access is on a word basis.
>>
>> 512K = 2 x 256K SIMMs
>> 1Mb = 4 x 256K SIMMs
>> 2Mb = 2 x 1Mb SIMMs
>> 2.5Mb = 2 x 1Mb SIMMs + 2 x 256K SIMMs (Not with TOS 1.6)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>I heard this works on TOS 1.6 if you put the 256k SIMMs as the first bank
>and the 1M SIMMs as the second bank. But I could be wrong. If you're
>having trouble, though, it's trivial to try it the other way.
>> 4Mb = 4 x 1Mb SIMMs
Well 2.5Mb does work on my 520STE with TOS 1.6, but it does think there
are 4Mb there. I have not had any problems yet but I have not (knowingly)
tried to use all of the memory thus far. I have the feeling that when I
do I will commit mass bit murder :-) by trying to throw them into spaces that
aren't there. I will try changing the boards round and let you know what
happens.
n
e
w
s
f
o
d
d
e
r
Cheers,
Ian
--
Ian Camm | JANET: camm@uk.ac.man.ee.els
Dept. of Electrical Engineering | ARPA: camm@els.ee.man.ac.uk
University of Manchester, England | UUCP: ...!!ukc!man.ee.els!camm
Disclaimer: If you think I need one make it up yourself.
------------------------------
Date: 6 Jun 91 22:40:23 GMT
From:
noao!ncar!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!lll-winken!aunro!ersys
!mforget@arizona.edu (Michel Forget)
Subject: Neophyte question: what's Blitter?
To: Info-Atari16@naucse.cse.nau.edu
darkstar@milton.u.washington.edu (Alden Hackmann) writes:
> We are the very new (3 days) owners of an Atari 1040 STe.
> There is a toggle on the options menu for something called Blitter.
> The little manual has no reference to it at all. Can anyone enlighten
> us as to the meaning of this option?
>
If you can select the "Blitter" option, do so. It is a special graphic
chip inside the machine that allows it to do Hardware Scrolling. It
makes for faster, smoother scrolling. I'm not sure about the other
capabilities. It is better than the standard, though, so use it if you
can.
<< ---------------------------------- >>
<< ersys!mforget@nro.cs.athabascau.ca >>
<< mforget@ersys.edmonton.ab.ca >>
<< Michel Forget >>
<< ---------------------------------- >>
------------------------------
Date: 6 Jun 91 20:39:54 GMT
From:
noao!asuvax!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!crdgw1!gecrdvm1
!syspmzt@arizona.edu
Subject: Re: Man w/ pipe
To: Info-Atari16@naucse.cse.nau.edu
In article <A1663047366@thelake.mn.org>, steve@thelake.mn.org (Steve Yelvington)
says:
>
>[In article <1991Jun6.131017.12110@ira.uka.de>,
> S_DINGLER@iravcl.ira.uka.de (|S| Florian Dingler) writes ... ]
>
>> I wonder if anyone knows who the man smoking a pipe is. You know, the one
>you
>> find in the ATARI-ST charset with the codes 28-31 or so. Is he just a little
>> joke or a special person or what ?
>> Please write followups, no mail.
>
>Bob is indeed a special person, being the revered icon of the Church of the
>Sub-Genius.
>
Well, now I know why Bob is seen on the dialog box of the ram disk I use.
I'd thought that the programmer was really cool to spend the time drawing
Bob. Now I know that the real cool person is or was hidden inside Atari
while they were developing the machine.
For all the deficiencies of the operating system, at least it offers
slack to all who seek.
Phil Z
------------------------------
Date: 6 Jun 91 18:56:50 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!uakari.primate.wisc.edu!crdgw1!gecrdvm1
!syspmzt@arizona.edu
Subject: XOR (Was RE: More than 4 Meg?)
To: Info-Atari16@naucse.cse.nau.edu
I can't reply to Ralph Berg, who asked about programming for the Cazio CZ1
with XOR:
XOR is a generic patch editor that runs in Dr. T's KCS Multi-Programming
Environment (MPE). It can also be run as a standalone program. As I
understand it, XOR uses modules that describes the programming requirements
for a given synth, and then uses a generalized interface to allow that
programming. Feedback from the synth category was very favorable to XOR
over other available packages. I like the idea of going to XOR since it s
supports a lot of synths, some of which are not exactly popular models. .
If you're not familiar with Dr. T's, they write a lot of midi software that
may not always have the greatest flexibility right off the bat, but are well
supported in upgrades, and are reasonably priced. I've stayed with the KCS
through 4 upgrades now, and with Tiger and Level II, have an extremely
powerful sequencer environment that supports the functioning of many external
programs; last night I figured how to initiate other GEM programs from
within the KCS so that I don't have to reload my sequencer configuration
just to get to my all-important Daleks game...
Phil Z
------------------------------
End of Info-Atari16 Digest
******************************
