Assembly

Página 3/5
1 | 2 | | 4 | 5

Por rolandve

Master (220)

Imagen del rolandve

04-05-2020, 16:11

Crystal clear! The puzzle gets a little less complicated. By using ld HL,* ($21) I can load the actual value and with ld (**),HL ($22) I can then get my results. Great. Thanks.

Por pgimeno

Master (245)

Imagen del pgimeno

04-05-2020, 23:07

rolandve wrote:
{ This procedure with 56 as a value has 56 as result }
Procedure plus(VAR nValue);
begin;
      inline ( $3A/nValue/  { ld a, (nValue) }
      $3C/                         { inc a }
      $32		              { ld (nValue),a }

		);
end;

Shouldn't the last line be $32/nValue { ld (nValue),a }?

Por Danjovic

Master (155)

Imagen del Danjovic

05-05-2020, 00:50

rolandve wrote:

Your answer is an exact copy of your previous answer.
This is not about TP, it is about how do I correctly shift, shift, not, shift, shift in assembly. where my byte comes in, in register HL. I can inline the code in TP.

Sorry it was a misunderstood caused by the browser. I didn't meant to be neither repetitive nor rude Smile

It is a pity that that documentation do not get under the hood, but reading the other posts so far I am glad that you are getting closer to a solution.

Por Danjovic

Master (155)

Imagen del Danjovic

05-05-2020, 02:06

Taking into account the example provided for CP/M, at page 158 of the ref[1], it looks to me that nValue holds a pointer instead of a variable. Then to access the variable it is necessary to get its address first.

Check this
ld a,(nVar) will load a with the lsb of the pointer to nvar

against this
ld hl,(nVar) now hl hold the pointer to the nVar
ld a,(hl) now a is loaded with the value of nVar

And you may try some of the following code

procedure Increment (var Integer: iVar);

begin
inline ( $2A/iVar/  { ld hl,(iVar) }  -> HL now has a pointer to iVar in memory
         $34/       { inc (hl)     }
)
end;
procedure ShiftInvert (var Integer: iVar);

begin
inline ( $2A/iVar/  { ld hl,(iVar) }  -> HL now has a pointer to iVar in memory
         $73/       { ld a,(hl)    }
         $cb/$1f    { rr a         }
         $cb/$1f    { rr a         }
         $2f/       { cpl          }
         $cb/$17    { rl a         }
         $cb/$17    { rl a         }
         $34/       { inc (hl)     }
)
end; 

and last but not least, the asterisk means the current address (program counter) of the first byte of the instruction that you are running.

L1:$00/      {              } 
   $CA/*+3/  {  JP L2       }  JP XXXX takes 3 bytes
L2:$00/      {              } 
   $CA/*-5/  {  JP L1       }  
L3:$D6/$20/  {  SUB 20h     }  just a instruction with 2 bytes
   $CA/*-2/  {  JP L3       } 
L4:$CA/*-0/  {  JP L4       } infinite loop  

[1] Turbo Pascal for CP/M

Por Danjovic

Master (155)

Imagen del Danjovic

05-05-2020, 07:10

Ooops.. Last instruction in second block should be ld (hl),a ($77)

Por pgimeno

Master (245)

Imagen del pgimeno

05-05-2020, 11:27

Danjovic wrote:

Taking into account the example provided for CP/M, at page 158 of the ref[1], it looks to me that nValue holds a pointer instead of a variable.

Oops, you're right, I saw the missing destination address but missed the context that it was a parameter passed by reference.

Por rolandve

Master (220)

Imagen del rolandve

06-05-2020, 19:57

No problem, I encountered another puzzle moment Smile You gave me the general direction to solve the puzzle.

inline ( 
         $2A/iVar/  	{ ld hl,(iVar) } 
         $7E/         	{ ld a,(hl)    } <-- ld a,(hl) is $7E not $73
         $cb/$3f/    	{ srl a         }
         $cb/$3f/    	{ srl a         }
         $2f/       	        { cpl          }
         $cb/$27/    	{ sla a         }
         $cb/$27/    	{ sla a         }
         $77       		{ ld (hl),a    }

);

which is significantly faster than

function invert(value : byte):byte;
var
    dbyte : byte;
begin;
     dbyte:=(value SHR 2);
     dbyte:= not dByte;
     dbyte:=(dByte SHL 2);
     invert:=dbyte;
end;

Por rolandve

Master (220)

Imagen del rolandve

07-05-2020, 21:41

Mmm,

My code uses snsmat to check for key combinations like CTRL-S,C etc. However after a some actions the program terminates and I expect that it is because the keyboard buffer fills up with the S,C etc characters. Not sure if this is true, the code runs perfect otherwise. In order to eliminate this potential cause, I would like to call killbuf (#156). Grauw's page mentions HL but I don't know what is supposed to go there.

Can I simply call #156 from assembly or should I first do some other things?

Thanks!

Por Manuel

Ascended (17075)

Imagen del Manuel

08-05-2020, 00:18

I always used:
MsxBios($156); {KILBUF, erase keyboard-buffer}
with msxbios.lib Smile

Por rolandve

Master (220)

Imagen del rolandve

08-05-2020, 09:21

Thanks! msxbios lib does a lot of work before it calls $156. As I expected It wasn't that simple Smile

Página 3/5
1 | 2 | | 4 | 5