OSDev.org

I find it rather interesting that the link there provides a boot section "by Gareth Owen"... in actual fact, that's _my_ boot sector, from about 5 years ago, from my original OS project; PolyOS.

In any event, a good book on assembly language is always a good thing to have, and a reference for the opcodes.

Jeff Dunteman wrote a good book for learning assembly, and is the book I learned from... I can't recall the title off hand, though.  I'm sure it'd be easy to find on Amazon.com

Jeff

carbonBased which link is that, and which program are you taking about ?.

ASHLEY4.

Actually both AND and CMP are necessary here.

AND AH, 0xF0 -- turns off all bits except the high four in AH (bits 12..15 in AX). It sets the zero flag only if the result in AH is zero, i.e., if bits 12..15 are already set to zero.

But he's not checking if bits 12..15 are all zero; he's checking if they're all one. (Popping a zero into the flags on an 8086, then pushing the flags, forces bits 12..15 all to be one.) CMP AH, 0xF0 sets the zero flag only if AH contains 0xF0, i.e., if bits 12..15 are all set to one. He branches (JE no386) only if that's the case.

http://www.nondot.org/sabre/os/files/Bo ... otsect.txt

And, actually, upon reading the document, it's actually surprisingly similar to the document I wrote (hmm... 7 years ago -- 1997):
http://www.neuraldk.org/document.php?boot_sector

Anyway, no worries... I find that boot sector all over the place.  At least it's serves a good purpose   Even though it is a _very_ early version of my actual boot sector; it doesn't even contain the kernel loading routines!

The program I'm talking about is PolyOS.  A operating system I developed a long ways back.  There's pieces of it all over the internet and, unfortunatley, that's all that's really left of it.  I lost the vast majority of it in an HD failure (just another example of why you should backup everything... in fact, people, back up NOW! )

Cheers,
Jeff

You should ask him to put your name as the writer of the code.

ASHLEY4.

Ok, I've read some articles on how the flags are in the 8086 and the 80286... in the 8086 are flags 12...15 always set, on the 286 are flags 12...15 in real mode always unset... With this knowledge we can test if we have to do with a 8086 or an 286. If both cases are untrue, we have a 386 or higher But I was wondering: which flags of the 386 (flags 12...15) are set in real mode? Not all, not nothing, is it?

that cannot be relied on because 386+ will have the last value loaded --not always zero but bit 15 will allways be clear but bits 12...14 can be set on a 386+ but not a 286

oh yes im stupid!
i didnt think about that I would skip the 8088/86-specific test since it can be built into the 286 test so a JNE JS after the AND will catch a 286 _and_ 8088/86 (after trying to SET rather than CLEAR the Flags)

sorry that should be:
JE no386
JS no386
rather than JNE JS

actually you can check very simply:

PUSHF               save preexisting flags
XOR AX,AX
DEC AX              set AX=0xFFFF
PUSH AX
POPF                set Flags
PUSHF
POP AX              read Flags
AND AX 0XF0         mask lower bits
JE no386            if AX=0 then 286
JS no386            if sign bit(bit 15)set then 8088/86
POPF                restore original flags, if you get here you have a 386!

Hmmm, I thought this would do it? (all made by my, so probably not good )

pushf
pushf
pop ax
mov bx,ax
and ah, 0xf0
jnz no386
and bh, 0xf0
jz no386
popf

no the only way to detect a 386 is to try to change the flags

my code could probably be optimized a little more but your code above detects all processors as no386 because your anding the same values both ways -- AH and BH contain the same value and you AND the same value and jump on oppoosit conditions the code I gave should work and is the simplest way:

force it set then if its clear you have a 286 because a 8088/86 will be forced set and a 386 will be changed to set

then check the sign bit (should still be set = bit 15 from the AND) bit 15 is ALLWAYS set on 8088/86 and NEVER set on the 386+ (or the  286 but we already eliminated that)

486 can then be detected by ability to change the AC flag

later 486s and everything after supports CPUID for Identifying and that is the only reliable way -- the ability to use CPUID is detected by the ability to change the ID flag

CPUID also provides a lot of other info

so this will work (sorry for dutch explanation)

mov si, msg_no_386 ;het bericht wat geprint zal worden als er geen 386 is...
push ax ;sla de originele waardes op
push dx ;
pushf ;
mov ax, 0xFFFF ;we gaan de flags allemaal zetten
push ax ;zet ze op de stack
popf ;en laad ze in de flags
pushf ;neem de waardes van de flags terug
and ah, 0xF0 ;and ah met 0xF0 (bits 12 tm 15)
jz fail ;als bits 12 tm 15 weer clear zijn, hebben we een 286
;we hebben nu alleen nog de 8086 en de 386 of hoger over
;op de 386 is bit 15 altijd clear, op de 8086 altijd gezet (bit 15 = sign flag)
js fail ;op de 8086 zal de sign flag gezet zijn, dus fail
popf ;zet de originele waardes terug
pop dx ;
pop ax ;