Just Solve the File Format Problem - User contributions [en]

CP2

2025-07-04T21:20:29Z

John e: /* File structure */

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
|extensions={{ext|cp2}}
}}
'''CP2''' is a disk image format created by the commercial disk copier Copy-II-PC in conjunction with a separate program, Snatch-It.

== Identification ==
The first 24 bytes of the file are ASCII 'SOFTWARE PIRATESRelease '.

== File structure ==
Files begin with a 30-byte header:
<pre>
+0x00 DB 'SOFTWARE PIRATES'
+0x10 DB 'Release '
+0x18 DB release (printable ASCII)
+0x1C DB '$'
+0x1D DB volume number (ASCII, starting with '0')
</pre>
Following the header will be one or more segments, each 64k or less in size. A segment is formed:
<pre>
+0x00 DW segment header length, little-endian word.
+0x02 DB cylinder
+0x03 DB head
+0x04 DB sector
+0x05 Sector headers, 384 bytes per track.
DW length of sector data
DB sector data
</pre>
To find the sector data length and sector data, take the offset in the file of the segment header and add the segment header length + 2. This address may overlap with the end of the last sector header.

A sector header is 16 bytes:
<pre>
+0x00 DB read result
+0x01 DB 8272 status register 0
+0x02 DB 8272 status register 1
+0x03 DB 8272 status register 2
+0x04 DB Sector ID: cylinder
+0x05 DB Sector ID: head
+0x06 DB Sector ID: sector
+0x07 DB Sector ID: size (0 for 128 bytes, 1 for 256 bytes, 2 for 512 bytes etc.)
+0x08 DW Offset to sector data from start of sector data area + 0x16AD
</pre>
To find the actual offset of a sector in the file, take its offset value in the header, subtract 0x16AD, and add the offset to the address of the sector data as determined from the segment header.

== Software ==
* [h ttps://github.com/retrohun/pce/blob/master/src/drivers/psi/psi-img-cp2.c PCE] contains some code to parse .CP2 disk images.

== Sample files ==
* ht tps://discmaster.textfiles.com/browse/29984/wbiz0000-0009/wbiz0008.tar/wbiz0008

CP2

2025-07-04T16:42:30Z

John e: /* File structure */

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
|extensions={{ext|cp2}}
}}
'''CP2''' is a disk image format created by the commercial disk copier Copy-II-PC in conjunction with a separate program, Snatch-It.

== Identification ==
The first 24 bytes of the file are ASCII 'SOFTWARE PIRATESRelease '.

== File structure ==
Files begin with a 30-byte header:
<pre>
+0x00 DB 'SOFTWARE Pirates'
+0x10 DB 'Release '
+0x18 DB release (printable ASCII)
+0x1C DB '$'
+0x1D DB volume number (ASCII, starting with '0')
</pre>
Following the header will be one or more segments, each 64k or less in size. A segment is formed:
<pre>
+0x00 DW segment header length, little-endian word.
+0x02 DB cylinder
+0x03 DB head
+0x04 DB sector
+0x05 Sector headers, 384 bytes per track.
DW length of sector data
DB sector data
</pre>
To find the sector data length and sector data, take the offset in the file of the segment header and add the segment header length + 2. This address may overlap with the end of the last sector header.

A sector header is 16 bytes:
<pre>
+0x00 DB read result
+0x01 DB 8272 status register 0
+0x02 DB 8272 status register 1
+0x03 DB 8272 status register 2
+0x04 DB Sector ID: cylinder
+0x05 DB Sector ID: head
+0x06 DB Sector ID: sector
+0x07 DB Sector ID: size (0 for 128 bytes, 1 for 256 bytes, 2 for 512 bytes etc.)
+0x08 DW Offset to sector data from start of sector data area + 0x16AD
</pre>
To find the actual offset of a sector in the file, take its offset value in the header, subtract 0x16AD, and add the offset to the address of the sector data as determined from the segment header.

== Software ==
* [h ttps://github.com/retrohun/pce/blob/master/src/drivers/psi/psi-img-cp2.c PCE] contains some code to parse .CP2 disk images.

== Sample files ==
* ht tps://discmaster.textfiles.com/browse/29984/wbiz0000-0009/wbiz0008.tar/wbiz0008

CP2

2025-07-04T16:38:56Z

John e: Created page with "{{FormatInfo |formattype=electronic |subcat=Disk Image Formats |extensions={{ext|cp2}} }} '''CP2''' is a disk image format created by the commercial disk copier Copy-II-PC in ..."

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
|extensions={{ext|cp2}}
}}
'''CP2''' is a disk image format created by the commercial disk copier Copy-II-PC in conjunction with a separate program, Snatch-It.

== Identification ==
The first 24 bytes of the file are ASCII 'SOFTWARE PIRATESRelease '.

== File structure ==
Files begin with a 30-byte header:
<pre>
+0x00 DB 'SOFTWARE Pirates'
+0x10 DB 'Release '
+0x18 DB release (printable ASCII)
+0x1C DB '$'
+0x1D DB volume number (ASCII, starting with '0')
</pre>
Following the header will be one or more segments, each 64k or less in size. A segment is formed:
<pre>
+0x00 DW segment header length, little-endian word.
+0x02 DB cylinder
+0x03 DB head
+0x04 DB sector
+0x05 Sector headers, 384 bytes per track.
DW length of sector data
DB sector data
</pre>
The length

A sector header is 16 bytes:
<pre>
+0x00 DB read result
+0x01 DB 8272 status register 0
+0x02 DB 8272 status register 1
+0x03 DB 8272 status register 2
+0x04 DB Sector ID: cylinder
+0x05 DB Sector ID: head
+0x06 DB Sector ID: sector
+0x07 DB Sector ID: size (0 for 128 bytes, 1 for 256 bytes, 2 for 512 bytes etc.)
+0x08 DW Offset to sector data from start of sector data area + 0x16AD
</pre>
To find the actual offset of a sector in the file, take its offset value in the header, subtract 0x16AD, and add the segment header length +

== Software ==
* [h ttps://github.com/retrohun/pce/blob/master/src/drivers/psi/psi-img-cp2.c PCE] contains some code to parse .CP2 disk images.

== Sample files ==
* ht tps://discmaster.textfiles.com/browse/29984/wbiz0000-0009/wbiz0008.tar/wbiz0008

Disk Image Formats

2025-07-04T16:21:00Z

John e:

{{FormatInfo
|formattype=electronic
|thiscat=Disk Image Formats
|image=Selanit floppy disk download icon.png
}}

[[Filesystem]]s and other file formats described on this page's parent page describe entities that exist on disks as they would normally be used.

However, there are also file formats that allow a physical disk (or tape or other medium) to be "imaged" into a file, either to be re-copied onto a physical disk later, or else used by an *emulator* of the computer system that would have originally used that sort of media.

These file formats represent a data image of one of the physical floppy disk (etc.) formats. In addition to the raw data from the disk/tape/etc, these formats may contain metadata that the corresponding emulator environment uses to correctly access the data.

Typically, when archiving a physical disk for later use, a physical disk will be imaged into one of these file formats. Sub-pages of this page should contain information on the format itself as well as instructions on how to extract a physical disk into that disk image format, including information about what physical drives are required, what software to use and how and what OS that is run under.

See also [[ROM and memory images]] for images of memory, and [[Floppy disk]]s for the physical floppies. See [[Archiving]] for archive and backup formats that are filesystem-based rather than raw-sector-based. See [[Filesystem]] for the filesystems. [[Forensics and Law Enforcement]] has formats for preserving drive contents with metadata for investigations.

==Floppy Disk Image Formats==
Images created directly from floppy disks.
===Generic Sector Images===

====Acorn====

* [[Acorn Archimedes Disk Image]]

====Amiga====

* [[ADF (Amiga)]]
* [[Disk Imploder]] (Amiga) (.dmp, .dex)
* [[Disk Masher System]] (Amiga) (.dms)
* [[WRP]]

====Amstrad====

* [[DSK (CPCEMU)]], used for Amstrad and related disks (typically [[3" disk]]s)

====APF Imagination Machine====

* [[APD]] (APF Imagination Machine emulated disk) (.apd)

====Apple II series====

* [[A2R disk image]]
* [[Apple Disk Image]] (Apple II disk image with header) (.2mg)
* [[Disk Copy 4.2]] (Apple)
* [[Disk Copy 6]] (Apple)
* [[DSK (Apple II)]], used for Apple II disks (typically 5.25" disks)
* [[EDD disk image]]
* [[Nibblized disk image]] (.nib), an Apple II disk image format that works for copy-protected disks
* SDK - See [[NuFX]].
* [[WOZ disk image]]

====Atari====
===== Atari 8-bit =====
* [[ATR]] (SIO2PC)
* [[DCM]] (Disk Communicator)
* [[DI]] (800XL DJ emulator)
* [[PRO]] (APE ProSystem)
* [[SCP]] (Spartados)
* [[XFD]] (Xformer)
===== Atari ST =====
* [[DIM]] (F-Copy)
* [[The JAM Packer]]
* [[MSA (Magic Shadow Archiver)]]
* [[ST disk image]]
* [[STT]] (STEEM)
* [[STX]] (Pasti)

====Commodore 64/128/PET/CBM====

* [[C64 Nibbler Format]] (.nib) (created by mnib)
* [[D64]] and its variants (D71, D81, all with optional error information) from the C64
* [[G64]] C64 raw (GCR coded) disk image

====Macintosh====

* [[Apple Disk Image]] (MacOS or OS X disk image with header) (.dmg, .smi, .img)
* [[DART]] (Apple)
* [[MOOF]]
* [[Sparse image]] (Apple disk image) (.sparseimage)

====MSX====
* [[PDI]] (Protected Disk Image)

====PC (DOS/Windows)====

* [[86F]] (86Box)
* [[ApriDisk]]
* [[CP2]] (Snatch-It / Copy-II-PC)
* [[CFI disk image]]
* [[CopyQM]]
* [[DDI]] (DiskDupe image file)
* [[Disk Express]] (.dxp)
* [[DSQ (disk image)|DSQ]]
* [[FDF Image]] (EZ-DisKlone)
* [[FDI]] (Formatted Disk Image)
* [[IMA]]
* [[IMD]] (ImageDisk)
* [[IMG (DOSIMG)|IMG]] (HD-Copy disk image)
* [[LoadDskF/SaveDskF]] (.dsk)
* [[Quick Release Sector Transfer]] (Compaq)
* [[RIM]] (EZ-DiskCopy PRO)
* [[SXD (Sydex)|SXD]] (CopyQM Plus)
* [[TD0]] (TeleDisk)
* [[XPACK disk image]] (.xdi)

====Tandy====

* [[DMK]]
* [[JV1/JV3]]
* [[JVC]]

====ZX Spectrum====
* [[Mirage Microdrive Snapshot]]
* [[TRD]] (see [[TR-DOS filesystem]])

====Misc.====
* [[Anex86 PC98 floppy image]] (.fdi)
* [[D88]] (.d88, .1dd, .2dd)
* [[DiscFerret floppy image]] (.dfi)
* [[DSK (Oric)]]
* [[Famicom Disk System]] (.fds)
* [[LDBS disk image]] (.ldbs)
* [[MESS floppy image]] (.mfi)
* [[Pasopia disk image]] (.d88)
* [[Raw disk image]] (.img) (ie, created with dd)
* [[Compressed Hunks of Data]] (.chd)
* [[SD HxC Floppy Image]] (.hfe) [https://hxc2001.com/download/floppy_drive_emulator/SDCard_HxC_Floppy_Emulator_HFE_file_format.pdf 1]
* [[SuperCard Pro]] (.scp)
* [[Wang Virtual Disk image]] (.wvd)

===Physical (Hardware) Images===

* [[DRAFT]] (Software Preservation Society intermediate format)
* [[IPF]] (Software Preservation Society image format)
* [[KryoFlux]]

==Optical Disc Image Formats==
CD-ROM, DVD-ROM, BluRay, GD-ROM etc. For the physical formats, see [[Optical Discs]].

* [[BlindWrite Image File]] (.bwi, .bwt, .b5i, .b6i) [https://en.wikipedia.org/wiki/BlindWrite wiki]
* [[CDI]] (Disc Juggler)
* [[CloneCD Control File]] (.ccd, .img, .sub)
* [[C2D]] Roxio
* [[CIF Image]] Roxio
* [[CUE and BIN]]
* [[CyberLink P2I]]
* [[DDP]] (Disc Description Protocol)
* [[DMG]] (Apple)
* [[Domesday Duplicator]] (.lds, .ldf, .raw)
* [[GI]] (Sonic Global Image File)
* [[ISOBuster Managed Image]] (IBP/IBQ)
* [[ISO image]] (.iso)
* [[ISZ]]
* [[MDF and MDS]]
* [[NRG]] (Nero Burning ROM)
* [[NTI CD Image]] (.ncd) [https://archive.org/download/nti-cd-maker-standard-edition-full-version-5.0.11-2001/NTICDM2K.iso/CDM2K%2FManual%2FEnglish%2FManual.pdf 1]
* [[TOAST]] (Roxio Toast)
* [[XDI (Extended Disc Image)]]
* [[TOC]] (CDRDAO)

===Optical Disc Project Formats===
Disc Burning Software Project files

* [[Nero Burning ROM]]
** [[NRI]] (CD-ROM Compilation)
** [[Nero CoverDesigner]]
** [[NSD]] Super VCD Compilation
** [[NRV]] Video CD Compilation
** [[NRE]] CD Extra Compilation
* [[CDL]] (Corel CD Creator)
* [[Easy CD Creator]] (CL2, CL3, CL4)
* [[CL5]] (Roxio EasyCD Creator 5)
* [[RCL]] (Roxio Creator Classic)
* [[ROXIO]] (Roxio Creator Classic/Easy Media Creator)
* [[ROX]] (Roxio Creator NXT)
* [[DMSD]] (Roxio MyDVD)
* [[DISC]] (Roxio TOAST)
* [[DVD Sonic]] (Sonic myDVD .dvd)
* [[NTI CD-DVD Maker]] (.cmd)
* [[Adobe Encore]] (.ncor)
* [[DVD Studio Pro]] (.dspproj)
* [[iDVD]] (.dvdproj)
* [[CyberLink Power2Go]]
* [[CD Architect]] (.cdp)
* [[DVD Architect]] (.dar)

==Hard Disk Image Formats==

* [[Ghost Image]] (.gho, .ghs)
* [[HDV (disk image)|HDV]]
* [[Raw disk image]] (.img)
* [[TeraByte Image]]

==Virtual Machine Disks and Virtualization Image Formats==
* [[OVF (Open Virtualization Format)]]
* [[qcow]] (QEMU)
* [[VDI]] (Virtual Disk Image) (VirtualBox) (.vdi)
* [[VFD (Virtual Floppy Disk)]] (Microsoft) (.vfd)
* [[VHD (Virtual Hard Disk)]] (Microsoft) (.vhd)
* [[VMDK]] (Virtual Machine Disk) (VMWare) (.vmdk)

==Tape Image Formats==

* [[APT (APF Imagination Machine)|APT]] (APF Imagination Machine emulated tape, logical bits) (.apt)
* [[APW]] (APF Imagination Machine emulated tape, raw audio) (.apw)
* [[CAS (Atari)|CAS]] (Atari; Digital Cassette Image system)
* [[PZX]] (ZX Spectrum)
* [[SIMH TAP]] (SIMH emulator's tape file format)
* [[T64]]
* [[TAP (Oric)]]
* [[TAP (ZX Spectrum)]]
* [[Tap file]] (contains data from Commodore data cassette)
* [[Tape Image Format]] (TIF) (used for seismic data)
* [[TZX]] (ZX Spectrum)
* [[Unified Emulator Format]] (UEF; also does Acorn disks and ROMs)

==Unknown==
* [[lbl]] See here for details: [https://web.archive.org/web/20130103032119/http://classiccmp.org/pipermail/cctalk/2012-December/326747.html]

==Tools==
* [[The Sleuth Kit and Autopsy]] can read raw, [[Expert Witness]], and AFF formats
* [http://www.winimage.com/ WinImage] to read, write and create images, also lots of info
* [http://foremost.sourceforge.net/ Foremost: console tool to recover files from disk images]
* [http://disktype.sourceforge.net/ disktype: detect format of disk or disk image]
* [[TrID|TrID File Identifier]]: recognize many disk image formats
* [https://github.com/bitcurator/bca-webtools bca-webtools]
* [https://github.com/eaas-framework/xmount xmount: emulates various disk image formats for use in emulators requiring them]

See also [[Disk Imaging Software & Systems]], and [[Forensics and Law Enforcement]].

== Links ==
* [http://qanda.digipres.org/20/what-are-the-reasons-for-saving-disk-images?show=183 What are the reasons for saving disk images?]
* [http://ils.unc.edu/digccurr/curategear2016-talks/woods-curategear2016.pdf BCA-Webtools: Accessing and Visualizing Disk Images in a Web Browser]

CBMFS

2024-11-21T09:38:22Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Filesystem
}}
The '''CBM File System''' was used by disk drives made by Commodore Business Machines for the PET, VIC-20, C64 and C128 range of computers. These drives were called 'intelligent peripherals' meaning the DOS (Disk Operating System) was run in the drive itself, not on the computer the drive was attached to.

The most popular CBM drive was the [[Commodore 1541 disk|1541]], which supported 35 tracks using [[GCR encoding]]. A later drive, the [[Commodore 1571 disk|1571]] disk, used a double-sided format for twice the space. 3 1/2" disks were later introduced to the Commodore via the [[Commodore 1581 disk|1581]] format, which used a variant of CBMFS (see [[Commodore 1581 filesystem]]).

== D64 File Format ==

The [[D64]] format is most frequently used to capture 1541 disk images, it consists of a sector-for-sector copy of a 1540/1541 disk. The standard D64 is a 174848 byte file comprised of 256 byte sectors arranged in 35 tracks with a varying number of sectors per track for a total of 683 sectors. Track counting starts at 1, not 0, and goes up
to 35. Sector counting starts at 0, not 1, for the first sector, therefore a track with 21 sectors will go from 0 to 20.

== Physical media ==

The original media (a 5.25" disk) has the tracks laid out in circles, with track 1 on the very outside of the disk (closest to the sides) to track 35 being on the inside of the disk (closest to the inner hub ring). Commodore, in their infinite wisdom, varied the number of sectors per track and data densities across the disk to optimize available storage, resulting in the chart below. It shows the sectors/track for a standard D64. Since the outside diameter of a circle is the largest (versus closer to the center), the outside tracks have the largest amount of storage.

{| class='wikitable'
! Track
! Sectors/track
! # Sectors
! Storage in Bytes
|-
| 1-17
| 21
| 357
| 7820
|-
| 18-24
| 19
| 133
| 7170
|-
| 25-30
| 18
| 108
| 6300
|-
| 31-40(*)
| 17
| 85
| 6020
|}

683 Sectors (for a 35 track image)

{| class='wikitable'
! Track !! #Sect !! #SectorsIn !! D64 Offset !! Track !! #Sect !! #SectorsIn !! D64 Offset
|-
| 1 || 21 || 0 || $00000 || 21 || 19 || 414 || $19E00
|-
| 2 || 21 || 21 || $01500 || 22 || 19 || 433 || $1B100
|-
| 3 || 21 || 42 || $02A00 || 23 || 19 || 452 || $1C400
|-
| 4 || 21 || 63 || $03F00 || 24 || 19 || 471 || $1D700
|-
| 5 || 21 || 84 || $05400 || 25 || 18 || 490 || $1EA00
|-
| 6 || 21 || 105 || $06900 || 26 || 18 || 508 || $1FC00
|-
| 7 || 21 || 126 || $07E00 || 27 || 18 || 526 || $20E00
|-
| 8 || 21 || 147 || $09300 || 28 || 18 || 544 || $22000
|-
| 9 || 21 || 168 || $0A800 || 29 || 18 || 562 || $23200
|-
| 10 || 21 || 189 || $0BD00 || 30 || 18 || 580 || $24400
|-
| 11 || 21 || 210 || $0D200 || 31 || 17 || 598 || $25600
|-
| 12 || 21 || 231 || $0E700 || 32 || 17 || 615 || $26700
|-
| 13 || 21 || 252 || $0FC00 || 33 || 17 || 632 || $27800
|-
| 14 || 21 || 273 || $11100 || 34 || 17 || 649 || $28900
|-
| 15 || 21 || 294 || $12600 || 35 || 17 || 666 || $29A00
|-
| 16 || 21 || 315 || $13B00 || 36(*)|| 17 || 683 || $2AB00
|-
| 17 || 21 || 336 || $15000 || 37(*)|| 17 || 700 || $2BC00
|-
| 18 || 19 || 357 || $16500 || 38(*)|| 17 || 717 || $2CD00
|-
| 19 || 19 || 376 || $17800 || 39(*)|| 17 || 734 || $2DE00
|-
| 20 || 19 || 395 || $18B00 || 40(*)|| 17 || 751 || $2EF00
|}

(*)Tracks 36-40 apply to 40-track images only

==CBM DOS Directory Structure ==
The directory track should be contained totally on track 18. Sectors 1-18
contain the entries and sector 0 contains the BAM (Block Availability Map)
and disk name/ID. Since the directory is only 18 sectors large (19 less one
for the BAM), and each sector can contain only 8 entries (32 bytes per
entry), the maximum number of directory entries is 18 * 8 = 144. The first
directory sector is always 18/1, even though the t/s pointer at 18/0 (first
two bytes) might point somewhere else. It then follows the same chain
structure as a normal file, using a sector interleave of 3. This makes the
chain links go 18/1, 18/4, 18/7 etc.

Note that you can extend the directory off of track 18, but only when
reading the disk or image. Attempting to write to a directory sector not on
track 18 will cause directory corruption.

Each directory sector has the following layout (18/1 partial dump):

00: 12 04 81 11 00 4E 41 4D 45 53 20 26 20 50 4F 53 <- notice the T/S link
10: 49 54 A0 A0 A0 00 00 00 00 00 00 00 00 00 15 00 <- to 18/4 ($12/$04)
20: 00 00 84 11 02 41 44 44 49 54 49 4F 4E 41 4C 20 <- and how its not here
30: 49 4E 46 4F A0 11 0C FE 00 00 00 00 00 00 61 01 <- ($00/$00)

The first two bytes of the sector ($12/$04) indicate the location of the
next track/sector of the directory (18/4). If the track is set to $00, then
it is the last sector of the directory. It is possible, however unlikely,
that the directory may *not* be competely on track 18 (some disks do exist
like this). Just follow the chain anyhow.

When the directory is done, the track value will be $00. The sector link
should contain a value of $FF, meaning the whole sector is allocated, but
the actual value doesn't matter. The drive will return all the available
entries anyways. This is a breakdown of a standard directory sector and
entry:

Bytes: $00-1F: First directory entry
00-01: Track/Sector location of next directory sector ($00 $00 if
not the first entry in the sector)
02: File type.
Typical values for this location are:
$00 - Scratched (deleted file entry)
80 - DEL
81 - SEQ
82 - PRG
83 - USR
84 - REL
Bit 0-3: The actual filetype
000 (0) - DEL
001 (1) - SEQ
010 (2) - PRG
011 (3) - USR
100 (4) - REL
Values 5-15 are illegal, but if used will produce
very strange results. The 1541 is inconsistent in
how it treats these bits. Some routines use all 4
bits, others ignore bit 3, resulting in values
from 0-7.
Bit 4: Not used
Bit 5: Used only during SAVE-@ replacement
Bit 6: Locked flag (Set produces ">" locked files)
Bit 7: Closed flag (Not set produces "*", or "splat"
files)
03-04: Track/sector location of first sector of file
05-14: 16 character filename (in PETASCII, padded with $A0)
15-16: Track/Sector location of first side-sector block (REL file
only)
17: REL file record length (REL file only, max. value 254)
18-1D: Unused (except with GEOS disks)
1E-1F: File size in sectors, low/high byte order ($1E+$1F*256).
The approx. filesize in bytes is <= #sectors * 254
20-3F: Second dir entry. From now on the first two bytes of each
entry in this sector should be $00 $00, as they are
unused.
40-5F: Third dir entry
60-7F: Fourth dir entry
80-9F: Fifth dir entry
A0-BF: Sixth dir entry
C0-DF: Seventh dir entry
E0-FF: Eighth dir entry

Files, on a standard 1541, are stored using an interleave of 10. Assuming a
starting track/sector of 17/0, the chain would run 17/0, 17/10, 17/20,
17/8, 17/18, etc.

Note: No GEOS entries are listed in the above description. See [[GEOS VLIR]] for GEOS info.

The layout of the BAM area (sector 18/0) is a bit more complicated...

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
-----------------------------------------------
00: 12 01 41 00 12 FF F9 17 15 FF FF 1F 15 FF FF 1F
10: 15 FF FF 1F 12 FF F9 17 00 00 00 00 00 00 00 00
20: 00 00 00 00 0E FF 74 03 15 FF FF 1F 15 FF FF 1F
30: 0E 3F FC 11 07 E1 80 01 15 FF FF 1F 15 FF FF 1F
40: 15 FF FF 1F 15 FF FF 1F 0D C0 FF 07 13 FF FF 07
50: 13 FF FF 07 11 FF CF 07 13 FF FF 07 12 7F FF 07
60: 13 FF FF 07 0A 75 55 01 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 01 08 00 00 03 02 48 00
80: 11 FF FF 01 11 FF FF 01 11 FF FF 01 11 FF FF 01
90: 53 48 41 52 45 57 41 52 45 20 31 20 20 A0 A0 A0
A0: A0 A0 56 54 A0 32 41 A0 A0 A0 A0 00 00 00 00 00
B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Bytes:$00-01: Track/Sector location of the first directory sector (should
be set to 18/1 but it doesn't matter, and don't trust what
is there, always go to 18/1 for first directory entry)
02: Disk DOS version type (see note below)
$41 ("A")
03: Unused
04-8F: BAM entries for each track, in groups of four bytes per
track, starting on track 1 (see below for more details)
90-9F: Disk Name (padded with $A0)
A0-A1: Filled with $A0
A2-A3: Disk ID
A4: Usually $A0
A5-A6: DOS type, usually "2A"
A7-AA: Filled with $A0
AB-FF: Normally unused ($00), except for 40 track extended format,
see the following two entries:
AC-BF: DOLPHIN DOS track 36-40 BAM entries (only for 40 track)
C0-D3: SPEED DOS track 36-40 BAM entries (only for 40 track)

Note: The BAM entries for SPEED, DOLPHIN and ProLogic DOS use the same layout as standard BAM entries.

One of the interesting things from the BAM sector is the byte at offset
$02, the DOS version byte. If it is set to anything other than $41 or $00,
then we have what is called "soft write protection". Any attempt to write
to the disk will return the "DOS Version" error code 73 ,"CBM DOS V 2.6
1541". The 1541 is simply telling you that it thinks the disk format
version is incorrect. This message will normally come up when you first
turn on the 1541 and read the error channel. If you write a $00 or a $41
into 1541 memory location $00FF (for device 0), then you can circumvent
this type of write-protection, and change the DOS version back to what it
should be.

The BAM entries require a bit (no pun intended) more of a breakdown. Take
the first entry at bytes $04-$07 ($12 $FF $F9 $17). The first byte ($12) is
the number of free sectors on that track. Since we are looking at the track
1 entry, this means it has 18 (decimal) free sectors. The next three bytes
represent the bitmap of which sectors are used/free. Since it is 3 bytes (8
bits/byte) we have 24 bits of storage. Remember that at most, each track
only has 21 sectors, so there are a few unused bits.

Bytes: 04-07: 12 FF F9 17 Track 1 BAM
08-0B: 15 FF FF FF Track 2 BAM
0C-0F: 15 FF FF 1F Track 3 BAM
...
8C-8F: 11 FF FF 01 Track 35 BAM

These entries must be viewed in binary to make any sense. We will use the
first entry (track 1) at bytes 04-07:

FF=11111111, F9=11111001, 17=00010111

In order to make any sense from the binary notation, flip the bits around.

111111 11112222
01234567 89012345 67890123
--------------------------
11111111 10011111 11101000
^ ^
sector 0 sector 20

Since we are on the first track, we have 21 sectors, and only use up to
the bit 20 position. If a bit is on (1), the sector is free. Therefore,
track 1 has sectors 9,10 and 19 used, all the rest are free. Any leftover
bits that refer to sectors that don't exist, like bits 21-23 in the above
example, are set to allocated.

Each filetype has its own unique properties, but most follow one simple
structure. The first file sector is pointed to by the directory and follows
a t/s chain, until the track value reaches $00. When this happens, the
value in the sector link location indicates how much of the sector is used.
For example, the following chain indicates a file 6 sectors long, and ends
when we encounter the $00/$34 chain. At this point the last sector occupies
from bytes $02-$34.

{| class='wikitable'
! 1
! 2
! 3
! 4
! 5
! 6
|-
| 17/0 (11/00)
| 17/10 (11/0A)
| 17/20 (11/14)
| 17/1 (11/01)
| 17/11 (11/0B)
| 0/52 (0/34)
|}

== Variations on the D64 layout ==

These are some variations of the D64 layout:

1. Standard 35 track layout but with 683 error bytes added on to the end
of the file. Each byte of the error info corresponds to a single
sector stored in the D64, indicating if the sector on the original
disk contained an error. The first byte is for track 1/0, and the last
byte is for track 35/16.

2. A 40 track layout, following the same layout as a 35 track disk, but
with 5 extra tracks. These contain 17 sectors each, like tracks 31-35.
Some of the PC utilities do allow you to create and work with these
files. This can also have error bytes attached like variant #1.

3. The Commodore 128 allowed for "auto-boot" disks. With this, t/s 1/0
holds a specific byte sequence which the computer recognizes as boot
code. See the document C128BOOT.TXT for more info.

Below is a small chart detailing the standard file sizes of D64 images,
35 or 40 tracks, with or without error bytes.

{| class='wikitable'
! Disk type
! Size
|-
| 35 track, no errors
| 174848
|-
| 35 track, 683 error bytes
| 175531
|-
| 40 track, no errors
| 196608
|-
| 40 track, 768 error bytes
| 197376
|}

The following table (provided by Wolfgang Moser) outlines the differences
between the standard 1541 DOS and the various "speeder" DOS's that exist.
The 'header 7/8' category is the 'fill bytes' as the end of the sector
header of a real 1541 disk See [[G64]] for a better
explanation of these bytes.

{| class='wikitable'
! Disk format !! Tracks !! Header 7/8 allsechdrs !! Dos type !! DiskDos vs. type
|-
| Original CBM DOS v2.6 || 35 || $0f $0f || "2A" ||$41/'A'
|-
| SpeedDOS+ || 40 || $0f $0f || "2A" ||$41/'A'
|-
| ProfessionalDOS Initial || 35 || $0f $0f || "2A" ||$41/'A'
|-
| (Version 1/Prototype) || 40 || $0f $0f || "2A" ||$41/'A'
|-
| ProfDOS Release || 40 || $0f $0f || "4A" ||$41/'A'
|-
| Dolphin-DOS 2.0/3.0 || 35 || $0f $0f || "2A" ||$41/'A'
|-
| Dolphin-DOS 2.0/3.0 || 40 || $0d $0f || "2A" ||$41/'A'
|-
| PrologicDOS 1541 || 35 || $0f $0f || "2A" ||$41/'A'
|-
| PrologicDOS 1541 || 40 || $0f $0f || "2P" ||$50/'P'
|-
| ProSpeed 1571 2.0 || 35 || $0f $0f || "2A" ||$41/'A'
|-
| ProSpeed 1571 2.0 || 40 || $0f $0f || "2P" ||$50/'P'
|}

The location of the extra BAM information in sector 18/0, for 40 track
images, will be different depending on what standard the disks have been
formatted with. SPEED DOS stores them from $C0 to $D3, DOLPHIN DOS stores
them from $AC to $BF and PrologicDOS stored them right after the existing
BAM entries from $90-A3. PrologicDOS also moves the disk label and ID
forward from the standard location of $90 to $A4. 64COPY and Star Commander
let you select from several different types of extended disk formats you
want to create/work with.

All three of the speeder DOS's mentioned above don't alter the standard
sector interleave of 10 for files and 3 for directories. The reason is that
they use a memory cache installed in the drive which reads the entire track
in one pass. This alleviates the need for custom interleave values. They do
seem to alter the algorithm that finds the next available free sector so
that the interleave value can deviate from 10 under certain circumstances,
but I don't know why they would bother.

Below is a HEX dump of a Speed DOS BAM sector. Note the location of the
extra BAM info from $C0-D3.

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
----------------------------------------------- ----------------
0070: 12 FF FF 03 12 FF FF 03 12 FF FF 03 11 FF FF 01 ????????????????
0080: 11 FF FF 01 11 FF FF 01 11 FF FF 01 11 FF FF 01 ????????????????
0090: A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 ????????????????
00A0: A0 A0 30 30 A0 32 41 A0 A0 A0 A0 00 00 00 00 00 ??00?2A?????????
00B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ????????????????
00C0: 11 FF FF 01 11 FF FF 01 11 FF FF 01 11 FF FF 01 ????????????????
00D0: 11 FF FF 01 00 00 00 00 00 00 00 00 00 00 00 00 ????????????????

Below is a HEX dump of a Dolphin DOS BAM sector. Note the location of the
extra BAM info from $AC-BF.

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
----------------------------------------------- ----------------
0070: 12 FF FF 03 12 FF FF 03 12 FF FF 03 11 FF FF 01 ????????????????
0080: 11 FF FF 01 11 FF FF 01 11 FF FF 01 11 FF FF 01 ????????????????
0090: A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 ????????????????
00A0: A0 A0 30 30 A0 32 41 A0 A0 A0 A0 00 11 FF FF 01 ??00?2A?????????
00B0: 11 FF FF 01 11 FF FF 01 11 FF FF 01 11 FF FF 01 ????????????????
00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ????????????????
00D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ????????????????

Below is a HEX dump of a PrologicDOS BAM sector. Note that the disk name
and ID are now located at $A4 instead of starting at $90.

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
----------------------------------------------- ----------------
0070: 12 FF FF 03 12 FF FF 03 12 FF FF 03 11 FF FF 01 ????????????????
0080: 11 FF FF 01 11 FF FF 01 11 FF FF 01 11 FF FF 01 ????????????????
0090: 11 FF FF 01 11 FF FF 01 11 FF FF 01 11 FF FF 01 ????????????????
00A0: 11 FF FF 01 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 ????????????????
00B0: A0 A0 A0 A0 A0 A0 30 30 A0 32 50 A0 A0 A0 A0 00 ??????00?2P?????
00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ????????????????
00ED: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ????????????????

Here is the meaning of the error bytes added onto the end of any extended
D64. The CODE is the same as that generated by the 1541 drive controller...
it reports these numbers, not the error code we usually see when an error
occurs.

Some of what comes below is taken from Immers/Neufeld book "Inside
Commodore DOS". Note the descriptions are not completely accurate as to
what the drive DOS is actually doing to seek/read/decode/write sectors, but
serve as simple examples only. The "type" field is where the error usually
occurs, whether it's searching for any SYNC mark, any header ID, any valid
header, or reading a sector.

These first errors are "seek" errors, where the disk controller is simply
reading headers and looking at descriptor bytes, checksums, format ID's and
reporting what errors it sees. These errors do *not* necessarily apply to
the exact sector being looked for. This fact makes duplication of these
errors very unreliable.

{| class='wikitable'
! Code
! Error
! Type
! 1541 error
! Error description
|-
| 03
| 21
| Seek
| No SYNC sequence found.
| Each sector data block and header block are preceeded by SYNC marks. If *no* sync sequence is found within 20 milliseconds (only ~1/10 of a disk rotation!) then this error is generated. This error used to mean the entire track is bad, but it does not have to be the case. Only a small area of the track needs to be without a SYNC mark and this error will be generated.<br/> Converting this error to a D64 is very problematic because it depends on where the physical head is on the disk when a read attempt is made. If it is on valid header/sectors then it won't occur. If it happens over an area without SYNC marks, it will happen.
|-
| 02
| 20
| Seek
| Header descriptor byte not found (HEX $08, GCR $52)
| Each sector is preceeded by an 8-byte GCR header block, which starts with the value $52 (GCR). If this value is not found after 90 attempts, this error is generated.<br/> Basically, what a track has is SYNC marks, and possibly valid data blocks, but no valid header descriptors.
|-
| 09
| 27
| Seek
| Checksum error in header block
| The header block contains a checksum value, calculated by [[Exclusive Or|XOR'ing]] the TRACK, SECTOR, ID1 and ID2 values. If this checksum is wrong, this error is generated.
|-
| 0B
| 29
| Seek
| Disk sector ID mismatch
| The ID's from the header block of the currently read sector are compared against the ones from the low-level header of 18/0. If there is a mismatch, this error is generated.
|-
| 02
| 20
| Seek
| Header block not found
| This error can be reported again when searching for the correct header block. An image of the header is built and searched for, but not found after 90 read attempts. Note the difference from the first occurance. The first one only searches for a valid ID, not the whole header.
|}

Note that error 20 occurs twice during this phase. The first time is when
a header ID is being searched for, the second is when the proper header
pattern for the sector being searched for is not found.

From this point on, all the errors apply to the specific sector you are
looking for. If a read passed all the previous checks, then we are at the
sector being searched for.

Note that the entire sector is read before these errors are detected.
Therefore the data, checksum and off bytes are available.

{| class='wikitable'
! Code
! Error
! Type
! 1541 error
! Error description
|-
| 04
| 22
| Read
| Data descriptor byte not found (HEX $07, GCR $55)
| Each sector data block is preceeded by the value $07, the "data block" descriptor. If this value is not there, this error is generated. Each encoded sector has actually 260 bytes. First is the descriptor byte, then follows the 256 bytes of data, a checksum, and two "off" bytes.
|-
| 05
| 23
| Read
| Checksum error in data block
| The checksum of the data read of the disk is calculated, and compared against the one stored at the end of the sector. If there's a discrepancy, this error is generated.
|-
| 0F
| 74
| Read
| Drive Not Ready (no disk in drive or no device 1)
|
|}

These errors only apply when writing to a disk. I don't see the
usefulness of having these as they cannot be present when only *reading* a
disk.

{| class='wikitable'
! Code
! Error
! Type
! 1541 error
! Error description
|-
| 06
| 24
| Write
| Write verify (on format)
|
|-
| 07
| 25
| Write
| Write verify error
| Once the GCR-encoded sector is written out, the drive waits for the sector to come around again and verifies the whole 325-byte GCR block. Any errors encountered will generate this error.
|-
| 08
| 26
| Write
| Write protect on
| Self explanatory. Remove the write-protect tab, and try again.
|-
| 0A
| 28
| Write
| Write error
| In actual fact, this error never occurs, but it is included for completeness.
|}

This is not an error at all, but when gets reported when the read of a
sector is ok.

{| class='wikitable'
! Code
! Error
! Type
! 1541 error
! Error description
|-
| 01
| 00
| N/A
| No error.
| Self explanatory. No errors were detected in the reading and decoding of the sector.
|}

The advantage with using the 35 track D64 format, regardless of error
bytes, is that it can be converted directly back to a 1541 disk by either
using the proper cable and software on the PC, or send it down to the C64
and writing it back to a 1541. It is the best documented format since it is
also native to the C64, with many books explaining the disk layout and the
internals of the 1541.

== What it takes to support D64 ==

The D64 layout is reasonably robust, being that it is an electronic
representation of a physical 1541 disk. It shares *most* of the 1541
attributes and it supports all file formats, since all C64 files came from
here. The only file I have found that can't be copied to a D64 is a T64 FRZ
(FRoZen files), since you lose the extra file type attribute.

Since the D64 layout seems to be an exact byte copy of a 1541 floppy, it
would appear to be the perfect format for *any* emulator. However, it does
not contain certain vital bits of information that, as a user, you normally
don't have access to.

Preceeding each sector on a real 1541 disk is a header block which
contains the sector ID bytes and checksum. From the information contained
in the header, the drive determines if there's an error on that header
(27-checksum error, 29-disk ID mismatch). The sector itself also contains
info (data block signature, checksum) that result in error detection (23
checksum, 22 data block not present, etc). The error bytes had to be added
on to the D64 image, "extending" the format to take into account the
missing info.

The disk ID is important in the copy protection of some programs. Some
programs fail to work properly since the D64 doesn't contain these ID's.
These bytes would be an addition to the format which has never been done
and would be difficult to do. (As an aside, the 4-pack ZipCode files do
contain the original master disk ID, but these are lost in the conversion
of a ZipCode to a D64. Only storing *one* of the ID's is not enough, all
the sector ID's should be kept.)

The extended track 1541 disks also presented a problem, as there are
several different formats (and how/where to store the extra BAM entries in
a sector that was not designed for them, yet still remain compatible).
Because of the additions to the format (error bytes and 40 tracks) there
exists 4 different types of D64's, all recognizeable by their size.

It is also the only format that uses the sector count for the file size
rather than actual bytes used. This can present some problems when
converting/copying the to another format because you may have to know the
size before you begin (see LBR format).

It also contains no consistent signature, useful for recognizing if D64
is really what it claims to be. In order to determine if a file is a D64,
you must check the file size.

(Content taken from [http://unusedino.de/ec64/technical/formats/d64.html D64.TXT] in Peter Scheper's excellent compendium of C64 file format information).

== Commodore C64 CP/M Filesystem ==

A D64 file written by the Commodore 64 port of [[CP/M]] will contain a [[CP/M file system]]. This has the following characteristics:
* 34 tracks
* 2 system tracks
* 17 256-byte sectors per track (appearing to CP/M as 34 128-byte sectors)
* 1k blocks
* 2 directory blocks

The CP/M filesystem is found on the first 17 sectors of each track (except track 18, which is skipped). CP/M numbers tracks from zero, so tracks 1-17 are accessed as 0-16, and tracks 19-35 as 17-33.

The CBMFS block availability map marks all sectors as used. The disk name is usually "CP/M DISK".

On a boot disk, the first sector contains a BASIC bootloader (present in the CBMFS directory as the file "CPM"). The remaining sectors of tracks 1 and 2 contain the 6502 host code and the CP/M BIOS, BDOS and CCP.

== Utilities ==
* [http://style64.org/dirmaster DirMaster: reads C64 disk images / archives / files in Windows]

[[Category:Commodore computers]]

Quick Release Sector Transfer

2023-09-06T17:35:51Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
}}

The QRST disc image format was used by Compaq to distribute disk images of diagnostic software. The file QRST.EXE or QRST5.EXE would be supplied with the disc images to write them to a floppy drive.

== Identification ==

QRST files start with the 4-character ASCII string <code>QRST</code>. The first character of the file extension is an underscore, followed by a 2-digit hexadecimal (version <5) or decimal (version 5) volume number.

== Structure ==

=== File header ===

The file begins with a 796-byte header:

{| class="wikitable"
! Offset
! Size
! Description
|-
|0x000 || 4 bytes || Magic number, <code>QRST</code>
|-
|0x004 || 4 bytes || Version number, floating point
|-
|0x008 || 4 bytes || Checksum (version <5), unused (version 5)
|-
|0x00C || 1 byte || Disk capacity:
{| class="wikitable"
! Value
! Meaning
|-
|0 || unknown
|-
|1 || 360k
|-
|2 || 1.2M
|-
|3 || 720k
|-
|4 || 1.4M
|-
|5 || 160k
|-
|6 || 180k
|-
|7 || 320k
|}
|-
|0x00D || 1 byte || Current volume number in set
|-
|0x00E || 1 byte || Count of volumes in set
|-
|0x00F || 96 bytes || Description, ASCIIZ
|-
|0x04B || 720 bytes || Disk label, ASCIIZ
|-
|0x31B || 1 byte || Always 0 (version <5), always 2 (version 5)
|}

Version 5 extends the header with an additional 25 bytes:

{| class="wikitable"
! Offset
! Size
! Description
|-
|0x31C || 1 byte || Unknown
|-
|0x31D || 4 bytes || Start of compressed data
|-
|0x321 || 4 bytes || Length of compressed data
|-
|0x325 || 4 bytes || [[CRC-32]] of compressed data
|-
|0x329 || 4 bytes || Unused (start)
|-
|0x32D || 4 bytes || Unused (length)
|-
|0x331 || 4 bytes || Unused (CRC-32)
|}

=== Version <5 data ===

In versions below 5, the header will be followed by the data tracks. These can be in one of three forms:

==== Uncompressed track ====
{| class="wikitable"
! Offset
! Size
! Description
|-
|0x00 || 1 byte || Cylinder
|-
|0x01 || 1 byte || Head
|-
|0x02 || 1 byte || 0 indicates uncompressed track
|-
|0x03 || calculated from disk type in header || Track data, uncompressed
|}

==== Blank track ====
{| class="wikitable"
! Offset
! Size
! Description
|-
|0x00 || 1 byte || Cylinder
|-
|0x01 || 1 byte || Head
|-
|0x02 || 1 byte || 1 indicates blank track
|-
|0x03 || 1 byte || Filler byte
|}

==== Compressed track ====
{| class="wikitable"
! Offset
! Size
! Description
|-
|0x00 || 1 byte || Cylinder
|-
|0x01 || 1 byte || Head
|-
|0x02 || 1 byte || 2 indicates compressed track
|-
|0x03 || 2 bytes || Length of compressed data
|-
|0x05 || As specified above || Compressed data
|}

The compressed data stream consists of alternating literal runs (a byte giving the length of the run, followed by that number of bytes data) and compressed runs (two bytes; first gives number of repeats, second gives byte to repeat).

=== Version 5 data ===

In version 5, the data is an entire disk image compressed with PKWARE Data Compression Library's Implode. (This is not the same as PKZIP's Implode.)

=== Checksum ===

In versions below 5, the checksum is the sum of all bytes on the disc, each byte multiplied by (1 + its offset on the disc). So for a 360k disc it would be (1 * first byte of first sector) + (2 * second byte of first sector) + ... + (368640 * last byte of last sector).

In version 5, the [[CRC-32]] covers the compressed data.

=== Multiple disc images in one file ===

At least one QRST file is known to exist which contains two disc images -- it has the structure of two separate QRST files concatenated together, each one describing itself as volume 1 of 1.

== Sample files ==

* [ftp://ftp.oldskool.org/pub/drivers/Compaq/Portable%20III/setup%20and%20diags/ Compaq Portable III setup and diagnostics]
* [https://ftp.zx.net.nz/pub/archive/ftp.hp.com/pub/softpaq/sp0000-0500/sp0484.zip QRST file containing two concatenated disc images]

D88

2022-09-06T21:46:26Z

John e: Created page with "{{FormatInfo |formattype=electronic |subcat=Disk Image Formats |extensions={{d88|1dd|2dd}} }} The '''D88''' disc image format is used to contain dumps of floppy disks, ma..."

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
|extensions={{d88|1dd|2dd}}
}}

The '''D88''' disc image format is used to contain dumps of [[floppy disk]]s, mainly associated with computers of Japanese origin.

== Identification ==
The little-endian doubleword at offset 20h is the offset to the first track. This must be 0x02A0 or 0x02B0.

== References ==
* [https://www.pc98.org/project/doc/d88.html Format specification at pc98.org]

Disk Express

2022-08-24T08:06:58Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
|extensions={{ext|dxp}}, special
|released=1991
}}

'''Disk Express''' (stylized as '''Disk eXPress''') is a shareware utility for PCDOS and OS/2 by Albert J. Shan, allowing floppy disks to be imaged. A disk image could be saved either as a data file, or as an executable that when run wrote its contents back to diskette.

== Identification ==

If the file is not executable, it begins with a 512-byte header. The first two bytes will be 'AS' and the third will be a version number, 0-2.

If the file is executable, it starts with an [[MS-DOS EXE]] header. Bytes 2-5 of the header give the length of the executable portion, as normal. The disk image header starting with 'AS' is found four bytes after the executable portion.

Executable files use the .EXE extension.

== Structure ==

=== Executable loader ===

Depending on the options selected when the disk was imaged, the executable loader (if present) will either be in [[MS-DOS EXE]] or [[New Executable]] format (for OS/2). It is followed by a 4-byte checksum and then the disk image data.

=== Disk image header ===

The disk image has a 512-byte header:

{| class="wikitable"
! Offset
! Size
! Description
|-
|0x000 || 2 bytes || Magic number, <code>AS</code>
|-
|0x002 || 1 byte || Major version of Disk Express required to write this file (2 in files generated by v2.x)
|-
|0x003 || 1 byte || Minor version required to write this file (30 if 'encrypted' or 'bad sectors' flags are set, otherwise 0)
|-
|0x004 || 1 byte || Release of Disk Express that created this file (single ASCII character)
|-
|0x005 || 1 byte || Disk capacity:
{| class="wikitable"
! Value
! Meaning
|-
|0 || 160k
|-
|1 || 180k
|-
|2 || 320k
|-
|3 || 360k
|-
|4 || 720k
|-
|5 || 1.2M
|-
|6 || 1.4M
|-
|7 || 2.8M
|}
|-
|0x006 || 4 bytes || [[CRC-32]] of disk data
|-
|0x00A || 1 byte || Compression type: 0 for uncompressed, 1-2 for compressed
|-
|0x00B || 1 byte || Last cylinder imaged
|-
|0x00C || 1 byte || Last head imaged
|-
|0x00D || 1 byte || Always 0
|-
|0x00E || 1 byte || Bitwise flags:
{| class="wikitable"
! Value
! Meaning
|-
|0x01 || Non-DOS disk
|-
|0x02 || Encrypted disk image
|-
|0x04 || Contains bad sectors
|}
|-
|0x00F || 1 byte || Always 0
|-
|0x010 || 4 bytes || Passphrase hash (if encrypted)
|-
|0x014 || 284 bytes || Always 0
|-
|0x130 || 4 bytes || CRC-32 of file header
|-
|0x134 || 200 bytes || File description: 5 lines each of 40 characters, [[CP437]] character set
|-
|0x1FC || 4 bytes || CRC-32 of description
|}

=== Sector data ===

The imaged sectors follow the header with no further header or trailer information. The default behaviour of Disk Express is to record up to the last allocated block on the disk, so the amount of data stored may be less than the media type in the header block.

If the file is compressed, then each track is compressed separately. Each track in this case is preceded by a little-endian word, giving the length of the compressed data. There are special cases if the length is 1 (in which case all bytes in the track are the same) or if it is the same as the uncompressed length (in which case the track is not compressed).

== Software ==
* [{{SACFTPURL|utildisk|dxp234.zip}} Disk eXPress v2.34]

Disk Express

2022-08-18T14:56:07Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
|extensions={{ext|dxp}}, special
|released=1991
}}

'''Disk Express''' (stylized as '''Disk eXPress''') is a shareware utility for PCDOS and OS/2 by Albert J. Shan, allowing floppy disks to be imaged. A disk image could be saved either as a data file, or as an executable that when run wrote its contents back to diskette.

== Identification ==

If the file is not executable, it begins with a 512-byte header. The first two bytes will be 'AS' and the third will be a version number, 0-2.

If the file is executable, it starts with an [[MS-DOS EXE]] header. Bytes 2-5 of the header give the length of the executable portion, as normal. The disk image header starting with 'AS' is found four bytes after the executable portion.

Executable files use the .EXE extension.

== Structure ==

=== Executable loader ===

Depending on the options selected when the disk was imaged, the executable loader (if present) will either be in [[MS-DOS EXE]] or [[New Executable]] format (for OS/2). It is followed by a 4-byte checksum and then the disk image data.

=== Disk image header ===

The disk image has a 512-byte header:

{| class="wikitable"
! Offset
! Size
! Description
|-
|0x000 || 2 bytes || Magic number, <code>AS</code>
|-
|0x002 || 1 byte || Major version of Disk Express required to write this file (2 in files generated by v2.x)
|-
|0x003 || 1 byte || Minor version required to write this file (30 if 'encrypted' or 'bad sectors' flags are set, otherwise 0)
|-
|0x004 || 1 byte || Release of Disk Express that created this file (single ASCII character)
|-
|0x005 || 1 byte || Disk capacity:
{| class="wikitable"
! Value
! Meaning
|-
|0 || 160k
|-
|1 || 180k
|-
|2 || 320k
|-
|3 || 360k
|-
|4 || 720k
|-
|5 || 1.2M
|-
|6 || 1.4M
|-
|7 || 2.8M
|}
|-
|0x006 || 4 bytes || [[CRC-32]] of disk data
|-
|0x00A || 1 byte || Compression type: 0 for uncompressed, 1-2 for compressed
|-
|0x00B || 1 byte || Last cylinder imaged
|-
|0x00C || 1 byte || Last head imaged
|-
|0x00D || 1 byte || Always 0
|-
|0x00E || 1 byte || Bitwise flags:
{| class="wikitable"
! Value
! Meaning
|-
|0x01 || Non-DOS disk
|-
|0x02 || Encrypted disk image
|-
|0x04 || Contains bad sectors
|}
|-
|0x00F || 1 byte || Always 0
|-
|0x010 || 4 bytes || Passphrase hash (if encrypted)
|-
|0x014 || 284 bytes || Always 0
|-
|0x130 || 4 bytes || CRC-32 of file header
|-
|0x134 || 200 bytes || File description: 5 lines each of 40 characters, [[CP437]] character set
|-
|0x1FC || 4 bytes || CRC-32 of description
|}

=== Sector data ===

The imaged sectors follow the header with no further header or trailer information. The default behaviour of Disk Express is to record up to the last allocated block on the disk, so the amount of data stored may be less than the media type in the header block.

== Software ==
* [{{SACFTPURL|utildisk|dxp234.zip}} Disk eXPress v2.34]

Disk Express

2022-08-18T09:28:01Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
|extensions={{ext|dxp}}, special
|released=1991
}}

'''Disk Express''' (stylized as '''Disk eXPress''') is a shareware utility for PCDOS and OS/2 by Albert J. Shan, allowing floppy disks to be imaged. A disk image could be saved either as a data file, or as an executable that when run wrote its contents back to diskette.

== Identification ==

If the file is not executable, it begins with a 512-byte header. The first two bytes will be 'AS' and the third will be a version number, 0-2.

If the file is executable, it starts with an [[MS-DOS EXE]] header. Bytes 2-5 of the header give the length of the executable portion, as normal. The disk image header starting with 'AS' is found four bytes after the executable portion.

Executable files use the .EXE extension.

== Structure ==

=== Executable loader ===

Depending on the options selected when the disk was imaged, the executable loader (if present) will either be in [[MS-DOS EXE]] or [[New Executable]] format (for OS/2). It is followed by a 4-byte checksum and then the disk image data.

=== Disk image header ===

The disk image has a 512-byte header:

{| class="wikitable"
! Offset
! Size
! Description
|-
|0x000 || 2 bytes || Magic number, <code>AS</code>
|-
|0x002 || 1 byte || Major version of Disk Express that created this file
|-
|0x003 || 1 byte || Minor version required to write this file (30 if 'encrypted' or 'bad sectors' flags are set, otherwise 0)
|-
|0x004 || 1 byte || Release of Disk Express that created this file (single ASCII character)
|-
|0x005 || 1 byte || Disk capacity:
{| class="wikitable"
! Value
! Meaning
|-
|0 || 160k
|-
|1 || 180k
|-
|2 || 320k
|-
|3 || 360k
|-
|4 || 720k
|-
|5 || 1.2M
|-
|6 || 1.4M
|-
|7 || 2.8M
|}
|-
|0x006 || 4 bytes || [[CRC-32]] of disk data
|-
|0x00A || 1 byte || Compression type: 0 for uncompressed, 1-2 for compressed
|-
|0x00B || 1 byte || Last cylinder imaged
|-
|0x00C || 1 byte || Last head imaged
|-
|0x00D || 1 byte || Always 0
|-
|0x00E || 1 byte || Bitwise flags:
{| class="wikitable"
! Value
! Meaning
|-
|0x01 || Non-DOS disk
|-
|0x02 || Encrypted disk image
|-
|0x04 || Contains bad sectors
|}
|-
|0x00F || 1 byte || Always 0
|-
|0x010 || 4 bytes || Passphrase hash (if encrypted)
|-
|0x014 || 284 bytes || Always 0
|-
|0x130 || 4 bytes || CRC-32 of file header
|-
|0x134 || 200 bytes || File description: 5 lines each of 40 characters, [[CP437]] character set
|-
|0x1FC || 4 bytes || CRC-32 of description
|}

=== Sector data ===

The imaged sectors follow the header with no further header or trailer information. The default behaviour of Disk Express is to record up to the last allocated block on the disk, so the amount of data stored may be less than the media type in the header block.

== Software ==
* [{{SACFTPURL|utildisk|dxp234.zip}} Disk eXPress v2.34]

Disk Express

2022-08-17T07:53:11Z

John e: Created page with "{{FormatInfo |formattype=electronic |subcat=Disk Image Formats }} "Disk Express" is a shareware utility for PCDOS and OS/2 by Albert J. Shan, allowing floppy disks to be imag..."

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
}}

"Disk Express" is a shareware utility for PCDOS and OS/2 by Albert J. Shan, allowing floppy disks to be imaged. A disk image could be saved either as a data file, or as an executable that when run wrote its contents back to diskette.

== Identification ==

If the file is not executable, it begins with a 512-byte header. The first two bytes will be 'AS' and the third will be a version number, 0-2.

If the file is executable, it starts with an [[MS-DOS EXE]] header. Bytes 2-5 of the header give the length of the executable portion, as normal. The disk image header starting with 'AS' is found four bytes after the executable portion.

Executable files use the .EXE extension.

== Structure ==

=== Executable loader ===

Depending on the options selected when the disk was imaged, the executable loader (if present) will either be in [[MS-DOS EXE]] or [[New Executable]] format (for OS/2). It is followed by a 4-byte checksum and then the disk image data.

=== Disk image header ===

The disk image has a 512-byte header:

{| class="wikitable"
! Offset
! Size
! Description
|-
|0x000 || 2 bytes || Magic number, <code>AS</code>
|-
|0x002 || 1 byte || Major version of Disk Express that created this file
|-
|0x003 || 1 byte || Minor version required to write this file (30 if 'encrypted' or 'bad sectors' flags are set, otherwise 0)
|-
|0x004 || 1 byte || Minor version of Disk Express that created this file
|-
|0x005 || 1 byte || Disk capacity:
{| class="wikitable"
! Value
! Meaning
|-
|0 || 160k
|-
|1 || 180k
|-
|2 || 320k
|-
|3 || 360k
|-
|4 || 720k
|-
|5 || 1.2M
|-
|6 || 1.4M
|-
|7 || 2.8M
|}
|-
|0x006 || 4 bytes || [[CRC-32]] of disk data
|-
|0x00A || 1 byte || Compression type: 0 for uncompressed, 1-2 for compressed
|-
|0x00B || 1 byte || Last cylinder imaged
|-
|0x00C || 1 byte || Last head imaged
|-
|0x00D || 1 byte || Always 0
|-
|0x00E || 1 byte || Bitwise flags:
{| class="wikitable"
! Value
! Meaning
|-
|0x01 || Non-DOS disk
|-
|0x02 || Encrypted disk image
|-
|0x04 || Contains bad sectors
|}
|-
|0x00F || 1 byte || Always 0
|-
|0x010 || 4 bytes || Passphrase hash (if encrypted)
|-
|0x014 || 284 bytes || Always 0
|-
|0x130 || 4 bytes || CRC-32 of file header
|-
|0x134 || 200 bytes || File description: 5 lines each of 40 characters, [[CP437]] character set
|-
|0x1FC || 4 bytes || CRC-32 of description
|}

=== Sector data ===

The imaged sectors follow the header with no further header or trailer information. The default behaviour of Disk Express is to record up to the last allocated block on the disk, so the amount of data stored may be less than the media type in the header block.

TD0

2021-12-08T01:49:07Z

John e: /* Overview */

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
|extensions={{ext|td0}}
}}

==Overview==
TeleDisk was an early PC based disk imaging program. It was often used to image floppy disks from other systems, notably IBM mainframes or DEC workstations

The file format provides for splitting disk images into multiple parts; in this case, the second part will have a .TD1 extension, the third .TD2, and so on. In practice split disk images are extremely rare.

==References==
* TeleDisk downloads [http://www.classiccmp.org/dunfield/img54306/teledisk.htm here]
* Format specification by Dave Dunfield [http://www.classiccmp.org/dunfield/img54306/td0notes.txt here]
* Some reverse engineering and pseudo-code [http://www.fpns.net/willy/wteledsk.htm here]
* MESS [http://git.redump.net/mame/tree/src/lib/formats/td0_dsk.c source code] for reading TD0 files

Vfont

2021-01-22T02:06:38Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Fonts
|released=1986
}}
'''vfont''' is a variable-sized bitmap font found on BSD and SunOS systems. Files may contain up to 256 character bitmaps; each bitmap is at most 127x127 pixels, and the total size of all bitmaps must not exceed 65535.

If a file extension is used, it tends to reflect the point size of the font (eg: .12, .14) rather than indicate the file type.

== Identification ==
Files begin with bytes {{magic|0x1E 0x01}} (little-endian systems) or {{magic|0x01 0x1E}} (big-endian systems). A program processing vfont data should be prepared to handle files with either byte order.

It may not be coincidental that the magic number for vfont is 0436 (octal), where the magic number for version 1 of [[PC Screen Font]] is 0x0436 (hexadecimal).

== Specifications ==
* [https://remilia.otherone.xyz/man/2.10BSD/5/vfont Format documentation from 2.10BSD]
* [http://www-lehre.inf.uos.de/~sp/Man/_Man_SunOS_4.1.3_html/html5/vfont.5.html Format documentation from SunOS 4.1.3]

== Sample files ==
* [https://tuhs.v6sh.org/UnixArchiveMirror/Distributions/UCB/4.2BSD/ 4.2BSD] → vfont.tar.gz -- fonts in little-endian format.

Vfont

2021-01-20T19:43:42Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Fonts
|released=~1988
}}
'''vfont''' is a variable-sized bitmap font found on BSD and SunOS systems. Files may contain up to 256 character bitmaps; each bitmap is at most 127x127 pixels, and the total size of all bitmaps must not exceed 65535.

If a file extension is used, it tends to reflect the point size of the font (eg: .12, .14) rather than indicate the file type.

== Identification ==
Files begin with bytes {{magic|0x1E 0x01}} (little-endian systems) or {{magic|0x01 0x1E}} (big-endian systems). A program processing vfont data should be prepared to handle files with either byte order.

It may not be coincidental that the magic number for vfont is 0436 (octal), where the magic number for version 1 of [[PC Screen Font]] is 0x0436 (hexadecimal).

== Specifications ==
* [http://www-lehre.inf.uos.de/~sp/Man/_Man_SunOS_4.1.3_html/html5/vfont.5.html Format documentation from SunOS 4.1.3]

== Sample files ==
* [https://tuhs.v6sh.org/UnixArchiveMirror/Distributions/UCB/4.2BSD/] → vfont.tar.gz -- fonts in little-endian format.

PC Screen Font

2021-01-20T19:41:21Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Fonts
|extensions={{ext|psf}}, {{ext|psfu}}
|released=~1989
}}
The '''PC Screen Font''' ('''PSF''') format is a fixed-width bitmap font format originally used on the PC under MS-DOS. It was subsequently adopted and extended for Linux console fonts.

PSF has been extended to support [[Unicode]]. The '''.psfu''' file extension is sometimes used to indicate that the file includes Unicode mappings, though '''.psf''' files often have them as well.

== Identification ==
Files begin with bytes {{magic|0x36 0x04}} (version 1) or {{magic|0x72 0xb5 0x4a 0x86}} (version 2). The former may be a reference to [[vfont]] format, the magic number of which is 0436 when converted to octal.

== Specifications ==
* http://www.win.tue.nl/~aeb/linux/kbd/font-formats-1.html

== Software ==
* [http://www.seasip.info/Unix/PSF/ PSF Tools]

== Sample files ==
* [https://packages.debian.org/stable/console-setup-linux console-setup-linux package] → console-setup-linux_*.deb → /usr/share/consolefonts/*.psf.gz

== Links ==
* [[Wikipedia: PC Screen Font]]

Vfont

2021-01-20T14:31:18Z

John e: /* Identification */

{{FormatInfo
|formattype=electronic
|subcat=Fonts
|released=~1988
}}
'''vfont''' is a variable-sized bitmap font found on BSD and SunOS systems. Files may contain up to 256 character bitmaps.

If a file extension is used, it tends to reflect the point size of the font (eg: .12, .14) rather than indicate the file type.

== Identification ==
Files begin with bytes {{magic|0x1E 0x01}} (little-endian systems) or {{magic|0x01 0x1E}} (big-endian systems). A program processing vfont data should be prepared to handle files with either byte order.

== Specifications ==
* [http://www-lehre.inf.uos.de/~sp/Man/_Man_SunOS_4.1.3_html/html5/vfont.5.html Format documentation from SunOS 4.1.3]

== Sample files ==
* [https://tuhs.v6sh.org/UnixArchiveMirror/Distributions/UCB/4.2BSD/] → vfont.tar.gz -- fonts in little-endian format.

Fonts

2021-01-20T00:35:39Z

John e:

{{FormatInfo
|formattype=electronic
|thiscat=Fonts
|image=Fonts.png
}}
Fonts describe how text looks (as opposed to how the characters are represented in text, which is the area of [[character encoding]]s). There are a number of formats that describe fonts for computers.

== Font formats ==
* [[Acorn Font]]
* [[Adobe Type 1]] (PostScript Type 1, ATM, .pfb, .pfm, .afm)
* [[Amiga bitmap font]]
* [[BDF]]
* [[BRFNT]]
* [[ByteMap font format]] [https://web.archive.org/web/20171031202737/http://bmf.wz.cz/bmf-format.htm]
* [[Calamus Font]] (.cfn)
* [[ChiWriter font]]
* [[CHR (Borland font)]]
* [[CID]], [[TFM]], [[OFM]], [[OVF]], [[OVP]], [[Metafont]] - TeX Fonts and support data
* [[CPI]]
* [[Daisy-Dot font]]
* [[Data Fork Suitcase font]] (OS X, .dfont)
* [[dfont]]
* [[Embedded OpenType]] (EOT)
* [[F3 font]]
* [[FIGlet font]]
* [[FNT (Windows Font)]]
* [[FontLab]] (.vfb)
* [[Fontographer]] (.fog)
* [[FON]] (Windows Font with NE/PE container)
* [[Font Suitcase]] (Mac pre-OS X, uses resource fork)
* [[GEM bitmap font]] (.fnt)
* [[GEOS Font]]
* [[GRASP font]]
* [[HEX (Unifont)]]
* [[IntelliFont]]
* [[Interlace Character Editor font]]
* [[MPlayer bitmap font]]
* [[Open Font Format]]
* [[OpenType]] (.otf)
* [[PaintJet soft font]] (.pjf)
* [[PC Screen Font]]
* [[PCF]]
* [[PFF2]] (.pf2)
* [[PFR]] (TrueDoc)
* [[PK font]]
* [[PostScript font]]
* [[sfnt]]
* [[Signum font]]
* [[SNF]]
* [[Speedo]] (.spd)
* [[Spline Font Database]] (.sfd)
* [[TexFont]] (.txf)
* [[TheDraw font]] (.tdf)
* [[TrueType]] (.ttf)
* [[Unified Font Object]] (.ufo, .ufoz)
* BSD / Sun [[vfont]]
* [[WOFF|Web Open Font Format]] (WOFF)
* [[WFN (font format)|WFN]]
* [[XFT]] Expert 3D Font

== Font metrics ==
* AFM, PFM: See [[Adobe Type 1]]
* [[TeX Font Metrics]] (.tfm)

== Glyph formats ==
* [[Glyph Interchange Format]] (.glif)

== Links ==

=== Fonts ===
* [http://comicneue.com/ Comic Neue: an attempted replacement for Comic Sans]
* [http://opendyslexic.org/ Open Dyslexic font; designed to be more easily readable by dyslexics]
* [http://reason.com/blog/2013/06/21/dont-want-the-nsa-to-read-your-email-use Don't Want the NSA to Read Your Documents? Use This Font.]

=== Tools ===
* [http://www.typesample.com/ Type Sample: tool for identifying and sampling web fonts]

=== Commentary ===
* [http://www.dustbury.com/archives/18596 Times is on my side]
* [http://www.slant.co/topics/67/~what-are-the-best-programming-fonts What are the best programming fonts?]
* [http://hivelogic.com/articles/top-10-programming-fonts Top 10 programming fonts]
* [http://www.cracked.com/blog/5-genuinely-offensive-font-choices-that-must-be-stopped/ 5 Genuinely Offensive Font Choices That Must Be Stopped]
* [http://www.cnn.com/2013/06/25/tech/social-media/image-macros-memes-impact-font/ This font has a big Impact on memes]
* [http://opentype.info/blog/2013/07/03/color-emoji-in-windows-8-1-the-future-of-color-fonts/ Color Emoji in Windows 8.1—The Future of Color Fonts?]
* [http://thenextweb.com/dd/2013/12/23/science-behind-fonts-make-feel/ The science behind fonts (and how they make you feel)]

=== Humor ===
* [http://www.mcsweeneys.net/articles/im-comic-sans-asshole I'm Comic Sans, Asshole!]
* [http://pixelambacht.nl/2015/sans-bullshit-sans/ Sans Bullshit Sans: leveraging the synergy of ligatures]

=== Other links ===
* O'Reilly, "Fonts and Encodings", Yannis Haralambous, ISBN 978-0-596-10242-5
* [http://www.kickstarter.com/projects/417863689/travelling-font-salesman-typographic-book Travelling Font Salesman - Typographic Book]
* [http://boingboing.net/2014/01/30/creatingafont.html Creating a font from a classic comic]
* [https://blog.wikimedia.org/2014/03/07/webfonts-making-wikimedia-projects-readable-for-everyone/ Webfonts: Making Wikimedia projects readable for everyone]
* [http://damieng.com/blog/2011/02/20/typography-in-8-bits-system-fonts Typography in 8 bits: System fonts]
* [http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/docs/formats.txt FreeType 2: Supported Font Formats]
* [https://github.com/file/file/blob/master/magic/Magdir/fonts Magic sequences for font formats recognized by file command]
* [https://answers.microsoft.com/en-us/windows/forum/windows_vista-windows_update/kb3013455-ms15-010-causes-font-corruption/8640d38d-19bd-46b6-9af0-6213c05107d3 KB3013455 (MS15-010) causes font corruption (Windows)]

Vfont

2021-01-20T00:35:07Z

John e: Created page with "{{FormatInfo |formattype=electronic |subcat=Fonts |released=~1988 }} '''vfont''' is a variable-sized bitmap font found on BSD and SunOS systems. Files may contain up to 256 ch..."

{{FormatInfo
|formattype=electronic
|subcat=Fonts
|released=~1988
}}
'''vfont''' is a variable-sized bitmap font found on BSD and SunOS systems. Files may contain up to 256 character bitmaps.

If a file extension is used, it tends to reflect the point size of the font (eg: .12, .14) rather than indicate the file type.

== Identification ==
Files begin with bytes {{magic|0x01 0x1E}} (little-endian systems) or {{magic|0x01 0x1E}} (big-endian systems). A program processing vfont data should be prepared to handle files with either byte order.

== Specifications ==
* [http://www-lehre.inf.uos.de/~sp/Man/_Man_SunOS_4.1.3_html/html5/vfont.5.html Format documentation from SunOS 4.1.3]

== Sample files ==
* [https://tuhs.v6sh.org/UnixArchiveMirror/Distributions/UCB/4.2BSD/] → vfont.tar.gz -- fonts in little-endian format.

Fonts

2021-01-20T00:23:40Z

John e:

{{FormatInfo
|formattype=electronic
|thiscat=Fonts
|image=Fonts.png
}}
Fonts describe how text looks (as opposed to how the characters are represented in text, which is the area of [[character encoding]]s). There are a number of formats that describe fonts for computers.

== Font formats ==
* [[Acorn Font]]
* [[Adobe Type 1]] (PostScript Type 1, ATM, .pfb, .pfm, .afm)
* [[Amiga bitmap font]]
* [[BDF]]
* [[BRFNT]]
* [[ByteMap font format]] [https://web.archive.org/web/20171031202737/http://bmf.wz.cz/bmf-format.htm]
* [[Calamus Font]] (.cfn)
* [[ChiWriter font]]
* [[CHR (Borland font)]]
* [[CID]], [[TFM]], [[OFM]], [[OVF]], [[OVP]], [[Metafont]] - TeX Fonts and support data
* [[CPI]]
* [[Daisy-Dot font]]
* [[Data Fork Suitcase font]] (OS X, .dfont)
* [[dfont]]
* [[Embedded OpenType]] (EOT)
* [[F3 font]]
* [[FIGlet font]]
* [[FNT (Windows Font)]]
* [[FontLab]] (.vfb)
* [[Fontographer]] (.fog)
* [[FON]] (Windows Font with NE/PE container)
* [[Font Suitcase]] (Mac pre-OS X, uses resource fork)
* [[GEM bitmap font]] (.fnt)
* [[GEOS Font]]
* [[GRASP font]]
* [[HEX (Unifont)]]
* [[IntelliFont]]
* [[Interlace Character Editor font]]
* [[MPlayer bitmap font]]
* [[Open Font Format]]
* [[OpenType]] (.otf)
* [[PaintJet soft font]] (.pjf)
* [[PC Screen Font]]
* [[PCF]]
* [[PFF2]] (.pf2)
* [[PFR]] (TrueDoc)
* [[PK font]]
* [[PostScript font]]
* [[sfnt]]
* [[Signum font]]
* [[SNF]]
* [[Speedo]] (.spd)
* [[Spline Font Database]] (.sfd)
* [[TexFont]] (.txf)
* [[TheDraw font]] (.tdf)
* [[TrueType]] (.ttf)
* [[Unified Font Object]] (.ufo, .ufoz)
* Sun [[vfont]]
* [[WOFF|Web Open Font Format]] (WOFF)
* [[WFN (font format)|WFN]]
* [[XFT]] Expert 3D Font

== Font metrics ==
* AFM, PFM: See [[Adobe Type 1]]
* [[TeX Font Metrics]] (.tfm)

== Glyph formats ==
* [[Glyph Interchange Format]] (.glif)

== Links ==

=== Fonts ===
* [http://comicneue.com/ Comic Neue: an attempted replacement for Comic Sans]
* [http://opendyslexic.org/ Open Dyslexic font; designed to be more easily readable by dyslexics]
* [http://reason.com/blog/2013/06/21/dont-want-the-nsa-to-read-your-email-use Don't Want the NSA to Read Your Documents? Use This Font.]

=== Tools ===
* [http://www.typesample.com/ Type Sample: tool for identifying and sampling web fonts]

=== Commentary ===
* [http://www.dustbury.com/archives/18596 Times is on my side]
* [http://www.slant.co/topics/67/~what-are-the-best-programming-fonts What are the best programming fonts?]
* [http://hivelogic.com/articles/top-10-programming-fonts Top 10 programming fonts]
* [http://www.cracked.com/blog/5-genuinely-offensive-font-choices-that-must-be-stopped/ 5 Genuinely Offensive Font Choices That Must Be Stopped]
* [http://www.cnn.com/2013/06/25/tech/social-media/image-macros-memes-impact-font/ This font has a big Impact on memes]
* [http://opentype.info/blog/2013/07/03/color-emoji-in-windows-8-1-the-future-of-color-fonts/ Color Emoji in Windows 8.1—The Future of Color Fonts?]
* [http://thenextweb.com/dd/2013/12/23/science-behind-fonts-make-feel/ The science behind fonts (and how they make you feel)]

=== Humor ===
* [http://www.mcsweeneys.net/articles/im-comic-sans-asshole I'm Comic Sans, Asshole!]
* [http://pixelambacht.nl/2015/sans-bullshit-sans/ Sans Bullshit Sans: leveraging the synergy of ligatures]

=== Other links ===
* O'Reilly, "Fonts and Encodings", Yannis Haralambous, ISBN 978-0-596-10242-5
* [http://www.kickstarter.com/projects/417863689/travelling-font-salesman-typographic-book Travelling Font Salesman - Typographic Book]
* [http://boingboing.net/2014/01/30/creatingafont.html Creating a font from a classic comic]
* [https://blog.wikimedia.org/2014/03/07/webfonts-making-wikimedia-projects-readable-for-everyone/ Webfonts: Making Wikimedia projects readable for everyone]
* [http://damieng.com/blog/2011/02/20/typography-in-8-bits-system-fonts Typography in 8 bits: System fonts]
* [http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/docs/formats.txt FreeType 2: Supported Font Formats]
* [https://github.com/file/file/blob/master/magic/Magdir/fonts Magic sequences for font formats recognized by file command]
* [https://answers.microsoft.com/en-us/windows/forum/windows_vista-windows_update/kb3013455-ms15-010-causes-font-corruption/8640d38d-19bd-46b6-9af0-6213c05107d3 KB3013455 (MS15-010) causes font corruption (Windows)]

LocoScript

2021-01-16T19:27:28Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Document
|subcat2=Word Processor
}}
'''LocoScript''' was the word processor bundled with the Amstrad PCW. There were four major versions for the PCW, and two for MSDOS.

8-bit versions:
* LocoScript 1 (1985) was bundled with the Amstrad PCW 8256/8512 (3" drives) and PcW 9256 and 10 (3.5" drives).
* LocoScript 2 (1987) was bundled with the Amstrad PCW 9512 (3" drive) and PcW 9512+ (3.5" drive), and was a common upgrade for the other models.
* LocoScript 3 (1993) was only available separately. It added semi-scalable fonts.
* LocoScript 4 (1996/7) was only available separately. It added support for images (in [[MDA]] format) and colour printing.

Most PCW documents, on either 3" or 3.5" floppy discs, are thus likely to be in LocoScript 1 or 2 format.

(The PcW 16 did not run LocoScript.)

While standard LocoScript had a relatively wide range of characters, there were some specialised versions for particular scripts, such as [http://www.fvempel.nl/manuals/araloco.pdf Euro-Arabic LocoScript] ([https://archive.org/details/8000-plus-magazine-37/page/n14/mode/1up see also]) and [http://www.habisoft.com/pcwwiki/doku.php?id=es:aplicaciones:advantage_hebrew_locoscript Hebrew LocoScript].

PC versions:
* LocoScript PC (later LocoScript PC Easy)
* LocoScript Professional

== File formats ==

Each major version of LocoScript changed the file format. Newer versions could read files from older versions, but not vice versa.

* LocoScript 1 is relatively well documented.
** [https://archive.org/details/35_Schneider_PC_International_1988-01 Schneider PC International 1988/01] (pp84-97) has a fairly detailed description of the LocoScript 1 format (in German), and provides Turbo Pascal source for a program LOCOCONV to convert it (updated in the [https://archive.org/details/44_Amstrad_PC_International_1988-10 1988/10 issue], pp92-97). Versions of that program exist in various places:
*** Werner Cirsovius' site ([https://web.archive.org/web/20160311002010/http://cirsovius.de/CPM/Projekte/TURBO-PASCAL/LOCO/LocoConv-en.html on Wayback machine]) had a copy. Wayback Machine doesn't have all the code, but the whole website is archived as a .7z [http://www.classiccmp.org/cpmarchives/index.php here].
*** A modified/translated version is on [http://fvempel.nl/domain.html Frank van Empel's site] (search for LOCOCON).
** Another, briefer description of the [https://www.seasip.info/Unix/Joyce/ls1frm.html LocoScript 1 file format] (in English)
** The character encoding used for the text portions is the [[Amstrad CP/M Plus character set]], except that the [[C1 controls]] range was used for control codes (different ones from the C1 control standard, which probably didn't exist yet) instead of the box-drawing characters of the CP/M Plus set.
* LocoScript 2 and up: no known descriptions (although plenty of software exists to read them). These versions had a greatly expanded character repertoire, more than can fit in a single-byte character set; see reference from [http://www.seasip.info/Unix/PSF/Amstrad/Scrchar/ John Elliott]. They share some of the same basic structure as LocoScript 1.
** Reportedly, Locomotive/LocoScript Software did produce format documentation for at least Loco 3 and 4 documents, the latter called ''The Structure of LocoScript 4 Documents'' and released under NDA; they don't seem to have made their way online. Refs: David Langford's columns in PCW Plus 114 (March 1996) and [https://archive.org/details/pcw-today-08/page/n37/mode/1up PCW Today issue 8 (Winter 97/98)].

LocoScript documents did not have a conventional file extension. The default filenames it suggested were <tt>DOCUMENT.000</tt>, <tt>DOCUMENT.001</tt>, etc.

== Identification ==

All known (PCW) LocoScript files start with the three ASCII bytes <tt>4A 4F 59</tt> ("JOY"), followed by two bytes identifying the major format version:
* <tt>01 00</tt>: Identified by LocoScript 4 as "LocoScript 2 document (Export)"
* <tt>01 01</tt>: LocoScript 1 (emitted by 1.1, 1.11e, 1.20, 1.42H)
* <tt>01 02</tt>: LocoScript 2 (emitted by 2.03, 2.12, 2.16, 2.28b)
* <tt>01 03</tt>: Identified by LocoScript 4 as "LocoScript 3 document (Export)"
* <tt>01 04</tt>: LocoScript 3 and 2.5x (emitted by 2.54, 3.06b)
* <tt>01 05</tt>: Identified by LocoScript 4 as "LocoScript 4 document (Export)"
* <tt>01 06</tt>: LocoScript 4 (emitted by 4.06, 4.10, 4.11)

In addition, the byte at offset 0x7F must be the 8-bit checksum of the preceding 127 bytes.

PC versions' documents seem to have a similar initial structure but start with the three ASCII bytes <tt>44 4F 43</tt> ("DOC"):
* LocoScript PC 1.08 (© 1990) comes with documents starting "DOC" followed by <tt>01 01</tt>.
* LocoScript Professional 2 Plus for MS-DOS (2.51) emits and reads documents starting with "DOC" followed by <tt>01 03</tt>.

Other files used by LocoScript have a similar header, with their own three-letter identification codes:
* "BMP" - Scalable font bitmap
* "CHR" - Printer font
* "CMB" - Dot matrix printer driver
* "DMN" - Disc Manager data (LocoScript PC)
* "DRV" - Driver
* "EDC" - Spellchecker dictionary
* "HLP" - Help file (LocoScript PC)
* "KBD" - Keyboard layout
* "KNO" - Settings
* "OML" - Overlay (Mail merge)
* "OSP" - Overlay (Spell checker)
* "OVL" - Overlay
* "PHR" - List of phrases
* "PRI" - Printer driver
* "SCR" - Screen characters
* "SDC" - Spellchecker dictionary
* "UDC" - Spellchecker dictionary
* "XCH" - Scalable font

== Converting LocoScript documents ==

Probably the most difficult problem with converting LocoScript documents into more readable formats is not the conversion process itself, but the fact that the majority of LocoScript files were stored on [[three inch disc|3-inch floppy disks]], which are now difficult to access. See the linked page for ideas for how to deal with this.

'''LocoLink''' (and the later 'LocoLink for Windows') is a hardware / software combination that connects a PC parallel port to the expansion connector of an Amstrad PCW, and provides the software tools for both transferring LocoScript documents to the PC, as well as converting them to RTF or TXT formats. Note that the later PcW 16 has part of LocoLink built-in, and while this means documents can be transferred from an older PCW to a PcW 16 and then onto a PC, PcW 16 computers are few and far between, making this option unlikely.

PCW LocoScript used CP/M format for its discs, so LocoScript files are likely to be found in a [[CP/M file system]].

Once you are at the stage of having individual document files:

* [https://ai.ansible.uk/ailink.html AILINK] by Ansible Information is former commercial software for Windows, now free, which can convert PCW LocoScript 1-4 documents to more modern formats such as RTF, keeping most of the formatting codes and special characters (not Greek and Cyrillic). It can do bulk conversions. If you're not trying to read actual floppy discs with it, it should work fine under modern Windows. It runs adequately on Linux under [[Wine]].
* The PC versions of LocoScript could read PCW files, and had an export function to other formats, but are no longer particularly easy to acquire and run themselves.

== Links ==
* [http://www.locoscript.co.uk/ Publisher's website]
** [https://web.archive.org/web/20141218181748/http://locoscript.co.uk/ 2014 archive]

[[Category:Amstrad]]

Crunch

2021-01-14T21:05:19Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Compression
|extensions={{ext|?z?}}, {{ext|zzz}}
}}
:''This article is about the CP/M compressed file format. See the [[#Disambiguation|disambiguation section]] for other "Crunch" formats.''

[[Crunch]] was a method of compressing single files popular on [[CP/M]], devised by Steve Greenberg circa 1986. It superseded [[Squeeze]] and was succeeded by [[CrLZH]], and crunched files were common in [[LBR]] archives. The underlying compression uses the [[LZW]] algorithm, combined with [[run-length encoding]].

Similar to [[Squeeze]], crunched files were signified in CP/M's 8.3 filename format by replacing the middle letter of the extension with Z (.?Z?), with the extension .ZZZ used for corner cases such as a blank extension.

There are two versions of the compressed data format, and not all decompressors support both. The new format is apparently more common.

== Disambiguation ==
Not to be confused with:
* The "crunched" compression methods used in [[ARC (compression format)|ARC]] format. These methods are possibly related to those used by CP/M Crunch, but the file formats are not otherwise similar.
* [[Crunch-Mania]] - An Amiga file compression utility
* [[Cruncher]] - An executable compression utility for DOS, by Ori Berger [http://cd.textfiles.com/simtel/simtel20/MSDOS/EXECOMP/CRUNCH10.ZIP]
* CRUNCH - A compression optimization utility for DOS, by Bruce Gavin. It does not appear to have any native file formats. [http://cd.textfiles.com/20mnn/ARCHIVE/CRUNCH10.ZIP]
* Crunch - An old [[ARC (compression format)|ARC]] compression utility by Richard P. Byrne [http://cd.textfiles.com/rbbsv3n1/d86v/crunch.zip]
* CRUNCH - A PKARC automation utility by Chuck Zulker [http://cd.textfiles.com/megarom/megarom1/ARC_LBR/CRUNCH.ZIP]

== See also ==
* [[Squeeze]] - predecessor
* [[CrLZH]] - successor
* [[LBR]] - container
* [[ZSQ (LZW compression)‎]] - Possibly related
* [[Zoo Z format]] - Same file naming convention

== Format details ==
Note that, as explained in the format documentation, the "filename" field contains not only the filename, but also extension data. If extension data exists, the filename extension is padded with spaces until it is exactly three characters long.

In archives originating on CP/M systems, the high bit of each byte in the filename field may contain encoded CP/M file attributes. To extract the original filename, each byte should be masked with 0x7F.

== Identification ==
Files begin with bytes {{magic|76 fe}}.

== Specifications ==

* The file header is described in the text file LZDEF20.DOC shipped with [http://www.classiccmp.org/cpmarchives/cpm/mirrors/oak.oakland.edu/pub/sigm/vol294/crunch20.lbr CRUNCH20.LBR].
** An extracted copy is provided [[Crunch/LZDEF20.DOC|here]].
** Note that the file header follows a similar/compatible structure to [[CrLZH]]. It was derived from [[Squeeze]], but bears only a little resemblance to it.
* FIXME: is the exact compression algorithm documented anywhere?
** CRUNCH20.DOC shipped in CRUNCH20.LBR says: ''It embodies all of the concepts employed in the UNIX COMPRESS / ARC512 algorithm, but is additionally enhanced by a "metastatic code reassignment" facility. This is one of several concepts I am developing as part of an effort to advance data compression techniques beyond current performance limits. I believe this is the first time this principle has been proposed or implemented.''
** See also "Technical Abstract" by Steven Greenberg, 16 November 1986: [http://www.classiccmp.org/cpmarchives/cpm/mirrors/oak.oakland.edu/pub/cpm/squsq/crunch.abs CRUNCH.ABS]

== Tools ==

* [[CFX]] (DOS/Unix)
* [http://www.svgalib.org/rus/lbrate.html lbrate] by Russell Marks, c. 2001 (Unix, GPL2)
* On CP/M (or emulators):
** The canonical tools were CRUNCH and UNCR. Possibly Greenberg's last version (Feb 1988) is v2.4: [http://www.classiccmp.org/cpmarchives/cpm/mirrors/oak.oakland.edu/pub/cpm/squsq/crunch24.lbr CRUNCH24.LBR], [http://www.classiccmp.org/cpmarchives/cpm/mirrors/oak.oakland.edu/pub/cpm/squsq/crnch24s.lbr CRNCH24S.LBR] (source code).
** The later LT31 deals with extracting from all of [[Squeeze]], [[Crunch]], [[CrLZH]] and [[LBR]] formats. Widely available in CP/M archives, e.g. [http://www.classiccmp.org/cpmarchives/cpm/mirrors/oak.oakland.edu/pub/cpm/arc-lbr/lt31.lbr LT31.LBR]
* [[The Unarchiver]]

== Sample files ==
* [http://www.classiccmp.org/cpmarchives/ftp.php?b=cpm/mirrors/oak.oakland.edu/pub/cpm/ OAK CP/M archive] → .../*.?z?
* Found in many [[LBR#Sample files|LBR]] files. Note that you may have to tell your LBR utility not to decompress them (e.g. <code>lbrate -n</code>).

[[Category:File formats with too many extensions]]
[[Category:CP/M]]

LocoScript

2021-01-12T21:03:24Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Document
|subcat2=Word Processor
}}
'''LocoScript''' was the word processor bundled with the Amstrad PCW. There were four major versions for the PCW, and two for MSDOS.

8-bit versions:
* LocoScript 1 (1985) was bundled with the Amstrad PCW 8256/8512 (3" drives) and PcW 9256 and 10 (3.5" drives).
* LocoScript 2 (1987) was bundled with the Amstrad PCW 9512 (3" drive) and PcW 9512+ (3.5" drive), and was a common upgrade for the other models.
* LocoScript 3 (1993) was only available separately. It added semi-scalable fonts.
* LocoScript 4 (1996/7) was only available separately. It added support for images (in [[MDA]] format) and colour printing.

Most PCW documents, on either 3" or 3.5" floppy discs, are thus likely to be in LocoScript 1 or 2 format.

(The PcW 16 did not run LocoScript.)

While standard LocoScript had a relatively wide range of characters, there were some specialised versions for particular scripts, such as [http://www.fvempel.nl/manuals/araloco.pdf Euro-Arabic LocoScript] and [http://www.habisoft.com/pcwwiki/doku.php?id=es:aplicaciones:advantage_hebrew_locoscript Hebrew LocoScript].

PC versions:
* LocoScript PC (later LocoScript PC Easy)
* LocoScript Professional

== File formats ==

Each major version of LocoScript changed the file format. Newer versions could read files from older versions, but not vice versa.

* LocoScript 1 is relatively well documented.
** [https://archive.org/details/35_Schneider_PC_International_1988-01 Schneider PC International 1988/01] (pp84-97) has a fairly detailed description of the LocoScript 1 format (in German), and provides Turbo Pascal source for a program LOCOCONV to convert it (updated in the [https://archive.org/details/44_Amstrad_PC_International_1988-10 1988/10 issue], pp92-97). Versions of that program exist in various places:
*** Werner Cirsovius' site ([https://web.archive.org/web/20160311002010/http://cirsovius.de/CPM/Projekte/TURBO-PASCAL/LOCO/LocoConv-en.html on Wayback machine]) had a copy. Wayback Machine doesn't have all the code, but the whole website is archived as a .7z [http://www.classiccmp.org/cpmarchives/index.php here].
*** A modified/translated version is on [http://fvempel.nl/domain.html Frank van Empel's site] (search for LOCOCON).
** Another, briefer description of the [https://www.seasip.info/Unix/Joyce/ls1frm.html LocoScript 1 file format] (in English)
** The character encoding used for the text portions is the [[Amstrad CP/M Plus character set]], except that the [[C1 controls]] range was used for control codes (different ones from the C1 control standard, which probably didn't exist yet) instead of the box-drawing characters of the CP/M Plus set.
* LocoScript 2 and up: no known descriptions (although plenty of software exists to read them). These versions had a greatly expanded character repertoire, more than can fit in a single-byte character set; see reference from [http://www.seasip.info/Unix/PSF/Amstrad/Scrchar/ John Elliott]. They share some of the same basic structure as LocoScript 1.
** Reportedly, Locomotive/LocoScript Software did produce format documentation for at least Loco 3 and 4 documents, the latter called ''The Structure of LocoScript 4 Documents'' and released under NDA; they don't seem to have made their way online. Refs: David Langford's columns in PCW Plus 114 (March 1996) and [https://archive.org/details/pcw-today-08/page/n37/mode/1up PCW Today issue 8 (Winter 97/98)].

LocoScript documents did not have a conventional file extension. The default filenames it suggested were <tt>DOCUMENT.000</tt>, <tt>DOCUMENT.001</tt>, etc.

== Identification ==

All known (PCW) LocoScript files start with the three ASCII bytes <tt>4A 4F 59</tt> ("JOY"), followed by two bytes identifying the major format version:
* <tt>01 00</tt>: Identified by LocoScript 4 as "LocoScript 2 document (Export)"
* <tt>01 01</tt>: LocoScript 1 (emitted by 1.1, 1.11e, 1.20, 1.42H)
* <tt>01 02</tt>: LocoScript 2 (emitted by 2.03, 2.12, 2.16, 2.28b)
* <tt>01 03</tt>: Identified by LocoScript 4 as "LocoScript 3 document (Export)"
* <tt>01 04</tt>: LocoScript 3 (emitted by 3.06b)
* <tt>01 05</tt>: Identified by LocoScript 4 as "LocoScript 4 document (Export)"
* <tt>01 06</tt>: LocoScript 4 (emitted by 4.06, 4.10, 4.11)

In addition, the byte at offset 0x7F must be the 8-bit checksum of the preceding 127 bytes.

PC versions' documents seem to have a similar initial structure but start with the three ASCII bytes <tt>44 4F 43</tt> ("DOC"):
* LocoScript PC 1.08 (© 1990) comes with documents starting "DOC" followed by <tt>01 01</tt>.
* LocoScript Professional 2 Plus for MS-DOS (2.51) emits and reads documents starting with "DOC" followed by <tt>01 03</tt>.

Other files used by LocoScript have a similar header, with their own three-letter identification codes:
* "BMP" - Scalable font bitmap
* "CHR" - Printer font
* "CMB" - Dot matrix printer driver
* "DMN" - Disc Manager data (LocoScript PC)
* "DRV" - Driver
* "EDC" - Spellchecker dictionary
* "HLP" - Help file (LocoScript PC)
* "KBD" - Keyboard layout
* "KNO" - Settings
* "OML" - Overlay (Mail merge)
* "OSP" - Overlay (Spell checker)
* "OVL" - Overlay
* "PHR" - List of phrases
* "PRI" - Printer driver
* "SCR" - Screen characters
* "SDC" - Spellchecker dictionary
* "UDC" - Spellchecker dictionary
* "XCH" - Scalable font

== Converting LocoScript documents ==

Probably the most difficult problem with converting LocoScript documents into more readable formats is not the conversion process itself, but the fact that the majority of LocoScript files were stored on [[three inch disc|3-inch floppy disks]], which are now difficult to access. See the linked page for ideas for how to deal with this.

'''LocoLink''' (and the later 'LocoLink for Windows') is a hardware / software combination that connects a PC parallel port to the expansion connector of an Amstrad PCW, and provides the software tools for both transferring LocoScript documents to the PC, as well as converting them to RTF or TXT formats. Note that the later PcW 16 has part of LocoLink built-in, and while this means documents can be transferred from an older PCW to a PcW 16 and then onto a PC, PcW 16 computers are few and far between, making this option unlikely.

PCW LocoScript used CP/M format for its discs, so LocoScript files are likely to be found in a [[CP/M file system]].

Once you are at the stage of having individual document files:

* [https://ai.ansible.uk/ailink.html AILINK] by Ansible Information is former commercial software for Windows, now free, which can convert PCW LocoScript 1-4 documents to more modern formats such as RTF, keeping most of the formatting codes and special characters (not Greek and Cyrillic). It can do bulk conversions. If you're not trying to read actual floppy discs with it, it should work fine under modern Windows. It runs adequately on Linux under [[Wine]].
* The PC versions of LocoScript could read PCW files, and had an export function to other formats, but are no longer particularly easy to acquire and run themselves.

== Links ==
* [http://www.locoscript.co.uk/ Publisher's website]
** [https://web.archive.org/web/20141218181748/http://locoscript.co.uk/ 2014 archive]

[[Category:Amstrad]]

Graphics

2017-04-07T21:23:36Z

John e: /* Icon, Cursor, and Avatar files */

{{FormatInfo
|formattype=electronic
|thiscat=Graphics
|image=Mona Lisa, by Leonardo da Vinci, from C2RMF retouched.jpg
|caption=Mona Lisa
}}
__NOTOC__
[[Electronic_File_Formats|Electronic Formats]] concerned with Image Data.

''See also:''
* [[3D and CAD/CAM Models]]
* [[Cameras and Digital Image Sensors]]
* [[Fonts]]
* [[Geospatial]]
* [[Page description languages]]
* [[Video]]

== Adjustment data ==

* [[AAE sidecar format]] (Apple iOS 8 / OS X Yosemite)

== Animated image formats ==
See also [[Video]].

* [[NEOchrome Animation|ANI (NEOchrome)]]
* [[Windows Animated Cursor|ANI (Windows Animated Cursor)]]
* [[ANIM]]
* [[Animatic Film‎]] (.flm)
* [[ANSIMation]]
* [[APNG]]
* [[BAM]] (Infinity Engine)
* [[Cyber Paint Sequence]] (.seq)
* [[DeluxePaint Animation]] (ANM or Anim)
* [[DVM]] (DVM Movie/Magic Software DVM)
* [[EVA]]
* [[FLIC]] (FLI, FLC)
* [[GIF]]
* [[GIFV]]
* [[GFY]]
* [[GRASP GL]]
* [[IFF-DEEP]]
* [[Imagic Film/Picture]] (Atari ST frames used in animation)
* [[JPX]]
* [[MNG]]
* [[PGX (Portfolio)]]
* [[PICS]]
* [[QTL]] (YUV SECAM or PAL image)
* [[Spectrum 512 Anispec‎]]
* [[SWF]] (Flash)
* [[XNG]]

== Character-based graphics ==
See [[Character encoding]] for details of character sets, some of which include graphical or line-and-box-drawing characters.

* [[ANSI Art]] (.ans)
* [[AN2]]
* [[ArtWorx Data Format]] (.adf)
* [[ASCII Art]]
* [[AVATAR]] (FidoNet)
* [[BIN (Binary Text)]]
* [[BSAVE Image]]
* [[iCEDraw]] (.idf)
* [[PCBoard]] (.pcb)
* [[RIPscrip]] (or RIPscript)
* [[TheDraw Save File]] (.td)
* [[TUNDRA]] (.tnd)
* [[XBIN]] (.xb)

== Colors ==
(Profiles, color spaces, palettes, swatches)
* [[Adobe RGB (1998)]]
* [[Adobe Swatch Exchange]] (.ase)
* [[Atari ST color palette]]
* [[Commodore 64 color palette]]
* [[DNG camera profile]]
* [[GIMP Palette]]
* [[ICC profile]]
* [[Photoshop Curve]]
* [[Photoshop Transfer Function]]
* [[RIFF Palette File]]
* [[sRGB]]
* [[YUV]]

== Comics creation ==
* [[Manga Studio]]

== Compression ==

Special-purpose compression algorithms and formats that may be used in multiple image file formats.

See also [[Compression]], for general-purpose algorithms.

* [[CCITT Group 3]]
* [[CCITT Group 4]]
* [[DCT compression]] (e.g. lossy [[JPEG]])
* [[JBIG]]
* [[JBIG2]]
* [[JPEG]]
* [[JPEG 2000 codestream]]
* [[JPEG-LS]]
* [[Lepton]]
* [[LOCO-I]] (Low Complexity Lossless Compression for Images)
* [[Mixed Raster Content]] (MRC, T.44)
* [[Modified Huffman]]
* [[Modified Modified READ]]
* [[Modified READ]]
* [[NeXT 2-bit RLE]]
* [[PackBits]]
* [[packJPG]] (.pjg)
* [[packPNM]] (.ppn)
* [[Rawzor]]
* [[Run-length colour encoding]] (T.45)
* [[Run-length encoding]]
* [[ThunderScan compression]]
* [[Wavelet compression]]

== Icon, Cursor, and Avatar files ==
(Formats often used for icons, cursors, avatars, thumbnails, etc.)

* [[Amiga Workbench icon]] (.info)
* [[AMOS Icon Bank]]
* [[Windows Animated Cursor|ANI (Windows Animated Cursor)]]
* [[Apple File and App Icons]]
* [[CUR]] (Microsoft Windows cursors)
** [[Windows 1.0 Cursor]]
* [[DEGAS Elite icon]] (.icn)
* [[EPOC AIF]]
* [[Favicon]]
* [[GEM resource file]] (.rsc)
* [[GlowIcons]]
* [[Haiku Vector Icon Format]]
* [[HP 100LX/200LX icon]] (.icn)
* [[ICDRAW icon]]
* [[ICNS]] (Apple/Macintosh Icon)
* [[ICO]] (Microsoft Windows icons)
** [[Windows 1.0 Icon]]
* [[Icon library]] (.icl)
* [[iThmb]] (iOS thumbnail images)
* [[Micrografx Icon]] (.icn)
* [[NeoDesk icon]] (.nic)
* [[NewIcons]]
* [[Nokia Group Graphic]] (.ngg)
* [[Nokia Logo Manager bitmap‎]] (.nlm)
* [[Nokia Operator Logo]] (.nol)
* [[Nokia Picture Message]] (.npm)
* [[Nokia Startup Logo]] (.nsl)
* [[OLPC 565]]
* [[OS/2 Icon]]
* [[OS/2 Pointer]] (.ptr)
* [[PaintShop Pro Browser Cache]] (pspbrwse.jbf)
* [[Photoshop Thumbnail Cache]]
* [[RIPscrip Icon]] (RIPterm Image, .icn)
* [[Sony Mavica 411]]
* [[Sun icon]]
* [[SuperJPG thumbnail cache]] (superjpg.tnc)
* [[Windows thumbnail cache]] (Thumbs.db)
* [[Xbox Live Avatar]]
* [[Xcursor]]
* [[X-Face]]
* [[XV thumbnail]]
* [[ZoomBrowser Ex thumbnail cache]] (ZbThumbnail.info)

== Metadata Formats ==

* [[Exif]]
* [[IPTC]] (or NAA)
* [[MakerNote]]
* [[MIX]]
* [[Photoshop Image Resources]]
* [[SAUCE]]
* [[XMP]]

== Programming languages (graphic-specific) ==

* [[CEEMAC]]
* [[High Level Shading Language]] (HLSL) (uses byte array header files)
* [[OpenGL Shading Language]] (GLSL)
* [[Processing]]

== Raster Graphics Formats ==

* [[AAI]] (Dune image)
* [[Abekas YUV]] (.yuv) (Diskus and Quantel QNV varieties of YUV files are apparently similar)
* [[Ability Office PhotoPaint]] (.apx)
* [[Acorn Sprite]]
* [[ADRG]]
* [[AIPD]]
* [[Alias PIX]]
* [[Alpha Microsystems BMP]]
* [[Amber ARR Bitmap Image]]
* [[AMOS Picture Bank]]
* [[AMOS Sprite Bank]]
* [[Analyze AVW]]
* [[Aperio SVS]]
* [[Apple volume label image]]
* [[Applixware Bitmap]]
* [[ARF (Axon Raw Format)]]
* [[ART (AOL compressed image)]]
* [[ART (PFS: First Publisher)]]
* [[Async Professional Fax]] (.apf)
* [[AVS X image]]
* [[Award BIOS logo]]
* [[AWD (Artweaver)]]
* [[AWD (At Work Document)]]
* [[BCIF]]
* [[BEF]]
* [[BFLI]]
* [[BGI image]]
* [[BIF (Image Alchemy)]]
* [[BigTIFF]]
* [[BioRad confocal image]]
* [[BMP]] (Windows BMP and OS/2 BMP)
* [[Bob ray tracer bitmap]]
* [[BPG]]
* [[BRender PIX]]
* [[BSAVE Image]]
* [[BSB]] (BSB/KAP)
* [[CADRG]]
* [[Calamus Raster Graphic]] (.crg)
* [[CALS raster]]
* [[Canvas (Atari)‎]] (.cpt, .cnv)
* [[Cartesian Perceptual Compression]] (CPC)
* [[CD5]] (Chasys Draw)
* [[CgBI]]
* [[Cineon]]
* [[Cisco IP Phone image]]
* [[Cloé picture]]
* [[CMU Andrew Toolkit image]] (.cmu)
* [[CMU Window Manager bitmap]]
* [[COKE (Atari Falcon)]]
* [[ColoRIX]] (RIX)
* [[CompuServe RLE]]
* [[CompW]]
* [[Corel Photo-Paint image]] (.cpt)
* [[Crack Art]] (.ca1, .ca2, .ca3)
* [[CUPS Raster]]
* [[CUT (Amstrad)]]
* [[DCS]] (Desktop Color Separation)
* [[DCX]] (ZSoft IBM PC multi-page Paintbrush)
* [[DEGAS image]] (.pi1, .pi2, .pi3, .pc1, .pc2, .pc3)
* [[DESR VFF]]
* [[DGI (Digi-Pic)]]
* [[DICOM]] (.dcm)
* [[Diddle sketch]]
* [[DiddleBug sketch]]
* [[DirectDraw Surface]] (.dds)
* [[DjVu]]
* [[DNG]]
* [[Doodle (Atari)]] (.doo)
* [[Doodle! (C64)]] (.dd, .jj)
* [[Doré Raster]]
* [[DPX]] (SMTPE DPX)
* [[Dr. Halo]] (.cut)
* [[DVI]] (Intel DVI, Digital Video Interface, Intel Real-Time Video)
* [[ECW]] (Enhanced Compression Wavelet)
* [[EggPaint]] (.trp)
* [[Enhanced Simplex]] (.esm)
* [[EPOC MBM]] (Symbian Multibitmap)
* [[EPOC Sketch]]
* [[Epson Printer Bitmaps]]
* [[ERDAS Imagine IMG]]
* [[ERDAS LAN/GIS]]
* [[ER Mapper Raster]] (.ers)
* [[Extended DEGAS image]]
* [[FaceSaver]]
* [[Falcon True Color]] (.ftc)
* [[farbfeld]]
* [[FAXX]] (IFF-FAXX)
* [[FBM image]] (Fuzzy Bitmap)
* [[FFLI]]
* [[FIASCO]]
* [[FIF (Fractal Image Format)]]
* [[FlashPix]] (.fpx)
* [[Flexible Image Transport System]] (FITS)
* [[Flexible Line Interpretation]] (FLI)
* [[FLIF]]
* [[FRA (Fractint)]]
* [[Freedom of Press]]
* [[FSH (EA Sports)]]
* [[G9B]]
* [[GEM Raster]] (.img)
* [[geoPaint]]
* [[GeoTIFF]]
* [[GIF]] (Graphics Interchange Format)
* [[GIMP Animated Brush]] (.gih)
* [[GIMP Brush]] (.gbr)
* [[GIMP Pattern]] (.pat)
* [[GLE]]
* [[GoDot]] (.4bt)
* [[GodPaint]] (.god)
* [[Graph Saurus]]
* [[GrayPaint]]
* [[GRF (Amstrad)]]
* [[GRFX]]
* [[GRIB]] (Gridded Binary)
* [[GROB]]
* [[GX1]]
* [[GX2]]
* [[HIPS]]
* [[HMR]] (Bentley Systems bitmap file, connected in some way to GeoTIFF)
* [[HP Paintjet]]
* [[HS2 (POSTERING)|HS2]]
* [[HSI JPEG]]
* [[HSI Raw]]
* [[HTC splashscreen]] (also known as NB format)
* [[IBM KIPS bitmap]]
* [[ICR (NCSA Telnet)]]
* [[IFF-DEEP]]
* [[ILBM]] (IFF, LBM, HAM, ACBM, etc.)
* [[Image Cytometry Standard]] (.ics)
* [[Image Exchange Format]]
* [[Imagic Film/Picture]] (Atari ST)
* [[IMG/HDR]] (Analyze 7.5)
* [[Img Software Set]]
* [[ImgStar]]
* [[IndyPaint]] (.tru)
* [[Inset PIX]]
* [[InShape IIM]]
* [[Intergraph Raster]]
* [[Interleaf image]]
* [[IPI]]
* [[IPLab]] (Image Processing Lab)
* [[IRIS CMYK Front End Processor CT]]
* [[Island Graphics TIFF]]
* [[IWC (WaveL)]]
* [[J6I]] (Ricoh Digital Camera image file)
* [[JBIG]]
* [[JBIG2]]
* [[JEDMICS C4]]
* [[Jeff's Image Format]]
* [[JFIF]] (JPEG File Interchange Format)
* [[JNG]] (JPEG Network Graphics)
* [[Jovian Logic VI]]
* [[JP2]] (JPEG 2000 Part 1 Annex I)
* [[JPC (LuraWave)]]
* [[JPEG]] (JPEG Interchange Format, .jpg)
* [[JPEG 2000]]
* [[JPEG 2000 codestream]] (.j2k, .j2c, .jpc)
* [[JPEG-HDR]]
* [[JPEG-LS]]
* [[JPEG XR]] (HD Photo)
* [[JPEG XT]]
* [[JPM]] (JPEG 2000 Part 6: Compound Image Format)
* [[JPS]]
* [[JPX]] (JPEG 2000 Part 2: Extensions, .jpf)
* [[KIFF]]
* [[KiSS CEL]]
* [[KoalaPainter]] (.koa, .gg)
* [[Kolor Raw]] (.kro)
* [[Krita]] (.kra)
* [[KTX]]
* [[LazPaint]] (.lzp)
* [[LIFF]] (Openlab Layered Image File Format)
* [[Lightning Strike]] (.cod)
* [[Lossless JPEG (original)]]
* [[Lotus Manuscript graphics]] (.bit)
* [[LSM]] (Zeiss Light Speed Microscope)
* [[LSS16]]
* [[Lucasfilm picture]] (.lff)
* [[Lumena CEL]]
* [[Lumena PIX/BPX]]
* [[LuraDocument Format]] (.ldf)
* [[LuraWave]] (LWF)
* [[MacPaint]]
* [[Magick Persistent Cache]] (MPC)
* [[MAKIchan Graphics]] (.mag)
* [[Maya IFF]]
* [[MDA|MDA/MDP]] (MicroDesign Area/Page)
* [[MDI]] (Microsoft Office Document Imaging)
* [[MegaPaint BLD]]
* [[MetaMorph Stack]] (.stk)
* [[MGR bitmap]]
* [[Microsoft Image Composer]] (.mic)
* [[MIF (MSX)]]
* [[MIFF]] (Magick Image File Format)
* [[MIX (Picture It!)]]
* [[Mixed Raster Content]] (MRC, T.44)
* [[MRF (Monochrome Recursive Format)]]
* [[MrSID]]
* [[MSP (Microsoft Paint)]]
* [[MSX BASIC graphics]]
* [[MTV ray tracer bitmap]]
* [[Multi Palette Picture]] (MPP)
* [[Multi-Picture Format]] (MPO)
* [[NASA Raster Metafile]]
* [[National Imagery Transmission Format]] (NITFS, NITF, .ntf)
* [[NEOchrome]] (.neo)
* [[Nero CoverDesigner]] (.ncd, .nct)
* [[Netpbm formats]] (PBM, PGM, PPM, PNM)
* [[The Newsroom|Newsroom, The]]
* [[NIFF (Navy Image File Format)]]
* [[NIFF (xloadimage)]]
* [[NIST IHead]] (.pct)
* [[NV12]] (a YUV format)
* [[OpenEXR]] (.exr)
* [[OpenRaster]] (.ora)
* [[OS/2 Bitmap Array]]
* [[OS/2 bitmap family]]
* [[OS/2 Boot Logo]]
* [[OTA bitmap]] (Nokia Over The Air, .otb)
* [[Paint.NET image]] (.pdn)
* [[PaintShop Pro]] (.psp, .jsl, .pfr, .tub)
* [[Palette Master]]
* [[Palm bitmap]]
* [[Palm Database ImageViewer]] / FireViewer PDB (.pdb)
* [[PAX (Pick Ax)]]
* [[PCIF]] (.pcf)
* [[PCO B16]]
* [[PCPaint CLP]]
* [[PCPaint PIC]] (a.k.a. Pictor)
* [[PCX]] (PC Paintbrush)
* [[PDS]] (NASA Planetary Data System, .img, .imq)
* [[PDS4]]
* [[PFM (Portable Float Map)]]
* [[PFS (Portable Floatmap Stream)]]
* [[PGC (Portfolio Graphics Compressed)]]
* [[PGF (Portfolio Graphics)]]
* [[PGF (Progressive Graphics File)]]
* [[PGX (JPEG 2000)]]
* [[Photo CD]] (.pcd)
* [[PhotoChrome]] (.pcs)
* [[PhotoDeluxe]] (.pdd)
* [[PhotoParade slideshow]] (.php, .4pp)
* [[Photoshop brush]] (.abr)
* [[Pi (image format)|Pi]]
* [[PIC (Yanagisawa)]]
* [[PIC2]]
* [[Picture Packer]]
* [[Picture Publisher]]
* [[Pixar picture]] (.pxr)
* [[Pixia]] (.pxa)
* [[PLD (PhotoLine)]]
* [[PM (XV image)]]
* [[PNG]] (Portable Network Graphics)
* [[Pocket PC Bitmap]] (.2bp)
* [[Poser Bump Map]] (.bum)
* [[Portable Arbitrary Map]] (PAM)
* [[Portable Bitmap Format]] (PBF)
* [[PRF (Fastgraph)]]
* [[PRF (Polychrome Recursive Format)]]
* [[Printfox bitmap]]
* [[PrintMaster]]
* [[The Print Shop|Print Shop, The]]
* [[Prism Paint]] (.pnt)
* [[PSB]] (Adobe Photoshop, large format)
* [[PSD]] (Adobe Photoshop)
* [[PSF (PhotoStudio)]]
* [[Psion PIC]]
* [[PTG]] (ArtRage)
* [[Puzzle image (X11)]]
* [[PWC (Piecewise-Constant Image Model)]]
* [[PWG Raster]]
* [[PXM (Pixelmator)]]
* [[Q0]]
* [[QDV (Giffer)]]
* [[QRT Ray Tracer bitmap]]
* [[QTIF]] (QuickTime image file, .qif)
* [[Quantel VPB image]]
* [[Radiance HDR]] (RGBE, XYZE, .hdr, .pic)
* [[Raw bitmap]]
* [[RDIB]]
* [[RLA]] (Wavefront)
* [[SBIG CCDOPS image]]
* [[Scitex CT]]
* [[SCR (ZX Spectrum)]]
* [[ScreenShot Hack PDB]]
* [[Seattle FilmWorks]] (.sfw, .pwp)
* [[Secret Photos puzzle]] (.xp0)
* [[Segmented Hypergraphics]] (.shg, .mrb)
* [[SGI (image file format)|SGI]] (IRIS, RGB)
* [[SGX]] (SView Graphics, SuperView Graphics)
* [[Sinclair QL screen]]
* [[Sixel]]
* [[Slow-scan television]] (.hrz)
* [[Softimage PIC]]
* [[Spectrum 512 Extended‎]] (.spx)
* [[Spectrum 512 formats]] (.spu, .spc, .sps)
* [[SPIFF]] (Still Picture Interchange File Format)
* [[Spooky Sprites]]
* [[STAD PAC]]
* [[Standard Archive Format]] (military missile data format that includes images among other data)
* [[STOS memory bank]] (.mbk)
* [[Structured Fax File]] (.sff)
* [[Sun Raster]] (.ras, .sun)
* [[Sun TAAC image]]
* [[Synu]] (Synthetic Universe)
* [[TAP (Tencent)]]
* [[TealPaint PDB]]
* [[Technicolor Dream]]
* [[TGA]] (Truevision Targa image)
* [[TIFF]] (Tagged Image File Format)
* [[TIFF/EP]]
* [[TIFF-FX]]
* [[TIFF/IT]]
* [[TIM (PlayStation graphics)]]
* [[Tiny Stuff]]
* [[TI picture file]]
* [[TLG (KiriKiri)|TLG]] (associated with [[KiriKiri Adventure Game System]])
* [[Unirast]] (Apple AirPrint)
* [[Utah RLE]]
* [[Valve Texture Format]] (.vtf)
* [[VBM (VDC BitMap)]]
* [[VEGX]]
* [[Verity Image]] (.vif)
* [[V.Flash PTX]]
* [[VICAR]]
* [[VIFF]] (Khoros Visualization, .xv)
* [[VIPS]] (.v)
* [[Vista data file]]
* [[VITec]]
* [[Vivid IMG]]
* [[VORT file]]
* [[WBMP]] (Wireless Bitmap)
* [[WebP]]
* [[Webshots picture]] (.wbz, .wb1, .wbd, .wbc, .wbp)
* [[WhyPic]] (.ypc)
* [[Wigmore Artist 64]]
* [[Windows DDB]]
* [[WinMiPS]]
* [[Winzle Puzzle]]
* [[WOBA]] (bitmap data extracted from a [[HyperCard stack]])
* [[Word for DOS screen capture]] (.scr)
* [[WPB (openCanvas)]]
* [[WSQ]]
* [[XBM]] (X BitMap)
* [[XCF]] (GIMP image)
* [[Xerox Doodle brush]]
* [[Xerox EDMICS-MMR]]
* [[Xerox EDMICS-RLC]]
* [[XGA (Falcon)]]
* [[XIFF]]
* [[Xim]]
* [[XLD4]] (.q4)
* [[XPM]] (X PixMap)
* [[XWD]] (X Window Dump)
* [[YBM]] (Bennet Yee's face format)
* [[Zeiss BIVAS]]
* [[Zoomify PFF]]
* [[Zoomify ZIF]]

== Raw camera formats ==
For raw image (digital negative) formats used by cameras (such as .3fr, .ari, .arw, .bay, .cap, .cr2, .crw, .eip, .dcr, .dcs, .drf, .dng, .eip, .erf, .fff, .iiq, .k25, .kdc, .mef, .mos, .mrw, .ndf, .nef, .nrw, .orf, .pef, .ptx, .pxn, .r3d, .raf, .raw, .rw2, .rwl, .rwz, .sr2, .srf, .srw, .x3f), see [[Cameras and Digital Image Sensors]].

== Software, utilities, libraries, and APIs for graphic manipulation ==

* [[IIIF]] (International Image Interoperability Framework)
* [[Image Alchemy]]
* [[ImageMagick]]
* [[Netpbm]]
* [[Photoshop]]
* [[RECOIL]] (formerly FAIL)
* [[XnView]]
* [http://imageconverter.rest7.com/ Rest7 Online Image Converter]

(See [[Graphic software]])

== System-specific graphic formats and modes ==

* [[Apple II graphics formats]]
* [[Atari graphics formats]]
* [[Commodore graphics formats]]
* [[HR (TRS-80)]] (.hr)
* [[Windows clipboard]] (.clp)

== Vector Graphics Formats ==
''(Including most metafile formats. Vector formats often support embedded raster images, and other objects that aren't actually vectors.)''

* [[Acorn Draw]]
* [[Adobe Illustrator Artwork]] (.ai)
* [[Amiga Metafile]] (.amf)
* [[Applixware Graphics]]
* [[Arts & Letters clip art library]] (.yal)
* [[Autodesk Slide]]
* [[AutoSketch]] (.skd)
* [[Calamus Vector Graphic]] (.cvg)
* [[CGM]] (Computer Graphics Metafile)
* [[CorelDRAW]] (.cdr, .cdx, .cdt, .cmx)
* [[DataDiagrammingML]] (Microsoft XML-based format)
* [[Dia]]
* [[DrawingML]] (Microsoft embedded graphics in XML Office formats)
* [[DrawIt]]
* [[Encapsulated PostScript]] (.eps, .epsf, .epsi)
* [[Enhanced Metafile]] (.emf)
* [[ER Mapper Vector]] (.erv)
* [[Fig]] (Xfig format)
* [[FreeHand]] (Aldus/Adobe)
* [[GEM VDI Metafile]] (GEM Vector, VDI, .GDI)
* [[Gerber format]] (used in printed circuit design)
* [[Haiku Vector Icon Format]]
* [[Harvard Graphics]]
* [[Instant Artist GFX]] (.gfx) (also known as Print Artist)
* [[Lotus 1-2-3 Chart]] (.pic)
* [[MacDraw]] (later ClarisDraw)
* [[Micrografx Draw]]
* [[Microsoft Office Drawing]]
* [[MIX (PhotoDraw)]]
* [[MVG]]
* [[NAPLPS]] (North American Presentation Layer Protocol Syntax)
* [[OpenDocument Drawing]] (.odg)
* [[PICT]] (Macintosh graphics)
* [[Pixie (vector graphics)|Pixie]] (.pxi)
* [[PLOT-10]] (Tektronix)
* [[Precision Graphics Markup Language]] (PGML)
* [[Presentation Manager Metafile]] (MET)
* [[Scalable Vector Graphics]] (SVG)
* [[SDA (StarOffice)]]
* [[Shapefile]]
* [[Simple Vector Format]] (SVF)
* [[sK1]]
* [[Skencil SK]]
* [[SXD]]
* [[TIFF annotation data]]
* [[UNIX Plot Format]]
* [[Visio]] (.vsd, .vss, .vst)
* [[VML]] (Vector Markup Language)
* [[Windows Metafile]] (.wmf)
* [[WordPerfect Graphics]] (.wpg)
* [[Xar (vector graphics)|Xar]] (Flare)
For modeling formats (such as IGES, NFF, OFF, POV-Ray, PRT, QRT), see [[3D and CAD/CAM Models]].

See also [[Machine Embroidery]].

== Miscellaneous ==
''(Formats and topics that are clearly identified, but which don't fit into another category, or still need to be categorized)''

* [[ANSI escape code]]
* [[Apple Preferred]] (APF)
* [[BodyPaint 3D]] (Maxon: .b3d)
* [[Chyron]]
* [[DeltaVision]] (medical microscopy format)
* [[Encyclopedia of Graphics File Formats]]
* [[Fax formats]]
* [[HDF]] (Hierarchical Data Format)
* [[IBM Audio Visual Connection (AVC) Still Video Image]]
* [[ImageLab/PrintTechnic]]
* [[KONTRON]] (embedded-systems company; apparently has graphic format of its own)
* [[Liberty IM]]
* [[PaperPort (MAX)]]
* [[Photoshop]]
* [[QDV (Random Dot Software)]]
* [[Windows Media Player Skin Package]] (.wmz)

== Uncategorized ==
''(Formats that may need to be more clearly identified and named, and moved to other categories)''

* [[BUF]]
* [[CAM]]
* [[CEL]]
* [[cicn]]
* [[cri]]
* [[csource]]
* [[Direct icns]]
* [[DL]]
* [[ElectronicImage]]
* [[IBL]]
* [[IBM PIC]]
* [[Icd5]]
* [[ISS]] (unidentified; XnView claims to support it)
* [[MHT]]
* [[MonkeyCard]]
* [[MonkeyLogo]]
* [[Oncor]]
* [[PDES]]
* [[Ppat]]
* [[Scrap]]
* [[SHS]]
* [[SNX]]
* [[StartupScreen]] (Macintosh SCRN, .scrn?)
* [[STV]]
* [[System 7 clip]]
* [[TBC]]
* [[TCL]]
* [[TN]]

== Unknown ==
''(Formats that are difficult or impossible to identify, and which may be deleted from this page)''

* [[.D]]
* [[NCG]]
* [[Palette]]
* [[TEX]] ''(Could be any of a number of TEXture formats.)''

==Links and Resources==
* [[Encyclopedia of Graphics File Formats]]
* [http://www.theatlantic.com/technology/archive/2013/01/the-never-before-told-story-of-the-worlds-first-computer-art-its-a-sexy-dame/267439/ World's first computer art (1950s pinup image)]
* [http://www.wired.com/underwire/2013/05/star-trek-art-atoms-ibm Art created with atoms]
* [http://fabiensanglard.net/rayTracing_back_of_business_card/ Raytracer program code that fits on a business card]
* [http://www.textfiles.com/programming/FORMATS/xga.pro XGA: A New Graphics Standard]
* [http://www.jagregory.com/abrash-black-book/ Michael Abrash’s Graphics Programming Black Book, Special Edition]
* [http://www.squarespace.com/logo Squarespace logo designer tool] (Want a logo for a silly dot-com company you're starting? Create one here!)
* [http://freshome.com/2014/02/27/unconventional-pixel-furniture-adding-intrigue-modern-rooms/ Unconventional Pixel Furniture Adding Intrigue to Modern Rooms]
* [http://skeptools.wordpress.com/2014/03/03/viral-photos-debunked-animal-rights-google-tineye-image-search/ See how to debunk viral photos in seconds using image search]
* [http://boingboing.net/2014/03/12/gettys-free-image-embedding.html Getty's free image embedding comes at a price]
* [http://addyosmani.com/blog/image-optimization-tools/ Image optimization tools]
* [http://www.loc.gov/preservation/resources/rfs/stillimg.html Library of Congress Recommended Format Specifications: Still Image Works]
* [http://www.historyofinformation.com/expanded.php?id=2245 The Most Famous Image in the Early History of Computing]
* [http://ianmilligan.ca/2014/07/21/image-file-extensions-in-the-wide-web-scrape/ Image File Extensions in the Wide Web Scrape]
* [http://questionsomething.wordpress.com/2012/07/26/databending-using-audacity-effects/ Databending effects of editing images with a sound editor]
* [http://www.imagemagick.org/script/identify.php ImageMagick Identify Command-line Tool]
* [http://bertolami.com/index.php?engine=blog&content=posts&detail=perceptual-hashing Perceptual Hashing]
* [http://8bitartwork.co.uk/ Retrospecs: iOS app to convert images to imitate old 8-bit systems' graphics]
* [http://alvyray.com/Memos/CG/Microsoft/6_pixel.pdf A Pixel Is Not A Little Square]
* [http://literarymachin.es/deepzoom-osd-server/ Serve deepzoom images from a zip archive with openseadragon]
* [http://iipimage.sourceforge.net/2014/12/iiif IIIF – The International Image Interoperability Framework]
* [http://iiif.io/ IIIF official site]
* [https://stacks.stanford.edu/file/druid:df650pk4327/2015ARCHIVING_IIIF.pdf The International Image Interoperability Framework (IIIF): A community & technology approach for web-based images]
* [http://creativeshory.com/know-use-image-file-types-jpeg-gif-png/ Know When to Use Image File Types: JPEG, GIF & PNG]
* [http://stackoverflow.com/questions/27974945/can-we-programatically-compare-different-images-of-same-resolutions/27976171#27976171 Can we programatically compare different images of same resolutions?]
* [http://www.webdesigndev.com/freebies/best-color-palette-tools 20 Best Color Palette Tools for Web and Graphic Designers]
* [https://www.youtube.com/watch?v=Tfh0ytz8S0k How "oldschool" graphics worked, Part 1] · [https://www.youtube.com/watch?v=_rsycfDliZU Part 2] (videos)
* [http://ninedegreesbelow.com/photography/xyz-rgb.html Completely Painless Programmer's Guide to XYZ, RGB, ICC, xyY, and TRCs]
* [http://potrace.sourceforge.net/ Potrace: Transforming bitmaps into vector graphics]
* [http://cloudinary.com/blog/one_pixel_is_worth_three_thousand_words About a 1x1 image in many file formats]

Windows 1.0 Cursor

2017-04-07T21:23:09Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|cur}}
}}
The Windows 1.x variant of the '''CUR''' format is used in Microsoft Windows versions 1 and 2 to define mouse pointer shapes. It has little in common with the [[CUR]] format used by Windows 3 and above.

== Format ==
Files begin with a little-endian word, which is one of:
{| class="wikitable"
! Value
! Meaning
|-
| 0003 || Device-Independent Format
|-
| 0103 || Device-Dependent Format
|-
| 0203 || Both formats
|}

This is followed by a 12-byte header describing the cursor bitmap:
{| class="wikitable"
! Offset
! Type
! Meaning
|-
| 0000 || WORD || csHotX, X-coordinate of hot spot
|-
| 0002 || WORD || csHotY, Y-coordinate of hot spot
|-
| 0004 || WORD || csWidth, width of bitmap in pixels
|-
| 0006 || WORD || csHeight, height of bitmap in pixels
|-
| 0008 || WORD || csWidthBytes, width of bitmap in bytes
|-
| 000A || WORD || csColor, cursor color
|-
|}
Two bitmaps come after the header, each <code>csHeight</code> * <code>csWidthBytes</code> bytes long. The first bitmap is ANDed with the screen pattern; then the second is XORed on top of it.

If the file is in 'Both formats' format, the cursor header and bitmaps will then be repeated.

== See also ==
* [[CUR]]
* [[Windows 1.0 Icon]]

== Sample files ==
* Samples can be found in the Windows 2.x DDK, or generated with the Windows 1.x / 2.x icon editor ICONEDIT.

[[Category:Microsoft]]
[[Category:Windows]]

Windows 1.0 Icon

2017-04-07T21:22:52Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|ico}}
}}
The Windows 1.x variant of the '''ICO''' format is used in Microsoft Windows versions 1 and 2 to define monochrome icons. It has little in common with the [[ICO]] format used by Windows 3 and above.

== Format ==
Files begin with a little-endian word, which is one of:
{| class="wikitable"
! Value
! Meaning
|-
| 0001 || Device-Independent Format
|-
| 0101 || Device-Dependent Format
|-
| 0201 || Both formats
|}

This is followed by a 12-byte header describing the icon bitmap:
{| class="wikitable"
! Offset
! Type
! Meaning
|-
| 0000 || DWORD || Not used (corresponds to hot spot X/Y in the [[Windows_1.0_Cursor]] format).
|-
| 0004 || WORD || Width of bitmap in pixels
|-
| 0006 || WORD || Height of bitmap in pixels
|-
| 0008 || WORD || Width of bitmap in bytes
|-
| 000A || WORD || Not used (corresponds to cursor color in the [[Windows_1.0_Cursor]] format).
|-
|}
Two bitmaps come after the header, each <code>csHeight</code> * <code>csWidthBytes</code> bytes long. The first bitmap is ANDed with the screen pattern; then the second is XORed on top of it.

A file in 'device independent' format is stored at double its eventual size (so a 32×32 icon would be saved as a 64×64 bitmap). A file in 'Both formats' format contains the header and bitmaps for the 'device-independent' version of the bitmap, followed by the header and bitmaps for the 'device-dependent' version.

== See also ==
* [[Windows 1.0 Cursor]]
* [[ICO]]

== Sample files ==
* Samples can be found in the Windows 2.x DDK, or generated with the Windows 1.x / 2.x icon editor ICONEDIT.

[[Category:Microsoft]]
[[Category:Windows]]

ICO

2017-04-07T21:22:26Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|ico}}
|mimetypes={{mimetype|image/vnd.microsoft.icon}}, {{mimetype|image/x-icon}}
|pronom={{PRONOM|x-fmt/418}}
}}
'''ICO''' is a Microsoft Windows icon format.

ICO files can have multiple icon images of different sizes and color types in the same file, so that programs displaying them can pick the best image for a particular use.

== Format ==
An ICO file begins with a 6-byte header, followed one or more 16-byte directory entries (one for each image). Each entry contains information about the image's size, color format, and location in the file.

The rest of the file contains the actual images, which usually use a variant of [[BMP]] format (without the file header, and with a transparency mask). Alternatively, they may use [[PNG]] format.

ICO format is very similar to [[CUR]] (cursor) format.

== Identification ==
Files begin with bytes <code>00 00 01 00</code>.

Note that this byte sequence is not very discriminating. For example, many [[JBIG]] files begin the same way.

== Changing default icons for Windows file types ==

Versions of Windows up through XP had a nice and simple means of changing default icons for file types through the properties tab you can pull up for any file/folder. However, Microsoft in its infinite wisdom (or wisdumb?) decided to change that starting in Vista, removing the option and making the changing of icons something that practically requires a PhD in computer science. (Changing icons for ''folders'' is still a simple option, but not for files.) If you want to try it, here's how:

* Run Registry Edit (Regedit.exe from the start menu)

* Navigate to '''HKEY_CURRENT_USER \ Software \ Microsoft \ Windows \ CurrentVersion \ Explorer \ FileExts \ ''.ext'' \ UserChoice''', where ''.ext'' is replaced by the file extension you are trying to modify

* If no UserChoice item exists here, go up one level to the one named after the extension you're looking for.

* Note the value of this field, which is what the file type in question is known as to Windows.

* Now go to '''HKEY_CLASSES_ROOT \ ''yourfiletype'' \ DefaultIcon''' in Registry Edit, where ''yourfiletype'' is replaced with the value found in the extension data above.

* Change the value here to the path/filename of the desired icon. If no DefaultIcon item exists, create one under the file type.

* Icon paths can be the name of a .ico file, or an .exe or .dll that contains an icon; in cases where multiple icon images are in a file, the name needs to be suffixed with a comma and a number which gives the index of the icon within the file, where 0 is the first one. The icon picker which you can get while changing icons for a folder/directory can be helpful here; if you choose an exe/dll file, it shows all icons in the file and if you count from left to right and top to bottom you can determine the index of the one you want.

== See also ==
* [[BMP]]
* [[CUR]]
* [[Favicon]]
* [[OS/2 Icon]]
* [[Windows 1.0 Icon]]

== Software ==
Many image viewers and web browsers support ICO format.
* [http://www.nongnu.org/icoutils/ icoutils] (icotool)

== Sample files ==
* http://cd.textfiles.com/ccbwindows93/ICONS/

== References ==
* [[Wikipedia:ICO %28file format%29|ICO (Wikipedia)]]
* [https://web.archive.org/web/20070423201738/http://www.oreilly.com/www/centers/gff/formats/miccur/index.htm GFF Format Summary: Microsoft Windows Cursor and Icon] (from archive.org)
* The evolution of the ICO file format: [https://blogs.msdn.microsoft.com/oldnewthing/20101018-00/?p=12513 part 1], [https://blogs.msdn.microsoft.com/oldnewthing/20101019-00/?p=12503 part 2], [https://blogs.msdn.microsoft.com/oldnewthing/20101021-00/?p=12483 part 3], [https://blogs.msdn.microsoft.com/oldnewthing/20101022-00/?p=12473 part 4]
* [http://www.winhelponline.com/blog/change-file-type-icon-windows-7-vista/ Changing default file icons in Vista and Win7]

[[Category:Microsoft]]
[[Category:Windows]]

Windows 1.0 Icon

2017-04-07T21:21:44Z

John e: Created page with "{{FormatInfo |formattype=electronic |subcat=Graphics |extensions={{ext|ico}} }} The Windows 1.x variant of the '''ICO''' format is used in Microsoft Windows versions 1 and 2 t..."

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|ico}}
}}
The Windows 1.x variant of the '''ICO''' format is used in Microsoft Windows versions 1 and 2 to define monochrome icons. It has little in common with the [[ICO]] format used by Windows 3 and above.

== Format ==
Files begin with a little-endian word, which is one of:
{| class="wikitable"
! Value
! Meaning
|-
| 0001 || Device-Independent Format
|-
| 0101 || Device-Dependent Format
|-
| 0201 || Both formats
|}

This is followed by a 12-byte header describing the icon bitmap:
{| class="wikitable"
! Offset
! Type
! Meaning
|-
| 0000 || DWORD || Not used (corresponds to hot spot X/Y in the [[Windows_1.0_Cursor]] format).
|-
| 0004 || WORD || Width of bitmap in pixels
|-
| 0006 || WORD || Height of bitmap in pixels
|-
| 0008 || WORD || Width of bitmap in bytes
|-
| 000A || WORD || Not used (corresponds to cursor color in the [[Windows_1.0_Cursor]] format).
|-
|}
Two bitmaps come after the header, each <code>csHeight</code> * <code>csWidthBytes</code> bytes long. The first bitmap is ANDed with the screen pattern; then the second is XORed on top of it.

A file in 'device independent' format is stored at double its eventual size (so a 32×32 icon would be saved as a 64×64 bitmap). A file in 'Both formats' format contains the header and bitmaps for the 'device-independent' version of the bitmap, followed by the header and bitmaps for the 'device-dependent' version.

== See also ==
* [[Windows_1.0_Cursor]]
* [[ICO]]

== Sample files ==
* Samples can be found in the Windows 2.x DDK, or generated with the Windows 1.x / 2.x icon editor ICONEDIT.

[[Category:Microsoft]]
[[Category:Windows]]

Windows 1.0 Cursor

2017-04-06T00:48:43Z

John e: Created page with "{{FormatInfo |formattype=electronic |subcat=Graphics |extensions={{ext|cur}} }} The Windows 1.x variant of the '''CUR''' format is used in Microsoft Windows versions 1 and 2 t..."

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|cur}}
}}
The Windows 1.x variant of the '''CUR''' format is used in Microsoft Windows versions 1 and 2 to define mouse pointer shapes. It has little in common with the [[CUR]] format used by Windows 3 and above.

== Format ==
Files begin with a little-endian word, which is one of:
{| class="wikitable"
! Value
! Meaning
|-
| 0003 || Device-Independent Format
|-
| 0103 || Device-Dependent Format
|-
| 0203 || Both formats
|}

This is followed by a 12-byte header describing the cursor bitmap:
{| class="wikitable"
! Offset
! Type
! Meaning
|-
| 0000 || WORD || csHotX, X-coordinate of hot spot
|-
| 0002 || WORD || csHotY, Y-coordinate of hot spot
|-
| 0004 || WORD || csWidth, width of bitmap in pixels
|-
| 0006 || WORD || csHeight, height of bitmap in pixels
|-
| 0008 || WORD || csWidthBytes, width of bitmap in bytes
|-
| 000A || WORD || csColor, cursor color
|-
|}
Two bitmaps come after the header, each <code>csHeight</code> * <code>csWidthBytes</code> bytes long. The first bitmap is ANDed with the screen pattern; then the second is XORed on top of it.

If the file is in 'Both formats' format, the cursor header and bitmaps will then be repeated.

== See also ==
* [[CUR]]
* [[ICO]]

== Sample files ==
* Samples can be found in the Windows 2.x DDK, or generated with the Windows 1.x / 2.x icon editor ICONEDIT.

[[Category:Microsoft]]
[[Category:Windows]]

CUR

2017-04-06T00:36:14Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|cur}}
}}
'''CUR''' is a Microsoft Windows cursor format.

CUR files can have multiple icon images of different sizes in the same file, so that programs displaying them can pick the size that is appropriate for a particular use. Image data within the file is either in [[BMP]] or [[PNG]] format, with some header bytes defined by the CUR standard.

== Format ==
Files have a 6-byte fixed header, followed by one or more 16-byte directory entries, followed by the image data.

CUR format is very similar to [[ICO]] (icon) format.

== Identification ==
Files begin with bytes <code>00 00 02 00</code>.

== See also ==
* [[Windows Animated Cursor|ANI (Windows Animated Cursor)]]
* [[Windows 1.0 Cursor|CUR (Windows 1.0)]]
* [[ICO]]

== Software ==
* [http://www.nongnu.org/icoutils/ icoutils] (icotool)

== Sample files ==
* http://cd.textfiles.com/desktopworks/MOUSEPNT/

== References ==
* [[Wikipedia:ICO_%28file_format%29|ICO (Wikipedia)]] (also describes CUR)
* [https://web.archive.org/web/20070423201738/http://www.oreilly.com/www/centers/gff/formats/miccur/index.htm GFF Format Summary: Microsoft Windows Cursor and Icon]

[[Category:Microsoft]]
[[Category:Windows]]

Windows DDB

2017-04-06T00:30:58Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|ddb}}, {{ext|bmp}}
|pronom={{PRONOM|fmt/114}}
|released=1985
}}
'''Windows DDB''' (Device-Dependent Bitmap), or '''Windows BMP v1''', is a graphics format associated with Microsoft Windows 1.0. It has only a little in common with the [[BMP]] formats that succeeded it.

== Disambiguation ==
The term ''DDB'' is also used for the in-memory BITMAP structure used by the Windows API. This structure is not necessarily the same as the file format described in this article. (Maybe it is the same on old versions of Windows?)

Bitmap files in this format can be found in the Windows 2 DDK.

This format is not the format saved by Windows 1.0 Paint. It is generated by ICONEDIT, the Windows 1.x icon / cursor / bitmap editor.

== Format ==
Files begin with a 16-byte header, the last 14 bytes of which correspond to the BITMAP structure:
{| class="wikitable"
! Offset
! Type
! Meaning
|-
| 0x0000 || WORD || File type: 0x0002, RT_BITMAP. Top bit set if discardable.
|-
| 0x0002 || WORD || bmType: Always 0x0000 for main memory bitmap
|-
| 0x0004 || WORD || bmWidth: Width in pixels
|-
| 0x0006 || WORD || bmHeight: Height in pixels
|-
| 0x0008 || WORD || bmWidthBytes: Width of a line in bytes
|-
| 0x000A || BYTE || bmPlanes: Number of planes in bitmap
|-
| 0x000B || BYTE || bmBitsPixel: Number of bits per pixel
|-
| 0x000C || DWORD || bmBits: Always zero in disk file
|}
This is followed by the bitmap, in top-to-bottom order, with bmWidthBytes bytes per line.

== Links ==
* {{EGFF|bmp|Microsoft Windows Bitmap File Format Summary}}, from the [[Encyclopedia of Graphics File Formats]]

[[Category:Microsoft]]
[[Category:Windows]]

Windows DDB

2017-04-06T00:30:30Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|ddb}}, {{ext|bmp}}
|pronom={{PRONOM|fmt/114}}
|released=1985
}}
'''Windows DDB''' (Device-Dependent Bitmap), or '''Windows BMP v1''', is a graphics format associated with Microsoft Windows 1.0. It has only a little in common with the [[BMP]] formats that succeeded it.

== Disambiguation ==
The term ''DDB'' is also used for the in-memory BITMAP structure used by the Windows API. This structure is not necessarily the same as the file format described in this article. (Maybe it is the same on old versions of Windows?)

Bitmap files in this format can be found in the Windows 2 DDK.

This format is not the format saved by Windows 1.0 Paint.

== Format ==
Files begin with a 16-byte header, the last 14 bytes of which correspond to the BITMAP structure:
{| class="wikitable"
! Offset
! Type
! Meaning
|-
| 0x0000 || WORD || File type: 0x0002, RT_BITMAP. Top bit set if discardable.
|-
| 0x0002 || WORD || bmType: Always 0x0000 for main memory bitmap
|-
| 0x0004 || WORD || bmWidth: Width in pixels
|-
| 0x0006 || WORD || bmHeight: Height in pixels
|-
| 0x0008 || WORD || bmWidthBytes: Width of a line in bytes
|-
| 0x000A || BYTE || bmPlanes: Number of planes in bitmap
|-
| 0x000B || BYTE || bmBitsPixel: Number of bits per pixel
|-
| 0x000C || DWORD || bmBits: Always zero in disk file
|}
This is followed by the bitmap, in top-to-bottom order, with bmWidthBytes bytes per line.

== Links ==
* {{EGFF|bmp|Microsoft Windows Bitmap File Format Summary}}, from the [[Encyclopedia of Graphics File Formats]]

[[Category:Microsoft]]
[[Category:Windows]]

DSK (CPCEMU)

2017-03-13T23:00:11Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
|extensions={{ext|dsk}}
}}

The CPCEMU disc image format (conventional extension .DSK) is conventionally used for images of Amstrad CPC, Amstrad PCW, and Spectrum +3 [[floppy disk]]s.

It is thus the ''de facto'' disc image format for most 3" [[floppy disk]]s. (There's probably no technical reason it couldn't image other disk types, but typically it doesn't.)

Such disk images will often (but not always) contain a [[CP/M file system]].

== References ==

* [http://www.cpctech.org.uk/docs/dsk.html Original format specification]
* [http://www.cpctech.org.uk/docs/extdsk.html Extended DSK (EDSK) specification] (extensions to handle representing copy protection, etc -- Marco Vieth, Ulrich Doewich, Kevin Thacker)
* [http://www.cpcwiki.eu/index.php/Format:DSK_disk_image_file_format cpcwiki.eu] -- (FIXME just the same as above, or more information?)
* [http://simonowen.com/misc/extextdsk.txt simonowen.com] -- extensions to handle further copy protection schemes

[[Category:Amstrad]]
[[Category:ZX Spectrum]]

DSK (CPCEMU)

2017-03-13T22:59:53Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
|extensions={{ext|dsk}}
}}

The CPCEMU disc image format (conventional extension .DSK) is conventionally used for images of Amstrad CPC, Amstrad PCW, and Spectrum +3 [[floppy disk]]s.

It is thus the ''de facto'' disc image format for most 3" [[floppy disk]]s. (There's probably no technical reason it couldn't image other disk types, but typically it doesn't.)

Such disk images will often (but not always) contain a [[CP/M file system]].

== References ==

* [http://www.cpctech.org.uk/docs/dsk.html Original format specification]
* [http://www.cpctech.org.uk/docs/extdsk.html Extended DSK (EDSK) specification] (extensions to handle representing copy protection, etc -- Marco Vieth, Ulrich Doewich, Kevin Thacker)
* [http://www.cpcwiki.eu/index.php/Format:DSK_disk_image_file_format cpcwiki.eu] -- (FIXME just the same as above, or more information?)
* [http://simonowen.com/misc/extextdsk.txt] -- extensions to handle further copy protection schemes

[[Category:Amstrad]]
[[Category:ZX Spectrum]]

MS-DOS date/time

2017-02-23T22:08:28Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Elements of File Formats
|released=1981
}}
'''MS-DOS date''' and '''MS-DOS time''' are data formats associated with [[MS-DOS]]. They are used in some file formats from the MS-DOS era. Each is a 16-bit integer.

'''MS-DOS date''' represents a day in the range 1980 to 2099 (or maybe 2107, but dates after 2099 aren't always correctly handled).

'''MS-DOS time''' represents a 2-second interval within some day. The time is usually expected to be in "local time", and there is no indication of the time zone. This makes it fairly useless in the internet age.

== Specifications ==
* [https://msdn.microsoft.com/en-us/library/windows/desktop/ms724247%28v=vs.85%29.aspx Windows Dev Center: DosDateTimeToFileTime function] - Describes MS-DOS date and time formats

== Related formats ==
Examples of file formats that use MS-DOS date/time:
* [[FAT12]]
* [[ZIP]]
* [[CopyQM]]

[[Category:Microsoft]]

CopyQM

2017-02-23T08:25:51Z

John e: Created page with "{{FormatInfo |formattype=electronic |subcat=Disk Image Formats }} ==Overview== CopyQM was a disk imaging program published by Sydex. Unlike their similar program [[TD0|TeleDi..."

{{FormatInfo
|formattype=electronic
|subcat=Disk Image Formats
}}

==Overview==
CopyQM was a disk imaging program published by Sydex. Unlike their similar program [[TD0|TeleDisk]], it did not support disks where different tracks had different sector formats.

==References==
* [http://rio.early8bitz.de/cqm/index.htm File format definition] (reverse-engineered)

Disk Image Formats

2017-02-23T08:20:55Z

John e:

{{FormatInfo
|formattype=electronic
|thiscat=Disk Image Formats
|image=Selanit floppy disk download icon.png
}}

[[Filesystem]]s and other file formats described on this page's parent page describe entities that exist on disks as they would normally be used.

However, there are also file formats that allow a physical disk (or tape or other medium) to be "imaged" into a file, either to be re-copied onto a physical disk later, or else used by an *emulator* of the computer system that would have originally used that sort of media.

These file formats represent a data image of one of the physical floppy disk (etc.) formats. In addition to the raw data from the disk/tape/etc, these formats may contain metadata that the corresponding emulator environment uses to correctly access the data.

Typically, when archiving a physical disk for later use, a physical disk will be imaged into one of these file formats. Sub-pages of this page should contain information on the format itself as well as instructions on how to extract a physical disk into that disk image format, including information about what physical drives are required, what software to use and how and what OS that is run under.

See also [[ROM and memory images]] for images of memory, and [[Floppy disk]]s for the physical floppies. See [[Archiving]] for archive and backup formats that are filesystem-based rather than raw-sector-based. See [[Filesystem]] for the filesystems. [[Forensics and Law Enforcement]] has formats for preserving drive contents with metadata for investigations.

==Floppy Disk Image Formats==
Images created directly from floppy disks.
===Generic Sector Images===

====Acorn====

* [[Acorn Archimedes Disk Image]]

====Amiga====

* [[ADF (Amiga)]]
* [[Disk Imploder]] (Amiga) (.dmp, .dex)
* [[Disk Masher System]] (Amiga) (.dms)

====Amstrad====

* [[DSK (CPCEMU)]], used for Amstrad and related disks (typically 3" disks)

====APF Imagination Machine====

* [[APD]] (APF Imagination Machine emulated disk) (.apd)

====Apple II series====

* [[Apple Disk Image]] (Apple II disk image with header) (.2mg)
* [[Disk Copy 4.2]] (Apple)
* [[Disk Copy 6]] (Apple)
* [[DSK (Apple II)]], used for Apple II disks (typically 5.25" disks)
* [[EDD disk image]]
* [[Nibblized disk image]] (.nib), an Apple II disk image format that works for copy-protected disks

====Atari====

* [[ATR]] (SIO2PC)
* [[DCM]] (Disk Communicator)
* [[DI]] (800XL DJ emulator)
* [[DIM]] (F-Copy)
* [[MSA (Magic Shadow Archiver)]]
* [[PRO]] (APE ProSystem)
* [[SCP]] (Spartados)
* [[ST disk image]]
* [[STT]] (STEEM)
* [[STX]] (Pasti)
* [[XFD]] (Xformer)

====Commodore 64/128====

* [[C64 Nibbler Format]] (.nib) (created by mnib)
* [[D64]] and its variants (D71, D81, all with optional error information) from the C64
* [[G64]] C64 raw (GCR coded) disk image

====Macintosh====

* [[Apple Disk Image]] (MacOS or OS X disk image with header) (.dmg, .smi, .img)
* [[DART]] (Apple)

====PC (DOS/Windows)====

* [[CopyQM]]
* [[DDI]] (DiskDupe image file)
* [[FDI]] (Formatted Disk Image)
* [[IMA]]
* [[IMD]] (ImageDisk)
* [[IMG (DOSIMG)|IMG]] (HD-Copy disk image)
* [[Quick Release Sector Transfer]] (Compaq)
* [[TD0]] (TeleDisk)

====Tandy====

* [[DMK]]
* [[JV1/JV3]]

====Misc.====

* [[DiscFerret floppy image]] (.dfi)
* [[Famicom Disk System]] (.fds)
* [[MESS floppy image]] (.mfi)
* [[Pasopia disk image]] (.d88)
* [[Raw disk image]] (.img) (ie, created with dd)

===Physical (Hardware) Images===

* [[DRAFT]] (Software Preservation Society intermediate format)
* [[IPF]] (Software Preservation Society image format)

==Optical Disc Image Formats==
CD-ROM, DVD-ROM, BluRay, GD-ROM etc.

* [[BWI]] (BlindWrite Image File)
* [[CDI]] (Disc Juggler)
* [[CloneCD Control File]] (.ccd, .img, .sub)
* [[CUE and BIN]]
* [[DDP]] (Disc Description Protocol)
* [[DMG]] (Apple)
* [[ISO image]] (.iso)
* [[ISZ]]
* [[MDF and MDS]]
* [[NRG]] (Nero Burning ROM)

==Hard Disk Image Formats==

* [[HDV (disk image)|HDV]]
* [[Raw disk image]] (.img)

==Virtual Machine Disks and Virtualization Image Formats==
* [[OVF (Open Virtualization Format)]]
* [[qcow]] (QEMU)
* [[VDI]] (Virtual Disk Image) (VirtualBox) (.vdi)
* [[VHD (Virtual Hard Disk)]] (Microsoft) (.vhd)
* [[VMDK]] (Virtual Machine Disk) (VMWare) (.vmdk)

==Tape Image Formats==

* [[APT]] (APF Imagination Machine emulated tape, logical bits) (.apt)
* [[APW]] (APF Imagination Machine emulated tape, raw audio) (.apw)
* [[CAS (Atari)|CAS]] (Atari; Digital Cassette Image system)
* [[PZX]] (ZX Spectrum)
* [[T64]]
* [[TAP (ZX Spectrum)]]
* [[Tap file]] (contains data from Commodore data cassette)
* [[TZX]] (ZX Spectrum)
* [[Unified Emulator Format]] (UEF; also does Acorn disks and ROMs)

==Unknown==
* [[lbl]] See here for details: [http://classiccmp.org/pipermail/cctalk/2012-December/326747.html http://classiccmp.org/pipermail/cctalk/2012-December/326747.html]

==Tools==
* [[The Sleuth Kit and Autopsy]] can read raw, Expert Witness, and AFF formats
* [http://www.winimage.com/ WinImage] to read, write and create images, also lots of info
* [http://foremost.sourceforge.net/ Foremost: console tool to recover files from disk images]
* [http://disktype.sourceforge.net/ disktype: detect format of disk or disk image]
* [http://mark0.net/soft-trid-e.html TrID File Identifier]: recognize many disk image formats
* [https://github.com/bitcurator/bca-webtools bca-webtools]
* [https://github.com/eaas-framework/xmount xmount: emulates various disk image formats for use in emulators requiring them]

See also [[Disk Imaging Software & Systems]], and [[Forensics and Law Enforcement]].

== Links ==
* [http://qanda.digipres.org/20/what-are-the-reasons-for-saving-disk-images?show=183 What are the reasons for saving disk images?]
* [http://ils.unc.edu/digccurr/curategear2016-talks/woods-curategear2016.pdf BCA-Webtools: Accessing and Visualizing Disk Images in a Web Browser]

Quick Release Sector Transfer

2017-02-15T21:19:29Z

John e:

LocoScript

2016-08-26T09:13:20Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Document
}}
'''LocoScript''' was the word processor bundled with the Amstrad PCW. There were four major versions for the PCW, and two for MSDOS.

At least in the PCW versions, the [[Amstrad CP/M Plus character set]] was used for the text portions, except that the [[C1 controls]] range was used for control codes (different ones from the C1 control standard, which probably didn't exist yet) instead of the graphical characters of the CPM/PLUS set.

== Converting LocoScript Documents ==

Probably the most difficult problem with converting LocoScript documents into more readable formats is not the conversion process itself, but the fact that the majority of LocoScript files were stored on 3-inch floppy disks, which are now difficult to access. However, there are methods of transferring data if a working PCW is available.

* '''LocoLink''' (and the later 'LocoLink for Windows') is a hardware / software combination that connects a PC parallel port to the expansion connector of an Amstrad PCW, and provides the software tools for both transferring LocoScript documents to the PC, as well as converting them to RTF or TXT formats. Note that the later PcW 16 has part of LocoLink built-in, and while this means documents can be transferred from an older PCW to a PcW 16 and then onto a PC, PcW 16 computers are few and far between, making this option unlikely.

* Alternatively, it is possible to [http://fvempel.nl/3pc.html connect a 3-inch floppy drive to a PC], and read the disks from that. Conversion programs can then be used to access the transferred documents.

* A somewhat easier solution is to [http://fvempel.nl/drive.html connect a 3.5-inch floppy drive to a PCW] ([http://pcwpage.co.uk/making-a-data-cable-for-a-3-to-a-standard-3-5-drive/ another guide]), transfer the documents from 3-inch to 3.5-inch media on the PCW, and then read the documents off the disks on a PC with 3.5-inch floppy drive. Instructions for adding a second drive are available, and there are programs such as 22disk and [http://ai.ansible.uk/freebies.html CP/M copier] (listed as CPM.EXE) which can read 3.5-inch media created on a PCW.

* There is also software that runs on a PCW, enabling it to read and write to 3.5-inch MSDOS floppy disks. One such program is Moonstone Computing's PCW 2-in-1.

== Links ==
* [http://www.locoscript.co.uk/ Publisher's website]
** [https://web.archive.org/web/20141218181748/http://locoscript.co.uk/ 2014 archive]
* [http://www.seasip.info/Unix/Joyce/ls1frm.html LocoScript 1 file format]
* [http://cirsovius.de/CPM/Projekte/TURBO-PASCAL/LOCO/LocoConv-en.html LocoConv - Pascal source to read LocoScript documents]

[[Category:Amstrad]]

Finance and Accounting

2016-04-26T19:05:07Z

John e: /* Interchange formats: proprietary */

{{FormatInfo
|formattype=electronic
|thiscat=Finance and Accounting
|image=Money grabber.png
}}

==Accounting software==

* [[Exact]]
* [[Peachtree]]
* [[QuickBooks]] (.qbo)

==Interchange formats: open==

* [[GnuCash XML Format]]
* [[OFX]]
* [[QIF]]
* [[Tax XML]] (used by various governmental entities for e-filing)
* [[TXF]] (Tax Interchange Format; used by TurboTax)

==Interchange formats: proprietary==

* [[BACS Standard 18]]
* [[QFX]]

== Market data ==

* [[ITCH]] (NASDAQ)

==Personal finance software==

* [[Budget (Apple II)]]
* [[Lemon]] (app/website tracking cards and receipts)
* [[Microsoft Money]]
* [[Quicken]]

==Tax software==

* [[H&R Block]] (.t11, etc.; changes every year)
* [[TurboTax]] (.tax, .tax2010, etc.; changes every year)

== Naming and numbering systems ==

* [[Routing transit number]]

== See also ==

* [[Currency]]

== Links ==
* [http://www.theguardian.com/politics/2014/apr/18/hmrc-to-sell-taxpayers-data HMRC to sell taxpayers' financial data]

Finance and Accounting

2016-04-26T19:04:43Z

John e: /* Interchange formats: proprietary */

{{FormatInfo
|formattype=electronic
|thiscat=Finance and Accounting
|image=Money grabber.png
}}

==Accounting software==

* [[Exact]]
* [[Peachtree]]
* [[QuickBooks]] (.qbo)

==Interchange formats: open==

* [[GnuCash XML Format]]
* [[OFX]]
* [[QIF]]
* [[Tax XML]] (used by various governmental entities for e-filing)
* [[TXF]] (Tax Interchange Format; used by TurboTax)

==Interchange formats: proprietary==

* [[BACS_Standard_18]]
* [[QFX]]

== Market data ==

* [[ITCH]] (NASDAQ)

==Personal finance software==

* [[Budget (Apple II)]]
* [[Lemon]] (app/website tracking cards and receipts)
* [[Microsoft Money]]
* [[Quicken]]

==Tax software==

* [[H&R Block]] (.t11, etc.; changes every year)
* [[TurboTax]] (.tax, .tax2010, etc.; changes every year)

== Naming and numbering systems ==

* [[Routing transit number]]

== See also ==

* [[Currency]]

== Links ==
* [http://www.theguardian.com/politics/2014/apr/18/hmrc-to-sell-taxpayers-data HMRC to sell taxpayers' financial data]

BACS Standard 18

2016-04-26T19:04:24Z

John e: Created page with "{{FormatInfo |subcat=Finance and Accounting }} '''BACS Standard 18''' is a file format used to send payment instructions in the United Kingdom. The format is maintained by [..."

{{FormatInfo
|subcat=Finance and Accounting
}}

'''BACS Standard 18''' is a file format used to send payment instructions in the United Kingdom.

The format is maintained by [http://www.bacs.co.uk/ the Bankers' Automated Clearing Service], and the detailed specification is available only to subscribers.

Some banks have issued their own specifications for a "Standard 18" file to be imported by their software. These specifications do not necessarily match that issued by BACS; they may impose additional requirements, or change the semantics of some fields.

The file headers and trailers are based on ANSI X3.27.

== Documentation ==
* [http://www.mosaicsoftware.co.uk/support/bank-file-maker-bacs.aspx File format overview and example]
* [https://www.iccs.edu/lecture/lecture_data/1395417284Bacs%20standard%2018%20MIG.pdf HSBC "Standard 18" format definition]
* [http://businessbanking.bankofireland.com/fs/doc/wysiwyg/std-18-file-specification-bol-import.pdf Bank of Ireland "Standard 18" format and example]

RIPscrip Icon

2016-03-22T19:42:44Z

John e:

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|icn}}, {{ext|msk}}, {{ext|hot}}, {{ext|bmm}}, {{ext|bmh}}
|released=1993
}}
'''RIPscrip Icon''' (also known as '''RIPterm Image''', '''RIP Icon''', etc.) is a family of raster graphics formats associated with the ''RIPterm'' BBS software. It usually refers to the '''ICN''' format in particular. It is mainly used for icons, such as graphics for buttons, but can be used for other purposes.

RIPterm 1.x uses '''.ICN''' format, and also '''.MSK''' ("mask") and '''.HOT''' ("hot icon") formats.

RIPterm 2.x uses standard [[BMP|Windows BMP]] format, and also '''.BMM''' ("mask") and '''.BMH''' ("hot icon") formats.

[[RIPscrip]] (also spelled '''RIPscript''') is a format for defining user interfaces.

== Format ==
=== ICN ===
ICN files have a four-byte header indicating the width and height, followed by uncompressed pixel data. Images use a 16-color predefined palette. 256-color images are also said to be possible, though it's not clear how they could be identified.

According to the RIPSCRIP.DOC file, ICN "is identical in design to the [[Borland_Graphics_Interface|Borland BGI graphics]] putimage() and getimage() buffer format."

=== MSK, HOT ===
Format unknown. Possibly the same as ICN.

=== BMM, BMH ===
BMM and BMH files presumably use [[BMP]] format, but interpreted in a special way.

== Specifications ==
* [http://cd.textfiles.com/darkdomain/programs/code/ripsc154.zip ripsc154.zip] → RIPSCRIP.DOC → "RIPscrip ICON FILE FORMAT SPECIFICATION"

== Software ==
* [[Konvertor]]
* [[XnView]] (read-only)
* [http://cd.textfiles.com/cavebbsfiles/NET/RIPTM154.EXE RIPterm 1.54] ([[Self-extracting ZIP]] format)
* [http://cd.textfiles.com/cavebbsfiles/NET/RT22001.EXE RIPterm 2.20] ([[Self-extracting ZIP]] format)

== Sample files ==
* [http://cd.textfiles.com/cavebbsfiles/NET/RIPTM154.EXE RIPterm 1.54] (ICONS directory)
** [http://ftpmirror.your.org/pub/misc/dos/cavebbs/The%20Cave%20BBS%20File%20Section/MISC/NEWRIP.ZIP-contents/ICONS/ Same as above, with links to individual files]
* [http://archives.thebbs.org/ra108a.htm BBS Archives: RIP Art]
* http://cd.textfiles.com/expandin/RIPART/

== Links ==
* [http://cd.textfiles.com/cavebbsfiles/NET/RT22001.EXE RIPterm 2.20] → SHARWAR.EXE → RIPTERM.DOC
* [http://www.bbsdocumentary.com/library/PROGRAMS/GRAPHICS/RIPSCRIPT/ RIPscript], from the BBS Documentary Library

Borland Graphics Interface

2016-03-22T19:41:31Z

John e: Created page with "{{FormatInfo |formattype=electronic |subcat=Executables |extensions={{ext|bgi}} }} The '''Borland Graphics Interface''' is a graphics library used by DOS programs, which inclu..."

{{FormatInfo
|formattype=electronic
|subcat=Executables
|extensions={{ext|bgi}}
}}
The '''Borland Graphics Interface''' is a graphics library used by DOS programs, which includes the ability to use loadable drivers. These drivers have the file extension .BGI.

== Identification ==
Files begin with <code>'P' 'K' 0x08 0x08 </code> -- this is shared with the [[CHR_(Borland_font)|CHR]] font files used by BGI. The four-byte signature is followed by either <code>'BGI Device Driver'</code> or <code>'SVGA 256 Colour BGI Device Driver'</code>.

== Main Entry ==
The first 160 bytes of the driver file are a header. This is followed by the driver code segment. Far calls will be made to this address with SI containing the function number to execute.

== Bitmap images ==
BGI contains <code>getimage()</code> and <code>putimage()</code> functions to save and load images. The images thus saved have a 4-byte header (two little-endian words giving the image's width and height) followed by the image data, in a form specific to the driver used. A 16-colour VGA image will contain four monochrome bitmaps for the four planes. These images, with a .ICN extension, are used as icons by [[RIPscrip_Icon|RIPscrip 1.x]] and Counterpoint.

== Specifications ==
* ftp://ftp.musoftware.de/pub/uz/bgi/ contains documentation and source code for creating BGI drivers, along with several complete drivers.

== Links ==
* [[Wikipedia:Borland Graphics Interface]]

[[Category:Borland]]

Quick Release Sector Transfer

2016-03-13T01:01:37Z

John e:

Quick Release Sector Transfer

2016-03-13T01:01:13Z

John e:

Quick Release Sector Transfer

2016-03-12T22:49:04Z

John e:

Quick Release Sector Transfer

2016-03-12T22:33:58Z

John e: Created page with "{{FormatInfo |formattype=electronic |subcat=Disk Image Formats }} The QRST disc image format was used by Compaq to distribute disk images of diagnostic software. The file QRS..."

GW-BASIC tokenized file

2014-08-26T23:15:37Z

John e:

{{FormatInfo
|subcat=Source code
|subcat2=Tokenized BASIC
|extensions={{ext|bas}}
|released=1981
}}

'''GW-BASIC tokenized files''' stored programs in the version of the [[BASIC]] programming language used on IBM PC compatibles in the days when interpreted BASIC was regularly included on personal computers as shipped from the factory. Originally the IBM PC had versions of BASIC called BASIC and BASICA, the latter being an "advanced" BASIC with a few more features. Part of it was in ROM, and part was loaded from disk. Other manufacturers' PC compatibles (or "clones") didn't have the ROM BASIC, but used a BASIC from Microsoft which was compatible to it, and went by a few manufacturer-specific names but was generically known as GW-BASIC (with varying claims existing about what the GW stands for, either the initials of a Microsoft employee (Greg Whitten) involved in adapting it from Bill Gates' original CP/M BASIC, or possibly for "Gee Whiz").

Like most BASICs of its era, BASIC/BASICA/GW-BASIC used a tokenized format to save its programs, rather than plain-text source code. Printable ASCII characters (space through tilde) generally stood for themselves (except when part of a multi-byte sequence), but other bytes had different meanings. The "high-bit" bytes from #128-#255 stood for the various BASIC commands (some as single bytes, others as part of two-byte sequences), while some of the control characters had special meanings including signifying the start of a binary-encoded sequence encapsulating a numeric constant. A null (#0) byte marked the end of a program line, and some header bytes were used at the start of the line to encode the line number and some byte offsets.

Files saved to disk are preceded by a single byte to indicate if the program was protected: 0FEh if protected, 0FFh if not. Files saved to [[IBM PC data cassette|cassette tape]] omit this byte, because byte 9 of the cassette header holds the protection status.

== Tokens ==

Blanks are unused, or at least unknown.

As noted, some of the tokens are preceded or followed by other bytes representing other symbols which are suppressed on listing the program (so they are "invisible"). These are presumably there to make parsing by the interpreter easier.

{| class="wikitable"
! title="Hexadecimal code point" | Hex
! title="Decimal code point" | Dec
! title="BASIC element the token stands for" | Token meaning
|-
|80||128||
|-
|81||129||END
|-
|82||130||FOR
|-
|83||131||NEXT
|-
|84||132||DATA
|-
|85||133||INPUT
|-
|86||134||DIM
|-
|87||135||READ
|-
|88||136||LET
|-
|89||137||GOTO
|-
|8A||138||RUN
|-
|8B||139||IF
|-
|8C||140||RESTORE
|-
|8D||141||GOSUB
|-
|8E||142||RETURN
|-
|8F||143||REM
|-
|90||144||STOP
|-
|91||145||PRINT
|-
|92||146||CLEAR
|-
|93||147||LIST
|-
|94||148||NEW
|-
|95||149||ON
|-
|96||150||WAIT
|-
|97||151||DEF
|-
|98||152||POKE
|-
|99||153||CONT
|-
|9A||154||
|-
|9B||155||
|-
|9C||156||OUT
|-
|9D||157||LPRINT
|-
|9E||158||LLIST
|-
|9F||159||
|-
|A0||160||WIDTH
|-
|A1||161||ELSE (stored with invisible colon, 3A, before it)
|-
|A2||162||TRON
|-
|A3||163||TROFF
|-
|A4||164||SWAP
|-
|A5||165||ERASE
|-
|A6||166||EDIT
|-
|A7||167||ERROR
|-
|A8||168||RESUME
|-
|A9||169||DELETE
|-
|AA||170||AUTO
|-
|AB||171||RENUM
|-
|AC||172||DEFSTR
|-
|AD||173||DEFINT
|-
|AE||174||DEFSNG
|-
|AF||175||DEFDBL
|-
|B0||176||LINE
|-
|B1||177||WHILE (stored with invisible plus, E9, after it)
|-
|B2||178||WEND
|-
|B3||179||CALL
|-
|B4||180||
|-
|B5||181||
|-
|B6||182||
|-
|B7||183||WRITE
|-
|B8||184||OPTION
|-
|B9||185||RANDOMIZE
|-
|BA||186||OPEN
|-
|BB||187||CLOSE
|-
|BC||188||LOAD
|-
|BD||189||MERGE
|-
|BE||190||SAVE
|-
|BF||191||COLOR
|-
|C0||192||CLS
|-
|C1||193||MOTOR
|-
|C2||194||BSAVE
|-
|C3||195||BLOAD
|-
|C4||196||SOUND
|-
|C5||197||BEEP
|-
|C6||198||PSET
|-
|C7||199||PRESET
|-
|C8||200||SCREEM
|-
|C9||201||KEY
|-
|CA||202||LOCATE
|-
|CB||203||
|-
|CC||204||TO
|-
|CD||205||THEN
|-
|CE||206||TAB(
|-
|CF||207||STEP
|-
|D0||208||USR
|-
|D1||209||FN
|-
|D2||210||SPC(
|-
|D3||211||NOT
|-
|D4||212||ERL
|-
|D5||213||ERR
|-
|D6||214||STRING$
|-
|D7||215||USING
|-
|D8||216||INSTR
|-
|D9||217||' (stored with invisible ":REM", 3A 8F, before it)
|-
|DA||218||VARPTR
|-
|DB||219||CSRLIN
|-
|DC||220||POINT
|-
|DD||221||OFF
|-
|DE||222||INKEY$
|-
|DF||223||
|-
|E0||224||
|-
|E1||225||
|-
|E2||226||
|-
|E3||227||
|-
|E4||228||
|-
|E5||229||
|-
|E6||230||>
|-
|E7||231||=
|-
|E8||232||<
|-
|E9||233||+
|-
|EA||234||-
|-
|EB||235||*
|-
|EC||236||/
|-
|ED||237||^
|-
|EE||238||AND
|-
|EF||239||OR
|-
|E0||240||XOR
|-
|F1||241||EQV
|-
|F2||242||IMP
|-
|F3||243||MOD
|-
|F4||244||\
|-
|F5||245||
|-
|F6||246||
|-
|F7||247||
|-
|F8||248||
|-
|F9||249||
|-
|FA||250||
|-
|FB||251||
|-
|FC||252||
|-
|FD||253||(signals that next byte represents token from List 2)
|-
|FE||254||(signals that next byte represents token from List 3)
|-
|FF||255||(signals that next byte represents token from List 4)
|}

=== List 2: 2nd-byte tokens following FD ===

These are preceded by a FD (hex) byte.

{| class="wikitable"
! title="Hexadecimal code point" | Hex
! title="Decimal code point" | Dec
! title="BASIC element the token stands for" | Token meaning
|-
|81||129||CVI
|-
|82||130||CVS
|-
|83||131||CVD
|-
|84||132||MKI$
|-
|85||133||MKS$
|-
|86||134||MKD$
|-
|87||135||
|-
|88||136||
|-
|89||137||
|-
|8A||138||
|-
|8B||139||EXTERR
|}

=== List 3: 2nd-byte tokens following FE ===

These are preceded by a FE (hex) byte.

{| class="wikitable"
! title="Hexadecimal code point" | Hex
! title="Decimal code point" | Dec
! title="BASIC element the token stands for" | Token meaning
|-
|81||129||FILES
|-
|82||130||FIELD
|-
|83||131||SYSTEM
|-
|84||132||NAME
|-
|85||133||LSET
|-
|86||134||RSET
|-
|87||135||KILL
|-
|88||136||PUT
|-
|89||137||GET
|-
|8A||138||RESET
|-
|8B||139||COMMON
|-
|8C||140||CHAIN
|-
|8D||141||DATE$
|-
|8E||142||TIME$
|-
|8F||143||PAINT
|-
|90||144||COM
|-
|91||145||CIRCLE
|-
|92||146||DRAW
|-
|93||147||PLAY
|-
|94||148||TIMER
|-
|95||149||ERDEV
|-
|96||150||IOCTL
|-
|97||151||CHDIR
|-
|98||152||MKDIR
|-
|99||153||RMDIR
|-
|9A||154||SHELL
|-
|9B||155||ENVIRON
|-
|9C||156||VIEW
|-
|9D||157||WINDOW
|-
|9E||158||PMAP
|-
|9F||159||PALETTE
|-
|A0||160||LCOPY
|-
|A1||161||CALLS
|-
|A2||162||
|-
|A3||163||
|-
|A4||164||NOISE (PCjr), DEBUG (Sperry PC)
|-
|A5||165||PCOPY (PCjr, EGA system)
|-
|A6||166||TERM (PCjr)
|-
|A7||167||LOCK
|-
|A8||168||UNLOCK
|-
|}

=== List 4: 2nd-byte tokens following FF ===

These are preceded by a FF (hex) byte.

{| class="wikitable"
! title="Hexadecimal code point" | Hex
! title="Decimal code point" | Dec
! title="BASIC element the token stands for" | Token meaning
|-
|81||129||LEFT$
|-
|82||130||RIGHT$
|-
|83||131||MID$
|-
|84||132||SGN
|-
|85||133||INT
|-
|86||134||ABS
|-
|87||135||SQR
|-
|88||136||RND
|-
|89||137||SIN
|-
|8A||138||LOG
|-
|8B||139||EXP
|-
|8C||140||COS
|-
|8D||141||TAN
|-
|8E||142||ATN
|-
|8F||143||FRE
|-
|90||144||INP
|-
|91||145||POS
|-
|92||146||LEN
|-
|93||147||STR$
|-
|94||148||VAL
|-
|95||149||ASC
|-
|96||150||CHR$
|-
|97||151||PEEK
|-
|98||152||SPACE$
|-
|99||153||OCT$
|-
|9A||154||HEX$
|-
|9B||155||LPOS
|-
|9C||156||CINT
|-
|9D||157||CSNG
|-
|9E||158||CDBL
|-
|9F||159||FIX
|-
|A0||160||PEN
|-
|A1||161||STICK
|-
|A2||162||STRIG
|-
|A3||163||EOF
|-
|A4||164||LOC
|-
|A5||165||LOF
|}

== Format documentation ==
* [http://www.chebucto.ns.ca/~af380/GW-BASIC-tokens.html GW-BASIC tokenised program format]

== Sample files ==
* Many files on [http://cd.textfiles.com/bthevhell/ Between Heaven and Hell Version II CD], such as [http://cd.textfiles.com/bthevhell/200/104/ /200/104/*.bas]

== Other links and references ==
* [[Wikipedia:GW-BASIC|Wikipedia article: GW-BASIC]]

[[Category:Microsoft]]

IBM PC data cassette

2014-08-15T23:10:11Z

John e: More detail on what the header flags mean

{{FormatInfo
|formattype=physical
|subcat=Magnetic tape
|subcat2=Audio Cassette
|released=1981
}}
Yes, the '''IBM PC''' did have a cassette port at one point. Actually, only the original IBM Personal Computer model 5150, and the later PCjr (intended as a low-end home computer), had this; other PCs did away with this feature which was rarely used on this platform given that just about everybody got their PC with at least one disk drive. Apparently, though, IBM felt that when they made their entry into the PC field (after years of regarding small computers as "toys" unworthy of their attention) they needed to be sure their machine duplicated all the features present in other brands of personal computers around at the time, and most of them had cassette interfaces then because disk drives had been so expensive in recent history (and those computers were aimed at home/hobby markets with limited budgets). By the time of the IBM PC, disk drives had come down in price, while IBM's computers were aimed at a more upscale business/professional market, so cassettes saw little use there.

The format consists of 1-millisecond-long pulses for each 1 bit, and 0.5-millisecond pulses for each 0 bit. A tape record starts with a leader of 256 bytes of all 1 bits (hex FF), followed by a single synchronization bit (0), and then a synchronization byte (hex 16, the [[ASCII]] character from the [[C0 controls]] designated as SYN). This is followed by one or more 256-byte data blocks. Each data block is followed by a 2-byte [[CRC]], with the most significant byte first. After the last block, a 4-byte trailer is written of all 1 bits (hex FF).

Tokenised BASIC programs and memory areas saved by IBM Cassette BASIC consist of two records: the first one is a header (always 256 bytes, of which the first 16 are significant), and the second one contains the data.

ASCII listings and data files consist of a sequence of 256-byte records; the first one is a header, as above, and subsequent ones contain the data. If the first byte of the record is 0, this is not the last record, and all 255 following bytes are valid data. Otherwise it gives the number of valid bytes in the last record, plus one.

The header layout is:

{| class="wikitable"
! Offset
! Size
! Description
|-
|0x00 || Byte || Always 0xA5
|-
|0x01 || 8 bytes || Filename, ASCII
|-
|0x09 || Byte || Flags:
{| class="wikitable"
! Bit
! Meaning if set
! Example command to create
|-
|7 || Tokenised BASIC || <kbd>SAVE "file"</kbd>
|-
|6 || ASCII listing || <kbd>SAVE "file", A</kbd>
|-
|5 || Protected tokenised BASIC || <kbd>SAVE "file", P</kbd>
|-
|0 || Memory area || <kbd>BSAVE "file", address, length</kbd>
|-
|No bits set || Data || <kbd>OPEN "O",1,"file"</kbd>
|}
|-
|0x0A || Word || Number of bytes in the following data record (little-endian word)
|-
|0x0C || Word || Segment of load address (little-endian word)
|-
|0x0E || Word || Offset of load address (little-endian word)
|}

== References ==
* [http://www.brutman.com/Cassette_Waveforms/Cassette_Waveforms.html Reading IBM PC and PCjr Cassette Waveforms]
* [http://www.vintage-computer.com/vcforum/showthread.php?8829-IBM-PC-Cassette-interface Discussion of IBM PC cassette interface]
* [[Wikipedia:IBM cassette tape|Wikipedia article]]
* [http://67.185.176.54:8080/ Mike's PCjr Page]
* [http://www.minuszerodegrees.net/manuals/IBM_5150_Technical_Reference_6322507_APR84.pdf IBM PC Technical Reference, 1984]: Pages 5-106 to 5-107

[[Category:IBM]]

IBM PC data cassette

2014-08-15T10:08:21Z

John e:

{{FormatInfo
|formattype=physical
|subcat=Magnetic tape
|subcat2=Audio Cassette
|released=1981
}}
Yes, the '''IBM PC''' did have a cassette port at one point. Actually, only the original IBM Personal Computer model 5150, and the later PCjr (intended as a low-end home computer), had this; other PCs did away with this feature which was rarely used on this platform given that just about everybody got their PC with at least one disk drive. Apparently, though, IBM felt that when they made their entry into the PC field (after years of regarding small computers as "toys" unworthy of their attention) they needed to be sure their machine duplicated all the features present in other brands of personal computers around at the time, and most of them had cassette interfaces then because disk drives had been so expensive in recent history (and those computers were aimed at home/hobby markets with limited budgets). By the time of the IBM PC, disk drives had come down in price, while IBM's computers were aimed at a more upscale business/professional market, so cassettes saw little use there.

The format consists of 1-millisecond-long pulses for each 1 bit, and 0.5-millisecond pulses for each 0 bit. A tape record starts with a leader of 256 bytes of all 1 bits (hex FF), followed by a single synchronization bit (0), and then a synchronization byte (hex 16, the [[ASCII]] character from the [[C0 controls]] designated as SYN). This is followed by one or more 256-byte data blocks. Each data block is followed by a 2-byte [[CRC]], with the most significant byte first. After the last block, a 4-byte trailer is written of all 1 bits (hex FF).

Files saved by IBM Cassette BASIC consist of two records: the first one is a header (always 256 bytes, of which the first 16 are significant), and the second one contains the data.

The header layout is:

{| class="wikitable"
! Offset
! Size
! Description
|-
|0x00 || Byte || Always 0xA5
|-
|0x01 || 8 bytes || Filename, ASCII
|-
|0x09 || Byte || Flags. When listing files, BASIC displays 'P' if bit 5 is set, 'B' if bit 7 is set, 'A' if bit 6 is set, 'M' if bit 0 is set, 'D' otherwise.
|-
|0x0A || Word || Number of bytes in the following data record (little-endian word)
|-
|0x0C || Word || Segment of load address (little-endian word)
|-
|0x0E || Word || Offset of load address (little-endian word)
|}

== References ==
* [http://www.brutman.com/Cassette_Waveforms/Cassette_Waveforms.html Reading IBM PC and PCjr Cassette Waveforms]
* [http://www.vintage-computer.com/vcforum/showthread.php?8829-IBM-PC-Cassette-interface Discussion of IBM PC cassette interface]
* [[Wikipedia:IBM cassette tape|Wikipedia article]]
* [http://67.185.176.54:8080/ Mike's PCjr Page]
* [http://www.minuszerodegrees.net/manuals/IBM_5150_Technical_Reference_6322507_APR84.pdf IBM PC Technical Reference, 1984]: Pages 5-106 to 5-107

[[Category:IBM]]

IBM PC data cassette

2014-08-15T10:07:33Z

John e: Added structure of BASIC header

{{FormatInfo
|formattype=physical
|subcat=Magnetic tape
|subcat2=Audio Cassette
|released=1981
}}
Yes, the '''IBM PC''' did have a cassette port at one point. Actually, only the original IBM Personal Computer model 5150, and the later PCjr (intended as a low-end home computer), had this; other PCs did away with this feature which was rarely used on this platform given that just about everybody got their PC with at least one disk drive. Apparently, though, IBM felt that when they made their entry into the PC field (after years of regarding small computers as "toys" unworthy of their attention) they needed to be sure their machine duplicated all the features present in other brands of personal computers around at the time, and most of them had cassette interfaces then because disk drives had been so expensive in recent history (and those computers were aimed at home/hobby markets with limited budgets). By the time of the IBM PC, disk drives had come down in price, while IBM's computers were aimed at a more upscale business/professional market, so cassettes saw little use there.

The format consists of 1-millisecond-long pulses for each 1 bit, and 0.5-millisecond pulses for each 0 bit. A tape record starts with a leader of 256 bytes of all 1 bits (hex FF), followed by a single synchronization bit (0), and then a synchronization byte (hex 16, the [[ASCII]] character from the [[C0 controls]] designated as SYN). This is followed by one or more 256-byte data blocks. Each data block is followed by a 2-byte [[CRC]], with the most significant byte first. After the last block, a 4-byte trailer is written of all 1 bits (hex FF).

Files saved by IBM Cassette BASIC consist of two records: the first one is a header (always 256 bytes, of which the first 16 are significant), and the second one contains the data.

The header layout is:

{| class="wikitable"
! Offset
! Size
! Description
|-
|0x00 || Byte || Always 0xA5
|-
|0x01 || 8 bytes || Filename, ASCII
|-
|0x09 || Byte || Flags. When listing files, BASIC displays 'P' if bit 5 is set, 'B' if bit 7 is set, 'A' if bit 6 is set, 'M' if bit 0 is set, 'D' otherwise.
|-
|0x0A || Word || Number of bytes in the following data part (little-endian word)
|-
|0x0C || Word || Segment of load address (little-endian word)
|-
|0x0E || Word || Offset of load address (little-endian word)
|}

== References ==
* [http://www.brutman.com/Cassette_Waveforms/Cassette_Waveforms.html Reading IBM PC and PCjr Cassette Waveforms]
* [http://www.vintage-computer.com/vcforum/showthread.php?8829-IBM-PC-Cassette-interface Discussion of IBM PC cassette interface]
* [[Wikipedia:IBM cassette tape|Wikipedia article]]
* [http://67.185.176.54:8080/ Mike's PCjr Page]
* [http://www.minuszerodegrees.net/manuals/IBM_5150_Technical_Reference_6322507_APR84.pdf IBM PC Technical Reference, 1984]: Pages 5-106 to 5-107

[[Category:IBM]]