far end of B8000h screen as a page?

Index > Main > far end of B8000h screen as a page?

Author

Thread

lazer1

Joined: 24 Jan 2006
Posts: 185

lazer1 17 Jun 2007, 20:14

I use a b8000h legacy 80x25 page via:

Code:


    mov ax, 03h
    int 10h

Now 80x25 means there are 80 x 25 x 2 bytes == 4000 bytes,

however an MMU page is 4096 bytes,

so if I map 0b8000h via the MMU to a virtual page say it is 123000h

then the first 4000 bytes of the page are fine, just some text
appears.

But if someone writes to the last 96 bytes of the page at 123000h
that goes to the last 96 bytes of the physical page at b8000h

namely b8fa0 to b8fff

I am thinking of a protected system here, what happens
about the last 96 bytes b8fa0 to b8fff as I cannot protect
those with the MMU?

does the h/w just ignore them or?

17 Jun 2007, 20:14

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 17 Jun 2007, 21:00

The same problem with 13h mode, the screen memory is only 64,000 bytes, not 65,536 bytes.

Ralf brown's memory list says this:

Code:

--------V-MA0000000--------------------------
MEM A000h:0000h - EGA+ GRAPHICS BUFFER
Size:   65536 BYTEs  
--------V-MB8000000--------------------------
MEM B800h:0000h - CGA TEXT/GRAPHICS BUFFER
Size:   16384 BYTEs
--------V-MB8000000--------------------------
MEM B800h:0000h - EGA/VGA+ TEXT BUFFER
Size:   32768 BYTEs
--------V-MB8000000--------------------------
MEM B800h:0000h - HGC GRAPHICS BUFFER (PAGE 1)
Size:   32768 BYTEs

According to that, you should don't worry about crossing those "limits". But if you still want to ensure that any access will not cross the b8fa0 limit and you are not using a flat memory scheme then it should be enough using a segment descriptor with a limit of 4000 bytes and any base (since the paging will map from base to [base+limit-1] to $B8000).

Using a flat memory scheme would be possible actually by placing the text memory at the highest virtual addresses and setting a limit that prevents accessing the last 96 bytes of B800:0000. However it requires clearing the granularity bit to 0. I'm not familiar with protected mode programming but I think that you will not be able to map the 4 GB - 96 bytes of virtual space with that bit cleared.

17 Jun 2007, 21:00

lazer1

Joined: 24 Jan 2006
Posts: 185

lazer1 18 Jun 2007, 15:49

LocoDelAssembly wrote:

The same problem with 13h mode, the screen memory is only 64,000 bytes, not 65,536 bytes.

how is the int 13h space used?

b8000h is arranged thus:

an array of byte pairs:

ascii byte,
colour byte: top 4 bits is the background colour,
lower 4 bits is the foreground colour

the colour has 4 bits xrgb
where for background colour x==flashing colour,
and for foreground colour x == bright, so eg
non flashing bright red on blue background 'a' is

'a' , 00011100b

usually you dont use flashing chars so it is 16 foreground
colours on 8 background colours.

Quote:

Ralf brown's memory list says this:
Code:
--------V-MA0000000--------------------------
MEM A000h:0000h - EGA+ GRAPHICS BUFFER
Size:   65536 BYTEs  
--------V-MB8000000--------------------------
MEM B800h:0000h - CGA TEXT/GRAPHICS BUFFER
Size:   16384 BYTEs
--------V-MB8000000--------------------------
MEM B800h:0000h - EGA/VGA+ TEXT BUFFER
Size:   32768 BYTEs
--------V-MB8000000--------------------------
MEM B800h:0000h - HGC GRAPHICS BUFFER (PAGE 1)
Size:   32768 BYTEs      
According to that, you should don't worry about crossing those "limits". But if you still want to ensure that any access will not cross the b8fa0 limit and you are not using a flat memory scheme then it should be enough using a segment descriptor with a limit of 4000 bytes and any base (since the paging will map from base to [base+limit-1] to $B8000).

as long as the extra bytes belong to the "space" of the b8000h
screen then its ok.

this is for long mode where there are no segments so I cannot
use segment descriptors. I set the screen up in 16 bit code via
the BIOS, but access it in long mode,

Quote:

Using a flat memory scheme would be possible actually by placing the text memory at the highest virtual addresses and setting a limit that prevents accessing the last 96 bytes of B800:0000. However it requires clearing the granularity bit to 0. I'm not familiar with protected mode programming but I think that you will not be able to map the 4 GB - 96 bytes of virtual space with that bit cleared.

probably the thing to do is to mark the page as SUPERVISOR and
not allow user code direct access. User code has to call system code
which in software avoids going beyond the limits,

but if the extra bytes are safe then the user can directly access them,

18 Jun 2007, 15:49

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 18 Jun 2007, 16:01

Quote:

how is the int 13h space used?

Actually MODE 13h, the int is the number 10h too. It's just a byte per pixel. Every byte tells to the video card and index into the colour palette.

If you want to see an example of mode 13h download the DOS version of fasm and look into the mandel example.

18 Jun 2007, 16:01

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum