how memory maps to monitor screen

At various places on the web one can find an article by Krishnakumar
entitled "Writing your own Toy OS". In Part I of this article, he has
an assembly language program boot.s and a C program write.c which are
pretty simple. The assembly language program boot.s is assembled under
Linux using as86 and linked with ld86 to produce a file named boot. The
C program writes boot to the boot sector of a floppy and also places
0x55 and 0xAA respectively at bytes 510 and 511 of the boot sector. This
is just a proof of concept: booting from the floppy causes the machine,
during bootup, to write the letter A in blue to the upper left corner of
the monitor screen and then hang in an infinite loop. I've tried it and it
works fine. Here is the code for boot.s:

entry start
start:
mov ax,#0xb800
mov es,ax
seg es
mov [0],#0x41
seg es
mov [1],#0x1f
loop1: jmp loop1

I decided to modify the code to write two blue letters (A and B) instead of
one and obtained:

entry start
start:
mov ax,#0xb800
mov es,ax
seg es
mov [0],#0x41
seg es
mov [1],#0x1f
add ax,#0x2
mov es,ax
seg es
mov [0],0x42
seg es
mov [1],#0x1f
loop1: jmp loop1

I assembled and linked this with as86 and ld86 and wrote it to the boot
sector of a floppy. When I booted the floppy, the blue A and blue B did
appear on the screen. The A was in the upper left corner and the B was
16 spaces to the right of it. In another version of the program, I had
it write 256 characters in what I thought would be consecutive positions
and, instead, they got written in 5 equally spaced columns with 25 characters
in a column, so some where apparently not on the screen.

Anyway, this shows that I don't understand how the relevant part of memory
gets written to the monitor screen. Can someone please explain how I have
to modify the program I wrote in order to get the B to appear immediately
to the right of the A, and more generally to the i-th position in the j-th
row? Also, in the case of the 256 characters at allegedly consecutive
positions, as described above, what happened to the remaining 256-125=131
characters that didn't appear?
--
Ignorantly,
Allan Adler <ara DeleteThis @zurich.csail.mit.edu>
* Disclaimer: I am a guest and *not* a member of the MIT CSAIL. My actions and
* comments do not reflect in any way on MIT. Also, I am nowhere near Boston.

Allan Adler <ara.RemoveThis@nestle.csail.mit.edu> writes:

> I decided to modify the code to write two blue letters (A and B) instead of
> one and obtained:
>
> entry start
> start:
> mov ax,#0xb800
> mov es,ax
> seg es
> mov [0],#0x41
> seg es
> mov [1],#0x1f
> add ax,#0x2
> mov es,ax
> seg es
> mov [0],0x42
> seg es
> mov [1],#0x1f
> loop1: jmp loop1
>
> I assembled and linked this with as86 and ld86 and wrote it to the boot
> sector of a floppy. When I booted the floppy, the blue A and blue B did
> appear on the screen.

I figured out what was wrong: the ax register is copied to es, which only
defines the segment. Increments in ax amount to adding 16 to the address,
not 1. Leaving ax alone and simply writing to [2] and [3] for the B made
the characters adjacent on the screen.

> Anyway, this shows that I don't understand how the relevant part of memory
> gets written to the monitor screen. Can someone please explain how I have
> to modify the program I wrote in order to get the B to appear immediately
> to the right of the A, and more generally to the i-th position in the j-th
> row? Also, in the case of the 256 characters at allegedly consecutive
> positions, as described above, what happened to the remaining 256-125=131
> characters that didn't appear?

By writing 128 A's, 128 B's and 128 C's and examining the screen carefully,
I figured this out too. The screen is 25 lines of 80 characters each, each
character requiring a byte for the ascii code and a byte to say it is blue.
So the screen corresponds to 4000 bytes located, in this case, at address
B800:0000h. These 4000 bytes constitute the screen buffer in this mode.

Now that that problem is solved, I'm trying to capture those 4000 bytes
and write them to 8 sectors on the floppy using interrupt 13h with AH=3.
For some reason that isn't working.
--
Ignorantly,
Allan Adler <ara.RemoveThis@zurich.csail.mit.edu>
* Disclaimer: I am a guest and *not* a member of the MIT CSAIL. My actions and
* comments do not reflect in any way on MIT. Also, I am nowhere near Boston.