--- trunk/doc/technical.html	2007/10/08 16:19:28	21
+++ trunk/doc/technical.html	2007/10/08 16:19:37	22
@@ -4,15 +4,15 @@
 <table border=0 width=100% bgcolor="#d0d0d0"><tr>
 <td width=100% align=center valign=center><table border=0 width=100%><tr>
 <td align="left" valign=center bgcolor="#d0efff"><font color="#6060e0" size="6">
-<b>Gavare's eXperimental Emulator:&nbsp;&nbsp;&nbsp;</b></font>
+<b>Gavare's eXperimental Emulator:</b></font><br>
 <font color="#000000" size="6"><b>Technical details</b>
 </font></td></tr></table></td></tr></table><p>
 
 <!--
 
-$Id: technical.html,v 1.67 2005/11/24 12:32:10 debug Exp $
+$Id: technical.html,v 1.72 2006/02/18 15:18:15 debug Exp $
 
-Copyright (C) 2004-2005  Anders Gavare.  All rights reserved.
+Copyright (C) 2004-2006  Anders Gavare.  All rights reserved.
 
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions are met:
@@ -108,12 +108,14 @@
 	line option.)
   <p>
   <li><b>All other modes:</b><br>
-	These use a kind of dynamic translation system. (This system does
-	not use host-specific backends, so it is not "recompilation" or
-	anything like that.) Speed is slower than real binary translation,
-	but faster than traditional interpretation, and with some tricks
-	it will hopefully still give reasonable speed. The ARM and PowerPC
-	emulation modes uses this kind of translation.
+	These use a kind of dynamic translation system. This system does
+	not recompile anything into native code, it only uses tables of
+	pointers to functions written in (sometimes machine-generated) C
+	code. Speed is lower than what can be achieved using real binary
+	translation into native code, but higher than when traditional
+	interpretation is used. With some tricks, it will hopefully still
+	give reasonable speed. The ARM and PowerPC
+	emulation modes use this kind of translation.
 </ul>
 
 
@@ -330,7 +332,7 @@
 
 Each file called <tt>dev_*.c</tt> in the <tt>src/device/</tt> directory is
 responsible for one hardware device. These are used from
-<tt>src/machine.c</tt>, when initializing which hardware a particular
+<tt>src/machines/machine_*.c</tt>, when initializing which hardware a particular
 machine model will be using, or when adding devices to a machine using the
 <tt>device()</tt> command in configuration files.
 
@@ -345,10 +347,7 @@
   <li>A <tt>devinit</tt> function in <tt>src/devices/dev_foo.c</tt>. It
 	would typically look something like this:
 <pre>
-	/*
-	 *  devinit_foo():
-	 */
-	int devinit_foo(struct devinit *devinit)
+	DEVINIT(foo)
 	{
 	        struct foo_data *d = malloc(sizeof(struct foo_data));
 
@@ -356,7 +355,7 @@
 	                fprintf(stderr, "out of memory\n");
 	                exit(1);
 	        }
-	        memset(d, 0, sizeof(struct foon_data));
+	        memset(d, 0, sizeof(struct foo_data));
 
 		/*
 		 *  Set up stuff here, for example fill d with useful
@@ -380,6 +379,11 @@
 	}       
 </pre><br>
 
+	<p><tt>DEVINIT(foo)</tt> is defined as <tt>int devinit_foo(struct devinit *devinit)</tt>,
+	and the <tt>devinit</tt> argument contains everything that the device driver's
+	initialization function needs.
+
+  <p>
   <li>At the top of <tt>dev_foo.c</tt>, the <tt>foo_data</tt> struct
 	should be defined.
 <pre>
@@ -423,11 +427,15 @@
   <p>
   <li>And last but not least, the device should have an access function.
 	The access function is called whenever there is a load or store
-	to an address which is in the device' memory mapped region.
-<pre>
-	int dev_foo_access(struct cpu *cpu, struct memory *mem,
+	to an address which is in the device' memory mapped region. To
+	simplify things a little, a macro <tt>DEVICE_ACCESS(x)</tt>
+	is expanded into<pre>
+	int dev_x_access(struct cpu *cpu, struct memory *mem,
 	    uint64_t relative_addr, unsigned char *data, size_t len,
 	    int writeflag, void *extra)
+</pre>	The access function can look like this:
+<pre>
+	DEVICE_ACCESS(foo)
 	{
 		struct foo_data *d = extra;
 		uint64_t idata = 0, odata = 0;