P-mode is working but jmp to kernel triple falts

[Eric Avery]

Ok now that i am finaly in p-mode i have been
trying to get to my kernel code that i have
loaded at 0x2000 however when i jmp to SYS_SEL:0x2000
it falts and i reboot (SYS_SEL is a valid code
discriptor) I think im just not getting how to
address the kernel code and trying to jmp to
SYS_SEL:0x2000 is putting me into junk
memmory?

[J. Weeks]

>On 2002-02-11 23:26:32, Eric Avery wrote:
>Ok now that i am finaly in p-mode i have been
>trying to get to my kernel code that i have
>loaded at 0x2000 however when i jmp to SYS_SEL:0x2000
>it falts and i reboot (SYS_SEL is a valid code
>discriptor) I think im just not getting how to
>address the kernel code and trying to jmp to
>SYS_SEL:0x2000 is putting me into junk
>memmory?

Well of course it is... your kernel is not as
SYS_SEL:0x2000.

You are aware that real mode is segments, correct?
In fact, each segment, effectivealy spans 16 bytes.
In other words, in between segment 0x0000 and
0x0001 in real mode is 16 bytes.

Sooo... assuming SYS_SEL is a segment starting at
0x0, your 0x2000 is real mode segmented model
will become 0x2000 * 16 in flat pmode memory...
in other words, you kernel (assuming its been
loaded correctly) is at SYS_SEL:0x20000.

Try that, and see what happens.

Jeff

[The Legend]

>On 2002-02-12 09:45:03, J. Weeks wrote:
>>On 2002-02-11 23:26:32, Eric Avery wrote:
>>Ok now that i am finaly in p-mode i have been
>>trying to get to my kernel code that i have
>>loaded at 0x2000 however when i jmp to SYS_SEL:0x2000
>>it falts and i reboot (SYS_SEL is a valid code
>>discriptor) I think im just not getting how to
>>address the kernel code and trying to jmp to
>>SYS_SEL:0x2000 is putting me into junk
>>memmory?
>
>Well of course it is... your kernel is not as
>SYS_SEL:0x2000.
>
>You are aware that real mode is segments, correct?
>In fact, each segment, effectivealy spans 16 bytes.
>In other words, in between segment 0x0000 and
>0x0001 in real mode is 16 bytes.
>
>Sooo... assuming SYS_SEL is a segment starting at
>0x0, your 0x2000 is real mode segmented model
>will become 0x2000 * 16 in flat pmode memory...
>in other words, you kernel (assuming its been
>loaded correctly) is at SYS_SEL:0x20000.
>
>Try that, and see what happens.
>
>Jeff
That is something I never understood in pmode
programming. If between each segment in real mode
are additional 16 bytes (which I didn't know
until now), why is the result 0x2000 * 16 ?

[J. Weeks]

>That is something I never understood in pmode
>programming. If between each segment in real mode
>are additional 16 bytes (which I didn't know
>until now), why is the result 0x2000 * 16 ?

It's a weird system, for sure.
You know that, for example, between 0xA000
and 0xB000 there is 64k (65536d), right?

In other words, using the segment 0xA000, and a
16 bit offset, you can access all memory up to
(but not including) 0xB000.

Now, of course, that means 64k is divided up into
0x1000 segments, so, for each individual
segment, we have 65536d/0x1000 = 16d bytes.

also of note:
0x0000:16d = 0x0001:0d
0x0000:17d = 0x0001:1d
etc...

Does that makes sense? I can't think of an overly
good way to explain it... got any more questions?

Jeff

[The Legend]

>On 2002-02-12 11:24:34, J. Weeks wrote:
>>That is something I never understood in pmode
>>programming. If between each segment in real mode
>>are additional 16 bytes (which I didn't know
>>until now), why is the result 0x2000 * 16 ?
>
>It's a weird system, for sure.
>You know that, for example, between 0xA000
>and 0xB000 there is 64k (65536d), right?
Yes, 64k is the segment size in real mode.
But 0xB000 - 0xA000 = 0x1000, which is not 65536,
but 4096, and if I append another 0 it comes out
expected, right?

>
>In other words, using the segment 0xA000, and a
>16 bit offset, you can access all memory up to
>(but not including) 0xB000.
Yes, that is how the stupid (okay "old") real mode
addressing works ...

>
>Now, of course, that means 64k is divided up into
>0x1000 segments, so, for each individual
>segment, we have 65536d/0x1000 = 16d bytes.
>
A segment is divided into smaller pieces? This is
something I didn't know.

>also of note:
>0x0000:16d = 0x0001:0d
>0x0000:17d = 0x0001:1d
>etc...
Okay, I can access the same memory with differnt
segment-offset combinations, now I know why the
the segment index is not in the form 0x0-0xF
(which would make sense for real mode, 16*64KB
would 1 MB, hmm, perhaps we would lose some memory
to the BIOS-ROM & devices ...).

>
>Does that makes sense? I can't think of an overly
>good way to explain it... got any more questions?
>
>Jeff
What you explained here was for real-mode, right?

The Legend

[Guest]

>>It's a weird system, for sure.
>>You know that, for example, between 0xA000
>>and 0xB000 there is 64k (65536d), right?
>
>Yes, 64k is the segment size in real mode.

Yes! Each segment is 64k _LONG_... _BUT_, they
exist every 16 bytes! In other words, every 16
bytes a new segment begins.

>But 0xB000 - 0xA000 = 0x1000

Right, which means 0x1000 segments!!! Not 0x1000
bytes!

>which is not 65536,
>but 4096, and if I append another 0 it comes out
>expected, right?

Well, yeah... add another zero in hex, and you're
actually multiplying by 16 (ie, each segment spans
16 bytes, as I said).

>>In other words, using the segment 0xA000, and a
>>16 bit offset, you can access all memory up to
>>(but not including) 0xB000.
>
>Yes, that is how the stupid (okay "old") real mode
>addressing works ...

Uhm... pmode is segmented as well. Only difference
is, you decide on the frequency, and size of a
segment.

>>Now, of course, that means 64k is divided up into
>>0x1000 segments, so, for each individual
>>segment, we have 65536d/0x1000 = 16d bytes.
>>
>A segment is divided into smaller pieces? This is
>something I didn't know.

No, that's not what I mean... that was a really
bad (and now that I read it, not entirely accurate)
way to reinforce the fact that real mode segments
have a frequency of 16 bytes.

>Okay, I can access the same memory with differnt
>segment-offset combinations, now I know why the
>the segment index is not in the form 0x0-0xF
>(which would make sense for real mode, 16*64KB
> would 1 MB, hmm, perhaps we would lose some memory
> to the BIOS-ROM & devices ...).

!?

>What you explained here was for real-mode, right?

Well, yeah, but if you can't understand real
mode segmentation, you can't convert real mode
segment/offset combo's into pmode (let alone
write a pmode kernel!)

Jeff

[The Legend]

>On 2002-02-12 21:08:50, Anonymous wrote:
>>>It's a weird system, for sure.
>>>You know that, for example, between 0xA000
>>>and 0xB000 there is 64k (65536d), right?
>>
>>Yes, 64k is the segment size in real mode.
>
>Yes! Each segment is 64k _LONG_... _BUT_, they
>exist every 16 bytes! In other words, every 16
>bytes a new segment begins.

Okay now I understand why I write to the 0xA000
segment. A part of it overlaps with the 0xA001
segment and with every other segment up to 0xAFFF,
then I would have to use different offsets.


>
>>But 0xB000 - 0xA000 = 0x1000
>
>Right, which means 0x1000 segments!!! Not 0x1000
>bytes!
>
>>which is not 65536,
>>but 4096, and if I append another 0 it comes out
>>expected, right?
>
>Well, yeah... add another zero in hex, and you're
>actually multiplying by 16 (ie, each segment spans
>16 bytes, as I said).

Okay, then the segment number * 16 is the effective
address I am using?

>
>>>In other words, using the segment 0xA000, and a
>>>16 bit offset, you can access all memory up to
>>>(but not including) 0xB000.
>>
>>Yes, that is how the stupid (okay "old") real mode
>>addressing works ...
>
>Uhm... pmode is segmented as well. Only difference
>is, you decide on the frequency, and size of a
>segment.
Yes, of course! I meant flat mode here, I don't want
to use segments in my OS.


>
>>>Now, of course, that means 64k is divided up into
>>>0x1000 segments, so, for each individual
>>>segment, we have 65536d/0x1000 = 16d bytes.
>>>
>>A segment is divided into smaller pieces? This is
>>something I didn't know.
>
>No, that's not what I mean... that was a really
>bad (and now that I read it, not entirely accurate)
>way to reinforce the fact that real mode segments
>have a frequency of 16 bytes.
>
>>Okay, I can access the same memory with differnt
>>segment-offset combinations, now I know why the
>>the segment index is not in the form 0x0-0xF
>>(which would make sense for real mode, 16*64KB
>> would 1 MB, hmm, perhaps we would lose some memory
>> to the BIOS-ROM & devices ...).
>
>!?
I meant for 1 MB of memory divided in 64 kb segments,
they could have used 16 segments which would be enough,
then we would have to calcuate the effective address as
segnum * 65536 + offset. I think this would have been
even easier for programs when memory is contained in more
than one segment. But Intel didn't do it this way ...

>
>>What you explained here was for real-mode, right?
>
>Well, yeah, but if you can't understand real
>mode segmentation, you can't convert real mode
>segment/offset combo's into pmode (let alone
>write a pmode kernel!)
>
>Jeff

[J. Weeks]

>Okay now I understand why I write to the 0xA000
>segment. A part of it overlaps with the 0xA001
>segment and with every other segment up to 0xAFFF,
>then I would have to use different offsets.

Right.

>Okay, then the segment number * 16 is the effective
>address I am using?

Exactly. Plus the offset, of course.

>Yes, of course! I meant flat mode here, I don't want
>to use segments in my OS.

Yeah, I figured, just wanted to make sure you knew
about this... you don't wanna go writting to
0xa000 in pmode, and wonder why it doesn't work.

>I meant for 1 MB of memory divided in 64 kb segments,
>they could have used 16 segments which would be enough,
>then we would have to calcuate the effective address as
>segnum * 65536 + offset. I think this would have been
>even easier for programs when memory is contained in more
>than one segment. But Intel didn't do it this way ...

Indeed. The only reason I can think that Intel
would do it this way, would be because... when
loading a program into memory, you load it
relative to a segment, right?

If their were only 16 segments, 64k long, then you'd
be waisting a lot of memory. You load in a
problem 65k bytes long, and you'll effectively use
two segments, thus wasting 63k. Back then
memory wasn't cheap

Jeff