formats index
	*** LBR (LiBRary, C64 version only)

** Document revision 1.1

  There are two different types of LBR files, one for the C64 and one  more
commonly used by CP/M (in this case on the  C128).  This  explanation  only
deals with the C64 type.

  This is a native C64 format, slightly similar in  structure  to  ARK/LNX.
There exists a program on the C64 called  "Library  10.0"  which  seems  to
maintain these archives. From the information  in  the  program  (which  is
written in BASIC with a small ML subroutine), it appears  the  program  was
really meant for up/downloading files from BBS's.  From  looking  over  the
text in Library V7.0, the author appears to be Mike Swanson,  or  at  least
the author of that version.

  The archive starts out with a 3 byte signature ("DWB"), the file size and
file types are stored in ASCII with a single space padding their start/end,
and all strings and numbers are terminated with a .

      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F        ASCII
      -----------------------------------------------   ----------------
0000: 44 57 42 20 39 20 0D 53 55 50 45 52 20 44 4F 53   DWB˙9˙˙SUPER˙DOS
0010: 0D 50 0D 20 31 35 30 37 20 0D 44 4D 43 20 31 2E   ˙P˙˙1507˙˙DMC˙1.
0020: 32 2F 47 52 41 46 46 49 54 59 0D 50 0D 20 32 30   2/GRAFFITY˙P˙˙20
0030: 32 34 31 20 0D 42 2E 44 45 4C 54 41 20 5A 41 4B   241˙˙B.DELTA˙ZAK
0040: 20 2E 44 4D 43 0D 50 0D 20 32 37 30 32 20 0D 42   ˙.DMC˙P˙˙2702˙˙B
0050: 2E 52 4F 43 4B 20 5A 41 4B 31 20 2E 44 4D 43 0D   .ROCK˙ZAK1˙.DMC˙
0060: 50 0D 20 32 38 38 36 20 0D 49 4E 46 4F 52 4D 41   P˙˙2886˙˙INFORMA
0070: 54 49 4F 4E 2E 2E 2E 0D 50 0D 20 38 38 34 38 20   TION...˙P˙˙8848˙
0080: 0D 42 2E 4B 49 44 44 49 4E 47 20 20 20 2E 44 4D   ˙B.KIDDING˙˙˙.DM
0090: 43 0D 50 0D 20 32 38 39 31 20 0D 42 2E 47 41 4C   C˙P˙˙2891˙˙B.GAL
00A0: 57 41 59 20 5A 41 4B 2E 44 4D 43 0D 50 0D 20 32   WAY˙ZAK.DMC˙P˙˙2
00B0: 38 36 30 20 0D 42 2E 41 20 4D 55 53 49 43 20 20   860˙˙B.A˙MUSIC˙˙
00C0: 20 2E 44 4D 43 0D 50 0D 20 33 31 33 37 20 0D 47   ˙.DMC˙P˙˙3137˙˙G
00D0: 2E 50 41 43 4D 41 4E 49 41 20 20 2E 44 4D 43 0D   .PACMANIA˙˙.DMC˙
00E0: 50 0D 20 33 32 36 32 20 0D 01 08 0B 08 00 00 9E   P˙˙3262˙˙˙˙˙˙˙˙×

  The first 3 bytes are the signature to the file, "DWB", perhaps the  true
authors initials...

0000: 44 57 42 .. .. .. .. .. .. .. .. .. .. .. .. ..   DWB.............

  Following this is the number of entries in the directory (9). See how  it
has a space preceeding it, trailing it, and  a    at  the  end  of  the
string.

0000: .. .. .. 20 39 20 0D .. .. .. .. .. .. .. .. ..   ...˙9˙..........

  Following this we have the first directory  entry.  The  file  is  "Super
DOS", it is a program file ("P"), and it is 1507 bytes long. The  filenames
are not stored with any shift-space padding (like most other  formats),  so
the directory entries vary widely in size. The filename does get terminated
with a . From my experiments with the Library program,  it  does  *not*
support REL files.

0000: .. .. .. .. .. .. .. 53 55 50 45 52 20 44 4F 53   .......SUPER˙DOS
0010: 0D 50 0D 20 31 35 30 37 20 0D .. .. .. .. .. ..   .P.˙1507˙.......

  Following this are the remaining directory entries.

0010: .. .. .. .. .. .. .. .. .. .. 44 4D 43 20 31 2E   ..........DMC˙1.
0020: 32 2F 47 52 41 46 46 49 54 59 0D 50 0D 20 32 30   2/GRAFFITY.P.˙20
0030: 32 34 31 20 0D .. .. .. .. .. .. .. .. .. .. ..   241˙............
 ...
00C0: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 47   ...............G
00D0: 2E 50 41 43 4D 41 4E 49 41 20 20 2E 44 4D 43 0D   .PACMANIA˙˙.DMC.
00E0: 50 0D 20 33 32 36 32 20 0D .. .. .. .. .. .. ..   P.˙3262˙.......

  If it is not obvious yet, there is no way to know where the first  file's
data starts in the archive until the whole directory  has  been  read.  The
byte following the  of the last entry it is the first byte of the first
entry.

00E0: .. .. .. .. .. .. .. .. .. 01 08 0B 08 00 00 9E   .............˙˙×

  From the starting location of the file file's data, you can now calculate
where all the other entries start by using the file size, contained in each
directory entry. In this case, the first file starts at $00E9 (offset 233).
The second will then start at $06CC (1740).

06C0: .. .. .. .. .. .. .. .. .. .. .. .. 01 08 0B 08  .................

  64COPY supports this format on a read-only basis, allowing you to convert
the files contained to another format.

---------------------------------------------------------------------------

What it takes to support LBR:

  Except for a simple layout, and a 3-byte signature to identify the  file,
a few obvious deficiencies exist in the LBR layout which can  make  support
difficult.

  Reading LBR files, in order to copy files out, is relatively  easy.  Once
the directory is read we know all the file sizes, and we  also  know  where
the first file starts. It is a simple matter to figure out where each  file
actually starts in the LBR from this information.

  Writing LBR is more difficult as it would appear that you must  know  the
size of each file *before* you create the LBR header. It would also  appear
that the whole directory must be created before *any* file copying can take
place. When copying files from a D64 to an LBR, you don't know the  *exact*
file size as they are stored in sectors. You would need to scan the  source
file, tracing the sectors until the last one to determine its size.

  Unlike LNX/ARK, the size of the directory is not made to  fit  blocks  of
254 bytes (for easy 1541 usage), and the files are not aligned to 254  byte
boundaries. This makes deleting files more difficult  as  no  matter  which
file gets deleted, the whole file will have to be re-written.

  The lack of a consistent directory entry size (like D64's 32 bytes)  also
makes working with LBR inconvenient. Many of the file formats for  the  C64
and the emulators suffer from this lack of a  well-defined  layout.  It  is
understandable, however, why  formats  like  LBR  (and  LNX)  create  their
entries in ASCII rather than binary as it's easier to use BASIC and  output
a number in ASCII (delimited with a ) than to calculate and output  the
value in binary format.

  The last negative for LBR is it doesn't support REL or  GEOS  files,  but
thats not so important.