I have an "RUNTIME ERROR"
Keelokitty
200 AT 0413:0091" TRYING TO INSTALL WINDOWS 95 AFTER REFORMATING SYSTDEM.
PLEASE HELP OR TELL ME WHERE TO FIND THE ANSWERS.
THANK YOU
SHELLEY
Robert AH Prins
news:20041209064303...@mb-m18.aol.com...
In the mini-FAQ in comp.lang.pascal.borland. Your problem has nothing to
do with Windoze, it's a problem with the startup code in the Borland
Pascal 7 Crt unit, which is trying to calibrate itself on a very fast
CPU. Here is part of the mFAQ:
**********************************************************************
3. Very Frequently Asked Questions.
**********************************************************************
Why do fast CPUs (Celeron, Pentium II and >200MHz) give problems
with Crt.Delay?
A problem may occur with a PP-200 (or better) CPU in that Runtime
Error 200 is generated in the start-up code of the CRT unit. This is
caused by division of a large number by 55 whose result won't fit
into a 16 bit register; the CPU generates an 'overflow' exception/
interrupt which is interpreted by the system library as "divide by
zero" exception/interrupt.
See Timo Salmi's FAQ #124 for details.
See Section 4.2 for replacement CRT units available for download.
Frank Heckenbach's remedy, for TP/BP 7.00/7.01, is
available at
http://fjf.gnu.de/bp-progs.html#NewDelay
Or Roger Donais's remedy : Those without source, compiling DOS real
mode programs may find RDELAY.ZIP useful
ftp://ftp.uwasa.fi/pc/turbopas/rdelay10.zip
It contains source for a Turbo 4.0 through 7.0 compatible unit
designed to prevent the "Divide by 0" error encountered on fast
machines.
Osmo Ronkanen has produced a Loader program for those programs that
cannot be patched. His newsgroup posting is available from
ftp://garbo.uwasa.fi/pc/turbopa7/tfix.zip
There was a related problem in earlier TP version when the
initialisation code calibrated the delay to be too short without
generating an error. Frank Heckenbach's page has a fix and also see
Timo Salmi's FAQ, article #67. The replacement CRT units from Pedt
Scragg and Robert Prins also address the problems with the
incorrect delay on processors >200MHz for TP V5.0, V5.5 and V6.
Franz Glaser has collected a large number of patches for this and
they can be found via
http://www.geocities.com/SiliconValley/2926/tp.html
Andreas Bauer has produced a patch for an executable program.
Available from
ftp://garbo.uwasa.fi/pc/turbopa7/tppatch.zip
This program can be installed as a tool in the Pascal IDE:
~B~auer's TPPATCH / TPPATCH / $EXENAME
You can check by compiling to disk and running a program using Alt-R
R that uses a non-fixed CRT unit. After the RTE200, use Alt-T B then
run the program again - the error will be fixed.
Further discussions of timing and delays can be found in Prof.
Salmi's TurboPascal FAQ, in Kris Heidenstrom's Timing FAQ,
ftp://garbo.uwasa.fi/pc/programming/pctim003.zip
in the newsgroup comp.lang.pascal.borland - *read previous posts
first*, and at http://www.merlyn.demon.co.uk/pas-wait.htm#Delay
There has been a tentative suggestion that >450MHz CPU's could give
problems with *some* of the fixes available. This seems to be, at
the time of writing, affecting the programs that have used c't
magazine fix and related ones which patched the code to set the
divisor to 126 instead of 55. C't have now released a new patch that
will work above 450MHz. Obtainable from
ftp://ftp.heise.de/pub/ct/ctsi/ctbppat.zip
If you do use a fix for this error which does not work then please
post *which* fix with the file datestamp and place obtained, your
CPU / OS / Error Message returned.
Frank Heckenbach's fix is provided with the French TP7.01 free
download.
The same problem occurs with the TurboPower OpCrt & TpCrt units. The
patches that used to be available on their late ftp site have been
put onto SourceForge. The URL is
http://sourceforge.net/projects/tpopro/
and you need to look for bug #955482. (At this moment it is the only
bug) The patches are in a (Win)RAR archive.
Robert
--
Robert AH Prins
prino at onetel dot com
J. Yazel
===============================
The problem is caused by your hardware which is to
fast for the software timing loops in one of your
programs (not in Windows).
Two "fix" programs are available that have worked
about half the time for me.
Get them at:
ftp://garbo.uwasa.fi/pc/goldies/crtfix.zip
ftp://garbo.uwasa.fi/pc/turbopa7/tppatch.zip
Good luck.
Jack
Dr John Stockton
11:56:43, seen in news:comp.os.msdos.misc, Robert AH Prins
<pr...@onetel.com> posted :
>
> Further discussions of timing and delays can be found in Prof.
> Salmi's TurboPascal FAQ, in Kris Heidenstrom's Timing FAQ,
> ftp://garbo.uwasa.fi/pc/programming/pctim003.zip
> in the newsgroup comp.lang.pascal.borland -
> *read previous posts
> first*,
That's probably better removed now; most are *very* previous.
> and at http://www.merlyn.demon.co.uk/pas-wait.htm#Delay
and/or ...pas-r200.htm ???
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
pe...@nospam.demon.co.uk
keelo...@aol.com "Keelokitty" writes:
I had just this problem reinstalling w95 on a PC with a AMD K6-2
processor; there are a handful of w95 installation/system files
that have to be replaced (the originals have timing loops that
run too fast on processors faster than ~200MHz).
Search for AMDK6UPD.EXE -- can't remember whether I got it from
MS or AMD, but the MSKB is the place to start; it's a known and
well-documented problem.
Pete
--
"We have not inherited the earth from our ancestors,
we have borrowed it from our descendants."