• Please review our updated Terms and Rules here

486dx2 hardware error?

V

vol.litwr

Experienced Member
Joined
Mar 22, 2016
Messages
324
I received a report that my number pi calculator for DOS works wrong on an IBM 425 SX/S ValuePoint. So there is a possibility that the first 486DX2 has a bug. Would anyone like to run this pi calculator on any 486dx2 based machine? The attached program must print 3141.
I have tested the program on emulators and the 386dx, Celeron, and AMD Phenom. It works correctly there.
 

Attachments

  • pi-log6.zip
    409 bytes · Views: 9
The 425 SX/S has a 25 MHz 486SX, not a DX2. As you know, I assume, the SX lacks the FPU.

I have a 486DX2/50 if you want me to test. But that probably won't help here.
 
There were a few bugs in 386s and 486s made by Intel. Here are the known ones for 486 processors...

80486 bugs:
The following are some bugs for the 80486DX and the 80486SX/80487SX processors:

  • A code breakpoint that is set on an instruction like JMP, CALL, etc., will clear the lower 4 bits of DR6 when satisfied. Another bug will occur if a code breakpoint is set on an instruction that immediately follows a RETN, JCXZ, intrasegment indirect CALL, or intrasegment indirect JMP. In this case the breakpoint is taken even when the control transfer instruction is executed. A code breakpoint set at the target instruction will not be taken because the erroneous breakpoint will set the RF flag. There is no workaround for this bug.
  • When writing to TR5 with the control bits set to 01b, 10b, or 11b, and if in the same time a prefetch is pending, this may cause the CPU to hang.
  • If a segment violation occurs on the target of a short jump and if an external interrupt (NMI or INTR) occurs on the same CLK as the GP fault, the 80486 will not correctly handle the GP fault. There is no workaround for this bug.
  • A bug in the FPU creates three cases when the FERR# error is generated by a floating point operation, but it is not reported correctly.
  • If an unmasked exception occurs when the numeric exception bit in CR0 is clear and the IGNNE# pin is active, the performance of the FPU will be retarded as long as the exception remains pending.
 
Timo W. said:
The 425 SX/S has a 25 MHz 486SX, not a DX2. As you know, I assume, the SX lacks the FPU.

I have a 486DX2/50 if you want me to test. But that probably won't help here.
Click to expand...
It is an upgraded 425 SX/S, it actually uses 486dx2-66.
It would be very interesting to know what your 486dx2/50 must print. Thank you in advance.
 
twolazy said:
There were a few bugs in 386s and 486s made by Intel. Here are the known ones for 486 processors...

80486 bugs:
The following are some bugs for the 80486DX and the 80486SX/80487SX processors:

  • A code breakpoint that is set on an instruction like JMP, CALL, etc., will clear the lower 4 bits of DR6 when satisfied. Another bug will occur if a code breakpoint is set on an instruction that immediately follows a RETN, JCXZ, intrasegment indirect CALL, or intrasegment indirect JMP. In this case the breakpoint is taken even when the control transfer instruction is executed. A code breakpoint set at the target instruction will not be taken because the erroneous breakpoint will set the RF flag. There is no workaround for this bug.
  • When writing to TR5 with the control bits set to 01b, 10b, or 11b, and if in the same time a prefetch is pending, this may cause the CPU to hang.
  • If a segment violation occurs on the target of a short jump and if an external interrupt (NMI or INTR) occurs on the same CLK as the GP fault, the 80486 will not correctly handle the GP fault. There is no workaround for this bug.
  • A bug in the FPU creates three cases when the FERR# error is generated by a floating point operation, but it is not reported correctly.
  • If an unmasked exception occurs when the numeric exception bit in CR0 is clear and the IGNNE# pin is active, the performance of the FPU will be retarded as long as the exception remains pending.
Click to expand...
Thank you but my code doesn't use any of listed things. Maybe my code allows us to discover a new bug. IMHO it is rather a bug of a particular system but it can be a general hardware error of any 486 or 486dx2. I need results from several systems to be sure. The 486dx2-66 is the most interesting case.
 
Caluser2000 said:
I've got a range of 486s if you want me to test it. AMD/INTEL blah blah
Click to expand...
I have simply asked people, if anyone shares my interest in finding a possible 486dx2 bug, please run my program. Is there something wrong with my request?
 
vol.litwr said:
I have simply asked people, if anyone shares my interest in finding a possible 486dx2 bug, please run my program. Is there something wrong with my request?
Click to expand...
This may not be the problem but you want to cld at the start of your program before the rep stosw; looks like the flag register is undefined at startup: http://www.fysnet.net/yourhelp.htm
edit: also, don't you need a jmp $+2 to clear prefetch queue after your self-modifying code (mov [129h],ax; mov [117h],ax)
 
Last edited:
Makefile said:
This may not be the problem but you want to cld at the start of your program before the rep stosw; looks like the flag register is undefined at startup: http://www.fysnet.net/yourhelp.htm
edit: also, don't you need a jmp $+2 to clear prefetch queue after your self-modifying code (mov [129h],ax; mov [117h],ax)
Click to expand...
Thank you very much! JMP $+2 solves the problem but this has arisen a new question. Why do other machines work fine without this JMP? And I doubt about the prefetch queue because the problem appears even when modified code is more than 20 bytes away from the point of its modification - so it is rather something wrong with the cache. So it may be a hardware error.
BTW it seems all late DOSes set D=0 when they start a program.
 
vol.litwr said:
Thank you very much! JMP $+2 solves the problem but this has arisen a new question. Why do other machines work fine without this JMP? And I doubt about the prefetch queue because the problem appears even when modified code is more than 20 bytes away from the point of its modification - so it is rather something wrong with the cache. So it may be a hardware error.
BTW it seems all late DOSes set D=0 when they start a program.
Click to expand...

The more hardware-oriented posters are going to have to take on this one. All I know is that the 486 prefetch queue is 32 bytes which is quite a while forward, and there are also write buffers so execution continues even when the previous instruction hasn't finished writing to memory. Seems like something that could crop up, making the distance to the stale instruction even more than 32 bytes with self-modifying code if the overwritten code isn't cached at the time of the write. Remember that on a write miss, the 486 just updates memory without loading the affected memory into internal cache.
 
You must log in or register to reply here.
Back
Top