OSDev.org

Hey ya. I've one big problem, really big, maybe not so big. I've 2 computers, if you're interested in that, they're: Intel Celeron 1.3GHz 128RAM, ant another is Cyrix instead 233MHz 68RAM. THe problem is that my OS runs fine on cyrix, but on my celeron computer it get a division by zero fault, which shows into address, with BT instruction, as far as i know, division by zero fault can be only excepted then DIV or IDIV instruction tries to divide by zero, or the result is too big. So i'll be happy if someone will help me .

Maybe it's some other exception happend (maybe invalid opcode?) but your IDT entery for that exception points to divide by zero exception handler.

Try to replace BT with TEST instruction, then try again.

Now i've changed BT with AND, then with TEST, the only effect what can i see is that fault comes again and again at address 00100BD3. My ORG is 1024*1024+1024. Here is a disassembly cut of that code:
00100BCE EB82 jmp short 0xb52
00100BD0 FB sti
00100BD1 E464 in al,0x64
00100BD3 2401 and al,0x1
00100BD5 0F8477FF jz near 0xb50
00100BD9 FF db 0xFF
00100BDA FF75F3 push word [di-0xd]
There is the 4th line where the fault comes. I don't understand, on another PC it works, on mine doesn't =\ .

That sounds like a badly-remapped PIC to me ... a division by zero that is repeatedly thrown at non-div opcodes ...
your disassembler doesn't seems accurate either: it looks like it tries to disassemble 32bit code in 16-bit mode ...

Hmm... What happens when you remove this line?
It looks like you have bad PIC or IDT setup code.

Emm... IDT is working fine, PIC remapped fine too. On another computer it works. Disassembly is in 32bit form, maybe i'll try to test it on some other computers :-\ ...

This _cannot_ produce any exception (maybe broken CPU, but I don't think so)!

It happens just after you have enabled interrupts, so there is something wrong with hardware interrupts, I guess.
This code looks really strange! What this suppose to do?

xsix wrote: 00100BD5 0F8477FF jz near 0xb50
00100BD9 FF db 0xFF
00100BDA FF75F3 push word [di-0xd]

That is not 32-bit disassembly. There is a 16-bit offset supplied with that near jump instruction. Clearly, the next two bytes also belong to it. Also, there is a 16-bit register used in an address calculation without an address size override prefix.

Send real code instead of disassembly. Or tell your compiler to produce asm output and compare the resaults.

I use NASM. Disassembly done with ndisasm with parameter -b 32... CPU isn't broken, i hope ;D. Ok, whatever, thank you all for your answers, i'll find that error, my code, my problems.

So if you are coding in assembly in the first place why are you providing output that has been run through two seperate processes rather than just showing us the original?

I'm not good in english... But disassembly is the same as asm code. Doesn't matter,i just want to know why so simple thing faults on one computer, but not on another.

xsix wrote: I'm not good in english... But disassembly is the same as asm code.

No it isn't. Source is usually better formatted and commented. It does also rule out any wrongful settings to the disassembler.

It's also one less step to copy-paste than disassemble-copy-paste.