*** LBR (LiBRary containers, C64 version only)
*** Document revision: 1.3
*** Last updated: March 11, 2004
*** Contributors/samples: Joe Forster/STA
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 containers. 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 container 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 <CR>.
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 <CR> 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 <CR>. 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 container until the whole directory has been read. The
byte following the <CR> 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 <CR>) 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.
|