Erik-jan.Vens@samba.acs.unc.edu (Erik-jan Vens) (11/15/90)
My friend Tom Hageman, author of a good many UN*X utilities, has also written a good resetable, resizable, configurable RAMdisk. Tom is sort of a guru in our local Atari community and we are thinking about releasing all his programs in the public domain. They already are really, but they are not on the net. He has also done a port of JOVE (Jonathan's Own Version of Emacs) which in fact should be called TOVE (Tom's...) because it has almost nothing to do with the original JOVE anymore. Sourcewise that is. It is completely bugfree, well improved and runs on Atari ST, MSDOS, UNIX (diff.t flavours). Anyway, since the RAM disk topic came up, I could as well submit his RAMRESIZ for release on the net. I do seem to remember that comp.binaries.atari.st is a moderated newsgroup. Can anyone tell me how to submit? Erik-Jan. Vens@Rug.NL
entropy@mole.ai.mit.edu (Nick Castellano) (11/16/90)
In article <1642@beguine.UUCP> Erik-jan.Vens@samba.acs.unc.edu (Erik-jan Vens) writes: >My friend Tom Hageman, author of a good many UN*X utilities, has also >written a good resetable, resizable, configurable RAMdisk. Tom is sort >of a guru in our local Atari community and we are thinking about >releasing all his programs in the public domain. They already are >really, but they are not on the net. > >He has also done a port of JOVE (Jonathan's Own Version of Emacs) which >in fact should be called TOVE (Tom's...) because it has almost nothing >to do with the original JOVE anymore. Sourcewise that is. It is >completely bugfree, well improved and runs on Atari ST, MSDOS, UNIX >(diff.t flavours). Great! I'll be looking forward to seeing them. Especially Jove, since the current port to the ST is a bit screwy. >Anyway, since the RAM disk topic came up, I could as well submit his >RAMRESIZ for release on the net. I do seem to remember that >comp.binaries.atari.st is a moderated newsgroup. Can anyone tell me how >to submit? If your news software is properly configured, posting to the newsgroup should automatically mail it to the moderator. Just arc (or zoo) it, uuencode it, and post it. Alternately, mail it to koreth@panarthea.ebay.sun.com, who is the moderator. >Erik-Jan. Vens@Rug.NL Nick -- | | | entropy@mole.ai.mit.edu | | | ncastellano@{eagle.wesleyan.edu, wesleyan.bitnet} / | \ Sinkhole!dEADHEAd[@mast.citadel.moundst.mn.org] (call 203-873-8518) / | \
asplundm@physc1.byu.edu (06/19/91)
I am presently using EDISK on my ST, and I love the reset-proofness of it, but I find it annoying that I can't change Ram Disk sizes without a cold re-boot. Can anybody either tell me what I am doing wrong, or tell me about a better program? Matt Asplund BYU Provo UT
wabe@ukc.ac.uk (W.A.B.Evans) (06/25/91)
In article <310asplundm@physc1.byu.edu> asplundm@physc1.byu.edu writes: >I am presently using EDISK on my ST, and I love the reset-proofness of it, >but I find it annoying that I can't change Ram Disk sizes without a cold >re-boot. Can anybody either tell me what I am doing wrong, or tell me about >a better program? > >Matt Asplund >BYU >Provo UT As far as I am aware, ALL reset proof ramdisks involve a RESET if they are resized. In this EDISK is no exception. However the main point of this reply is to draw your attention to Mark Williams Co.'s RDY ramdisk utility that is now PUBLIC DOMAIN - even if you are not a registered licensee of Mark Williams "C". This is FAR more sophisticated than EDISK (I am familiar with both!) - in that it allows you to configure Reset-Proof ramdisks that are Booting or non-booting and you can simultaneously load as many ramdisks as memory and/or volume letters (C:\,D:\,....P:\) allow. You may also configure the ramdisk to have the FAT structure of a FLOPPY so you can SECTOR-copy the entire contents of floppies quickly onto them (using DFT.PRG - a program within DFSUITE2 - also available on the network) - or you may use 16-bit FATS for additional access speed. Further they may be saved WITH CONTENTS to .PRG files on floppy or hard disks and loaded again with ease by simply executing them. As Mark Williams reputedly no longer write software for the ST, there was a hiccup when I tried to use my old RDY installations on a new STE. I looked into the problem, to discover it was to do with the RESET VECTOR not being correct for the STE. A minor hack produced RDE.PRG - the STE-compatible version of Mark Williams' RDY.PRG - which, with Mark Williams Co.'s permission, was distributed on atari.binaries.st last January or early February. This has solved similar problems for many who recently "upgraded" to an STE - as is testified by the many Emails I've received. One further advantage is that saved RDY ".PRG" files may be packed with an efficient packer (like PFXPAK - also PUBLIC DOMAIN) that makes them extremely economical to store on Floppy. Working this way with a 4-Mbyte STE I can load many different utilities on different ramdisks simultaneously and have not so far felt the need for expensive error-prone hard-disks. Anyway, hope this may help some readers. W. Alan B. Evans [ wabe@ukc.ac.uk ] P.S.: Whilst EDISK is not as sophisticated as RDY/RDE, it is excellent as a SINGLE reset proof ramdisk. It works equally well on the new TOS as well as the older versions - which means it "looks up" the proper RESET VECTOR, *((long *)0x4), in Supervisor Mode before executing it - which was the fault with RDY (or at least the version of RDY I was given when I upgraded to Mark Williams "C" version_3.0.6). When I upgraded I never was given the sourcecode of this "newer" RDY that worked satisfactorily on 4Mb machines (presumably there was insufficient space on the upgrade disk) - so I would be obliged if anyone who bought version 3.++ of Mark Williams "C" and who presumably got this "updated sourcecode" - which is now also PUBLIC DOMAIN (or so I learn from a FAX from Mark Wms' Dale Schumacher - but I don't really know where to access it) could be bothered to Email me this. True I could probably get it from Mark Wms. Co. also - but, as they've left the ST-scene, let's not bother them. I would then, I believe, be able to modify it so that a single RDY.PRG would work (like EDISK) on all ST machines - the only slight doubt is whether there is enough room in the bootsector of a self-loading RDY ramdisk to include the few bytes of additional code required to "look-up" the reset address vector before using it.