no way to compare when less than two revisions

Differences

This shows you the differences between two versions of the page.

@@ Line 1: / Line 1: @@
+====== C=Hacking #20 ======
+<code>
+                   ########
+             ##################
+         ######            ######
+      #####
+    #####  ####  ####      ##      #####   ####  ####  ####  ####  ####   #####
+  #####    ##    ##      ####    ##   ##   ##  ###     ##    ####  ##   ##   ##
+ #####    ########     ##  ##   ##        #####       ##    ## ## ##   ##
+#####    ##    ##    ########  ##   ##   ##  ###     ##    ##  ####   ##   ##
+#####  ####  ####  ####  ####  #####   ####  ####  ####  ####  ####   ######
+#####                                                                    ##
+ ######            ######           Issue #20
+   ##################             April 18, 2001
+       ########
+...............................................................................
+	Ineptitude: If you can't learn to do something well, learn to enjoy
+		    doing it poorly.
+					-- "Demotivator" poster
+...............................................................................
+BSOUT
+Hoo-ah!  Time for another late (but hopefully great) issue of C=Hacking!
+This issue features several nifty articles on both software and hardware
+projects.  There seems to be a lot of activity in the hardware area right
+now, so hopefully we'll see more hardware articles in future issues.
+In the software area, however...
+If I may pithily berate for a moment, I'd like to observe that talking about
+programming on comp.sys.cbm is -- this may come as a surprise to some -- not
+the same as actually programming.  I'd like to once again encourage those who
+have been talking about projects, or have half-completed projects sitting
+around on an FD disk somewhere, to go for it and get the job done!
+Just like... um... C=Hacking (hey, it gets done... eventually...).
+The format for this issue has changed a little, with all the news and stuff
+moved into the previously skimpy "Jiffies" section.  Therefore, this is now
+just the 'me' column.
+So 'me' would like to thank all the authors in this issue for their time
+and effort (and patience), and all of the true C= Hackers out there for their
+spirit and work and cool projects.
+'Me' is also very happy to announce that he is getting married on August 17.
+And heck, you're ALL INVITED (I think an SX-64 would make an excellent
+wedding present, don't you?).
+And finally, me still thinks the 64 is the niftiest computer ever made.
+Onwards!
+-Steve
+.......
+....
+..
+.                                    C=H #20
+</code>
+===== Contents =====
+<code>
+BSOUT
+	o Voluminous ruminations from your unfettered editor.
+Jiffies
+	o News, things, and stuff.
+Side Hacking
+	o "Super/Turbo CPU VDC Hack", by Henry Sopko <henry.sopko@hwcn.org>
+	  Normally it is not possible to access the VDC chip when using
+	  a SuperCPU64 or Turbo CPU on a 128.  The 1-wire hack described
+	  in this article fixes that situation!
+	o "16K Memory Expansion for the VIC-20", by Per Olofsson
+	  <MagerValp@cling.gu.se>.  This article describes a nifty way to
+	  add more memory to the VIC-20, along with some basic circuit
+	  design information for the hardware neophyte (i.e. people like me!).
+	o "Quick Quadratic Splines", by moi <sjudd@ffd2.com>
+	  A spline is a powerful tool for drawing a curve through an arbitrary
+	  set of points -- for motion/animation, for arbitrary curves (like
+	  fonts), and numerous other tasks.  This article describes _quadratic_
+	  splines and some fast C64 implementations, and includes a program
+	  for experimenting with splines.
+Main Articles
+	o "VIC-20 Kernal ROM Disassembly Project", by Richard Cini
+	  <rcini@email.msn.com>
+	  The ever-dependable Richard Cini has written the fourth article
+	  in the quest for a complete disassembly of the VIC-20 kernal.  This
+	  installment focuses on device I/O routines: SETNAM, SETLF, OPEN,
+	  and beyond.
+	o "MODs and Digital Mixing", by Jolse Maginnis
+				       <jmaginni@postoffice.utas.edu.au>.
+	  Josmod is a program for JOS, by Jolse, that can play Amiga MOD files
+	  (and their newer successors).  This article describes the general
+	  functioning of the program, the layout of a MOD file, and how to mix
+	  multiple digital samples in real-time (and hence play MODs!).
+	o "The C64 Digi", by Robin Harbron <macbeth@psw.ca>, Levente
+	  Harsfalvi <levente@terrasoft.hu>, and Stephen Judd <sjudd@ffd2.com>
+	  This article is, we hope, a complete reference on digital sampling
+	  and the C64, including: general theory, SID hardware description,
+	  and methods of playback (changing $d418, pulse width modulation,
+	  and various tricks).  Numerous code examples are given, along with
+	  a program that does true 8-bit playback at 16KHz -- it requires a
+	  SuperCPU, but it is most impressive, and chances are awfully good
+	  that you've never heard a digi like this out of SID before.
+</code>
+===== Credits =====
+<code>
+Editor, The Big Kahuna, The Car'a'carn..... Stephen L. Judd
+C=Hacking logo by.......................... Mark Lawrence
+Special thanks to the folks who have helped out with reviewing and such,
+to the article authors for being patient, and to all the cbm hackers that
+make this possible!
+Legal disclaimer:
+) If you screw it up it's your own fault!
+) If you use someone's stuff without permission you're a dork!
+About the authors:
+Jolse Maginnis is a 20 year old programmer and web page designer,
+currently taking a break from CS studies.  He first came into contact
+with the C64 at just five or six years of age, when his parents brought
+home their "work" computer.  He started out playing games, then moved on
+to BASIC, and then on to ML.  He always wanted to be a demo coder, and in
+met up with a coder at a user's group meeting, and has since worked
+on a variety of projects from NTSC fixing to writing demo pages and intros
+and even a music collection.  JOS is taking up all his C64 time and he
+is otherwise playing/watching sports, out with his girlfriend, or at a
+movie or concert somewhere.  He'd just like to say that "everyone MUST
+buy a SuperCPU, it's the way of the future" and that if he can afford
+one, anyone can!
+Richard Cini is a 31 year old vice president of Congress Financial
+Corporation, and first became involved with Commodore 8-bits in 1981, when
+his parents bought him a VIC-20 as a birthday present.  Mostly he used it
+for general BASIC programming, with some ML later on, for projects such as
+controlling the lawn sprinkler system, and for a text-to-speech synthesyzer.
+All his CBM stuff is packed up right now, along with his other "classic"
+computers, including a PDP11/34 and a KIM-1.  In addition to collecting
+old computers Richard enjoys gardening, golf, and recently has gotten
+interested in robotics.  As to the C= community, he feels that it
+is unique in being fiercely loyal without being evangelical, unlike
+some other communities, while being extremely creative in making the
+best use out of the 64.
+Robin Harbron is a 28 year old internet tech support at a local
+independent phone company.  He first got involved with C= 8-bits
+in 1980, playing with school PETs, and in 1983 his parents convinced
+him to spend the extra money on a C64 instead of getting a VIC-20.
+Like most of us he played a lot of games, typed in games out of
+magazines, and tried to write his own games.  Now he writes demos,
+dabbles with Internet stuff, writes C= magazine articles, and, yes,
+plays games.  He is currently working on a few demos and a few games,
+as well as the "in-progress-but-sometimes-stalled-for-a-real-long-time-
+until-inspiration-hits-again Internet stuff".  He is also working on
+raising a family, and enjoys music (particularly playing bass and guitar),
+church, ice hockey and cricket, and classic video games.
+Levente Harsfalvi is a 26 year old microcontroller programmer who works at
+a small local company.  His first C= encounter was a Plus/4 at school, at
+the age of 12, and later (1988) his parents bought a C-16.  After learning
+BASIC and ASM coding he joined a Plus/4 demo group (GOTU, and later Coroners),
+and has worked on game conversions, an FLI editor, music software (including
+a SID emulator to play c64 music on TED) and numerous other software and
+hardware projects.  More recently he has begun taking some measurements on
+the Plus/4 to figure out things such as how the sound generator works and is
+working on a C-16 demo.  Outside of the C= he enjoys cycling and running,
+and ~50km walking tours.
+For information on the mailing list, ftp and web sites, send some email
+to chacking-info@jbrain.com.
+While http://www.ffd2.com/fridge/chacking is the main C=Hacking homepage,
+C=Hacking is available many other places including
+	http://www.funet.fi/pub/cbm/magazines/c=hacking/
+	http://metalab.unc.edu/pub/micro/commodore/magazines/c=hacking/
+</code>
+===== Jiffies =====
+<code>
+$01 Not _too_ long ago, an effort was made to write down the pin assignments
+    for the video port of all the major C= computers.  The result, as compiled
+    by William Levak <wlevak@cyberspace.org>, is:
+              7
+Commodore          6           Video Connector
+              1
+         4
+                                                    Plus4     C16/C128
+     CBM-II      VIC20     VIC20CR    C64     Pin C64A/SX64   C64B/C/E
+    --------- ------------ ------- ---------- --- ---------- ----------
+(R) Luminance +5 V         +5 V    Monochrome  1  Monochrome Monochrome (Y)
+    Ground    Ground       Ground  Ground      2  Ground     Ground
+(B) V. Sync.  Audio        Audio   Audio       3  Audio      Audio      (W)
+(W) Video     50 Ohm Video Video   Video       4  Video      Video
+(Y) H. Sync.  Video        Video   Audio In    5  Audio In   Audio In
+  Chroma     Chroma     (R)
+             +5 V
+$02 "Professor Dredd" <profdredd@yahoo.com> has uploaded the programs
+    from "Inside Commodore DOS" to his webpage at
+	http://www.geocities.com/profdredd
+$03 Todd Elliot has written a version of Pasi Ojala's zip/unzip program
+    for GEOS/Wheels, available at:
+	http://www.cs.tut.fi/~albert/Dev/gunzip-geos/
+$04 Jeri has been hard at work on her video/cpu-board:
+	http://www.geocities.com/cm_easy/
+$05 Jolse has been hard at work on JOS (but you'll have to wait until next
+    issue for the article!):
+    Here's the latest Jos news:
+    Support for CMD HD, including native partitions. (Read only atm, and no
+partitions)
+    Enhanced shell with filename completion and recursive wildcards.
+    Improvements to the GUI - the architecture now allows for a different
+    window interface styles transparent to the application.
+    Numerous showstopper bugs killed.
+    Improvements to the httpd server to allow directory listings.
+    Swiftlink/T232/Duart drivers.
+    Started writing tutorials for programmers wanting to give Jos a go.
+    Plus heaps more things not worth mentioning..
+    cya!,
+    Jolse
+$06 Philip 'Pepto' Timmermann has made some very accurate measurements
+    (and RGB calculations) of VIC-II colors:
+	http://www.pepto.de/projects/colorvic/
+$07 And finally, I have written a 2D graphics library for use by assembly
+    language programs (plot points, draw lines and circles, that kind of
+    thing).  It's super-easy to use and pretty fast, so go ahead and use it
+    if you need some hires drawing routines!
+    For more information, pop on over to
+	http://www.ffd2.com/fridge/grlib/
+</code>
+====== Side Hacking ======
+===== Super/Turbo CPU VDC Hack =====
+<code>
+                           Super/Turbo CPU VDC Hack
+                                     for
+         Commodore 128 with SuperCPU 64 or Turbo Master CPU Accelerators
+	     		        by Henry Sopko
+		            (henry.sopko@hwcn.org)
+As many of you probably know, accessing the VDC (8563) chip is not
+possible when using a SuperCPU 64 (version 1 tested only!) or the
+TurboMaster CPU (latest revision), until now. With this 1 wire hack,
+you can have access to the C128 (flat only tested) VDC 80 column
+chip with your SCPU 64 or TurboMaster CPU!
+DISCLAIMER
+--------------------------------------------------------------------
+I take no responsibility whatsoever to any damage that may occur to
+your Computer or SCPU 64/TM CPU resulting from this hardware hack!
+You do this hack totally at YOUR OWN RISK!
+[C=Hacking disclaimer: if you screw it up, it's your fault!]
+--------------------------------------------------------------------
+This hack was only tested on a flat C128, using CMD's SCPU 64 (version 1).
+Tested also was the Turbo Master CPU 4.09 MHz accelerator from Schnedler
+Systems (latest revision).
+Parts required: (1) long wire (12 inches or so, cutting it to length).
+INSTRUCTIONS
+Dissassemble your C128, taking the metal shield completely off.  With the
+motherboard exposed, find the 8563 VDC chip (U22). After locating this chip,
+remove it (take note of the notch position, so you correctly re-insert the
+chip). Bend out PIN 9 (R/W) of the 8563 just enough so it does not touch the
+socket or any metal (in the flat 128, theres not much room, so be carefull).
+Now re-insert the 8563 chip. Take a wire (you can either solder the wire to
+pin 9 as I did, or use Microclips -- your choice).  Now, connect the wire by
+soldering or using Microclips to PIN 5 on the CARTRIDGE EXPANSION PORT. Thats
+it!
+I have done this hack quite a while ago without any signs of problems
+whatsoever. The C128 functions the same with or without a SCPU 64 or TM CPU
+connected after preforming this hack. I really did this hack for the Turbo
+Master CPU so I could access the VDC. Turns out, that the SCPU 64 accelerator
+(and maybe others?) work with this hack as well. The better choice of course
+is to buy a CMD SuperCPU 128 to take full advantage of the Commodore 128 in
+both modes!
+</code>
+===== 16K Memory Expansion for the Vic-20 =====
+<code>
+By Per Olofsson <MagerValp@cling.gu.se>.
+Thanks to Ruud Baltissen, Pasi Ojala and Spiro Trikaliotis for help and
+suggestions.  The latest version of this project may be found at
+http://www.cling.gu.se/~cl3polof/64.html.
+I tried to keep the expansion as simple as possible, requiring no chips
+besides the two memory chips, and a minimum of soldering. It uses two 6264
+SRAM chips (62256 also works) piggy-backed to the Kernal and Basic 2364
+ROMs. It's recommended that you do the expansion one chip at a time, as this
+greatly simplifies troubleshooting. After the first chip checks out OK, do the
+second one. I'll start out by explaining a few basic principles.
+o Static Electricity
+We'll be using CMOS RAM chips, and they are very sensitive to static
+electricity. If you don't have an anti-static wrist strap, make sure you touch
+a grounded surface before you touch the chips. Do not work sitting on shag
+carpet in a mohair sweater while petting the cat :)
+o Be Careful With ICs
+ICs are sensitive to heat, and keeping the soldering iron for too long on a
+pin can toast the chip. If you need to redo a solder joint on a pin, wait for
+it to cool down first.
+o Up, Down, and Pin Numbering
+The top of a DIP IC (the kind used in Vic-20s) is marked with a small notch,
+looking something like this:
+       ___ ___
+  =|   V   |=  8
+  =|       |=  7
+  =|       |=  6
+  =|       |=  5
+      `-------'
+As you can see, the pin numbers start at 1, and the first pin is the top left,
+going down to the bottom left, then from the bottom right to the top right.
+Piggy-backing
+-------------
+Piggy-backing is a quick way of adding another IC on top of an existing
+one. Normally you would create a PCB with chip sockets, connect it to the
+expansion port and populate it with memory chips, but with piggy-backing you
+simply add chips on top of internal ones.  This works when the new chip's pins
+has signals that are identical to, or closely matches, the layout of the one
+it's being mounted on top of.
+RAM
+                                                ___ ___
+ROM                 NC   1  =|   V   |=  28  Vcc
+             ___ ___                 A12   2  =|       |=  27  /WE
+   A7   1  =|   V   |=  24  Vcc       A7   3  =|       |=  26  CS2
+   A6   2  =|       |=  23  A8        A6   4  =|       |=  25  A8
+   A5   3  =|       |=  22  A9        A5   5  =|       |=  24  A9
+   A4   4  =|       |=  21  A12       A4   6  =|       |=  23  A11
+   A3   5  =|       |=  20  /CS       A3   7  =|       |=  22  /OE
+   A2   6  =|       |=  19  A10       A2   8  =|       |=  21  A10
+   A1   7  =|       |=  18  A11       A1   9  =|       |=  20  /CS1
+   A0   8  =|       |=  17  D7        A0  10  =|       |=  19  D7
+   D0   9  =|       |=  16  D6        D0  11  =|       |=  18  D6
+   D1  10  =|       |=  15  D5        D1  12  =|       |=  17  D5
+   D2  11  =|       |=  14  D4        D2  13  =|       |=  16  D4
+  Vss  12  =|       |=  13  D3       Vss  14  =|       |=  15  D3
+            `-------'                          `-------'
+As you can see there are 8 that don't match. However, we don't have to rewire
+all of them. NC means "No Connection" so we can just ignore that pin. Note
+that if you're using 62256 chips you'll have to wire this one too, see
+below. We want to connect CS2 to Vcc, and we'll also swap A11 and A12, leaving
+pins to solder on each chip. Swapping address bus pins works on RAM chips,
+as it only affects how bits are stored internally -- when you read them out
+again, they're swapped back. This also works for the databus.
+We'll mount one 6264 on top of the Kernal ROM, and one 6264 on top of the
+Basic ROM. The ROMs are marked UE11 and UE12 and can be found in the bottom
+right of the motherboard. The wiring is identical for the two chips, except
+for the /OE and /CS1 pins. The pins that we want to rewire we carefully bend
+up so that they don't connect to the ROM. You want to bend them almost all the
+way up (about 150 degrees) so that you can reach them with the soldering
+iron. The pins are very sensitive, so make sure you bend the right pins --
+bending a pin back again could easily break it.
+Sometimes the pins on the RAM are too wide apart to make a good connection
+when you piggy-back it. In this case, bend all the pins on the RAM slightly
+inwards. You can do this by putting it on the side on a flat, hard surface and
+press gently.
+o Soldering A11/A12 and Vcc
+You could get A11, A12, and Vcc from several places on the motherboard, but as
+they're available on the ROMs we'll just solder small wires from the ROM to
+the RAM. Remember that we're swapping A11 and A12, so connect pin 18 on the
+ROM to pin 2 on the RAM. Connect pins 26 and 28 on the RAM to eachother.
+o Soldering /WE
+Pin 27 on the RAMs should be connected to pin 34 on the 6502 CPU. The CPU is
+the 40-pin chip in socket UE10 on the motherboard, right next to the ROM
+chips. Pin 34 is the 7th pin if you count from the top right pin on the CPU.
+o /OE and /CS1
+In the Vic-20 memory is divided into 8 blocks of 8K each. Block 0 is further
+divided into 8 1K blocks, of which 5 are populated with RAM.  Block 4 is used
+by the VIC and the VIA chips, block 6 is the Basic ROM, and block 7 is the
+kernal ROM. This leaves four blocks (1, 2, 3 and 5) available for cartridges
+and RAM expansions. For RAM to be visible to the basic interpreter, you must
+start by adding ram in block 1, then 2 and then 3. RAM in block 5 is never
+detected by the basic. 8K cartridges use block 5, and 16K cartridges use block
+together with another one, usually 3. To be as compatible as possible with
+existing cartridges and to expand basic memory I'll use block 1 and 2 for this
+expansion, but you could use any two of the available blocks you want. I've
+added instructions for making the blocks selectable by switches below.
+The block signals are available on the 74LS138 decoder chip marked UC5 on the
+left side of the motherboard. Block 1 is on pin 14, block 2 is on pin 13,
+block 3 is on pin 12 and block 5 is on pin 10. If you look closely you'll see
+that the signals for block 1 and 2 go out from the chip a few mm to a small
+pad. It's much easier to connect your wires to these pads than the pins on the
+decoder chip. Solder a wire from block 1 to pin 20 and 22 on the first RAM
+chip, and a wire from block 2 to pin 20 and 22 on the second RAM chip.
+You're done!
+That's all. When you power up the Vic-20, you should be greeted with a 19967
+BYTES FREE message. If you've only done one chip so far, you'll get 11775
+BYTES FREE, provided you connected it to block 1. If you've connected memory
+to other blocks but not block 1, you'll just get the normal 3583 BYTES FREE
+message. To test your memory, try this program:
+input "test which block";b
+s = b*8192 : t = s+8191 : e = 0
+print "testing databus"
+for a = s to t : poke a, 85 : if peek(a)  85 then gosub 1000
+poke a, 170 : if peek(a)  170 then gosub 1000
+next : de = e
+e=0 : print "testing high address bus"
+for a = s to t : poke a, int(a/256) : next
+for a = s to t : if peek(a)  int(a/256) then gosub 1000
+next : he = e
+e=0 : print "testing low address bus"
+for a = s to t : poke a, a and 255 : next
+for a = s to t : if peek(a)  a and 255 then gosub 1000
+next : print
+print de;"errors found in databus test"
+print he;"errors found in high address bus test"
+print e;"errors found in low address bus test"
+end
+e = e+1 : print "error at";a : return
+The program takes a couple of minutes to run.
+Troubleshooting
+---------------
+  The computer doesn't start at all, or all you get is a black screen
+   You've probably shorted or toasted something. Not good, this could
+   have damaged the computer. Recheck all your soldering and make sure
+   that you haven't accidentally connected something wrong.
+  The computer powers up with 3583 bytes free
+   Memory in block 1 is either not connected or not working. Check the
+   connections between block 1, /CS1 and /OE, between R/W and /WE, and
+   between Vcc, CS2 and Vcc.
+  The computer powers up with something other than 3583, 11775 or 19967 bytes
+  free
+   Memory is functioning partially, check A11 and A12. This could also
+   indicate that a RAM chip is faulty.
+  The computer powers up with the correct number of bytes free, but the memory
+  test program fails
+   Memory is functioning partially. If the databus test fails, check the
+   connections between block 1, /CS1 and /OE, between R/W and /WE,
+   between Vcc, CS2 and Vcc, and D0 through D7. If the address bus test
+   fails, check A0 through A12.
+Using 62256 chips instead of 6264
+---------------------------------
+You can freely substitute 62256 chips for the 6264. Only two pins differ:
+RAM                          62256 RAM
+             ___ ___                           ___ ___
+   NC   1  =|   V   |=  28  Vcc     A14   1  =|   V   |=  28  Vcc
+  A12   2  =|       |=  27  /WE     A12   2  =|       |=  27  /WE
+   A7   3  =|       |=  26  CS2      A7   3  =|       |=  26  A13
+   A6   4  =|       |=  25  A8       A6   4  =|       |=  25  A8
+   A5   5  =|       |=  24  A9       A5   5  =|       |=  24  A9
+   A4   6  =|       |=  23  A11      A4   6  =|       |=  23  A11
+   A3   7  =|       |=  22  /OE      A3   7  =|       |=  22  /OE
+   A2   8  =|       |=  21  A10      A2   8  =|       |=  21  A10
+   A1   9  =|       |=  20  /CS1     A1   9  =|       |=  20  /CS1
+   A0  10  =|       |=  19  D7       A0  10  =|       |=  19  D7
+   D0  11  =|       |=  18  D6       D0  11  =|       |=  18  D6
+   D1  12  =|       |=  17  D5       D1  12  =|       |=  17  D5
+   D2  13  =|       |=  16  D4       D2  13  =|       |=  16  D4
+  Vss  14  =|       |=  15  D3      Vss  14  =|       |=  15  D3
+            `-------'                         `-------'
+Pin 26 (A13) can be connected to Vcc just like on the 6264, but we need to
+wire pin 1 (A14) to either Vcc, Vss or another address bus pin. It's probably
+easiest to wire it to pin 2 (A12). We won't be using the greater capacity of
+the 62256 using this method (doing so would require some kind of decoder
+logic) but sometimes 62256 chips are cheaper than 6264, or maybe you just have
+some lying around.
+Adding Block Select and Write Protect Switches
+----------------------------------------------
+Adding block select switches allows you to chose which blocks should be
+populated on the fly. This allows you to chose between a basic expansion and a
+"cartridge emulator" that allows you to load cartridge images into ram and run
+them. I added one switch for each chip, giving the first chip the option
+between block 1 and 3, and the second between 2 and 5.
+  block 1 -----o
+                \
+                 o----- to /CS1 and /WE on chip 1
+  block 3 -----o
+  block 2 -----o
+                \
+                 o----- to /CS1 and /WE on chip 2
+  block 5 -----o
+As a kind of copy protection, some cartridge images try to modify themselves
+to detect if they're running from RAM. If we add write protect switches we'll
+be able to run those as well. Switch to write enabled while loading, then
+switch to write protected and reset.
+      R/W -----o
+                \
+                 o----- to /WE on chip 1
+     +5 V -----o
+      R/W -----o
+                \
+                 o----- to /WE on chip 2
+     +5 V -----o
++5 V is the same as Vcc.
+</code>
+===== Quick Quadratic Splines =====
+<code>
+S. Judd <sjudd@ffd2.com>
+Splines are neat.
+Splines are a way of drawing curves -- specifically, drawing a curve through
+any set of _points_ that you choose; for example, a curve that starts at (0,0),
+goes over to (100,50), then loops back to (50,0), and continues on through
+any number of points can be drawn just by specifying the points.
+This is a very useful thing!  One place splines are used is in drawing fonts.
+With a relatively small list of points, it becomes possible to draw letters
+in arbitrary shapes (and scale those shapes easily).  Another application
+is animation -- it is possible to specify a long motion path using just
+a few points along the path.  Furthermore, an animated object might have
+different parts that move differently -- arms, legs, head, etc.  By just
+specifying a few frames of the animation, splines can be used to generate
+the in-between frames.
+Chances are good that by now you are thinking about some of your own
+applications for splines, so let's see how they work.
+Most articles/books/etc. that talk about splines talk about "cubic splines".
+This article is going to talk about "quadratic splines", which never seem
+to be mentioned.  Which is a pity, since quadratic splines are perfectly
+adequate for many (if not most) spline applications and are far more
+computationally efficient.
+Graphically, a two-dimensional quadratic spline looks something like:
+              * P1
+             / \
+            /   \
+           /     \
+          /  . .  \
+         / .     . \
+        /.         .\
+       /.            .
+      /.              * P2
+     .
+    .
+P0 *
+(Another brilliant display of ASCII art).  The curve starts at P0, moves
+towards P1, and then turns around and heads towards P2, where it ends.  If
+we draw lines from P0 to P1 and from P1 to P2, these lines are tangent to
+the curve at the endpoints P0 and P2; that is, these lines say what
+"direction" the curve is going at the endpoints.  Using the above diagram,
+it should be very easy to visualize how changing P1 changes the shape of
+the curve.
+So here, for your computing pleasure, is a quadratic spline:
+P(t) = P0*(1-t)^2 + 2*P1*t*(1-t) + P2*t^2
+where P0, P1, P2 are constant values, and t ranges from zero to one.  If
+you don't like equations, then how about a computer program to compute
+the above:
+P0=10:P1=100:P2=37
+FOR T=0 TO 1 STEP 1/16
+PRINT T,P0*(1-T)*(1-T) + 2*P1*T*(1-T) + P2*T*T
+NEXT
+This is actually very easy to understand.  When t=0, P(t) = P0.  As t starts
+to increase, (1-t) starts to decrease and P(t) starts moving towards P1.  As
+t gets even larger P(t) starts moving towards P2, until finally, at t=1,
+P(t) = P2.
+You may be wondering why there is that 2*P1 in the equation, instead of
+just P1, but that will become apparent shortly.
+At this point there is an important thing to notice about the above
+equations: adding _any_ constant to P0 P1 and P2 is just like adding the
+constant to the entire spline P.  Let P0=P0+C, P1=P1+C, P2=P2+C; the
+spline is then
+P'(t) = (P0+C)*(1-t)^2 + 2*(P1+C)*t*(1-t) + (P2+C)*t^2
+      = [ P0*(1-t)^2 + 2*P2*t*(1-t) + P2*t^2 ] + C*[(1-t)^2 + 2*t*(1-t) + t^2]
+      = P(t) + C
+This is one reason that factor of 2 multiplying P1 is important -- it makes
+the expression multiplying C add up to 1.  This property means that splines
+can be _translated_ easily.  Note that one value you can translate everything
+by is P0 -- subtract P0 from each point and the spline becomes
+P(t) - P0 = 2*(P1-P0)*t*(1-t) + (P2-P1)*t^2
+and hence
+P(t) = 2*(P1-P0)*t*(1-t) + (P2-P1)*t^2 + P0
+which gets rid of the P0*(1-t)^2 term.  Depending on how the spline algorithm
+works, this can save some computation time.
+Now, the points P0, P1 etc. are called "control points".  If you're on the ball
+(or if you've tried the BASIC program above) you've noticed that while the
+spline starts at P0 and ends at P2, it never actually reaches P1 -- it just
+heads towards it but then heads away towards P2.  If a different P1 is
+chosen, the spline still starts at P0 and ends at P2 but takes a different
+path between the endpoints.  P1 controls the shape of the curve.
+So now let's say we want a curve that passes through three points, s0, s1,
+and s2, using a quadratic spline.  P0 and P2 are easy to choose:
+	P0 = s0
+	P2 = s2
+P1 can actually be chosen at this point to be any number of points.  All we
+do is choose a value for t -- call it t1 -- when the spline should hit s1:
+P(t1) = s1 => P1 = (s1 - P0*(1-t1)^2 - P2*t1^2) / (2*(t1*(1-t1))
+(just substitute t=t1 into the equation for P(t) and solve for P1).  So if
+t1=1/2, say, then
+P1 = (s1 - P0/4 - P2/4) / (2 * 1/4)
+   = 2*s1 - (P0 + P2)/2
+and the spline will hit s1 halfway through the iteration at t=1/2.
+In a typical application, of course, the curve will need to go through tens,
+hundreds, even thousands of points.  Naturally, the way to do this is by
+joining a bunch of splines together.
+If we just choose a spline for every three points, using the above equation
+for P1, there will typically be sharp corners where the splines join
+together.  Sometimes this is a good thing -- for example, when drawing
+something like a valentine we might want sharp corners.  But usually
+what is needed is a nice smooth curve through all the points.
+With quadratic splines this is a piece of cake.  Each spline has three
+control points: the two endpoints, and the middle control point P1.  The
+endpoints are simply chosen to be the points we want to pass through,
+and P1 can then be chosen to make all the connections smooth.
+That is, given a list of points s0, s1, s2, ... to put a curve through,
+choose s0 and s1 to be the endpoints of the first spline, s1 and s2 to
+be the endpoints of the second spline, and so on, and choose the middle
+control points to make everything smooth.
+"Smooth" here means a continuous first derivative -- if you don't know what
+a derivative is then don't worry about it, it just means that the "slope" of
+each spline is the same where they join together.  Given a spline
+S1(t) = P0*(1-t)^2 + 2*P1*t*(1-t) + P2*t^2
+the derivative at t=1 is given by
+S1' = 2*(P2 - P1)
+P2-P1 is simply the line segment running from P1 to P2, which verifies what
+was said earlier: at P2 the curve is tangent to a line drawn from P1 to P2.
+              * P1
+             / \
+            /   \
+           /     \
+          /  . .  \
+         / .     . \
+        /.         .\
+       /.            .
+      /.              * P2
+     .
+    .
+P0 *
+P2-P1 is the direction the curve is headed in.  So to join another spline
+smoothly to the first one, simply extend this line segment and make sure
+the second middle control point lies somewhere on that line:
+              * P1
+             / \
+            /   \
+           /     \
+          /  . .  \
+         / .     . \
+        /.         .\
+       /.            .
+      /.              * P2
+     .                 .       * P5
+    .                   \.   ./
+P0 *                     \ ../
+                          \ /
+                           * P4
+Since the first spline is tangent to P2-P1, and the second spline is tangent
+to P4-P2, the two splines have the same slope at P2, and join smoothly.
+Note that P4 can be _anywhere_ along the P2-P1 line, and choosing different
+values for P4 will change the curve.
+To make this more precise, let the two splines be given by
+S1(t) = P0*(1-t)^2 + 2*P1*t*(1-t) + P2*t^2
+S2(t) = P3*(1-t)^2 + 2*P4*t*(1-t) + P5*t^2
+To join them smoothly, the slope of the first spline must be proportional
+to the slope of the second spline at the joint:
+P4-P3 = c*(P2-P1)
+where c is some constant (the _direction_ of the two slopes need to be the
+same, but not the magnitude).  So, to make the second spline fit smoothly
+to the first we simply choose the middle control point P4 as
+P4 = P3 + c*(P2-P1)
+or, in plain English, starting from P3 (the joining point) move some
+distance c in the direction P2-P1.  To see why the factor c is important
+just scroll up a page or two to the diagram, and imagine how the curve
+changes as P4 slides back and forth along the line.
+We now have the tools to construct a smooth curve that passes through any
+points s0, s1, s2, s3, ...  Let the first spline pass through s0, s1,
+and s2, using the t=1/2 formula given earlier:
+P0 = s0
+P1 = 2*s1 - (s0 + s2)/2
+P2 = s2
+P1 could be chosen in other ways, of course, but the above usually works
+pretty well.  Then choose each succeeding spline to match up smoothly with
+the previous spline:
+P3 = s2			;start at spline 1 endpoint
+P4 = P3 + c1*(P2-P1)	;smooth joint
+P5 = s3			;next point
+P6 = s3
+P7 = P6 + c2*(P5-P4)
+P8 = s4
+and so on.  (When drawing smooth curves, it is of course really only
+necessary to store the middle control points P4 P7 etc. for each spline).
+The choice of the constants c1 c2 etc. really depends on how you want the
+curve to look.
+As you can see above, each extra point requires another spline.  One spline
+per point may sound like a lot, but there are a lot of pixels in-between each
+pair of points, and more importantly these are quadratic splines and hence
+can be made to go very, very fast.
+Computing the spline
+--------------------
+Note that the control points are one-time calculations; those three constant
+values completely determine the spline.  One way of drawing the spline is
+to use some lookup tables for t^2, 2*t*(t-1), and (1-t)^2 and do a little
+fast multiply magic.  This is fast and straightforward, so I won't talk
+about it much except to mention that signed multiplies may be required,
+and each curve is limited to 256 points (t can go from 0 to 255 in the
+lookup tables).  Note also that it would be nice to have an "incremental"
+plot routine, i.e. one that just updates pointers when necessary, instead
+of recomputing all the bitmap pointers at every iteration.
+Which of course brings us to a second way of drawing the spline: to ask
+"how does the spline change when I increment t?"
+Let's say that t is incremented by dt at each step (t -> t+dt).  At each
+step, then, the spline changes by
+S(t+dt) = P0*(1-t-dt)^2 + P1*2*(t+dt)*(1-t-dt) + P2*(t+dt)^2
+	= S(t) + k1*dt^2 + k1*2*t*dt + k2
+where k1 = P0 - 2*P1 + P2 and k2 = 2*dt*(P1 - P0).  That is, to advance one
+step, we add
+	k1*dt^2 + 2*k1*t*dt + k2
+to the current value.  Take a look at how the above value changes as t
+changes:
+t	k1*dt^2 + 2*k1*t*dt + k2
+--	------------------------
+	k1*dt^2		    + k2 =   k1*dt^2 + k2
+dt	k1*dt^2 + 2*k1*dt^2 + k2 = 3*k1*dt^2 + k2
+*dt	k1*dt^2 + 4*k1*dt^2 + k2 = 5*k1*dt^2 + k2
+*dt	k1*dt^2 + 6*k1*dt^2 + k2 = 7*k1*dt^2 + k2
+and so on.  This means that all we have to do to advance the spline is
+something like
+	c0 = k1*dt^2
+	C = c0 + k2
+	S = P0
+:loop
+	S = S + C
+	plot S
+	C = C + 2*c0
+	loop
+Which is really, really fast.  Instead of specifying the spline with the
+three values P0, P1, and P2 we can specify it by the three values P0, k1,
+and k2.
+It is possible to understand this iterative method somewhat.  The update
+constant k1 can be written as
+	k1 = (P0-P1) + (P2-P1)
+whereas k2 goes like
+	k2 ~= (P1-P0).
+P1-P0 is the "direction" line segment towards P1, so the curve starts moving
+towards P1.  But k1 starts to balance that out with the P0-P1 term (the line
+segment pointing in the opposite direction), while moving towards P2 with the
+P2-P1 term, which is the direction line segment from P1 to P2.  Now, isn't
+that all nice and clear now?
+The Program
+-----------
+At the end of this article I've included a sort of "spline laboratory" --
+it's a little BASIC program that lets you experiment with different aspects
+of splines and see what they look like.  It uses BLARG for the graphics, so
+I've included that as well.
+When you run it, it plots three points on the screen to draw a curve through.
+You can move these points around, as well as add new points, draw the splines,
+draw the control point "a-frames", and so on.  It has a ton of commands,
+basically because I just added them as I got curious about different things:
++/-		Move to next/previous point
+cursor keys	Move current point
+return		Draw spline
+space		Clear screen
+*		Toggle point display
+< >		Decrease/increase accuracy (number of bits in iteration)
+<-		Increase/decrease time step (number of points in spline)
+=		List control points (numerical values)
+.		Draw control point a-frame
+S		Toggle smooth splines (see below)
+A		Add more points
+Q		Quit
+Pressing "A" adds three points at a time, starting at the last point in
+the curve.  The reason for adding three points, instead of just one, is
+because of the "S"mooth spline feature.  When smooth splines are selected,
+the program will draw a smooth curve through all the points.  When toggled
+off, the program will draw a spline through every three points, using the
+"t=1/2 method" to select the middle control point.
+The program uses the fast iteration method described earlier, using fixed
+precision arithmetic (since this is what an assembly program would do).
+The < and > keys are used to change this precision, since certain splines
+need more precision than others.
+Finally, the value CC=0.4 is set in line 10.  This is the "smoothing"
+constant, i.e. c1 in the equation for P4 below:
+P3 = s2			;start at spline 1 endpoint
+P4 = P3 + c1*(P2-P1)	;smooth joint
+P5 = s3			;next point
+You might want to experiment with different values, to see what happens
+(or else let each spline have their own value).
+Anyways, the program is not meant to be terribly profound -- just a starting
+point and something to play with to work out your own ideas on!
+Cubic Splines
+-------------
+Just for completeness, here is a cubic spline:
+P(t) = P0*(1-t)^3 + 3*P1*t*(1-t)^2 + 3*P2*(1-t)*t^2 + P3*t^3
+As you can see, it has four terms instead of three, and is cubic in t.  But
+the idea is the same -- at t=0 it starts at P0, as t increases moves
+towards P1, then towards P2, and finally ends at P3.
+You can also see that it is significantly more computationally involved than
+the quadratic spline.  Moreover, computing the middle control points P1 and P2
+is also fairly involved -- much more involved than with the quadratic spline.
+So, why use a cubic spline?  Two reasons: first, you can specify the derivative
+at _both_ endpoints -- the direction line P1-P0 will be the slope at the
+starting point, and the direction P3-P2 will be the slope at the end point.
+This gives some flexibility needed for certain applications.
+Second, you can alternatively match _second_ derivatives at the connection
+points, which again can be useful for certain applications.
+For more information about cubic splines, just check out any decent graphics
+book.
+The Program
+-----------
+begin 644 slab.zip
+M4$L#! H    & $]LQQJSS3>D,0<  /0(   *    8FQA<F<N;6TN;P\  0(4
+M!18%!@T(+0=]_OY^"1$3%A,&!??W]U<#(FR(L/E!SS)AVIRI4]2S4P,LW#]U
+MPL+^4\_'F4[Y_:DAIF.>?VK@A0>"!DA88.S^D04BAY[?O'_S XWSAQZ?]#YH
+M1@S\/_3[H@OV)CBP<T?@RB'>9PH0^-2G+$%F?5H5Y-6@3JF"# IR:M&A4HL@
+MW[3HU*E!CQ;1OBC2GR"=!I7J-&E0%L> @\R_M*A+D$R?6BDV5:1)G2XQ?BK4
+MHD&,+;0(E)DND?X(=D\Q%8U3B88I'W0J%6F4:%(KT:TSU:)2HJN^*%2D19U$
+MM;W2JD2)6%]5*XCG_@<9\P5MO\QY(W=;!-Z)]W(W>L=;@SOF&ISIWN,%[P(_
+M#[Q&<B,7A=+X5,$SF7+XH4FE#F5:5/Q1J9''#?_4J%'R39\2+5H>=M(CW)O#
+MUF"?%UJENJ[13^D;:OJA3YG"5@^P:W#XP?T/_VL\O7&2Q\4?GVU\]G'IQR4>
+M!\D1..B"A/^#_ P<]D*0PH%#IY^Y?\#4_\&:_M]Y?T#TN88S-OSSR"'2FW32
+M_WN/! X?8W+PL"MFHQXZ0>3HH;M')RWH(>-3/CQ&,. C@S=\CLD?0X?@J_<U
+MXPZ+[X=N'[[YY"#ABT\N$KYZ,.V>F7P][)<D'\)<D<G?51-. LG*X2]8#PFI
+M9'G)AFD0I#2FH==/#AL^A#<?))TTY7^V'X$9AW _G?K)ME-+ <>I@YP+$(&]
+M-439(@J'$\K=]>FDX!6J[BT6.-+>889GXCU*IN=/=;Q!KK]=FB+.=A?GPA1A
+M%S1>$:9%G(K;A9PA/U0-'CEL!=DG!UJZ8OJ D ."59P2W\VO5*G2MGR-[;P!
+M&NRO0A@M6[&L/^BZ/XB*/?$QENU7/F0!/Q^S#ZINE7$,LK2_KN8SK</'FYIF
+MX0 0ZTW!!^\9/G@4C#6#Y1O/8P7['S!0D! 1$A08\/_?GQ\?'AP@.1LF '1A
+M 7I5+(/L[^J9"Y86B+,\1=6E!Y:O"%MC:8*D"Q;:M'&3%DCHG >22K\BX8&0
+MM1=&:?BD:&3?K5\0ML&D_],&%(VXL$G'Z(4[QCRL-+#').@5$1;^![W1_VJ$
+MT<*C44(NF&SXAF!NI_%(=<72HTL7Q*%PA;9J!+>Y<"GO5*8S0J:8$)!RKCDA
+M<-4P$28$MXRK>K^1:H,T'-Q=\;W3Q3] \E;#39LD?Q)R'/RAMX'R@,"LM*@
+M[15#^]DK\?.HR8:YP.'B)04T7$8.'"$DU^Z%^O]ZSWZ*RJ%OXP92N6A9DT8%
+M0C=OANA]_<-TF/PD;/2E^Z=%$'-0<Z^_;_[3\)4#-'U"[L8PAXU=0.V!SI +
+M;8'P+Y8W"?F&]_6<#1'>\R!/#XM"#D^9_U7>YY)"STD!_)^IT>'&"T(L7O9$
+M[$:9!OT"[R[5SO]>YU;_BIV9*AWV&/Y =KR@P)(#B]B.@]'IAI_A8+E4=B[K
+M&#:6M Q$JXC=I<GLS9<&"_H ]O UPJR8_ _-?&H,"B?O<):^\73?-O8]6K1,
+MKP[KA4OQ"A_E*YP4(%8"MQI+1PG;H:I9H8H@]>G"IMC$Z@RL.2$.;#%=H>#9
+MT]%N#;^1N!<T79J)JJ6LE_*9^X1.]F"*<=7)D4-&B!%5)CBF+!=&50D8RD<)
+MIRU$7<1?>&UA-J;W<Z)YV2SS,[@N-83(NEL,,C?B$:I:V9S*\C8VI]K8!,0%
+MY$T!WA4L-E[:K1*:?L-MS;<UFN;302(O;G"-L>$7$[HM[/5EW<"OT3C();WU
+MYE)L5FS<K7&"$+YO6VQF&1E2(QOOM'Q;XFXA^S:JU@#COZE<\W!%Z7#S!4FA
+M@YMV"S^$:@G5_K:WR\4Q ?:9%\OWFF2FQS=;V,$4-F9R:\U@:$OA=#&-&K[(
+MY!E.)@MXE#PF/:K4WL=,.#\_9O/';!Q5IRRV&,F5Q+YT:I@>/!F^NY@SAD\D
+MJC[1SWQ_#*Q ,9M/#89T2GE=QJ=,NIS&8/+>1_KF^6.(>:AB\Z?.O>2<4 Z;
+M.B2;OL+)>X&P(I('X@A+62CM E#:5ML4R_BI;ZM(N1=5P[%J\!O45LR,_M-Y
+M(BS!)#W!V/NDT?V1]X.!PN!?6Y0-/"B%;I1B9 KPH *D40$Y\6#! _P/L'5$
+MZ"E!0F_96F#WA ,;$=\:8'>D*9#W:QQM2OX-^QIOY'QKC- ;]>2GQMGHN'4G
+M!-F(>)!Y <*'$?-B";E53Q-@4QBI=3 OFH#)8.C[3BMAW'XKA(I%@\04#063
+MAKU:&G!*O@W]B&%?=:$IOW493)8R'[Y!<"S9!47_=]3Z8"-$LT#(ZL%#A#[3
+M44%R:M"-NH)$GMO/PJ%/GIGZ<*&%>9JI2:1ND/&F1]P8L8#M;I^.[GH:O 2,
+M-'N#G'ELFN],(V?74&)P2@Q R:D',$$_,>$4F. $F&#XR./DN%OMG\QJBJ!!
+MQ4P?9"8T= &/KT2408-GM#R8;10!:$X:H#.Y4T8@DA'Y" P&4$L#! H    &
+M %1LQQJZ:;<U#@8  %P)   )    <W!L:6YE;&%B%!$2! ($!08%#@8.!PD(
+M/@<>!W[__PT1$P<&! ,&!006]_?W)P,B3(BP(,#R,6T"#(E0(4"B5&7'U#DU
+MJ=8BQK>I<^A0V3!=T@0X%.%#@(9!8AV*TB;-E"RS&.-0L1CC68P=H%:$% $^
+M!NFT9TR9-W4>?3JUJE"0,F'"A D0,$(>_'LJ%*/K\"_,%,=XC./1#]EE(!]'
+M^2\C# K0* SS!'UJTZ=/J2(%:91IT*, >R,T"M!)_F7JS)*O,9Z6[#'D#=GV
+M$_KXGQSA4H#C8]Q=I_JA ,\CA HP<)*QD[*_3G&O>Q+7I3C>%PSP/T*R -6#
+MA)&-0\F6XLH$J#&A6X"A@Y+4N1@$\64? _O,E"!/@VP< [ "O)D0+P!K%=E9
+M!'7N55:QKHX)D&I"0=S<@1NX*N['3<B(FR-QVYK*SI+/CA-:XN8(W,#R^SGA
+M)NYM.XAMOUD3(.^$G=I9I<A3#?>K45"R*5RKSD0[<ZDG!$59AU &\/N$H^C9
+MAY%!*L3.2OL*%9;29A[:H*VT'U+A*6V.H6T+)\*3O#@5IK+F+]8PPWI5H2IK
+M7F%MJCR4]17<0XW5<W\*U@*TJY"6-[?PYE7>/AM&=\0/,+'"6][<P]MGN-QR
+M5IA+FJ-(>\Z<. %N5[A+FEV*L*08'!N5G!H>Q"&:Q!":9!*:1/ U8\>9M?(5
+M]O+G*?Y6\KZ*^  ++O1EK;-CBPQR;0BW2Q<B:WD3ONH97]95&09O!"^5&G0P
+MSE7C9.7\5>/A^>O >*FE9<O:'+E5ENI"D0$3T=+%+F09D+S.S#I@EX/UA38#
+M8 +-##(I"TU 2*_GA3NZ>4JW2 ;I;NR%0 -X0@HS@/,9EUC&^D*E <>]'<16
+M 19?:'X V@$#E+[P_("?=7".'FKXJ0"[+T0_L#$(/4V_4/Y )3932,Y@^?L+
+M^0\,#"*M($FMC >HDJ%!@EAEHZ0:XZRLYJK$LU.5L8SXS&G^C&;8:T.^DX_S
+MK@PA$LPB#\\B#\TB#YI%'CPM0XT$*C\6UJ98 S,D26#Q*PFYX;E7.FMA7LZ-
+MZ'NLAQFZ).@8(&F&2PD$]J%/FT*M2K7(<9U2E?J4R:=_F@1YD9TU0R;Z4;]S
+MAE8)K"Z3M.+K(%P*:<O1,M*NL2&8<);):EQ7"32O8<LI^ZK0<VRI)Q\9?Y9Q
+M\"SCG&6< ?)LJ 9V"6@R!T3FO.%;@HLNWF$PYC%KY'JS#>G,$VE@J'2Y#?T2
+M '487QVJ'6_#OP1U K3<$# !F0;VFJ7VJD^K3E%^5:E6BS"L-PPTWMH-!Q.
+MY94L6=1CRW)B&DZ_WA"1Y@!.HCED^0 [.FQ,0%&6Y2GF4&RT)>NJ8E\MHV F
+M<,T"#L\"KEG <8!%'4H"/ Y3/*[*: -\U>$EA+E)8$,RRHIUR DV5_):T3I\
+MM5@#.X3U6HD694HU:,NF16;[4R*ML%GLUSN,Y5W)#FL3H 6W=JB; "U89],@
+MI+B-B_N9-EN1M+92W"&QR@X#,@SPQY05&BE?IJQ4T,PTALY0LG"?B/^Q7)](
+M(9[QH;-ZS5*/9JD'SU(/FJ5>L]3KTH?80E;4\"S\3 5Z4BN>\\2OD\CR.F\K
+MY&9!Q@&"?2B>0,B$RJ#](%.QU 6H]B$[@84#O',0O0!]A(>RCL5F^,."!6+F
+M+3_6OEE4ANVKEJM#+"\W'T-EXGCX"W^HP%QGPQA'58WSJG$\Q\O\YP\I%A@\
+MPKL:V>T_] #O6:Y@V'8EM.<*G_&(:H2(PERN,'X9IRL,I7.8$%L6@"W"LUF/
+M,9L);V,M9#I/B#(+N#2+#*<*D6<!B0$ZA5>7D5^M$(T6N/5K(3X_$.LL]I-H
+M[ =ETDMG#!'Z 8I^!.5;U=3CZ)\"H:"L??R&1WRGJY/4[$/4?L"CD[53926\
+MA'.(Y ^(=)(R!EIW0W1_H*136<X%.!PB_H."0+[;(>)>L-.#3AGYV?2^'Z+P
+MA41>XBGR-E<A\CJ#;)KZ(9NG4=D3/D"*$9E]KWK8NXB7LPLC9F^G?4Q5%&<.
+M^S,C6L->>5*_3)"J",VW[.03'T4SI@*<&A'<O==& 1Y+F&)C3W-E-., LT94
+MO]#1AA502P$""@,*    !@!/;,<:L\TWI#$'  #T"   "@
+MI($     8FQA<F<N;6TN;U!+ 0(* PH    & %1LQQJZ:;<U#@8  %P)   )
+M              "D@5D'  !S<&QI;F5L86)02P4&      (  @!O    C@T
+#
+end
+.......
+....
+..
+.                                    C=H #20
+</code>
+====== Main Articles ======
+===== VIC KERNAL Disassembly Project - Part IV =====
+<code>
+Richard Cini
+February, 2001
+Introduction
+============
+	In the last installment of this series, we examined the six remaining
+routines that are called from the IRQ and NMI vectors. The routines examined
+are responsible for updating the jiffy clock, determining the location of
+color RAM, scanning the keyboard, and reading and setting the cursor position.
+	Having fully completed the main processor vectors, we'll continue this
+series by examining other Kernal routines.
+More Subroutines
+================
+	Much of the last three articles dealt with routines that were used in
+the VIC's startup process, configuring the screen and I/O devices, and polling
+the keyboard for user input.
+	Although the entire Kernal ROM consists of probably over 100
+individual subroutines -- all indirectly callable in some way - the VIC's
+developers really intended the user to only call the 39 routines accessible
+through the jump table at the end of the ROM. When looking at this table,
+we've so far only discussed only 10 of the routines contained therein.
+	It was designed in this fashion for multiple reasons. The functions
+selected for the jump table were clearly the ones Commodore found to be most
+useful for software programmers. The other routines were "internal" routines
+used by the "public" routines and the BASIC ROM.
+The jump table also hid code changes from the software programmer, although I
+don't believe that there were ever any significant updates to the Kernel after
+its initial release. The calling routine and parameters remained consistent
+even if the underlying code changed. It also facilitated sharing programs
+between machines with common lineage. For example, certain programs could be
+shared between the PET, VIC and the C64. Of course, minor modifications of
+these programs were required to account for different I/O locations.
+This structure is no different than a modern operating system such as Windows,
+or even the Macintosh, which had the concept of a ROM "toolbox."
+Anyway, I digress...
+When examining the functions available in the jump table, the following
+distribution becomes apparent:
+User I/O (screen/keyboard):	 3 functions
+Timekeeping:			 3 functions
+Memory management:		 3 functions
+Processor control:		 4 functions
+Device I/O:			26 functions
+Commodore appeared to be giving greatest support for interfacing the VIC to
+various devices. Many of these routines were used by the built-in BASIC
+interpreter to support file I/O through the tape deck and the serial IEEE
+port, as well as printer and RS232 support. Unfortunately, the only devices
+that made it onto the IEEE bus were floppy drive and printer devices. If there
+are others, I appreciate knowing about them.
+	Anyway, this provides a nice segue into looking at the device I/O
+routines in some detail.
+	The first step is opening a device. All devices are eligible to be
+opened in this manner. The OPEN function requires that the program call two
+preparatory routines first. The first one, SETNAM sets the filename parameter
+required by OPEN. Clearly only certain devices make use of a filename (such as
+the cassette or disk drive devices). For devices not requiring a filename
+pointer, just set the pointer to "null".
+FE49  ;===================================================
+FE49  ; ISETNM - Set filename (internal)
+FE49  ; Call with .A = filename length, .X = LSB of filename
+FE49  ; string, .Y = MSB of filename string
+FE49
+FE49  ISETNM
+FE49 85 B7	STA FNMLEN		; set length
+FE4B 86 BB  	STX FNPTR		; ptr L
+FE4D 84 BC  	STY FNPTR+1		; ptr H
+FE4F 60    	RTS
+	Calling SETNAM sets three Zpage variables that tell the OPEN routine
+where in memory to find a string containing the filename. Setting the length
+parameter to zero yields a null string.
+	When opening an RS232 channel, the filename string would contain two
+ASCII characters representing the configuration values for the command
+register and the control register.
+	The next call that is required is to set the underlying device
+parameters for the OPEN call.
+FE50	;===================================================
+FE50    ; ISETLF - Set logical file parameters (internal)
+FE50    ; Call with .A = file number, .X = device # (0-30),
+FE50	; .Y = command
+FE50	ISETLF
+FE50 85 B8  	STA LOGFIL		; file #
+FE52 86 BA  	STX CHANNL		; device
+FE54 84 B9  	STY SECADR		; secondary address
+FE56 60     	RTS
+	The SETLFS parameters are fairly common: the file handle number, the
+device to access, and any secondary address to send to the device. The
+combination of SETNAM and SETLFS is analogous to this BASIC statement:
+	OPEN 2,8,1, "mydat"
+where "2" corresponds to the file handle number, "8" is the device, and "1"
+is the secondary address. These numbers are ultimately stored in their
+respective data tables at location IOPEN_S3 in the OPEN routine.
+	Opening the RS232 channel does not require the use of a secondary
+address.
+	During file I/O, it's helpful to check the status of the current
+device by using the READST function. READST retrieves the value of the CSTAT
+variable. CSTAT is set through a call to ISETMS1 (at $FE6A) by various I/O
+routines based on device response.
+FE57	;===================================================
+FE57    ; IRDST - Get I/O status word (internal)
+FE57	;
+FE57	IRDST
+FE57 A5 BA  	LDA CHANNL		; get current device
+FE59 C9 02  	CMP #$02		; RS232?
+FE5B D0 0B  	BNE ISETMS+2		; no...branch to OS messages
+FE5D AD 97 02   LDA RSSTAT		; get RS232 status
+FE60 A9 00      LDA #$00
+FE62 8D 97 02   STA RSSTAT
+FE65 60         RTS
+FE66
+FE66
+FE66	;===================================================
+FE66    ; ISETMS - Control OS messages (internal)
+FE66	; On entry, .A is message number. Bit7=1 for KERNEL messages, and
+FE66	; Bit6=1 for control messages. Bit0-Bit5 is message number.
+FE66    ;
+FE66    ; set flag for OS messages
+FE66    ;
+FE66    ISETMS
+FE66 85 9D       	STA CMDMOD		;save message #
+FE68 A5 90       	LDA CSTAT		;get status
+FE6A
+FE6A    ; set ST bits
+FE6A    ISETMS1
+FE6A 05 90       	ORA CSTAT		;twiddle bits based on .A
+FE6C 85 90       	STA CSTAT		;save status
+FE6E 60          	RTS
+	The return values of the READST call have different meanings depending
+on what device is being accessed:
+	BIT	Cassette	  Serial R/W	Tape L/V
+	===	========	  ==========	========
+	Write timeout
+	Read timeout
+	Short block	  Short block
+	Long block	  Long block
+	Unrecoverable	  Any mismatch
+			  	  read error
+	Checksum error			Checksum error
+	End of file	  EOI line
+	End of tape	  Device not	End of tape
+				  present
+	So, after having set the file name information and setting the device
+access parameters, we're ready to actually OPEN the file. The following code
+is heavily commented, so I'll only expand where necessary.
+	The Kernal keeps track of the open files using a series of file handle
+tables. A maximum of 10 logical files can be open at one time. FILTBL keeps
+track of the logical file handle established in the call to SETLFS. SECATB
+keeps track of the secondary address associated with a given logical file
+number. Finally, the DEVTBL variable tracks which device number relates to the
+file handle. These three tables mirror the variables in the SETLFS call.
+F40A	;======================================================
+F40A    ; IOPEN - Open file (internal)
+F40A    ; Required prior calls:  FFBA/SETLFS and FFBD/SETNAM
+F40A	; No arguments
+F40A	IOPEN
+F40A A6 B8       	LDX LOGFIL	;get file number
+F40C D0 03       	BNE IOPEN_S1	;F411 read from output file?
+F40E 4C 8D F7    	JMP IOERMS6	;Yes, emit "NOT INPUT FILE" error
+F411
+F411        IOPEN_S1
+F411 20 CF F3    	JSR FIND	;locate file # in table
+F414 D0 03       	BNE IOPEN_S2	;file number not found, so move on
+F416 4C 81 F7    	JMP IOERMS2	;found, so emit "FILE OPEN" error
+F419
+F419        IOPEN_S2
+F419 A6 98       	LDX COPNFL	;get # of open files
+F41B E0 0A       	CPX #$0A	;are there 10 files open already?
+F41D 90 03       	BCC IOPEN_S3	;no, OK to open new file
+F41F 4C 7E F7    	JMP IOERMS1	;more than 10, "TOO MANY FILES" error
+F422
+F422        IOPEN_S3			; allocate file slot in table
+F422 E6 98       	INC COPNFL	;add 1 to count of open files
+F424 A5 B8       	LDA LOGFIL	;get file number from call
+F426 9D 59 02    	STA FILTBL,X	;save file # in table
+F429 A5 B9       	LDA SECADR	; get secondary address
+F42B 09 60       	ORA #%01100000	;$60 make it a device command
+F42D 85 B9       	STA SECADR	;save it as secondary and add it to the
+F42F 9D 6D 02    	STA SECATB,X	; SA table for that open file
+F432 A5 BA       	LDA CHANNL	;save device number to the
+F434 9D 63 02    	STA DEVTBL,X	;  device table
+F437
+F437					;Special handling for certain devices
+F437 F0 5A       	BEQ IOPENRC	; keyboard device? Yes, return
+F439
+F439 C9 03       	CMP #$03	;Is the device the screen?
+F43B F0 56       	BEQ IOPENRC	; yes, then return clear
+F43D 90 05       	BCC IOPEN_S4	;must then be the tape or RS232-branch
+F43F
+F43F					; Start IEEE stuff
+F43F 20 95 F4    	JSR SENDSA	;send secondary to IEEE bus and
+F442 90 4F       	BCC IOPENRC	; return clear
+F444
+F444         IOPEN_S4
+F444 C9 02       	CMP #$02	;RS232 (2)?
+F446 D0 03       	BNE IOPEN_S5	;not RS232, so process tape device
+F448 4C C7 F4    	JMP SEROPN	;open RS232 device
+F44B
+F44B         IOPEN_S5			;Tape device (1)
+F44B 20 4D F8    	JSR GETBFA	;Get tape buffer address
+F44E B0 03       	BCS IOPEN_S6	;MSB>2? No, continue with open
+F450 4C 96 F7    	JMP IOERMS9	;Bad tape buffer, emit "ILLEGAL DEVICE
+F453					; NUMBER" error
+F453
+F453         IOPEN_S6			;Continue with tape processing
+F453 A5 B9       	LDA SECADR	;get SA
+F455 29 0F       	AND #%00001111	;Are we in write/save mode?
+F457 D0 1F       	BNE IOPEN2	;yes, prompt for Play + Record
+F459
+F459 20 94 F8    	JSR PLAYMS	;wait for "PLAY" key
+F45C B0 36       	BCS IOPENRC+1	;$F494 return CY=1
+F45E
+F45E 20 47 F6    	JSR SRCHMS	;print "Searching for [name]" message
+F461 A5 B7       	LDA FNMLEN	;get length of filename
+F463 F0 0A       	BEQ IOPEN1	;no name specified, so search for
+F465					;  next header
+F465
+F465 20 67 F8    	JSR LOCSPH	;search for specific tape header
+F468 90 18       	BCC IOPEN3	;$F482 go get header
+F46A F0 28       	BEQ IOPENRC+1	;$F494 return found CY=1
+F46C
+F46C         IOPENA			; done searching and file was not found
+F46C 4C 87 F7    	JMP IOERMS4	;F787 "FILE NOT FOUND" error
+F46F
+F46F         IOPEN1			; Get next tape header
+F46F 20 AF F7    	JSR LOCTPH	;search for next header
+F472 F0 20       	BEQ IOPENRC+1	;$F494 return found CY=1
+F474 90 0C       	BCC IOPEN3	;$F482 go get header
+F476 B0 F4       	BCS IOPENA	;$F46C not found
+F478
+F478         IOPEN2			; write tape header
+F478 20 B7 F8    	JSR RECDMS	;wait for REC & PLAY keys
+F47B B0 17       	BCS IOPENRC+1	;$F494 return CY=1
+F47D
+F47D A9 04       	LDA #$04	;control byte ID for data header
+F47F 20 E7 F7    	JSR WRTPHD	;write tape header
+F482
+F482         IOPEN3
+F482 A9 BF       	LDA #$BF	;pointer to tape buffer head
+F484 A4 B9       	LDY SECADR	; get secondary address
+F486 C0 60       	CPY #$60	;SA=0 (read) mode?
+F488 F0 07       	BEQ IOPENRC-2	;$F491 Yes, skip write
+F48A
+F48A A0 00       	LDY #$00	; write mode
+F48C A9 02       	LDA #$02	;control byte ID for data block
+F48E 91 B2       	STA (TAPE1),Y	;write it to buffer
+F490 98          	TYA
+F491 85 A6       	STA BUFPNT	;save pointer
+F493
+F493         IOPENRC
+F493 18          	CLC
+F494 60          	RTS
+	The OPEN function spends most of its time saving parameter information
+into variable tables and figuring out which device to open. If the OPEN call
+is for the tape device, the code either reads or writes the respective tape
+header.
+	OPEN calls nine other routines, six of which deal with tape input and
+output. The three non-tape routines are FIND (find file number in table),
+SENDSA (send secondary address), and SEROPN (open RS232 device). Since the
+OPEN code spiders out so, I'm going to leave the tape-related routines to
+another article.
+	FIND is a very easy routine. It searches through the file handle table
+to see if the handle of the file we're trying to open is already being used as
+a result of a previous call to OPEN. Clearly each file handle number has to be
+unique to prevent confusion at the system level. If a file is already in use
+with the same handle number, .X returns non-zero, enabling the calling routine
+to drop into an error handler ("FILE OPEN" error).
+F3CF	;==========================================================
+F3CF	; FIND - Look for logical file number in open-file table
+F3CF    ; On entry to FIND1, .A=file#. On exit, .X=offset in file table
+F3FC	; to matching file number.
+F3CF
+F3CF             FIND
+F3CF A9 00       	LDA #$00
+F3D1 85 90       	STA CSTAT	;clear Status variable
+F3D3 8A          	TXA		; .X is logical file number copied to
+F3D4					; .A for use in FIND1
+F3D4             FIND1
+F3D4 A6 98       	LDX COPNFL	;get #of open files to count through
+F3D6
+F3D6             FINDLOOP		; loop
+F3D6 CA          	DEX
+F3D7 30 15       	BMI FLATRBX	;$F3EE reached 0, then exit
+F3D9 DD 59 02    	CMP FILTBL,X	;is this the one?
+F3DC D0 F8       	BNE FINDLOOP	;$F3D6 no, try again
+F3DE 60          	RTS		;return with .X= offset into table
+	The FLATRB routine is not used in OPEN, but the FIND subroutine exits
+through it. I don't know why this is since the FIND routine has a return path
+of its own. Anyway, FLATRB takes an index number into the open file table and
+sets the Zpage file variables according to the values pointed to by the
+index. For example, if I call FLATRB with .X=0, the file variables will be set
+with the information stored in location [0] of each of the file handle table,
+the device table, and the secondary address table. So, one could select an
+open file handle, use FIND to get the index number, and then use FLATRB to set
+the Zpage variables to the right values for subsequent use.
+F3DF	;==========================================================
+F3DF	; FLATRB - Set file values
+F3DF	; On entry, .X = offset in the file tables. Returns with
+F3DF	; Zpage file variables set.
+F3DF
+F3DF		 FLATRB
+F3DF BD 59 02    	LDA FILTBL,X
+F3E2 85 B8       	STA LOGFIL		;get file handle number
+F3E4 BD 63 02    	LDA DEVTBL,X
+F3E7 85 BA       	STA CHANNL		;get device
+F3E9 BD 6D 02    	LDA SECATB,X
+F3EC 85 B9       	STA SECADR		;get SA
+F3EE
+F3EE             FLATRBX
+F3EE 60          	RTS
+	After the OPEN routine determines that the file handle to be opened is
+unique, assigns the file variables to the various data tables, and determines
+which device is being opened, the code forks. If the device is the keyboard
+(device 0) or screen (device 3), OPEN returns. If it's the tape deck (device
+), the code continues by searching for or writing a tape header using the
+information supplied in the OPEN call. If it's for the RS232 adapter (device
+), execution jumps to SEROPN to continue the opening process. Finally, if
+it's an IEEE device (device >=4), then OPEN calls SENDSA to shift out the
+secondary address. When SENDSA returns, OPEN returns to the original
+caller. If SENDSA returns with the carry flag set (indicating an error
+condition) and then returns, execution will ultimately fall through to an
+"ILLEGAL DEVICE ERROR" error.
+F495	;==========================================================
+F495	; SENDSA - Send secondary address
+F495
+F495             SENDSA
+F495 A5 B9       	LDA SECADR	;get SA
+F497 30 2C       	BMI SNDSARC	;$F4C5 less than 0, exit
+F499
+F499 A4 B7       	LDY FNMLEN	;get filename length
+F49B F0 28       	BEQ SNDSARC	;$F4C5 no filename, just exit
+F49D
+F49D	             			; prepare to send filename string
+F49D A5 BA       	LDA CHANNL	;get device	number and...
+F49F 20 18 EE    	JSR ILISTN+1	;  command it to listen
+F4A2 A5 B9       	LDA SECADR	;get SA
+F4A4 09 F0       	ORA #%11110000	;$F0 make it into listen command
+F4A6 20 C0 EE    	JSR ISECND	;sent it to IEEE bus
+F4A9 A5 90       	LDA CSTAT	;check status variable
+F4AB 10 05       	BPL SENDSA1	;$F4B2 OK, then continue
+F4AD
+F4AD 68          	PLA		;error, set stack for caller's caller
+F4AE 68          	PLA
+F4AF 4C 8A F7    	JMP IOERMS5	;emit "DEVICE NOT PRESENT" error
+F4B2
+F4B2             SENDSA1		; continue processing-send filename
+F4B2 A5 B7       	LDA FNMLEN	;get filename length
+F4B4 F0 0C       	BEQ SNDSARU	;length is 0, so send unlisten command
+F4B6             		; There is a filename, so send it to IEEE
+F4B6 A0 00       	LDY #$00	; set loop counter
+F4B8
+F4B8             SENDSALP		; output filename to IEEE bus
+F4B8 B1 BB       	LDA (FNPTR),Y	;get character
+F4BA 20 E4 EE    	JSR ICIOUT	;send it
+F4BD C8          	INY		;get next one
+F4BE C4 B7       	CPY FNMLEN	; at the end?
+F4C0 D0 F6       	BNE SENDSALP	;no, then loop
+F4C2
+F4C2             SNDSARU		;done sending filename, so send
+F4C2 20 04 EF    	JSR IUNLSN	; unlisten command to IEEE bus
+F4C5
+F4C5             SNDSARC
+F4C5 18          	CLC
+F4C6 60          	RTS
+	SENDSA is a simple routine that checks for a valid secondary address
+and whether the OPEN command involves a filename. Then, the routine commands
+the specified device to "listen" and sends the secondary address and the
+filename to it. When completed, the code sends the "unlisten" command to the
+device and returns success. If there is a problem sending data to the device,
+a "device not present" error is generated.
+	The next routine is SEROPN. SEROPN is called by OPEN when it
+determines that the device that's being opened is the RS232 port. Here's a
+quick story about RS232 support in the VIC.
+Based on some information that I've seen on the Web and what's available in
+"Inside VIC" and the "VIC20 Programmer's Reference Guide", I've concluded that
+the VIC hardware was originally designed to include a MOS 6551 ACIA
+communications chip. The 6551, with appropriate level shifters, would have
+provided true hardware support for RS232. But for cost reasons, board space
+reasons, or both, the 6551 was dropped and emulated in software and in
+hardware by using a spare port on one of the existing 6522 VIAs.
+The Kernal includes a lot of code to manage RS232 FIFO buffers and to perform
+the bit shifting through the User Port (port B of VIA 1). The User Port only
+provides TTL-level RS232; Commodore and others sold an adapter that provided
+the level-shifting hardware (typically TI 1488/1489 chips) and a DB25F
+connector. The circuit is very simple and could have been built by any
+resourceful hobbyist.
+Without further delay, here's the code that completes the opening process for
+the RS232 serial device:
+F4C7	;==========================================================
+F4C7    ; SEROPN - Open RS-232
+F4C7	;  "filename" contains the initialization data for the
+F4C7	;  command and control registers
+F4C7
+F4C7             SEROPN
+F4C7 A9 06       	LDA #%00000110	;set VIA DDR. PB[2:1] are DTR and RTS
+F4C9 8D 12 91    	STA D1DDRB	; signals, respectively
+F4CC 8D 10 91    	STA D1ORB
+F4CF A9 EE       	LDA #%11101110	;$EE. Set PCR for CB2/CA2 manual high
+F4D1 8D 1C 91    	STA D1PCR	; and CB1/CA1 for H->L IRQ trigger
+F4D4					; CB2 is RS232-TX and CB1 is RS232-RX
+F4D4 A0 00       	LDY #$00
+F4D6 8C 97 02    	STY RSSTAT	; clear status byte
+F4D9
+F4D9             SEROPLP
+F4D9 C4 B7       	CPY FNMLEN	;is the filename length = 0?
+F4DB F0 0A       	BEQ SEROPN1	;$F4E7 yes, go straight to open
+F4DD
+F4DD B1 BB       	LDA (FNPTR),Y	;copy first 4 chars of filename...
+F4DF 99 93 02    	STA M51CTR,Y	; to buffer and loop
+F4E2 C8          	INY
+F4E3 C0 04       	CPY #$04
+F4E5 D0 F2       	BNE SEROPLP	;$F4D9 loop
+F4E7
+F4E7             SEROPN1		;done copying init_data
+F4E7 20 27 F0    	JSR BITCNT	;get number of data bits
+F4EA 8E 98 02    	STX BITNUM	;save data bits count
+F4ED AD 93 02    	LDA M51CTR	;get control register
+F4F0 29 0F       	AND #%00001111	;$0F isolate baud rate bits
+F4F2 D0 00       	BNE $+2		;F4F4
+F4F4
+F4F4					;convert baud rate bitmap to clock
+F4F4					; divisor
+F4F4 0A          	ASL A		;*2
+F4F5 AA          	TAX
+F4F6 BD 5A FF    	LDA R232TB-2,X	;$FF5A,X baud rate H
+F4F9 0A          	ASL A
+F4FA A8          	TAY
+F4FB BD 5B FF    	LDA R232TB-1,X	;$FF5B,X baud rate L
+F4FE 2A          	ROL A
+F4FF 48          	PHA
+F500 98          	TYA
+F501 69 C8       	ADC #$C8
+F503 8D 99 02    	STA BAUDOF	;save baud rate divisor
+F506 68          	PLA
+F507 69 00       	ADC #$00
+F509 8D 9A 02    	STA BAUDOF+1
+F50C
+F50C AD 94 02    	LDA M51CDR	; command register
+F50F 4A          	LSR A
+F510 90 09       	BCC SEROPN2	;$F51B
+F512
+F512 AD 20 91    	LDA D2ORB	;check DSR (data set ready)
+F515 0A          	ASL A
+F516 B0 03       	BCS SEROPN2	;$F51B ready, continue
+F518 4C 16 F0    	JMP DSRERR	;not ready, DSR error
+F51B
+F51B             SEROPN2		; device ready
+F51B AD 9B 02    	LDA RIDBE	;set RS232 buffer pointer
+F51E 8D 9C 02    	STA RIDBS	; -- RX --
+F521 AD 9E 02    	LDA RODBE
+F524 8D 9D 02    	STA RODBS	; -- TX --
+F527
+F527					; prepare to "hide" buffer in memory
+F527 20 75 FE    	JSR IMEMTP+2	; get MEMTOP
+F52A A5 F8       	LDA RIBUF+1	;has RX buffer been created?
+F52C D0 05       	BNE SEROPN3	;$F533 yes, check on TX buffer
+F52E 88          	DEY		; else create input buffer
+F52F 84 F8       	STY RIBUF+1
+F531 86 F7       	STX RIBUF
+F533
+F533             SEROPN3
+F533 A5 FA       	LDA ROBUF+1	;TX buffer created?
+F535 D0 05       	BNE SEROPN4	;$F53C yes, skip create
+F537 88          	DEY
+F538 84 FA       	STY ROBUF+1	;else create TX buffer
+F53A 86 F9       	STX ROBUF
+F53C
+F53C             SEROPN4		; set MEMTOP to hide buffers from BASIC
+F53C 38          	SEC
+F53D A9 F0       	LDA #$F0
+F53F 4C 7B FE    	JMP STOTOP	;$FE7B set new MEMTOP
+SEROPN begins by extracting the values of the command and control registers
+from the "filename" string passed to it from the OPEN routine. SEROPN then
+saves the number of data bits contained in a serial data frame and then
+calculates the proper clock divisors for the selected baud rates. The 6551
+transmit and receive clocks are emulated by using one of the timers in VIA1 to
+shift out the data at the specific bit rate. Receiving bits is accomplished
+through the NMI routine discussed in Part 2 of this series.
+In a nifty trick, SEROPN allocates transmit and receive buffer memory at the
+top of BASIC RAM and lowers the top of RAM variable to fake BASIC into
+thinking that there's 512 bytes less of memory.
+The SEROPN routine finally exits and returns to OPEN by a JMP to STOTOP, the
+routine used to set the top of system memory.
+Well, that's all that we have time for. Next time, we'll tackle some of the
+tape routines related to the OPEN command.
+.......
+....
+..
+.                                    C=H #20
+</code>
+===== Mods and digital mixing =====
+<code>
+by Jolse Maginnis
+jmaginni@postoffice.utas.edu.au
+As most of you know, MOD playing on the C64 is nothing new, Nate/DAC wrote
+modplay64 quite a while ago now, but there has never been any in depth look at
+how a mod is played. So in this article I will discuss everything you need to
+know about MODs and digital sound mixing (well the main bits anyway!)
+Very recently I got sick of working on OS stuff and started working on my own
+modplayer for JOS, called, wait for it... Josmod! I was really quite surprised
+at the quality of sound it produced, particularly as it was only playing with
+Bit Mono SID digis.
+At that stage Josmod only played 4-channel Amiga format MOD's which have been
+around for a long time but are now being outdated by newer formats such as
+S3M, XM and IT. These new formats are in the same style as the old Amiga MOD
+formats, except they allow for more channels, more instruments/samples and
+different effects. Since the SCPU is a fast enough machine to mix and play
+more than 4 channels at once, and I was sick of seeing so many MOD's that it
+couldn't play because they were done in the newer formats, I added support for
+S3M's and more recently, XM mods.
+Josmod didn't take very much time to write at all, for one reason in
+particular: it's written in C. Compared to writing an application in assembly,
+C is so much easier to debug and test. That's one of the great things about
+the 65816, you can write in a high level language and get away with it. One
+part of Josmod had to be written in 65816, and that's the mixer, which has to
+be optimized as it's where 90% of Josmod's time is spent.
+Enough propaganda! On with the show..
+-------------------------------------------
+There are 3 main parts to any modplayer: the loader, the player routine & the
+mixer.
+First of all I will start by talking about the mixer as it's the simplest part
+and also the part that deals with the actual sounds themselves.
+The Mixer
+---------
+First of all, I'd like to point out that I'm no expert on digital sound, and I
+only learned all this stuff myself when I started writing Josmod.  Here's an
+ASCII drawing of a digitally sampled sound:
+     --                            --
+    /  \               --        /    \
+   /    \             /  \      /      \
+------------------------------------------
+          \         /      \  /
+           \       /        --
+            \     /
+              ---
+-128
+Yes I know it looks crap, but you get the idea. You'll note that it's a SIGNED
+sample, which is very important when it comes to mixing.
+The Amiga has 4 digital sound channels, each capable of playing its own set of
+sampled data, so it can effective play four different sounds at the same time.
+But what about the C64? SID's only capable of playing one digi at a time. How
+on earth can we get it to play 2 samples at once, or 4? 8 or 16? C64's aren't
+alone in their single channel output problem, most PC sound cards only have 1
+channel for output (2 if you count Stereo). So how is it done? It's extremely
+simple actually. You just add them together! But remember it's signed
+addition!
+The one thing that you have to worry about when adding though, is that you
+don't overflow your result. For example, if you're adding two 8 bit numbers
+together you could easily go higher than 127 or lower than -128, just by
+having two loud samples. So it's best to use a 16 bit result, and handily the
+has 16-bit registers. :) On a side note, if a sample is mixed with an
+exact opposite of itself, it turns to silence! I believe this is actually used
+in some new cars to cut down on noise inside the car!  [Editor's note: it is
+also used in things like aviation headsets, and goes under terms like "Active
+Noise Reduction" and "Active Noise Cancellation"]
+Not only does the mixer have to mix samples together, it also has to control a
+couple of other things, namely volume and pitch.  The player reads the notes
+and effects, and tells the mixer which samples to play, at what speed and how
+loud they are supposed to be.
+I'll start with volume, as it's quite an easy transformation. In Amiga MODs
+volumes range from 0 (Silence) to 64 (Full volume). So a volume of 32 would be
+half volume, and effectively divide the samples by 2. e.g. A sample of -40
+would become -20 at volume 32, and a sample of 100 would become 50. The best
+and fastest way to perform volume calculations in real time is of course
+using a lookup table. So you end up with mixer code that looks like this:
+(65816 remember!)
+        lda [Samp]      ; Get the current sample
+        and #$ff        ; It's 8 bits only
+        asl             ; Multiply by 2 since the volume
+        tay             ; table is 16 bit values
+        lda [VolTab],y  ; Get the value!
+VolTab contains a pointer to the appropriate volume table, which is calculated
+with:
+Sample*Volume/64
+Volume was easy but what about pitch? Ordinarily if we were dealing with
+normal 1 channel digis we'd simply change our CIA timer rate so data would
+be fetched at a different speed, which is ideal. This is basically what the
+Amiga does, except it's done in hardware, so doesn't steal valuable CPU
+cycles. However, we can't do this as we're mixing various samples into one! So
+instead we have to simulate different pitches by altering the sample position
+at varying rates, rather than just going straight to the next sample.
+So for example, if a sample needs to be played at twice its normal speed, we
+add 2 to the sample pointer rather than 1, and it will sound twice as
+fast. It's all very well adding values like 1 and 2, but what if the sample
+needs to be 1.5 times the normal speed? It's easy solved with some fixed point
+math (16 bits for the fraction, 16 bits for the integer part), and you end up
+with something like this (remember that Samp is a pointer into the sample
+data):
+        txa             ; Add the fraction part
+        adc Low         ; X is used to hold the low part
+        tax
+        lda Samp        ; Now add the integer with carry
+        adc Hi
+        sta Samp
+        bcc noinc       ; Crossed a bank boundary?
+        inc Samp+2
+noinc   ....
+Very simple really isn't it?
+Note that the tradeoff here is between playback rate and sample rate; that is,
+if we have a sound sampled at 10000 samples per second, and take every other
+sample, that's like taking 5000 samples per second.  So instead of changing
+the _playback_ rate -- which is what e.g. changing the CIA timers does -- we
+instead effectively change the original _sample_ rate. Another thing worth
+mentioning is that when the playback rate is greater than the sample rate, you
+can improve output by "interpolating" the sample. Interpolating is basically
+guessing what the sample would have sounded like if it were sampled at the
+playback rate. I won't go into it any more than that, as adding it will slow
+the mixer down. I believe Nate's latest modplay64 does interpolation.
+That's basically all that the mixer does, but I've left out one part, which is
+the part that adds the samples together. Rather than adding 4 values together
+at a time the Josmod mixer uses a buffer to add all the values for 1 channel
+in one go, and then adds all the samples for the next channel to that buffer,
+etc. This means that the mixer can handle as many channels as it wants, rather
+than being fixed to 4 channels. Here is the code for mixing 2 samples: (Assume
+bit registers!)
+        lda [Samp]
+        and #$ff
+        asl
+        tay
+        lda [VolTab],y
+        adc (OutBuf)            ; Add it to the buffer
+        sta (OutBuf)
+        txa
+        adc Low
+        tax
+        lda Samp
+        adc Hi
+        sta Samp
+        bcc ninc
+        inc Samp+2
+ninc    lda [Samp]
+        and #$ff
+        asl
+        tay
+        lda [VolTab],y
+        ldy #2                  ; Next buffer position
+        adc (OutBuf),y
+        sta (OutBuf),y
+        txa
+        adc Low
+        tax
+        lda Samp
+        adc Hi
+        sta Samp
+        bcc ninc2
+        inc Samp+2
+ninc2   ...
+By changing Samp (and Low/Hi) the same code can add different samples to the
+buffer.  Josmod uses an unrolled mixing loop which does 16 samples before
+looping, otherwise there'd be too much loop overhead.
+You will note that at the end of mixing all the channels what we're left with
+is a buffer that is full of 16 bit samples. Well, I believe the IDE64 team
+have a made a 16 bit sound card... but generally this buffer is not going to
+be of any use to us, until we convert it to 8 bit unsigned data. The SID uses
+bit unsigned samples, and the DigiMax and other user port sound cards, use 8
+bit unsigned, so it's the best format to convert it to.
+Not only does it need to be converted to 8 bit unsigned, but remember the
+overflow problem? Values that are too loud need to be clipped to their maximum
+volume (127 or -128). So we can kill two birds with one stone here, and create
+a post processing lookup table that converts the data and also clips loud
+samples.  If it were graphed the table would look something like this:
+$ff -------
+     ^     \
+ Clipped    \
+             \
+              \
+$80 ------------------------
+                \
+                 \
+                  \
+                   \
+                   --------
+                       ^
+                    Clipped
+So after all channels are mixed together, the buffer is postprocessed with
+that table to prepare it for output on the sound device! Which incidentally
+could be any device, as Josmod is device independent, it's up to the device
+driver to deal with getting a CIA interrupt and what to do with the
+samples. In the case of 4-bit SID this would be:
+        lda [Samp]
+        lsr
+        lsr
+        lsr
+        lsr
+        sta @$d418      ; @ means long addressing - $00d418 SID Volume register!
+That's about all for the mixer, the only other thing that it needs to do is to
+check if a sample has ended, and either stop it, or loop it back to some
+point.
+Bear in mind that the mixer I've described is a mono one, as all channels get
+mixed into the one output buffer. A stereo one would mix channels into two
+different output buffers.
+I should mention that since I wrote this article, I've made some improvements
+to the mixer. Namely pre-calculating the sample pointer offset, so that the
+mixer loop doesn't need to calculate the next sample position for every
+sample. So now the sample mixing code is much quicker:
+        lda [Samp]
+        and #$ff
+        asl
+        tay
+        lda [VolTab],y
+        adc (OutBuf)            ; Add it to the buffer
+        sta (OutBuf)
+	ldy #1			; The offset to the next sample
+	lda [Samp],y		; (precalculated)
+        and #$ff
+        asl
+        tay
+        lda [VolTab],y
+        ldy #2                  ; Next buffer position
+        adc (OutBuf),y
+        sta (OutBuf),y
+	....
+        txa			; Add sample speed * 16
+        adc Low			; This code now only gets
+        tax			; executed once per 16
+        lda Samp		; samples rather than every
+        adc Hi			; sample.
+        sta Samp
+        bcc ninc2
+        inc Samp+2
+ninc2   ...
+These changes provide, at a guess, a dramatic increase of about 30 percent in
+playback speed. The only drawback to this method is very slight loss of
+accuracy, but I don't think you will be able to tell the difference.
+The Loader
+----------
+You've now seen how to mix samples, so what you need to know next is how to
+load in the samples from the modfile and also load the data that tells you how
+to play them. Ok let's check out the .mod file format. Sizes are all in bytes.
+Offs : Size
+------------
+    : 20   : Module name
+   : 930  : Sample headers for 31 Samples
+  : 1    : Number of orders
+  : 1    : Unused?
+  : 128  : The orders
+: 4    : Identification string
+: ?    : The patterns
+?    : ?    : The 8 bit sample data for all samples
+Ok first of all you need to know exactly what orders & patterns are.
+Patterns contain all the information about what pitch and sample to play and
+also contain information about effects which change the volume and pitch of
+samples. Every pattern contains 64 rows of data. Each row holds note
+information for the number of channels contained in the tune (normally 4 in
+Mods). A pattern can be visualised as something like this:
+       2       3       4
+------------------------------------
+:  | 1 c-1 | 2 d-2 | 2 f#5 | 3 e-4 |
+:  | 5 d-1 | - --- | - --- | 3 f-4 |
+......
+: | 4 e-1 | 3 d-1 | - --- | - --- |
+------------------------------------
+That's a simplified version of what a pattern is like, as it doesn't include
+any effect information.
+So what does "1 c-1" mean?
+Well the first 1 refers to the sample number, while "c-1" refers to the note
+and octave to play (C natural, octave 1).
+Orders will be familiar to anyone who's had any experience with some of the
+SID editors/players. Rather than playing pattern 0, pattern 1, etc.. through
+to the last pattern, orders allow you to choose the order in which patterns
+are played, thus allowing you to repeat patterns easily.  E.g. The order table
+may look something like this: 0 1 2 3 2 2 4 3 5 6
+You will notice that nowhere in the mod format does it mention how many
+patterns are contained in the file.. To calculate this you look through the
+order table and find the highest value, and use that as the number of patterns
+in the file (+1).
+Ok now let's have a look at the sample header format:
+    : 22   : Name
+   : 2    : Length (divided by 2)
+   : 1    : Finetune
+   : 1    : Default Volume (0-64)
+   : 2    : Loop position (divided by 2)
+   : 2    : Loop length (divided by 2)
+
+One thing to be warey of here is the fact that the 16 bit values stored in
+this structure are in big endian format, because Amigas use the 680x0 line of
+processors. So to convert it for use with C64 it needs the high and low bytes
+swapped around. Also I have no idea why the 16 bit values are stored divided
+by 2... I guess this is something to do with playing the mod on the Amiga too,
+or perhaps to allow larger than 64k samples?
+Ok now we know what the format of a .mod file is, it's time to get it loaded
+so our player can play it!
+You will notice that the first 1084 bytes of the file are fixed, so one
+approach to loading would be to load those first 1084 bytes and go on from
+there, but the approach I use is to load each part of the header seperately,
+which makes it easier to put the data in a format easier for the player. Ok
+let's take a look at the C source for Josmod's .mod loader..
+First a couple of declaration for identifying which mod format it is:
+typedef struct IdentStruct {
+	char *String;
+	int channels;
+} Ident;
+static Ident idents[] = {
+        {"2CHN", 2},
+        {"M.K.", 4},
+        {"M!K!", 4},
+        {"FLT4", 4},
+        {"4CHN", 4},
+        {"6CHN", 6},
+        {"8CHN", 8},
+        {"CD81", 8}
+};
+int loadMod(char *name, ModHead *mp) {
+	/* Variable declarations */
+	FILE *fp;
+	S3MSamp *samp;
+	unsigned char *patp;
+	unsigned int i,j,temp,numpat,temp2;
+	long patsize;
+	char *samdata;
+	Ident *idp;
+	/* Open the mod */
+	fp = fopen(name, "rb");
+	if (!fp) {
+		perror("josmod");
+		exit(1);
+	}
+	/* Read the name of the mod */
+	fread(mp->Name,1,20,fp);
+	mp->Name[20]=0;		// C strings are null terminated!
+	/* Read 31 sample headers */
+	samp = &mp->Samples[0];
+	for (i=0;i<31;i++) {
+		/* Read name and null terminate */
+		fread(samp->Name,1,22,fp);
+		samp->Name[22]=0;
+		/* Read length
+		Note: readWord() converts the 16 bit value
+		into C64 format
+		*/
+		samp->Length = readWord(fp) << 1;
+		/* Read and calculate finetune
+		Finetune is a 4 bit signed value
+		Values over 8 are negative values
+		*/
+		samp->Finetune = fgetc(fp);
+		if (samp->Finetune>=8)
+			samp->Finetune -= 16;
+		/* Read volume */
+		samp->Volume = fgetc(fp);
+		/* Read and calculate ending/looping positions */
+		temp = readWord(fp) << 1;
+		samp->Replen = readWord(fp) << 1;
+		/* If the loop length is higher than 2, this
+		is a looping sample, otherwise it's a standard
+		non looping sample that stops at the end */
+		if (samp->Replen > 2) {
+			samp->Looped = 1;
+			samp->End = (char *) temp + samp->Replen;
+			if ((unsigned int) samp->End > samp->Length)
+				samp->End = (char *) samp->Length;
+		} else {
+			samp->End = (char *) samp->Length;
+			samp->Looped = 0;
+		}
+		/* Go to next sample structure */
+		samp++;
+	}
+	/* Read orders and calculate number of patterns */
+	mp->NumOrders = fgetc(fp); fgetc(fp);
+	numpat=0;
+	for (i=0;i<128;i++) {
+		 temp = fgetc(fp);
+		 if (temp > numpat)
+		 	numpat = temp;
+		 mp->Orders[i] = temp;
+	}
+	numpat++;
+	mp->NumPatterns = numpat;
+	/* Identify type of mod */
+	fread(mp->Type,1,4,fp);
+	mp->Type[4]=0;
+	mp->Channels=0;
+	idp = &idents[0];
+	for (i=0;i<8;i++) {
+		if (!strncmp(idp->String,mp->Type,4)) {
+			mp->Channels=idp->channels;
+			continue;
+		}
+		idp++;
+	}
+	/* If we couldn't identify it, this isn't a mod file!
+	close the file and return. Otherwise print number of
+	channels. */
+	if (!mp->Channels) {
+		fclose(fp);
+		return 0;
+	} else {
+		printf("Channels %d\n",mp->Channels);
+	}
+	/* Calculate pattern sizes and allocate memory for patterns */
+	mp->LineSize = 4 * mp->Channels;
+	mp->PatSize = 64 * mp->LineSize;
+	patsize = mp->PatSize * numpat;
+	patp = xmalloc(patsize);
+	mp->Patterns = patp;
+	/* Load patterns */
+	for (i=0;i<numpat;i++) {
+		for (j=mp->PatSize/4;j;j--) {
+			/* Each note is stored in 4 bytes.
+			Contained in the 4 bytes is:
+			Sample number.
+			Note
+			Effect
+			Effect Parameter
+			conv2Note() converts the mod format note format
+			into a format easier for Josmod.
+			*/
+			* (unsigned int *) (patp+2) = readWord(fp);
+			* (unsigned int *) patp = readWord(fp);
+			conv2Note(patp);
+			patp += 4;
+		}
+	}
+	/* Load Samples */
+	samp = &mp->Samples[0];
+	for (i=0;i<31;i++) {
+		printf("Sample %d: %s\n",i,samp->Name);
+		if (samp->Length) {
+			/* If the sample exists, allocate memory
+			for it, and read it in. Then fix up it's end
+			pointer, then call fixSamp() to prepare it for
+			mixer output. */
+			samdata = xmalloc((long) samp->Length + 128);
+			fread(samdata,1,samp->Length,fp);
+			samp->Samp = samdata;
+			samp->End = (unsigned long) samp->End + samdata;
+			fixSamp(samp->Looped, samp->End, samp->Replen, 128);
+		} else samp->Samp = NULL;
+		samp++;
+	}
+	/* Close the file and return successfully */
+	fclose(fp);
+	return  1;
+}
+That's all for the loader! Now that patterns, orders, and samples are all
+loaded and in a suitable format, the player is ready to play it!
+Unfortunately that's all for now, as the player is quite a complicated topic,
+I'll save it for a later article. But before I finish, I do want to give you a
+basic outline of what happens in the player, so you can see where the mixer
+fits into all this.
+The Player
+----------
+Mods have two speed variables which control the way a mod is played. One is
+BPM, or Beats Per Minute. BPM specifies the speed at which the mod player
+routine is called, the default value is 125 BPM, or 50 times a second. As we
+all know, 50hz is the speed of PAL TV's, so it's no coincidence that this is
+the default, as it allowed Amiga players to setup their play routines on an
+interrupt synchronised with the screen, the same as with SID players.
+BUT since we don't have the luxury of having hardware to play the samples for
+us, it's not a good idea to hook our player to a raster interrupt, instead we
+calculate how many output samples need to mixed before we update our mod. We
+calculate that with the following:
+playbackrate / (BPM*2 / 5)
+This value is what I call the "TickSize". Everytime the player is updated, it
+will mix TickSize bytes of samples, then loop and update the mod again, mix
+TickSize bytes again, etc..
+The other speed variable is the number of Ticks per beat, and defaults to 6.
+This means that the mod player only fetches the next row of pattern data every
+Ticks. E.g. After 6*TickSize samples have been mixed.
+Each channel in the Mod has assocatied with it, a mixer structure, which looks
+like this:
+typedef struct {
+	char *Samp;		// Current sample position
+	char *End;		// End or loop position
+	unsigned long Replen;	// How far to loop back
+	unsigned long Speed;	// Speed/pitch of sample
+	int Low;		// Fractional part of sample position
+	int Repeats;		// Whether or not it repeats
+	int *VolTab;		// Pointer to volume table
+	int Active;		// Whether to mix this channel
+				// or not
+} MixChan;
+The player has to prepare these structures for each channel and on every tick
+update the appropriate fields depending on the data contained in the patterns.
+I'll leave you with psuedo code for what the player looks like:
+tickbeat = 6
+row = 64
+tickcount = 0
+orderup = 0
+make all channels inactive
+while (orderup < numorders) {
+	if (row == 64) {
+		get next pattern from orders
+		orderup++
+	}
+	if (tickcount == 0) {
+		get row data from pattern
+		process note - set sample speed
+		process sample number - set sample position volume
+		process effect - speed, volume and position effects
+	} else {
+		process effect
+	}
+	mix ticksize samples
+	if (mixing buffer full) {
+		play buffer
+	}
+	tickcount++
+	if (tickcount >= tickbeat) {
+		tickcount = 0
+		move to next row
+		row++
+	}
+}
+That's basically what the mixer does. The majority of the player code deals
+with effects processing, most of which are easy to process. Effects include:
+Portamento - sliding a note's pitch up or down.
+Volume setting/sliding
+BPM and Tick Beat changes
+Pattern looping
+Vibrato and Tremolo - Slight alterations in pitch and volume.
+Some effects are only processed on Tick 0, and some are processed on other
+ticks.
+Anyway that's all for now, the player code will be examined in a later
+article.  In the meantime you can view the source code in HTML form at:
+http://jos64.com/src/josmod.c.html
+.......
+....
+..
+.                                    C=H #20
+</code>
+===== The C64 Digi =====
+<code>
+Robin Harbron <macbeth@psw.ca>
+ Levente Harsfalvi <levente@terrasoft.hu>
+  Stephen Judd <sjudd@ffd2.com>
+Introduction
+------------
+Digis -- digitally sampled audio -- are fairly common on the 64.  This is
+meant to be a comprehensive article on digis: how they work, examples,
+different playback methods on the 64 (volume register and Pulse Width
+Modulation), and some tricks.  We'll even show you how to play 6-bit and
+even 8-bit digis in high quality on a 64, which is really pretty neat to
+hear.
+The first part discusses digis from a fundamental point of view -- just
+what a digi is, acoustic signals, and things like that.  The most common
+method of playing digis is via the volume register at $d418, and the next
+two sections are devoted to this technique.  Section two discusses some
+SID fundamentals, and the reason why $d418 may be used for digis (and why
+later-model SIDs don't play digis correctly); Section three discusses
+$d418-digis from a software perspective: how to play them, tricks for
+improving them, how to boost digis on 8580 SIDs, and how to detect what
+kind of SID (6581 or 8580) is in the machine.  The fourth and final part
+of this article discusses pulse width modulation, and includes example source
+code and a binary that plays a true 7-bit digi at around 16KHz -- something
+which, we think, has never been done before.
+Without further ado...
+===============
+Digis: Overview
+===============
+	The whole point of playing a digi on a 64 is to provide something
+for your ear to hear.  So let's begin by discussing just what an acoustic
+signal is and how that relates to digis.
+	Probably everyone knows that "sound" is how your ear responds to
+changes in air pressure -- that is, when you clap your hands together,
+it compresses the air between your hands in a special way, and that
+higher pressure moves outwards into the surrounding air (since it's at
+lower pressure).  That pressure change propagates along and when it
+encounters your ear it causes the ear drums to move, causing three little
+bones to move, causing some fluid to move, causing tiny, exquisitely
+sensitive hairs to move, transmitting a signal that your brain converts
+to "sound".
+	An audio speaker also changes the air pressure in response to a
+signal.  If you take a coil of wire and change the voltage on it, it
+generates a magnetic field; if a magnet is placed inside the coil, the
+changing magnetic field will place a force on the magnet, causing it to
+move, causing some air to be pushed along, causing a change in pressure,
+causing a signal to propagate to your ear which your brain interprets as
+Van Halen.  All a stereo (CD player, etc.) does is send a varying voltage
+signal to the speaker.  As that voltage level goes up and down the magnet
+moves back and forth, and so the speaker converts that electrical energy
+into an accoustic wave.
+	For us, the trick is to coax SID into sending a specific voltage
+signal to the speaker, the way a stereo or CD player might.  And a CD player
+is of course a very apt comparison, since it is itself a digi player.
+	Just for reference, a really good pair of ears can hear signals from
+around 20Hz to 22KHz, with the sensitivity dropping considerably outside
+of around 100Hz to 10KHz.  A CD player has a playback rate of 44KHz, and
+the highest frequency SID can generate from the frequency registers is
+around 4KHz.  If you've ever set SID to maximum frequency and heard just
+how high 4KHz is, you can appreciate that even 10KHz is _really_ high, and
+actually quite difficult to hear.  In human speech, most of the information
+content of vowel sounds is contained in the range 300Hz - 3KHz, and above
+around 1KHz for consonant sounds; most information in musical sounds is in
+the range 100Hz - 3KHz.
+Discrete Sampling
+	To understand digis a little better, consider the more general
+case of a discretely sampled signal -- a continuous signal sampled at
+discrete time intervals.  Let's say we had some device producing a
+_continuous_ sinusoidal signal in time:
+         *  *
+      *        *
+    *            *
+   *              *
+  *                *
+ *                  *                      *
+*                    *                    *
+                      *                  *
+                       *                *
+                        *              *
+                         *            *
+                           *        *
+                              *  *
+-----------------------------------------------> time
+(yes, I did miss my calling as an ASCII artist)
+To turn the signal into a _discrete_ signal, we simply sample the
+signal at discrete intervals of time.  For example, let's say the above
+signal lasts one second, and is input into a device which measures the
+value every 1/4-second.  The device will spit out four numbers: 0, 1, 0,
+and -1:
+          *
+*                   *
+                              *
+The sampling frequency here is four samples per second -- 4 Hz.  If we were
+to then play back this signal at the sampling frequency, we'd get a signal
+like
+          **********
+**********          **********
+                              **********
+So one thing sampling does is to "staircase" a signal -- the sample becomes
+some sort of "average" value over the sample period.  Increasing the sample
+rate -- taking more samples per second -- will smooth things out, and the
+sampled signal will look (and sound!) more like the original signal.
+Now let's say we just took two samples in that one second -- 2 Hz sampling
+rate -- and just happened to catch the signal at its maximum and minimum
+values (the peak and trough).  Upon playback, the signal would look like
+*********************
+                    *
+                    *
+                    *
+                    *
+                    *
+                    *
+  		    *********************
+That is, a square (pulse) wave.  If you're on the ball, you've noticed
+that the frequency of the new signal is 1 Hz -- exactly half the sampling
+frequency.  This is also called the Nyquist frequency.  In general, the
+_maximum_ frequency that can be captured in a discrete sample (called the
+Nyquist critical frequency) is half the sampling frequency -- as you can
+see above, it takes two data points to get a single (nonzero) frequency.
+So, for example, the highest frequency a CD player -- which has a sampling/
+playback rate of 44KHz -- can capture is 22KHz, well above the range of
+normal human hearing.
+Thus, increasing the sample rate increases the frequency range captured
+in the discrete signal.  This is why a digi at a high sample rate in general
+sounds better than a digi sampled at a low sample rate.
+BUT -- there is more to life than sample rate: there is also sample
+resolution.  The sample resolution -- 4-bit samples, 8-bit samples, etc. --
+determines how accurately the sample measures the actual signal.  For
+example, let's say we sample sin(x) when x=0.5:
+	sin(0.5) = 0.4794255...
+No matter what sample resolution we use, there will always be some error
+in the measurement, and the _true_ value of the sample will be the
+_measured_ value plus some error.
+In general the sampling errors are random and uniformly distributed, so
+the sampled signal corresponds to the original signal plus some noise (the
+random errors).  That is why you almost always hear some sort of hiss on
+a normal C64 digi, which uses a resolution of 4 bits per sample.
+So, increasing the sample _resolution_ decreases the amount of noise introduced
+into the sampled signal (and increases the dynamic range), and increasing the
+sample _rate_ increases the frequency range.
+If you're _really_ on the ball, you've noticed that the 1-Hz square pulse
+above actually contains frequencies higher than 1Hz, simply because a
+square pulse contains higher harmonics in addition to the 1Hz fundamental
+frequency.  And you've also no doubt realized that the sampled pulse wave
+would sound different than the original sine wave (due, of course, to the
+added harmonics) -- it's at the right frequency, but it will sound like a
+pulse wave instead of a sinusoid.
+Have we somehow broken the Nyquist limit?
+The answer is no, because of a nifty thing called the Discrete Sampling
+Theorem, which says that, given the samples h_n of a bandwidth-limited
+function h(t), the original function h(t) is given by
+	h(t) = dt * Sum{ h_n * sin(2*pi*f_c*(t-n*dt)) / (pi*(t-n*dt)) }
+where dt is the sampling period and f_c is the cutoff/critical frequency.
+What this means is that the original signal can be _reconstructed_ from the
+discrete samples, not that it is _equivalent_ to the discrete samples.
+The Nyquist limit is the highest frequency that can be _reconstructed_ from
+the discrete samples, not the highest frequency that will be produced if you
+"staircase" the discrete samples through a speaker.  If the original
+signal is bandwidth-limited, and there are at least two samples for the
+highest frequency, then the signal can be completely reconstructed.
+Since a "normal" digi contains all these extra frequencies, shouldn't a digi
+sound "different" than a "true" analog signal?  Sure.  On the other hand, many
+of the extra frequencies are beyond the range of human hearing, and the rest
+can often be removed using a filter -- all CD players filter the output, for
+example.  So sometimes it is worthwhile to turn on a low/band pass filter
+when playing a C64 digi, especially at lower sample rates.
+And that more or less summarizes basic discrete sampling theory.
+=============
+D418 Playback -- Hardware
+=============
+The SID contains both analog and digital subparts on one silicon plate -- in
+other words, it is a mixed signal device.
+At the time, the SID was certainly the best of the microcomputer sound chips.
+This may be mostly due to its mixed signal design, which the designers used
+to solve certain problems.
+The hard thing in a sound generator design is to implement waveforms, volume
+control, and mixing. Things like that don't really fit into the digital
+'either 0 or 1' philosophy, unless lot of data bits and arithmetic functions
+are involved. In a fully digital sound chip, the waveforms could be generated
+by ROM lookup tables. The mixing function could be derived from binary
+addition, while the volume control from division or multiplication. Unless the
+sound functionality is greatly simplified, the arithmetic functions must be
+present and they must be implemented in hardware. Finally, the D/A conversion
+could be done by (fast) pulse width modulation just at the output stage.
+(Most of today's wavetable sound cards operate like this).
+This method implies heavy arithmetic hardware, which was not an option for
+designers back then. Still, most sound chips were fully digital, and all
+suffer from the required compromises (i.e. generating square waves only,
+no dedicated channel volume control, etc. - both TED and the VIC-I are obvious
+examples).
+The solution that one finds in the SID design is very straightforward: mixing
+and variable volume level is problematic in a digital circuit when dealing
+with waveforms, so simply avoid doing it. In the SID, only the microcomputer
+interface, the registers, the oscillators (phase accumulating oscillators),
+and other controller logic are digital; the mixing and volume control parts
+are fully analog. There are digital to analog converters providing analog
+voltage levels from the digital state variables. The SID D/As are in fact
+'multiplying' D/As, having an analog input (AIN), an input base voltage
+(IBASE), and a digital input. They operate by amplifying the input voltage
+offset (AIN-IBASE) by a factor proportional to the number on the digital input
+and adding this offset back to the base level.
+This mixed signal design also allowed some other features to be implemented.
+The most important one is the analog filter (that is, a two integrator loop,
+bi-quadratic filter, according to Yannes). With that, the SID points beyond a
+home computer sound chip - it is a true analog subtractive synth (marketing as
+such was cancelled because of manufacturing capacity reasons).
+Here is a detailed map on the SID inners (analog path; probably my most
+beautiful ASCII ever :-D). Info can be found in the SID patents (US 4,677,890;
+), the MOS 6581 technical document (can be found somewhere on the Net), or
+the back of the Programmer's Reference Guide (PRG).
+                -----------------  11bit  ------------
+                |Cutoff freq reg|-------->|Cutoff D/A|---------o
+                -----------------         ------------         |
+                    $d415-16                                   |
+                                                               |
+                -----------------  4bit   ------------         |
+                |Resonance reg. |-------->|Reson. D/A |-o      |
+                -----------------         ------------- |      |
+                    $d417.[4-7]                         |      |
+                                                        |      |
+                                 =0                     v      v
+-----------    -----------     >o------------>|    ------------------
+|wave D/A |--->|env. D/A |-->o/               |    |                |
+-----------    -----------      o--->|        |    |                |
+     ^              ^          ^ =1  o--------|--->|                |
+     |12bit         |8bit      |     |        |    |                |
+     |              |          |     |        |    |                |
+-----------    -----------     |     |        |    |                |
+|OSC1 +   |    |ADSR cnt+|     |     |        |    |                |
+|wave sel.|    |env. log.|     |     |        |    |                |
+-----------    -----------     |     |        |    |                |
+$d400-03,      $d405-06,    $d417.0  |        |    |                |
+$d404.[1-7]    $d404.0               |        |    |     FILTER     |
+                                     |        |    |                |
+                                 =0  |        |    |                |
+-----------    -----------     >o----|------->|    |                |
+|wave D/A |--->|env. D/A |-->o/      |        |    |                |
+-----------    -----------      o--->|        |    |                |
+     ^              ^          ^ =1  |        |    |                |
+     |12bit         |8bit      |     |        |    |                |
+     |              |          |     |        |    |                |
+-----------    -----------     |     |        |    |                |
+|OSC2 +   |    |ADSR cnt+|     |     |        |    |                |
+|wave sel.|    |env. log.|     |     |        |    |                |
+-----------    -----------     |     |        |    |                |
+$d407-0a,      $d40c-0d,    $d417.1  |        |    |                |
+$d40b.[1-7]    $d40b.0               |        |    | LP   BP   HP   |
+                                     |     =0 |    ------------------
+                                 =0  |    >o->|       |    |    |
+-----------    -----------     >o----|--o/    |   *** o    o    o
+|wave D/A |--->|env. D/A |-->o/      |     o- |      /    /    /
+-----------    -----------      o--->|  ^  =1 |   =0 V    V    V   =1
+     ^              ^          ^ =1  |  |     |      o o  o o  o o
+     |12bit         |8bit      |     |  |     |      | |  | |  | |
+     |              |          |     |$d418.7 |<-------o    |    |
+-----------    -----------     |     |        |<------------o    |
+|OSC3 +   |    |ADSR cnt+|     |     |        |<-----------------o
+|wave sel.|    |env. log.|     |     |        |
+-----------    -----------     |     |        |
+$d40e-11,      $d413-14,    $d417.2  |        |
+$d412.[1-7]    $d412.0               |        |    -----------------
+                                     |        |    | Master volume |AUDIO
+                                 =0  |        o--->|     D/A       |----->
+                               >o----|------->|    ----------------- OUT
+EXT IN --------------------->o/      |                     ^
+                                o--->|                     |4bit
+                               ^ =1           ^            |
+                               |              |       $d418.[0-3]
+                            $d417.3  ^        |
+                                     |        |
+                    Analog mixing ---|--------|
+***: Filter type select switches, $d418.[4-6] respectively
+$d418 digis
+-----------
+The most common method of playing a digi is to use the register at $d418.
+When someone plays a digi using the master volume register, the situation is
+similar to the waveform D/A converters. Both D/As are multiplying D/As --
+signal amplifiers whose amplification is proportional to the input digital
+number. If there is a nonzero signal offset on the D/A input it will be
+multiplied proportionally by this number.
+Playing digis with $d418 is possible because there is indeed a relatively
+large DC voltage offset on the master volume D/A. This offset is present
+right from the moment when the SID is powered up.
+Where can this DC offset come from?
+There is a mixer before the master volume D/A (see figure). If there's a DC
+offset on the D/A input, it must come from there. ...And going further,
+the DC offset on the mixer must also come from somewhere.  But where?
+Signals come from the three ADSR volume D/As, the EXTIN line, and the three
+outputs of the filter. Fortunately, all paths that go to the mixer have analog
+switches (all paths can be disconnected from the mixer individually, if that's
+needed).
+The above analog switches are driven by the filter selection bits ($d417 bits
+-3), the voice 3 off bit ($d418 bit 7) and the filter type selection bits
+($d418 bits 4-6).
+After a reset, the filter selector bits are all 0 (all signals are routed
+towards the master mixer), the 'voice 3 off' switch is on, and the filter type
+selector bits are 0 (filter outputs are unconnected). In this state, only
+EXTIN and the three SID voice signals are present on the mixer. EXTIN can
+be eliminated as the source since it has no DC offset (as long as the computer
+was not hacked, see notes on the 8580).
+The ADSR volume D/A is similar to the previously mentioned multiplying D/As.
+If the digital number on the input is 0, the input analog signal offset can't
+pass through (as measurements verify). This is the case when SID is reset,
+setting the envelope counters to zero.  Therefore, nothing behind the ADSR
+multiplying D/As can have any effect on the DC offset of the mixer.
+So, the DC offset must come from the ADSR multiplying D/As. Another
+measurement shows that even the mixer itself has a small DC offset.
+Tests and results
+-----------------
+I did some tests that support this theory. They were done 'by hand', by simply
+using a digital voltmeter + the FC3 monitor.
+The chip was a 6581(R1), 0883, Hong Kong (an early 6581).
+When turned on the voltage on the AUDIO OUT was about 5.5 volts (slowly
+decreasing as it warmed up, stopping at about 5.43 after some 10 mins - all
+subsequent tests were done after this time period).
+Writing $0f to $d418 raised the output voltage to 6.15 volts. Therefore, the
+maximum output amplitude that can be achieved when playing digis is 0.72 volts
+in this 'mode' (without wiggling any other SID settings to achieve higher
+voltage levels) -- remember that what counts is the maximum voltage
+_difference_, not the maximum absolute voltage.
+The next test is to determine if the mixer has its own DC offset (with all
+possible paths are disconnected). It's possible to do. With the volume at
+maximum (to maximize any effect), all voices are routed towards the filter
+($d417 = $0f), while making sure that the filter outputs are not routed to the
+mixer ($d418 = $0f). In this state no paths can drive the mixer. The result
+is 5.39 volts. When the volume changes, the output also changes towards the
+previous 5.43 volts --> there is a (very small) DC offset from just the mixer.
+What could be the DC offset value of each individual SID voice (i.e. the base
+level difference of the multiplying D/As)?  Doing the above, but leaving one
+voice routed to the mixer ($d417 = $0e, $0d or $0b) gives 5.69 volts.
+.69-5.43 = 0.26 volts, and 5.43 + 3*0.26 = 6.21, almost 6.15 volts.
+To determine if the ADSR multiplying D/As act as expected, I used pulse
+waves with zero frequency and 0 or $fff pulse width (two cases), to make the
+input signal of the ADSR multiplying D/A the minimum and maximum possible
+level. After careful checking, the output changed a few hundredth volts
+(about 0.01 volt per voice).  So the D/A doesn't close up completely, but
+it's still O.K.
+To prove that these offsets are equal for all voices, I did another test. Some
+people know that the filter inverts phase (multiplies the input signal by -1).
+Machine is reset, $d417 = $01, $d418 = $9f. (Voice 1 is routed through the
+filter, voice 3 is cut off from the mixer completely ($d418.7), low pass
+filter is selected, volume = $0f). The output voltage was 5.41 volts, just
+very slightly below the "default" output level. This means that the DC of
+voice2 + (-1*) DC of voice 1 resulted in about 0 relative offset. Doing
+similar tests proved that the DC offsets for the voices match each other
+almost exactly (within a few hundredths of a volt).
+These measurements all support the idea that the DC offset comes from the
+ADSR multiplying D/As, that the offset is mostly independent from the waveform
+D/A converters (as long as sustain levels are 0), and that the offsets are
+equal for all voices. In addition, a small DC offset is supplied by the master
+signal mixer itself.
+What if we try different sustain settings? For this test, set the volume to
+maximum, as usual. Set the sustain level to $0f for all voices ($d406, $d40d,
+$d414 = $f0). Start the attack, but with no waveform selected ($d404, $d40b,
+$d412 = 01). The output level is now 5.21 volts, a little bit below the '0'
+offset of the audio output! (Doing the test with just one voice (all
+others disconnected), the output is 5.29 volts).
+Finally, we can do some experiments with the pulse waveform.  The pulse
+waveform is useful for these tests, since at zero frequency we can set both
+the minimum and the maximum constant DC levels at the voice D/A just by using
+the pulse width registers. Reset the computer. Set voice 1 to zero frequency,
+pulse level $0fff, sustain level 15, and $d404=$41 (pulse waveform + gate on).
+Route only voice 1 through the mixer ($d417 = $0e). The output voltage is
+similar to the test when no waveform was selected -- 5.29 volts! This seems to
+show that "waveform accu = $0fff" is the same as when no waveform is selected
+(i.e. the waveform D/A digital input pins are pulled high when they're not
+driven, as seen in most other NMOS chips).
+When the pulse width is 0 in the above test the output changes to 6.34 volts.
+This seems to be strange (a multiplying D/A giving higher signal level for
+multiplying something by 0).
+Now, when the ADSR multiplying D/A is closed, the output is 5.70 volts. When
+it's fully open, the output changes from 5.29 volts (wave acc= $fff) to 6.34
+volts (wave acc = 0). One reasonable answer is that the base voltage of the
+waveform D/A is higher, and the analog input is tied lower than the base
+voltage of the ADSR D/A -- the effect is that the SID waveforms will lie
+'around' the ADSR multiplying D/A base voltage, more or less symmetrically.
+This was surely done intentionally, to reduce absolute voltage levels (for
+linearity).  In the 6581, the big DC offset is probably a result of having the
+ADSR D/As and the master volume D/A at different base levels (the difference
+appears as true DC offset on the master volume D/A). If both were the same
+(presumably at VDD/2), and the waveform D/A parameters were selected similarly
+(operation is symmetric to VDD/2), there would be no final DC offset at all.
+Rather like the 8580...
+Other issues
+------------
+So now we know why $d418 digis are possible - but still, there are some things
+to note.
+The DC offset on the master volume D/A changes with different SID settings,
+and whatever affects the DC offset on the mixer will affect the digi
+volume. For example, even the filter output signals have a small DC offset.
+Just do a test - set the volume to 0f, then simply turn one filter route on
+(for example, $d418 = $1f). You'll hear a small click (i.e. a small DC offset
+change on the mixer), even if the filter has no input.
+Moreover, as seen above, the DC offset can be eliminated completely (just by
+SID register settings), leading to no audible digi sound at the output.  In
+other words, whatever affects the DC offset on the mixer _will_ affect the
+digi volume.
+One place where this is important is playing a digi with a tune: there's a
+constantly changing signal going to the mixer instead of a constant DC offset,
+so playing a digi on the master volume also causes distortion for both the SID
+voices and the digi sound (since they're cross modulated). To reduce this
+effect most 3+1 like SID + digi players play samples by writing 8-offset sample
+values to $d418 (ie. adding 8 to 3-bit sample values and writing this to $d418
+- see players used by Jeroen Tel and other famous composers using digi). This
+trick reduces the modulating effect while still maintaining good digi volume.
+The DC offsets used to create awful clicking sometimes. For example, the
+filter inverts phase. If the filter is currently routed to the mixer, there'll
+be a large 'click' (2 times the DC offset) when a voice is on and its routing
+is changed to or from the filter.
+The 8580
+--------
+This is a completely redesigned chip. I don't know details, but it was
+probably redesigned by the time all other chips in the C64 were done for CSGs
+new manufacturing technology and the C64c. It is a 'better' chip from the
+technical side (but in my opinion it sounds crude in comparison to the 6581,
+at least the R4 series). The 6581 was designed in months. Bob Yannes had to do
+everything from scratch and use the manufacturing technology MOS currently had
+(NMOS). And it shows.  First, it has high background noise. The DC offsets are
+really also a misfeature. The D/A converters are sometimes non-monotonic (at
+least, the waveform D/As and the filter cutoff D/A have some drops at the
+change of the most significant bits). The op-amps in the active (resonant)
+filter are simple, linearized NMOS inverters ;-) (loopbacked, they act like
+more or less linear op-amplifiers around VDD/2). And I still haven't mentioned
+bugs in the digital side (ADSR envelope bugs). Because of the above, one
+probably won't find two identical 6581 chips -- each sounds a little bit
+different (mostly due to the filter). Since the active components of the
+filter are far from ideal, the filter is strongly nonlinear (the cutoff curve
+changes with signal amplitude). On the other hand, these things are what make
+the SID sound so unique.
+Most of the problems were fixed in the 8580. It has much less background
+noise. The chips sound the same (there are hardly any differences between
+different 8580s). Most of the DC offset issues (the clicks) were elminated. It
+needs less power, and lower VDD level. Something was changed also in the
+digital logic, but the ADSR part was not touched. The 'combined' waveforms are
+a bit different (and more useable from the musician's point of view).
+The clicks were reduced, which means that there is no (or no significant) DC
+offset on the master volume D/A in the 8580.
+(I have not done any measurements, but after listening to a lot of 3+1 channel
+type musics, I have a strong suspicion that even if sounds are turned on, the
+average DC offset on the master volume D/A is still minimal).
+To fix this in software, you'll have to wait until the next section of this
+article.
+To fix this in hardware, people use a simple hack: take a resistor of about
+k and tie the SID EXTIN line to GND through that (directly, beside the
+chip, on the mainboard).
+The EXTIN line goes directly to the mixer, and thus the master volume D/A, or
+can also be routed through the filter. In either case, unless the filter is
+disconnected, the above hack will give a pretty large DC offset, similar to
+the original 6581s. So, digi sounds can be played :-) (even with SID music
+playing simultaneously, similar to the 6581).
+This solution is good as a work around, but there's one thing to note: this is
+not completely the same as the 6581 ADSR D/A offset voltage. At least, this
+offset is negative (should that pin rather be tied to VDD?). Programs that
+depend on the 6581s way of DC offsets will not work correctly (but I know of
+very few such programs, so at worst you'll experience slightly different digi
+sound only occasionally -- but hey, the 8580 sounds different anyway). Another
+problem is that when EXTIN is routed through the filter the DC offset may
+cause strong distortion since the DC operating point of the filter is changed
+-- bad news if the 'semi-linear' amplifiers in the filter are picky about
+absolute DC level.  Some music (not neccessarily involved with digis) indeed
+do route EXTIN through the filter, for noise reduction on older C64s (with the
+earlier C64 mainboards that pick up lots of 'digital' background noise from
+EXTIN). DC distortion can also occur occasionally for the same reason but on
+the master volume D/A (the higher the difference from VDD/2, the greater the
+risk of experiencing nonlinearity and clipping distortion).
+Some final words
+----------------
+A lot of this information comes from Dag Lem, who is certainly the No. 1 SID
+hacker for me ;-). Take a look at reSID, his SID emulator library (the sources
+can be downloaded from somewhere). reSID contains so much reverse engineered
+information of the real SID that you won't believe it -- check it out if
+you're interested.
+=============
+D418 Playback -- Software
+=============
+$D418 digis are by far the most common playback method.  The volume register
+gives 16 different amplitudes (0-15), and so can provide 4-bit digi playback.
+In its most basic form, this is an extremely easy routine to code.  Simply
+load each 4-bit sample, and store it in the volume register ($d418).
+Assuming $fd/$fe are pointing to the beginning of a series of samples, the
+following code will play it back:
+	 ldy #0
+:loop	 lda ($fd),y
+	 sta $d418
+	 ldx #5 ;some delay value
+:delay	 dex
+	 bne :delay
+	 iny
+	 bne :loop
+	 inc $fe
+	 jmp :loop
+The ldx #5 would have to be adjusted depending on the speed of the
+sample - the lower this number (not including zero) the faster the
+sample will play back.
+There are a number of improvements we could make to this code - first
+of all, this method takes twice as much RAM to store the sample as is
+necessary.  Because we're dealing with 4-bit samples, we can store 2
+samples in each byte.  This can be handled simply by alternately
+masking out the high bits (with AND #15) to play the sample stored in
+the low nybble, and by shifting the high nybble down to the low nybble
+to play the high nybble (LSR : LSR : LSR : LSR).  A lookup table may also
+be used to save processor cycles (but use more RAM).
+Another improvement is to move the routine to zero-page, and use self-
+modifying code.  In general, this results in the fastest digi players.
+We should of course have the routine check for the end of the sample --
+typically just checking the high byte of the zero-page pointer is enough
+(in this case, checking $fe).  Typically digis are page aligned anyway, so
+just zeroing out the unused part (if any) of the last page is fine.
+Finally, it is often important that each sample of a digi is played back
+at regular intervals.  If the samples aren't played at a steady speed,
+extra distortion is audible.  In the example above, playback is steady
+for a full page (256) of samples - but several extra cycles are added
+by incrementing the zero-page pointer to the digi.  The situation
+worsens when we start adding extra code to check for the end of the
+digi, and even the main loop starts getting irregular when we add the
+code for the simple form of packing discussed earlier (2 4-bit samples
+per byte).
+These problems can be solved by careful cycle counting and adding NOP
+and harmless BIT instructions in strategic places to make each
+iteration the same number of cycles, regardless of which branch is
+taken - people who have written a stable raster routine, or done some
+Atari 2600 coding have likely done this sort of painstaking work
+before.
+NMI-driven digis
+----------------
+More commonly, however, we enlist the help of CIA #2 and have it
+generate regular Non-Maskable Interrupts which we use to call our digi
+player.  This has two important advantages - first, it makes timing
+much more simple.  Second, it frees your main program to do other
+things while the digi is playing "in the background".
+To experiment, I pulled a 4-bit packed digi from the extras disk
+included with Super Snapshot 5.22.  It's the beginning seconds of the
+introduction to Classic Star Trek (Space, the Final Frontier).
+Here's the source for a fairly "frills-free" NMI based digi player,
+with my comments after blocks of code:
+start    = $1400
+end      = $7cff
+freq     = 141
+ptr      = $fd
+Labels start and end simply point to the beginning and end of the
+digi.  Freq isn't actually the frequency - it's the number of
+processor cycles between interrupts necessary to play the digi at the
+desired speed/pitch.  If you know the frequency (in hz) of the digi,
+simply divide your CIA clock speed (approximately 1000000 hz) by the
+digi frequency.  In this case, the digi runs at approximately 7100 hz.
+We use two zero page locations to form a 16-bit pointer to the current
+sample in the digi to play.
+         *= $1000
+         ;disable interrupts
+         lda #$7f
+         sta $dc0d
+         sta $dd0d
+         lda $dc0d
+         lda $dd0d
+         sei
+This code simply disables interrupts and initializes both CIA timers.
+         ;blank screen
+         lda $d011
+         and #255-16
+         sta $d011
+Just like erratically timed code can introduce distortion when a digi is
+played back, the VIC steals cycles from the processor that can cause
+interrupts to not occur precisely when you'd like them to.  This routine will
+work without the screen blanked, but the extra noise introduced when the
+screen is on is noticeable when the time between samples is less than around
+.5-3 times the time the processor is stopped.  Another option is to use some
+multiple of the raster timing as the sampling rate, and start the routine on a
+non-badline, to ensure that the interrupts never occur on a badline.  (A final
+option is to use a raster-driven interrupt for the digi; with the SCPU, it is
+actually possible to drive an IFLI display and play a digi at the same time,
+badlines and all -- email Robin for more info, or maybe wait for a future
+article!).  But the simplest thing to do is to blank the screen :).
+         ;switch out roms
+         lda #$35
+         sta 1
+         ;point to our player routine
+         lda #<nmi
+         sta $fffa
+         lda #>nmi
+         sta $fffb
+Unless using the KERNAL routines is necessary in my program, I always
+switch out the ROMs.  One of the biggest benefits is that our NMI
+routine will be immediately called, rather than using $0318/$0319 and
+waiting for the KERNAL to indirectly call your routine.
+         ;initialize player
+         lda #<start
+         sta ptr
+         lda #>start
+         sta ptr+1
+         ldy #0
+         sty flag
+         lda (ptr),y
+         sta sample
+This section simply initializes the various memory locations that the
+player uses - sets ptr/ptr+1 to point to the beginning of the digi,
+loads the first sample, and clears the flag that handles the
+alternating between the lower and upper nybble of the packed samples.
+         ;setup CIA #2
+         lda #<freq
+         sta $dd04
+         lda #>freq
+         sta $dd05
+Sets Timer A on CIA #2 to freq.
+         lda #%10000001
+         sta $dd0d
+Enables Timer A interrupts on CIA #2.
+         lda #%00010001
+         sta $dd0e
+Sets Timer A to run in continuous mode.  As soon as Timer A counts
+down to zero, it will automatically be reloaded to the last writes to
+$dd04/$dd05 and begin counting down again.
+endless  jmp endless
+For this example, we just put the computer in an endless loop.
+nmi
+         pha
+         txa
+         pha
+         tya
+         pha
+         ;play 4-bit sample
+         lda sample
+         and #15
+         sta $d418
+We play the sample while all the code is still linear - before any
+branches have occurred.  This is to minimize the distorting effects I
+mentioned earlier.  The AND #15 is used so we don't inadvertently
+enable the filter bits in $d418 with the high nybble packed into
+sample.
+         ;clear NMI source
+         lda $dd0d
+By reading $dd0d, we are acknowledging the source of the interrupt,
+and the CIA will now generate another interrupt next time Timer A
+counts down to zero.
+         ;just something to look at
+         inc $d020
+         ;every other NMI do 1) or 2):
+         lda flag
+         bne lower
+Now we deal with "unpacking" the samples.
+         ;1) shift upper nybble down
+upper    lda sample
+         lsr a
+         lsr a
+         lsr a
+         lsr a
+         sta sample
+         jmp exit
+When flag is set to zero, we shift the high nybble of sample down to
+the low nybble so it's ready to be played next NMI.
+         ;2) get a new packed sample
+         ;   then point to next
+lower    ldy #0
+         lda (ptr),y
+         sta sample
+         inc ptr
+         bne checkend
+         inc ptr+1
+When flag is set to one, we load a new packed sample into sample, and
+point ptr at the next packed sample.
+         ;if end of sample, point to
+         ;beginning again
+checkend lda ptr
+         cmp #<end
+         bne exit
+         lda ptr+1
+         cmp #>end
+         bne exit
+         lda #<start
+         sta ptr
+         lda #>start
+         sta ptr+1
+Simply check for the end of the digi, and if we've reached it, loop
+back to the beginning of the digi.
+         ;toggle flag and exit NMI
+exit     lda flag
+         eor #1
+         sta flag
+         pla
+         tay
+         pla
+         tax
+         pla
+         rti
+         ;sample's lower nybble holds
+         ;the 4-bit sample to played
+         ;next NMI - the upper nybble
+         ;holds the next nybble to be
+         ;played on "odd" NMIs, and is
+         ;undefined on "even" NMIs.
+sample   .byte 0
+         ;flag simply toggles between 0
+         ;and 1 - used to decide whether
+         ;to play upper or lower nybble
+flag     .byte 0
+Improving D418 Digis
+--------------------
+D418 digis tend to generate a lot of noise, because, of course, the 4-bit
+sample resolution.  Over the years people have come up with numerous tricks to
+improve the sound of a d418 digi; here are some that we know of and have tried.
+The first, and most obvious, thing to do is to use the low-pass filter, since
+a lot of the noise is at higher frequencies.  Unfortunately this won't work,
+since the filters occur in SID before the volume amplifier -- all the filters
+can do is change the DC offset that makes the digi possible.  This trick
+will work for methods that use SID voices, however (such as Pulse Width
+Modulation, discussed in the next section).
+Another trick is to "dither" the sound, as discussed in C=Hacking #11.  The
+idea here is to generate an intermediate "average" value by toggling between
+two values.  For example, if d418 is set to '8' half of the time, and '9' the
+other half, its 'average' value will be 8.5.  So this is somewhat like adding
+an extra bit of resolution.  In principle, you can extend this further: if it
+is '8' one-third of the time and '9' for the remaining two-thirds, the average
+value will be 8.66.  And so on.
+Now, we aren't _really_ increasing the sample resolution here, but are instead
+increasing the sample playback rate -- we're playing two samples ('8' and '9'
+for example) where before we played just one.  Don't get too carried away
+thinking about "average" voltage levels (after all, there is an average
+voltage for the entire digi but that's not what you hear!) -- what's important
+is how well the sampled signal represents the original signal.  If the
+original signal is rising from 8 to 9 during the sample interval, this type
+of trick will work well.
+Which leads us to another trick: interpolation.  This is really a compression
+trick, more than a 'resolution' trick.  Let's say that one sample value is 5,
+and the next value is 9.  It might be reasonable to expect an 'intermediate'
+value of 7, to play right after the 5.  Once again, the idea is to increase
+the playback rate to better-represent the original signal.  This type of trick
+increases the playback rate without increasing the amount of data -- and as
+always, your mileage may vary.  Many modern soundcards and CD-players use
+interpolation.
+Another curious trick is to add noise to the signal -- that is, the 4-bit
+sample corresponds to the original signal plus noise.  Sometimes, by adding
+noise to the signal playback the noise can actually cancel!  The 'dithering'
+trick above can be viewed in this way.
+Boosting 8580 Digis
+-------------------
+As most people know, there are 'old' SIDs (6581) and 'new' SIDs (8580), and
+$d418 digis do not work right on 8580 SIDs, (such as in the 128D, most 128s,
+and the 64C) for the reasons discussed earlier -- the 8580 does not have a
+residual voltage leading into the amplitude modulator.
+The software fix for this is pretty simple: have SID generate a signal, and
+hence a voltage, for the volume register to modify.  You can actually use
+pretty much any waveform to do this, but a pulse is the simplest, since a
+pulse wave just toggles between two voltage levels.  Moreover, page 463 of
+the PRG says, "The TEST bit, when set to a one, resets and locks Oscillator 1
+at zero until the TEST bit is cleared.  The Noise waveform output of
+Oscillator 1 is also reset and the Pulse waveform output is held at a DC
+level."  So it's not really necessary to worry about the frequency or pulse
+width, by using the test bit.
+BUT -- it is very important to set the sustain level to $f.  The ASDR envelope
+generators generate the voltage.  A sustain level of 0 gives no improvement.
+So, to 'boost' a digi on a later-model SID, you can just turn on a pulse with
+the test bit set:
+	LDA #$FF
+	STA $D406
+	LDA #$49
+	STA $D404
+Setting more voices gives the digi a substantial extra boost:
+	LDA #$FF
+	STA $D406
+	STA $D406+7
+	STA $D406+14
+	LDA #$49
+	STA $D404
+	STA $D404+7
+	STA $D404+14
+The moral is: if you're writing a digi routine, and want it to work on all
+computers, be sure to boost the digi.
+And for completeness, using more channels is a commonly used trick to enhance
+digi resolution on the Plus/4. The TED digi resolution (the volume register)
+is 3 bits.  Fortunately, all channel on/off bits + the volume level are in the
+same register ($ff11). If one source is on, the output DC is about half of the
+level when both are turned on. This trick can be extended further to results
+in a 'semi 4-bit' or 5-bit digi table (the dynamic range is enhanced, but
+there are larger steps at the table end than at the start).  This trick could
+also be used in SID if the sound sources were accurately preset, but runs into
+problems due to the non-matching SID-versions and having the control bits in
+multiple registers.
+SID Type Auto-Detect
+--------------------
+The following routine will detect what type of SID is in use.  I've
+tested it on a fair cross-section of my collection of computers - my
+NTSC 128D, two 64Cs, two "breadbox" C-64s, and my PAL breadbox 64.  In
+all cases the code performed 100% accurately - but still, there may be
+cases where it fails.  I'd be interested to know if anyone finds any
+faults in the routine, so I can improve it!
+How does the routine work?  I was told that the old SID (6581) and the
+new SID (8580) behave differently when set to play combined
+waveforms.  I coded a fairly simple routine to use the REU to sample
+$d41b (the upper 8 bits of Oscillator 3's waveform output) for a full
+k bank.  Then I experimented with various frequencies and
+combinations of waveforms on Oscillator 3 until I found consistently
+different results with the two different SIDs.
+When I combined the triangle and sawtooth waveforms and then sampled
+$d41b I found that most of the time the oscillator was just putting
+out zeros, with occasional bursts of numbers.  These "bursts" were
+consistently near $ff on the 8580, while the 6581 was always well
+below $80 - often $3f was the highest it would get.
+So, the detection code ended up being quite simple - I'll explain each
+block of code:
+         *= $4000
+start    sei
+         lda #11
+         sta $d011
+Disable bad-lines (by blanking the screen).  This prevents badlines
+from interfering with the detection process.
+         ;sid setup here!
+         lda #$20
+         sta $d40e
+         sta $d40f
+Set Oscillator 3's Frequency Control to $2020.  I just randomly chose
+this value when experimenting, and it worked, so I kept it.  The trick
+here is to set a value fast enough that the oscillator will make a
+number of cycles (so we can get a good sample of the values coming
+out) but not so fast that it might miss any of the "bursts" I was
+mentioning earlier.
+         lda #%00110001
+         sta $d412
+Combine the triangle and sawtooth waveforms and start the ADSR cycle.
+         ldx #0
+         stx high
+loop     lda $d41b
+         cmp high
+         bcc ahead
+         sta high
+ahead    dex
+         bne loop
+This loop takes 256 samples of Oscillator 3's output, saving the
+highest value in location high.
+         lda #%00110000
+         sta $d412
+Stop Oscillator 3.
+         cli
+         lda #27
+         sta $d011
+Turn the screen back on.
+         lda high
+         rts
+high     .byte 0
+Return from the routine with the highest value sampled from Oscillator
+in the accumulator.  This allows you to branch based on the high
+bit:
+	   bmi SID8580
+	   bpl SID6581
+Voila!
+======================
+Pulse Width Modulation
+======================
+	The primary limitation of using the volume register is, of course,
+that it is only 4-bits.  Pulse width modulation (PWM) allows us to get
+around that limitation.
+	In general, there are lots of ways of transmitting information.
+If you've ever used a radio you've encountered both amplitude modulation,
+where the signal is encoded as the amplitude of some carrier wave, and
+frequency modulation, where the signal is encoded by changing the frequency
+of the carrier wave.  In both cases, the idea is to strip out the encoded
+information and throw away the carrier.
+	Yet another possibility is pulse width modulation: use a pulse
+wave at some carrier frequency, and modulate the pulse width.  Pulse width
+modulation has several nice properties for transmitting signals; we can
+take advantage of it to play digis.
+	Pulse waves, of course, take on only two possible values: zero and
+one (low and high, etc.).  Over a single period, a pulse wave will in general
+be low for some amount of time and then high for some amount of time.
+The _duty cycle_ of a pulse wave is the amount of time it spends in the high
+state compared to the total period.  For example, a square wave, which is
+low exactly half the time and high the other half, has a duty cycle of 50%:
+	      ______	______
+	      |	   |    |    |
+	      |    |    |    |
+	 _____|    |____|    |____ ...
+Remember that, regarding SID, a signal like the above is simply a voltage
+level.  What is the _average_ voltage over a single period?  Since a square
+wave is zero half the time and one the other half the average value is
+just 1/2.  If instead the pulse had a duty cycle of 75%, it would be low
+for 1/4 the cycle and high for 3/4, giving an average value of 3/4.
+So the _average_ value of a single pulse is simply the duty cycle.  So if
+we change the duty cycle for each pulse we can essentially generate a
+series of average voltage values -- and since a digi is nothing more than
+a series of average signal values, we can use PWM to play a digi.
+To make this more precise, let's say we had a digi sampled at 1KHz -- one
+thousand samples per second.  Since each sample value will be approximated
+by a pulse, we need one thousand pulses per second.  The duty cycle of
+the first pulse will be the first sample value, the duty cycle of the
+second pulse will be the second sample value, and so on.  Note that
+the sample rate is the carrier frequency -- the frequency of the modulated
+pulse train, 1KHz in this case.
+(Actually, to be more accurate, we need _at least_ 1000 pulses per second --
+for example, we could use 2000 pulses per second, and represent each sample
+value using two pulses.  So the more correct statement is that the pulse
+carrier frequency is the maximum sample playback frequency.).
+The advantage for playing C64 digis is that we have much more resolution
+for the pulse width, and probably not in the way you think!  Because you
+are probably thinking that SID has this nice 12-bit pulse width that
+we can use here.  The problem is that the absolute highest frequency SID
+can produce, using the frequency registers, is about 4KHz, which would
+be the maximum playback rate.
+There's still another catch -- the carrier wave is still there!  Imagine
+trying to encode a signal that was constant, say 1/2 everywhere.  To
+generate a "digi" value of 1/2, you'd use a square wave, half down and
+half up.  So while the _average_ value of each pulse would be 1/2, the
+actual signal would be a square wave at the carrier frequency (look at
+the little picture above if you don't see it -- its average value is 1/2).
+Trying to modulate a 4KHz carrier wave results in a piercing 4KHz tone,
+and a _maximum_ sample rate of 4KHz (and this assumes that you can sync your
+code up exactly with SID).  So that's pretty worthless for digis.
+			- BUT -
+What if we could change the voltage level manually?  Let's say some
+hypothetical machine language program toggled the voltage level
+on each machine cycle -- the result would be a square wave of
+frequency 0.5 _mega_ hertz.  Okay, let's say it changed the voltage
+level every 10 machine cycles -- the result would be a carrier
+frequency of around 50 KHz.  The point here is that a machine language
+program can generate its own pulse waveform, and do so at much higher
+frequencies than SID can produce.
+Toggling the voltage levels turns out to be very simple.  As was
+described earlier, the way to "boost" digis on later SIDs is to use
+a pulse waveform at frequency zero.  Depending on the value of the
+pulse width register, SID will set the output voltage to either high
+or low.  So all a program has to do is set up a pulse waveform at zero
+frequency and use the pulse width registers to toggle the voltage --
+set $d403 to either $00 or $ff to toggle low/high.  (You could also use
+$d418 to toggle low/hi, but this method should produce more uniform
+results, and unlike $d418 can be filtered).
+So now we're cooking -- we've got a program that can generate a pulse
+train.  The next step is to change the width of each pulse to represent
+the sample values in our digi.  Remember that the duty cycle -- the
+percentage of time the pulse spends high -- is the average value for that
+pulse.  But also remember that each digi sample represets an average
+value over the sample period.  If the pulse period is equal to the sample
+period, then _the duty cycle is exactly the sample value_!
+Example: let's say that we have an 8-bit sampled digi, so that values go
+from 0-255, and our program generates pulses with a period of 256 "ticks".
+Now pick a sample value, say 56.  All the program has to do is hold the
+pulse high for 56 "ticks", and low for the remaining 255-56 = 199 "ticks",
+and it will have the correct average value: 56/256.  So a program to play
+-bit samples might look like
+- Load .X with next sample value
+- Load .Y with 256-.X
+- Set pulse high
+- Loop for .X iterations (each loop iteration is one "tick")
+- Set pulse low
+- Loop for .Y iterations
+- Loop back to step 1
+Let's say that each "tick" takes m cycles, and the sample size is 2^n, so
+that there are 2^n ticks per sample.  A stock machine runs at around
+^6 cycles/second, so...
+	(10^6 cycles/second) / (2^n ticks/sample * m cycles/tick)
+	= 10^6 cycles/second / (m * 2^n cycles/sample)
+	= 10^6 / (m * 2^n) samples/second
+So, for example, let's say we had n=6-bit samples -- 2^6 = 64 -- and could
+generate pulses with a resolution of one machine cycle -- m=1.  Then
+we could play that 6-bit sample at 10^6/64 = 15.6KHz.  That is _really
+very good_!  In principle -- possibly using the CIA timers, possibly using
+fixed delay loops, possibly using a massively unrolled loop -- this can
+be done on a stock machine.  (I did try using the CIA timers, but the
+number of cycles to set up the timers was too big, and made it sound poor;
+I've included the code below though.)
+At this point it becomes a numbers game.  As we increase the sample size
+(increase m or n above), we _decrease_ the sampling rate -- if, in the
+above example, we instead use 8-bit samples, the sampling frequency drops
+by a factor of four to around 4 KHz.  So there's a tradeoff between
+resolution and sampling frequency.
+AND... we still have this issue of the carrier frequency.  You should be
+able to convince yourself that the sampling frequency above is exactly
+the carrier frequency.  So with the 8-bit resolution example there
+would be an awful 4KHz tone running through the playback.  There are
+only two ways to beat the carrier frequency: push it high enough that
+you no longer hear it, or else push it high enough that you can use the
+filters to dampen it down.
+How high is high enough?  You can judge for yourself, but 15 KHz is
+pretty tough to hear, unless you have good ears and the volume is really
+loud -- so 6-bit samples are within reach on a stock machine.
+But add a SuperCPU into the picture, and the numbers get _really_ nice.
+Everyone knows that a SCPU can interact with the C64 at 1MHz, and
+hence generate pulses with 1MHz resolution, using code like
+	lda #$ff
+	sta $d403	;Set level high
+:loop	lda $d011	;wait for C64 cycle
+	dex
+	bne :loop
+where .X contains the sample value.  But what happens if we try to move
+beyond that 1MHz?  What if we put some NOPs into the above delay loop,
+in place of the lda $d011?  Well, in principle it means that the duty
+cycles won't always be right, which corresponds to some sampling error.
+In practice, however, it works _really well_!  Consider what happens when
+the above code is changed to:
+:loop
+	nop
+	nop
+	dex
+	bne :loop
+The earlier formula still applies, but now using 20MHz cycles:
+* 10^6 / (m * 2^n) samples/second
+In this example each loop iteration -- each "tick" -- is nine 20MHz cycles,
+giving a playback rate of approximately 17Khz for 7-bit samples.  Which
+is TOTALLY COOL!
+And it can even be pushed to 8-bit samples (although I personally don't think
+they sound any better, at least with the code I've tried; maybe the code can
+be improved).  Using loops like
+:loop
+     dex
+     beq :done
+     dex
+     beq :done
+     ...
+     dex
+     bne :loop
+:done
+it is possible to "fine-tune" the loop tick to somewhere between 4-5 cycles,
+giving a playback rate between 15KHz and 19KHz, for an 8-bit sample.  Pretty
+cool.  The code is also a little more involved (with 7-bit samples we can
+use BMI for the loop branches; not so with 8-bits).  But it really is
+possible to play 8-bit samples at 19KHz on a C64 (plus SuperCPU).
+Using two voices
+----------------
+You may be thinking, Hey, we've got three pulse waves to work with, can
+we improve the performance by using multiple pulses?
+Let's say we have two pulses, P1 and P2, with the same period.  When both
+are activated, the pulses simply add together -- that is, the total voltage
+is just the sum of the individual voltages, and therefore the _average_
+voltage is the sum of the individual pulse averages:
+	avg voltage = D1 + D2
+where D1 and D2 are the duty cycles of pulses P1 and P2.  In the simplest
+case, this gives us an extra bit of resolution -- if D1 and D2 are both
+-bit values, say, then D1+D2 is an 8-bit value.
+-BUT-
+Consider, for a moment, what would happen if we were to change the amplitude
+of the second pulse -- that is, let's say the maximum voltage it took on
+was 1/16 of the maximum voltage of the first pulse.  The average voltage
+would then be
+	avg = D1 + D2/16
+This then gives us _four_ extra bits of resolution, with each bit to the
+_right_ of the decimal place.  For example, if D1 and D2 are 4-bit numbers,
+with D1=xxxx and D2=yyyy, then the avg will be a number like xxxx.yyyy
+(four bits to the left of the decimal place and four to the right).
+Of course, we can change the pulse amplitude by changing the sustain
+setting, so in principle this gives a very easy and efficient way of
+playing high-resolution digis.  In practice, I have not been able to
+make it work very well.  I used a sustain setting of 1 and split an
+-bit sample into two 4-bit pulses; I believe the result sounds better
+than 4-bits, but certainly doesn't sound anywhere near 8-bits.  My
+suspicion is that it is because the second pulse voltage is not really
+/16 of the first pulse, which corresponds once again to adding noise
+to the sample value.
+To find out, we can just measure the output at different sustain levels.
+The following table gives the voltage output for voice 1 using a pulse
+waveform at zero frequency and volume 15:
+    Pulse Width      Diff
+SU  000    fff	  000	fff
+f  6.34   5.29   .08	.07
+e  6.26   5.36   .02	.01
+d  6.24   5.37   .06	.05
+c  6.18   5.42   .03	.02
+b  6.15   5.44   .05	.03
+a  6.10   5.47   .03	.02
+  6.07   5.49   .04	.02
+  6.03   5.51   .03	.02
+  6.00   5.53   .05	.03
+  5.95   5.56   .03	.02
+  5.92   5.58   .05	.02
+  5.87   5.60   .04	.03
+  5.83   5.63   .04	.02
+  5.79   5.65   .06	.02
+  5.75   5.67   .05	.02
+  5.70   5.69
+Voice 2 is identical within a few hundredths of a volt.  If this test is
+repeated using voices 1 and 2 simultaneously, the result is:
+    Pulse Width
+SU  000    fff
+f  7.30   5.25
+e  7.12   5.36
+d  7.09   5.37 (!)
+c  6.95   5.46
+b  6.88   5.49
+a  6.78   5.54
+  6.72   5.58
+  6.62   5.62
+  6.58   5.65
+  6.47   5.70
+  6.40   5.73
+  6.31   5.78
+  6.22   5.82
+  6.13   5.87
+  6.07   5.90
+  5.97   5.95
+Note the weird step at $0d -- the response is definitely not linear!
+Now, to summarize, when using one voice, the "positive" amplitude (about the
+mean 5.70V) is .64V and the "negative" amplitude is .41V, giving a spread of
+.05V.  With two voices together, the amplitudes are 1.33V, 0.72V, and 2.05V
+respectively.  If the two signals were simply added together, the numbers
+should be 1.28V, 0.82V, and 2.1V.
+What we originally wanted was a signal like
+	D1 + D2/16
+that is, another pulse that is 1/16 the value of the 'full' pulse.  1/16 of
+the positive amplitude is .64V/16 = .04V, and 1/16 of the negative amplitude
+is .41V/16 = .026V.  A setting of sustain level 1, on the other hand, gives
+voltage offsets of 0.05 and 0.02, giving approximately
+	.64V / .05V = D1 / 12.8
+	.41V / .02V = D1 / 20.5
+So, in summary, whereas I wanted D1 + D2/16, I was actually getting something
+that varied from D2/12.8 to D2/20.5, even if the two voices summed together
+correctly.
+There may still be a way to make all this work right, which would be great,
+but I'm tired :).  The code from my attempts is below.
+I also could not get two 7-bit pulses to sound like an 8-bit pulse.  I took
+an 8-bit pulse and divided it in half, assiging each half to a pulse
+(and giving the extra bit to pulse 2, if an extra bit was present).
+I suspect that another issue is that it is impossible to update both
+pulses simultaneously, meaning some delay between pulses, which translates
+to adding -- surprise! -- noise to the signal.  Perhaps it would be
+more effective at lower resolutions, however.
+If someone has some success using these techniques I'd be interested in
+hearing it.
+SID lockups
+-----------
+Blindly applying these PWM algorithms has a way of locking up SID -- like,
+locking him up hard.  To be honest, I don't have a good explanation for why
+this happens, and I haven't yet found a good method of prevention -- toggling
+the test bit, playing a real sound for a short time, toggling the gate bit,
+and so on, just don't seem to "initialize" SID reliably enough.  Sometimes the
+code works, and sometimes it doesn't -- it's the same code both times.  Often
+resetting the machine will make things work; I'm not sure what hardware resets
+take place within SID, but the kernal certainly zeros him out so that's a
+possibility.  The other observation is that playing a tune seems to 'clear
+out' whatever is blocking SID.  So there _must_ be some kind of software
+solution to the problem.
+In the example code pressing RESTORE restarts the code, which will usually
+clear the 'blockage' after a tap or two, if it happens.
+If anyone has some thoughts on this issue (or even better, an explanation
+of what is going on!) I'd love to hear them.
+========
+The Code
+========
+And that about sums stuff up, we think.  All that remains is a zipfile
+containing code examples of the things we've discussed.  The archive
+contents are:
+digi-$1200.o  pwm-2cia.d.s  pwm-jmj       pwm8.d.s
+digi-$1200.s  pwm-cia.f.s   pwm.d.s
+pwm-$1200.s   pwm-cia.g.s   pwm2.c.s
+The main example program is "pwm-jmj", for the SuperCPU.  This file contains
+code at $1000 and a sample at $1200 (the sample is a sample I made on my
+Amiga years and years ago, of Jean Michel-Jarre; it's really not very clean,
+but it still sounds pretty nifty).  So, to run it just load and SYS 4096.
+You _need_ a SCPU to run it; it plays the sample at 7-bits and around 16KHz,
+using pulse width modulation (pwm-$1200.s is the source code).  If you want
+to compare it to a 4-bit $d418 digi, just load "digi-$1200.o",8,1 and
+sys 4096.  The other files are different code experiments -- using two
+pulses, using the CIAs, 8-bit samples, and so on (all written in Sirius,
+of course) and may provide ideas for anyone wanting to experiment further.
+If you want to try your own sample with the code, I suggest converting it
+to RAW format.  RAW format is just the digi, with no headers, and uses
+signed 8-bit numbers.  It's what I converted the sample to, and what the
+code is designed to play!
+Okay, enough talk -- go listen to that cool 7-bit 16KHz JMJ digi!
+begin 644 digibin.zip
+M4$L#! H    !  -IQQIT41>R90   &L    ,    9&EG:2TD,3(P,"YO ""D
+M E!(7RH)A?8-+,0OU;]&%:@Y;&1!(H!&%R0^:(3!8B, U!H%"%E XD,#$H,T
+M(D -3ZL(T%)LA'E*7Q) 2G(JX4A-E(=6'95!TV=.'[1TYO:5VI<,#+1P+Z$E
+M@- ()A8F 0%02P,$"@    8 _&C'&I6%<YMA 0  <@(   P   !D:6=I+20Q
+M,C P+G,,"@$3 @,$4TH%:OO[6P8  1;W]_>W 0)4V5 E2.))CR8%610KU*)2
+MDS8MZI2J3I#0KS=O@,W3F2L'&1/F2YDR7\*$ 7U#T$^E'@5),B:,YAM"?9K4
+M*570/4&3-!JTX=2@3:$R+<+,,65L<U*G2:DV!,V4:%"0(WELNR'HJ52#@E@G
+M:_NP8B%6[\6*AS:X>I)&C8+?:3PI4ZI%I4[A>J(T8];H*JJV0840_JCV!M6D
+M)8Y.*"V4/(92I8)AI%J:,<'OA%Z5Z=2B((4^?3J5*LBG3LB:!NFG%DVB;I)$
+M8<:H?%"G1!0^H>:&3)\^A5+N+1I7[-H0=-&G4L['(?'/=*H48@2_LWG0I45!
+MT@0I-"G5*5;=@.*QP6.Q/V;1ACJO!DU*!==E(]&B6!N"%NJT*(ALJ#^ITZ$@
+M6H.U!GY1[<H8$+^8=FA3*)FW":,M,!Y]*L7ASC%A8#P.>BB3GG<E^57L 5!+
+M P0*  0 !@#Y:,<::WXHL L"  !X P  "P   '!W;2TD,3(P,"YS3@<(K0/]
+M'0,=" 5-!@@M!P,$!0@&" <6" 8%*!T$!00% Q4& P<&! 4D"!0%%@@&!1@-
+M&/V-_OY^!/[^"!X(+@@.)P8>!@X'!@<>!GX$_NX/ 0(# @,"! ,T!AL%N_S\
+M/ L  P(#!P47!O?W]V>1(Z?_]!?HSN]WXOK3[=P9L\DO)BKVPS8Z;/BWWDB5
+M2J1[04MZZ*3=OOC3M7L87T)[VK=T0\)8?&MJN$"">OVT9$K+G&C];X8N_ZKK
+MM?_WPQZS37!-M;#\=LGUT\'LO6M%MWO<V=],Q>6%4KTI=;D[[<F^^&'/YZV_
+M:;/+JQ;3;MI'EN"!%59N2&N*JP3K"@SAYY8]HMNMT16'-Q=66&*5P%GA3%=S
+MO<>4DBA-0I2("P54CHCJM+4NQR1,[7G#*!.L%YNS2K;\;-I4BW=%ZHN47QFC
+M]J>WF7%^3W!I'@?4VB=(/:]!_.8,G?XIMRZ'"2SJ0=AO=WX\1>7;KB['+HGG
+MI;[2SK:_R2YQWDXM<#93E^>!Q%DBM[\IG6!><INX^\\5KLO1;([[H%_2SB?A
+MA"MUF>VNL3[N*&ORM#;CT'_$%$^&HX_GL?Y)&BH/5M"OH".>+_43^K07A_$X
+M_%9P3A7U: B<9J4AKS(-)IUS/=Q'O-X(/ K^RJ7S:.B4TO72>=S,DX_C" P=
+MRJ;?SR;JF57<EG+[\5@2(3>A6-7#7%!+ P0*  0 !@#\:,<:]D)"*[$"  #P
+M!@  #    '!W;2TR8VEA+F0N<TD'"*X#_AX#'@@&3@<&& X'% 85%@<&!P8%
+M!Q@>! 44 P0&!0,'" 0%) @4 P87!@4^"/YN__^?!?__.#\8#P@''P8?%Q\'
+M?P7_[PXB(Q(#)0P%!PP$!NS]W04+$003! 8#1F<&]_>G4:-&^5%>H"?NO!O3
+MW/KD;K?C7W3(,!_V0@<4\%LB)T5>%\X-E3_5"W?KZK3=BZUN]7;^OL "":)Z
+M0UL#?V)PA;-?T\_9PCP%_92_VBWDY^8I?[I;*?K/M'7<2UW6=?V_:4^W,\%F
+M4H?Y5W.NZ2_F)=AN/^\IS_F)I93RFB[2TI0W7EW__W1G_TP_SB\$[,]4>WZI
+M8VE--"VI:T*Z6-_J[A>N/=-]BW&7/G(NN?IP^GUKW5D$92#O)=)W9=4\K9>R
+M!XL$7)<Y70P?6^UWNC?-U264A+)[CZI33E(M5O&?FT\'6R*X3'&+T\Y:@V$-
+M%UA+D*SAZ1L-4R:549+;,W $+BWI8G1L7UV37B)0WK*8]Y+P+887U!RAZ=NP
+M/,G#<#G.K.&!.\W9OFT;VY[)FS948/*]&H5A@L<1Z;%Q:^)"RE-*%S>$]?H%
+M_J8VMMM,]ML]]Z\!6)6LM:/<L[KW%6H6U!9J((KT[3RF+!8%RFXR^F8A+OT8
+M(VT1?V:\$W#6^Y)_YG2B@ZF6><HU;/Y0O=#=%S]9>WC2']ON?LWE2Y%*NNDB
+MY=?[=;GS_[[51EZ15:))7B$I[_U/X/MT /'"#>JYI'[Z&2DSEKW,U)]T,64A
+M,*S:,0ANR^DB3&C^Q.79] ?XQ1=E&GP6HE;O"2LMY?>C&I;SCB*'&&2#L[6O
+M:HSQ>)O;C16>N?K.X^GB'H(WAH-=\6'GLS6<(GF$NO^CN84Q,(V%@$>5/%[P
+M'(;0#,\9@Z*@U,7L!RUNID1R,TU:(A;@M"C\][I?%I,54$L#! H !  & /=H
+MQQKFO<<O:P(  &D%   +    <'=M+6-I82YF+G-'![T#_1T#'0@&318-" T'
+M%!8%%@<&%P4H'00%! 4#!!4#!P@$!00#! @%% 4F!3T(_3W^_LX%_OY(+A@.
+M" <>!AX7'@=^!/[N$0$# @,"$P(')28,!@3\#/V]!@L  P<3!0,G%O?W]S>1
+M(Z?\E!?$*9YWH[N;._G;-^%?5*BP'U;#!!+H6R(E1%H7SH8NG/;%WEQ[=O^R
+M[6U?4[@OR,"";M^X<\#'AU0^S>N&.5.>I^">\FVS(<_/4^'TMU7X/[USQ9>Z
+MK.OZ?[=/WZ1#2*>.\V_G?#=<3%WC5MT.<S,50(^O)E?KBLTE^94NS___]*?Y
+MZ:$TOY#!KRNYV][FQ>XSW;?\=-O,+[547:L?V:H\K9?2HV_ OFG69:XKX;)M
+M\T[_IKF]!*>X1'>75"DQ035*W30A:MC+FG'4V:X2O"NT_']^/KTZ$U1X&9U8
+MX3)K@F&%IP\Q<)42-2E@@IR=QQ'5\:A<7>I*5'9H+U]V\"B#9W,O<1^O((2Z
+M&W:,U7PYQJSP"!2O.MX)E([H&PUK&:P098JO*PV>>^X%]::=[1L:]]W,P^LD
+M5AE'MUAT&L[7\GC8<REY ?-8MDGHS2#9,Y2B)5\B_-_O-M-/'!XGU16Z2^$4
+M"Q3."E^Y:$'<[,,X+]4W9:9!QSRK1JNX4E>$SS4/96UA37^_.T2@%H^-,PZ5
+M'SYF/DT:+>J4M(6='4JO3+'+L=/S;5TI[EUZM]]9KB[5(IE$+)+RGF!./STU
+M?7^:4MW"Y?X^C+ K)4%<+'G*=SR.!JZ-<(N;>]+*=H-<;[ /RYAP[BL9^T'#
+M9DA$-H-)$Z',8$;A'W1/I-(44$L#! H !  & /=HQQJHW6A*AP(  .0%   +
+M    <'=M+6-I82YG+G-&![T#_1T#'0@&30<&#0@-!Q06!387!"@=! 4$!0,$
+M%0,'" 0%! ,%" 44!28%/0C]/?[^S@7^_D@N& X(!QX&'A<>!WX$_NX0 0,"
+M P(3 C4'%@P5_ S]O08,  ,' P8"%C<&]_?W)Y$C1_J17A"G=-Z-SM_<*=RN
+M"?^B0H7]L!HFD$#?$C$QXKIP-G3QM"_VYMJSNY=M;_N:XGU!!A9T^X:= SXA
+MI,II7KZ?,I5I#.XIWS8;\L(T%D]W6X7^TSM7>JG+NJ[_Y_?IFG0(Z=1A^NU4
+MR/<74]>X5;?]U(Q%T!.J*=5ZMJFDO/+EZ?^?[C0_W9>G%[+UZ;:97FJYNB:8
+M!J'7<^ZVMWFQ^XSW+<:N?F2NKO4\G+ZY.5U:!$H#N9?X[U*K\KA>2@\6=M"Z
+M3/4<+MLV[W1OG-I+4(I+<G=9E9(258/UI@D1(&7-,"#YNTKPKH"5_PO3Z=19
+M8N%E=&)%*JP)AA49/\HP)<XPG@CET^ W7%WJ.2K;MU?!-MT8;Q9S+W$?SX<1
+M?.?['6,57XXP*S( >5YU=B*EXWV#8JV&%:Q,"?7<&#CG7E!OW-FN$3*_FZE_
+M>8D4R-$MYNG8GZ\UU.^IG+* #<DV&;T9)'OZ<C2$KQ'^[W:;Z48_YR<8EXG4
+M G,RILX>=BF>4O'+5,%:"!>UR&;.2_6-F;&',\VJT5(6J6?A<\V#2EM87TJN
+MKDG>=SN/"'0CL7$&(0D?,YTF#>6JC9NVN+-]^56H<B5V?+ZMY]+>Y7>[G=5X
+MB0MC%"57!#R?;GQ@VOXTI5JY7.GN W#CZF2(BB6/A3R)HX%KH]QB93YY9:M!
+MJC?8!V1(./=E#/V@H=(GGDIOTD2HT#D8_+WN24JJ E!+ P0*  ( !@ *:<<:
+MTV5I'GL[   "4   !P   '!W;2UJ;6H<  $" P0%!QD'"0LN"QX?"P\+7PD+
+M"0LO"P\*_X\< @,")*4$!01%!@<&!R8'%@=F%P9'!@<F!08%)A<!0DR-L#%!
+MZJGQ-L8X,#7$QAD('V!A_:DE%MYWN/D-?F. U!L'$/P"H/^_L0'"#Z(Z/U!]
+MZGA;1X2> O$(_[3^I("5JD[Z%S5\!:);('7UZA%#VUV)8^40]YO7#[V[^?VE
+M]R<'"[VZ>Y#0:G=""+4;*].'$%L'Y YS,)?_'PB2_']XH.\4NF/.HB."]!C1
+MM42(OR[M3X(_$#W[BA ARV_L%WIJ+HA^6O4..&W4%D#X QL/G-[X+W3A(%,W
+M!/@(]0D^%C"X"0QN X,;P>!6,+@9#&X'@V=[MV\X9^H A9^H\!\4/N.<XF&F
+M)M@8<<[&BP3?<4[L./>+_J\9Y.C^("L(_M9_F;/ U#8+!\0*<GU$IKMS8MPO
+M'*)XD**&;])#F+1:/7KP *%,>C"H-M>>$0<N795[L08/B+4!Q!IN31$BTM5,
+M(T(@7>L/$O+-R5.S3@5)DNA,&(Q/]2E(J45;%G5*M:A4@*EOF#]G@ B&/4CI
+M_T'^'@]R*CG$J_Y)U8-Q&*?BYTJ7-,# K3 ;?DKA,%L_MM@86?2#;!WI\)5'
+M;-#X#2%;A!]ATQB@@$VK?TNV"&W3S1KPO81]9\#-8CU7@9#I[V>2^*W+WT\>
+M&3K#U@I^F^; U@L*O^9 L50K7OSHT"-#BP\K-ESIL^G3D /9OV>_GKSX\.'3
+M?R]?'OWY]^C?V[^_?_]^@/L#_L]'^ 4"OZ7,B_/?I]<NFC;V]?;9WY=?O___
+M@@L3/HR8<6)'C1Y-;DS9,>3'D" [G@1:=FO*A?7GMZ\__ORWP!]7^.G'QR]/
+M/W[]_/?S]^^?;_#W#^P/L.#%G1[[B;YWU;ZSV^]O/^!]@/TP?<*&#"<^E!C1
+MXL2-%"]:K#@18T2,%F=V]2I3X;[<J__WY>>?5W\>_;C G3[]^_;RU=>7_QY_
+M_7^:'F#"B"QI+@PHGSSPX>-6?;])7S\@__T&^R<,N- @PH<)+S:D6)'BQHH;
+M+X(LF?4L3XK]]?>C_?KMUZ]/5_SESP6>IF_?OKU[]^^6K_+OW\?_W__&DQ7U
+MO_^^NSCX__W]__]_<"!"A!$=-ISHT"'%!:/M4.'"A@6N7\'@[WR:<^#]]O,J
+M/?[V[^<);G:)/[]>N)\O?WT\X8YW^//GR\\??R!&C?OG=Q^F?/;NTF5_0 '@
+M'N'"A0\;/GP0^ R:M\2&$2<NC+BR:M"-_.WK&]5N?]VE)[]^O/MTQ-?N[45?
+M<./KS_TT2[\%/MRX$/]WY,6SF3\]X,Z':1]@[8@50+L":KX [B=$2IG^X,:>
+M/SONEZ?9[=E9^_/CRX_#].X0'7V^I^R,#[7[V1>U[]]_8<:+_M-+;]YMU^_/
+M![[S^<(#'FQX\&%!A@\V_4**#R\P?X5V[_'G4YX@%28D> "\\UW[=Z?U*),C
+M/$T1XJMC]_5T[SX;-,BP [U^L+WY^0$1*DCM@@4##A!W@X=XD+S _P0+(DSH
+M\(!J5E@19<^<(2<2R/S^ 0Y;'JU4*\^_QRB.)U^>SMQIZ_@^W7Y9^_X,%>('
+M7UW\N]0*W@83+#K.0O05*SCZ"+$U+A<4\/[\^Q^\>%*E1P6,[/WX M=A[]>'
+M[??5ZO?G/2]?/=_R#>KSW;7Z_ D9&EP?GARXB_]^MW]@>3'?M?R 6,-/XA+S
+M-5^C3R#+B^SX4$#OG3?[=(:B0U&AV%[QHOT RC[A ?F)M?E]\P779\?NK=Z)
+MOKK/<VW_!@^@EJX^\2+&C1LY=KQXP94SU.+YE"<^]8#X#"5.7IP[;ZZ4$]8"
+M#U%<WUZSDVR!!:+=> <,D"P_]"]O\J"A]0VNY*O\ 8=> .8RW 3H[8(%"O6,
+M(Y:_Y,8(MQT@TZEV/$@977XZ95['?\V/'[^^><_/[=L M#\ >LJ0D"=M^5_@
+MM?+^ ?[KCS2E64[<8<L:02R_R0^W/ %A';]]^?':(\'3E,!!KZS62LWR.&5Z
+M^+(_V ^H;[CY$1_B>?,0G+T$^%@AP@.D)=_[-I5B/8'@EDA1(@/4]_<KXI?_
+ML3W[TUR)+$&5Z.H$?A=XSW^/\>OULSQ%]J[Y%3(8YRSY!H%C!XDK/TD>;L6R
+M*;#R_09%CM:C.ZU')[OS\TM-A4E7,MP%8M/Z+:_,;2]SQ)G<I625L+*#1_$!
+MQ@MW^4S$\(, ];'"Y3';\P+'] A]OU#SOU4390=8-1*UZ6GK^I*O/45.BZ#Q
+MA9I..\$T4-R?8\B1(G!>1B_F'_A/4LB^S9-35IOS^&*-[(M2>N87"%N72?\8
+M388'6M7:?]9'F)X5>7+^J=)+O)@Q@[@MT>%"!,'R?W[!$:55G.O7HP^A6FF?
+M\UV.[;6+MIVU9[#9"P)?H8+ 3V"])F7__I9GA0W639=K<M6Z9O<*5#SJW?<N
+M5='6?\H&^UM4JK>2]P%H"]1@@P:(XX ![+XLUZY%FRX7\C1KX[M6NG@2S?Y,
+MX___,.-^^[:[C3N[83B]F<?]HDV=9@>_4,"JPH\0>/H<VS>"[/WOT2+65FN4
+MXX5ULI0E:E.C);LZ8X,$ 80"<MP#YD>H(>G-?_\^TA&[^.%$"CG/$2H!<=H#
+M_1WK\MU!"DIE1&CCWU=S21_87^WMJF95P.9_L8:.58I,R<?R9Y!IAE"\5#L!
+MJ(H7*IYKC^#C^?/@HW3C?[DK\^\1 PM(C0\,*QD*&P"U,K>^\5E KR%AZ(4+
+M4@XS3-"YX%<MX'S.8_KT5#;?M\<XNN7_Q4,V$+B:!?F/KH$-9 N)+T(E::;!
+MF%^O+B\>BE]1K%!WR%A@?:\F4IM_/XZ/5#U  800*4*Z/D]A!=E*C$^0(('+
+M+4 [&K24-[["T?/S\[9"A?-YCVYS@*S/ 0*GWX1O18L%#+/4!50M-+CJ<P!Z
+ME;*1R#\>)ZO0[$\0@)B^"1#.!M(9S=K\^?E&S%&]G0 ;P \&IT]Q ]14.ED:
+M;0PU7<U#SH<;T9[.JZA? )/Y0/V2MQ*] JHC9<WC4L"E;T8"CQ6DFX29#0@+
+M#1OVA\C4<+3]]NW;\U_'0/LJU51N!] V_E?,J!KX@*%B!-5 M"Q(T;>E.NMC
+MAXZ'RF0W[@X8,.#,UY[N] ,VQ#CBF:YY<V?/H$./)EW:U.E3ITV7(B4*=.=-
+MF2Y70)U+AMS@\).JZZ]W.S7-O5]_GKQX\-Z[<]^N';NUZM.C0WONS'DSY\Z=
+M-VO&;/DQY<F1,V\.33ESZ,Z8+YL.7;KTZ=NK:P<_GKOX\^7/NW?;A,?;=#0]
+MT_XHLF3.G3R11FUJE:K3L%NOEG4[=N[=NW/Q_OT3.,#SZHV+5FU7L%RO1G6Z
+M5&?/FRE9GCAKA?T?/)QH>F;CZM:O-V^N7/CMW:E9ER9]>?/DQ(T!!QJW 04.
+MP <GRO6F6[NVG;OW<.+'ES>?OIT[N*"UN+@M@]\W">0U=<Z7-F4T&X<UC"]R
+M\%A['*%R1VG29<N6+U7.3'&:7R"^RY0M2ZHL>?(DR9,C;#OE"KI=Z'?TP'3W
+MF"%D1C*M40/$O<+@6CE/(!49?8GMDE?.<8;/!5,3U%>^C/G29@Y"72C2I4^K
+M5LUZ=6O7L&'!ABU[=FU:M&C+FA4KIO'+EE73^&L"/^U:M&G+3'[:L66_ANWZ
+MU0MD@TG\L6._=KV:->K4I4F+%@T:U&=-FBP876<I'4_PEF!E?/M-;JD<'OSV
+MZM&-)_?]NW9MV*U7DSZEJV>V7-GQXT6!CSCQX$*MZ35 "B9\&''DQYDO96NI
+MO5I6X+M^'?N5H9Q+MH$'#Q;XRI$[7^Y\^K/PKP[].O;LX+NQ2C5+1S=V\#ZN
+MIE08UBRO.4#%):*%JB$N6,!19)@"/X+*?N/'CR-P\PKDCMDBL9[SRY4L41RW
+MR90H5[I@W#-?THPY\^9,';KRCE->Z-&C3$[24:M:(2W!'GNF,K]]^W;NW+IU
+M G=<.8KO]@WDLTV;ENP9RQINKUE@I5CYZ1-M?LG@;F*XD2(A;:% ?_J Q'OB
+MD'Z9,XJU^D/G\I8X55,G9\GJN][>VGSX[MRS6Z<^77KTY\V?.V?>?'GR9)NR
+M<-^];]^>/?NU[->M7[-^O1IUJ4!XY\^;^OE,@?#-GCV'%DVZ=.K5J5MM_NO7
+ML6G3IM79MFW?SHU+\&_3FN]:@<.W"D>6CPNW>1W#?UWDVF7IU;.]2Y[Z^/#B
+M;AJA4S)E\N0:?US@"*[*;RIK=[ ]KQXHZ1O?V'. K"N"'L$BJQ2PG"'P-0@N
+M8\D1/K*D212QC1(%;J<8W"J$2S?'I&FC&^P3Z-"A18]L2[<5#AR5ZM0I@4?X
+M5*UD5JTTN*]>87RI3YDF-<(K_]R)T\;KW\R9,\=ZX\2)(_%KSIQ)0_!,.T:E
+MSE)EBHC/'3<8<\4LK6$$$@,-/-Y7T#A?X,8GD^R>O?KTYL=_WQ93KTY=^C/?
+M9KX<N?'BPX4'!_[;MV]?K?+P88%?_'AR9?D^^O1IMV#LV+%?OQ;XUJM/2R_4
+M/W[<6. 7+Q8X4./&C15.L+^<N3/8KWX]NW;MVK?!MC?7A-KERJK3IU?7,MW.
+MJ'E=G-7B,>YU6:X03ZJII8Z/YO* @TX;"V%=35Q'R,*F",(I[A"X.005X7:(
+MP,$C29JP#;M\@9MG6-QOXLPQ^#<BNV8-RGPC<"%>8WVR7P2>K>0/-#B=+LI5
+MN9!%H>$1=?8;1M--\H1V0/&H1D)\R0$!,)J&FA^$588@7"E3,)OS 21J<!3W
+MXXI_YZX-LG +,V?/%CAB]]T:7H8B=??YYP('C<KBQ7T*D_NW:O<X>!A["0<5
+MW)L%[N?24'.VT[Q-6Q!J]+O/(0N_CS=200V9WP7>6M=M.63J6)DLWK]/GJ"7
+MH9I& ],&"!87($GHJ9!1(0O7%2T(%\X+[MG$N\/-(@87W%\C!NS&(/6DR(-@
+M/+RGP6S!H+I"X IQ]+K&P21+EBP!.U+\D2-D%VI;I&#,II :*ZCI"#4<,$!$
+M)-7 #^*J4!M!*J&4B0'ZXRI4]7,7*C;MZ^IV8W(E4>+&[P(7TDAIB-QT*37.
+M]"(ZXPN8M(H"%7S>?'EQQ"+:^?PY^QYW':65?&SQH]OYCB*2G-GLV;<[#14N
+MV<C/O5\S(KDFK9(^1[$G,(O2S?[N.NDFM$%J#7$B60S1/6V84R!R. .EJ+%F
+ML(1Q?G!M_/#!EUG%+JF>$(%-0W2#V#I5=7E8U!9KV6)OB15:(BE+"1BF0+BR
+MLB/X.(+(HK&U^@+Z'&$DZCUMUMJP +V*+(<!?!2!NK:N@.Y_M89<@;S>\N.-
+M$\+)%)"8OCT_#*[GC()W0QD+ (AR:/1N$997462[^Q365VWNOR^H %/W]_(*
+M=42$U:'I%*C$TLG#:.]D+#9PAS&#6U6R6D&W,H%@4E2A1]>KQH\_GU*C^.LR
+M!>@.XO]TB9"*'50T#WA)9N"2D)S+#1J#2(5^&LFB$!K?QP=4D2IK+ JJX ,6
+M+BK;,C(E?Z:<=M(ILMOV;U]=(9V.6[^O4&.%\;Y8\D.EUU@21*,^4D4:1HMZ
+M ]&WV#1JA@YTB@_@7<.L:<\_X#R)<SMPI^_E[XLR/3)I2?WCN8<OO[UY<>71
+MG3&\GU._O@W"BO/LY76@S0Y%4[_U;XC@N;W"HCLQ(%KV9@="IL!Y#+,J8%[!
+M8B^ 1FIU5K;KV?OVM'NC\U3]K3^>?%DS)\^>.W7BI"E#Z7NE"4V8PVJ;7M"[
+M,=:<:I."O%T P?0_:/&]$+WUL[)^)Q)Y??Z0#\>G B;&73SY]._H4OV!.'L1
+MD[0.MZ.W<]&B0X,"];FS1@OZ"O:;0"^P0YLQ%[:K]N&];1Q;G]YL&:,X!__=
+M:^)D^+MKN\I9EP:M^?+ES*0G0>_+DT??;LWZ>?;ET7S^V:4A*&\'1ZVK>__R
+MWKBUK%$R-$$&EWYGB>Z>(*=^L@7 #9<*_"808[)R^Q C(/<(_IV2\=Z[9\FF
+MW;*P?M(P.*E0HUO%+F6!I@9G5F5THY[N_:<I]9\S+XY\."ZQN6E+5?5$Q@C0
+M@0L%/F34MUUWUKQY=.I4!*-H']M6-'[,9A<VUYYM5Y^GHS[_&S;*Z4JPRWER
+M37)JZ !)TY Q<E!Z-FD2)$@0(V\1.?.7,MSZ+N[61:U.+4K#ZA1)HRS1]<AD
+M7X(>HWF+]$"-R5F*>HKDBLX$ N7^%5/.W-$U:_93JU[5FD42>\3)9.);LX"5
+MLWK=NO7KUS*#]%:M7=.4E>.:0<62Y+5RS9HUR^B;;=L&E6ZC2Z-]4YGCAM4Z
+M1;%<M5=]J)''7FJ4B'.A4W2[N=D]O2)1:O\&""@?./MLKT!5N/S^OOKMT8LI
+MTK40<=2G:K7 '_V9<Z;3O/CPX<.%!ST&U-#C)XK\PH4'$Q+\0M\(V$",GSB1
+MZEX<F7+GU+:44L []&C2IF@I2\JC]C'N%98&7AP:Q#T\]6:?8M_%B:4,\MIG
+M@UBRFYE<C4VK"[RH]#LU0W@8NM#%"9(RWLA"F*^!5TK-(HJFH$I#,XP\"K8C
+M2LH:LYB3V"1M3&Z),^A2)V"ERQ9[UHQ2B;#9JE6;ELUB' <8IUM7CC$FN.O>
+MY;,J[%>/XL^-$[CGOFWS*H65L5ZUFF4B_[7J4Z- >2!4N4*5IE/B'1>#:[XH
+M1O%_A[OM#)]*[O !,99"MDC=A'I[<GVE9DR>CS82)UYLW/?6O:L2,\1;S;-9
+MKUK&_JU:S!6_-8G<NS<O+Y=KB6.7'SOVK+$2Z+-&G?J4>:=&K3JU:E;;&.7+
+M"JA-HP(?%S$6>''Q7($?["J/3+5V=^]?OQ6X?PLC_&#R%#-E3E+Y)V_&\J7;
+MW>BED&7TZ;8VP5S-:>JRV&$$-@T5[@E3DR]>,-GN"((VTDW&<0QO#Q3(13P(
+M-("-*ET:-6J47725P&LL:[EK%VZ9B^&#B8BG\8B?&8F/!8,O5XUR#7UT2.V)
+ME3P+&)5)RL\E2;A-B523&,T<'MSLHC[</RASA<=3KY!U">OV9.@-:0!_6RJR
+M"'2A_63X:N+=;&)7*:Y4L1.\8Q\-&H^^+!=?EHCZZLI%2B4EWB]JEM1=?ETI
+M>6>#GPS?R6+EJ'P?71KL\;ZR:>P?6Q8#T\'(M8-AIJ9\\N3&GG*5/TP;!;U,
+MZ_MRKY;$3G^C&/@</*%M(HI,5[!<+HU8R.KR ;8E&94 0?62M#TB\/XZS2:\
+M(G4GD%\!C-J%TZ11*<)%K8I015LWJJ+$_>/,=M*D2HZ+\(^@0R3:-**199P5
+ME96$L2"G2J*Q0DHZ+URP@M:6*3H4*)6D2A0E Z[.9(<,Q PTL.:'-?WN85*X
+M"J83P50,@LDI8:2O@P<//IQ3TBOB<QL"F:Z3B>"2RZT(*'%BW>&_X45M''56
+M78$JV[FSP3NNE:R)FC@*<=5DS1=J=PM\[^"F-SH6U>OT-OD3I)#12R0,!9FI
+M]#(,<$ NX@?$)DJD2J3$E_!LO0N]NT>1O7 )X008]K"-M!1] G+"N!4XLQ@&
+ME[A<V2CTB!Z)=(HF@JS'7B#EJ,FP B<-,5/.I 95-IJ&#-!?02I1'#)$'9WH
+M$T"1X80(UF0,( =%9FB(7HU.*GE=X*H0L/U[I@0,\?DYB>[G)%$JD1U*L'?#
+MVUR^&\_ES1ED[M[]^_=OZ,FX(O+7AK*U<^>&FKU[PYS'_2#HH<+RZ;45I"3)
+M1^5Z4#HM+Q>43JJ*-/0BR MEA VF4+Q@D/ !)YWF!+1M\9B*C3%4([HMIN*0
+M'.(2]16Y<&E(6AOR)?(=5:,5J++FTSFD:1&*3#Y(A&\Y1$VI>$ P$3A/0!0)
+MJ3*_*9D)Y&D(&G7H;K4QN&HG %'$*N,[L>]')Z#!18ATE>A,@_,Q6RT(I#L#
+M^$,2OZH_ X!KOB?!*Z"JK]O].E?"Z'#_'%&TN(:^-\ZRY*SZ[7!13%A)H[*3
+M F?TZN?OH]-D EL@/YC7@&1_/IR$T?TTD C7(M__\0'!=8?4L@<@:33I^P\(
+M$Z!\87\E*LZW!5>A2V"?:"$T0K,D-S4.=4E"+299VTGYF++UZ]?G)UE @X@'
+M'&3L@$I!I4)"CONO0Z3GJ2]FQA GD!U1 @U\KEF6: <;QDZEB@RP22*9MT=?
+M#AXF-E*[+,_,10@8 1B_#%HQ7CA$XO#<A%]O\P2TB^O[\!]48 Y0,]"GOQBR
+M:M,0VYWP9]&._[A$X97)?QO"VKMX\^E,L%3)=B_/A>>-0T?PXNQTL(Q^=V3@
+MZW8D-75J,@@+1M60-0##22J]^C)"2$N<'N$';1[#1>%%.H.A%2B$N"A<#Y19
+MDM\)*RJ'<U\>9J.K .J!#7[@DB2/_$!:35,CW"&#MAW"!OGC4AGA;S$@^&L;
+M3'\C G9M-K<?]OGI8-!>A_<_[VZ,V^#*H!W;:XMCS\<'NOCEW>1*N %6#'"5
+MY-XX'W:0=B)H>1F/$)G2V&_0U*\J+2F@VP%V^GLJ9E3RV\6I>_36S7>?QT;%
+M9W@>8"/,.//#E?(\66!V1*WO'QB_X/]S>?F-!3OR&VV '/59^Y(9$VI4J/+E
+MSY4),38%&D%7]W\?_?;TU=>IPXYM\>J]UTNI<;8^/LT#\XU*Q73# (P_3_&'
+MSYY^[Y&EK:+\ ^1K5/Z'K14$6_#7&VHD*@-27OK3 P@^ LQ^3T]%I$47N# =
+M(RM9)L II?@"7^/)"*'=3DIU\-/1QTDW/EOX @&DMO($(.$0JL"J[9 8.T[T
+M.).(P'[JSY$)!YP[UM.@2^9J-72V>7%(V_'V0+X7]*7?"56.Z*P-=O[RB>?>
+MMNE,L \PE"L\#!D$55#"D.,&V>2^Y8DI>W#LG7!0H8&RUW8U",GGG"\HK\Z)
+M]+B6'P=F?#0@M3!$)?XPP #(\9'OKO[>GS\;P9+##+*EOR2C70*:3+8?8CC)
+MSS0Z\^*^LN=S88N*O]S*<[?E1U>OA**H"JDS:HHQ&O :KNU75[Z]'@$M-=<'
+ML-R*H?TY/ D\)8/R6&'"/[:L*51F!<#J>4URYKP\ATA&)KTA1'Q=A.U9/6G+
+M!FYE"6EDS+52G[[.K2ON2A0,X$=C@0BRH2P,1B#RG'%ESZ,W,0J\Q^1H%78%
+M>WX\-X=>D)J%WSMSU/558,E(_^$(*+=E^;UUY-<X*"'1-&F)P)4(E'8H82(C
+M]XTI?ZQ6._<.=-?T!"=Y)H8I(HCMI7$<CWK^ARMO3)"L087Z_.[W:3BDA1:1
+MU<BU@S&;*!917?DW29U+@Y9,X/1$-6%TB&!O08>H4-(Q+.^+(1=,AYUA$[8M
+MWYN)G[\_@.3;P-VG- XJ *,I$#=8UB\0ZSU#&IC9PIW0= (84HWNCDC-]O,!
+M63B"@I:"KY@'%PDS.-U=#:IV3.)XZH#0"8-RM$9]!ZJ^2 5)5SBV[#A4IJ'@
+MG8\!3!"V2DEM7O+_D,"K="K7Y^^/[Z'PR<D0EXF4UQ1+D;)&EC-/3KB&>3"4
+MTW&\BN5\28$HG:'*6JR/"BU;#=E56OJ^?3WR$1#M?D^JP&#0!T%F&KDQFS 2
+MX_,:8.B&)G7NVQP_7HW![:@60F+)M79!9_;UI'CG.V"A)A ;<!E\P O,#\@)
+MB7Z'(](-VC#.MT'=CF$HE; [&IT.=/I5YYNV<&_**"R7=TK;E'8$HU&RDHC&
+M!/B@J I,AMJV](1-@*^(=/UXJD$X( UJ 8.X=$D<M56-:1*%(>P3^J-"0YQ,
+MHFD.(AZ* =B!R8U%G& *"C>47VOKFZ'A_/D6NOGGFU:$612=:D!$#%JR?EAP
+MOST 3PJ3\!C(2>,!:QWU# 7J!MX777E"=>_[:% :B/:Z[8DP2,(@) J1[4XO
+M#_+^>8 $X1DL -$\@(.C"M,1&RP%^B\J6+52S7\ ?L*=]4%1+*]/@^7=<9HR
+MC'_?44<@I/=Y3C6<_R6@\( 2#G40&C-0S%<_IS&;JR&]^TGH*).EHF)V!X%:
+M4*![V(Y$0F@IH"E@X +1@DYDA,J@KJ%IK2I0GH?Z!O?OE\?1-7#\>30TM,/R
+MO]?IUR?XH%*@H&B !ZPQT'L4!;)_?^(+3L8,E+ "5P[P1"!7EA+K>X*3.XM,
+MHPD9?1'BHUA__W]O#)22\($1!!/H8F$#&P'*(.$"<@P%D(PO!P',3F( &3A"
+M8>%Y"@%J&RH($AF06:;IHV%D0R,3 OB_'1H<[SX0'$-YFBHT9"EJM;XT.1*Q
+M,W$RW='XX("F"*502(: )*U9LKW4"$3A>0\*<E"(= 9@I^( CL@ #@120A!#
+MQ0B D)3*8D7AB!8H .:# 1@;UZ]?CSY4;J2O%;(J50<$@2(D:'*=#QZPR?C@
+M@#(:*I'YWR9 &Q43.)+0?>)HHGC*5/\K7VL/]QM24"R3QM<EF4 NY "Q$53U
+MOUGE =.S/Q.37A/(M8$$GLQ'8L4 QB@3.#2$05(DP/[&E9Y(*B+IB(0N,&0E
+MTC.K'4ZO$5*NJA! J8SOXRN0D:\0\\0,]7&5(J'+3<#F$CD+-C>XR/C :PK
+M*:(>0#6H"4*1:H0%Y!%%+$\XL/ %I"RAJ,U9XE.N)P72ZP1\#P+I@RH?MB/!
+M[HT$&Q:F"2XOE)LY86YF8$^]F\I;_+8!I8*9AQZ$',H^WH9$*56'4(]0U2<F
+M2X]T@Y6;(NCQ)81M4VR/_/Q%JEYEE/\&"NN-$PQ,HCC-*6Y8 4QP@X<KD3*%
+MU>OT"#*%"= 0(OX#PDM)DJ]9G\1P1YXA \:#09"#+J:\_HT*VX-+BV^_=F!Y
+MVHGCZMO#U<$1BBYA,+T55W-1!M/]T#7V/EAA2!M!;[5)8?2RI:6;RU;E&?H/
+M2W^+$/M?%S_PHLRE/55^N/HKG% ",8:Z%^AOO'!8-V*%OW!_^@ C_P=(U^T+
+MO@=8/Z'^]P3RUN=,7B]LSU3Z9X]7BLM_,&1_@&X,,)ZI=M*ZL6([.[S(D'S[
+MZN*OG7:V)LS2DV./;FVG?FT@MXI_@Q!4<'9?CDU,X NB'S#CPI +-106-E[R
+M8D<+:"L2H7<LLC(]1@;!NX#?[+XI@ERZ,\7DW:F"] ?P=JG7W!$"EUA)#&F#
+M$OZU)N(!\ZI[_6 _#Z0)$$J6?E\^"VY<C]%I\A]S=I1(OQ_+F;XZE_$[6;I^
+MP0E!>7$4SM8N4$_CD ?_3?'.3)F@=K^.;="!N[MA[?=..;<GB7L$\U5^JG5S
+M$L<"L"K8+;Z'4)=DZVM_+T+\G^.'L.NW%&GA\ \HFB"MV8F2D+P\@,I WARA
+MQ% WD#AA\7G$Z\=#Z*3HL,D)/8)\Z$^-IU=9O;MC+?#YM3G7Z\2[^93+C:.L
+M>@V]HK@Z!*Q@7192>Z*2M7W>'\V]0"U VAQ=;X)H^PXOF+MTM?P&7)(&8XH&
+M!O8 $EVX#$+'.D07)!6&0+M"-ZEFDS_\'P"<*)J0^?K]"BZA0'G_@)!G?BY'
+MVE#C8/P &?S$&_JO]_24V.R,!DESLO+_=U2NP.7MVKM=<5F 5()N6%MQHC/-
+M#@WN "4GK9$:2*'<757&-X%S%#.L-Z:0#(FJ21IFZ?U%P$P +MO!/A=:LOX
+M1Q-K=90<' T(CF#.6AKB F-_2)WO!8X("87Z 15#SJ?4LJ;WTW^78T!PUN/-
+MJZ?_#Z)XWY.KND558-4QZ6$;$^XFA-*MM^?L7(Y(IA\^6)G*>Z+8^(!2HY\C
+M7;($N([X(*JR25PU@_V# TCUP _2+$4XDO@&". 9@<4<0<DJN%7=Z:$=^C@"
+M^A;@L.4#5[!WB  "BMZJY'2:[/GW@$U)3>,JIBT0D'A++=<C-H'A>50'#S2
+M!$4-&XF:8D7\0!^+0C8G"#KN]_()-(D-I9DDFA+L#K;[:8;U55F,H-3T,PAB
+M\+Z(2B0&8FA(AR4-S0:4P(347"[$(+F4;N1E42#K6B6%(268D 1E'>E=2COT
+M,#B >TB,Q!$P&&"3:\Z4P)76K>KY08B[!R992HP_0$'Z<]OF8E4-@W1')$\#
+M(/SO1N=ZUL3ZUB8QJUH&&^BR!#;(IYG>@DWXA/ JTSM-'3DE1M6B%5U7C?W%
+M1V>'[2TM:B8#H##%H !S4$2B<((%@S1 B!\E+[:@8X<FY:!?@<3PP'YD#5*K
+M%(T&(&[B6E#*9@-T$U%U%#0-0&SRO:L.N0\5,70=&9CJ4"2#I0]:E?:_<2-0
+ME<34Q-1#"6F?4,&*#+R!48$68;"B?V)_4A,3F,LT ^,)3,$*=C(=J""I[H$"
+M5@SD3"36^,#= NTP[/]?YA!%MWQYJ(&4$IJ=\[FH%")*-5VN>Z5D(PV&&HI^
+M4$R0(,$"%!.R:GR U% 9C30:^2')("!NY@*A:Y- ED:WQZMUJ(YWT#"_[!C!
+MBH(+S$Q8P)>._ IY&1!<0,&Q/@F/W;>KHZ!^%J^1\1IQE:63,G3#!CN%#Z@%
+M)&H2Z(AP"QP@:N0FP@]F OZGYM#E4.5RYJ@JA3+KNV.06*--0GP#R9#(4ID_
+MODJCHB;9(()&E4AR"G43.HVX+83([?:9_R4*+WAJR*U#(8TBH4Y'%0HM0Z&Y
+M4 FO:)@+Q@(%Y)(HJK"ZA)6,+MW@R)J0'4Q)&M9'/"2F*!*A#9(J(A5AN5X&
+M@1Q0Y.<@J$:Y)FG%ZBHG<+"_360$M\0+$Z"(P/2G-Y? STG5<NR@,C%G! @)
+M#U"A$$>A[EB@/ZV,%#XKD%:8@#YB_?I6#=S?)_,^Y:!G1?V;'89,@(;["R!$
+MY*8((K/\>1$9W \;D39B @APPG*AAHKY[UN3T;((5 @CT=&')"%X@5ZC7;1^
+M?MLF?\$-U@7:C*H2U]O#()((O<DN<!MT:<E=?K>A$JMI7:6:\7D5U!OS@Q34
+M'L&' Y@A@2LL%]9*IRWH[3>H/,4@[*'K[#&J4Y$'BC(.@ EA  ]#'.=S%+(,
+MQ.[&[E1LG3Q$DV@RMS0*LA\1VNF"X/XV0\D;([I&UYG X!S_X<T0#:T'5!U8
+MIC>&]CP3'.DD#?\^#^H(81*%08@-X@PE/+4\@6%=@6M[?O+Q#$%0L(YYPP?D
+MG#9RK++X48#5<69X## =+N?;AJ1(%+WP4-DP'.T<C,_9AUQ9\^O?MTXF. .Y
+M [4%WN5*E"0>@B5LA0CV^8IZR*Y"/63#]-:E68![ *L(-O'>MEN;[FPY<N/&
+MC 3?,>3(D1\_CBQY$N%W?NSX\>3%G0U'ODRY<F7/BC-CSFP(_#/W8BI/4VBW
+M(U9'6#$K&27C1HK"*XOB]*D4*=DE4>$W,LQYQ^;%(^8!])_ @<_]0P&Z[%:G
+M3Y>Z['G2I<D7(52'!3&^3S >38^G7_PW[MBC.X^./#FQ9$,8P8>D/( %%#A
+M%@RXT.!#+AQY<_+<KT5[GEUZ=>O3MT<-,;>>O3KX[6(ID,<))!G+_&"YII*\
+M>"&&H*RILI I^9(:]&YW-RKE!Q>"6.![&//.X*AZF\*33]"&7N>+*FB7QS=V
+MD%1%2'GQ;IA1 JH>\F()Z_Y ^!5%7B@0(OT.%]PO<\;L>3-HC1ANG4%]-/Y(
+MFTFC6OECC=8KF#OVLVWCY!'GV3>@^^YI"LM]6Y=MWKE[^?J)'!4.W\W[-JX:
+M.W_:.:T?]FG0F3:J/^2)4I'6M\((+*LG97F_-'AT.=#FV+TMR]>7]YY=6W3H
+MR9@1/R[4XA^,B' ?%CRH-  Q6M%Y4)E'\GKERY]+[P:.G+AN8 ^X51V%3Y=^
+M7=K555BV[UPK8>#):#.TE7AW:]@8)K73\H8UB3&IMZ.)#I\N D$7DLM)-?ES
+M_VAZ/RBBE/RE?+?B=D@N$/"%Y(HAQ3:SX;)C<Y".H<:^$R=/'IN5$DK7CSY%
+MVI3ITB80\*UBW=I5:]0L?L1NY]ZUB_=OGM+T*P !\J:ER^YK=R]>O'OZ_&_?
+MOODL7)FLV;%CR88=&S9,G'\K&,4;_J,^NLACLN@_MRYO+0M1G('^@?'AB(JZ
+MND"I*;W=>;(G^ET_?EM;OB"O$O_L62S^UK7N'9$/!=_UZ=6F2Y?N#%KSYLN6
+M+U_NC-ES)458/M]9-*DK7['L^M7J<O+E'I!W;U](_MV[<D_V B_W:==2\RCS
+M=^_.M>;Q;E\>^,(RF.2<D3,3H"B,BXR[VA4I%?QG0F%DED?XRI\_N[P\; E?
+M'R^D1B]+3%]C!MFT@I-L*V!(KD##B;9&0AVABV >87Z=.C!"N!&8'^C/GS_*
+M?+J56[3]M>Q9MF_EUL'-=@KP*%LM&B]O+X?@+8&O-6N6P+]ZA8#T5"EM/C>_
+M4R5,8:)#WGQ+X9LXRH)QU/EJ$*]4T9?N /=[ZU+C':!)(K?3FIS8EE\DF'<\
+MHDQ:,0I^<"'LV*YHAL;C;][\V0Y&.I^E+7ER7%#>R)J\?^>FI<@IE@CNW\.H
+MO&3E:UAL/<[9JS?[E5;YZ\R#(X]^O;GNVL*8L$L'AH/_Z_.'UR+\Z\_X_KV)
+M95B96/U>#^EI,>%I9#X*^VRJ-?G9GSF0+6">OLT*$LP+Z\ZMS"VF=X202%[<
+M;=$A"KC%EM>: -#1#[PDIZ1;#^\(&ND- 8Y'MEBY4O.7J,"_ 0)^Z,Z7*IJ@
+MDW11Q??C@_-!+GNYZ12V'V(W <%WFM0((!^UZ1'"VVRD/VV<=X]>L8W*^&7-
+M'!.X$.#=W&:_98O1,GR6*4=V #G\P!():.*%"R% _/8LK5F<OY[#0EH:Z0S+
+M6R>$4AP_?CPLCN6)')^[2NJ%H^NC$$^@'D>4<O5JH5$7_/#AQ9,[AM+RA,2Y
+MVP1(\VETS83)B_>NO;JT]Z+RID:"1Q\-H2M"NUJ6IX454Q#<]G5J/'B">C3!
+MM2XUF4:?CH3D<T DGS^?3HG#\^?92-  2EJR[A8S "CX052D-4]*!K900Z"O
+M%T$0Q=)ON8+T)<7J=_[N!7?*E"I9N.#Z(Y;A1U2Y+!< ,I;Y"/-*N7?@6>J!
+M4F/9,#(AW;%C!PP<,U!I: ?)"=8\&6424QA 18<61WPZV22^-].!^Q,1N%_A
+M4!&6HKJL,G25)34)"DYG'AKQJ,1%)DB6IV(Y?OQX 1W481+M<A@J<PIC0O.A
+M]OET20&%Q^-,AL4]3]UM3CQIKS@PKPL2_<Y)AB1-9QE11,P/IT)WA3@2U3#R
+M\)Q@+V/__XY$-+'[L<^P@>,.@:.4\\</=01CQ(CACA *U!<O? YOU& 5T'TH
+M$C4CRJE"%++P,FD-$D1X@)='?#RAB* ;%70G(G#D $0)[I? @V 4^E-1$I86
+M64VR]D10L9$!$@\D4"/  B82R [#\_0R0G)A>Y.#KJ,^*&5&N)WNF% 3A+9C
+M=Z1!M",& 0JID*>9P(@$&_@TPB)A 3X2#, CL0#'0?)H?RR.[R5(B-[T@T'5
+M5>?RA!>'?@CZBN $<A2P QP.".!+0@9(5,*3L5=O/7O[?_1;H8/RQ"\&R?3I
+M20?2"U31X5_,VC0#WA&#J4[A]^Y4!3'[A3<SQCOANI1,C/9AGD*5XO"S0/SE
+M'//]_@$Z,,B%]- L=$IZ/$Z04GSP8E2?$6H@U^OPF'T[PD"!W@ '^ %ZM-]9
+MCKI87K^^?.O/S^--':%Y5^BS'2+P1_X4._0#O=I!B$6#K7%I3 1B/-=;R1 6
+M##W;_56V+" ":K[#<XL&6T\F,G@X=M.MVV-(QO+8GV+].A9MV[=SZ];IZ SV
+M:M2D0XK.-%W$@$Z[M., EC,]%5I2,EJ3/C[\]RZK=7/VS5-;EAS9\>+#A0DM
+M=*"7A)HE6]X\673MS;I7A:RM]Z?^/#9S9G?7U<U/[Y]QY+P[M!/ E+2D?)3T
+MWDR%3(RS"-)W*@FP?P('?!YE!/!_ N>]=M\4[JQ$9M8K//X7)=R  ]3>ZN\R
+MWLB/=>QHWL&VZHTT">"$%@<*NE#F@-*F+PV42[T,YXZN/QW<$UN.E/L1E2+O
+M#@9417F] 9Z<H%PB)C^S9U A:&NC1S#*<[T64<1[_I@ZGMET[-08:^L1@AND
+MR1*@X)(F-^R\I$Y&@C?R!)KR@MOTA;VHKY/&/>*!3;F?0#VDR9,J%KSD9FJS
+MN?G0H4_?KLVRLF]R-/WTJ9IR#S;JU*M3LV+5\C<=UHQ<.>T:U5X#JNF;_7S2
+M>5#INW7CA)+7>AV:,RD7D#%9LF33J-)GRY;]ZG5KEH9Q6+9>F*A?F%(^]8@9
+M7XHLZ&[8G2@AS Z2AP/C5;].7?ISI[6\9]JW.2=:#>" =#%P!2[X]*C7@0<F
+M7!A1-<:3/)E2,1VJ6"[F(RY<%[Q^O-A>9V2D<NS2O:=W,YK*Y>OKDX.*0"9Z
+MSJ@DZ3E2D' UL-\H\R6'%M0(?&BL$$$ &B(%@J,,LJ70HC=3FB1!A3)(D!]!
+MAC!]@1%+TLQA24YR-;^*I1#YS"6^YI0U5$XC5S9K=D[B7L-7G 8T"ER"KP;Q
+MU725V[I]._=/Z> SP1AFKH+]/I\D5 5NKEI*D\G8:1.4<5&D3Z4>S?F";2\B
+MJ&:W_]@@#HV %,UF[-.?+]OEBQLOMBT?C^;/-_=]>_9K5KP=^O.E<6'$DH+Q
+MRYL[^?O1I5%1XZE5J:)=YP;^N_8IECSHSZA&Z=:;*T^R<FT94[3DC@ENSJ ]
+MJ3YJ5N1X+DY\.3#EARU[5C,I^D=O-GW+F6;^G+HUNDDOOR?I<S"\<#';BI)"
+M0/1QKR?."\0_KV^C!Y#HAMWY#<;78RL"W72+%"%)HJ%X@HQD B=^B1NPIE_.
+MI&GCKR7;1Y,N?6+NJ5[M@BF'Y7**5]5"#A9CV%,NR4HN\DF%#L&DFU!A$R4-
+MXU2V^XMPA[V22TEFHT%_[HS!R=;9<T=!E4,5ZA\M^N.4]?@[ C_G3!6:6CR%
+M2Y^8^R<L4 -&D50Q:L9D<CM-5D<AN->3SQY].7-G?,[*"C',KMU[6*7,7-FG
+M,#)G'%KE*:*7.P-&&>+(C2,+Q!+Q8FZEK'+M6).)'Y[Z%!/V6F0E@9PG#FQ:
+MEN;RCD95/#S8XO>^M9"_[;N8\GZ&!<VNO!V<(2F#]#K"E74;;7<F]O>@5F>2
+MI"H5-&E.@EP \GQ4$GHPK> "KB[1!D0,(Q1PM:OA?U B)Y ?@0C,0J\_HZ9\
+M\\8D7O,F#T<@H.BB29-L U'D9/&9+TC1+0*?98M8,@W0OVG3QB^6V4-*^R8-
+M5=(Y](?'/HEBF.2,1$P2IE^ZN":O"/P6R$3:](IN5"P5 .] Z$90SQ231P5=
+M@HMBZJPV] JN.*E&'-PQC*R1,@YNIFO;I#)U[!!$72.:19JVT95 DRQ:[([3
+M)>LBO^PC^_DSF:R6W)O5E/TWE.-J.YF=*]-<)%D<L17XX.X$/9*,Q^B6L.)
+M%VAQR*(R/.^?0*$+ RF_"77:_.!H;*"&0E24U)#\[X*E4Z"U_H9%0IW (462
+M-(G"VS+W+U\TV,+A"9*FD(KT2(1*J!CXXP?/+J&,HB4J; @/PQ4^)^#S?1$Y
+M2"63,P0NR.= 816B"[E/L.:(#+YDR$0@)PEYZ2 \'4HD]*Y!YG0G*ETIU-:I
+M!N5Y.!/CFQ%0@5(95#9"=+Q8H&=S@;Y]VT+>&\1@<9SH<H$K@1<+3$C%Y2:F
+ML?%#%E>>V=%(^%W@4 M!, C^9X>@,.]XD4""*F;$\28JVI+1C&!_1PT&@-50
+M078  X43-"5&<-8)1_(#8R0"C4>.!'&8&G:::(,&Y"CZ4F &HR,JA#KC#'BT
+M^B07&!$0$=P/(5 C?G!RT4)&"EF!JB9MBQ&^X,)34$3C +#QO\!A?S@BE4@4
+MK%0O$#SN[P.)4%3TU0AU!$"""X@;SRLK</MV;1V%)E>D22)31*A(Y(3GN0?*
+MR)8W&/1%HBM%U(SGQR/ P?DH%-!=1I>& 9 D"!?Y'PB"O"IJ5V)UZ*BB2C,(
+M7(#:'.!)II(,0BFP0 %D'G"DBSS4)T,U2-3'R0="V&EZ+M AJ 4YP7]+)$UA
+M(6 F!Y<M*$$H.03+GD# @0XJO61<L$#_N&+0%7_T+"?<4DO<VKRL"FPO5Z[L
+MYM7W9\YLQ*8\2S.8:J'3<:9'63[]>H!!4YD!"+AH*J%=%3Q+:STTZLJ& ^H(
+M$H/Q]M3+^QDZ0TA:E(R5$.$B18!"=T!SI_!1P KR"/(4DBN80$<"ML]L0!W^
+M\61$>B)+/,[7TH&E!>YIAA>X)"SN'FX,S.@R'&C2U"""5B-VH0$<.Z TT=L3
+M:2IUP><OB,"OL,#WOI'/,Z4PWT&)0SETVC)&#@RLI&)P;*VL++H5*N'\S\ZH
+M _4"V"<@$HKN@OL/X,X$^T$>J1[_8 :-_<H!JG+U]-WX,"][>&_K^R<KS=*L
+M%EM#3?T83BB+<GOY]L"RZY&D"^:#EP\^%&B@RSH!9N+R>=9(+^1$<D:0A;IA
+M!R?K$/9<YZGEM-_\<O<#8C65$P^NB[\'%5JXY0O-X31N*&%6I<!) "ZA+L1+
+M/LXB(HMQM2,5^/G]V3R-$':0,!_)WUV'XVXCEKMUW1R=D/ V"*MK+"=,+DQK
+MX)]^GI:F8(UNU,S&UZ*3 IZV?U!)[& B"&1O089,$E1'ARY.6/%D#<>KUHS.
+M"""04_<>[V_.(#5MX-V\B'8 :KL4;%N4T..(7C:0=C0'(7;-27F &!;=P.61
+M\BT(EMR0!M"W?3'FT9(#XU&6HD.6(/K.D4T+3QOHA]_6\28W<787 7/^__F
+MGOO7 TCS0Z(E]L^'1 @HGA^ G"JIKV)51"#1I$<OLB;+CQAV69 Z^FMUK7 8
+MQ-]@0X01!DRNR""&\(,%@AU0"YVFTDHO9+$ #MS^&@B9X ?(OJ>>TY/@ 7;^
+M@0Q-L@RY$%_%QN*6MM!\4KO [Q:L3>O?1+;2$%*;6>!Q6FQJ<B^^(0B:C'4%
+M1W ?J(#(\*ZO\0"U5XXU/=Z);!!&XA24SOV&_O;]@9ZA^]@=\,X0K$JS7X"$
+M567A$!<,8 *#FC>!&#@_>#5'R+$=(#?Q ]5;"T2:L@0?802=6L.<G! E3$?X
+MZ?C03N=ABHSJ[\BL%NF\7@2/F&9P/C3:^.JJ0O T)!EK'3\]31FX1B"*9]$#
+MDM9%;/,48)TLQ\I]*$5)%% X0A3M!Z"3PY]"2=$.(X6OMZ^1]X"EXP'9_@ 4
+M(658M;0&HY1[ +&3W.GZ'50- 7<\."\\\W)W)H\+W.2&T>=HX 3GN#Z^GTU9
+MM/W5/60(/& *I">H6*2X+7"W>.7W\^1^]*?P!]$.Q:D'W%<'1CE; -\#VE@H
+MA>8$4F!\@.LABBT)#EV89 ,A>R>%%IA,J:+"J[I"U -T@6CIN!T"(V?-Z4!&
+M1X$3FB7#-;@\KVV00M-J07AELQ$:X&*@F\4(" (C^.*P@QHP!ZCQ5&AY$ 3(
+M"-#40!.63$X48D!!8$TV1P"#[CX'$#%A '<;":YF/A\=ZW4S@6:KB9(+Q._G
+MM8%!) S3"QS'Q\>ZE"Z"?7P_((I@],&D <$,'1!QM*V"53-$\+60*=0#(1X:
+M64)56BBTO"9I1?CA@Y*O2?  , JX_GX- J%1--5)B(: 6:\OP*K3LJKGOH[!
+MH,$)I OL**&SO-O1N;,&M&UDM,A:)P!U;:"(5+V51AS0P->NY4H-K#A1JTJ>
+M&8&MH@+2_F 7@FE^Q>E71</[ @Q8>&@X0 J.K@GC(V,1V91$(']!)H&<*,>7
+M-V6"Z]>7EVENETC<7EY4X/W]Y'2T-M$M2IV'Z(#+((;I!$P+& "CW6PPH#\]
+M EF\$38@3E>=3-M EHX(#"- -0:0AT+.$PZ"G"ATSPD,Y*"A=!M!2D<D"L)5
+MS^-K/(_-0PV-Y@;4IL#\$#1H7-R/W(PP <6E!IH3)%4[". 5ZA"L(^X3<SW0
+M'N%2V/^C._[7TR1Y <BF=O)]0.VD\W0QCZ!P5,-]3_2($.*Z&=WL")QNCI"#
+M?OEW/]D!T 8Y6YF'K%7*"1":_85.4@R#,X*T!:UD4+E(VOLK9/1@"XRE86@#
+M?)]\1:.FGF%^;PJZ41#*A!M < )K J!0O#4H_4;T*JNN6.@#M4J[L()?R(YV
+MXG3P1KV*N(4.4X**QH7")5)$J^Q]"CB[ _,HK&+[]^@:ZL 1/D"I2G0#XH\1
+MJ*C('%+DD"(DI4%O%": )D*4V@9!07\)$V '^%7^%R7# 0/T"N)'KI]/3R-*
+MF4&\0".* B&EJ>A#9GG RNYB.N>3D"#<]^?.E/39(((\$B:@&OOCGDAM!1.%
+M'9"S"<A5A%;)E[']>5($NL.ZWB7+=UP@@,0&[*#LH*[[ :E1:MM;%6TX$C<)
+M(V%,'CC 1$2,RQ9N("XS?OKOOGB>/P]B<3NR(TP("QA-3/L+8]$9,A DIO_Q
+MY]RB$?#V(+<:?;C>6P?V:VQ)!EA)66L[V;^GM[O:I%8E!$Q?G^VSMQW^Y4@"
+M"B+)N[=5F2OTY0B%EVG#?4&S+Y@S;=$-@#XA3IP1#.;RUX^3<(IP+#[=RU7"
+MYW5P/#3.N/_[W. $,#_04M15O>#AX@8SL/A!"::6KXSG#E2HAW:DP,;?,ZH+
+M$S589G187]-WX\8#1WQPN5A*15V[YC]/>WI,I!]*_@3H$3- F3'LFOH5$A!L
+M $H0^!_TF74%S(K37^Q9TO^Z;03%,M^SGN!@E(= 0P[]M4D#3TASXKN4T9[^
+MONEBA(W99QBELG0%-17@:8M!)EV;DP&O*_^6( NNXX!69)T^>WF KU!+ P0*
+M  0 !@#Z:,<:33MY=.T!  !4 P  !P   '!W;2YD+G-*!QB= _T= QT(!4T&
+M""T'% 4(!@@'%@@&!2@=!"4#!18#%@0%) @$ P0%!@@&!1@-%_V=_OYN!/[^
+M+A<>!PXG!1X&'@8''@=^!?[N#P$" P(# @0#- 8;!;O\_#P&  42]_?WMU&C
+MIO_T%^$DG7=C^]N=PAW;Y!<3,OMA&QTZ[%O6*+5:E'4%+>FA$L]^<;?;9QA?
+M?M_]YF[(CZ6WI(8)%^CKISE7F<OQUO]FZ))>?5GM__UPQK8)LJD7Y[_G0C]=
+MS*XIJZZ>\;2_F4KS"][T3+6[^[8O;CCE^Y;?['9^]5+:FO:1)2A@A94UV"7%
+M58)P!0;]"_,9T>WFHRL.;RZLL,(J$5EAF<Z;ZSVFE$1I$HQ$+A91.3*JTY9,
+M-28_[?N&42:LE\U9I2V_AS;UTKH@^6<IU\H8M3]]Y\;R>X)+\SB@UCZ!Z+DT
+MTF_NT.F?XO;3[C+5[!Q_7^17.>W^33O' CNUR-E<IEH>#-PUL?<WE1OX2][Q
+MI_\^<:8:[>2\#^PEGJ1$C;B6J3K=)0MB7V%-GI9F'/J/F-+-<?C'^UC_)#XV
+M+K"&?@T=\7REG]"GO32,U^$/6]ND'CYFF94&M\CX8-)RH3=P-KPW @^;^]IJ
+MY4)#IU27U<J%F_($XCR!P2]CTP]FDX3"!&93#4L!4$L#! H !  & /9HQQIR
+MY4!WL@(  (<%   (    <'=M,BYC+G-,!QB=!/T= QT(!BT7)@@6% 46" 8(
+M!@@6*!T$!10#)@,&" 0&) 8%! ,%%A08#1C]_3W^S@7^_@X(#A<>!PX'#@<&
+M'@8>!@<>!WX&_NX. 1)#! ,'%0P$/ :L_?T%#0 " P8#!@<&%P;W]_='D2,7
+M[ 4_PDVY_S7=*]_$-YST'Q,J=H=M=)BP?]URJM6<;0--Z.3;_OA7;F\__%+[
+MVG_B^M^51LKS?O(;YJ?\Z<\R_KYTNM+YX$]K_E3]<<FO_"S/FZK&+Y:?Y.>?
+MJ73J/]?S^-K<_P.I?_O.N4,*Q25^2>S&>TK3^WTJ:-HW]\/$MF,]\VO.FODC
+M+5U7[IN(QM$;\IWYF_MR?^)25]Z/>W]>AM^-2_TS0JC<\UNG^UJ;]OSDFY+\
+M$TH+W->Y=/Y[L2^G_,)U@\A[U]_A%(,N%J8NN[IC=LO8=',:VKS]U)!)W?<[
+MW+,7QVGY(3(?E59^0OX_OK_S^^M>;,_R"Z>L+8N2*U%I\=7=W(+Q#JYMV6N&
+MJP7E"@6[)RYW0%>9NJY)=7-CA2NL%B@K/-.M(/XF%4J,5AS\;LG!47(&)6,L
+MA:D$XTQ4K:+BB5JRUJBT&" W_2 4(+5LJ:I"DRU_E]8+IVV5ZHN5;65"[5[0
+MUL/\O^#2//2HM?? D=P$MA=?7]8_ ZF?I<:8SM)$I>4V1-9*.%[%5JKU-,K7
+M<E[;,B+2>/YK?E[Y40T73HU*BR:SW<7).&'9*B_AI[=!WH[#CK.CTHC:-39<
+M$%_##[">1IRJXKSLHBKF:OKH_9S8_4@(25X3D1-,F9Z2=Z4;?_K,XI-.6Y.D
+MK)E>@VSC*N$3\@V;%SY/*\,SSIX^]</S\+YJ[EC'ULE<997\U2&.*3PMAW-X
+M;T!P5[.-YY3*BONREKWK1F6EXCQZ."<QO(XQ.YK1DA)'-&/,] 502P,$"@ $
+M  8 ^FC'&LJ@5',0 @  _@,   @   !P=VTX+F0N<T<^!WX#_@X' QX'!DX&
+M!RX&) <&!P8'!@<&!2<> P85 R8#%@0&) <D%@<%!A<.%_Y^__^/!/__+Q<?
+M!P\G!A\&'Q8?!G\%_^\/ 2(3! ,$ R4,!WP&7/W]'0H $@87!@<&]_?W9]&B
+M%_R"%VQG['=*_>EVRAF;[!<?D_!A&Q<P\%O6_'G.7U?0DAZ;OMN7=+IV#^-+
+M;D_[;C<DC^6W1 P4)-3KIYN8=2NIUO]ZZ#)>X;+:__MACTT=KB[,O+^]*?UT
+M,+OFK+K9XVY^/97OBVIZL=J=]C0O:=B5\Y9?M\U]A>6\->\C:WC@P.H:><EQ
+MU;"N8(2?<O>(+FY;5QW:7%FA+%8-S@I5Z!:N]@A3(J50) E?,C-1.1=5\I9B
+M-3YY:L\;1AF?]'PQ9Q5_R\^F=6%Y79#^2CE6)M3^@C9QK+PGN#2/ VKM'5+/
+MD1"_/D.G?XZ%?>V(I^TL\:LFW-3S<E_6;MI?-[=$+A1^FYM8K%8&%6>5W/XZ
+MZX1YV6WJ[K^8S\5JG)QW'_JE[XQT'Y_G8E6N+@E$[BZE('M:S/8X]!PAS=)>
+MET\BT.09989E4Q;W>![_7UW%/,"9P;]T9=;R,!Z(.D,$G.&^Q$V>@0ATV!"A
+M$D0R?US_>@-Y*WBAM8XGK#C*HI4Q<26EUW(;U!L&-Y#]>55QX:'3<W1955RJ
+M*Q.=>QK#&YCS:<R:EC+1F.-F*E!+ 0(* PH    !  -IQQIT41>R90   &L
+M   ,              "D@0    !D:6=I+20Q,C P+F]02P$""@,*    !@#\
+M:,<:E85SFV$!  !R @  #               I(&/    9&EG:2TD,3(P,"YS
+M4$L! @H#"@ $  8 ^6C'&FM^*+ + @  > ,   L              *2!&@(
+M '!W;2TD,3(P,"YS4$L! @H#"@ $  8 _&C'&O9"0BNQ @  \ 8   P
+M         *2!3@0  '!W;2TR8VEA+F0N<U!+ 0(* PH !  & /=HQQKFO<<O
+M:P(  &D%   +              "D@2D'  !P=VTM8VEA+F8N<U!+ 0(* PH
+M!  & /=HQQJHW6A*AP(  .0%   +              "D@;T)  !P=VTM8VEA
+M+F<N<U!+ 0(* PH  @ &  IIQQK396D>>SL   )0   '              "D
+M@6T,  !P=VTM:FUJ4$L! @H#"@ $  8 ^FC'&DT[>73M 0  5 ,   <
+M         *2!#4@  '!W;2YD+G-02P$""@,*  0 !@#V:,<:<N5 =[("  "'
+M!0  "               I($?2@  <'=M,BYC+G-02P$""@,*  0 !@#Z:,<:
+MRJ!4<Q "  #^ P  "               I('W3   <'=M."YD+G-02P4&
+/  H "@ O @  +4\
+end
+.......
+....
+..
+.                                    C=H #20
+::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
+cu next time!
+-S
+.......
+....
+..
+.                                    - fin -
+</code>