OSDev.org

[attachment deleted by admin]

You can try my FritzOS code...but I am looking at your code now...

In your:

jmp LINEAR_CODE_SEL:PMODECODE + 0x7c00

try getting rid of the + 0x7c00

still looking...

I belive I found the problem, in your:

jmp 0x00100000

try

jmp LINEAR_CODE_SEL:0x00100000

Could be wrong here (And it's happened before...will again ) but this looked odd:

0x00100000 does not equal 0x0010:0000
0x0010:0000 segment:offset equals 0x00000100 linear

Ie "Their staff is too long, they're digging in the wrong place"...commence weird Egyptian jig. ;D

It's multiply segment address by 16 (Move left 1) and add offset to it.

This is why 0x07c0:0000 = 0x0000:7c00

This should lead you to understanding of just why you're limited to 1mb in plain real mode. Max address is 0xFFFFF.

Mind you, it's late, and my mind's hazy so if this is completely wrong hopefully one someone else can correct it and I'll remove the post.

Curufir

Try loading your kernel at 0x1000, to test with....I will post code on how to do this.

Tom wrote: I belive I found the problem, in your:

jmp 0x00100000

try

jmp LINEAR_CODE_SEL:0x00100000

Nope this is fine. He's already loaded CS with the code selector when he made the jump to PMode.

Curufir

[attachment deleted by admin]

I might be wrong but I didn't think that you can access above 1mb with creating a 32bit segment, even with a20 enabled you still cannot access above 1mb without this segment.

Correct me if I'm wrong, but this is what I thought.

Well... for the most part your right. But things get a bit tricky just around the 1MB area itself...

When Intel designed the 8086, the purpose of the segment:offset approach was to allow them to use two 16-bit registers to efficiently form a single 20-bit value, matching the 20 address pins (A0 - A19) that the they were able to fit on the chip. While it worked well enough, there was one catch: the segment:offset pairs could reference addresses larger than 0xFFFFF. Specifically, the addresses from FFFF:00010 to FFFF:FFFF created absolute addresses in the range 0x100000 to 0x10FFEF, resulting in an extra addressing space of just a little less than 64K.

Since there were only 20 physical address lines on the 8086, this made no difference; the memory wrapped around at the 1M point, regardless of anything else, and the addresses from 0x10000 to 0x10FFEF remapped to 0x00000 to 0x0FFEF.
This worked well enough, until the 80286 was developed. Because the new chip had 24 address lines, it could address those extra 65520 bytes, even in real mode. IBM, when they were designing the PC/AT around the chip, realized that a lot of MS-DOS software depended on where the memory wrap-around was, and would break. So, for backwards compatibility reasons, they designed the AT so that the 21st address line (line A20) fed through a previously unused line on the 8042 keyboard controller, masking it and thus forcing the memory to continue to wrap around at 1M.

Some time later, a programmer with Microsoft (or IBM or Lotus - the histories seem to disagree on this) found that it was possible to program the 8042 so as to unmask the A20 line, allowing this extra memory - which would become known as the High Memory Area - to be used. Several memory instensive programs began using this workaround, and IBM soon released a new revision of the BIOS that included a routine to automatically handle the A20 switch. Eventually, when MS-DOS 5.0 was released, MicroSoft included a special driver, himem.sys, which controlled access to the HMA.

So, to make a very long and tortuous story short, yes, it is possible to access a small bit of memory at 0x100000 using 16-bit segment:offset addresses.

However, as was already pointed out, the way he's doing it doesn't work. To load the sector into location 0x100000, he'd need to set ES to 0xFFFF and BX to 0x0010 (or some segment:offset pair adding up to the same thing, though this is probably both the easiest and most memory-efficient address to use).

A much better explanation than mine.

It's a pity the "Where do I start?" thread is so screwed up. IMO there's definitely a place on the board for making a sticky thread of good answers to common questions. I don't know how the board works, but having a thread with only admin write access (To prevent it becoming a mess) containing posts like the one above would be handy for people as a reference.

Curufir

Hey Guys

I tried Tom's test code and i now get a

>>PANIC<< exception(): 3rd exception with no resolution

error thrown up by bochs but it gets further then it used to.

Peter

Hmmm....could I see your log? And where the exception occurs?

[attachment deleted by admin]

Hmmm....I don't see the problem...but I think it is your GDT. Maybe you could try the FritzOS code....works in bochs ( please download BOCHS 2.0.pre2 ).