perry@well.UUCP (Perry S. Kivolowitz) (01/22/87)
I plan to work on creating uuencoded shar files for the ASDG Recoverable Ram Disk tonight. This means the net might see a posting before Friday of this week. What Is The ASDG Recoverable Ram Disk? It is an AmigaDOS device driver which implements a completely DOS compatible (unlike ram:) disk device in memory. Unlike ram:, the ASDG recoverable ram disk survives resets, guru's, and crashes. That is, after the guru visits, one simply reboots to find the full contents of the ram disk still in tact. Is The ASDG Recoverable Ram Disk Tied To ASDG Hardware? It was since its first shipping in August of 1986. However, I have removed dependencies on the ASDG hardware (which amounted only to looking at serial numbers) for the public version. Will The ASDG Recoverable Ram Disk Work With Anyone's Hardware? It should, unless the memory board designer was totally inept and caused the ram to become mashed when system resets take place. Will The ASDG Recoverable Ram Disk Work With NO Fast Ram At All? Yes. I put in this feature knowing that a lot of people don't have fast ram expansion boards yet but could still benefit from a recoverable ram disk. Is The ASDG Recoverable Ram Disk In The Public Domain? NOOOOOO. It is not. ASDG Incorporated retains all rights to the software. We are specifically not releasing it to the public domain so that we may main- tain at least some legally enforcable control over who may and may not dis- tribute this product. Who Can Distribute This Product? (1) Networks and BBS's run by non-vending entities. (2) User Groups (for non-profit benefit). (3) Fred Fish (he...and he alone). Who Cannot Distribute This Product? (1) No vendor or hardware or software may distribute this product under any guise or pretense. Especially you Ed. (2) People who repackage Fred Fish's work for a quick buck. Does The ASDG Recoverable Ram Disk Cost Anything? We'd appreciate a payment of 10 bucks sent to ASDG. This is optional, of course, but if the product saves hours of your work that would have been lost due to a guru, don't you think 10 bucks is a small price to part with? Sending a payment to ASDG also will make you registered owner of the Recoverable Ram Disk which means we'll answer your questions and keep you informed about new releases of the recoverable ram disk and other software and hardware products. People say the shareware concept is dead. I'm betting a substantial product that it isn't. Keep Shareware alive. If you find the recoverable ram disk a life saver (and you probably will), send a donation. Why Is ASDG Doing This? Several reasons: (1) I promised I would (to people on the Well) when I was developing the recoverable ram disk. (2) I am a big believer in user supported software (anyone remember Scrimper, SSV, Balls and a lot of other programs I've contributed to the public). (3) It'll demonstrate that ASDG is the only hardware house in the Amiga market with a bona-fide software expertise in house. Good hardware is good to have. But...good hard- ware with good software is *great* to have. Sorry to be so long but...watch comp.sys.amiga for the recoverable ram disk posting. Perry S. Kivolowitz ASDG Incorporated
chapman@eris.BERKELEY.EDU (Brent Chapman) (01/24/87)
In article <2445@well.UUCP> perry@well.UUCP (Perry S. Kivolowitz) writes: >Who Can Distribute This Product? > > (1) Networks and BBS's run by non-vending entities. > (2) User Groups (for non-profit benefit). > (3) Fred Fish (he...and he alone). > >Who Cannot Distribute This Product? > > (1) No vendor or hardware or software may distribute this > product under any guise or pretense. Especially you Ed. > (2) People who repackage Fred Fish's work for a quick buck. The way I read these rules, Fred is allowed to place the program one one of his disks, but my dealer is not allowed to let me make a copy of that disk, even if they don't charge me anything (a dealer is a "vendor", nyet?). Is this your intent? Note: I look forward to getting this thing, and I applaud you for releasing it (I was gonna get it when I got your new 8Meg board, but so much the better to have it now); I'm just curious about how you plan to distribute this thing. If your redistribution conditions are more restrictive than Fred's (as demonstrated above), he may be understandably unwilling to place it on one of his collection disks. Brent -- Brent Chapman chapman@eris.berkeley.edu or ucbvax!eris!chapman
spencer@eris.BERKELEY.EDU (Randy Spencer) (01/24/87)
In article <2322@jade.BERKELEY.EDU> chapman@eris.BERKELEY.EDU (Brent Chapman) writes: >In article <2445@well.UUCP> perry@well.UUCP (Perry S. Kivolowitz) writes: >>Who Can Distribute This Product? >> >> (1) Networks and BBS's run by non-vending entities. >> (2) User Groups (for non-profit benefit). >> (3) Fred Fish (he...and he alone). >> >Note: I look forward to getting this thing, and I applaud you for releasing >it (I was gonna get it when I got your new 8Meg board, but so much the better >to have it now); I was hoping to be the first to comment on this, but I am just too slow. Well, here is the official list of non-working programs to reach this node. Cleanramdisk works Cleanramdisk.info don't Deleteramdisk don't Deleteramdisk.info don't Sysmon don't Sysmon.info works Fastmem works Fastmem.info works asdg.vdisk.device don't (I think) (hard to tell) And all the stuff that wasn't uuencoded is the same. What makes me think I am right and the posting was bad? Well, all the stuff that does work. The icons that *are* pictures right next to icons that don't appear. The way that cleanramdisk brings up a window saying can't find "asdg.vdisk.device" and the other executables say "not an object module". I used the same uudecode on them all and moved them with one kermit file transfer. And of course sh never complained about checksum errors. Well, I hope that there is a repost this weekend, I have a users group meeting Monday, what a scoop for my users group. I don't mean to not thank Perry for his great (I hope) rrdisk, I will when I get my hands on a working copy. Makes sense to me! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Randy Spencer P.O. Box 4542 Berkeley CA 94704 (415)284-4740 C#(415)283-5469 I N F I N I T Y spencer%eris@berkeley.edu Now working for |||||||||||::::... . . spencer@USCVAXQ.bitnet But in no way |||||||||||||||::::.. .. . ....ucbvax!eris!spencer Officially representing ||||||||||||:::::... .. s o f t w a r e -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
g-cheng@gumby.UUCP (01/27/87)
In article <2445@well.UUCP>, perry@well.UUCP (Perry S. Kivolowitz) writes: > I plan to work on creating uuencoded shar files for the ASDG Recoverable Ram > Disk tonight. This means the net might see a posting before Friday of this > week. This is really great !!!!!!! > > What Is The ASDG Recoverable Ram Disk? > > It is an AmigaDOS device driver which implements a completely DOS compatible > (unlike ram:) disk device in memory. Unlike ram:, the ASDG recoverable ram > disk survives resets, guru's, and crashes. That is, after the guru visits, > one simply reboots to find the full contents of the ram disk still in tact. Some questions about a recoverable ram disk that survives crashes though. Assuming that before a program crashed, it wrote to the ram area occupied by the ram disk. What consequences would this have on the ram disk itself after the guru? Unless the ram memory has been write protected, wouldn't this result in inconsisten ram disk data? > > Perry S. Kivolowitz > ASDG Incorporated Chin-Long Cheng UW Madison
kaz@cadovax.UUCP (01/28/87)
In article <2323@jade.BERKELEY.EDU> spencer@eris.BERKELEY.EDU (Randy Spencer) writes: >In article <2322@jade.BERKELEY.EDU> chapman@eris.BERKELEY.EDU (Brent Chapman) writes: > (discussion about recoverable ram disk recently posted) > >Well, here is the official list of non-working programs to reach this node. > .....(list of files that worked and didn't work) > >.....and the other executables say "not an object module". >I used the same >uudecode on them all and moved them with one kermit file transfer. And >of course sh never complained about checksum errors. >Randy Spencer P.O. Box 4542 Berkeley CA 94704 (415)284-4740 C#(415)283-5469 Just thought you would like to know that I experienced the same failures when I downloaded with Kermit. Since I am new to this stuff, (uudecode kermit etc) I thought it might have been my error. Well, last night I used Xmodem to download and then I CHOPed to size. All the programs I tested that previously failed ("not an object module") now work. Is this the fault of kermit or what? Regards, Kerry Zimmerman # {ucbvax,ihnp4,decvax}!trwrb!cadovax!kaz # cadovax!kaz@ucla-locus.arpa
hamilton@uxc.cso.uiuc.edu.UUCP (01/28/87)
spencer@eris says: >I was hoping to be the first to comment on this, but I am just too slow. >Well, here is the official list of non-working programs to reach this node. > >Cleanramdisk works >Cleanramdisk.info don't >...etc... >I used the same >uudecode on them all and moved them with one kermit file transfer. And >of course sh never complained about checksum errors. i had trouble downloading asdg.vdisk.device from the vax to my amiga. i used c-kermit on the vax end, and i tried both vt100 and akermit on amy. i made repeated efforts, making sure i had binary/image mode emabled on both kermit's. i always got complaint-free transfers, but the result was always a munged file! i don't know why kermit was failing, and it makes me nervous about kermit in general. ultimately, i noticed that the corruption was starting at the same place in the file each time, so i used "dd" to chop it at that point, downloaded the pieces seperately, and used "join" to reconstruct. in the case of deleteramdisk, after the initial uudecode, the file looked like: 000003f3 hunk_header 00000000 no name 00000003 3 hunks, 00000000 numbered 0, 00000002 thru 2 00000340 1st hunk is x340 longwords (3,328 bytes) 00007c00 2nd hunk is x7c00 longwords (126,976! bytes) 00000100 3rd junk is x100 longwords (1,024 bytes) 0003e900 supposed to be 000003e9, hunk_code 00034efa supposed to be code hunk size 032c436f code ... after playing around with it, i think it was supposed to look like: 000003f3 same as before 00000000 00000003 00000000 00000002 0000030d 1st hunk is x30d longwords (3,124 bytes) 0000004d 2nd hunk is x4d longwords (308 bytes) 00000001 3rd hunk is x1 longwords (4 bytes) 000003e9 hunk_code 0000030d x30d longwords 4efa032c code ... this passes as a valid "object module", but i haven't tried running it to see if it really works. it looks to me like the file was bad BEFORE it was uuencoded; the .uu file looks fine, and part of the problem is missing, not just modified, data. thus, uu-checksums would NOT have prevented it. i haven't checked the icons yet, either. [at this point, i wonder why metacomco didn't include checksums in their object module format...] in spite of the problems, i have it running on my amiga, and it's saving me a lot of time every warm-boot. thanx perry! wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: ihnp4!uiucuxc!hamilton ARPA: hamilton%uiucuxc@a.cs.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uiucuxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton
stever@videovax.UUCP (01/30/87)
In article <1359@cadovax.UUCP>, Kerry Zimmerman (kaz@cadovax.UUCP) writes: [ discussion of problems with the ASDG Recoverable RAM Disk posting ] > Just thought you would like to know that I experienced the same failures > when I downloaded with Kermit. Since I am new to this stuff, > (uudecode kermit etc) I thought it might have been my error. > > Well, last night I used Xmodem to download and then I CHOPed to size. > All the programs I tested that previously failed ("not an object module") > now work. > > Is this the fault of kermit or what? I uploaded the files from our VAX/750 using Kermit 4D(060) on both ends (Amiga Kermit 4D(060) is by those fine fellows at the Software Distillery), in image mode (no newline-to-carriage return/line feed translation), with error checking type 3 (16-bit CRC). To ensure they were uploaded correctly, I then downloaded them back to the VAX and compared them with the originals. All files were identical. Uudecode (from Fish disk #38, I think) loved them. The resulting files appear to work correctly (I only have 512K, so won't be using the RRD very much!). Steve Rice ---------------------------------------------------------------------------- {decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever
perry@well.UUCP (01/31/87)
For the people having downloading the ASDG recoverable ram disk with kermit, please use ``set file type binary'' from within kermit. Hey the rrd works as posted (except for deleteramdisk which I reposted correctly).
stever@videovax.UUCP (02/02/87)
In article <172200029@uxc.cso.uiuc.edu>, Wayne Hamilton (hamilton@uxc.cso.uiuc.edu) writes: > . . . > i had trouble downloading asdg.vdisk.device from the vax to my amiga. > i used c-kermit on the vax end, and i tried both vt100 and akermit on amy. > i made repeated efforts, making sure i had binary/image mode emabled on > both kermit's. i always got complaint-free transfers, but the result was > always a munged file! i don't know why kermit was failing, and it makes me > nervous about kermit in general. . . . I have followed a strategy that has proven quite successful at ensuring reliable uploads from our VAX. First, I upload the file. Then, I download it *back* to the VAX and use diff to compare the original file with the doubly-copied file. With Amiga Kermit, this is easily mechanized. I have a shell script that walks a directory tree, generating a makescript for the amiga (file makescript.amiga) which creates any needed directories, a file for the Kermit "take" command (file takefile.kermit), and a parallel directory (<directory name>.check) which receives the doubly-copied files. After the files have been transferred both ways, I use the directory form of the diff command to compare all of the doubly-copied files with the original ones (note the use of "more" to control output): diff -crs <directory name> <directory name>.check | more I can begin a transfer and go to bed, secure in the knowledge that the files will be waiting for me in the morning (the last line of takefile.kermit is a "bye" command, which causes the VAX Kermit to log off when the transfer is finished). The next time I log on, I just diff the two directories, and any transfer errors are immediately apparent. This has worked for many megabytes of data. If anyone is interested in a copy of the shell script, send email to me. If I get enough requests, I will post it. Steve Rice ---------------------------------------------------------------------------- {decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever
walton@tybalt.caltech.edu.UUCP (02/05/87)
In the referenced articles, a few people complain about problems getting the ASDG RRD (and other files) into their machine. One even goes so far as to transfer all the files back to the original machine, with a diff to catch any failures. This sounds like an unnecessary waste of time to me. I think some of the problems people have been having are due to a recently reported bug in C-Kermit (used under Unix and also the basis of Amiga Kermit) which can result in a truncated transfer of a binary file. Details and a possible bug fix are in mod.protocols.kermit (Volume 6, Number 1 of the Info-Kermit Digest). Until the fix is verified, C-Kermit users had probably best send uuencoded files to their Amiga's as text and decode them there.