Recent content by Vol

Excuse me, but what is OpenRetroSCSI ? I haven't been able to google this. :mad: Actually your latest results are much closer to the other guy's results than the previous ones for OS 8.5. I can also assume that his RAM is just running slower. And thanks a lot for your support. EDIT. Your...

One more reason for the difference may be the RAM speed. Systems may use 60-80 ns RAM chips.

Thank you very much! However we have got a mystery. Results from another system show much lower performance. How might this be possible? I have three ideas about this: 1) your system uses the L2 cache while other system doesn't use it; 2) OS 8.5 has a much faster routine to output characters...

I am gathering results for the speed of the pi-spigot algorithm for different platforms. Now it is time for the Macintosh computers based on the PowerPC and running MacOS. It would be great to get results from the PPC601 and PPC603 but other models are welcome too. Three programs are...

:)

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...

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...

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...

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 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...

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...

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...

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

I can't still get any clue. :( I've prepared the next tests but it can be for long. :( It would be great if you can provide telnet/ftp or ssh access for me to your system. This can speed up things very much. The next tests pi-log3 >trace3.txt pi-log4 >trace4.txt

Your results show that every single instruction works correctly. So the problem probably is a combination of some instructions. Do you know about the famous POPAD/PUSHAD bug of all the 80386 chips? Let's continue our efforts to find out the source of the strange results. Would you like to run...