Mercurial > hg-old > index.cgi
diff doc/main.docbook @ 107:69ead2e61763
Added start of a manual and updated maintainer docs to mention generated documentation
author | lost |
---|---|
date | Wed, 28 Jan 2009 05:02:44 +0000 |
parents | |
children |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/main.docbook Wed Jan 28 05:02:44 2009 +0000 @@ -0,0 +1,97 @@ +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.5//EN"> +<book> +<bookinfo> +<title>LW Tool Chain</title> +<author><firstname>William</firstname><surname>Astle</surname></author> +<copyright><year>2009</year><holder>William Astle</holder></copyright> +</bookinfo> +<chapter> + +<title>Introduction</title> + +<para> +The LW tool chain provides utilities for building binaries for MC6809 and +HD6309 CPUs. The tool chain includes a cross-assembler and a cross-linker +which support several styles of output. +</para> + +<section> +<title>History</title> +<para> +For a long time, I have had an interest in creating an operating system for +the Coco3. I finally started working on that project around the beginning of +2006. I had a number of assemblers I could choose from. Eventually, I settled +on one and started tinkering. After a while, I realized that assembler was not +going to be sufficient due to lack of macros and issues with forward references. +Then I tried another which handled forward references correctly but still did +not support macros. I looked around at other assemblers and they all lacked +one feature or another that I really wanted for creating my operating system. +</para> + +<para> +The solution seemed clear at that point. I am a fair programmer so I figured +I could write an assembler that would do everything I wanted an assembler to +do. Thus the LWASM probject was born. After more than two years of on and off +work, version 1.0 of LWASM was released in October of 2008. +</para> + +<para> +As the aforementioned operating system project progressed further, it became +clear that while assembling the whole project through a single file was doable, +it was not practical. When I found myself playing some fancy games with macros +in a bid to simulate sections, I realized I needed a means of assembling +source files separately and linking them later. This spawned a major development +effort to add an object file support to LWASM. It also spawned the LWLINK +project to provide a means to actually link the files. +</para> + +</section> + +</chapter> + +<chapter> +<title>Output Formats</title> + +<para> +The LW tool chain supports multiple output formats. Each format has its +advantages and disadvantages. Each format is described below. +</para> + +<section> +<title>Raw Binaries</title> +<para> +A raw binary is simply a string of bytes. There are no headers or other +niceties. Both lwlink and lwasm support generating raw binaries. ORG directives +in the source code only serve to set the addresses that will be used for +symbols but otherwise have no direct impact on the resulting binary. +</para> + +</section> +<section> +<title>DECB Binaries</title> + +<para>A DECB binary is compatible with the LOADM command in Disk Extended +Color Basic on the CoCo. They are also compatible with CLOADM from Extended +Color Basic. These binaries include the load address of the binary as well +as encoding an execution address. These binaries may contain multiple loadable +sections, each of which has its own load address.</para> + +<para> +Each binary starts with a preamble. Each preamble is five bytes long. The +first byte is zero. The next two bytes specify the number of bytes to load +and the last two bytes specify the address to load the bytes at. Then, a +string of bytes follows. After this string of bytes, there may be another +preamble or a postamble. A postamble is also five bytes in length. The first +byte of the postamble is $FF, the next two are zero, and the last two are +the execution address for the binary. +</para> + +<para> +Both lwasm and lwlink can output this format. +</para> +</section> + + +</chapter> +</book> +