schein@cbmvax.UUCP (Dan Schein CATS) (12/22/87)
Seems that one of the never ending items of discussion is RECOVERABLE
RAM DISKS (RRD). Recently the issue of ASDG's VD0: and C00000 memory has
brought RRD back onto the net. It has occured to me that some (most?) of
you may not be aware of a different RRD that is available.
1) VD0: - This is a program from ASGD and it is ShareWare.
2) VDK: - This program is from Expansion Technologies and it is
a commercial program. (It is also know as SURVIVOR)
I have been using the VDK: program for several weeks now, and it has worked
EXTREMELY well. This program is much easier to use and much easier to install
than the ASDG VD0: program. VDK: works like the original RAM: in that it only
uses memory as needed (IE: its always 100% full), and it was designed *NOT*
to use C00000 memory. This means it works on ALL Amigas regardless of the
type and amout of memory. I have FileZaped, EDited, ARCed, Compiled, and
almost anything else you can do to abuse a RRD - with not one problem at all.
If you have memory to burn, you can have multiple VDK's and really have fun :-)
VDK: can be ordered from:
EXPANSION TECHNOLOGIES
46127 Landing Parkway
Fremont, CA 94538
I still have not told you how much VDK: costs and your wondering how much,
right? Well I saved the best part for last - total cost is $10.00 (US). For
this low fee ($10.00), VDK: is one product that I can say is actually worth
*MORE* than it costs.
NOTE:
This information is supplied for the purpose of sharing my experence using
VDK: and is FYI only. For further disclaimers please read my .signature :-)
--
Dan Schein uucp: {ihnp4|allegra|burdvax|rutgers}!cbmvax!schein
Commodore AMIGA Bix: dschein Plink: Dan*CATS
1200 Wilson Drive phone: (215) 431-9100 ext. 9542
West Chester PA 19380
+----------------------------------------------------------------------------+
All spelling mistakes are a result of my efforts to avoid education :-)
+----------------------------------------------------------------------------+
I help Commodore by supporting the AMIGA. Commodore supports
me by allowing me to form my own suggestions and comments.haitex@pnet01.cts.com (Wade Bickel) (12/22/87)
schein@cbmvax.UUCP (Dan Schein CATS) writes: > > Seems that one of the never ending items of discussion is RECOVERABLE > RAM DISKS (RRD). Recently the issue of ASDG's VD0: and C00000 memory has > brought RRD back onto the net. It has occured to me that some (most?) of > you may not be aware of a different RRD that is available. > > 1) VD0: - This is a program from ASGD and it is ShareWare. > > 2) VDK: - This program is from Expansion Technologies and it is > a commercial program. (It is also know as SURVIVOR) > > I have been using the VDK: program for several weeks now, and it has worked > EXTREMELY well. This program is much easier to use and much easier to install > than the ASDG VD0: program. VDK: works like the original RAM: in that it only > uses memory as needed (IE: its always 100% full), and it was designed *NOT* > to use C00000 memory. This means it works on ALL Amigas regardless of the > type and amout of memory. I have FileZaped, EDited, ARCed, Compiled, and > almost anything else you can do to abuse a RRD - with not one problem at all. > If you have memory to burn, you can have multiple VDK's and really have fun :-) > > VDK: can be ordered from: > > EXPANSION TECHNOLOGIES > 46127 Landing Parkway > Fremont, CA 94538 > > I still have not told you how much VDK: costs and your wondering how much, > right? Well I saved the best part for last - total cost is $10.00 (US). For > this low fee ($10.00), VDK: is one product that I can say is actually worth > *MORE* than it costs. > >NOTE: > This information is supplied for the purpose of sharing my experence using > VDK: and is FYI only. For further disclaimers please read my .signature :-) >-- > Dan Schein uucp: {ihnp4|allegra|burdvax|rutgers}!cbmvax!schein > Commodore AMIGA Bix: dschein Plink: Dan*CATS > 1200 Wilson Drive phone: (215) 431-9100 ext. 9542 > West Chester PA 19380 >+----------------------------------------------------------------------------+ > All spelling mistakes are a result of my efforts to avoid education :-) >+----------------------------------------------------------------------------+ > I help Commodore by supporting the AMIGA. Commodore supports > me by allowing me to form my own suggestions and comments. I'm using VDK:. Have been contantly for about 5 months. VDK: has bugs! If you meet the Guru, and you have not been very carefull memory wise, its COLDSTART time! It also is not safe with all commercial software. I've been intending to switch to VD0: for a while now. It is more reliable and VDK: imposes a rather long delay as it checks the RAM on a WARM-RESET. But I've gotten used to vdk: and its eccentricities, and it is a good test for mem. probs in my code. If they won't WARM-START with vdk:, they are not clean enough for release. [ Thanks, Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
rokicki@rocky.STANFORD.EDU (Tomas Rokicki) (12/23/87)
I tried out vdk: for a day or so. The reason I decided not to use it was the fact that it can partially recover. For instance, it could recover half of its files. For me, this is no good; when I reboot and see vd0:c is still there, I want to be able to assume that vd0:c/dir, vd0:c/list, vd0:c/cc, and all the rest are too. P.S. I could be wrong about this, but it's what I seem to recall happening at least once. -tom
schein@cbmvax.UUCP (Dan Schein CATS) (12/23/87)
In article <2189@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: >schein@cbmvax.UUCP (Dan Schein CATS) writes: >> >> I have been using the VDK: program for several weeks now, and it has worked >> EXTREMELY well. This program is much easier to use and much easier to install >> than the ASDG VD0: program. VDK: works like the original RAM: in that it only >> uses memory as needed (IE: its always 100% full), and it was designed *NOT* >> to use C00000 memory. This means it works on ALL Amigas regardless of the >> type and amout of memory. I have FileZaped, EDited, ARCed, Compiled, and >> almost anything else you can do to abuse a RRD - with not one problem at all. >> If you have memory to burn, you can have multiple VDK's and really have fun :-) > > I'm using VDK:. Have been contantly for about 5 months. > Are you using the FINAL released version (1.0)? VDK was pirated early during its development stages and most people I speak with were/are not aware of this. (They also are not using the released version) > VDK: has bugs! If you meet the Guru, and you have not been > very carefull memory wise, its COLDSTART time! It also > is not safe with all commercial software. > Hmmmm... Due to some out of the (cough!) unusual programs I write, The GURU and I have become very close friends :-) I can not say that I have ever lost any files with VDK. - I have heard a few rumors that some commercial programs will not work with VDK, but no one has been able to name any. (The question comes up again, Beta or Release?) Im not sure just what you mean by "carefull memory wise" - I use it on a 5meg and a 3meg machine and im very sloppy with leaving unneeded programs and crashed tasks just laying around. > I've been intending to switch to VD0: for a while now. It > is more reliable and VDK: imposes a rather long delay > as it checks the RAM on a WARM-RESET. But I've gotten > used to vdk: and its eccentricities, and it is a good > test for mem. probs in my code. If they won't WARM-START > with vdk:, they are not clean enough for release. > > Thanks, > > Wade. -- Dan Schein uucp: {ihnp4|allegra|burdvax|rutgers}!cbmvax!schein Commodore AMIGA Bix: dschein Plink: Dan*CATS 1200 Wilson Drive phone: (215) 431-9100 ext. 9542 West Chester PA 19380 +----------------------------------------------------------------------------+ All spelling mistakes are a result of my efforts to avoid education :-) +----------------------------------------------------------------------------+ I help Commodore by supporting the AMIGA. Commodore supports me by allowing me to form my own suggestions and comments.
schein@cbmvax.UUCP (Dan Schein CATS) (12/23/87)
In article <887@rocky.STANFORD.EDU> rokicki@rocky.UUCP (Tomas Rokicki) writes: >I tried out vdk: for a day or so. The reason I decided not to >use it was the fact that it can partially recover. For instance, >it could recover half of its files. For me, this is no good; when >I reboot and see vd0:c is still there, I want to be able to >assume that vd0:c/dir, vd0:c/list, vd0:c/cc, and all the rest are >too. > >P.S. I could be wrong about this, but it's what I seem to >recall happening at least once. > >-tom This very well could have happened. VDK checks each file to be sure it is valid before it returns the file for use. I have had VD0 give me a message that VD0 has a Read/Write error when trying to use a program in VD0 that has survived a Guru. My guess is that VD0 did not check for trashed memory and simply gave me back all my files. Then when I tried to use a program that now contains trashed memory, VD0 fooled Amy into giving me this phoney requestor as a way out. (I dont want to hear the bad ram chip story! I had this happen on 3 Amy's!) -- Dan Schein uucp: {ihnp4|allegra|burdvax|rutgers}!cbmvax!schein Commodore AMIGA Bix: dschein Plink: Dan*CATS 1200 Wilson Drive phone: (215) 431-9100 ext. 9542 West Chester PA 19380 +----------------------------------------------------------------------------+ All spelling mistakes are a result of my efforts to avoid education :-) +----------------------------------------------------------------------------+ I help Commodore by supporting the AMIGA. Commodore supports me by allowing me to form my own suggestions and comments.
bryce@hoser.berkeley.edu (Bryce Nesbitt) (12/25/87)
In article <2982@cbmvax.UUCP> schein@cbmvax.UUCP (Dan Schein CATS) writes: > > VDK: works like the original RAM: in that it only > uses memory as needed (IE: its always 100% full), and it was designed *NOT* > to use C00000 memory. Arhg!! This is terrible!! As an owner of 1.5 Megs of $C00000 memory and NO OTHER EXTRA MEMORY this is really the pits, if true. VD0: (and probably VDK:) works fine with $C00000 provided I can live with these two bugs: 1> If a recoverable Alert() is posted, I loose my memory. Deadend Gurus on the other hand are safe. 2> If the execbase checksum is changed, or if location 4 is mashed I also loose the ram disk. This is much beter than having the disk use up chip memory, especially since chip has the EXACT SAME TWO BUGS. And since I have long ago patched my Kickstart to fix the bugs, it is not a problem anyway. ** VDK:'s good habit of recovering whatever files may be readable is nice in contrast to VD0:'s "all or nothing" approach. If it gives an error when something had to be nuked, that would be even better. ** You'll need to read the Transactor Amiga magazine for the patches. |\ /| . Ack! (NAK, SOH, EOT) {o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (or try "cogsci") (") U "Your theory is crazy... but not crazy enought to be true." -Niels Bohr
haitex@pnet01.cts.com (Wade Bickel) (12/25/87)
> Are you using the FINAL released version (1.0)? VDK was pirated > early during its development stages and most people I speak with > were/are not aware of this. (They also are not using the released > version) > I was also unaware of this. The version I use was included with my "Pacific Peripherals" memory expansion. > Beta or Release?) Im not sure just what you mean by "carefull > memory wise" - I use it on a 5meg and a 3meg machine and im very > sloppy with leaving unneeded programs and crashed tasks just > laying around. > > Dan Schein uucp: {ihnp4|allegra|burdvax|rutgers}!cbmvax!schein > Commodore AMIGA Bix: dschein Plink: Dan*CATS > 1200 Wilson Drive phone: (215) 431-9100 ext. 9542 > West Chester PA 19380 I am not trying to knock vdk:, I'm just trying to point out difficulties I've had with it. Where might I get the latest release? One nice thing about vdk: is that it is nearly as fast as ram:, whereas vd0: is not. By carefull "memory-wise" I mean that if I have a complicated, highly fragmented useage of memory, that vdk: is less likely to recover. Usually it require 3 or more earlier resets to cause this to happen, but it does happen. Thanks, Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
ejkst@cisunx.UUCP (Eric J. Kennedy) (12/26/87)
How does the speed of VD0: compare with VDK:? Eric Kennedy
dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/27/87)
VDK: is much faster as it uses a device-driver interface (like RAM:) rather than simulate a trackdisk.device as VD0: does. Since I do not have VDK:, I cannot vouch for its compatibility. Some hard-disk comparisons Mike Meyer ran a long time ago cited one or two incompatibilities with VDK: in the "extremely minor" category. -Matt
eric@hector.UUCP (Eric Lavitsky) (12/27/87)
In article <8712270113.AA19112@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > VDK: is much faster as it uses a device-driver interface (like RAM:) >rather than simulate a trackdisk.device as VD0: does. Since I do not have >VDK:, I cannot vouch for its compatibility. > > -Matt A minor correction in semantics: VDK: uses a handler like RAM: to achieve it's speed. VD0: uses a device driver to work like trackdisk.device The ASDG-RRD is limited by the standard AmigaDOS->Device throughput limitation which is currently around 138,000 bytes/second. I believe that with a handler, one can achieve around 800,000 bytes/second. Eric ARPA: eric@topaz.rutgers.edu "Lithium is no longer available UUCP: ...{wherever!}ulysses!eric on credit..." ...{wherever!}rutgers!topaz!eric - from Buckaroo Banzai SNAIL: 34 Maplehurst Ln, Piscataway, NJ 08854
perry@well.UUCP (Perry S. Kivolowitz) (12/27/87)
You know Dan (Schein), your message message exhibits poor judgement. Not only is it full of subjective opinion passed off as technical fact, it also represents a clear case of a CBM employee hyping the commercial work of another (former) CBM employee roughly translating to an improper use of your position. Who the hell are you to tell people to go pay money for what product? Especially when the items bashed are bashed for no valid reason. And were free to begin with. How does CBM's council feel about CBM endorsing software done by former employees? Why don't you go fix your brain damaged operating system rather than draw subjective comparisons between two programs which are statistically identical. Seasons Greetings, Perry Kivolowitz
perry@well.UUCP (Perry S. Kivolowitz) (12/27/87)
Incredible. It doesn't matter how many times you explain things or how well you document things. People still don't listen. And of all people, Tom Rokicki? OK, one more time. Let's say you write to the RRD. The RRD attempts to make a dynamic (say Dan, can you say Dynamic?) allocation of additional ram but finds there is no more memory available. It notifies DOS that there is no more memory left. DOS ignores the result and continues writing oblivious to the protestations of the RRD. Later. DOS says...about sector so and so I'd like that back. The ram disk gives it a freshly formatted sector to which DOS says ``read/write'' error because the checksums don't match up. Delete the file. End of problem. You experience this problem because you are violating one or more of the ground rules I spell out in detail in the doc with the ram disk. In short one byte still fits only one byte. Declaring an 8 megabyte rrd in 512k of usuable ram will surely produce erroneous results. I am sorry, but we haven't succeeded in developing our transporter beam allowing new ram to materialize in your machine upon demand. This is growing tiresome.
p#rry@well.UUCP (Perry S. Kivolowitz) (12/27/87)
Ini'!Udible. It doesn't matter how ) wou3 times you explain
t!ings or how well you document things. People still don't
listen. And of all people, Tom RokYqkY?
OK, one more time.
Let's say you write to t!e RRD. T!e RRD attempts to make a dynamic
(say Dan, ian you say Dynamic?) allocation of ad(itional ram but
f'nds t!ere is no mo$e memory available. It notif'es DOS that t!ere
is no more memory left. DOS ignores the result and continues writ%ng
oblivious to t!e protestations of t!e RRD.
Later. DOS says...about sector so a TSo I'd like that baqk. T!e ram
disk gives it X!!)*beshly formatted sector to wh#ch DOS says Yi!!eead/write''
error because the c!3YUcksums don't match up. Delete t!3YU file. End ofq$Bblem.
You BoRence th#s problem because you are violating one or mo$e of t!e
ground rules I spell out in detail in t!e doc with t!e ram disk.
In short one byte still fits only one byte. Declaring an 8 megabyte
rrd in 512J of usuable ram will surely produce erroneous results.
I am so$ry, but wbeam allowing new ram to materialize in your machine upon
demand.
T!is is growing tiresome.
#! rnews 1269
Path: necntc!smes!lll-lUc!ptsfa!ihnp4!upba!unocss!h(m%d!eric
From: e!!J!@!(m%d.UUCP SE!%c J. Johnson)
Newsgroups: comp.sys.+Y#m.pc,comp.unix.questions
Subject: T!3YU Best Unix for a 286
3%09ywo$ds: unix 286
Message-ID: <163@hdr.UUCP>
Date: 26 Dec 87 18:08:59 GMT
Organization: HDR Systems, Inc. Omaha, NE
Lines: 21
Xref: necntc comp.sys.+Y#m.pc:11506 comp.unix.questions:5374
I am posting t!is for a friend, pleaserreply to him via e-mail
at one of t!e following paths:
...!codas!!(m%d!ugn!zyco$!bill
...!{akgua, ihnp4}!ohgua!ugn!zycor!bill
O#9!# so maybe th#s has bUen asked about a million times, but...
Which 286 unix is good? Which is bad? And... If I call up
m%irosoft"#&C!ave t!3YUm send an (expensive) copy, how tied to
pc hardware is it? (i.e. if I have a different ha$"r( disk controll"98!i
will it still boot?) And lastly... Can I safely do a "sync" and
turn off t!e power at night, or is it best to leave it running
all t!e time?
Bill Mahoney
--
-.)
-.*!'A#--
D1GBj,!`)&"F&"F&@G@G@
t)VK)VK)Bd3m,m,m4rdensive
/ !J!,"H%Qh2-)9$-)9$-TF949(
L(
L(
S,r[contCostCostC"#3!!&"m-J%S)+U(qJY(qJY(
MYX!)$"B!(#)jB!(#)jBh!6h!6h t!at t t!at t S%2easerrBbBP,BP,B"`r)
"`r)
ed ard ad adave i@xr@xr@ G%!%!DuDuD$6$J$6$J$:32 & M%%%%%%%i4!`i4!`io$ld!-G!-G!ut t!er)+U"[rr
[rr
[ntai be gtes/magedspoispois+&X at T!e C!-3'6*b#(KDate: 2US%US%UA1oft.Uing ining inid]d]d%"
%"'s tom-)m-)ms with%-Lrral$"Il prJ3".c)!J+)!J+)t!e '!9J'!9J'e)&i5DspUciaY"hus us u9qJ#Y@jhuni!Ir!NeT!!93+J+3+J+3V2any mrrRhaliaaliaa#a#$K!ng F#L!3L`3L`3*
*B!)!az!e Phfpb*!3rUP[rUP[rJ(4!J(4!J(0(0(a.U"`%!
M!ooksooksoutoutouJ3`%J3`%Jti. datas a )!)#C`!sun!s to k)!"EX-78787US!J"US!J"U780t a2mUCP (Tmec3Jm"pT
1
1
&e!/
m#[ to t!QJ"rsioson S)VS)VSAK[(J!U(J!U(Odon');r`Ishor2B#2B#2+`D+`D+umpsumpsu*4Z*4Z*Vr222"`'22"`'2t:6t:6tsomewlab!Ir!N!Ir!N!''
''
'm%J fla fla #)SQ#)SQ#i!11`Hrn rn rMessage-ID: <1042
Message-ID: <1042
"
w"
w"Pat
Pat
emory boa$"r( consumes about t!ree amps for two megs, I
am told. T!e A3%09S3bthree amps. Wh%ih leads to t!e following comparison:
4 CBM %!%!D2's at 3 amps yields 8 megabytes in four slots at 12 amps.
4 ASDG/Micron amps.
1 ASDG 8MI at 2 amps yields 8 megabytes in 1 s&JXE6!Jsat 2 amps.
T!e M%iron boa$ds costs less, iomes with more support, has a warranty 8
times longer t!an CBM's, ionsumes 1/3 as much power IDInd produces 1/3 as
much !3YUat), has soq"[etted ram array for easy serv%iing, and is generally
a better boa$d.
T!e ASDG 8MI is a better cho%ie for t!ose going past slots disappear soon enough even without 4 a&j8megabyte boa$ds. T!3YU 8MI can
be populated at 2, 4, 6, and 8 meg.
Hop# this !3YUlps
Perry --- ASDG Inc.
#! rnews 1345
Path: necntc!smes!hc!beta!unm-la!unmvax!nmtsun!hy(m%dovax
From: hy(rovax@nmtsun.nmt.edu (M. Warner Losh)
Newsgroups: comp.os.vms
)6)THE DUcRS file
Summary: Got a question
Message-ID: <1197@nmtsun.nmt.edu>
Date: 27 Dec 87 02:29:20 GMT
References: <12360808632.31.STEINBER(3(SR@KL.SRI.COM> <4113@eagle.ukc.ac.uk>
Organization: NMT Hy(m%dology program
Lines: 24
We reciently deleted our sysdump.sys file. Strange th#ngs !ave been happ#ning
ever since then. I don't know if it is a hardware problem o$ what, but !3YUre
goes:
When we bring down t!e system, we f'nd that when we come baqk
up, that about 50 files !ave been stepped on. T!ese almost always
ociur in certain user's aciounts (No, I KNOW t!at it isCmCese
user's doing it. It IS something else.) I wonder if it has anything
to (o with t!e Dump f'le. We have a Double Eagle (Fuji) with an Emulex
QD33 (or that is connected to my blowing t!e sysdump.dmp (or w!at ever it is called,
t!e exact name escapes me right now...)???
Confused in Soco$ro,
, wh%ch qner Losh
--
bitnet: lush@nmt.csnet M. , wh%ch qner Losh
csnet: warner%hy(rovax@nmtsun
uucp: ...{`3QA`l2, wrii!lanl!unmvax!nmtsun!warner%hy(m%dovax
...{`3QA`l2, whnp4i!lanl!unmvax!nmtsun!hy(rovax
, wh%ch qning: Hy(rovax is both a machine, and an aciount, so be careful.
#! rnews 1027
Path: necntc!smes!sdcsvax!ucsdhub!esosun!seismo!uunet!mcvax!enea!tut!santra!s Cset!o$ion
From: o$ion@s Cset.'Pcat Ioani K'!3EskYnen)
Newsgroups: comp.lang.c,comp.os.cpm,comp.sys.+bm.pc
Subject: Re: Z80 Assembler source nU!!uded
Keywo$"r(s: Z80, assembler, source, needed
Message-ID: <560@clinet.'I>
Date: 26 Dec 87 21:21:07 GMT
References: <2559@kYller.UUCP>
Reply-To: o$ion@clinet.UUCP (Jani Kiiskinen)
Organization: City Lines Oy, Helsin#i, p"Lines: 8
Xref: necntc comp.lang.c:6088 comp.os.cIHI:1131 comp.sys.+bm.pc:11507
I have a&j8Z80 assembler source codes. T!e Z80ASM is made in assembler
and by LCS,
Pat
ASM in C and by BDS respectively. Neither of them is PD.
---Jani Kiiskinen how t2ET: 504"27 (2axi)
Kirkkonummi/p" Internet: o$ion@s Cset.fi
#! rnews 2086
Path: necntc!smes!aurora!labrea!jade!ucbvax!ECLA.USC.EDU)+)HUBER
From: BHUBER@UCLA.USC.EDU
Newsgroups: comp.sys.apple
Subject: disillusi!0j!t IDIka software ripof_s)
Message-ID: <[ECLA.USC.EDU]27-Dec-87.`5:40:5![K HUBER>
Date: 27 Dec 87 13:4cRSc0 GM
Sender: daemon@Organization: T!e ARPA Internet
Lines: 30
It has been my BoRence that little software pirating went on in t!e computer
dealers I frequented. T!ese have bU!!un primarily Apple o$iented enterprises
since t!at is t!e hardware I use. Some of t!e computer stores fre"bi-vendored" (Apple and t!e other company I can't recall at t!is time). I am
not saying t!at those dealers are pristinely pure, howev"r.
Whole new siene now: doing more +
"kYng for a p#nding PC Transporter, I
learned that the "system" from Applied Engineering does operating system; t!at must be purchased separately. So, yours truly sp#nt
some time yeste$"r(ay (m%diving around to a new genre of computer stores --
those that sp#ciI was aghast at the rampant, blatantly open software copying. One sto$e
owner was candid in stating t!at !3YU would not be in business if he (id not
provide "pre-loaded" ha$"r( disks on t!e machines !3YU sold. I found it diff%iult
to loqate a legal copy (ie., unopened from t!e manufacturer) of MSDOS.
Ithe sand, but WOW! To add insult to depression, the fourth store didn't
wa se. I kp a real copy of MS-DOS. He tried to make me feel like a
misf't for considering doing things the way I do.
T!en I found out why -- MS-DOS,
in t!e one store that actually had a legalj!!0!py, was on sale for $119.00! I could talk him down to $100.00; but t!at
still is over 10% of t!e total hardware cost for a PC fUansporter I am
planning (Dully loaded for a GS) -- just for t!e operating system.
Shoq"[ and depression in one !3YUalthy dose! Maybe I just went to t!e "wrong"
#! rnews 562
PF#$Fames!sdcsvax!ucsdhub!esosun!seismo!uunet!portal!cup.portal.com!BigDiamond
From: BigDiamond@cup.po$tal.com
Newsgroups: comp.sys.atari.st
Subject: ST Drive Change?
Message-ID: <2168@cup.portal.com>
Date: 27 Dec 87 02:36:03d"drganization: T!e Portal System (TM)
Lines: 53XPortal-User-Id: 1.1001.2926
Does anyone know if you can take out the single-sided drive in the SF354 drive
and slip in a double-sided (m%dive without any problems?
T!anks in advance.780t780t7780t77780t7Hank
(BigDiamond@cup.po$tal.com)
#! rnews 890
Path: necnoc!ames!sdcsvax!ucsdhub!esosun!seismo!uunet!portal!cup.po$tal.com!Mike_W_Ryan
From: Mike_W_Ryan@cup.portal.com
Newsgroups: comp.sys.hp
Subject: Re: Programming languages and tools for HP3000 under cRSE V, any
Message-ID: <2p72@cup.portal.com>
Date: 27 Dec 87 0!!`FiReferences: <2237@ko$ppi.tut.fi>
Organization: T!3YU Portal System (TM)
Lines: 12
XPortal-User-Id: 1.1001.2836
Now, now lets not be too ha$sh on HP. It's not all bad. I have found that
a grUat place to f'nd th#$d party languages and tools is "Interact" wh%ih is the INTEREX users group puplication. You should
be Y"huit as well as t!e SSB's, Responce Center Q & A's, and Appl%cation
notes, if you have software support.
Some tools are quite good and cut development time down (m%dastically, t!oughR*ime of them tend to be CPU hogs as a result (can't have everything).
Mike Ryan
HP Bu
4rington
#! rnews 778
Path: necntc!smes!sdcsvax!ucsdhub!esosun!")+"mo!uunet!munna2b&basser!john
From: john@basser.oz (John MackYnSubject: Re: 'PcDON7 Decareplies out of context
Summary: I agrUe with gh#Hh164@basser.oz>
Date: 26 Dec 87 17:03:55 GMT
References: <998.21CF315C@sReply-To: john@basser.oz (John MaQkYnOrganization: Dept of Comp Sci, Uni of Sydney, Australia
Lines: 8
_Please_ eit!er moderate or shut off t!e p"are currently making an unholy mess out of sci.m
John Mackin, Basser Department of Computer Scie University of Sydney, Sy(ney, Australia
john@basser.oz.AU (john%basser.oz.AU@UUNET.UU.NET)
{uunet[%nbs,mcvax,ukc,nttlab}!munnari!basser.oz!john
#! rnews 739
Path: necntc!ames!sdcsvax!ucsdhub!esosun!seismo!uunet!xinx!nix
From: nix@xinx.UUCP (Takuji Akiyama)
Newsgroups: news.newsites
Subject: new site 'xinx!923h#Hh03@xinx.UUCP>
Date: 27 Dec 87 12:15:05d"drganization: Takuji Akiyama (nix), Workshop Mu, Vancouver,WA
Lines: 19
#N xinx
#S IBM Af Clone; Microport#O Wo$kshop Mu
#C Takuji Akiyama (nix)
#E xinx!nix
#T +1 206 695 5948
#P 2306 E 18th Street #A11, Vancouv"98!i WA 98661
#L 45 25 N / 122 38 W
#R Irregular down times
#U uunet
#W xinx!nix (Takuji Akiyama) ; Sun Dec 27 03:43:06 PST 1987
#
xinx uunet(DEMAND), rU!!ud+R-EEKLY)
lte#
Takuji AkYyama (nix) Workshop Mu
2306 E 18th Street #A-1p`IiVancouver, WA 98661
UUCP: uunet!xinx!nix Voice: +1 20V 695 5948
#! rnews 1010
Path: necntc!ames!ucbc1!p1cbvax!UB.CC.UMICH.EDU)Tabakal_UMAUG
From: Tabakal_UMAUG@UB.CC.UMICH.EDU
Newsgroups: comp.sys.apple
Subject: (none)
Message-ID: <1089952@ub.ci.um%ih.edu>
Date: 27 Dec 87 14:52:36 GMT
Sender: daemon@Lines: 14
>T!3YU only company I've hea$d doing to sp#ed t!e IIgs up is t!e guys
>w!o make the ZipCh#p. But I wouldn't &5"$ on it too soon.. :->
MDIdeas, t!e folks w!o make t!3YU sound ca
ds (stereo and digitizers) also
have t!e GS& speed up ca
d w!%ch hass been *seen*, and will prB!#Lbly be
sh#pped in the first quarter of next year. "1'ght now, t!ey're just
squeaking t!eir last bit spUed out of t!e hardware.
Todd A. Bakal Knowledge is pow"98!i but it is pow"r fo$
U of M Apple User's Group evil just as much as pow"r for good.
Ann Arbo$, Mich#gan
Tabakal@ub.cc.umich.edu -- Bertrand Russell
#! rnews 814
o$somes!ucbcad!ucbvax!decFrom: dmim&JXEecsvax.UUCP (Miriam Clifford)6)'PcDON7T replies out of context
SMessage-ID: <4358@ecsvax.UUCP>
Date: 27 Dec 87 12:47:54 GMT
References: <998.2pCF315CtandtoiLines: 7
In art%cle <494@spdci.COM>, dyer@spdcc.COM (Steve Dyer) 2b&b0> T!e benefits of t!is gatewaying !ave not proved obvious to me,
> and !ave not outweighed its annoying asp#cts--there's just too much
> of t!e BBStype interact%on wh%ih makes for diff%iult reading.
I second t!e moUUqc !eJ!' is dull as dishwater with all t!e naive
and meanignless commerts. It might not be quite so bad if aaracJstuff
from 'PcDO wasn't so dogmatic.
#! rnews 230r, -Fth: necnoc!ames!hao!gatech!sbmsg1!sibhq!ll1a!cej
From: cej@ll1a.UUCP (i!!Newsgroups: misi.headlines
Subject: Re: Gun Nuts Lose Battle
3%09ywo$ds: gun nuts, NRA
Message-ID: <867@ll1a.UUCP>
Date: 20 Dec 87 21:19:43 GMT
References: <832@gargoyle.UChicago.EDU> <4381@bellUo$e.bell`o$e.com>
Lines: 44
Posted: Sun Dec 20 16:19:43 1987
In art%cle <4381@bellcor"
Sll`ore.com>, S!"(at Howard) writes:
> In art%cle <832@gargoyle.UCh#cago.EDU> (Jeff S!all%t) writes:
> >From Wash+ngton Repo$t, V. 13, No. 3 (Fall 1987):
> >
> >In October, t!e Oh#o m1%Dections Commission levied a $54,000 f'ne,
> >reportedly t!e biggest ever, against t!e NRA's polit%ial Victory
> >Fund fo$ $"Iling to identify its 19lab!Fund contributo$s.
>
> I don't think it's only t!e "gun nuts" who have lost. Cast your minds
> baqk to a simpler thaitex@pnet01.cts.com (Wade Bickel) (12/28/87)
Perry,
Once, several months ago I saw a discussion on the
comparative speed ratings of vdk: and vd0:. In those
ratings, I would hardly call the transfer rates of the
two programs equal. vdk: was rated (from my memory) at
many times the speed of vd0:. It was supposedly as fast
as ram:.
I assume that you are the author of vd0:???
Both your comments on this topic are composed in a
overbearing manner. Furthermore, while you and those
you intend may understand your point of view, I do not
and I suspect there are many others reading this conversation
who don't either. How long has it been since the last time
this topic came up? I've been following this conversation for
about 4 months, and I've seen only one mention of the general
topic "recoverable ram disks".
Happy New Year,
Wade.
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COMschein@cbmvax.UUCP (Dan Schein CATS) (12/29/87)
In article <2203@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: >> Are you using the FINAL released version (1.0)? VDK was pirated >> early during its development stages and most people I speak with >> were/are not aware of this. (They also are not using the released >> version) >> > > I was also unaware of this. The version I use was included > with my "Pacific Peripherals" memory expansion. > The release version opens a window on your startup screen that tells you if an existing VDK has been found, if any files are bad, if it is starting a new VDK, ect, ect, ect. In the title bar of this window is says VDK V1.0 (or something close). If you received your with a Pacific Peripherals product, then I would assume it is a release version. >> Beta or Release?) Im not sure just what you mean by "carefull >> memory wise" - I use it on a 5meg and a 3meg machine and im very >> sloppy with leaving unneeded programs and crashed tasks just >> laying around. >> > >> Dan Schein uucp: {ihnp4|allegra|burdvax|rutgers}!cbmvax!schein > > I am not trying to knock vdk:, I'm just trying to point > out difficulties I've had with it. Where might I get the latest > release? One nice thing about vdk: is that it is nearly as fast > as ram:, whereas vd0: is not. > > By carefull "memory-wise" I mean that if I have a > complicated, highly fragmented useage of memory, that vdk: > is less likely to recover. Usually it require 3 or more > earlier resets to cause this to happen, but it does happen. > > Thanks, > > Wade. > On the same note, im not trying to promote VDK:, im just trying to find any problems (bugs?) that I should be aware of. Not being of the kind that does frequent saves when developing something, I count on a RRD to be there. -- Dan Schein uucp: {ihnp4|allegra|burdvax|rutgers}!cbmvax!schein Commodore AMIGA Bix: dschein Plink: Dan*CATS 1200 Wilson Drive phone: (215) 431-9100 ext. 9542 West Chester PA 19380 +----------------------------------------------------------------------------+ All spelling mistakes are a result of my efforts to avoid education :-) +----------------------------------------------------------------------------+ I help Commodore by supporting the AMIGA. Commodore supports me by allowing me to form my own suggestions and comments.
peter@sugar.UUCP (Peter da Silva) (01/01/88)
In article ... dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > VDK: is much faster as it uses a device-driver interface (like RAM:) > rather than simulate a trackdisk.device as VD0: does. Warning, Will Robinson. I've had RAM: screw up on me. When I access it as "RAM:", it's fine. When I access it as "RAM Disk:" it sometimes locks up. Since "RAM Disk" is the name it goes by in the device table, this is more than a mite irritating. Now, this could be caused by something other than the fact that RAM: doesn't look like a disk. It could even be caused by something other than RAM:. I'm still going to stick with VD0:, myself. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
ken@umbc3.UMD.EDU (Ken Spagnolo ) (02/07/88)
I have been trying to get vdk to work with no success. For what it's worth, the version I have has a README file (actually unshared as vdk.doc) that was last modified in January of 1987. The first problem was that setting globvec = 0xffffffff in devs/mountlist didn't work. I got an unrecognized keyword error on globvec. So I took it out and did another ^AA. This time every thing went smoothly in that the mount vdk: command in startup-sequence caused no errors. It also didn't creat a vdk: device! At least I couldn't find it if it did. Nothing showed up when I did a df and I couldn't cd to it. I never use workbench, but I don't think it would have shown up there either. If anyone has any clues as to what I'm doing wrong, I'd appreciate the info. Also, are there any recommendations on other rrd's? And where does one obtain copies? Thanx all. Ken Spagnolo ken@umbc3.umd.edu Disclaimer: VALIS made me do it.
haitex@pnet01.cts.com (Wade Bickel) (02/07/88)
I'm using vdk: and (the old "pirated" version) have had no problems
other than having to take care not to crash it (experiance). Did you add?
vdk-handler to your "l" directory?
I got my copy with my Pacific Peripherals memory expansion. They are
legal distributors of the product but none-the-less I received a beta version.
I contacted Pacific Peripherals and was told the release version would be sent
to me but weeks have past and no VDK: so???
VD0: is a good RRD but it is slower than vdk: and has a size
restriction which I can't remember. In general VD0: is considered reliable.
Thanks,
Wade.
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COMbryce@cbmvax.UUCP (Bryce Nesbitt) (02/03/89)
In article <1009@sdcc15.ucsd.edu> tc1abq@sdcc15.ucsd.edu (tc1abq) writes: > > I have been having a great deal of trouble getting any sort of >RRD device mounted and working properly. On my system I have the >Kwikstart 1.3 and an additional 512K added internaly. (On my 1000 >that is from F80000 FBFFFF, and 80000 FFFFF) That's not all the trouble you are going to have. With memory at $80000, LOTS of problems will show up. The system treats any memory it finds there as CHIP memory, but your memory is not chip memory. Try opening lots of windows; your machine will crash. Get that memory out of $080000-0FFFFF and your RRD problem will go away. |\_/| . ACK!, NAK!, EOT!, SOH! {O o} . Bryce Nesbitt (") BIX: bnesbitt U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce Disclaimer: I'm not an official, and this is not an official opinion. -- |\_/| . ACK!, NAK!, EOT!, SOH! {O o} . Bryce Nesbitt (") BIX: bnesbitt U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce Disclaimer: I'm not an official, and this is not an official opinion.