I had an idea to write the file's starting cluster number a few spaces to the left of the file name when I write a directory listing to the screen using memory at 0xb8000. I used 00 for the background/foreground bytes for the bytes of the cluster number so they don't show up on the screen. When I change the bg/fg byte to 0x0f for the number 0x0003 it shows as a black space followed by a white heart - which is correct. The number 0x000d shows as a black space and a white musical note - which is correct as far as I know. I'm sure the correct bytes are where I intend.

My idea is to position the cursor on a visible asterisk left of the file name and hit the enter key. The program reads the invisible cluster number written in the screen buffer 'to the left' of the asterisk. The problem is that anywhere I place the cursor, hitting the enter key returns 0x081b regardless where the cursor is on the screen. With the cursor on the visible asterisk to the right of the invisible cluster number bytes the following code executes:

mov ah,03 ;get cursor position
int 0x10 ;returns dh=row, dl=col
mov al,dh
mov bl,160
mul bl ;ax=dh*160
add dl,dl
movzx dx,dl ;dx=dl*2
add dx,ax ;screen buffer coord. of cursor
mov di,dx
sub di,2
mov ah,byte[es:di] ;hi byte of cluster #
sub di,2
mov al,byte[es:di] ;lo byte of cluster #

This code returns 0x081b in ax regardless of where the cursor is - anywhere on the screen. Apparently it's not possible to read the bytes from the screen buffer like this.  Does anyone know how to do this?
TIA.   Bill S.

On Sun, 15 Dec 2019 21:24:42 -0800, bilsch01 wrote:

I had an idea to write the file's starting cluster number a few spaces
to the left of the file name when I write a directory listing to the
screen using memory at 0xb8000. I used 00 for the background/foreground
bytes for the bytes of the cluster number so they don't show up on the
screen. When I change the bg/fg byte to 0x0f for the number 0x0003 it
shows as a black space followed by a white heart - which is correct. The
number 0x000d shows as a black space and a white musical note - which is
correct as far as I know. I'm sure the correct bytes are where I intend.

My idea is to position the cursor on a visible asterisk left of the file
name and hit the enter key. The program reads the invisible cluster
number written in the screen buffer 'to the left' of the asterisk. The
problem is that anywhere I place the cursor, hitting the enter key
returns 0x081b regardless where the cursor is on the screen. With the
cursor on the visible asterisk to the right of the invisible cluster
number bytes the following code executes:

mov ah,03 ;get cursor position
int 0x10 ;returns dh=row, dl=col
mov al,dh
mov bl,160
mul bl ;ax=dh*160
add dl,dl
movzx dx,dl ;dx=dl*2
add dx,ax ;screen buffer coord. of cursor
mov di,dx
sub di,2
mov ah,byte[es:di] ;hi byte of cluster #
sub di,2
mov al,byte[es:di] ;lo byte of cluster #

This code returns 0x081b in ax regardless of where the cursor is -
anywhere on the screen. Apparently it's not possible to read the bytes
from the screen buffer like this.  Does anyone know how to do this?
TIA.   Bill S.

The way I see it, you forgot to set the ES register to the correct value.

The program writes the directory listing to screen buffer using es=0xb800 then proceeds to set up the arrow keys and read the cluster number bytes it has written to screen memory - all using es=0xb800.

ds=0x1000
es=0xb800 is screen buffer
gs=0x1200 is buffer with root directory

Maybe the screen buffer is unavailable for reading? Is that possible?

bilsch01,

The problem is that anywhere I place the cursor, hitting the enter key
returns 0x081b regardless where the cursor is on the screen.

Suggestion: Check if your values are what you expect them to be.   And start
with *writing* something to the screen before you subtract 2 from DI.   It
will show you if your calculated position is where the cursor is.

If-and-when that doesn't quite work, display the contents of DX after the
"get cursor" call.   After that shows the expected values display the
contents of ES:DI. just before reading from screen-memory / subtracting 2
from DI

Remark: The code you posted works here.

Maybe the screen buffer is unavailable for reading? Is that possible?

Ofcourse.  But not likely (never heard of it).

Regards,
Rudy Wieser

I don't use a debugger with these .bin files. I have a routine I jump to that reads a pushed word and prints 4 hex digits in the corner of the screen and then goes into infinite loop.  Crude but pretty useful. I have similar routines that use call and ret but this one is to be used with jmp. Well, what I had done was type

push ax
call vuhex

instead of

push ax
jmp vuhex

vuhex isn't made for call and  ret.

It's interesting that I made the mistake because I was using jmp vuhex
for checking the screen buffer coordinate in dx register and getting correct results. Then I tried reading screen memory with 'call' and wondered about reading screen memory.

Thanks everyone for your help. Sorry for the bother.

Bill S.

On Monday, December 16, 2019 at 5:39:33 AM UTC-5, bilsch01 wrote:

I don't use a debugger with these .bin files.

Use a debugger.  Microsoft's CodeView 3.x or 4.x can be found
online where Microsoft's C Compiler 6.x is, or MASM 6.x if you
are using DOS, Windows, or OS/2.  It will debug in raw assembly
mode for .BIN files.

You need a debugger to examine the contents of things to see
if what you think it is actually it what it is.  It will gain
you much productivity and resolve issues far more quickly in
pretty much every case.

If you use Microsoft's compilers, use /ZI to include symbolic
debugger information so you can actually step through your
source code rather than machine code.  It makes things so
much easier across-the-board.

--
Rick C. Hodgin