mnib - Frequently Asked Questions

Getting mnib to work

Command Line options

Screen output


Getting mnib to work

mnib doesn't work

Please check the requirements carefully. To run mnib, you need:

Where do I get an XP1541 cable from?

You can either buy the cable(s) or build them yourself.

My XP1541 cable doesn't work

Please enter your BIOS settings and check the entry for the parallel (printer) port. Make sure that the printer port is in bidirectional mode. This should be something like ECP or EPP. A port setting of SPP will most definitely not work!

Does mnib work under Windows XP?

Most definitely NOT. mnib needs to directly access the printer port, and needs to do so in a very exclusive manner. Therefore, it turns off interrupts over a considerable amount of time. All of these things can not easily done on Windows XP, and therefore there won't be a version of mnib running on Windwos XP for quite some time.

Where do I get cwsdpmi.exe?

DJGPP can be found on any mirror. For example,, directory /pub/simtelnet/gnu/djgpp CWSDPMI can be found at the same location under v2misc or here.

Command Line options

Which settings should I use to copy original disks?

For the first attempt to read in an original disk, always use the default settings, without specifying any options on the command line. The default settings will read each track with the standard bit rate and will not read halftrack information. In my experience this is sufficient for 90% of all original disks. Specifying any options will rather harm then help with these disks.

When should I use -h (Halftracks)?

True half tracks are very rarely used as a copy protection. It is more common to use 'wide track' protection, which writes two tracks with the same information, and as a side result also writes the half track inbetween. However, to copy wide track protection you don't need the -h switch either. Basically, -h should only be used as a very last ressort (if anything else fails).

When should I use -d (scanned density)?

(Nutshell explanation) The -d flag tells mnib to go scan the track density and use the scanned value for reading out each track. This is necessary for a couple of custom disk loaders that push more information on the inner tracks of a disk than the standard Commodore format. Also, some copy protected tracks may use a non-standard density on a certain track. Only use this option if the disk disk image doesn't work otherwise. Necessary for some Epyx games (Vorpal), vmax! and Rapidlok disks (Accolade, Microprose).

(Comprehensive explanation) As Commodore disks rotate with constant speed (5 rotations per second), there's a difference in the data density you can write on the outer vs. the inner tracks of a disk. Commodore therefore uses different write densities on 1541 disks, namely:

However, this settings can be tweaked, and some software houses did this to fit more data on the upper tracks or as a form of copy protection. Namely Epyx games (Vorpal), v-max! and Rapidlok (Microprose) typically use a different write density layout.

This can be detected by mnib if you use the -d switch, like in:

mnib -d gunship.nib

Now, mnib uses the scanned track density value rather than the standard 'Commodore format' value. You can see differences in scanned vs. standard density during the nibble process, where the scanned value and the default value are printed on the screen for each track, and an arrow indicates the speed actually used.

Use the -d switch only for disks where this is necessary (see above: Vorpal, v-max!, Rapidlok, Microprose); the scan function is not 100% accurate, and for most disks using the standard density is appropriate.

Screen output

What does 'perfect match' mean?

The main difference between mnib and tools like Star Commander is that mnib reads out the low level information off a disk, whereas Star Commander reads out the high level data. As a consequence, mnib cannot use the high-level checksum mechanism for detecting, if the track read has been read out correctly: This is, because the track may not be a Commodore DOS track, but may be stored in a custom format on the disk, with custom checksumming mechanisms.

Therefore, in order to provide some kind of feedback of how reliable the read process works on the disk, each track is read several times. The resulting data from the different reads are compared to each other, and if mnib was able to read out identical data on a given track two times it is marked as a 'perfect match'. A perfect match implies that both the actual data and the length of the Synchronization Patterns found on each Sector and Sector header completely match.

What does 'match' mean?

Due to limitations of the 1541 SYNC signal lengths may slightly vary on successive reads. Therefore, it is not always possible to get a 'perfect match' for a given track. 'match' means that the actual use-data found on the track matches, but the exact length of the SYNC signal does not. Usually this isn't a problem, as the actual length of the SYNC signal is not relevant: as long as there is a minimum- length SYNC signal, the data will be read out correctly. (Sometimes the length of a SYNC signal is used for copy protection purposes: In this case, the protection verifies, that the length of the SYNC signal lies between a minimum and a maximum length. However, mnib usually is good enough for these kinds of checks regardless if it's a 'perfect match' or 'match'.)

Why don't I always get a 'match' or a 'perfect match'?

In some cases it might not even be possible to get a 'match' for a given track: Usually the data information stored on a track doesn't take up all the physical space available on the track. Therefore, at the end of each track there's a 'sector gap', which doesn't contain user data but usually holds some 'filler' data. It doesn't actually need to contain this filler data, it can also be just left unformatted. In this case, the 1541 reads garbage (random bits), which of course will never lead to a 'match' on consecutive reads.

Just in front of each SYNC signal there may be GCR data bits that do not honor the recording standards. Consider that somebody saves data on a disk (for example, a high score save file etc.). First, the 1541 drive needs to find the start of the sector to save. When the sector is found, the floppy toggles from reading mode to writing, and the actual block data is written to the track. However, on the very last bit of the write data the write head stops writing data to the track. Directly after this last bit, the old magnetic signal from the previous data is still present on the disk. However, there is a transition between new data and old data that may leaves the first bit of 'old' data in an undefined state. Therefore, this bit may very on successive reads and prevent the track from even getting a 'match'.