page@ulowell.cs.ulowell.edu (Bob Page) (12/22/87)
Note: FastMemFirst is the same as SlowMemLast; it was recently renamed. ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.edu ulowell!page "I've never liked reality all that much, but I haven't found a better solution." --Dave Haynie, Commodore-Amiga
dave@dms3b1.UUCP (Dave Hanna) (07/04/88)
In article <268@jackson.UUCP>, egranthm@jackson.UUCP (Ewan Grantham) writes: > I have seen this suggestion to turn on FastMemFirst in two places today, > but can't find such a utility anywhere on my 1.2 disks. FastMemFirst is in the System drawer on the _A2000/A500_ version of the 1.2 Workbench disk. It is not on the 1.2 Disk supplied with the Enhancer package. > Ewan Grantham (601) 354-6454 ext.358 -- Dave Hanna, Daltech MicroSystems | "Do or do not -- There is no try" P.O. Box 584, Bedford, TX 76095 | - Yoda (214) 358-4534 (817) 540-1524 | UUCP: ...!killer!gtmvax!dave |
mikb@stcns3.stc.oz (Mike Benson) (07/18/88)
In article <124@dms3b1.UUCP> dave@dms3b1.UUCP (Dave Hanna) writes: >In article <268@jackson.UUCP>, egranthm@jackson.UUCP (Ewan Grantham) writes: >> I have seen this suggestion to turn on FastMemFirst in two places today, >> but can't find such a utility anywhere on my 1.2 disks. > >FastMemFirst is in the System drawer on the _A2000/A500_ version >of the 1.2 Workbench disk. It is not on the 1.2 Disk supplied >with the Enhancer package. Pardon? I just looked at my Workbench disk (C= P/N 380724-07) that came with my (very early - 512K motherboard) A2000. The only tool that refers to fastmem is "NoFastMem". Anyone possessed of wisdom on this issue care to comment? > >> Ewan Grantham (601) 354-6454 ext.358 > > >-- >Dave Hanna, Daltech MicroSystems Any clod can have the facts, but having opinions is an art. +----------------------------------+------------------------------------------+ | Mike Benson | ACS: mikb@stcns3.stc.OZ.AU | | Alcatel-STC Pty Ltd | ARPA: mikb%stcns3.stc.OZ.AU@uunet.UU.NET | | 11th Floor, 5 Blue St | UUCP: {enea,hplabs,mcvax,uunet,ukc}!\ | | North Sydney NSW 2060 AUSTRALIA | munnari!stcns3.stc.OZ.AU!mikb | +----------------------------------+------------------------------------------+
daveh@cbmvax.UUCP (Dave Haynie) (07/20/88)
in article <624@stcns3.stc.oz>, mikb@stcns3.stc.oz (Mike Benson) says: > Pardon? I just looked at my Workbench disk (C= P/N 380724-07) that came with > my (very early - 512K motherboard) A2000. The only tool that refers to > fastmem is "NoFastMem". Anyone possessed of wisdom on this issue care to > comment? It was originally called "SlowMemLast". Then someone decided that "SlowMem" sounded bad, so they renamed it "FastMemFirst". In any case, what it does is make the $C00000 memory the last "FAST" tagged memory list to be used by the OS. Which means, if you have other FAST memory, your system will go faster, since that other FAST memory isn't subject to custom chip contention. > | Mike Benson | ACS: mikb@stcns3.stc.OZ.AU | -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
kim@amdahl.uts.amdahl.com (Kim DeVaughn) (07/21/88)
In article <624@stcns3.stc.oz>, mikb@stcns3.stc.oz (Mike Benson) writes: > In article <124@dms3b1.UUCP> dave@dms3b1.UUCP (Dave Hanna) writes: > >In article <268@jackson.UUCP>, egranthm@jackson.UUCP (Ewan Grantham) writes: > >> I have seen this suggestion to turn on FastMemFirst in two places today, > >> but can't find such a utility anywhere on my 1.2 disks. > > > >FastMemFirst is in the System drawer on the _A2000/A500_ version > >of the 1.2 Workbench disk. It is not on the 1.2 Disk supplied > >with the Enhancer package. > > Pardon? I just looked at my Workbench disk (C= P/N 380724-07) that came with > my (very early - 512K motherboard) A2000. The only tool that refers to > fastmem is "NoFastMem". Anyone possessed of wisdom on this issue care to > comment? FastMemFirst was originally named SlowMemLast. Try looking for that instead. I suppose it was a Marketing decision to change the name, and thus cause the ensuing confusion. Probably the same person/committee/etc. that was responsible for the Left-Amiga to Chicken-head fiasco ... /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
armhold@topaz.rutgers.edu (George Armhold) (05/24/89)
[Sorry if this has been mentioned before] Is the FastMemFirst program needed in my startup-sequence if I have an A1000 w/ only 512k? As I understand it, FastMemFirst just re-arranges any memory expansion (which I don't have.) A related question- the manual that came w/ the Enhancer 1.3 package says (on page 1-6): "...the Amiga defaults to using $C00000 RAM, FAST RAM, then CHIP RAM." What exactly is CHIP RAM? Thanks, -George
Yuklung_Morris_Ng@cup.portal.com (05/26/89)
Hey, you must be new in Amiga community. How do you like your A1000? Chip ram is just like the low memory on IBM, although it has more function. It serves as the video ram, memory for sound, buffering the devices, and e everything has to access the custom chips. (That's why it's called chip ram.) No, you don't need the FastMemFirst if you only have 512K, same as for those who have Fatter Agnus and 1 meg internal memory. There should be no problem to use it unnecessarily, just a waste of time and disk access time on your s startup-sequence. Be the Power of Amiga Bless you all! - Morris
stan@teroach.phx.mcd.mot.com (Stan Fisher) (08/01/89)
Recently I believe I read on the net that:
When using the Super Agnes chip, therefore elimating the C00000 RAM,
it is no longer necessary to run fastmemfirst in the startup-sequence, in
order to conserve Chip RAM. Was I dreaming this? Was it the Super Agnes
alone that changed this? or was it the use of SetCPU 1.5 too? Seems to me
irregardless of Super/old Agnes, a program requesting "either type of RAM"
could be given chip, when fast is available. Don't I still want to run
fastmemfirst? And does Mergemem really merge 16bit and 32bit memory pools
into contiguous space?
System = A2000 Rev. 4.x
A2620
ProRAM w/2Meg
SuperAgnus 1Meg Chip
1.3 Rom
Also (since I mentioned SetCPU) does Dave Haynie's .profile on cbmvax
do a 'mail > /dev/null' B^)
Stan Fisher - stan@teroach.phx.mcd.mot.com - asuvax!mcdphx!teroach!stan
Motorola Microcomputer Division, Tempe, Arizona - (602) 438-3228lphillips@lpami.wimsey.bc.ca (Larry Phillips) (08/01/89)
In <477@tardis.Tymnet.COM>, jms@tardis.Tymnet.COM (Joe Smith) writes:y >In article <11353@mcdphx.phx.mcd.mot.com> stan@teroach.phx.mcd.mot.com (Stan Fisher) writes: >> When using the Super Agnes chip, therefore elimating the C00000 RAM, >>it is no longer necessary to run fastmemfirst in the startup-sequence, in >>order to conserve Chip RAM. Was I dreaming this? Was it the Super Agnes > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^^^^^^^^ -- This assumption is false. No it isn't. Your premises are wrong. >>alone that changed this? or was it the use of SetCPU 1.5 too? Seems to me >>irregardless of Super/old Agnes, a program requesting "either type of RAM" >>could be given chip, when fast is available. > >A plain A2000 with a 2 megs of expansion RAM has 3 types of memory: > 512K of chip RAM, which is slow due to access by the custom chips. > 512K of non-chip RAM at C00000, which is slow due to being on the chip bus. > 2048K of expansion RAM, which is fast due to not being accessable by the > custom chips. This is true, except that a 2000 with 2 megs of expansion ram and the 'obese Agnus' has only two types of memory, CHIP and FAST. The chunk that was FAST only by virtue of being on the CHIP bus, addressed at $C00000 is now pure CHIP, and is no longer addressed at $C00000, but is instead readdressed to be contiguous with the original CHIP memory. >In a setup like that, the C00000 RAM would be near the head of the list >of available memory because it is detected before the autoconfigure expansion >RAM. This is not nice, since requests for "fast" RAM would go to the slow >non-chip memory instead of the fast non-chip memory. FastMemFirst (also >known as SlowMemLast) puts the slow-fast RAM at the end of the list where >it is less likely to get used. > >FastMemFirst has no effect if you don't have any expansion memory. >FastMemFirst has no effect if you don't have any memory at C00000 (an A500). FastMemFirst has no effect on a 500 with the second 512K and an 'obese Agnus' (Jay Miner likes to call it the 'Gordo Agnus'), since there is no $C00000, HALF-FAST memory. FastMemFirst has no effect on a 2000 with a Gordo Agnus. >The request for "either type of RAM" tells the system to search the fast-RAM >free list first, then search the chip-RAM free list only if the search of >the fast-RAM list failed. The searching of the fast-RAM list first is >always done - regardless of whether FastMemFirst has been done or not. > >In summary: FastMemFirst is a kludge to make systems with the old Agnus and >real expansion memory run faster. It is not needed if you have then new >1-meg Agnus. In summary, the Gordo Agnus is a fully engineered _solution_ to the kludge of having $C00000 memory. Hmm... so why are you disagreeing right up until the last statement? -larry -- "So what the hell are we going to do with a Sun?" - Darlene Phillips - +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
mks@cbmvax.UUCP (Michael Sinz - CATS) (08/01/89)
In article <11353@mcdphx.phx.mcd.mot.com> stan@teroach.phx.mcd.mot.com (Stan Fisher) writes: > >Recently I believe I read on the net that: > > When using the Super Agnes chip, therefore elimating the C00000 RAM, >it is no longer necessary to run fastmemfirst in the startup-sequence, in >order to conserve Chip RAM. Was I dreaming this? Was it the Super Agnes ^^^^^^^^^^^^^^^^^ FastMemFirst was there to move the $C00000 RAM after any other MEMF_FAST type memory. This was done since $C00000 RAM was on the same bus as the MEMF_CHIP and thus runs slower when HI-RES OVERSCAN 16-Colour screens are used. >alone that changed this? or was it the use of SetCPU 1.5 too? Seems to me >irregardless of Super/old Agnes, a program requesting "either type of RAM" >could be given chip, when fast is available. Don't I still want to run >fastmemfirst? And does Mergemem really merge 16bit and 32bit memory pools >into contiguous space? Because there is no $C00000 "fast" memory on a 1-Meg chip-ram system, there is no more need to do the FastMemFirst. It has nothing to do with SetCPU or any other program. MergeMem will merge the memory pools if you have an autoconfig RAM board in the system along with the 2620. The 2620 memory will get used first since it autoconfigs first. -- /----------------------------------------------------------------------\ | /// Michael Sinz -- CATS/Amiga Software/Support Engineer | | /// PHONE 215-431-9422 UUCP ( uunet | rutgers ) !cbmvax!mks | | /// | |\\\/// ...and then, just as all was in kaos, someone said: | | \XX/ "Let there be ... what was that!? ... An Amiga? ... light!" | \----------------------------------------------------------------------/
jms@tardis.Tymnet.COM (Joe Smith) (08/02/89)
In article <11353@mcdphx.phx.mcd.mot.com> stan@teroach.phx.mcd.mot.com (Stan Fisher) writes: > When using the Super Agnes chip, therefore elimating the C00000 RAM, >it is no longer necessary to run fastmemfirst in the startup-sequence, in >order to conserve Chip RAM. Was I dreaming this? Was it the Super Agnes ^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^ -- This assumption is false. >alone that changed this? or was it the use of SetCPU 1.5 too? Seems to me >irregardless of Super/old Agnes, a program requesting "either type of RAM" >could be given chip, when fast is available. A plain A2000 with a 2 megs of expansion RAM has 3 types of memory: 512K of chip RAM, which is slow due to access by the custom chips. 512K of non-chip RAM at C00000, which is slow due to being on the chip bus. 2048K of expansion RAM, which is fast due to not being accessable by the custom chips. In a setup like that, the C00000 RAM would be near the head of the list of available memory because it is detected before the autoconfigure expansion RAM. This is not nice, since requests for "fast" RAM would go to the slow non-chip memory instead of the fast non-chip memory. FastMemFirst (also known as SlowMemLast) puts the slow-fast RAM at the end of the list where it is less likely to get used. FastMemFirst has no effect if you don't have any expansion memory. FastMemFirst has no effect if you don't have any memory at C00000 (an A500). The request for "either type of RAM" tells the system to search the fast-RAM free list first, then search the chip-RAM free list only if the search of the fast-RAM list failed. The searching of the fast-RAM list first is always done - regardless of whether FastMemFirst has been done or not. In summary: FastMemFirst is a kludge to make systems with the old Agnus and real expansion memory run faster. It is not needed if you have then new 1-meg Agnus. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
hassinger@lmrc.uucp (Bob Hassinger) (08/03/89)
In article <477@tardis.Tymnet.COM>, jms@tardis.Tymnet.COM (Joe Smith) writes: ... > FastMemFirst has no effect if you don't have any expansion memory. > FastMemFirst has no effect if you don't have any memory at C00000 (an A500). I was under the impression that the 512K A501 internal memory option for the A500 *was* addressed at C00000 (e.g. slow-fast mem - on chip bus). Is that what you where saying or am I wrong?
jms@tardis.Tymnet.COM (Joe Smith) (08/04/89)
In article <684@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >No it isn't. Your premises are wrong. Oops. I cut out the lines in article <11353@mcdphx.phx.mcd.mot.com> where stan@teroach.phx.mcd.mot.com (Stan Fisher) writes: "I can't believe this is true". The rest of my posting was trying to set Stan straight. >In summary, the Gordo Agnus is a fully engineered _solution_ to the kludge of >having $C00000 memory. Hmm... so why are you disagreeing right up until the >last statement? I forgot that some people may not have seen the orginal posting. Mea culpa. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
johnhlee@cory.Berkeley.EDU (Vince Lee) (08/04/89)
In article <11353@mcdphx.phx.mcd.mot.com> stan@teroach.phx.mcd.mot.com (Stan Fisher) writes: > >Recently I believe I read on the net that: > > When using the Super Agnes chip, therefore elimating the C00000 RAM, >it is no longer necessary to run fastmemfirst in the startup-sequence, in >order to conserve Chip RAM. Was I dreaming this? Was it the Super Agnes >alone that changed this? or was it the use of SetCPU 1.5 too? Seems to me >irregardless of Super/old Agnes, a program requesting "either type of RAM" >could be given chip, when fast is available. Don't I still want to run >fastmemfirst? And does Mergemem really merge 16bit and 32bit memory pools >into contiguous space? You seem to be quite confused to what fastmemfirst does. Not surprising, since a recent issue of Amigaworld spouted out the same misunderstanding to all its readers in a help column (who would write AmigaWorld for help anyway?) When a program asks for either type of ram (MEMF_PUBLIC) is automatically receives Fast RAM first if a sufficient block is available regardless of whether or not FastMemFirst is run. What FastMemFirst does is insure that REAL fast RAM (fast memory on the FAST bus) is given preference over fake fast (slow) RAM, which is memory on the CHIP bus which has been configured as fast RAM. If you have a fat agnus, your c00000 ram is now configured as chip RAM, so you have no slow RAM and don't need FastMemFirst. -Vince Lee > Stan Fisher - stan@teroach.phx.mcd.mot.com - asuvax!mcdphx!teroach!stan > Motorola Microcomputer Division, Tempe, Arizona - (602) 438-3228
phoenix@ms.uky.edu (R'ykandar Korra'ti) (08/06/89)
In article <488@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: >I wonder how many A500's have a full meg of memory. The impression I get is >that most of the A500's in the home have only 512K and 1 floppy. Accurate >numbers would have to come from Commodore, since polling the net would >produce biased results. (The typical net-news reader is more likely to >expand their system than the typical home computer user.) Maybe so, but I know a lot of A500 owners (and am one myself) - and I know of only one A500 which has NOT been expanded past base configuration. The most popular two upgrade paths are a second floppy or memory; I've done both, as have several others I know. The more popular upgrade among those who have only done one is getting up to 1 meg RAM. -- | "Signature V1.2.1.2..." | phoenix@ms.uky.edu | phoenix@ukma.bitnet | | "Got enough addresses, bub?" | CIS 72406,370 | PLink: Skywise | | "Alms! Alms! Laser printers for the poor!" | QLink: Bearclaw |
csuwk@warwick.ac.uk (Ade Lovett) (08/07/89)
In article <12358@s.ms.uky.edu> phoenix@ms.uky.edu (R'ykandar Korra'ti) writes: >In article <488@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: >>I wonder how many A500's have a full meg of memory. The impression I get is >>that most of the A500's in the home have only 512K and 1 floppy. Accurate >>numbers would have to come from Commodore, since polling the net would >>produce biased results. (The typical net-news reader is more likely to >>expand their system than the typical home computer user.) > >Maybe so, but I know a lot of A500 owners (and am one myself) - and I know >of only one A500 which has NOT been expanded past base configuration. The most >popular two upgrade paths are a second floppy or memory; I've done both, as have >several others I know. The more popular upgrade among those who have only done >one is getting up to 1 meg RAM. Too right. If you're going to use your A500 for anything other than playing games, then a second floppy is a must unless you want to suffer from Mac-elbow :-) and the extra 1/2Meg is almost as vital when you have lots of tasks running (although I wouldn't recommend the A501 - in the UK at least there are a lot of similar boards around which also have an easily accessibly enable/disable switch on them - some much nicer than software hacks when you want to run programs that don't like the extra memory. Mind you, when the ECS comes out, everything will be ok, won't it??? :-) aDe
daveh@cbmvax.UUCP (Dave Haynie) (08/09/89)
in article <11353@mcdphx.phx.mcd.mot.com>, stan@teroach.phx.mcd.mot.com (Stan Fisher) says: > Recently I believe I read on the net that: > When using the Super Agnes chip, therefore elimating the C00000 RAM, > it is no longer necessary to run fastmemfirst in the startup-sequence, in > order to conserve Chip RAM. Was I dreaming this? Perhaps. The use of FastMemFirst was never for conservation of Chip RAM. Rather, the 1.2 and 1.3 OS links $00C00000 memory into the memory list prior to any autoconfigured memory. In the A2000 and A500 system implementations, $00C00000 memory is subject to blitter contention, just as if it were Chip memory. So the FastMemFirst program moves that chunk of memory to the end of the memory list, where it will be the last Fast memory used. In all Amiga 32 bit systems, the 32 bit memory is always autoconfigured before any 16 bit memory, so you don't need to worry about reordering anything but the $00C00000 memory, and of course, once all your Chip bus memory is in fact Chip memory, you don't need to use FastMemFirst. > Was it the Super Agnes alone that changed this? or was it the use of SetCPU > 1.5 too? The 1 Meg Agnus eliminated the need for FastMemFirst. SetCPU is smart enough to use 32 bit RAM for it's ROM images if such memory is available and you're using an A2620 or A2630, but it doesn't change the ordering of any normal allocations. > Seems to me irregardless of Super/old Agnes, a program requesting "either > type of RAM" could be given chip, when fast is available. If AllocMem() works as specified, an AllocMem(x,0L) would always return a block of size x in Fast memory before considering any Chip memory. This does imply that it may be traversing the memory list twice, should there only be a block of size x free in the last region of Chip memory (you usually only have one region of Chip memory, but it's possible to have more). > Don't I still want to run fastmemfirst? No. > And does Mergemem really merge 16bit and 32bit memory pools into contiguous > space? Yes. And SetCPU handles that case too, though if you are concerned about having the maximum contiguous chunk of memory available, you should fire up SetCPU FASTROM with the "HEAD" option, so that it'll allocate it's ROM image and maps at the start of 32 bit RAM, rather than at the end. > System = A2000 Rev. 4.x > A2620 > ProRAM w/2Meg > SuperAgnus 1Meg Chip > 1.3 Rom > Also (since I mentioned SetCPU) does Dave Haynie's .profile on cbmvax > do a 'mail > /dev/null' B^) It's more sophisticated than that. When I get mail, I pass it to a filter I wrote (about 50,000 lines of LISP) that's smart enough to know if such mail is Worth My Time To Read. Actually, I've been kind of out of it for at least two weeks; first finishing up a long-term project, then away on vacation for a week. And again, you never know about stuff actually making it through usenet. > Stan Fisher - stan@teroach.phx.mcd.mot.com - asuvax!mcdphx!teroach!stan > Motorola Microcomputer Division, Tempe, Arizona - (602) 438-3228 -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Be careful what you wish for -- you just might get it
stan@teroach.UUCP (Stan Fisher) (08/09/89)
In article <7578@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <11353@mcdphx.phx.mcd.mot.com>, stan@teroach.phx.mcd.mot.com (I) say: (My questions deleted) (Daves responses deleted) >> Also (since I mentioned SetCPU) does Dave Haynie's .profile on cbmvax >> do a 'mail > /dev/null' B^) >It's more sophisticated than that. When I get mail, I pass it to a filter >I wrote (about 50,000 lines of LISP) that's smart enough to know if such mail >is Worth My Time To Read. >Actually, I've been kind of out of it for at least two weeks; first finishing >up a long-term project, then away on vacation for a week. And again, you >never know about stuff actually making it through usenet. >Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" I'm VERY glad to have Dave and his colleagues available AND interested in responding to questions like the one I posed here. I'm also VERY glad that Dave saw the smiley after the crack about mail > /dev/null. I'm sure these people must get megs of e-mail a day and they can't respond to everything. You folks ARE APPRECIATED. Now... Dave.... about that 2090A boot timeout problem of mine ;^} Isn't there something I can patch in the EPROM to extend that delay?? 8^o B^) How soon might there be a 2090A update (firm/software, drivers whatever) Stan Fisher - stan@teroach.phx.mcd.mot.com - asuvax!mcdphx!teroach!stan Motorola Microcomputer Division, Tempe, Arizona - (602) 438-3228
451061@UOTTAWA.BITNET (Valentin Pepelea) (08/09/89)
Dave Haynie <daveh@cbmvax.uucp> writes in Message-ID: <7578@cbmvax.UUCP> > It's more sophisticated than that. When I get mail, I pass it to a filter > I wrote (about 50,000 lines of LISP) that's smart enough to know if such mail > is Worth My Time To Read. May I say, I does not work right. I asked you some pertinent questions a long while ago; never got a reply back. Some other people have also told me the same. The world would be a better place if you got rid of that monster, and inspected the first paragraph of each message yourself. Valentin _________________________________________________________________________ The godess of democracy? "The Name: Valentin Pepelea tyrants may destroy a statue, Phonet: (613) 231-7476 but they cannot kill a god." Bitnet: 451061@Uottawa.bitnet Usenet: Use cunyvm.cuny.edu gate - Confucius Planet: 451061@acadvm1.UOttawa.CA