How to transfer AT&T 6300 ".360" disk images onto physical floppies

Question

I got these MS-DOS 3.3 disk images for the AT&T 6300 from archive.org:

• ATDOS331.360
• ATDOS332.360
• ATDOS333.360
• ATDOS334.360

Supposing that I have access to a physical 5.25″ floppy drive running on a Windows 98 machine and some disks. What is the easiest way to transfer the images onto the disks?

The files are all in ".360" format. What are the names of some utility programs that could open that format and copy it to a disk.

Really at this point I don't know if the files are just the raw disk bits or if there are headers attached to the data, which would require the use of a special program that understands such headers.

Answer 1

These are headerless sector dumps of the 360KiB disks, and can be written directly to the appropriate floppies. Since you’re using Windows 98, I suspect the best tool to do is ImageDisk.

You’ll need to convert the images first:

BIN2IMD ATDOS331.360 ATDOS331.IMD DM=5 N=40 SS=512 SM=1-9 /2

(250kbps MFM, 40 cylinders, 512 bytes per sector, sectors mapped linearly, two-sided output).

Then you can write the images to disks using IMD.

Answer 2

In general, identifying a file format by the file extension can be misleading. Many files carry an extension that does not correspond to the actual format of their contents (just for one example, many DOS executables with the extension .COM are actually in the MZ format), while some formats have no single standard extension at all. Raw disk images in particular may carry any of numerous different extensions: .IMG, .IMA, .DSK, or as we see here, .360 (I also remember seeing .720 or .144, depending on the underlying disk geometry). To discover what format a file is in, one may use a utility such as file:

$ file *.360
ATDOS331.360: DOS/MBR boot sector, code offset 0x34+2, OEM-ID "IBM  3.3", sectors/cluster 2, root entries 112, sectors 720 (volumes <=32 MB), Media descriptor 0xfd, sectors/FAT 2, sectors/track 9, dos < 4.0 BootSector (0x0), FAT (12 bit by descriptor), followed by FAT
ATDOS332.360: DOS/MBR boot sector, code offset 0x34+2, OEM-ID "IBM  3.3", sectors/cluster 2, root entries 112, sectors 720 (volumes <=32 MB), Media descriptor 0xfd, sectors/FAT 2, sectors/track 9, dos < 4.0 BootSector (0x0), FAT (12 bit by descriptor), followed by FAT
ATDOS333.360: DOS/MBR boot sector, code offset 0x34+2, OEM-ID "IBM  3.3", sectors/cluster 2, root entries 112, sectors 720 (volumes <=32 MB), Media descriptor 0xfd, sectors/FAT 2, sectors/track 9, dos < 4.0 BootSector (0x0), FAT (12 bit by descriptor), followed by FAT
ATDOS334.360: DOS/MBR boot sector, code offset 0x34+2, OEM-ID "IBM  3.3", sectors/cluster 2, root entries 112, sectors 720 (volumes <=32 MB), Media descriptor 0xfd, sectors/FAT 2, sectors/track 9, dos < 4.0 BootSector (0x0), FAT (12 bit by descriptor), followed by FAT

If file outputs ‘DOS/MBR boot sector’ it is probably safe to assume that it is a raw sector image of either an MBR-partitioned disk or a FAT floppy. Some particularly old raw disk images may fail to be detected by this method, though: as raw images have no discriminating signature of their own, they have to be identified by the signature of the contained file system, but sufficiently old FAT versions do not have those either. The worst-case scenario is that file outputs ‘data’ or something completely bogus, like ‘dBase III DBT’.

For disk images in particular, utilities from the LIBDSK project may be helpful. Among them there is dskid, which can identify both the underlying low-level disk format (i.e. the way the surface of the disk is supposed to be divided into sectors) and the container format of the file (called a ‘type’ by LIBDSK to distinguish it from the former). Although this one in turn may be too eager to identify files as raw images; it will do so for any image type that LIBDSK does not support.

LIBDSK also includes dskdump, dsktrans and dskconv, which can transfer sectors from one container format to another, and even to and from a physical disk drive. There is source code and binaries for DOS and for Windows available to download (and they do run under Windows 9x too).

Answer 3

Those are raw disk images. No special software is needed. You can use the DEBUG program - a part of DOS - to load the image from file to memory, and then to write it out to disk. I do suggest you try it out using either actual MS-DOS or FREEDOS, or by rebooting into DOS mode from Windows.

Within debug, it’d go something like:

N atdos331.360 - set the file to load from, you should start debug in the folder containing that file
L - load the file starting at CS:0100
R - show registers to check that the BX:CX pair has the number of bytes read as expected (360k = 720*512, so BX:CX=5:A000)
W 100 0 0 2D0 - write from CS:0100 to drive 0 (A:) starting at sector 0, a total of 720 (2D0) sectors

I don’t recall at the moment whether DEBUG starts with a suitable value of CS, but I presume it should - ie. CS must be just above debug’s own memory area. You’ll have no problem fitting 360k worth of data into the available space.