Add tonc-specific styling + general visual cleanup

content/affobj.md

@@ -683,6 +683,10 @@ For anchoring, you actually need one set of coordinates for each coordinate-spac
 <div class="lblock">
 
 <table border=0 cellpadding=1 cellspacing=0>
+<colgroup>
+    <col span="1" style="width: 14%;">
+    <col span="1" style="width: 86%;">
+</colgroup>
 <tbody valign="top">
 <tr align="left"> <th width=48>point</th>		<th>description</th> </tr>
 <tr>

content/dma.md

@@ -37,7 +37,7 @@ Every kind of transfer routine needs 3 things: a source, a destination and the a
 The use of the source and destination registers should be obvious. The control register needs some explaining. Although the `REG_DMAxCNT` registers themselves are 32bits, they are often split into two separate registers: one for the count, and one for the actual control bits.
 
 <div class="reg">
-<table class="reg" id="tbl:reg-dmaxcnt"
+<table class="reg reg-huge" id="tbl:reg-dmaxcnt"
   border=1 frame=void cellPadding=4 cellSpacing=0>
 <caption class="reg">
   REG_DMAxCNT @ <code>0400:00B8</code>+12<i>x</i>

content/gfx.md

@@ -241,7 +241,7 @@ Note that in these examples the sum of the weights is 1, so that the final color
 Backgrounds are always enabled for blending. To enable sprite-blending, set `OBJ_ATTR.attr0`\{a\}. There are three registers that control blending, which unfortunately go by many different names. The ones I use are `REG_BLDCNT`, `REG_BLDALPHA` and `REG_BLDY`. Other names are `REG_BLDMOD`, `REG_COLEV` and `REG_COLEY`, and sometimes the ‘E’ in the last two is removed. Be warned. Anyway, the first says how and on which layers the blend should be performed, the last two contain the weights. Oh, since the GBA doesn't do floating point, the weights are [fixed-point](fixed.html) numbers in 1.4 format. Still limited by 0 and 1, of course, so there are 17 blend levels.
 
 <div class="reg">
-  <table class="reg" id="tbl:reg-bldcnt" border=1 frame=void cellpadding=4 cellspacing=0>
+  <table class="reg reg-huge" id="tbl:reg-bldcnt" border=1 frame=void cellpadding=4 cellspacing=0>
     <caption class="reg">REG_BLDCNT (REG_BLDMOD) @ <code>0400:0050h</code></caption>
     <tr class="bits">
       <td>F E</td>
@@ -336,7 +336,6 @@ The `REG_BLDALPHA` and `REG_BLDY` registers hold the blending weights in the for
       <td class="rclr0">eva</td>
     </tr>
   </table>
-  <br>
   <table>
     <col class="bits" width=40>
     <col class="bf" width="8%">
@@ -376,7 +375,6 @@ The `REG_BLDALPHA` and `REG_BLDY` registers hold the blending weights in the for
       <td class="rclr2">ey</td>
     </tr>
   </table>
-  <br>
   <table>
     <col class="bits" width=40>
     <col class="bf" width="8%">
@@ -672,7 +670,7 @@ So you have one byte for each value. That's bytes as in *unsigned* chars. The co
 The possible content for the windows are backgrounds 0-3 and objects. No suprise there, right? In total, we have regions: win0, win1, winOut and winObj. `REG_WININ` (`0400:0048h`) controls win0 and win1, `REG_WINOUT` (`0400:004ah`) takes care of winOut and winObj. There's one bit for each content-type, plus one for blending, which you will need if you intend to use blending on the contents of that particular window.
 
 <div class="reg">
-  <table class="reg" id="tbl:reg-winio" border=1 frame=void cellpadding=4 cellspacing=0>
+  <table class="reg reg-huge" id="tbl:reg-winio" border=1 frame=void cellpadding=4 cellspacing=0>
     <tr class="bits">
       <th>register</th>
       <td>F E</td>

content/interrupts.md

@@ -361,7 +361,7 @@ Note: I said register**s**, plural! Each CPU mode has its own stack and link reg
 <br>  
 So, assembly it is then. The function below is the assembly equivalent of `irs_master_c()`. It is almost a line by line translation, although I am making use of a few features of the instruction set the compiler wont't or can't. I don't expect you to really understand everything written here, but with some imagination you should be able to follow most of it. Teaching assembly is *way* beyond the scope of this chapter, but worth the effort in my view. Tonc's [assembly chapter](asm.html) should give you the necessary information to understand most of it and shows where to go to learn more.
 
-```asm
+```armasm
     .file   "tonc_isr_master.s"
     .extern __isr_table;
 

content/regbg.md

@@ -66,11 +66,11 @@ Both the tiles and tilemaps are stored in VRAM, which is divided into <dfn>charb
   <b>{*@tbl:cbb-sbb}</b>:
   charblock and screenblock overlap.
 </caption>
-<colgroup span=1 style="background-color:#D0D0D0;"></colgroup>
-<colgroup span=3 style="background-color:#B0B0B0;"></colgroup>
-<colgroup span=3 style="background-color:#D0D0D0;"></colgroup>
-<colgroup span=3 style="background-color:#B0B0B0;"></colgroup>
-<colgroup span=3 style="background-color:#D0D0D0;"></colgroup>
+<colgroup span=1 style="background-color:none;"></colgroup>
+<colgroup span=3 style="background-color:var(--table-alternate-bg);"></colgroup>
+<colgroup span=3 style="background-color:none;"></colgroup>
+<colgroup span=3 style="background-color:var(--table-alternate-bg);"></colgroup>
+<colgroup span=3 style="background-color:none;"></colgroup>
 
 <tbody align="left"><tr>
   <th>Memory
@@ -234,10 +234,8 @@ The description of `REG_BGxCNT` can be found below. Most of it is pretty standar
 </table>
 </div>
 
-<div class="cblock">
-<table width="100%" id="tbl:bg-size">
-<tr align="center">
-<td>
+<div class="cblock" id="tbl:bg-size">
+<div style="display: inline-block">
   <table id="tbl-reg-size" border=1 cellpadding=2  cellspacing=0>
   <caption align="bottom">
     <b>{*@tbl:bg-size}a</b>: regular bg sizes
@@ -251,7 +249,8 @@ The description of `REG_BGxCNT` can be found below. Most of it is pretty standar
     <tr><td> 11   <td><code>BG_REG_64x64</code> <td> 64×64 <td> 512×512 
   </tbody>
   </table>
-<td>
+</div>
+<div style="display: inline-block">
   <table id="tbl-aff-size" border=1 cellpadding=2 cellspacing=0>
   <caption align="bottom">
     <b>{*@tbl:bg-size}b</b>: affine bg sizes
@@ -265,8 +264,8 @@ The description of `REG_BGxCNT` can be found below. Most of it is pretty standar
     <tr><td> 11   <td><code>BG_AFF_128x128</code><td>128×128 <td>1024×1024
   </tbody>
   </table>
-</table>
-</div><br>
+</div>
+</div>
 
 Each background has two 16-bit scrolling registers to offset the rendering (`REG_BGxHOFS` and `REG_BGxVOFS`). There are a number of interesting points about these. First, because regular backgrounds wrap around, the values are essentially modulo *mapsize*. This is not really relevant at the moment, but you can use this to your benefit once you get to more advanced tilemaps. Second, these registers are **write-only**! This is a little annoying, as it means that you can't update the position by simply doing `REG_BG0HOFS++` and the like.
 
@@ -745,6 +744,7 @@ The second demo, *sbb_reg*, uses a 64×64t background to indicate how multiple s
 
 
 <div id="cd-demo-sbb">
+
 ```c
 #include "toolbox.h"
 #include "input.h"
@@ -1048,7 +1048,7 @@ I intend to use tonclib in a number of later demos. In particular, the memory ma
 <div class="note">
 <div class="nhgood">
 
-Better copy and fill routines: `memcpy16`/`32` and `memset16`/`32`
+Better copy and fill routines: memcpy16/32 and memset16/32
 
 </div>
 

content/regobj.md

@@ -194,9 +194,11 @@ There are a few interesting things about these structures. First, you see a lot
 </div>
 
 <div class="note">
+
 <div class="nhgood">
 Force alignment on OBJ_ATTRs
 </div>
+
 As of devkitARM r19, there are new rules on struct alignments, which means that structs may not always be word aligned, and in the case of `OBJ_ATTR` structs (and others), means that `struct` copies like the one in `oam_update()` later on, will not only be slow, they may actually break. For that reason, I will force word-alignment on many of my structs with `ALIGN4`, which is a macro for `__attribute__((aligned(4)))`. For more on this, see the section on [data alignment](bitmaps.html#ssec-data-align).
 </div>
 
@@ -358,10 +360,10 @@ I'll say it here too: `attr0` contains *y*, `attr1` contains *x*. Note that bits
 This attribute tells the GBA which tiles to display and its background priority. If it's a 4bpp sprite, this is also the place to say what sub-palette should be used.
 
 <div class="reg">
-<table class="reg" id="tbl:oe-attr2"
+<table class="reg" id="tbl-oe-attr2"
   border=1 frame=void cellpadding=4 cellspacing=0>
 <caption class="reg">
-  {*@tbl:oe-attr2}: <code>OBJ_ATTR.attr2</code>
+  <code>OBJ_ATTR.attr2</code>
 </caption>
 <tr class="bits">
 	<td>F E D C<td>B A<td>9 8 7 6 5 4 3 2 1 0
@@ -379,19 +381,19 @@ This attribute tells the GBA which tiles to display and its background priority.
 <tbody valign="top">
 <tr class="bg0">	
   <td>0-9<td class="rclr0">TID
-  <td><code>ATTR2_ID#</code>
+  <td>ATTR2_ID#
   <td>Base <b>tile index</b> of sprite. Note that in bitmap modes,
     this must be 512 or higher.
 <tr class="bg1">	
   <td>A-B<td class="rclr2">Pr
-  <td><code>ATTR2_PRIO#</code>
+  <td>ATTR2_PRIO#
   <td><b>Priority</b>. Higher priorities are drawn first (and therefore 
     can be covered by later sprites and backgrounds). Sprites cover 
     backgrounds of the same priority, and for sprites of the 
     same priority, the higher <code>OBJ_ATTR</code>s are drawn first.
 <tr class="bg0">	
   <td>C-F<td class="rclr1">PB
-  <td><code>ATTR2_PALBANK#</code>
+  <td>ATTR2_PALBANK#
   <td><b>Palette bank</b> to use when in 16-color mode. Has no effect if
 	the color mode flag (<code>attr0</code>{C}) is set.
 </tbody>
@@ -497,7 +499,7 @@ Finally, what I call my build macros. These piece together the various bit-flags
 #define ATTR1_BUILD_A(x, size, aff_id)               \
 ( ((x)&511) | (((aff_id)&31)<<9) | (((size)&3)<<14) )
 
-Attribute 2
+// Attribute 2
 #define ATTR2_BUILD(id, pbank, prio)                 \
 ( ((id)&0x3FF) | (((pbank)&15)<<12) | (((prio)&3)<<10) )
 ```

content/sndsqr.md

@@ -895,7 +895,7 @@ R(f) = 2048 - \frac{2^{17}}{f}
 Both square-wave generators have registers `REG_SNDxCNT` for envelope/length/duty control and `REG_SNDxFREQ` for frequency control. Sound 1 also has sweep control in the form of `REG_SND1SWEEP`. Look in {@tbl:snd-names} for the traditional names; note that in traditional nomenclature the suffixes for control and frequency are *different* for channels 1 and 2, even though they have exactly the same function.
 
 <div class="reg">
-<table class="reg" id="tbl-reg-snd1cnt"
+<table class="reg" id="tbl-reg-snd1cnt" width=420
   border=1 frame=void cellpadding=4 cellspacing=0>
 <caption class="reg">
 <span class="nobr">
@@ -1014,7 +1014,7 @@ A_m = \frac{2}{\pi} \cdot \frac{sin({\pi}Dm)}{m}
 Some more on the duty cycle. Remember we've done a Fourier analysis of the square wave so we could determine the frequencies in it. Apart from the **base frequency**, there are also **overtones** of frequencies *m·f*. The spectrum (see {@fig:sqrf}) gives the amplitudes of all these frequencies. Note that even though the figure has lines, only integral values of *m* are allowed. The base frequency at *m*=1 has the highest significance and the rest falls off with 1/*m*. The interesting part is when the sine comes into play: whenever *m·D* is an integer, that component vanishes! With a fractional duty number –like the ones we have– this happens every time *m* is equal to the denominator. For the 50% duty, every second overtone disappears, leaving a fairly smooth tone; for 12.5%, only every eighth vanishes and the result is indeed a noisier sound. Note that for *both* ¼ and ¾ duties every fourth vanishes so that they should be indistinguishable. I was a little surprised about this result, but sure enough, when I checked they really did sound the same to me.
 
 <div class="reg">
-<table class="reg" id="tbl-reg-snd1freq"
+<table class="reg" id="tbl-reg-snd1freq" width=420
   border=1 frame=void cellpadding=4 cellspacing=0>
 <caption class="reg">
 <span class="nobr">
@@ -1068,7 +1068,7 @@ Some more on the duty cycle. Remember we've done a Fourier analysis of the squar
 </div><br>
 
 <div class="reg">
-<table class="reg" id="tbl-reg-snd1sweep"
+<table class="reg" id="tbl-reg-snd1sweep" width=420
   border=1 frame=void cellpadding=4 cellspacing=0>
 <caption class="reg">
   REG_SND1SWEEP (SOUND1CNT_L / SG10_L) @ <code>0400:0060h</code>

content/swi.md

@@ -189,7 +189,6 @@ The source address points to an array of `AFF_SRC` structs (also known as `ObjAf
   </mstyle>
 </math>
 
-<br>  
 By now you should know what this does: it scales horizontally by 1/*s*<sub>x</sub>, vertically by 1/*s*<sub>y</sub> followed by a counter-clockwise rotation by *α*. `ObjAffineSet()` does almost exactly what `obj_aff_rotscale()` and `bg_aff_rotscale()` do, except that `ObjAffineSet()` can also set multiple matrices at once.
 
 The source data is kept in `ObjAffineSource` (i.e., `AFF_SRC`) structs. Now, as the routine sets affine matrices, you might think that the destinations are either `OBJ_AFFINE` or `ObjAffineDest` structs. However, you'd be wrong. Well, partially anyway. The problem is that the destination always points to a *p*<sub>a</sub>-element, which is not necessarily the first element in struct. You *will* make the mistake of simply supplying an `OBJ_AFFINE` pointer when you try to use it to fill those. Don't say I didn't warn you.
@@ -228,7 +227,7 @@ typedef struct OBJ_AFFINE
 
 You might think this whole discussion was rather pointless since you can't access the registers and the `swi` instruction unless you use assembly, which will be pretty tough, right? Well, no, yes and no. The necessary assembly steps for BIOS calls are actually rather simple, and are given below.
 
-```asm
+```armasm
 @ In tonc_bios.s
 
 @ at top of your file