|
| |
M. D. O'Connor's TD Analysis Report
|
|
|
|
Introduction: |
M. D. O'Connor is the author of the free TD Analysis Report
entitled "Time Dilation, Technical Dilation, and Corporate Dilation." It is
an exhaustive report based on both textual and test research on the subject
of Time Dilation. Mr. O'Connor was involved with a research group in 1997
soon after the Time Dilation discovery.
This document is intended to put to rest public apprehensions of a "fallout"
from a computer anomaly first known as "Time Dilation" (TD), now renamed
"Time and Date Instabilities" but retaining the acronym "TD." It is also
called the "Crouch-Echlin Effect."
Randall Bart first coined the term "Time Dilation" at the time of the
discovery. In Einsteinian physics, it refers to the phenomenon where an
observer moving at high speed or in a strong gravity experiences time at a
different rate than another observer in another frame of reference. At the
time of the discovery, it was a reference to the RTC chip that is
"experiencing time" at a different rate than our perception of time.
However, the term is not an accurate representation of the anomaly,
therefore it was renamed "Time and Date Instabilities" by Mr. Jace Crouch.
O'Connor's report shows the following:
|
|
|
|
|
One Symptom, One Cause: |
There is only one TD anomaly symptom: a substantial change
in system time/date information forward or backward relative to the true
date/time. This symptom is observable by examining the system date and time
on a computer after a computer boot. A TD anomaly occurs only during
a computer boot. The fact that it occurs only during a computer boot points
to a singular cause, because the same number of the same processes occur
in the same sequence in every computer power-up. The TD anomaly is a
random event and is not repeatable.
This singular cause is the BIOS code that, during computer boot, does not
properly avoid the small segment of time occurring every second, in which
the Real Time Clock (RTC) is updating itself with the date and time. Another
cause is the system interrupts are not disabled before RTC is read for the
time or date information. A third cause is the lack of, or too little, I/O
delay between back-to-back RTC instructions. The nature of date or time
retrieval with respect to the Update In Progress (UIP) bit in the RTC makes
the TD anomaly a random event.
Causes other than defined above, such as "bus fights" or CMOS memory
corruption, are not valid causes of the TD anomaly, because the TD anomaly
occurrence is limited to during a computer power-up (not a
warm-boot). A bus fight can occur at any time, usually during computer
operation, but if it occurs, the computer will hang. CMOS memory corruption,
if it occurs, will affect more than just the time and date information
within the RTC, and the time and date information cannot be selectively
corrupted without affecting other areas of CMOS memory.
Current spikes, if any, resulting from turning on the power to a computer is
also an unlikely cause of the anomaly for the same reason: the time and date
cannot be selectively affected within the RTC without affecting the rest of
the chip. The use of diodes in the power distribution circuit (where a
rechargeable battery is included) prevent reverse current from occurring
during computer power-up. In addition, the power supply itself is a
computer-grade unit designed for this purpose. Still furthermore, if current
spikes are responsible for the TD anomaly, why are we not seeing this
anomaly on computers with buffered RTC chips?
O'Connor's report shows that, technically, a TD anomaly is specifically
defined as a large difference in time or date between the RTC and BIOS/DOS.
But a TD anomaly can be falsely identified by a misdiagnosed symptom. An
example of this is a dying battery in the computer. There are other cases of
similar symptoms that have nothing to do with TD. If there is a way to
properly diagnose a TD anomaly, it is this: if the system date or time shows
an advanced date or time relative to the true date or time, it is proof
positive of a TD anomaly. On the other hand, if the system date or time has
retrogressed instead of advanced, it is not proof of a TD anomaly because
any number of causes apply which have nothing to do with TD. Hence, for a
retrogressed date or time symptom, further investigation is warranted. This
investigation should begin with an immediate examination of the RTC and BIOS
information. If the RTC/BIOS information are consistent to within 2 seconds,
there is no TD anomaly, even if the RTC information shows an incorrect time
or date.
The TD definition has changed or expanded at most three times since the
discovery. The current definition, as defined by the Crouch-Echlin group,
now includes multiple causes and symptoms of the anomaly, but without
specifying what these are. But these causes, identified in O'Connor's
report, were well known by software experts before the discovery.
The lack of a well-defined TD definition unfortunately means, and in fact
causes, false TD reports to be submitted by persons with insufficient
understanding of the TD anomaly. The definition is not properly defined, and
the name "Time and Date Instabilities" implies more than one problem or
cause, which is not true.
See O'Connor's report for more details. |
|
|
TD Anomaly in Intel's Test Data: |
Intel's free report includes test data based on "Manual
Cycling" methodology, which was conducted on Mike Echlin's Zenith 286 CPU #2
board.
Critical analysis of Intel's test data in their report in Appendix C (pages
16-17) indeed shows strong evidence of time-related TD anomaly. In fact, it
shows evidence of two, not one, separate anomalies:
1. Echlin's 286 BIOS time conversion anomaly (which Intel
reported), and
2. TD anomaly as an advanced time anomaly
(which Intel overlooked).
Below is a plot taken from O'Connor's report. This plot is based solely on
Intel's test data with reconstructed wristwatch seconds of time. The
wristwatch seconds of time is not recorded in Intel's test data. The
wristwatch seconds of time is reconstructed based on Intel's 0.036% offset
theory, and is explained in O'Connor's report.
In its report, Intel called attention to Echlin's Zenith 286 BIOS conversion
anomaly, which O'Connor's report calls the "0.036% offset theory." The BIOS
conversion anomaly causes a 0.036% error in DOS time relative to the RTC
time. Note that the BIOS conversion anomaly is not the cause of the
TD anomaly, because the maximum offset error on any given day is no more
than 31 seconds.
Because the 0.036% offset error is linearly proportional to the time of
day, it is possible to reconstruct the wristwatch seconds of time
to show when the DOS-reported time was recorded in Intel's data. The result
is this plot shown below.
The blue plot represents the delta time in seconds between the wristwatch
reference time and calculated DOS-reported
time of day based on Intel's 0.036% offset theory. The red plot is the delta
time in seconds between the wristwatch reference time and
actual DOS-reported time of day. The zero reference line in the
plot means there is no deviation in time between the reference time and
DOS-reported time.
Data points above the zero reference line indicate an
advanced time anomaly. Data points below this line indicate a
retrogressed time anomaly. The fact that the blue line stays below the
zero reference line makes sense, since the Zenith BIOS conversion formula
(cited in Intel's report) is always 0.036% less than it should be relative
to the DOS conversion formula (also cited in Intel's report).
The plot shows proof positive that not just the BIOS conversion anomaly is
being exhibited, but also that an advanced time anomaly
is being exhibited. This is the reason Intel presented the BIOS conversion
anomaly in terms of a theory
without raw data to back it up.
The red plot follows the blue plot in most places. This is the result of the
reconstruction of the wristwatch seconds of time based on Intel's 0.036%
offset theory.
However, the red plot departs from the blue plot in several places. This is
the result because the wristwatch seconds of time cannot be reconstructed,
and therefore remains set at zero seconds (Intel did not record the
wristwatch seconds of time, therefore zero seconds is assumed). The reason
the seconds of time cannot be reconstructed is that the time difference
between wristwatch and DOS-reported time is greater than the maximum
allowable limit for wristwatch-seconds-of-time adjustment, which is 59
seconds. In other words, if the time difference is greater than 59 seconds,
the wristwatch seconds of time cannot be adjusted because it is outside
the 59-second limit, and therefore is unknown.
This is where either serious discrepancies are seen, or the person who
recorded the data took some serious sips of coffee before recording the DOS
time.
The errant red data points in the above chart can be brought down lower and
closer to the zero reference line by adding up to 59 seconds to the
wristwatch seconds of time, but cannot be reduced by more than 59 seconds
because the adjustment limit is 59 seconds. This means all data points above
the 60-second mark in the chart still remain above the zero
reference line when 59 seconds is added. The rest falls below the zero
reference line, but still remains above the blue plotted line.
All of this means there is no way to reconcile any of these errant red
data points to Intel's 0.036% offset theory, regardless of the wristwatch
seconds of time adjustment.
Therefore, a TD anomaly is present on this computer.
See O'Connor's report for full details. Two more
charts are included in this analysis. |
|
|
Echlin's "Logic Path" Theory Debunked: |
Jace Crouch/Mike Echlin espouses what is called the "Logic
Path" theory, which is a theory of how a TD anomaly occurs based on the
value of the century year. It means the TD anomaly, according to their
theory, does not occur until the year 2000.
Mathematical calculations are necessary to convert the date in BCD format
into binary before being stored in RAM as a binary value. This theory
assumes that the date conversion routine is interposed within the RTC read
routine. The theory is also based on the assumption that these calculations
are all done "on the fly" while reading the RTC date.
But Intel's report is correct: there is no such logic path decision based on
the century year value, no, not in the BIOS code. This logic path
decision is performed "at a higher level," as Intel said in its report. This
higher level is the DOS kernel.
In truth, the date conversion occurs after complete date
information is retrieved from the RTC. How, then, does the date conversion
routine (allegedly including dual logic paths) push the date retrieval
period into the update period of the RTC? In order to perform date
conversion into a singular number of days in hex, all of the date
information, including the century byte, must be retrieved first.
Since it is the DOS kernel code that performs date conversion from BCD to
binary, there is no interposition of conversion code into the BIOS code that
reads the date from the RTC. In fact, the RTC date data returned to the DOS
kernel is in packed BCD format, the same format used in the RTC registers.
Therefore, all RTC read operations for the date are completed before the
conversion occurs. Hence, there is no "logic path" to speak of while reading
the RTC for the date. As a result, Mr. Echlin's Logic Path theory falls flat
to the ground.
This is why Intel's report in Appendix C makes the same conclusion. If there
is a logic path based on the century year value, it is handled in the DOS
kernel after, not while,
reading the RTC for the date.
See O'Connor's report for full details. |
|
|
Advanced Versus
Retrogressed Anomaly: |
There are two types of TD anomalies identified in
O'Connor's report: Advanced and Retrogressed.
An advanced time or date anomaly is a TD anomaly showing an excessively
advanced system time or date relative to the true time or date.
A retrogressed time or date anomaly is a TD anomaly showing an excessively
retrogressed
system time or date relative to the true time or date.
An advanced time/date symptom is proof positive of a TD anomaly, because
there is no scenario or condition identified with causing a false case of
retrogressed time/date anomaly that also causes a false case of
advanced time/date anomaly. In fact, there is no precedent for such an
advanced time/date symptom.
In contrast, a retrogressed time/date symptom can be caused by factors other
than a true TD anomaly. One example is a weak battery in the computer, which
supplies DC power to the RTC while the computer is turned off.
Theoretically, if an RTC is not buffered, the bad data in the update period
will consist of either FFh or the value of the seconds of time in all the
registers, including the alarm data. If FFh, the result will be an advanced
anomaly, because this data is always in the value of FF in hex. If seconds
of time value instead of FFh, either advanced or retrogressed anomaly will
result, depending on the value and the true time/date when it occurs.
Both Jace Crouch's "Zoom" 286 computer and Mike Echlin's Zenith 286 computer
show evidence of an advanced time/date anomaly, the former showing advanced
date anomaly, and the latter showing advanced time anomaly (or
retrogressed in some cases, see O'Connor's report). On the "Zoom" computer,
no time anomaly occurs. On the Zenith computer, no date anomaly occurs.
What does this tell you?
It is evidence that, during a computer boot, the time and date information
is separately
processed. This is confirmed through examination of published BIOS code
and technical references.
What does this mean? It means the time and date information are not read
together from the RTC. It means a shorter aggregate access time is required
to read either the time or date from the RTC, and this is important because
the RTC read routine has only 244 microseconds to read all the data it needs
to read. Echlin/Crouch's "Logic Path" Theory as
explained on their web site falsely (unintentionally) implies that both time
and date are read together from the RTC.
See O'Connor's report for more details. |
|
|
TD and Y2K: |
The TD anomaly is not related to Y2K problems because:
- Y2K issues deal solely with the 2-digit year date problem, a known
problem for which there is a known solution.
- The TD anomaly is not caused by the fact that the century byte has to
be included in the calculations after Y2K; it is caused by poor BIOS
code that does not honor the UIP or other problems.
|
|
|
RTC Cleared as Culprit: |
M. O'Connor's report shows the importance of understanding
computer speed versus RTC aggregate access time. The computer speed affects
the RTC aggregate access time, but does not affect the 244-microsecond
window. Computer speed also affects the execution speed of a running
diagnostics utility, which in itself affects the time it takes to read data
from the RTC.
O'Connor's report conclusively shows that Echlin's RTC.EXE program can lead
to false conclusions on 286 machines, because it runs too slowly on 286
machines to gather enough RTC data within the allotted 244-microsecond
window.
The following RTC data dump excerpt shows an aggregate RTC access time of
557 microseconds, which is much higher than the 244-microsecond window
allows, assuming the aggregate access time is defined as the time it takes
to read all the time and date information, plus all the alarm data, plus the
status byte. For the purpose of this demonstration, the RTC aggregate access
time is compared from two different diagnostic programs, therefore the
validity of this access time definition is not important. This data dump
comes from Echlin's RTC.EXE utility. Does this mean we have a problem with
this particular computer showing this characteristic?
(Note the "3" in the "err" column in this data dump. A "3" indicates a
possible TD anomaly. This RTCSCAN program was written by M. O'Connor to
facilitate fast processing of the dumped data and return a shortened data
dump listing showing the relevant areas of interest.)
Generated by RTCSCAN vs 0.60
RTCSCAN: RTC Data File Scanner
Copyright 1998 Michael D. O'Connor
RTC Data Scan Results
----------------------------------------------
LineNo. se sa mn ma hr ha dw dy mo yr st err
1 31 1f 35 58 19 1a 5 3 8 0 26 0
2 31 1f 35 58 19 1a 5 3 8 0 26 0
0 -- -- -- -- -- -- -- -- -- -- -- 0
613 31 1f 35 58 19 1a 5 3 8 0 26 0
614 31 1f 35 58 19 1a 5 3 8 0 a6 1
615 ff ff ff ff ff ff ff ff ff ff a6 1
616 ff ff ff ff ff ff ff ff ff ff a6 1
617 ff ff ff ff ff ff ff ff ff ff a6 1
618 ff ff ff ff ff ff ff 3 8 0 26 0
619 32 1f 35 58 19 1a 5 3 8 0 26 0
0 -- -- -- -- -- -- -- -- -- -- -- 0
2561 32 1f 35 58 19 1a 5 3 8 0 26 0
2562 32 1f 35 58 19 1a 5 ff ff ff a6 3
2563 ff ff ff ff ff ff ff ff ff ff a6 1
2564 ff ff ff ff ff ff ff ff ff ff a6 1
2565 ff ff ff ff ff ff ff ff ff ff a6 1
2566 ff ff ff ff 19 1a 5 3 8 0 26 0
2567 33 1f 35 58 19 1a 5 3 8 0 26 0
0 -- -- -- -- -- -- -- -- -- -- -- 0
4508 33 1f 35 58 19 1a 5 3 8 0 26 0
4509 33 1f 35 58 19 1a 5 3 8 0 a6 1
4510 33 1f 35 ff ff ff ff ff ff ff a6 1
4511 ff ff ff ff ff ff ff ff ff ff a6 1
4512 ff ff ff ff ff ff ff ff ff ff a6 1
4513 ff ff ff ff ff ff ff ff ff ff a6 1
4514 34 1f 35 58 19 1a 5 3 8 0 26 0
0 -- -- -- -- -- -- -- -- -- -- -- 0
6456 34 1f 35 58 19 1a 5 3 8 0 26 0
6457 34 1f 35 58 19 1a 5 3 8 0 a6 1
6458 ff ff ff ff ff ff ff ff ff ff a6 1
6459 ff ff ff ff ff ff ff ff ff ff a6 1
6460 ff ff ff ff ff ff ff ff ff ff a6 1
6461 ff ff ff ff ff ff ff ff 0 0 26 0
6462 35 1f 35 58 19 1a 5 3 8 0 26 0
0 -- -- -- -- -- -- -- -- -- -- -- 0
8404 35 1f 35 58 19 1a 5 3 8 0 26 0
8405 35 1f 35 58 19 1a 5 3 ff ff a6 3
8406 ff ff ff ff ff ff ff ff ff ff a6 1
8407 ff ff ff ff ff ff ff ff ff ff a6 1
8408 ff ff ff ff ff ff ff ff ff ff a6 1
8409 ff ff ff ff ff 0 5 3 8 0 26 0
8410 36 1f 35 58 19 1a 5 3 8 0 26 0
0 -- -- -- -- -- -- -- -- -- -- -- 0
10352 36 1f 35 58 19 1a 5 3 8 0 26 0
10353 36 1f 35 58 19 1a ff ff ff ff a6 3
10354 ff ff ff ff ff ff ff ff ff ff a6 1
10355 ff ff ff ff ff ff ff ff ff ff a6 1
10356 ff ff ff ff ff ff ff ff ff ff a6 1
10357 ff ff 0 58 19 1a 5 3 8 0 26 0
10358 37 1f 35 58 19 1a 5 3 8 0 26 0
0 -- -- -- -- -- -- -- -- -- -- -- 0
12299 37 1f 35 58 19 1a 5 3 8 0 26 0
12300 37 1f 35 58 19 1a 5 3 8 0 a6 1
12301 37 ff ff ff ff ff ff ff ff ff a6 1
12302 ff ff ff ff ff ff ff ff ff ff a6 1
12303 ff ff ff ff ff ff ff ff ff ff a6 1
12304 ff ff ff ff ff ff ff ff ff 0 26 0
12305 38 1f 35 58 19 1a 5 3 8 0 26 0
0 -- -- -- -- -- -- -- -- -- -- -- 0
14247 38 1f 35 58 19 1a 5 3 8 0 26 0
14248 38 1f 35 58 19 1a 5 3 8 0 a6 1
14249 ff ff ff ff ff ff ff ff ff ff a6 1
14250 ff ff ff ff ff ff ff ff ff ff a6 1
14251 ff ff ff ff ff ff ff ff ff ff a6 1
14252 ff ff ff ff ff ff 0 3 8 0 26 0
14253 39 1f 35 58 19 1a 5 3 8 0 26 0
0 -- -- -- -- -- -- -- -- -- -- -- 0
16195 39 1f 35 58 19 1a 5 3 8 0 26 0
16196 39 1f 35 58 19 1a 5 ff ff ff a6 3
16197 ff ff ff ff ff ff ff ff ff ff a6 1
16198 ff ff ff ff ff ff ff ff ff ff a6 1
16199 ff ff ff ff ff ff ff ff ff ff a6 1
16200 ff ff ff 0 19 1a 5 3 8 0 26 0
16201 40 1f 35 58 19 1a 5 3 8 0 26 0
0 -- -- -- -- -- -- -- -- -- -- -- 0
18142 40 1f 35 58 19 1a 5 3 8 0 26 0
18143 40 1f 35 58 19 1a 5 3 8 0 a6 1
18144 40 1f 35 58 ff ff ff ff ff ff a6 1
18145 ff ff ff ff ff ff ff ff ff ff a6 1
18146 ff ff ff ff ff ff ff ff ff ff a6 1
18147 ff ff ff ff ff ff ff ff ff ff a6 1
18148 ff 1f 35 58 19 1a 5 3 8 0 26 0
18149 41 1f 35 58 19 1a 5 3 8 0 26 0
0 -- -- -- -- -- -- -- -- -- -- -- 0
20000 41 1f 35 58 19 1a 5 3 8 0 26 0
The answer: No, it does not mean we have a problem with the above data dump.
The RTC data dump came from Echlin's RTC.EXE program; it ran too slowly to
gather all the readings from the RTC, due mainly to the speed of the 286
microprocessor. The reading speed of this program is also a factor.
The following RTC data dump excerpt comes from the same 286 computer and is
dumped by another program, written in assembler, which runs faster to gather
more readings from the RTC than did Echlin's RTC.EXE in the same time
period.
Generated by RTCSCAN vs 0.60
RTCSCAN: RTC Data File Scanner
Copyright 1998 Michael D. O'Connor
RTC Data Scan Results
----------------------------------------------
Record se sa mn ma hr ha dw dy mo yr st err
1 22 1F 38 58 17 1A 00 28 11 00 26 0
2 22 1F 38 58 17 1A 00 28 11 00 26 0
0 -- -- -- -- -- -- -- -- -- -- -- 0
2842 22 1F 38 58 17 1A 00 28 11 00 26 0
2843 22 1F 38 58 17 1A 00 28 11 00 A6 1
2844 22 1F 38 58 17 1A 00 28 11 00 A6 1
2845 22 1F 38 58 17 FF FF FF FF FF A6 1
2846 FF FF FF FF FF FF FF FF FF FF A6 1
2847 FF FF FF FF FF FF FF FF FF FF A6 1
2848 FF FF FF FF FF FF FF FF FF FF A6 1
2849 FF FF FF FF FF FF FF FF FF FF A6 1
2850 FF FF FF FF FF FF FF FF FF FF A6 1
2851 FF FF FF FF FF FF FF FF FF FF A6 1
2852 FF FF FF FF FF FF FF FF FF FF A6 1
2853 FF FF FF FF FF FF FF FF FF FF A6 1
2854 FF FF FF FF FF FF FF FF FF FF A6 1
2855 FF FF FF FF FF FF FF FF FF FF A6 1
2856 FF FF FF FF FF FF FF FF FF FF A6 1
2857 FF FF FF FF FF FF FF FF FF FF A6 1
2858 FF FF FF FF FF FF FF FF FF FF A6 1
2859 FF FF 38 58 17 1A 00 28 11 00 26 0
2860 23 1F 38 58 17 1A 00 28 11 00 26 0
0 -- -- -- -- -- -- -- -- -- -- -- 0
5772 23 1F 38 58 17 1A 00 28 11 00 26 0
It is sufficient to conclude that there is more data in the UIP period in
the above data dump than in the previous one. The RTC aggregate access time
is now 139.25 microseconds in the above data dump, far less than the
244-microsecond window. This proves that Echlin's RTC.EXE utility runs too
slow to gather all the data within the same time period on 286 machines.
Echlin's RTC.EXE utility was written in C++ and has been discontinued since
late 1998. However, Echlin's newest utilities are still written in C++
language. But assembler is much faster than programs written in C++
language. The BIOS code is all written in assembler.
However, it does not mean that there is no TD anomaly in the 286 computer,
because these programs were run while the computer is in operation. The TD
anomaly occurs only during computer power-up. The TD anomaly culprit is in
the BIOS code, and there is no way to repeat the action of the executing
BIOS code, even with diagnostic software, because the BIOS code is different
among BIOS versions.
O'Connor's report does not claim that all BIOS chips are suspect
for the cause of the TD anomaly. There are some old BIOS code (as early as
1985 in one case) that has all the earmarks of properly-coded BIOS routines
from which a TD anomaly should never occur.
At least one of Echlin's free diagnostic utilities returns the RTC access
time in microseconds as part of its results information. But this access
time is an arbitrary value as far as the user is concerned. There is no clue
as to the definition of the "RTC access time." O'Connor's report supplies
this definition, but not Echlin's own definition. However, the utility
appears to treat both the time and date as a single aggregate access. If
this is the case, then the returned access time should be divided in half.
Reason? The time and date are separately processed in a computer
boot, not together. Access time for the time and date are each approximately
the same, but only insofar as Echlin's utility is concerned. The actual
access time may be different during computer boot, especially for the time
of day.
If the utility returns the access time with an "OK" message but also returns
a message that the RTC failed the buffered test (non-buffered RTC), it still
recommends treating the machine as "suspect." The truth is that if the
access time is far less than the 244-microsecond window, there is absolutely
no cause for concern, buffered RTC or non-buffered RTC, if the UIP
bit is honored.
But let us not forget that the RTC access time is not a primary issue to be
considered as far as TD is concerned. Echlin's "Logic
Path" Theory, of which the RTC access time is a primary factor, has
already been disproved. If the UIP bit in the RTC is not being honored by
the BIOS code, it therefore follows that there is no need to extend the
access time beyond 244 microseconds to read bad data. The primary issue
is whether the UIP bit is honored by the BIOS code.
This RTC analysis (and other analyses shown in O'Connor's report) shows that
the RTC is not the culprit for the TD anomaly.
See O'Connor's report for full details, including
how the RTC aggregate access time is calculated based on these data dumps.
|
|
|
Download O'Connor's TD Analysis Report: |
M. D. O'Connor's TD Analysis Report is a copyrighted work
and is registered in the U.S. Copyright Office in Washington D.C., U.S.A.
The report is copyright 2000 Michael D. O'Connor, all rights reserved.
Distribution of this report is authorized under the following conditions:
- This report shall be distributed free of charge with nothing attached
to it except as an attachment to email.
- This report shall not be bundled, packaged, attached, or otherwise
tied to or with any merchandise or product.
- This report shall not be posted on web sites for display without prior
consent of the author. The only exception to this are forums, BBS's, and
FTP sites where this report may be posted as a downloadable item only.
- This report shall not be distributed for profit, including
distribution charges.
- This report shall not be modified in any way, shape, or form,
including the PDF file type of this document.
Adobe Acrobat Reader 4.0 is required to view the TD Analysis Report.
To download the report, click on one of the following choices:
Screen Optimized: TDARS.PDF
Download the above if you want to click on the URL's provided in the report
to link you directly from your Acrobat Reader to the respective web site.
Numerical footnotes in the body of the report will also link you to the
respective endnotes at the end of the report, whose URL's found therein will
link you to web sites when you click on them.
NOTE: URL's are not guaranteed to be valid after the release of this report.
Most are valid at the release date of this report.
Print Optimized: TDARP.PDF
Download the above if you only want to print this report. The URL's provided
in the endnotes will not link you to web sites from your Acrobat Reader.
However, the URL's in the body of this report will link you to web
sites directly from your Acrobat Reader. All numerical footnote links will
only point you to the last page of the endnotes.
|
|
This page created by Michael D. O'Connor
28 Feb 2000 |
|
[Top]
[ Home ] [ What's New ] [ Contact Us ] [ Referrals ] [ Feedback ] [ Products Summary ] [ DownLoads ] [ Orders ] [ Links ] [ Anti-Spyware ] |
|
