On Mon, Jan 05, 2004 at 05:41:34PM +0100, Christian Biere wrote:
> Ben Collver wrote:
> > It is hard for me to believe the code is supposed to continue at 0:0
> > because that range of memory is all zeroed out.
> 
> That would be a bug (somewhere) because the first 4k at 0:0 contain
> the IDT (interrupt decriptor table). Though, I remember you can
> its location even in read-mode with 'lidt'.

Before the code switches to real mode, it does set the IDT:
        lidt    idt_real@GOTOFF(%ebx)

[...snipped...]

idt_real:
        .word   0x400 - 1                       # idt limit ( 256 entries)
        .word   0, 0                            # idt base = 0L

> > 0000265d: sti                       ; fb
> 
> Here you allow interrupts (unless the PIC is programmed to disable them)
> and a few instructions later something goes haywire. Suspicious.
> 
> > 0000265e: xor EAX, EAX              ; 6631c0
> > 00002661: mov [DS:0000], EAX        ; 66a30000
> > 00002665: mov [DS:0004], EAX        ; 66a30400
> > 00002669: mov [DS:0008], EAX        ; 66a30800
> > 0000266d: xor EBX, EBX              ; 6631db

I suspect you are onto something, as you hinted earlier, associating this
odd behavior with enabling interrupts.  I'll try beraking after the cli and
tinker around a bit.

Thank you for the help,

Ben
-- 
A hacker does for love what others would not do for money.