Available now: AmigaOS 3.1.4

[AC/DC HACKER!]

Originally Posted by Olaf Barthel

So far it seems that very few have tried the new Disk Doctor, and if they did, it may not have been much to write about

The new Disk Doctor currently does two things "only": 1) it can check if a volume is in good shape and point out defects it finds and 2) it can copy/salvage/recover files, directories, hard and soft links from a volume and store these on a different storage device.

All operations which the new Disk Doctor performs leave the volume to examine/copy from unchanged. It is completely non-destructive (unlike its "disgraced" 1980'ies precursor).

Please consider checking your hard disk partitions for defects (that is, those partitions which use FFS, DCFS or LNFS). The new Disk Doctor can detect issues which (as far as I can tell) no other tool of the same kind has paid attention to before.

I ran examine test on my SYS only so far, but will return to checking it more. It's like Pagan gifts under the tree in December (But I don't use trees anymore for years), but it's October. Ha, ha, ha, yeah, the old version was horrible. I noticed it's not destructive when I checked the arguments. The ability to copy off data reliably is like gold in the hand. Also ran DiskSalv 4, and it looks like it's out of a job... I had to pick FFS instead of Best-Guess, and during the scan a very different kind of display kept scrolling. At the end, it prompted about many errors. So... Yeah, I'll be checking DiskDoctor a bit soon.

Originally Posted by gulliver

It doesnt tolerate very long filenames, and has problems dealing with them when they are near the limits >100 characters.

Add to that the fact that it has more enforcer/muforce hits than a bad boxer.

Haw, haw, very funny analogy!

[James]

Originally Posted by gulliver

It doesnt tolerate very long filenames, and has problems dealing with them when they are near the limits >100 characters.

Ah yes, I try to avoid extremely long filenames.

Originally Posted by gulliver

Add to that the fact that it has more enforcer/muforce hits than a bad boxer.

Originally Posted by bubbob42

It also replaces icon information window with its own. Problem here: The calculated values are wrong for large harddisks. This has been fixed for the GadTools version you'll get without using RAWBinfo.

Thanks to you both for the info.

[AC/DC HACKER!]

I've had to modify some Boot Menu scripts for a Boot Menu program I use to get some games to function correctly (involved process). This update causes problems with Uropa 2 (and I haven't gone through (my games) to a large extent). So I modified a script for when the update is active and force a hard reset.

If I had the ROMs on the A4000 Motherboard I wouldn't be able to do that. I'd have to modify the a single Generic WHDLoad install. Or attempt other degrader options. So far, WHDLoad is so fantastic, it's doing well, but not having the ROMS on the Motherboard is more helpful...for now.

I'll reply more as I notice stuff. I'm not a fan of OS 3.9, I noticed way too many bugs for Games and the "Boot Menu" system I use. For loading stuff into Fast Mem like Icons, it is really sweet (fast), but I've noticed the tickles 3.5 to go faster, even when I didn't replace 68K with PPC software. When I first got my 3.9, I was impressed after BB4.. A lot faster, but Speed does not mean quality all around. That's when I decided 3.1 and 3.5 are still better in many ways. You changed the Memory Access with this update and with DOpus 5, I NOTICE it. Sometimes I use (DOpus) 4 also...see it there as well.

[pgovotsos]

With the comments about SFSsalv and the new Diskdoctor, I was wondering if Disksalv 4 will still work?

[Olaf Barthel]

Originally Posted by pgovotsos

With the comments about SFSsalv and the new Diskdoctor, I was wondering if Disksalv 4 will still work?

It should work for the file system variants it was designed for, and for the media available at the time it was released (1994). The file system variants would be OFS, FFS and DCFS, and the media would be floppy disks and desktop hard disk drives not larger than 4 GB. Larger hard disk drives were available at the time, but the Amiga could not make good use of them.

Once you go beyond the 4 GB size limit things invariably become complicated. This is one of the reasons why the new Disk Doctor was written.

The new Disk Doctor can deal with storage devices in the TB range, and in order to do that, it has to manage the data which describes what it finds on the disk in a most memory-efficient way. Finding that way was quite the challenge

Also, the new Disk Doctor has to support all three options for accessing data beyond the 4 GB barrier (the 1994 TD64 standard, the 1996 NSD TD64 standard and direct SCSI access which was the last to be added). This made for a far more complex program than I had expected it to become

The focus is on large storage media, and not so much on floppy disks. I believe DiskSalv4 has its own raw floppy disk data MFM decoder to recover information which the built-in trackdisk.device driver cannot deliver. The new Disk Doctor has no special support for floppy disks.

[kolla]

I need a history lesson - why was NSD made, when TD64 already did the job? My understanding is that NSD goes beyond what TD64 does, as it also deals with other devices.

[bubbob42]

Originally Posted by kolla

I need a history lesson

read comp.sys.amiga.*-archives - I'm sure you're going to learn a lot, not only technical stuff.

I need more popcorn.

[SaphirJD]

Why i have seen that so late... bought

[Olaf Barthel]

Originally Posted by kolla

I need a history lesson - why was NSD made, when TD64 already did the job? My understanding is that NSD goes beyond what TD64 does, as it also deals with other devices.

Um, "short" answer coming up...

NSD tried to solve a set of problems which had been dogging the Amiga for then more than a decade: how to make device drivers behave consistently and robustly, how to categorize them and how to learn about their respective abilities.

In the original operating system design the name of a device driver used to imply its purpose and functionality, e.g. serial.device, parallel.device, trackdisk.device, audio.device all say something about the kind of hardware they provide access to.

It would not last. One of the first new Commodore-made device drivers was hddisk.device which was a mass storage driver for the early bridgeboard/XT hard disks (so they named it "hard disk disk device", which isn't exactly in the same league as "trackdisk.device"). This was a driver which did what trackdisk.device could, but it was not attached to floppy disk hardware. Oops.

Then came 3rd party expansion hardware for the serial port such as the ASDG dual serial board (1988/1989?) which didn't use "serial.device" but "siosbx.device". This may have been when serial communications programs (e.g. "Diga!") had to learn not to open "serial.device" by default but to allow the user to specify what device to use. Get the name wrong and... trouble would follow.

This is the kind of trouble which NSD was trying to help to avoid. You should be able to check if the device you are going to open actually does what you expect it to. Sounds good enough? There's more. Because you couldn't expect anything at the outset because device drivers were so varied and bug-ridden, the NSDPatch program would add a layer to each known "legacy" device configured that would implement the device query method introduced by NSD and also smooth over some of the effects of implementation bugs, if possible. Such a "known problem" would be that a device driver crashes if you send it a command which it does not know, or which it misinterprets. NSDPatch tried to address such problems and (from what I can tell) had a positive impact. Still sounds good enough?

This is where the NSD idea collided at high speed with the "Trackdisk 64" standard which was already in preparation in 1993/1994. If my notes are correct, the limitations of the "scsi.device" API were already known to require a solution for large storage devices (apparently 9 GB hard disks were already available for server use in that year) and there were talks at the 1993 Orlando DevCon between the interested parties and Randell Jesup who was in charge of the "scsi.device" development at Commodore at the time. By early 1994 the TD64 standard as we know it today was finalized, but the official Commodore "scsi.device" did not include it: Commodore went over the rails in April 1994 and that was that.

NSD implemented the same command semantics as the "Trackdisk 64" standard, but with different command numbers in compliance with the command numbering scheme NSD introduced. This made sense in the context of NSD, but to say that it had repercussions would be understating it...

For example, at the time NSD was introduced the actual implementation of mass storage drivers which supported large devices would use the "Trackdisk 64" design. The NSD standard rendered these obsolete, and if I remember correctly, the NSDPatch wound up replacing these commands with the NSD versions blocking the use of the "native" Trackdisk 64 commands.

Patched versions of the FFS appeared which supported and required the Trackdisk 64 command set, which were not compatible with the NSD versions of these commands. Of course, then there was the NSD compatible version which did not support the Trackdisk 64 commands, which was then patched to support it, and things really went out of control at some point, leaving so much bad blood behind that to this day nobody involved in the affair can look back at the time without feeling at least some regrets. Something broke then which was never going to be reconciled.

So, which idea won out, eventually? NSD command support is still available in plenty of drivers written after the standard was published and it's technically a reasonable idea to implement because it adds functionality which is not available through the operating system itself (that would be exec.library). The TD64/NSD feud tarnished the NSD standard, and the issues it tried to address (introducing predictably robust device driver behaviour, categorization, query interface) are still to a large degree unresolved. Application software and file systems still seem to implement both command sets, though, but this turned out to be difficult because the Amiga device driver concept does not make it hard to implement it incorrectly. It made it hard to deal with incorrectly implemented device drivers instead.

For example, the new Disk Doctor now defaults to use the TD64 command set for large storage devices and not the NSD variant thereof because we found that some mass storage drivers will crash if you so much as send them an NSD query command. I call this a bug, but some may suspect ulterior motives (everybody likes a good conspiracy theory, and there are no known bad conspiracy theories, only boring ones).

AmigaOS 3.1.4 specifically introduced a method for allowing applications to check the file system environment data information to learn if a storage device should not be used with NSD commands, or not with TD64 commands, and with direct SCSI I/O commands instead. There didn't seem to be a robust way to address the problem created by device drivers not implementing one kind of command set, or for that matter, for not implementing any command set to access large storage media with.

This is how progress and pragmatism looks like.

[Olaf Barthel]

Originally Posted by bubbob42

read comp.sys.amiga.*-archives - I'm sure you're going to learn a lot, not only technical stuff.

Actually, I wouldn't recommend it. We cannot change the past, only how we understand it in retrospect.

What the TD64/NSD feud broke cannot be unbroken. AmigaOS 3.1.4 provided "kintsugi" by repurposing the file system device environment vector's contents to identify devices which do not support NSD or TD64. This is better than dwelling on the past.

[bubbob42]

Originally Posted by Olaf Barthel

Actually, I wouldn't recommend it. We cannot change the past, only how we understand it in retrospect.

Oh, I was only referring to the "ego" part of these historic discussions. Even back then I thought, that at some point the discussion wouldn't circle around technical aspect, but rather be about "who's right".

Sounds familiar, doesn't it?

[Olaf Barthel]

Originally Posted by bubbob42

Oh, I was only referring to the "ego" part of these historic discussions. Even back then I thought, that at some point the discussion wouldn't circle around technical aspect, but rather be about "who's right".

Sounds familiar, doesn't it?

Since most of the "discussions" were conducted online rather than face-to-face, what else would have been the most easily achievable outcome?

The discussion would have benefitted from an arbiter, such as Commodore could have been, had the the exchange occured in late 1993/early 1994.

Without the arbiter this was an exchange between peers, if you will, and the discussion inevitably ended up petering out with no definite results other than outrage, disgust and reinforcement of one own's point of view.

[LoneWolf]

My A1200 has an Idivision AGA MKII and a Blizzard 1230IV. But after installing Workbench 3.1.4 I get a software error. It only boots if I disable the 1230IV card by pressing 2 during boot.

[indigolemon]

Originally Posted by LoneWolf

My A1200 has an Idivision AGA MKII and a Blizzard 1230IV. But after installing Workbench 3.1.4 I get a software error. It only boots if I disable the 1230IV card by pressing 2 during boot.

Did you add a 68030 library, as per the FAQ?

[desiv]

Originally Posted by indigolemon

Did you add a 68030 library, as per the FAQ?

That was my thought also, although I am still a bit fuzzy on this part.
Does his Blizzard need those libraries?
I did see the FAQ, but it mentioned looking in aminet for generic libraries if there isn't one for your card...
I did some quick searches in aminet and didn't find anything, so some pointers would be great.
It installed fine for me in WinUAE, so I didn't have a problem.
I was thinking maybe it won't matter for when I get to my 1200, as I have an ACA1230 with no MMU and it installed and worked without me doing anything from animet.
Then I installed Best Workbench and I thought I saw it copy a 68030 library.
So, I guess I don't understand what those are and where they are.
Any pointers (search terms to use for aminet) would be great!

I did find this:
http://m68k.aminet.net/package/util/sys/Mu680x0Libs

But still not sure I understand it.. actually, I know I don't yet understand it and whether or not it is needed and why. ;-)

Thanx!

[wawa]

personally i wonder a bit about the necessity to have processor dedicated libraries, that is left for user to manipulate. imho the os should detect the cpu at boot and load necessary patches it sees fit. thats how aros does it. why shouldnt it be possible with amiga kickstart is not clear to me, except there are performance or other caveats i dont know of.

[LoneWolf]

Originally Posted by indigolemon

Did you add a 68030 library, as per the FAQ?

I followed the faq where it mentions to look on aminet for the propper libraries. The thing is that there are none for the blizzard 1230IV.

So tried to install the alternative that is to look for the mmulib on aminet, which I did then the installer complained about the setpach version.

[pgovotsos]

Originally Posted by LoneWolf

I followed the faq where it mentions to look on aminet for the propper libraries. The thing is that there are none for the blizzard 1230IV.

So tried to install the alternative that is to look for the mmulib on aminet, which I did then the installer complained about the setpach version.

Isn't the required driver on the P5-SCSI tools disk here?

http://amiga.resource.cx/exp/blizzard1230mk4

[DanyPPC]

On BestWB archive there are 68020 and 68030 library. I have installed both in my A1200 Blizzard030mkIV.

[AC/DC HACKER!]

@ Olaf Barthel

Maybe I'm a little ding-dong here.. I figured I'd give COPYING a shot.

DiskDoctor COPY A4K: TO SAVED:

I created a new partition from some vacant space, and formatted with Long Filename. The above line produced "Object in Use" for the destination after all the checking. Odd! I then made a folder/directory called Saved. After DiskDoctor quit.

Adjusted the argument. Ran it again. Same result. Then I added "/" to it. But usually that's not required.

DiskDoctor COPY A4K: TO SAVED:Saved/

Same thing..object in use. Next, I'll disable the "Long Filename" in RDB and see if that's it. Then reset.. Because currently, if Long Filename on my SYS: is seen as ADOS at boot. I'm going to redo the install soon with the updated script for 3.1.4..

Update: That didn't do it. I've altered the arguments again.

DiskDoctor COPY FROM=A4K: TO SAVED:

Still then same. Am I missing something? None of the other arguments looks like they'd be needed for copying existing files. There isn't a GUI to pick files from so I was thinking it would do a copy process of what it found. Hmm..but the "In Use" suggests that the "SAVED" partition is unwritable but...I'm able to make a directory/folder in it before DiskDoctor is active.

Is "FFS" as an argument required?? You made it, so you've used it. It's finding files and lists stuff very fast, I can tell it's noticing files that are there and has not reported ANY problem, so...I'm confused. I'm betting I'll type, "Duuuhh!" once you inform me. MY thought is that it's going to just copy what it's able to the destination; which is "In Use" but not.