OK, I get the idea - lacking in description. No problem.....
A little background
Back in 2011 when I first started this thing, the prevailing paradigm for moving files from one disk image to another (e.g. a DFS SSD file to an ADFS ADF file) was to open a program, load the SSD, export the file (complete with INF), then close that, open a different program, load the ADF, import the file (INF and all), and then close it.
To my mind this seemed silly: the file is the same thing to both systems, so why can't be directly transferred? I envisioned something like an FTP client. In this model, you have "local" (your computer) on the left, and "remote" (the site you're dealing with) on the right. Then you can copy files back and forth as required.
So I came up with this:
(Couple of notes: yes, that's the hard drive image found elsewhere on this forum - NUTS can handle it because it doesn't load images into memory, it operates on them directly. Yes, that's fake directories in a DFS disk image. It just makes the whole thing work more intuitively that way. There's going to be a FAQ entry in the documentation explaining this....)
The Application
So here we have a DFS image on the left, and an ADFS hard disk (Risc OS) on the right. Should you so desire you can just select something on the left, hit "Copy" and off it goes. No intermediate step. (In fact, if such a file is under 4MB the "holding store" for the data in transit is in RAM).
OK, so that's the basic idea. Here's what makes it different: everything uses the "agnostic" idea of where stuff is. So for example, the ADFS (Old Map) file system handler works equally well on an ADF/ADL image, as it does directly accessing a CF card. It's the same code that runs, because the data
source is separated from the file system.
At present, while there *is* support for floppy drives, it's the standard Windows API, so your mileage will be crappy. But in theory, it'll work.
The whole system is plugin-based, so you could (for example) implement a plugin that provides access to a Kryoflux device, without having to write any file system code. The existing FS handlers will work with the data source component.
So here's a run down on the "killer" (lol) feature list:
* Support for a wide variety of Acorn/Risc OS file systems, Commdore D64s, AmigaDOS, AMSDOS, +3DOS, TRD, TZX, TAP, CDT, and so on.... there's quite a few filesystems in there, some more complete than others.
* Support for "wrappers" - data sources that implement some container over the filesystem. For example, you can (if you feel inclined) put a Risc OS 800K E disk image inside a CPCEMU DSK file.
* Support for unusual types inside other containers (internally called the "Foreign Object Protocol"). For example, you can created Risc OS ISO images that respect the ! naming, along with file types.
* Icon resolving: Where native use of a file system would show custom icons under the right circumstances, NUTS will too (turned off by default because it usually involves extra processing).
* Image "Install": Copies the contents of an image to another file system in one click.
* Tape image player: Plays back files such as TZX and TAP as the audio that they represent. (UEF to come when I figure out the most intuitive way to do it).
* Translators: Read, save, tweak and print images (of the graphic kind), text (including tokenised BASIC) and audio from selected formats.
* Font system: Original characters are faithfully reproduced by using the original font associated with objects. In the screenshot above, you can see the "BBC Micro" font in use for the SSD, while "Risc OS" is in use for the ADFS hard drive. There is not much difference between them, but they do put some characters in different places, especially above ASCII 126. Notably, the £ sign is in a different place.
* Deals with INF files
* Allows image nesting: you can modify the contents of a Risc OS Sprite file while it's inside an ADF image inside a ZIP file without extracting anything (though depending on container sizes and nesting level, it may be slow to do).
* Imaging Wizard: Sector-by-sector copy of a filesystem from one source to another (again, due to the crappy Windows floppy drive support this is unlikely to be of major use until a decent floppy interface/driver plugin appears).
* Image repair tools (selected file systems)
And there's probably more.
But that's all I could manage in 12 years with some considerable breaks.
Any questions?
