bruce@ektools.UUCP (Bruce D. Nelson ) (07/10/87)
Simon Poole's program, DLII.ARC was recently posted on GEnie. Last night, the
GEnie sysops purged it, and left a main banner message saying, in part, that
bugs had been reported in it and that they urged users who d/l'ed it to
destroy their copies.
As DLII was the answer to my many queries on the net about a "chkdsk" for the
ST (and, BTW, it DID fix the disk I needed to have fixed), I'd like to find
out when another version might be forthcoming.
Simon, thanks for the nice program. I hope you can work out the tangles that
made the GEnie people nervous.
Bruce D. Nelson, Sr. Appl. Analyst: Software Maint., Tech. Support Svcs.
EASTMAN KODAK COMPANY, 901 Elmgrove Rd., Rochester, NY 14650, (716)726-7890
UUCP: {allegra, seismo}!rochester!kodak!ektools!bruce
ARPA: kodak!ektools!bruce@rochester.ARPAat@laura.irb.informatik (Andreas Toenne) (07/11/87)
In article <736@ektools.UUCP> bruce@ektools.UUCP (Bruce D. Nelson ) writes: >Simon Poole's program, DLII.ARC was recently posted on GEnie. Last night, the >GEnie sysops purged it, and left a main banner message saying, in part, that >bugs had been reported in it and that they urged users who d/l'ed it to >destroy their copies. > ... >Simon, thanks for the nice program. I hope you can work out the tangles that >made the GEnie people nervous. I wonder what the bugs are ??? I like DLII but I'm getting very nervous too if this program is really capable of munching my precious data. Andreas Toenne CS Dept. U of Dortmund, W-Germany at@unido.uucp toenne@unido.uucp at@unido.bitnet D
bammi@cwruecmp.UUCP (07/11/87)
In article <736@ektools.UUCP> bruce@ektools.UUCP (Bruce D. Nelson ) writes: >Simon Poole's program, DLII.ARC was recently posted on GEnie. Last night, the >GEnie sysops purged it, and left a main banner message saying, in part, that >bugs had been reported in it and that they urged users who d/l'ed it to >destroy their copies. Can you post a copy of the banner. What bugs were found?? Last night i run DLII and REORG (after backing up of-course!) on my hard disk (5-5-10 partitions, on an old Atari SH212 drive/supra autoboot driver, with Landon Dyers foldrxxx and beckmeyer diskcache) and it did the job perfectly. >As DLII was the answer to my many queries on the net about a "chkdsk" for the >ST (and, BTW, it DID fix the disk I needed to have fixed), I'd like to find >out when another version might be forthcoming. > >Simon, thanks for the nice program. I hope you can work out the tangles that >made the GEnie people nervous. I second the Kudos to Simon for another very nice program. Look forward to new versions. -- usenet: {decvax,cbosgd,sun}!cwruecmp!bammi jwahar r. bammi csnet: bammi@cwru.edu <---------Please note change of address arpa: bammi@cwru.edu <---------Please note change of address compuServe: 71515,155
dclemans@mntgfx.MENTOR.COM (Dave Clemans) (07/14/87)
About bugs in DLII: I encountered the following problem, using DLII_024.arc from genie. I unpacked the archive into a 800K ramdisk (within a four megabyte 520, so there was no problem with running out of memory), and then ran reorg.prg. At no time did I tell reorg to actually start doing some reorganization; I just got to it's "desktop" and immediately exited. Before I ran reorg, counting the unpacked DLII archive, there was about 500K worth of stuff in the ramdisk; afterwards there was nothing whatsoever. This would make it seem that DLII/reorg has a major bug that's either related to ram disks in some strange way, or with disks that have a 12 bit FAT table. dgc
neil@atari.UUCP (Neil Harris) (07/15/87)
In article <2173@cwruecmp.UUCP>, bammi@cwruecmp.UUCP (Jwahar R. Bammi) writes: > > Can you post a copy of the banner. What bugs were found?? Last night > i run DLII and REORG (after backing up of-course!) on my hard disk (5-5-10 > partitions, on an old Atari SH212 drive/supra autoboot driver, with Landon > Dyers foldrxxx and beckmeyer diskcache) and it did the job perfectly. Actually, we on GEnie did not find bugs, it was simply that we were told that the version we had posted contained 10 known bugs. Since then, a later version was posted which is available to the public. -- --->Neil Harris, Director of Marketing Communications, Atari Corporation UUCP: ...{hoptoad, lll-lcc, pyramid, imagen, sun}!atari!neil GEnie: NHARRIS/ WELL: neil / BIX: neilharris / Delphi: NEILHARRIS CIS: 70007,1135 / Atari BBS 408-745-5308 / Usually the OFFICIAL Atari opinion
K538915@CZHRZU1A.BITNET (07/17/87)
dgc (whoever that may be) writes: >About bugs in DLII: > >I encountered the following problem, using DLII_024.arc from genie. > >I unpacked the archive into a 800K ramdisk (within a four megabyte 520, ^^^^^^^^^^^^^^^^^ This is something I can't check (but I would like to be able to *GRIN*) >so there was no problem with running out of memory), and then ran reorg.prg. >At no time did I tell reorg to actually start doing some reorganization; >I just got to it's "desktop" and immediately exited. Before I ran reorg, >counting the unpacked DLII archive, there was about 500K worth of stuff >in the ramdisk; afterwards there was nothing whatsoever. > Since ReOrg does not write to the disk AT ALL before you explicitly tell it to do so, the loss of the ramdisk contents is not a result of ReOrg making a mistake while writing to disk. > >This would make it seem that DLII/reorg has a major bug that's either >related to ram disks in some strange way, or with disks that have >a 12 bit FAT table. > >dgc > It is surely NOT related to FAT's with 12 bit entries, as this is the same format floppys and all ramdisks I know about use. Possibly your problem was related to one of these: -Not reading the handbook before using ReOrg and not using the diskcheck function of DLII before using it. -Your ramdisk has some special charateristics, which make it incompatible with normal disks. If you can send me a copy of the ramdisk you use, I can try and see if I can find the cause of all this trouble. DL II/ReOrg Status ------------------ People which have actually read the copyright notice on DL II and ReOrg will have noticed that there is NO clause allowing these programs to be duplicated or distributed without my consent. But since the current version (0.24) is in every sense still a beta-test version, I've got nothing against it floating around a bit (it would be impossible to stop anyway). Things that still have to be done before I'll even start thinking about releasing it officially are: -finsh the handbook -cleanup the user interface -get rid of all remaining bugs. Simon Poole K538915@CZHRZU1A.BITNET PS: Please send bug reports to my address and not to the net, if possible (and I would like to know what the '10 known bugs' are/were)! PPS: How much longer is imminent? PPPS: YAWN! (02.27!)
dclemans@mntgfx.MENTOR.COM (Dave Clemans) (07/17/87)
Someone asked a question about taking an ST to 4 megabytes, so here goes: To get to 4 megabytes, I installed an Aerco memory board into my ST (the Aerco board is also what is distributed by the E. Arthur Brown mail-order company). If it's relevant, I have a very early ST (with a rev A board). The Aerco board can be used to take a 520 to 1 megabytes, 2.5 megabytes or 4 megabytes. Going to 1 or 2.5 megabytes everything is solderless; to go to 4 megabytes requires significant soldering on the memory daughter board, but no soldering to the ST itself. The Aerco board connects to the ST at three points. First, the MMU chip is removed from it's motherboard socket, and placed in a seperate socket on a small piggyback board. That piggyback board then plugs into the mmu socket, and also to the memory daughter board. The memory board connects at two other points to the ST mother board, using clips that fit over two data bus buffer chips. Provided that the 1040/520STFM board layout uses the same two buffer chips to handle the memory data lines, and those buffer chips are in approximately the same relative location to the mmu socket as on the 520ST motherboard, the Aerco memory board could also be used on the 1040/520STFM. To be able to reach 4 megabytes without doing any soldering on the ST's motherboard changes are made on the piggyback board mentioned above so that none of the control signals from the mmu that are meant to go to the ram array reach the motherboard; they only go to the memory daughter board. The board has worked very solidly for me. dgc
frans@philmds.UUCP (Frans Meulenbroeks) (07/21/87)
Has anyone considered the following: Build a piggyback board (a la Airco board), that will pass all references to the lower 1MB to the ST's motherboard, and reroute references to the next 3 MB. Then it would be possible to enlarge the memory of the ST without discarding the memory that is already present. I know that the extra chips might give a problem with the power supply. Is this feasible?? Or is it impossible due to timing problems? -- Frans Meulenbroeks Philips Distributed Realtime Multiprocessor System uucp: for the time being: philmds!frans sometime in the future: phildr2!frans