Can Anyone tell me why this doesn't work?

Hi All,


This is a bita Vesa(256) code to get a line of pixels - it works fine
in protected mode but hangs mysteriously in real mode - I'm fairly new
to asm & wressling with the segment registers and I can't see what it
is that I'm doing wrong - all suggestions welcome (Jason?)

Phil


procedure gline8(x1,x2,y :word;var Buff ointer);assembler;
{hangs in real mode , fine in prot}
asm
cld
mov di, offset Buff
mov cx,x1

@@rloop: push cx

mov bx,y
shl bx,2
DB $66
mov si,word ptr LineOffsets[bx]
DB $66
mov ax,cx
DB $66
add si,ax
DB $66
mov bx,si
DB $66
shr bx,16
{ the above should be shld ebx,esi,16 but I don't know the
opcodes }
cmp bx,CurReadBank
je @@readpix

mov CurReadBank,bx ; { reset to new page }
add bx,bx
DB $66
mov dx,word ptr BankVals[bx]
xor bx,bx
call dword ptr switchbank
{ same as mov ax,$4F05
int 10H or WinfuncPtr in real mode}

mov bx,ReadWindow
test bx,bx
jnz @@readpix
mov bx,CurReadBank
mov CurWriteBank,bx

@@readpix:
push ds
mov ds,SegA000
movsb
pop ds

@@DiffBank:
pop cx
inc cx
cmp cx,x2
jc @@rloop
end;

On Thu, 21 Feb 2008 03:32:51 -0800 (PST), HubbleBubble
<phil_simmons@bluebottle.com> wrote:

>Hi All,
>
>
>Thimovsbs is a bita Vesa(256) code to get a line of pixels - it works fine
>in protected mode but hangs mysteriously in real mode - I'm fairly new
>to asm & wressling with the segment registers and I can't see what it
>is that I'm doing wrong - all suggestions welcome (Jason?)
>
> Phil
>
>
>procedure gline8(x1,x2,y :word;var Buff ointer);assembler;
> {hangs in real mode , fine in prot}
> asm
> cld
> mov di, offset Buff

The minimum change should load [es:di] with Buff (es is used as the
destination segment register in movsb)

les di, [Buff]

> mov cx,x1
>@@readpix:
> push ds
> mov ds,SegA000
> movsb
> pop ds
>

Wolfgang

--
In order to e-mail me a reply to this message, you will have
to remove PLEASE.REMOVE from the address shown in the header
or get it from http://home.netsurf.de/wolfgang.ehrhardt
(Free AES, CRC, Hash, and HMAC source for Pascal/Delphi)

"HubbleBubble" <phil_simmons@bluebottle.com> wrote in message
news:c8858c24-d50a-4842-9d7e-622f2df575b5@62g2000hsn.googlegroups.com...
> Hi All,
>
>
> This is a bita Vesa(256) code to get a line of pixels - it works fine
> in protected mode but hangs mysteriously in real mode - I'm fairly new
> to asm & wressling with the segment registers and I can't see what it
> is that I'm doing wrong - all suggestions welcome (Jason?)

*Always* put your "db $66" prefixes on the same line as the instruction they
prefix, otherwise it's very Turbo Debugger unfriendly.

db $66; shr bx,16

Use square brackets when referencing memory locations, so that it is easier
to see what the instruction is doing:

mov cx,[x1]
les di,[Buff]

Wolfgang has found [the/a] problem, so does it work now?

--
Jay

Jason Burgon - author of Graphic Vision
http://homepage.ntlworld.com/gvision

On 2008-02-21, HubbleBubble <phil_simmons@bluebottle.com> wrote:

I never really did this kind of $66 stuff, but I can vaguely remember that
there were two prefixes, $66 and $67, and that in general $66 evaluates to
the instruction with all parts updated to 32-bit, and $67 lets the register
sizes remain 16-bit. (maybe with the exception of memory operands)

> DB $66
> mov ax,cx

So this would be mov eax,ecx while

db $67 mov ax,cx

would remain ax,cx

If I keep that in the back of my head, I wonder what will happen to this
line:

> DB $66
> mov si,word ptr LineOffsets[bx]

Will this also become dword ptr?

So in general I'd try to put this code in some assembler, assemble, and then
disassemble again with a disassembler that really knows the 32-bit opcodes
and verify that what comes out of it is really what you want. (and put that
then in comments in the TP code)

I haven't done any realmode work since I left TP in 1997-8, so don't really
have strong recommendations, but maybe others can make suggestions about
proper tooling for

On Feb 21, 6:11*pm, Wolfgang.Ehrhardt.PLEASE.REM...@munich.netsurf.de
(Wolfgang Ehrhardt) wrote:
> On Thu, 21 Feb 2008 03:32:51 -0800 (PST), HubbleBubble
>
>
>
>
>
> <phil_simm...@bluebottle.com> wrote:
> >Hi All,
>
> >Thimovsbs is a bita Vesa(256) code to get a line of pixels - it works fine
> >in protected mode but hangs mysteriously in real mode - I'm fairly new
> >to asm & wressling with the segment registers and I can't see what it
> >is that I'm doing wrong - all suggestions welcome (Jason?)
>
> > Phil
>
> >procedure gline8(x1,x2,y :word;var Buff ointer);assembler;
> > {hangs in real mode , fine in prot}
> > asm
> > * * * * *cld
> > * * * * *mov di, offset Buff
>
> The minimum change should load [es:di] with Buff (es is used as the
> destination segment register in movsb)
>
> * * * * * *les di, [Buff]
>
> > * * * * *mov cx,x1
> >@@readpix:
> > * * * * *push ds
> > * * * * *mov ds,SegA000
> > * * * * *movsb
> > * * * * *pop ds
>
> Wolfgang
>
> --
> In order to e-mail me a reply to this message, you will have
> to remove PLEASE.REMOVE from the address shown in the header
> or get it fromhttp://home.netsurf.de/wolfgang.ehrhardt
> (Free AES, CRC, Hash, and HMAC source for Pascal/Delphi)- Hide quoted text-
>
> - Show quoted text -

Thanks for your suggestions guys:

Right, this is where I get deeply confused - I'm trying to write code
which will work in both real and protected mode. Maybe this is an
unrealistic ambition.

Your suggestion of using les di,[buff] is one I tried (and many
variations until I tore most of my hair out) but in real mode I
repeatedly get an invalid pointer error with the passed pointer when
trying to free its memory (it gets corrupted somehow) - by using the
offset only this problem was avoided ... in protected mode if I load
the segment register es then I get error 216 - obviously since
protected mode wants a selector not a segment - so I guess I have to
convert the pointer segment to a selector in pmode? but I don't know
how to do this - anyway pmode is happy with just offsets. Maybe I
should stick to pmode only

"HubbleBubble" <phil_simmons@bluebottle.com> wrote:

> Right, this is where I get deeply confused - I'm trying to write code
> which will work in both real and protected mode. Maybe this is an
> unrealistic ambition.

No, it's trivial in 16:16 protected mode.

> Your suggestion of using les di,[buff] is one I tried (and many variations
until I > tore most of my hair out) but in real mode I repeatedly get an
invalid pointer
> error with the passed pointer when trying to free its memory (it gets
corrupted
> somehow) - by using the offset only this problem was avoided ...

Then something somewhere else is wrong because you should definately be
loading the complete pointer with "les".

Ah, I've just noticed that you pass Buff as a "var" parameter, but Buff is
itself a pointer, so what you have in Buff is a pointer to a pointer,
because "var" parameters are passed as pointers. So what you need to do is
redefine your function as:

procedure gline8(x1,x2,y: Word; Buff : Pointer); assembler;

OR

procedure gline8(x1,x2,y: Word; var Buff : TScanLine); assembler;

Where TScanLine is an array of bytes or whatever.

*Now* you can use "les" to obtain the *value* of Buff, rather than the
address of where Buff is stored. As you wrote it, you need to do this:

les di,[Buff] ; ESI = address of Buff
les di,[es:di] ; ESI = value of Buff

> in protected mode if I load the segment register es then I get error 216 -
> obviously since protected mode wants a selector not a segment -

No, you don't understand. In protected mode, the upper 16-bits of a 16:16
pointer *is* a selector, or at least that's what it's supposed to be.

> so I guess I have to convert the pointer segment to a selector in pmode?

Only if it was supplied by DOS or the BIOS.

> but I don't know how to do this - anyway pmode is happy with just offsets.

I can assure you that 16-bit pmode most certainly isn't "just happy with
offsets". What the pmode version is probably doing is reading/writing to
somwhere else in memory, or you're just "getting lucky" that
Seg(AddressOfBuff) = Seg(Buff).

Maybe I should stick to pmode only

Hmm, I think you need to understand pointers a little more first. :-)

--
Jay

Jason Burgon - author of Graphic Vision
http://homepage.ntlworld.com/gvision

"Marco van de Voort" <marcov@stack.nl> wrote in message
news:slrnfrt6qa.30au.marcov@turtle.stack.nl...
> On 2008-02-21, HubbleBubble <phil_simmons@bluebottle.com> wrote:
>
> I never really did this kind of $66 stuff, but I can vaguely remember that
> there were two prefixes, $66 and $67, and that in general $66 evaluates to
> the instruction with all parts updated to 32-bit, and $67 lets the
register
> sizes remain 16-bit. (maybe with the exception of memory operands)

$66 is the operand size prefix while $67 is the address size prefix.

> > DB $66
> > mov ax,cx
>
> So this would be mov eax,ecx while

Yes (in a 16-bit code segment).

> db $67 mov ax,cx

> would remain ax,cx

It would, or it would be an illegal opcode, since there is no address
involved with this instruction.

> If I keep that in the back of my head, I wonder what will happen to this
> line:
>
> > DB $66
> > mov si,word ptr LineOffsets[bx]

mov esi, dword ptr LineOffsets[bx]

> Will this also become dword ptr?

Yes, but it will still use BX rather than EBX for the effective address
calculation. The "word ptr" is required to keep the 16-bit assembler happy
when SizeOf(LineOffsets[x]) = SizeOf(DWord).

--
Jay

Jason Burgon - author of Graphic Vision
http://homepage.ntlworld.com/gvision

On Feb 22, 3:26*pm, "Jason Burgon" <jayn...@ntlworld.com> wrote:
> "HubbleBubble" <phil_simm...@bluebottle.com> wrote:
> > Right, this is where I get deeply confused - I'm trying to write code
> > which will work in both real and protected mode. Maybe this is an
> > unrealistic ambition.
>
> No, it's trivial in 16:16 protected mode.
>
> > Your suggestion of using les di,[buff] is one I tried (and many variations
>
> until I > tore most of my hair out) but in real mode I repeatedly get an
> invalid pointer
>
> > error with the passed pointer when trying to free its memory (it gets
> corrupted
> > somehow) - by using the offset only this problem was avoided ...
>
> Then something somewhere else is wrong because you should definately be
> loading the complete pointer with "les".
>
> Ah, I've just noticed that you pass Buff as a "var" parameter, but Buff is
> itself a pointer, so what you have in Buff is a pointer to a pointer,
> because "var" parameters are passed as pointers. So what you need to do is
> redefine your function as:
>
> procedure gline8(x1,x2,y: Word; Buff : Pointer); assembler;
>
> OR
>
> procedure gline8(x1,x2,y: Word; var Buff : TScanLine); assembler;
>
> Where TScanLine is an array of bytes or whatever.
>
> *Now* you can use "les" to obtain the *value* of Buff, rather than the
> address of where Buff is stored. As you wrote it, you need to do this:
>
> * les *di,[Buff] ; ESI = address of Buff
> * les *di,[es:di] ; ESI = value of Buff
>
> > in protected mode if I load the segment register es then I get error 216-
> > obviously since protected mode wants a selector not a segment -
>
> No, you don't understand. In protected mode, the upper 16-bits of a 16:16
> pointer *is* *a selector, or at least that's what it's supposed to be.
>
> > so I guess I have to convert the pointer segment to a selector in pmode?
>
> Only if it was supplied by DOS or the BIOS.
>
> > but I don't know how to do this - anyway pmode is happy with just offsets.
>
> I can assure you that 16-bit pmode most certainly isn't "just happy with
> offsets". What the pmode version is probably doing is reading/writing to
> somwhere else in memory, or you're just "getting lucky" that
> Seg(AddressOfBuff) = Seg(Buff).
>
> Maybe I should stick to pmode only
>
> Hmm, I think you need to understand pointers a little more first. :-)
>
> --
> Jay
>
> Jason Burgon - author of Graphic Visionhttp://homepage.ntlworld.com/gvision

Yes that was it Jason - now works perfectly. Yes I did need to
understand more about pointers. Lacking anything but the tersest
description I assumed that I would need to pass the input pointer as a
var like in high level language since I wanted to alter its contents -
Now that I better understand the mechanism I've added your explanation
to my coding notes.

Thanks to all once again.

Phil