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

Sinclair BASIC tokenized file

2013-05-22T21:54:13Z

Jonnosan:

Sinclair BASIC is a dialect of the BASIC programming language created by by Nine Tiles Networks Ltd and used in the 8-bit home computers from Sinclair Research and Timex Sinclair.

The original 4KB version was developed for the Sinclair ZX80, followed by an 8KB version for the ZX81 and 16 KB version for ZX Spectrum.

Some unusual features of the Sinclair BASIC:
* There were keys on the keyboard for each BASIC keyword. For example, pressing P caused the entire command PRINT to appear. Some commands needed multiple keypresses to enter, For example, BEEP was keyed by pressing CAPS SHIFT plus SYMBOL SHIFT to access extended mode, keeping SYMBOL SHIFT held down and pressing Z.
* When programs where SAVEd, the file written to disk or tape contained all of BASIC's internal state information, including the values of any defined basic variables, as well as the BASIC tokens.

=== BASIC File Layout ===
On a ZX81 , a saved BASIC file is a snapshot of the computer memory from memory location 16393 through to the end of the variable table. There is no header.
{| class="wikitable"
! title="Memory Address" | Address
! title="Name" | Name
! title="Description" |Description
|-

|16393||VERSN ||0 Identifies ZX81 BASIC in saved programs.
|-
|16394||E_PPC||Number of current line (with program cursor).
|-
|16396||D_FILE||Pointer to the start of the 'Display file', i.e. what is being displayed on screen
|-
|16398||DF_CC||Address of PRINT position in display file. Can be poked so that PRINT output is sent elsewhere.
|-
|16400||VARS||Pointer to start of BASIC Variable table
|-
|16402||DEST||Address of variable in assignment.
|-
|16404||E_LINE||Pointer to line currently being entered
|-
|16406||CH_ADD||Address of the next character to be interpreted: the character after the argument of PEEK, or the NEWLINE at the end of a POKE statement.
|-
|16408||X_PTR||Address of the character preceding the marker.
|-
|16410||STKBOT||pointer to start (bottom) of stack
|-
|16412||STKEND||pointer to end (top) of stack
|-
|16414||BERG||Calculator's b register.
|-
|16415||MEM||Address of area used for calculator's memory. (Usually MEMBOT, but not always.)
|-
|16417|| ||not used
|-
|16418||DF_SZ||The number of lines (including one blank line) in the lower part of the screen.
|-
|16419||S_TOP||The number of the top program line in automatic listings.
|-
|16421||LAST_K||Shows which keys pressed.
|-
|16423|| || Debounce status of keyboard.
|-
|16424||MARGIN||Number of blank lines above or below picture: 55 in Britain, 31 in America.
|-
|16425||NXTLIN||Address of next program line to be executed.
|-
|16427||OLDPPC||Line number of which CONT jumps.
|-
|16429||FLAGX||Various flags.
|-
|16430||STRLEN||Length of string type destination in assignment.
|-
|16432||T_ADDR||Address of next item in syntax table (very unlikely to be useful).
|-
|16434||SEED||The seed for RND. This is the variable that is set by RAND.
|-
16436||FRAMES||Counts the frames displayed on the television. Bit 15 is 1. Bits 0 to 14 are decremented for each frame set to the television. This can be used for timing, but PAUSE also uses it. PAUSE resets to 0 bit 15, & puts in bits 0 to 14 the length of the pause. When these have been counted down to zero, the pause stops. If the pause stops because of a key depression, bit 15 is set to 1 again.
|-
|16438||COORDS||x-coordinate of last point PLOTted.
|-
|16439|| || y-coordinate of last point PLOTted.
|-
|16440||PR_CC||Less significant byte of address of next position for LPRINT to print as (in PRBUFF).
|-
|16441||S_POSN||Column number for PRINT position.
|-
|16442|| ||Line number for PRINT position.
|-
|16443||CDFLAG||Various flags. Bit 7 is on (1) during compute & display mode.
|-
|16444||PRBUFF||Printer buffer (33rd character is NEWLINE).
|-
|16477||MEMBOT||Calculator's memory area; used to store numbers that cannot conveniently be put on the calculator stack.
|-
|16507|| || not used
|-
|16509|| || First BASIC line.
|}

Each BASIC line is stored as:

2 byte line number (in big-endian format)
2 byte length of text including NEWLINE (in little endian format, length "excludes" the line number and length, i.e. to skip between lines you add "length of text" +4 bytes.
text (BASIC tokens)
NEWLINE (0x76)

When a numeric constant is included in the text of a BASIC line, an ASCII string displaying the constant value will be inserted, followed by the token 0x7E, and the next 5 bytes are the value of the constant in floating point format.

=== BASIC Variables Table ===
Following the last BASIC line comes the VARIABLEs table. Each entry in this table is of varying length and format. The first byte in each entry is the variable name, of which the upper 3 bits indicate the variable type.
{| class="wikitable"
! title="Variable Name" | Variable Name
! title="Description" |Description

|-
|011nnnnn|| single letter variable name, followed by 5 byte number
|-
|101nnnnn ||multi letter variable name (last letter has high bit set), followed by 5 byte number
|-
|100nnnnn || array of numbers
|-
|111nnnnnn || control variable of a for-next loop
|-
|010nnnnn ||single letter variable name - 0x20, 2 byte string length, text of string
|-
|110nnnnn || array of characters
|}

=== ZX81 BASIC Tokens ===
{|
{| class="wikitable"
! title="Token" | Token (Decimal)
! title="Description" |Description

|-
|0||
|-
|11||"
|-
|12||£
|-
|13||$
|-
|14||:
|-
|15||?
|-
|16||(
|-
|17||)
|-
|18||>
|-
|19||<
|-
|20||=
|-
|21||+
|-
|22||-
|-
|23||*
|-
|24||/
|-
|25||;
|-
|26||,
|-
|27||.
|-
|28||0
|-
|29||1
|-
|30||2
|-
|31||3
|-
|32||4
|-
|33||5
|-
|34||6
|-
|35||7
|-
|36||8
|-
|37||9
|-
|38||A
|-
|39||B
|-
|40||C
|-
|41||D
|-
|42||E
|-
|43||F
|-
|44||G
|-
|45||H
|-
|46||I
|-
|47||J
|-
|48||K
|-
|49||L
|-
|50||M
|-
|51||N
|-
|52||O
|-
|53||P
|-
|54||Q
|-
|55||R
|-
|56||S
|-
|57||T
|-
|58||U
|-
|59||V
|-
|60||W
|-
|61||X
|-
|62||Y
|-
|63||Z
|-
|64||RND
|-
|65||INKEY$
|-
|66||PI
|-
|112||<cursor up>
|-
|113||<cursor down>
|-
|114||<cursor left>
|-
|115||<cursor right>
|-
|116||GRAPHICS
|-
|117||EDIT
|-
|118||NEWLINE
|-
|119||RUBOUT
|-
|120||/
|-
|121||FUNCTION
|-
|127||cursor
|-
|128||
|-
|139||"
|-
|140||£
|-
|141||$
|-
|142||:
|-
|143||?
|-
|144||(
|-
|145||)
|-
|146||>
|-
|147||<
|-
|148||=
|-
|149||+
|-
|150||-
|-
|151||*
|-
|152||/
|-
|153||;
|-
|154|||-
|-
|155||.
|-
|156||0
|-
|157||1
|-
|158||2
|-
|159||3
|-
|160||4
|-
|161||5
|-
|162||6
|-
|163||7
|-
|164||8
|-
|165||9
|-
|166||A
|-
|167||B
|-
|168||C
|-
|169||D
|-
|170||E
|-
|171||F
|-
|172||G
|-
|173||H
|-
|174||I
|-
|175||J
|-
|176||K
|-
|177||L
|-
|178||M
|-
|179||N
|-
|180||O
|-
|181||P
|-
|182||Q
|-
|183||R
|-
|184||S
|-
|185||T
|-
|186||U
|-
|187||V
|-
|188||W
|-
|189||X
|-
|190||Y
|-
|191||Z
|-
|192||""
|-
|193||AT
|-
|194||TAB
|-
|195||?
|-
|196||CODE
|-
|197||VAL
|-
|198||LEN
|-
|199||SIN
|-
|200||COS
|-
|201||TAN
|-
|202||ASN
|-
|203||ACS
|-
|204||ATN
|-
|205||LN
|-
|206||EXP
|-
|207||INT
|-
|208||SQR
|-
|209||SGN
|-
|210||ABS
|-
|211||PEEK
|-
|212||USR
|-
|213||STR$
|-
|214||CHR$
|-
|215||NOT
|-
|216||**
|-
|217||OR
|-
|218||AND
|-
|219||<=
|-
|220||>=
|-
|221||<>
|-
|222||THEN
|-
|223||TO
|-
|224||STEP
|-
|225||LPRINT
|-
|226||LLIST
|-
|227||STOP
|-
|228||SLOW
|-
|229||FAST
|-
|230||NEW
|-
|231||SCROLL
|-
|232||CONT
|-
|233||DIM
|-
|234||REM
|-
|235||FOR
|-
|236||GOTO
|-
|237||GOSUB
|-
|238||INPUT
|-
|239||LOAD
|-
|240||LIST
|-
|241||LET
|-
|242||PAUSE
|-
|243||NEXT
|-
|244||POKE
|-
|245||PRINT
|-
|246||PLOT
|-
|247||RUN
|-
|248||SAVE
|-
|249||RAND
|-
|250||IF
|-
|251||CLS
|-
|252||UNPLOT
|-
|253||CLEAR
|-
|254||RETURN
|-
|255||COPY

|}

=== References ===
[http://www.worldofspectrum.org/ZX81BasicProgramming/ ZX81 BASIC Programming]

Sinclair BASIC tokenized file

2013-05-22T21:52:39Z

Jonnosan: add BASIC tokens

Sinclair BASIC is a dialect of the BASIC programming language created by by Nine Tiles Networks Ltd and used in the 8-bit home computers from Sinclair Research and Timex Sinclair.

The original 4KB version was developed for the Sinclair ZX80, followed by an 8KB version for the ZX81 and 16 KB version for ZX Spectrum.

Some unusual features of the Sinclair BASIC:
* There were keys on the keyboard for each BASIC keyword. For example, pressing P caused the entire command PRINT to appear. Some commands needed multiple keypresses to enter, For example, BEEP was keyed by pressing CAPS SHIFT plus SYMBOL SHIFT to access extended mode, keeping SYMBOL SHIFT held down and pressing Z.
* When programs where SAVEd, the file written to disk or tape contained all of BASIC's internal state information, including the values of any defined basic variables, as well as the BASIC tokens.

=== BASIC File Layout ===
On a ZX81 , a saved BASIC file is a snapshot of the computer memory from memory location 16393 through to the end of the variable table. There is no header.
{| class="wikitable"
! title="Memory Address" | Address
! title="Name" | Name
! title="Description" |Description
|-

|16393||VERSN ||0 Identifies ZX81 BASIC in saved programs.
|-
|16394||E_PPC||Number of current line (with program cursor).
|-
|16396||D_FILE||Pointer to the start of the 'Display file', i.e. what is being displayed on screen
|-
|16398||DF_CC||Address of PRINT position in display file. Can be poked so that PRINT output is sent elsewhere.
|-
|16400||VARS||Pointer to start of BASIC Variable table
|-
|16402||DEST||Address of variable in assignment.
|-
|16404||E_LINE||Pointer to line currently being entered
|-
|16406||CH_ADD||Address of the next character to be interpreted: the character after the argument of PEEK, or the NEWLINE at the end of a POKE statement.
|-
|16408||X_PTR||Address of the character preceding the marker.
|-
|16410||STKBOT||pointer to start (bottom) of stack
|-
|16412||STKEND||pointer to end (top) of stack
|-
|16414||BERG||Calculator's b register.
|-
|16415||MEM||Address of area used for calculator's memory. (Usually MEMBOT, but not always.)
|-
|16417|| ||not used
|-
|16418||DF_SZ||The number of lines (including one blank line) in the lower part of the screen.
|-
|16419||S_TOP||The number of the top program line in automatic listings.
|-
|16421||LAST_K||Shows which keys pressed.
|-
|16423|| || Debounce status of keyboard.
|-
|16424||MARGIN||Number of blank lines above or below picture: 55 in Britain, 31 in America.
|-
|16425||NXTLIN||Address of next program line to be executed.
|-
|16427||OLDPPC||Line number of which CONT jumps.
|-
|16429||FLAGX||Various flags.
|-
|16430||STRLEN||Length of string type destination in assignment.
|-
|16432||T_ADDR||Address of next item in syntax table (very unlikely to be useful).
|-
|16434||SEED||The seed for RND. This is the variable that is set by RAND.
|-
16436||FRAMES||Counts the frames displayed on the television. Bit 15 is 1. Bits 0 to 14 are decremented for each frame set to the television. This can be used for timing, but PAUSE also uses it. PAUSE resets to 0 bit 15, & puts in bits 0 to 14 the length of the pause. When these have been counted down to zero, the pause stops. If the pause stops because of a key depression, bit 15 is set to 1 again.
|-
|16438||COORDS||x-coordinate of last point PLOTted.
|-
|16439|| || y-coordinate of last point PLOTted.
|-
|16440||PR_CC||Less significant byte of address of next position for LPRINT to print as (in PRBUFF).
|-
|16441||S_POSN||Column number for PRINT position.
|-
|16442|| ||Line number for PRINT position.
|-
|16443||CDFLAG||Various flags. Bit 7 is on (1) during compute & display mode.
|-
|16444||PRBUFF||Printer buffer (33rd character is NEWLINE).
|-
|16477||MEMBOT||Calculator's memory area; used to store numbers that cannot conveniently be put on the calculator stack.
|-
|16507|| || not used
|-
|16509|| || First BASIC line.
|}

Each BASIC line is stored as:

2 byte line number (in big-endian format)
2 byte length of text including NEWLINE (in little endian format, length "excludes" the line number and length, i.e. to skip between lines you add "length of text" +4 bytes.
text (BASIC tokens)
NEWLINE (0x76)

When a numeric constant is included in the text of a BASIC line, an ASCII string displaying the constant value will be inserted, followed by the token 0x7E, and the next 5 bytes are the value of the constant in floating point format.

Following the last BASIC line comes the VARIABLEs table. Each entry in this table is of varying length and format. The first byte in each entry is the variable name, of which the upper 3 bits indicate the variable type.
{| class="wikitable"
! title="Variable Name" | Variable Name
! title="Description" |Description

|-
|011nnnnn|| single letter variable name, followed by 5 byte number
|-
|101nnnnn ||multi letter variable name (last letter has high bit set), followed by 5 byte number
|-
|100nnnnn || array of numbers
|-
|111nnnnnn || control variable of a for-next loop
|-
|010nnnnn ||single letter variable name - 0x20, 2 byte string length, text of string
|-
|110nnnnn || array of characters
|}

{|
{| class="wikitable"
! title="Token" | Token (Decimal)
! title="Description" |Description

|-
|0||
|-
|11||"
|-
|12||£
|-
|13||$
|-
|14||:
|-
|15||?
|-
|16||(
|-
|17||)
|-
|18||>
|-
|19||<
|-
|20||=
|-
|21||+
|-
|22||-
|-
|23||*
|-
|24||/
|-
|25||;
|-
|26||,
|-
|27||.
|-
|28||0
|-
|29||1
|-
|30||2
|-
|31||3
|-
|32||4
|-
|33||5
|-
|34||6
|-
|35||7
|-
|36||8
|-
|37||9
|-
|38||A
|-
|39||B
|-
|40||C
|-
|41||D
|-
|42||E
|-
|43||F
|-
|44||G
|-
|45||H
|-
|46||I
|-
|47||J
|-
|48||K
|-
|49||L
|-
|50||M
|-
|51||N
|-
|52||O
|-
|53||P
|-
|54||Q
|-
|55||R
|-
|56||S
|-
|57||T
|-
|58||U
|-
|59||V
|-
|60||W
|-
|61||X
|-
|62||Y
|-
|63||Z
|-
|64||RND
|-
|65||INKEY$
|-
|66||PI
|-
|112||<cursor up>
|-
|113||<cursor down>
|-
|114||<cursor left>
|-
|115||<cursor right>
|-
|116||GRAPHICS
|-
|117||EDIT
|-
|118||NEWLINE
|-
|119||RUBOUT
|-
|120||/
|-
|121||FUNCTION
|-
|127||cursor
|-
|128||
|-
|139||"
|-
|140||£
|-
|141||$
|-
|142||:
|-
|143||?
|-
|144||(
|-
|145||)
|-
|146||>
|-
|147||<
|-
|148||=
|-
|149||+
|-
|150||-
|-
|151||*
|-
|152||/
|-
|153||;
|-
|154|||-
|-
|155||.
|-
|156||0
|-
|157||1
|-
|158||2
|-
|159||3
|-
|160||4
|-
|161||5
|-
|162||6
|-
|163||7
|-
|164||8
|-
|165||9
|-
|166||A
|-
|167||B
|-
|168||C
|-
|169||D
|-
|170||E
|-
|171||F
|-
|172||G
|-
|173||H
|-
|174||I
|-
|175||J
|-
|176||K
|-
|177||L
|-
|178||M
|-
|179||N
|-
|180||O
|-
|181||P
|-
|182||Q
|-
|183||R
|-
|184||S
|-
|185||T
|-
|186||U
|-
|187||V
|-
|188||W
|-
|189||X
|-
|190||Y
|-
|191||Z
|-
|192||""
|-
|193||AT
|-
|194||TAB
|-
|195||?
|-
|196||CODE
|-
|197||VAL
|-
|198||LEN
|-
|199||SIN
|-
|200||COS
|-
|201||TAN
|-
|202||ASN
|-
|203||ACS
|-
|204||ATN
|-
|205||LN
|-
|206||EXP
|-
|207||INT
|-
|208||SQR
|-
|209||SGN
|-
|210||ABS
|-
|211||PEEK
|-
|212||USR
|-
|213||STR$
|-
|214||CHR$
|-
|215||NOT
|-
|216||**
|-
|217||OR
|-
|218||AND
|-
|219||<=
|-
|220||>=
|-
|221||<>
|-
|222||THEN
|-
|223||TO
|-
|224||STEP
|-
|225||LPRINT
|-
|226||LLIST
|-
|227||STOP
|-
|228||SLOW
|-
|229||FAST
|-
|230||NEW
|-
|231||SCROLL
|-
|232||CONT
|-
|233||DIM
|-
|234||REM
|-
|235||FOR
|-
|236||GOTO
|-
|237||GOSUB
|-
|238||INPUT
|-
|239||LOAD
|-
|240||LIST
|-
|241||LET
|-
|242||PAUSE
|-
|243||NEXT
|-
|244||POKE
|-
|245||PRINT
|-
|246||PLOT
|-
|247||RUN
|-
|248||SAVE
|-
|249||RAND
|-
|250||IF
|-
|251||CLS
|-
|252||UNPLOT
|-
|253||CLEAR
|-
|254||RETURN
|-
|255||COPY

|}

=== References ===
[http://www.worldofspectrum.org/ZX81BasicProgramming/ ZX81 BASIC Programming]

Sinclair BASIC tokenized file

2013-05-22T21:44:07Z

Jonnosan:

Sinclair BASIC tokenized file

2013-05-22T21:43:26Z

Jonnosan: layout variable table

Sinclair BASIC tokenized file

2013-05-22T21:33:22Z

Jonnosan: fixed table layout error

Sinclair BASIC tokenized file

2013-05-22T21:32:43Z

Jonnosan: initial version

Tokenized BASIC

2013-05-22T20:35:53Z

Jonnosan: add link to Sinclair BASIC

{{FormatInfo
|subcat=Source code
|thiscat=Tokenized BASIC
|extensions={{ext|bas}}
|image=Sol-screen.jpg
|caption=Sol BASIC screen shot (as simulated in Solace)
}}

'''Tokenized BASIC''' is a method of storing programs in the [[BASIC]] programming language by encoding the various keywords of the language as "tokens" instead of as plain text. Since the tokens are shorter byte sequences than the full text of the keywords, such programs take up less storage space in memory and in external storage such as disks or tapes, which was a significant concern in an era when computers were much more limited in memory and disk space than they are at present. It can also take less processing time for the interpreters to parse the code when it is in the form of tokens, which is another important concern for slower computers. Since computers are much faster and have much more memory and disk space now, tokenized languages are rarely used for source code storage, though compilers may generate intermediate data that is tokenized in some way in the course of producing executable code from text-based sources.

In its heyday of the 1960s through 1980s, BASIC existed in many dialects, designed for specific machine platforms, and the format of tokenized programs was different in each. On systems where file types were commonly identified using extensions, '''.BAS''' was usually used for BASIC programs, while other systems had their own ways of identifying file types and often had a type code specific to their own platform's BASIC interpreter (or multiple codes for different versions of BASIC, such as Apple II DOS's 'I' for Integer BASIC and 'A' for Applesoft floating-point BASIC).

People intending to transfer BASIC programs cross-system would usually export them in text form by piping the output of the LIST command to a text file (which sometimes required special tweaking to get the proper format; for instance, on the Apple II, one needed to do a poke first: '''POKE 33,33''', to set the screen window width narrow enough to defeat the automatic insertion of padding spaces on normal-size lines). Some BASICs made things easier by offering a "save-as-text" option in the SAVE command (sometimes appending ",A", with A for ASCII, worked). Cross-system porting usually required considerable program revision as well due to the great differences between different BASIC dialects.

Specific tokenized BASIC formats:

* [[APF Imagination Machine BASIC tokenized file]]
* [[Apple Integer BASIC tokenized file]]
* [[Applesoft BASIC tokenized file]]
* [[Atari BASIC tokenized file]]
* [[BBC BASIC tokenized file]]
* [[Coleco Adam SmartBASIC tokenized file]]
* [[Commodore BASIC tokenized file]]
* [[Compucolor BASIC tokenized file]]
* [[Exidy Sorcerer BASIC tokenized file]]
* [[GW-BASIC tokenized file]] (or BASICA) (IBM PC and compatibles)
* [[MBASIC tokenized file]] (Microsoft BASIC for CP/M)
* [[NASCOM BASIC tokenized file]]
* [[Ohio Scientific BASIC tokenized file]]
* [[Sinclair BASIC tokenized file]] (for ZX80, ZX81 and Spectrum)
* [[Sol BASIC tokenized file]]
* [[TI BASIC tokenized file]] (TI 99/4A)
* [[Tiny BASIC tokenized file]] (ran on KIM-1 and some other early machines)
* [[TRS-80 Color BASIC tokenized file]]
* [[TRS-80 Level II BASIC tokenized file]]

As a bit of trivia, three of the companies referenced above are named after U.S. states: Texas Instruments (TI), Ohio Scientific, and Connecticut Leather Company (Coleco).

== Links and references ==
* [http://edmond.orignac.pagesperso-orange.fr/detokenizer.html Detokenizers for Microsoft BASICs]
* [http://www.pagetable.com/?p=46 Microsoft 6502 BASIC archeology]

Tokenized BASIC

2013-05-22T20:35:25Z

Jonnosan:

{{FormatInfo
|subcat=Source code
|thiscat=Tokenized BASIC
|extensions={{ext|bas}}
|image=Sol-screen.jpg
|caption=Sol BASIC screen shot (as simulated in Solace)
}}

'''Tokenized BASIC''' is a method of storing programs in the [[BASIC]] programming language by encoding the various keywords of the language as "tokens" instead of as plain text. Since the tokens are shorter byte sequences than the full text of the keywords, such programs take up less storage space in memory and in external storage such as disks or tapes, which was a significant concern in an era when computers were much more limited in memory and disk space than they are at present. It can also take less processing time for the interpreters to parse the code when it is in the form of tokens, which is another important concern for slower computers. Since computers are much faster and have much more memory and disk space now, tokenized languages are rarely used for source code storage, though compilers may generate intermediate data that is tokenized in some way in the course of producing executable code from text-based sources.

In its heyday of the 1960s through 1980s, BASIC existed in many dialects, designed for specific machine platforms, and the format of tokenized programs was different in each. On systems where file types were commonly identified using extensions, '''.BAS''' was usually used for BASIC programs, while other systems had their own ways of identifying file types and often had a type code specific to their own platform's BASIC interpreter (or multiple codes for different versions of BASIC, such as Apple II DOS's 'I' for Integer BASIC and 'A' for Applesoft floating-point BASIC).

People intending to transfer BASIC programs cross-system would usually export them in text form by piping the output of the LIST command to a text file (which sometimes required special tweaking to get the proper format; for instance, on the Apple II, one needed to do a poke first: '''POKE 33,33''', to set the screen window width narrow enough to defeat the automatic insertion of padding spaces on normal-size lines). Some BASICs made things easier by offering a "save-as-text" option in the SAVE command (sometimes appending ",A", with A for ASCII, worked). Cross-system porting usually required considerable program revision as well due to the great differences between different BASIC dialects.

Specific tokenized BASIC formats:

* [[APF Imagination Machine BASIC tokenized file]]
* [[Apple Integer BASIC tokenized file]]
* [[Applesoft BASIC tokenized file]]
* [[Atari BASIC tokenized file]]
* [[BBC BASIC tokenized file]]
* [[Coleco Adam SmartBASIC tokenized file]]
* [[Commodore BASIC tokenized file]]
* [[Compucolor BASIC tokenized file]]
* [[Exidy Sorcerer BASIC tokenized file]]
* [[GW-BASIC tokenized file]] (or BASICA) (IBM PC and compatibles)
* [[MBASIC tokenized file]] (Microsoft BASIC for CP/M)
* [[NASCOM BASIC tokenized file]]
* [[Ohio Scientific BASIC tokenized file]]
* [[Sinclair BASIC tokenized file]] for ZX80, ZX81 and Spectrum
* [[Sol BASIC tokenized file]]
* [[TI BASIC tokenized file]] (TI 99/4A)
* [[Tiny BASIC tokenized file]] (ran on KIM-1 and some other early machines)
* [[TRS-80 Color BASIC tokenized file]]
* [[TRS-80 Level II BASIC tokenized file]]

As a bit of trivia, three of the companies referenced above are named after U.S. states: Texas Instruments (TI), Ohio Scientific, and Connecticut Leather Company (Coleco).

== Links and references ==
* [http://edmond.orignac.pagesperso-orange.fr/detokenizer.html Detokenizers for Microsoft BASICs]
* [http://www.pagetable.com/?p=46 Microsoft 6502 BASIC archeology]

Tokenized BASIC

2013-05-22T20:33:42Z

Jonnosan:

{{FormatInfo
|subcat=Source code
|thiscat=Tokenized BASIC
|extensions={{ext|bas}}
|image=Sol-screen.jpg
|caption=Sol BASIC screen shot (as simulated in Solace)
}}

'''Tokenized BASIC''' is a method of storing programs in the [[BASIC]] programming language by encoding the various keywords of the language as "tokens" instead of as plain text. Since the tokens are shorter byte sequences than the full text of the keywords, such programs take up less storage space in memory and in external storage such as disks or tapes, which was a significant concern in an era when computers were much more limited in memory and disk space than they are at present. It can also take less processing time for the interpreters to parse the code when it is in the form of tokens, which is another important concern for slower computers. Since computers are much faster and have much more memory and disk space now, tokenized languages are rarely used for source code storage, though compilers may generate intermediate data that is tokenized in some way in the course of producing executable code from text-based sources.

In its heyday of the 1960s through 1980s, BASIC existed in many dialects, designed for specific machine platforms, and the format of tokenized programs was different in each. On systems where file types were commonly identified using extensions, '''.BAS''' was usually used for BASIC programs, while other systems had their own ways of identifying file types and often had a type code specific to their own platform's BASIC interpreter (or multiple codes for different versions of BASIC, such as Apple II DOS's 'I' for Integer BASIC and 'A' for Applesoft floating-point BASIC).

People intending to transfer BASIC programs cross-system would usually export them in text form by piping the output of the LIST command to a text file (which sometimes required special tweaking to get the proper format; for instance, on the Apple II, one needed to do a poke first: '''POKE 33,33''', to set the screen window width narrow enough to defeat the automatic insertion of padding spaces on normal-size lines). Some BASICs made things easier by offering a "save-as-text" option in the SAVE command (sometimes appending ",A", with A for ASCII, worked). Cross-system porting usually required considerable program revision as well due to the great differences between different BASIC dialects.

Specific tokenized BASIC formats:

* [[APF Imagination Machine BASIC tokenized file]]
* [[Apple Integer BASIC tokenized file]]
* [[Applesoft BASIC tokenized file]]
* [[Atari BASIC tokenized file]]
* [[BBC BASIC tokenized file]]
* [[Coleco Adam SmartBASIC tokenized file]]
* [[Commodore BASIC tokenized file]]
* [[Compucolor BASIC tokenized file]]
* [[Exidy Sorcerer BASIC tokenized file]]
* [[GW-BASIC tokenized file]] (or BASICA) (IBM PC and compatibles)
* [[MBASIC tokenized file]] (Microsoft BASIC for CP/M)
* [[NASCOM BASIC tokenized file]]
* [[Ohio Scientific BASIC tokenized file]]
* [[Sinclair ZX81 BASIC tokenized file]]
* [[Sol BASIC tokenized file]]
* [[TI BASIC tokenized file]] (TI 99/4A)
* [[Tiny BASIC tokenized file]] (ran on KIM-1 and some other early machines)
* [[TRS-80 Color BASIC tokenized file]]
* [[TRS-80 Level II BASIC tokenized file]]

As a bit of trivia, three of the companies referenced above are named after U.S. states: Texas Instruments (TI), Ohio Scientific, and Connecticut Leather Company (Coleco).

== Links and references ==
* [http://edmond.orignac.pagesperso-orange.fr/detokenizer.html Detokenizers for Microsoft BASICs]
* [http://www.pagetable.com/?p=46 Microsoft 6502 BASIC archeology]

Talk:DOS executable (.com)

2013-05-21T08:27:10Z

Jonnosan:

== fixed vs relative addressing? ==

re ''They can only use relative adressing'' - in 8086 mode, a memory address is either
- relative within a segment,
- absolute within a segment
- absolute including a segment address

While it is unknown what segment a given COM file will be loaded into, it IS known (as specified) that it will be loaded from offset 0x100 into that segment. So intra-segment absolute addressing is perfectly valid. [[User talk:jonnosan|jonnosan]] 8:26 21 May 2013(UTC)

== compressed executable vs commandline program ==

Thanks for fixing the initial page. My source, a paper about the file utility mentioned .com files being compressed executables. Guess I should cite more... [[User:Maurice.de.rooij|Maurice.de.rooij]] ([[User talk:Maurice.de.rooij|talk]]) 07:28, 6 December 2012 (UTC)
* [http://scholar.google.nl/scholar?cluster=7943745569952873113 Extensions of the UNIX File Command and Magic File for File Type Identification]
:Ah, yes, that seems a bit wrong (unless they talk about some other, specific COM file). I wanted to add COM some time ago anyway (when I did EXE), but it somehow got lost due to my being busy recently. I just happened to notice it in the "recent changes" and fixed it. On some unrelated note, why can't we delete (or move/rename) any pages? There are a few now that are blanked because they were moved. Is delete/move only for administrators? --[[User:Darkstar|Darkstar]] ([[User talk:Darkstar|talk]]) 17:22, 6 December 2012 (UTC)
::"Move" exists in the pull-down menu to the right of "View history". I think "Delete" is reserved for admins, though. [[User:Dan Tobias|Dan Tobias]] ([[User talk:Dan Tobias|talk]]) 18:16, 6 December 2012 (UTC)
:: There seems not to exist such thing as compressed executable COM file, after an extensive search on the Google. Because the source was a university paper, I wrongly assumed that it didnt need verification. Another lesson learned... [[User:Maurice.de.rooij|Maurice.de.rooij]] ([[User talk:Maurice.de.rooij|talk]]) 18:37, 6 December 2012 (UTC)
::: Ah, indeed, I didn't see the "move" up there. Could have made my editing a bit more transparent. --[[User:Darkstar|Darkstar]] ([[User talk:Darkstar|talk]]) 22:22, 6 December 2012 (UTC)

Commodore 64 binary executable

2013-05-20T23:27:11Z

Jonnosan: add ref to CBMFS directory structure

{{FormatInfo
|subcat=Executables
|extensions={{ext|prg}}
}}

Binary files intended to be executed on a Commodore 64 (or emulator of it) are often stored with the extension .prg. (In the original Commodore environment, they generally didn't have an extension but had file type "PRG" in the [[CBMFS#CBM_DOS_Directory_Structure | directory structure]].)

The first two bytes in a PRG file are the memory address that the file should be loaded into (in little-endian format). For a C64 [[Commodore BASIC tokenized file]] file, intended to be loaded into $801, these bytes are $01,$08. Note that these bytes will be ignored (i.e. a PRG file will be loaded into $801) UNLESS the LOAD command had a non-zero parameter after the device number. i.e. LOAD "*",8 will load a file from device 8 (the typical device number for a disk drive) into $801, while LOAD "*",8,1 will load a file into whatever memory address is specified by the first 2 bytes of the PRG.

== Programs and utilities ==
* [http://search.cpan.org/~pawelkrol/D64-File-PRG-0.02/lib/D64/File/PRG.pm D64::File::PRG library for Perl to handle PRG files.]

[[Category:Commodore computers]]

CBMFS

2013-05-20T23:23:31Z

Jonnosan: add directory structure heading

{{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 runs in the drive itself, not on the computer the drive was attached to.

The most popular CBM drive was the 1541, which supported 35 tracks using GCR encoding.

==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.

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.

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 (for a 35 track image)

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.

1 2 3 4 5 6
---- ----- ----- ----- ----- -----
17/0 17/10 17/20 17/1 17/11 0/52
(11/00) (11/0A) (11/14) (11/01) (11/0B) (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.

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.

Disk format |Tracks|Header 7/8|Dos type|DiskDos
| |allsechdrs| |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.

Code Error Type 1541 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.
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.
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 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.

Code Error Type 1541 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.

Code Error Type 1541 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.

Code Error Type 1541 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).

[[Category:Commodore computers]]

Apple DOS file system

2013-05-20T22:10:50Z

Jonnosan:

Apple DOS 3.3 disks were 5 1/4" media containing 35 tracks of 16 sectors using a GCR encoding.

The DOS executable was stored on disk. The Disk ][ controller card (typically placed in slot #6 of an Apple ][) contained firmware that when started (via the command PR#6) would load the track $00, sector $00 into memory and start executing. In the case of a DOS boot disk, that sector would contain code that loaded the full DOS into memory, this was always stored in the first 3 tracks of a DOS boot disk.

When a new DOS boot disk was created (using the INIT command), the DOS in memory would be written to the disk being INITed. This made it easy for people to create variants of DOS (by altering the running copy of DOS then INITing a new disk). Common modifications made include changing the GCR encoding or the sync and sector header bytes (to prevent the copying of a disk via normal DOS copy programs), and extending the number of tracks per disk (up to 40)

=== Volume Table Of Contents ===
A standard Apple DOS 3.3 has a structure called a Volume Table of Contents (VTOC) stored at
track $11, sector $00

The contents of the VTOC are:

offset
-----
$00 not used
$01 track number of first catalog sector
$02 sector number of first catalog sector
$03 release number of DOS used to INIT this disk
$04-05 not used
$06 Diskette volume number (1-254)
$07-26 not used
$27 maximum number of track/sector pairs which will fit in one file track/sector
list sector (122 for 256 byte sectors)
$28-2F not used
$30 last track where sectors were allocated
$31 direction of track allocation (+1 or -1)
$32-33 not used
$34 number of tracks per diskette (normally 35)
$35 number of sectors per track (13 or 16)
$36-37 number of bytes per sector (LO/HI format)
$38-3B bit map of free sectors in track 0
$3C-3F bit map of free sectors in track 1
$40-43 bit map of free sectors in track 2
...
$BC-BF bit map of free sectors in track 33
$CO-C3 bit map of free sectors in track 34
$C4-FF bit maps for additional tracks if there are more than 35 tracks per diskette

=== Catalog ===
The catalog consists of a 35 byte "File Descriptive Entry" for each file on the disk. The catalog is a chain of sectors, the location of the first Catalog sector is found by looking in the VTOC.

offset
----
$00 Not Used
$01 track number of next catalog sector
$02 sector number of next catalog sector
$03-0A not used
$0B-2D First file descriptive entry
$2E-50 Second file descriptive entry
$51-73 Third file descriptive entry
$74-96 Fourth file descriptive entry
$97-B9 Fifth file descriptive entry
$BA-DC Sixth file descriptive entry
$DD-FF Seventh file descriptive entry

=== File Descriptive Entry ===
offset
----
$00 Track of first track/sector list sector, if this is a deleted file this contains FF
and the original track number is copied to the last byte of the file name (BYTE 20)
If this byte contains a 00, the entry is assumed to never have been used and is
available for use. (This means track 0 can never be used for data even if the DOS image
is 'wiped' from the disk)
$01 Sector of first track/sector list sector
$02 File type and flags:
$80+file type - file is locked
$00+file type - file is not locked
$00 - TEXT file
$01 - INTEGER BASIC file
$02 - APPLESOFT BASIC file
$04 - BINARY file
$08 - S type file
$10 - RELOCATABLE object module file
$20 - a type file
$40 - b type file
$03-20 File Name (30 characters)
$21-22 Length of file in sectors (LO/HI format)

=== Track Sector List Format ===
$00 Not used
$01 Track number of next T/S list of one is needed or zero if no more t/s list
$02 Sector number of next T/S list (if one is present)
$03-04 Not used
$05-06 Sector offset in file of the first sector described by this list
$07-oB Not used
$0C-0D Track and sector of first data sector or zeros
$0E-0F Track and sector of second data sector or zeros
$10-FF Up to 120 more track and sector pairs

Apple DOS file system

2013-05-20T22:10:13Z

Jonnosan: Created page with "Apple DOS 3.3 disks were 5 1/4" media containing 35 tracks of 16 sectors using a GCR encoding. The DOS executable was stored on disk. The Disk ][ controller card (typically p..."

Apple DOS 3.3 disks were 5 1/4" media containing 35 tracks of 16 sectors using a GCR encoding.

The DOS executable was stored on disk. The Disk ][ controller card (typically placed in slot #6 of an Apple ][) contained firmware that when started (via the command PR#6) would load the track $00, sector $00 into memory and start executing. In the case of a DOS boot disk, that sector would contain code that loaded the full DOS into memory, this was always stored in the first 3 tracks of a DOS boot disk.

When a new DOS boot disk was created (using the INIT command), the DOS in memory would be written to the disk being INITed. This made it easy for people to create variants of DOS (by altering the running copy of DOS then INITing a new disk). Common modifications made include changing the GCR encoding or the sync and sector header bytes (to prevent the copying of a disk via normal DOS copy programs), and extending the number of tracks per disk (up to 40)

=== Volume Table Of Contents ===
A standard Apple DOS 3.3 has a structure called a Volume Table of Contents (VTOC) stored at
track $11, sector $00

The contents of the VTOC are:

offset
-----
$00 not used
$01 track number of first catalog sector
$02 sector number of first catalog sector
$03 release number of DOS used to INIT this disk
$04-05 not used
$06 Diskette volume number (1-254)
$07-26 not used
$27 maximum number of track/sector pairs which will fit in one file track/sector
list sector (122 for 256 byte sectors)
$28-2F not used
$30 last track where sectors were allocated
$31 direction of track allocation (+1 or -1)
$32-33 not used
$34 number of tracks per diskette (normally 35)
$35 number of sectors per track (13 or 16)
$36-37 number of bytes per sector (LO/HI format)
$38-3B bit map of free sectors in track 0
$3C-3F bit map of free sectors in track 1
$40-43 bit map of free sectors in track 2
...
$BC-BF bit map of free sectors in track 33
$CO-C3 bit map of free sectors in track 34
$C4-FF bit maps for additional tracks if there are more than 35 tracks per diskette

=== Catalog ===
The catalog consists of a 35 byte "File Descriptive Entry" for each file on the disk. The catalog is a chain of sectors, the location of the first Catalog sector is found by looking in the VTOC.

offset
----
$00 Not Used
$01 track number of next catalog sector
$02 sector number of next catalog sector
$03-0A not used
$0B-2D First file descriptive entry
$2E-50 Second file descriptive entry
$51-73 Third file descriptive entry
$74-96 Fourth file descriptive entry
$97-B9 Fifth file descriptive entry
$BA-DC Sixth file descriptive entry
$DD-FF Seventh file descriptive entry

=== File Descriptive Entry ===
offset
----
$00 Track of first track/sector list sector, if this is a deleted file this contains FF
and the original track number is copied to the last byte of the file name (BYTE 20)
If this byte contains a 00, the entry is assumed to never have been used and is
available for use. (This means track 0 can never be used for data even if the DOS image
is 'wiped' from the disk)

$01 Sector of first track/sector list sector
$02 File type and flags:
$80+file type - file is locked
$00+file type - file is not locked
$00 - TEXT file
$01 - INTEGER BASIC file
$02 - APPLESOFT BASIC file
$04 - BINARY file
$08 - S type file
$10 - RELOCATABLE object module file
$20 - a type file
$40 - b type file
$03-20 File Name (30 characters)
$21-22 Length of file in sectors (LO/HI format)

=== Track Sector List Format ===
$00 Not used
$01 Track number of next T/S list of one is needed or zero if no more t/s list
$02 Sector number of next T/S list (if one is present)
$03-04 Not used
$05-06 Sector offset in file of the first sector described by this list
$07-oB Not used
$0C-0D Track and sector of first data sector or zeros
$0E-0F Track and sector of second data sector or zeros
$10-FF Up to 120 more track and sector pairs

Commodore 64 binary executable

2013-05-20T21:51:46Z

Jonnosan:

{{FormatInfo
|subcat=Executables
|extensions={{ext|prg}}
}}

Binary files intended to be executed on a Commodore 64 (or emulator of it) are often stored with the extension .prg. (In the original Commodore environment, they generally didn't have an extension but had file type "PRG" in the directory structure.)

The first two bytes in a PRG file are the memory address that the file should be loaded into (in little-endian format). For a C64 [[Commodore BASIC tokenized file]] file, intended to be loaded into $801, these bytes are $01,$08. Note that these bytes will be ignored (i.e. a PRG file will be loaded into $801) UNLESS the LOAD command had a non-zero parameter after the device number. i.e. LOAD "*",8 will load a file from device 8 (the typical device number for a disk drive) into $801, while LOAD "*",8,1 will load a file into whatever memory address is specified by the first 2 bytes of the PRG.

== Programs and utilities ==
* [http://search.cpan.org/~pawelkrol/D64-File-PRG-0.02/lib/D64/File/PRG.pm D64::File::PRG library for Perl to handle PRG files.]

[[Category:Commodore computers]]

GEOS Font

2013-05-20T21:33:24Z

Jonnosan: ontent taken from http://zimmers.net/geos/docs/fontfile.txt which is unattributed and has been floating around BBS and web sites for decades

GEOS Font files are multiple point size bitmaps stored in [[GEOS VLIR]] files; the chain number (0-126) is the
point size. GEOS limits a font to a point size of 48. This is
probably due to memory limitations for storing the font.
Nonexistent point sizes have VLIR chain addresses of $00,$FF.

The header in each font file contains Font ID and point size
information for the fonts in the file. This includes the FONT ID
at offset $80 (128) within the header block, the 32 byte point
size table at $82 (130) ordered from smallest to largest (padded
with 0's), and the 32 byte font sizes at $61 (97) ordered from
smallest to largest (padded with 0's). This leaves room for 16
fonts per font file.

Font files are identified by a unique ID number which is
stored in the file's info sector at offset 130. The info sector
contains a word identifier for each point size in the font. These
identifiers have the form: ID# * 8 + point size. In other words,
bits 15-6 represent the font number while bits 0-5 hold the point
size. These ID words are used by GEOwrite and GEOpaint.

0 BSW 13 Tilden
1 University 14 Evans
2 California 15 Durant
3 Roma 16 Telegraph
4 Dwinelle 17 Superb
5 Cory 18 Bowditch
6 Tolman 19 Ormond
7 Bubble 20 Elmwood
8 Fontknox 21 Hearst
9 Harmon 21 Brennens (BUG)
10 Mykonos 23 Channing
11 Boalt 24 Putnam
12 Stadium 25 LeConte

Each VLIR in a font file is organized as follows:

OffSet Description
------- -------------------------------------------------------
$00 Number of pixels minus 1 above the underline. This is
the line of print.
$01-$02 Number of bytes in the bit stream.
$03 Point size, character height in pixels.
$04-$05 Index from beginning of font to table of bit stream
indices. Usually $0008.
$06-$07 Index from beginning of font to first bit stream.
$08-??? Table of words which are indices into the bit streams;
one for each character from space (32) to the tilde
(126). There is also an extra index on the end. This
extra index is needed because the difference between a
character's index and the next character's index is the
width of the character in pixels.
???-??? Pointed to by $06-$07. The font is stored as several
bit streams, one for each line of pixels. The point
size is the number of bit streams. All the character
images are stored in the bit stream. The GEOS KERNAL
has some very sophisticated bit manipulation routines
for accessing any given character.

(content taken from http://zimmers.net/geos/docs/fontfile.txt which is unattributed and has been floating around BBS and web sites for decades)

Fonts

2013-05-20T21:29:32Z

Jonnosan: added GEOS font

{{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.

* [[Acorn Font]]
* [[BDF]]
* [[CID]], [[TFM]], [[OFM]], [[OVF]], [[OVP]], [[MetaFont]] TeX Fonts and support data
* [[dfont]]
* [[EOT|Embedded OpenType]]
* [[FON]] (Windows bitmap fonts)
* [[GEOS Font]]
* [[OTF|OpenType]]
* [[Open File Format]]
* [[PFB]], [[PFM]], [[AFM]], [[BDF]] (Adobe font formats)
* [[sfnt]]
* [[TTF|TrueType]]
* [[WOFF|Web Open Font Format]]

See [https://en.wikipedia.org/wiki/Category:Font_formats Wikipedia] for more.

==Resources==
* O'Reilly, "Fonts and Encodings", Yannis Haralambous, ISBN 978-0-596-10242-5
* [http://www.mcsweeneys.net/articles/im-comic-sans-asshole I'm Comic Sans, Asshole!]

[[Category:Fonts| ]]

GEOS VLIR

2013-05-20T21:26:05Z

Jonnosan: Content taken from http://unusedino.de/ec64/technical/formats/geos.html in Peter Scheper's compendium of c64 file formats

Later on in the life of the C64, the GEOS OS came out. It was a system
much like many other windowing OS's (MAC OS, Windows) in that it used
icons, windows, a mouse pointer and resource drivers. In order to contain
all the information needed for the windowing system (icon, window position,
creation time/date), a new filetype called VLIR was needed and directory
changes were made. While GEOS files might not be of interest to many of the
emulator users, it is likely that these files will be encountered, and
knowledge of them would be helpful.

There are actually two types of GEOS files, VLIR and SEQuential. Don't
confuse the GEOS SEQuential type with that of the standard D64 SEQ file.
They are related, but not the same. VLIR are described in more detail
following this paragraph. GEOS SEQuential files are all non-VLIR files,
including normal PRG, USR and SEQ types.

GEOS files usually have an entity attached called an INFO block. It
contains ICON info, author, file description, load address etc. However,
just because an INFO block does not exist for a given file, does not mean
that the file is not a GEOS file.

Each GEOS VLIR file or application is comprised of many separate chains
(called RECORDS) for different sections of the app/file. Each RECORD can be
loaded in separately and overtop of other ones. Below is a dump of the
first directory sector of the GEOS 2.0 disk. Note the first entry seems
normal enough, but the rest have additional information in the normally
unused section of the entry.

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
-----------------------------------------------
00: 12 04 82 13 00 47 45 4F 53 20 56 32 2E 30 20 45 <- Normal entry
10: 4E 47 4C 2E A0 00 00 00 00 00 00 00 00 00 58 00
20: 00 00 83 02 02 44 45 53 4B 20 54 4F 50 A0 A0 A0 <- First GEOS file.
30: A0 A0 A0 A0 A0 02 0F 01 04 58 08 13 0D 23 78 00 <- Note extra info
40: 00 00 83 0B 13 43 4F 4D 4D 20 31 33 35 31 28 61 from offset $15 to
50: 29 A0 A0 A0 A0 08 0F 00 0A 58 05 09 15 24 03 00 $1D.
60: 00 00 83 0F 0D 4D 50 53 2D 38 30 31 A0 A0 A0 A0
70: A0 A0 A0 A0 A0 0F 05 00 09 56 07 19 01 00 04 00
80: 00 00 83 08 0D 43 4F 4E 46 49 47 55 52 45 A0 A0
90: A0 A0 A0 A0 A0 08 05 01 0E 58 05 1F 0B 31 4E 00
A0: 00 00 83 01 10 50 41 49 4E 54 20 44 52 49 56 45
B0: 52 53 A0 A0 A0 01 08 00 06 57 08 0C 0E 00 12 00
C0: 00 00 83 0B 05 70 72 65 66 65 72 65 6E 63 65 20
D0: 6D 67 72 A0 A0 0B 12 00 05 56 0A 09 13 2D 16 00
E0: 00 00 83 08 11 70 61 64 20 63 6F 6C 6F 72 20 6D
F0: 67 72 A0 A0 A0 08 07 00 05 58 05 19 0C 10 16 00

Lets analyze the second entry to see what's all involved with GEOS files.
Note, the offset values have been changed to 0 to make referencing easier.

00: 00 00 83 02 02 44 45 53 4B 20 54 4F 50 A0 A0 A0
10: A0 A0 A0 A0 A0 02 0F 01 04 58 08 13 0D 23 78 00

Byte: $02: C64 filetype (see the section on D64 for an explanation) REL
files are not allowed.
03-04: Starting track/sector (02/02 from above) of C64 file if GEOS
filetype is $00. If GEOS filetype is non-zero, track/sector
of single-sector RECORD block
05-14: Filename (in ASCII, padded with $A0, case varies)
15-16: Track/sector location of info block
17: GEOS file structure
$00 - Sequential
01 - VLIR file
18: GEOS filetype
$00 - Non-GEOS (normal C64 file)
01 - BASIC
02 - Assembler
03 - Data file
04 - System File
05 - Desk Accessory
06 - Application
07 - Application Data (user-created documents)
08 - Font File
09 - Printer Driver
0A - Input Driver
0B - Disk Driver (or Disk Device)
0C - System Boot File
0D - Temporary
0E - Auto-Execute File
0F-FF - Undefined
19: Year (1900 + value)
1A: Month (1-12, $01 to $0C)
1B: Day (1-31, $01 to $1F)
1C: Hour (0-23, $00 to $17) in military format
1D: Minute (0-59, $00 to $3B)
1E-1F: Filesize, in sectors (low/high byte order)

If the values at byte $18 is 00 then we have a normal, sequential, C64
file, without an info block. If the value at byte $18 is anything other
than 00, we have a GEOS file, be it VLIR or sequential, with an info block.

One big addition to the directory is the TIME STAMP contained at $19-$1D.
The year is simply the number 1900 plus whatever is stored at that location
so the year 2005 would have a $69 (105 decimal) stored there. The rest of
the values are limited as described above.

The INFO BLOCK stores items like the ICON, size, load address, file
types, description, etc, and is always only 1 sector long. Since there is a
fixed space to store information, the ICON height, width and bitmap length
must be the same. Here is a sample info block, and layout...

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
----------------------------------------------- ----------------
00: 00 FF 03 15 BF 3F 83 F8 40 44 04 8E 38 E2 B5 93 ????+??°@D??8?+?
10: 59 AA 92 A9 B5 93 59 AA 92 A9 BF 93 F9 B1 93 19 Y???+?Y???+?????
20: 8E 10 E1 BB 93 B9 B5 93 59 AA 92 A9 B5 93 59 AE ??????+?Y???+?Y?
30: 92 E9 B1 93 19 80 10 01 BF 93 F9 FF D7 FD 80 38 ????????+??????8
40: 03 FF FF FF 83 05 00 00 2E D9 54 00 2E 50 68 6F ????????.+T?.Pho
50: 74 6F 20 4D 67 72 20 20 20 56 32 2E 31 00 00 00 to?Mgr???V2.1???
60: 00 43 68 72 69 73 20 48 61 77 6C 65 79 00 00 00 ?Chris?Hawley???
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ????????????????
80: 00 00 00 00 00 00 00 00 00 53 61 76 65 20 70 68 ?????????Save?ph
90: 6F 74 6F 20 69 6D 61 67 65 73 20 69 6E 20 61 20 oto?images?in?a?
A0: 53 61 76 65 20 70 68 6F 74 6F 20 69 6D 61 67 65 Save?photo?image
B0: 73 20 69 6E 20 61 20 70 68 6F 74 6F 20 61 6C 62 s?in?a?photo?alb
C0: 75 6D 20 66 6F 72 20 6C 61 74 65 72 20 75 73 65 um?for?later?use
D0: 20 69 6E 20 67 65 6F 57 72 69 74 65 20 6F 72 20 ?in?geoWrite?or?
E0: 67 65 6F 50 61 69 6E 74 2E 00 02 85 06 85 07 85 geoPaint.???????
F0: 08 85 09 85 16 A9 04 85 11 A9 00 85 10 4C 2F C2 ?????????????L/+

Byte: $00-01: Contains $00/$FF since its only 1 sector long
02-04: Information sector ID bytes (03 15 BF). The "03" is likely
the bitmap width, and the "15" is likely the bitmap height,
but rare exceptions do exist to this!
05-43: Icon bitmap (sprite format, 63 bytes)
44: C64 filetype (same as that from the directory entry)
45: GEOS filetype (same as that from the directory entry)
46: GEOS file structure (same as that from the dir entry)
47-48: Program load address
49-4A: Program end address (only with accessories)
4B-4C: Program start address
4D-60: Class text (terminated with a $00)
61-74: Author (with application data: name of application disk,
terminated with a $00. This string may not necessarily be
set, or it may contain invalid data)
The following GEOS files have authors:
1 - BASIC
2 - Assembler
5 - Desk Accessory
6 - Application
9 - Printer Driver
10 - Input Driver
75-88: If a document, the name of the application that created it.
89-9F: Available for applications, unreserved.
A0-FF: Description (terminated with a $00)

Note: all the text strings above are in ASCII, not PETASCII.

If the file is a VLIR, then the RECORD block is of interest. This single
sector is made up of up to 127 track/sector pointers, each of which point
to program sections (called RECORDS). VLIR files are comprised of loadable
RECORDS (overlays, if you wish to use PC terminology). The first RECORD is
what is always loaded first when you run that application. After that, the
OS loads whatever RECORD it needs. Here is a partial sample of the RECORD
sector...

00: 00 FF 08 00 09 04 09 03 0A 0A 0B 11 0F 11 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Byte: $00-01: Contains 00/FF since its only 1 sector long
02-03: Starting track/sector (8,0) for the first RECORD
04-05: Starting track/sector (9,4) for the second RECORD
06-07: Starting track/sector (9,3) for the third RECORD
08-09: fourth RECORD (10/10)
0A-0B: fifth RECORD (11/17)
0C-0D: sixth RECORD (15/17)
0E-0F: seventh RECORD (0/0)

When a T/S link of $00/$00 is encountered, we are at the end of the
RECORD block. If the T/S link is a $00/$FF, then the record is not
available.

Note that if you add up the sectors so far, we have only used two, one
for the INFO sector and one for the RECORD sector. Obviously there are more
used, and they are contained in the sector chains from the RECORD sector.
Each t/s link in the RECORD sector points to a chain of sectors, the length
of which is included in the sector count for the GEOS file. Doing a
VALIDATE on a GEOS disk when not in GEOS would de-allocate all these sector
chains (and the RECORD sector as well), which would not be good!

Below is the dump of a BAM sector from a GEOS-formatted D64 image and
there are some changes for GEOS. We have all the typical data (forward t/s
pointer to 18/1, DOS type, disk name/id) but we also have the GEOS-format
signature from $AB-BC. From observation, any GEOS-formatted disk will have
the GEOS signature written in the same place (offset $AB) in the sector
that contains the disk name/ID.

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
----------------------------------------------- ----------------
00: 12 01 41 00 13 FE DF 1F 0A 69 29 0D 15 FF FF 1F ??A??????i)?????
10: 0C 96 D6 16 01 00 00 10 00 00 00 00 11 FD BD 1D ????????????????
20: 15 FF FF 1F 0C 96 D6 16 00 00 00 00 00 00 00 00 ????????????????
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ????????????????
40: 00 00 00 00 00 00 00 00 0F FC FD 05 00 00 00 00 ????????????????
50: 00 00 00 00 06 05 05 05 01 00 40 00 00 00 00 00 ??????????@?????
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ????????????????
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ????????????????
80: 00 00 00 00 00 00 00 00 01 00 02 00 11 FF FF 01 ????????????????
90: 41 70 70 6C 69 63 61 74 69 6F 6E 73 A0 A0 A0 A0 Applications????
A0: A0 A0 4A 44 A0 32 41 A0 A0 A0 A0 13 08 47 45 4F ??JD?2A??????GEO
B0: 53 20 66 6F 72 6D 61 74 20 56 31 2E 30 50 BD 1E S?format?V1.0P??
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 18 2D 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 18,1, but it doesn't seem to matter)
02: Disk DOS version type
$41=1541
03: $2A, DOS version.
04-8F: BAM entries for each track, in groups of four bytes per
track, starting on track 1
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-AC: Border sector trk/sec (see below)
AD-BC: GEOS ID string ("GEOS format V1.x", in ASCII)
BD-DC: Unused (usually $00)
DD-FF: Free sector info for tracks 36-70, used on double-sided
1571 disks only!

The first two bytes at $AB/$AC ($13 $08) are the track/sector location of
the BORDER SECTOR, which is one sector long, has the same layout as a
normal directory sector, and is used for copying files from one disk to
another. When you need to copy a file, you drag the icon to the bottom of
the screen and the file is moved from its normal location in the directory
to the border sector. Since it is only 1 sector, it can only hold 8
entries.

If you want to check to see if a disk is formatted for GEOS, check the
string in the BAM sector starting at $AD (offset 173) for the string "GEOS
format". If it does not match, the disk is not in GEOS format. This is the
way that GEOS itself verifies if a disk is GEOS formatted.

On a D64/1541, here is how GEOS allocates blocks as it either saves files
or needs blocks for other purposes:

Saving files: When there's still at least one free block in the current
track, then the next block is searched for starting at the sector which is
away from the current one by at least the soft interleave. The exceptions
are track 25 and above where the interleave changes to the original
interleave _minus one_.

When stepping to the next track, the sector where the next block of the
files is saved to is computed as following:

New sector = (Next track - Previous Track) * 2 + 4 + Soft interleave

Getting the Border Sector: When allocating the GEOS border sector, the
search starts upwards from sector 19/0 for a free sector and then from
sector 1/0 if no free one has been found yet.

Getting the first sector for saving a file: Start searching from sector 1/0
and, on the first track that has at least one free sector, you start
searching at the sector computed by the form above.

=== How to detect if a file is GEOS ===

1. Check the bottom 3 bits of the D64 file type (byte position $02 of the
directory entry). If it is not 0, 1 or 2 (but 3 or higher, REL and
above), the file cannot be GEOS.

2. Check the FILE STRUCTURE and FILE TYPE bytes (byte position $23 and $24
respectively). If they are both $00, then the file is not GEOS, but is a
normal D64 filetype (no INFO block either).

3. Check the FILE STRUCTURE byte (position $23). If it is anything other
than $00 or $01, then the file is not GEOS (as those are the only legal
values).

4. If you've reached this point, and everything looks ok, then the file is
GEOS. Now, if the FILE STRUCTURE byte (position $23) is a $01, then the
file is a GEOS VLIR, othersize it is a GEOS SEQ.

5. Check the FILE TYPE byte (position $24). If it is non-zero, then there
is likely an INFO block attached. Check the track/sector pointer at
position $21/22 to see if they are valid numbers (track within the specs
of the disk and sector in range for the track value). If they look good,
then the info block exists.

(Content taken from [http://unusedino.de/ec64/technical/formats/geos.html GEOS.TXT] in Peter Scheper's compendium of c64 file formats)

CBMFS

2013-05-20T21:20:36Z

Jonnosan:

{{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 runs in the drive itself, not on the computer the drive was attached to.

The most popular CBM drive was the 1541, which supported 35 tracks using GCR encoding.

==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.

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.

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 (for a 35 track image)

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

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.

1 2 3 4 5 6
---- ----- ----- ----- ----- -----
17/0 17/10 17/20 17/1 17/11 0/52
(11/00) (11/0A) (11/14) (11/01) (11/0B) (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.

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.

Disk format |Tracks|Header 7/8|Dos type|DiskDos
| |allsechdrs| |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.

Code Error Type 1541 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.
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.
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 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.

Code Error Type 1541 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.

Code Error Type 1541 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.

Code Error Type 1541 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).

[[Category:Commodore computers]]

Filesystem

2013-05-20T21:20:07Z

Jonnosan: add GEOS VLIR

{{FormatInfo
|formattype=electronic
|thiscat=Filesystem
|image=Office Supplies File Cabinet 02.png
}}

Filesystems are [[Electronic_File_Formats|Electronic Formats]] that are a prerequisite to being able to read any file off a digital medium — you have to be able to mount the filesystem, and thus read it, in order to be able to read a file.

* [[Acer Fast Filesystem]] (SCO OpenServer)
* [[ADFS]] (Acorn MOS, RISC OS)
* [[AdvFS]](Advanced File System, Digital/Tru64 Unix)
* [[Ami File Safe]] (Amiga)
* [[Andrew File System]] (Carnegie Mellon University)
* [[APF Imagination Machine disk file system]]
* [[Apple DOS file system]] (Apple II; see also ProDOS below)
* [[Atari File Management Subsystem]] (FMS: Atari 400/800)
* [[AthFS]] (AtheOS/Syllable)
* [[BFS]] (BeOS)
* [[btrfs]] (Linux)
* [[CBMFS]] (Commodore 64)
** [[GEOS VLIR]] (GEOS Variable Length Index Record )
** [[CMDFS]] (CBMFS extension by Creative Micro Designs)
* [[Compucolor file system]]
* [[CP/M file system]]
* [[DDFS]] (Data Domain File System)
* [[DTFS]] (Desktop File System, [[SCO OpenServer]])
* [[EFS]] (Extent File System, SGI IRIX. Replaced by [[XFS]])
* [[EOS file system]] (Coleco Adam "data pack" tape drives and disks)
* [[exFAT]] (Microsoft, for flash memory)
* [[ext]] (developed for Linux, previously used MINIX fs)
* [[ext2]], [[ext3]], [[ext4]] (these are all just variants of each other)
* [[F2FS]], (Flash Friendly Filesystem)
* [[FAT8]]
* [[FAT12]]
* [[FAT16]]
* [[FAT32]]
* [[FFS]] (Amiga Fast File System)
* [[Files-11]] (VMS)
* [[Fossil]] (Plan 9)
* [[fuse-exFAT]] (open-source clone of exFAT)
* [[Google File System]]
* [[HAMMER]] (DragonflyBSD)
* [[HFS]]
* [[HFS+]]
* [[HPFS]] (OS/2 native file system)
* [[ISO 9660]]
* [[JFFS2]]
* [[LanyFS]] (Lanyard Filesystem)
* [[LogFS]]
* [[MDR (Floppy Disk)|MDR]] (audio instrument format close to MSDOS)
* [[MEGA file system]]
* [[MFS]] (ancient Macintosh filesystem)
* [[MINIX file system]]
* [[NILFS2]]
* [[NetWare File System]] (Novell NetWare, replaced by [[NSS]])
* [[NSS]] (Novell Storage Services)
* [[NTFS]]
* [[POHMELFS]] (distributed Linux filesystem)
* [[PRAMFS]] (Persistent & Protected RAM File-System)
* [[ProDOS file system]] (Apple)
* [[QFS]]
* [[ReFS]] (Microsoft's new FS- Resilient Filesystem, on Windows 8 Server)
* [[ReiserFS]]
** [[Reiser4]]
* [[SDFS]] (Deduplication based filesystem)
* [[SkyFS]] (SkyOS)
* [[SOS file system]] (Apple III)
* [[squashfs]]
* [[UCSD p-System Filesystem]] (UCSD Pascal)
* [[UDF]]
* [[UFS]] (Unix Files System, Solaris and BSD)
** [[UFS2]]
* [[VMUFAT]] (Filesystem for Dreamcast VMU units)
* [[VxFS]]
* [[WAFL]] (NetApp's commercial file system)
* [[Xiafs]] (Linux, dropped in favour of ext2)
* [[XFS]] (SGI)
* [[XtreemFS]], (Linux, distributed file system)
* [[YAFFS]]
* [[ZFS]]

== Format details ==
* [[desktop.ini]] (Windows)
* [[Desktop Services Store]] (Mac OS X)
* [[MBR]] (Master Boot Record)
* [[Resource Fork]] (MacOS)

CBMFS

2013-05-20T21:13:53Z

Jonnosan: add d64 heading

{{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 runs in the drive itself, not on the computer the drive was attached to.

The most popular CBM drive was the 1541, which supported 35 tracks using GCR encoding.

==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.

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.

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 (for a 35 track image)

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

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]] 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.

1 2 3 4 5 6
---- ----- ----- ----- ----- -----
17/0 17/10 17/20 17/1 17/11 0/52
(11/00) (11/0A) (11/14) (11/01) (11/0B) (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.

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.

Disk format |Tracks|Header 7/8|Dos type|DiskDos
| |allsechdrs| |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.

Code Error Type 1541 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.
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.
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 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.

Code Error Type 1541 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.

Code Error Type 1541 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.

Code Error Type 1541 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).

[[Category:Commodore computers]]

CBMFS

2013-05-20T21:12:10Z

Jonnosan: format corrections & attribution

{{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 runs in the drive itself, not on the computer the drive was attached to.

The most popular CBM drive was the 1541, which supported 35 tracks using GCR encoding. 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.

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.

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 (for a 35 track image)

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

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]] 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.

1 2 3 4 5 6
---- ----- ----- ----- ----- -----
17/0 17/10 17/20 17/1 17/11 0/52
(11/00) (11/0A) (11/14) (11/01) (11/0B) (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.

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.

Disk format |Tracks|Header 7/8|Dos type|DiskDos
| |allsechdrs| |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.

Code Error Type 1541 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.
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.
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 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.

Code Error Type 1541 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.

Code Error Type 1541 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.

Code Error Type 1541 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).

[[Category:Commodore computers]]

CBMFS

2013-05-20T20:53:47Z

Jonnosan: Created page with "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 pe..."

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 runs in the drive itself, not on the computer the drive was attached to.

The most popular CBM drive was the 1541, which supported 35 tracks using GCR encoding. 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.

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.

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 (for a 35 track image)

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

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 the [[GEOS]] 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.

1 2 3 4 5 6
---- ----- ----- ----- ----- -----
17/0 17/10 17/20 17/1 17/11 0/52
(11/00) (11/0A) (11/14) (11/01) (11/0B) (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.

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.

Disk format |Tracks|Header 7/8|Dos type|DiskDos
| |allsechdrs| |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.

Code Error Type 1541 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.

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.

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 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.

Code Error Type 1541 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.

Code Error Type 1541 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.

Code Error Type 1541 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.