Have an IBM PC compatible on the 486 or the first Pentium? Please run it for me!
- Thread starter Vol
- Start date
Thanks. But I am just baffled. 
What a strange CPU quirk! I have just prepared two more tests which generate very small outputs.
Just check the output on your system with the given.
pi-log5
0C45
01DF
1503
0C45
3141
pi-log6
3141
What a strange CPU quirk! I have just prepared two more tests which generate very small outputs.Just check the output on your system with the given.
pi-log5
0C45
01DF
1503
0C45
3141
pi-log6
3141
Thanks. But I am just baffled.
It probably means you have something to learn from all this.
Thank you very much. Yea, I am really curious why we get so unusual results. Your last traces finally detected that something is wrong but traces were too short to localize the problem. It is obvious that the trace generation affects the results (the generation should not have affected results on serviceable hardware) and this make things very complicated. I have prepared the next test, it just disables the CPU cache. Would you like just to check whether PI-LOG7 prints 3141 or some other number?
Thank you. The last result shows that the cache is not the cause for an error. I have prepared several more tests. Would you like to run them? All of them must print 3141. Just report which one prints something else.
However I'm not sure if you share my interest. Maybe I'm just an annoying person for you? Sorry if that's the case, I don't mean to be pushy. But if you share my interest let's continue.
BTW it is very interesting to test this code on another 486, maybe it is a common bug for all of these CPU's.
Oops, I actually ran pi-log7 on my WeeCee.
I went back and copied 7 through 12 to my 486 and I even tested back some of the old ones. The output changes between tries. Is that normal?
For instance, pi-log5 will output:
0000
0000
25A4
0000
0000
and running it again right after will give:
0000
0000
1162
0000
0000
pi-log6:
L8000
pi-log6 again:
0001
pi-log6 yet again:
0000
pi-log7:
0011
again:
0000
again:
0001
pi-log8:
9574
again:
0001 (or 0000, depending on the try attempt)
pi-log9:
0000 (I can alternate it with 0001 sometimes)
pi-log10 to pi-log12 behave the same way
don't worry about being annoying, I've been in your spot oftentimes, wondering why a piece of code did not behave the way I expected. Takes me second to bring those files to my old computer. In the interest of science, I'll continue.
I went back and copied 7 through 12 to my 486 and I even tested back some of the old ones. The output changes between tries. Is that normal?
For instance, pi-log5 will output:
0000
0000
25A4
0000
0000
and running it again right after will give:
0000
0000
1162
0000
0000
pi-log6:
L8000
pi-log6 again:
0001
pi-log6 yet again:
0000
pi-log7:
0011
again:
0000
again:
0001
pi-log8:
9574
again:
0001 (or 0000, depending on the try attempt)
pi-log9:
0000 (I can alternate it with 0001 sometimes)
pi-log10 to pi-log12 behave the same way
don't worry about being annoying, I've been in your spot oftentimes, wondering why a piece of code did not behave the way I expected. Takes me second to bring those files to my old computer. In the interest of science, I'll continue.
Thank you very much! It will be really astonishing if we are able to discover a general hardware bug for this CPU! Your last results are very promising, they give us chances to catch the bug. I didn't need to know what exactly was printed because the last tests have only two results: the correct one (3141) and all others.
My new tests generate tracings so we need to use the output redirection.
Code:
PI-LOG13>TRACE13.TXT
PI-LOG14>TRACE14.TXT
PI-LOG15>TRACE15.TXTBTW I am curios do you try to run something else on your PC: games, text editors, etc. Do they work correctly?
I've included my config.sys and autoexec.bat (renamed as .txt so that they can upload here) so you can see what's running. Right now, it's set up to accomodate Wing Commander 1, so I need expanded memory so I can run SoftMPU, in order to tap into some sweet Roland MT-32 music.
I run a CPU cache disabler right before running the game, and reenabling it right after. That disabler is NOT run as part of autoexec.bat, but rather, a separate batch file that's only launched when I launch the game itself. It's NOT been activated when I do your tests.
The purpose of this 486 is to give me access to a wide array of PC games and software from the early 90's up until the pre-3dfx days/pre-win95 days. I've played lots of the early Sierra games. The storage space (real 320 mb HD and compact flash 512 mb) makes it difficult to host a cd image so I haven't bothered with early DOS cd games much on that.
I run a CPU cache disabler right before running the game, and reenabling it right after. That disabler is NOT run as part of autoexec.bat, but rather, a separate batch file that's only launched when I launch the game itself. It's NOT been activated when I do your tests.
The purpose of this 486 is to give me access to a wide array of PC games and software from the early 90's up until the pre-3dfx days/pre-win95 days. I've played lots of the early Sierra games. The storage space (real 320 mb HD and compact flash 512 mb) makes it difficult to host a cd image so I haven't bothered with early DOS cd games much on that.
Thank you. This bug is very elusive. I don't think that any configuration can somehow affect the bug. We just need more tests.
PI-LOG16>TRACE16.TXT
PI-LOG17>TRACE17.TXT
If your system successfully runs other applications then it means that we have actually detected an unknown hardware bug.
Thank you again. A man suggested two possible reasons for the unusual results for my program. He thinks it may be the incorrect value of the D flag or some self-modifying code. So I have just prepared three more tests, each must print 3141. Please report if any of them prints anything else.
BTW the incorrect D flag may be a result of your configuration. So it is possible that your hardware works fine.
Pentium MMX 233. The first set is in a full screen command.com within Windows 98. The second set to "reboot to DOS mode" with a little overhead. It seems that most of the time on this machine is coming from print the digits to the screen.
| pi-ibmpc | pi-pc386 | pi-pc486 | |
100 | 0 | 0 | 0 |
1000 | 0.16 | 0.11 | 0.16 |
3000 | 1.1 | 1.04 | 1.04 |
9264 | 9.12 | 9.12 | 9.06 |
| just dos | |||
100 | 0 | 0 | 0 |
1000 | 0.16 | 0.11 | 0.11 |
3000 | 0.99 | 0.93 | 0.99 |
9264 | 8.4 | 8.4 | 8.4 |
Thank you. Your system is rather too fast for my table but in absence of other Pentiums I have to use the only one result I have now. It is interesting that per MHz efficiency for this task the Pentium MMX is almost equal to the Motorola 68040.
Your results also confirm that PI-PC486.COM has no advantages over PI-PC386. So I remove it from further testing.
It seems your message contains some critique of my benchmark. Ok, let me do some pure math explanations. Your results show that for 3000 digits the time for printing digits is about 4% for the first case (Windows 98) and about 3% for the second (Windows 98/DOS). Your can prove these numbers by running an attached program (PI-386ND.COM). It is the same as PI-PC386.COM but it doesn't print digits. Actually, the bigger problem is the timer accuracy, it is only about 0.06 seconds - this corrupts results for 100 and 1000 digits for the fast machines dramatically. So I have just written new versions of the pi calculators which use 200 Hz timer instead of the standard 18.21 Hz. So you can run PI-PC386.COM or PI-IBMPC.COM now and get more accurate results.
BTW is it possible to reduce the CPU frequency (233 MHz) on your system?
Thank you very much. Your results finally allow us to localize the problem. However I don't know how to call it. IMHO it is rather a bug because other CPUs work fine on my old code. I can suppose to call it as a cache quirk that somehow relates to the prefetch queue.
The details of the quirk. There is an instruction that modifies another instruction in my code. If we insert JMP $+2 after the former then your CPU works correctly. This JMP reloads the prefetch queue.
Would you like to run new PI-IBMPC.COM on your system? It must work correctly now. This program also uses more accurate timer measurement than the previous variant.
EDIT. I have just received information which explains the situation. The 486 uses 32-byte prefetch queue and this quite explains the problem. So there was no bug in your CPU, it was my miss. Sorry. But it was interesting to try to catch an imaginary bug.
Last edited:
Would you like to run new PI-IBMPC.COM on your system? It must work correctly now. This program also uses more accurate timer measurement than the previous variant.
EDIT. I have just received information which explains the situation. The 486 uses 32-byte prefetch queue and this quite explains the problem. So there was no bug in your CPU, it was my miss. Sorry. But it was interesting to try to catch an imaginary bug.
I'm glad all of this served this purpose! I had a 386 growing up and I could only admire my friends' 486 from afar. I vaguely knew about the terms L1 and L2 cache and how it could make games run smoother. It makes sense that it affects your code.
My tables are updated. Let me summarize our results:
1) two entries to the tables have been added;
2) the 8088 code is faster than the 80386 code on the 486 machine;
3) the 80486 code has the same speed as the 80386 code on the 486 machine, so the special version for the 486 was removed;
4) the 80486 peculiarity was detected and localized.
It looks pretty good.
Thank you very much!I wish you a pleasant time with old good games.