initial checkin

2 files changed, 610 insertions, 0 deletions

diff --git a/doc/6502_org_source_general_clockfreq.txt b/doc/6502_org_source_general_clockfreq.txt
new file mode 100644
index 0000000..389d8a3
--- /dev/null
+++ b/doc/6502_org_source_general_clockfreq.txt
@@ -0,0 +1,201 @@
+   [1][Return to Main Page]
+
+   Calculation of Clock Frequency by Leo Nechaev
+   [2][Up to Source Code Repository]
+     __________________________________________________________________
+
+   This program calculates the clock frequency of 6502-based system. The
+   result is stored in location 'Ticks' to 'Ticks+3' in BCD representation
+   ('Ticks' - 2 symbols before decimal point, 'Ticks+1' to 'Ticks+3' - 6
+   symbols after point), then result is sent via UART to the host (usually
+   PC with some kind of terminal programm).
+
+   With minimal modifications (deleting 'SED' and 'CLD' instructions,
+   changing ticks constants [from BCD to binary format], deleting
+   'terminal' subroutines) it may be used to determine real speed of
+   processor.
+rgConfig        =       $6000   ; write: D6=1 - NMI is off, D6=0 - NMI is on
+rgStatus        =       $6000   ; read:  D6=0 - UART is busy
+rgTxD           =       $5000   ; write: data to send via UART
+
+vcNMI           =       $FFFA
+
+Refresh         =       450     ; NMI rate in Hz
+
+        ldx     #<NMI           ; installing the NMI vector
+        ldy     #>NMI
+        stx     vcNMI
+        sty     vcNMI+1
+        lda     #$40            ; on start NMI is off
+        sta     InUse
+
+Again
+        lda     #0
+        sta     Flag
+        sta     Ticks           ; initializing counter
+        sta     Ticks+1
+        sta     Ticks+2
+        sta     Ticks+3
+        lda     #$FE            ; initializing NMI counter (zeropoint minus 2 ti
+cks)
+        sta     Timer
+        lda     #$FF
+        sta     Timer+1
+        lda     InUse           ; turn on NMI
+        and     #$BF
+        sta     rgConfig
+        sta     InUse
+
+-       bit     Flag            ; waiting for zeropoint minus 1 tick
+        bpl     -
+        lda     #0
+        sta     Flag
+
+-       bit     Flag            ; waiting for true zeropoint
+        bpl     -
+        lda     #0
+        sta     Flag
+
+Main                            ; main counting cycle
+;number of ticks per command   sum of ticks
+;                          v   v
+        lda     Ticks     ;4
+        clc               ;2   6
+        sed               ;2   8
+        adc     #$53      ;2  10
+        sta     Ticks     ;4  14
+        lda     Ticks+1   ;4  18
+        adc     #0        ;2  20
+        sta     Ticks+1   ;4  24
+        lda     Ticks+2   ;4  28
+        adc     #0        ;2  30
+        sta     Ticks+2   ;4  34
+        lda     Ticks+3   ;4  38
+        adc     #0        ;2  40
+        sta     Ticks+3   ;4  44
+        cld               ;2  46
+        bit     Flag      ;4  50
+        bpl     Main      ;3  53
+
+        lda     #0        ;2
+        sta     Flag      ;4   6
+        lda     Ticks     ;4  10
+        clc               ;2  12
+        sed               ;2  14
+        adc     #$95      ;2  16
+        sta     Ticks     ;4  20
+        lda     Ticks+1   ;4  24
+        adc     #0        ;2  26
+        sta     Ticks+1   ;4  30
+        lda     Ticks+2   ;4  34
+        adc     #0        ;2  36
+        sta     Ticks+2   ;4  40
+        lda     Ticks+3   ;4  44
+        adc     #0        ;2  46
+        sta     Ticks+3   ;4  50
+        cld               ;2  52
+        lda     Timer     ;4  56
+        cmp     #<Refresh ;2  58
+        bne     Main      ;3  61 + 34 (from NMI ISR) = 95
+        lda     Timer+1   ; 4
+        cmp     #>Refresh ; 2
+        bne     Main      ; 3
+
+        lda     InUse           ; turn off NMI
+        ora     #$40
+        sta     rgConfig
+        sta     InUse
+
+        ldx     #0              ; send first string to the host
+-       lda     Mes1,x
+        beq     +
+        jsr     Send
+        inx
+        jmp     -
+
++       lda     Ticks+3
+        pha
+        lsr
+        lsr
+        lsr
+        lsr
+        beq     +               ; delete non-significant zero (clock < 10MHz)
+        jsr     PrintDigit
++       pla
+        and     #15
+        jsr     PrintDigit
+        lda     #"."            ; decimal point
+        jsr     Send
+        lda     Ticks+2
+        jsr     PrintTwoDigits
+        lda     Ticks+1
+        jsr     PrintTwoDigits
+        lda     Ticks
+        jsr     PrintTwoDigits
+
+        ldx     #0              ; send second string to the host
+-       lda     Mes2,x
+        beq     +
+        jsr     Send
+        inx
+        jmp     -
++       jmp     Again           ; repeat process
+
+PrintTwoDigits
+        pha
+        lsr
+        lsr
+        lsr
+        lsr
+        jsr     PrintDigit
+        pla
+        and     #15
+        jsr     PrintDigit
+        rts
+
+PrintDigit
+        ora     #$30
+        jsr     Send
+        rts
+
+Send
+        bit     rgStatus
+        bvc     Send
+        sta     rgTxD
+        rts
+
+Mes1
+        .db     13
+        .tx     "Current clock frequency is "
+        .db     0
+
+Mes2
+        .tx     " MHz"
+        .db     0
+
+Ticks   .br     4,0
+Timer   .br     2,0
+InUse   .db     0
+Flag    .db     0
+
+NMI                        ;6
+        pha                ;3   9
+        inc     Timer      ;6  15
+        bne     +          ;3  18
+        inc     Timer+1    ; 5
++       lda     #$80       ;2  20
+        sta     Flag       ;4  24
+        pla                ;4  28
+        rti                ;6  34
+
+   Test results:
+     * with chip oscillator "1.8432" the result is '1.843266 MHz'
+     * with chip oscillator "20.000000M" and divider by 10 the result is
+       '2.000040 MHz'
+
+   Last page update: December 27, 2000.
+
+References
+
+   1. http://6502.org/
+   2. http://6502.org/source
diff --git a/doc/www.ganssle.com_articles_anmi.txt b/doc/www.ganssle.com_articles_anmi.txt
new file mode 100644
index 0000000..034ffdf
--- /dev/null
+++ b/doc/www.ganssle.com_articles_anmi.txt
@@ -0,0 +1,409 @@
+   [1]The Ganssle Group logo
+   [2]The Ganssle Group logo
+     * [3]Click here for a navigation menu
+
+     * [4]Firmware
+       Classes
+          + [5]Public Training
+          + [6]On-Site Training
+     * [7]Newsletter
+          + [8]Subscribe
+          + [9]Back Issues
+     * [10]Expert
+       Witness
+     * [11]Blog
+     * [12]Videos
+     * [13]Tool & Book
+       Reviews
+          + [14]Tool Reviews
+          + [15]Jack's Books
+          + [16]Other Embedded Books
+     * [17]Special
+       Reports
+          + [18]Designing Ultra-Low Power Systems
+          + [19]Surprising Scope Probe Issues
+          + [20]2020 Salary Survey
+          + [21]Debouncing Contacts
+          + [22]Watchdog Timers
+          + [23]Microprocessor History
+          + [24]Being a Consultant
+          + [25]Write-only Memory
+          + [26]Process Improvement for the Boss
+          + [27]Commenting Code
+          + [28]Testing RAM
+          + [29]Getting Into Embedded Work
+          + [30]Code Inspections
+          + [31]Automatic Bug-Finding
+          + [32]eXtreme Instrumenting
+          + [33]Math Approximations - Trig
+          + [34]Math Approximations - Other Functions
+          + [35]Better Resumes
+     * [36]Articles
+          + [37]All Articles
+          + [38]Analog, Filtering, etc
+          + [39]Communications
+          + [40]Debugging
+          + [41]Fun Embedded Stuff
+          + [42]Hardware
+          + [43]Historical
+          + [44]Managing Projects
+          + [45]Math in Computers
+          + [46]Memory
+          + [47]Philosophical and Career
+          + [48]Real Time
+          + [49]Software & Firmware
+          + [50]Tools for Embedded Developers
+          + [51]Sailing!
+     * [52]Random
+       Rants
+          + [53]Electronics
+          + [54]Business Issues
+          + [55]Software Engineering
+          + [56]Products and Reviews
+          + [57]Philosophy of Engineering
+          + [58]Miscellaneous
+          + [59]History of Electronics and Embedded
+          + [60]Software
+          + [61]Random Thoughts
+          + [62]Fun Stuff
+          + [63]Real-Time Issues
+     * [64]Humor
+     * [65]Contact/Search
+          + [66]Contact Info
+          + [67]Advertise With Us
+          + [68]Search This Site
+          + [69]Jack's Bio
+          + [70]Expert Witness
+          + [71]Our Privacy Policy
+
+The Perils of NMI
+
+   NMI is a critical resource, yet all too often it's misused.
+
+   Published in Embedded Systems Programming, April 1991
+   For novel ideas about building embedded systems (both hardware and
+   firmware), join the 40,000+ engineers who subscribe to [72]The Embedded
+   Muse, a free biweekly newsletter. The Muse has no hype and no vendor
+   PR. [73]Click here to subscribe.
+   LA104 Logic Analyzer October's giveaway is a LA104 mini logic analyzer.
+   I reviewed it in [74]Muse 406. .Enter the contest [75]here.
+
+By Jack Ganssle
+
+   Wise amateurs fear [76]interrupts. Fools go where wise men fear to
+   tread. Normal sequential code is hard enough to understand, code, and
+   debug. Toss in a handful of asyncronous events that randomly change the
+   processor's execution path, perhaps thousands of times per second, and
+   you have a recipe for disaster.
+
+   Yet interrupts are an important fact of life for all real time systems.
+   No experienced programmer would dream of replacing a clean interrupt
+   service routine with polled I/O, particularly where fast I/O response
+   is required.
+
+   In fact, interrupts are the both the best and worse microprocessor
+   feature. Well thought out interrupt-driven code will be reasonably easy
+   to write, debug and maintain. A poorly conceived interrupt routine is
+   probably the worst possible software to work on. Because interrupts are
+   so important to embedded systems, it is vital to become proficient with
+   their use.
+
+   If interrupts are tough to work with, then the non-maskable interrupt
+   (NMI) is the true killer of the business. Be careful before you connect
+   a peripheral to your processor's NMI input - think through the problems
+   carefully.
+
+   Almost every processor has some sort of NMI signal, though it may be
+   called something else. On the 68000, a level 7 interrupt cannot be
+   masked, and is equivalent to NMI. Some 8051-family CPUs have no
+   non-maskable interrupt, an idea that is sort of appealing in terms of
+   enforcing interrupt discipline.
+
+   I'm a firm believer in restricting NMI to those conditions that are
+   truly unusual and of momentous importance. Quite a few designers use
+   NMI as a general purpose interrupt, a practice that usually spells
+   disaster.
+
+   When timing gets tight, the code can easily disable a conventional
+   interrupt. Indeed, the very assertion of an interrupt signal
+   automatically turns all interrupts off until the software explicitly
+   reenables them, giving the code a clean window to process a high
+   priority task. Not so with NMI. An NMI at any time will interrupt the
+   CPU - no ifs, ands or buts. As long as the hardware supplies NMIs to
+   the processor, it will stop whatever it's doing and vector through the
+   NMI handler.
+
+   The very fact that NMI can never be disabled makes it ideal for
+   handling a small but vital class of extremely high priority events.
+   Chief among these is a power failure. If a system must die gracefully,
+   then hardware that detects the imminent loss of power can assert NMI to
+   let the software park disk heads, put moving sensors into a "safe"
+   state, copy important variables from RAM to non-volitile storage, and
+   generally prepare for being down.
+
+   Modern power supplies have little reserve capacity. Old linear designs
+   had massive filtering capacitors that acted like batteries with several
+   seconds of reserve capacity. Today's off-line switchers use
+   comparatively tiny capacitors; smart electronics does the filtering.
+   When the AC power goes down, the switcher's output quickly follows
+   suit.
+
+   During the short time it takes for power to trail away the code may
+   very well be executing with interrupts disabled. Only NMI is guaranteed
+   to be available at all times. Power fail is such an important event,
+   that NMI is really the only option for notifying the software of
+   power's impending demise.
+
+   Perhaps more should be said about power fail circuits at this point,
+   since so many suffer from serious design flaws. Most embedded systems
+   ignore power fail conditions. Running ROM based code with no dangerous
+   or critical external hardware, they can restart without harm from the
+   top when power resumes. However, two types of systems require
+   power-fail management hardware and software. The first category are
+   those systems controlling moving objects; a disk controller should park
+   the head, a robot should stop all motors, and an X-ray system should
+   shut down the beam.
+
+   The other class are systems that preserve transient data through a
+   power-up cycle. A data acquisition system might need to keep logged
+   data even when power goes down, an instrument sometimes has to save
+   painfully collected calibration constants, and a video game should
+   remember high scoring individuals' initials and totals.
+
+Decaying Power
+
+   Far too many designs rely on nothing more than battery backed up static
+   RAMs or some true non-volitile device like an EEPROM to store data
+   through multiple on/off cycles. More often than not these schemes work,
+   but all will sooner or later fail. Let's consider what happens when the
+   AC power fails.
+
+   Without AC, the power supply stops working. The computer continues to
+   run from the energy stored in the supply's output capacitor. The amount
+   of time left before the computer goes haywire is proportional to the
+   size of the capacitor in microfarads and inversely proportional
+
+   Until the computer's 5 volts decays to about 4.75 it continues to run
+   properly. At the 4.75 volt level most of the system's chips are no
+   longer operating in their design region. No one can predict what will
+   happen with any certainty.
+
+   At about 4.8 to 4.9 volts the well-designed power fail circuit will
+   inject an NMI into the computer (some detect missing AC cycles, a
+   better but more expensive approach). Probably the system has only
+   milleseconds before Vcc decays to the 4.75 volt region of instability.
+   The NMI routine should quickly shut down external events and save
+   critical variables.
+
+   After processing the power fail condition, the computer and external
+   I/O is all in a safe state. The voltage level continues to decline past
+   4.75 volts, eventually reaching zero. Unfortunately, the supply's
+   capacitor decays exponentially. It will provide something between zero
+   and 4.75 volts for a comparatively long time (perhaps seconds).
+
+   What does the CPU chip, memories, and glue logic do with, say, 4 volts
+   applied? No one knows. No vendor will guarantee any behavior under the
+   4.75 volt level. Frequently the program just runs wild, executing
+   practically random instructions. Your carefully saved data or
+   meticulously protected I/O could be destroyed by rogue instructions!
+
+   No power fail circuit is complete unless it clamps the reset line
+   whenever power is less than the magic 4.75 volt level. A suitable
+   circuit keeps the CPU in a reset state, preventing wild execution from
+   corrupting the efforts of the NMI power save routine. Motorola sells a
+   3-terminal reset controller for less than a dollar which will hold
+   reset down in low Vcc conditions.
+
+   Consider another case: suppose the power grid's sadly overload
+   summertime generating capacity experiences a brownout. If the line
+   drops from 110 VAC to, say, 80 volts, what happens to the +5 volt
+   output from your system's power supply? Most likely it will go out of
+   regulation, giving perhaps 3 or 4 volts until the 110 input level is
+   reestablished. Hopefully the power fail circuit will assert an NMI to
+   the processor chip. Using the conventional resistor/capacitor unclamped
+   reset circuit, the reset input will decline only to the 3-4 volt level,
+   not nearly low enough to force a reset when power comes back.
+
+   The reset clamping circuit will not only keep the CPU in a safe state;
+   in this brownout case it will also insure that the system restarts
+   properly when +5 volts is reestablished.
+
+   Regardless, NMI is the only reasonable interrupt choice for power fail
+   detection.
+
+NMI Abuse
+
+   Unfortunately, NMI is widely abused as a general purpose interrupt. Use
+   NMI only for events that occur infrequently. Never substitute it for
+   poor design.
+
+   It's not too unusual to see a divider circuit driving NMI, generating
+   hundreds or thousands of interrupts per seconds. Usually these designs
+   start life using a reasonable maskable interrupt. As the programmers
+   debug the system they find the CPU occasionally misses an interrupt, so
+   they switch over to NMI. This is a mistake. If the code misses
+   interrupts, there is a fundamental flaw in its design that NMI will not
+   cure.
+
+   Your code will miss interrupts only if some bottleneck keeps them
+   disabled for too long. Always design the code to keep interrupts
+   disabled only while servicing the hardware. Reenable them as soon as
+   possible. With good reentrant design, interrupts should never be off
+   for more than a few tens of microseconds.
+
+On the Edge
+
+   Quite a few processors implement NMI as an edge sensitive interrupt.
+   This guarantees that even a breathtakingly short pulse will set the
+   CPU's internal NMI flip flop, so the interrupt simply cannot be missed.
+   It might, however, cause several kinds of nasty problems.
+
+   Suppose the input comes from the real world, perhaps after having been
+   transmitted a few feet. Without proper pulse shaping circuitry, the
+   signal could easily have ragged edges or even multiple, closely spaced
+   transitions. Maskable interrupts live quite happily with short bouncing
+   on their lines, since the first transition will make the processor
+   disable the input and start the ISR. Even the fastest code will take a
+   few microseconds to service and reenable the interrupt, by which time
+   the transients will be long gone. NMI cannot be disabled; every bit of
+   bounce will reinitiate the NMI service routine. The result: one real
+   interrupt might masquerade as several independent NMIs, each one
+   pushing onto the stack and recalling the ISR.
+
+   Edge sensitive inputs respond when the input voltage crosses some
+   threshold. Imperfect digital circuits give a rather broad window to the
+   threshold. If the NMI input signal is perfectly clean but moves slowly
+   from the idle to the asserted state, it stays within the threshold
+   region for far too long, sometimes causing multiple NMI triggers.
+
+   Finally, the edge sensitive nature of the NMI signal renders it
+   susceptible to every stray bit of electrical noise. A clean NMI driven
+   by a gate on the other side of a circuit board might pick up unexpected
+   noise from other parts of the circuit.
+
+   Edge sensitive NMI inputs must be clean, noise free, and should switch
+   quickly and cleanly.
+
+   Remember that debugging NMI service routines is sometimes tough. How
+   will you single step in an NMI service routine if, while debugging,
+   dozens more NMIs keep coming? Most of us debug code by stopping at a
+   breakpoint and looking at the registers and variables. If, when
+   debugging the NMI handler, another comes along while we're stopped,
+   after resuming execution the service routine will re-invoke itself,
+   probably corrupting a non-reentrant value.
+
+   In summary, NMI is a valuable feature. Don't abuse it; restrict its use
+   to those few situations where only an NMI will solve a problem.
+
+   Do you need to eliminate bugs in your firmware? Shorten schedules? My
+   [77]Better Firmware Faster seminar will teach your team how to operate
+   at a world-class level, producing code with far fewer bugs in less
+   time. It's fast-paced, fun, and covers the unique issues faced by
+   embedded developers. [78]Here's information about how this class,
+   taught at your facility, will measurably improve your team's
+   effectiveness.
+
+   Free Embedded Muse newsletter - twice/monthly, hard-hitting technical
+   info that goes to 40,000+ engineers. Click [79]here to sign up or enter
+   your email here:
+   ____________________ Submit
+
+   Latest [80]Embedded Muse: Replies to 'Is Assembly Dead' and 'on Taking
+   Charge'.
+
+   Latest [81]blog: Is a heart rate of 72,123 beats per minute possible?
+
+   [82][ganssle-dot-com-ad.jpg] Advertise with us! Reach 200K embedded
+   developers per month. More info [83]here.
+     __________________________________________________________________
+
+   The Ganssle Group - [84]info@ganssle.com - copyright TGG, all rights
+   reserved. Contact info [85]here.
+
+References
+
+   1. http://www.ganssle.com/
+   2. http://www.ganssle.com/
+   3. http://www.ganssle.com/navigation.html
+   4. http://www.ganssle.com/onsite.htm
+   5. http://www.ganssle.com/classes.htm
+   6. http://www.ganssle.com/onsite.htm
+   7. http://www.ganssle.com/tem-subunsub.html
+   8. http://www.ganssle.com/tem-subunsub.html
+   9. http://www.ganssle.com/tem-back.htm
+  10. http://www.ganssle.com/expertwitness.html
+  11. http://www.ganssle.com/blog/index.html
+  12. http://www.ganssle.com/video/video-list.html
+  13. http://www.ganssle.com/tools.htm
+  14. http://www.ganssle.com/tools.htm
+  15. http://www.ganssle.com/book.htm
+  16. http://www.ganssle.com/bkreviews.htm
+  17. http://www.ganssle.com/spcl_reports.htm
+  18. http://www.ganssle.com/reports/ultra-low-power-design.html
+  19. http://www.ganssle.com/item/perils-of-scope-probes.html
+  20. http://www.ganssle.com/salsurv2020.html
+  21. http://www.ganssle.com/item/debouncing-switches-contacts-code.htm
+  22. http://www.ganssle.com/item/great-watchdog-timers.htm
+  23. http://www.ganssle.com/item/history-of-the-microprocessor.html
+  24. http://www.ganssle.com/item/becoming-a-consultant.htm
+  25. http://www.ganssle.com/misc/wom.html
+  26. http://www.ganssle.com/item/guide-to-managing-firmware-teams.htm
+  27. http://www.ganssle.com/item/writing-great-comments-firmware.htm
+  28. http://www.ganssle.com/item/how-to-test-ram.htm
+  29. http://www.ganssle.com/item/becoming-an-embedded-developer.htm
+  30. http://www.ganssle.com/inspections.htm
+  31. http://www.ganssle.com/item/automatically-debugging-firmware.htm
+  32. http://www.ganssle.com/item/instrumenting-firmware-for-debugging.htm
+  33. http://www.ganssle.com/item/approximations-for-trig-c-code.htm
+  34. http://www.ganssle.com/item/approximations-c-code-exponentiation-log.htm
+  35. http://www.ganssle.com/item/creating-great-resumes.htm
+  36. http://www.ganssle.com/articles-subj.htm
+  37. http://www.ganssle.com/articles.htm
+  38. http://www.ganssle.com/articles-subj.htm
+  39. http://www.ganssle.com/articles-subj.htm#Communications
+  40. http://www.ganssle.com/articles-subj.htm#Debugging
+  41. http://www.ganssle.com/articles-subj.htm#Fun
+  42. http://www.ganssle.com/articles-subj.htm#Hardware
+  43. http://www.ganssle.com/articles-subj.htm#Historical
+  44. http://www.ganssle.com/articles-subj.htm#Managing
+  45. http://www.ganssle.com/articles-subj.htm#Math
+  46. http://www.ganssle.com/articles-subj.htm#Memory
+  47. http://www.ganssle.com/articles-subj.htm#Philosophical
+  48. http://www.ganssle.com/articles-subj.htm#realtime
+  49. http://www.ganssle.com/articles-subj.htm#Processes
+  50. http://www.ganssle.com/articles-subj.htm#Tools
+  51. http://www.ganssle.com/jack/
+  52. http://www.ganssle.com/randomrants.htm
+  53. http://www.ganssle.com/randomrants.htm#electronics
+  54. http://www.ganssle.com/randomrants.htm#business
+  55. http://www.ganssle.com/randomrants.htm#softwareengineering
+  56. http://www.ganssle.com/randomrants.htm#products
+  57. http://www.ganssle.com/randomrants.htm#philosophy
+  58. http://www.ganssle.com/randomrants.htm#misc
+  59. http://www.ganssle.com/randomrants.htm#history
+  60. http://www.ganssle.com/randomrants.htm#software
+  61. http://www.ganssle.com/randomrants.htm#random
+  62. http://www.ganssle.com/randomrants.htm#fun
+  63. http://www.ganssle.com/randomrants.htm#realtime
+  64. http://www.ganssle.com/jokes.htm
+  65. http://www.ganssle.com/contact.htm
+  66. http://www.ganssle.com/contact.htm
+  67. http://www.ganssle.com/advertise.html
+  68. http://www.ganssle.com/search/search.html
+  69. http://www.ganssle.com/bio.htm
+  70. http://www.ganssle.com/expertwitness.html
+  71. http://www.ganssle.com/privacy-policy.html
+  72. http://www.ganssle.com/tem-subunsub.html
+  73. http://www.ganssle.com/tem-subunsub.html
+  74. http://www.ganssle.com/tem/tem406.html#article4
+  75. http://www.ganssle.com/contest.html
+  76. http://www.ganssle.com/articles/aintrp.htm
+  77. http://www.ganssle.com/onsite.htm
+  78. http://www.ganssle.com/onsite.htm
+  79. http://www.ganssle.com/tem-subunsub.html
+  80. http://www.ganssle.com/tem/tem407.html
+  81. http://www.ganssle.com/blog/blog/heart-rate.html
+  82. http://www.ganssle.com/advertise.html
+  83. http://www.ganssle.com/advertise.html
+  84. mailto:info@ganssle.com
+  85. http://www.ganssle.com/contact.htm