how to change as86 assember that nasm needed

[cm]

But why? I'd open /dev/vcsa or so, if I wanted to do it in gcc - or even if I didn't...

There are probably ways to do this in a win32 program too. The point was that setting pointers to arcane values is not the way to go in most protected mode environments.

[Frank Kotler]

Right. Instead of trying to make a stupid joke, I should have tried to explain why, in a protected mode OS, just writing to 0xb8000 isn't likely to do anything useful. In a word "paging"... "virtual memory"... or, "when is 0xb8000 not 0xb8000". A Linux executable starts at 0x8048000. Another Linux executable starts at 0x8048000, too. (same idea in Windows, only the address is 0x400000... or so) Yet we can run them at the same time! How is this possible? These addresses are "virtual" addresses, and don't refer directly to physical RAM. Instead, they serve as a sort of "index" into a hierarchy of "page directories" and "page tables"... These eventually refer to physical RAM... or perhaps to a swap file, if we're out of RAM (we don't want this to happen!) I'm fuzzy on the details, but you'll need to know if you're writing an OS!

The video (text) memory is at 0xB8000 physical. But in a multi-tasking OS, we wouldn't want to write direct to video memory even if we could - it might not be "our turn". So we pretty much need to utilize the OS for this kind of thing...

Right now, Codeferever (and maybe Maryjane, too - apparently they're not classmates) kind of have one foot in each of three canoes. We started out looking at Linux 0.12, and its "bootsect.s" - used the bios to print its message. Then we looked at some "dos" code, writing to 0xb800:0000 (and following bytes). This is, no doubt, running in "fake dos", as provided by Windows (ntdvm.dll?). You may need to need to be in "full screen mode" for this to work, it might not work in a "dos Window". Then we look at VC code. I don't know VC, but I ASSume it expects to be producing "Windows programs". Same CPU, but very different sets of rules, in terms of what we're allowed to do, and what has been done for us!

You'll gain an appreciation of this as you work from "bootsect.s" up through loading a working "system" of some kind. A 16-bit system is mildly amusing, but not useful, so you'll want to get into protected mode... set of tutorials by Alexei Frounze you may find useful here:

http://members.tripod.com/protected_mode/alexfru/pmtuts.html

Much more info about OS development here:

http://wiki.osdev.org/Main_Page

I suppose if 16-bit systems are obsolete, 32-bit systems are well on their way...

http://wiki.osdev.org/User:Stephanvanschaik/Setting_Up_Long_Mode

That should keep you busy for quite a long time! But take it in small steps, and we'll see if we can help with assembly-related questions that come up (if any).

Best,
Frank

[codeferever]

Thank you,Frank!
I know,each OS has it's own memory map,and DOS set text-mode at 0xb8000,and windows put it at 0x40000,perhaps,although in a virtual DOS(I want to know the range of DOS in Windows XP,if anyone know).And when we use nasm to compile a 16-bit code,windows will set it's start code at "Virtual DOS"address,then we can display our routine correctly,right?
and if we use VC,it will set it at a address(this is what I want to know,but  I think it is not the "Virtual DOS"address...) by default , however,my code will run into a "can't be read or write" space,then windows warning us ?

I want to know the DOS memory map,is there anybody knows?
And I think it is a very interesting way to control a peripheral device like writing characters at 0xb8000 when their addresses have been known in Virtual DOS memory...

[Keith Kanios]

x86 Memory Map @ OSDev.org Wiki

[Frank Kotler]

Yeah, that's a good one! I was going to suggest that there's a "memory.lst" in that big package of stuff you downloaded from Ralf Brown. The OSdev stuff is probably "more relevant" to what you'll be doing - same information, pretty much.

But I didn't explain it right. Dos doesn't "put" text-mode video memory at 0xB8000, that's where it "is" - physical memory, on the video card. Starts at 0xA0000 - graphics memory, usually. At 0xB0000 is usually "monochrome card" text memory, at 0xB8000 EGA/CGA/VGA text memory. You can persuade the card to use any of these addresses by diddling a couple bits on a port (3CFh ?) - I don't see any advantage to doing so. ("Richard Cooper", a.k.a. "PJ", author of "softer" for Linux, puts text at 0xA0000 - I don't know why. That's how I happen to know we can do it.) At 0xC0000 is the code for the video card

When Windows boots, along with switching to pmode, it enables "paging" (bit 31 in cr0). At this point, all addresses are "virtual". The "virtual dos address" will start at zero and run up to one megabyte (Or so... there's a "high memory area" above one megabyte). But this is "mapped" to physical memory - wherever Windows wants to put it.

This is a hardware feature (available on 386+ dunno about 286) that the OS takes advantage of. You don't "have" to enable paging in your OS - probably want to get something working without it first - but the reason Intel added it, and everybody uses it, is that there are big advantages to "virtual memory".

That's still not a good explanation. Poke around that OSdev site (and nntp:alt.os.development ) looking for "MMU", "paging", "virtual memory" and the like. I suspect that working through an example (which I have not done) is the best way to understand it...

Best,
Frank