Author Topic: an other assembly question (Read 7666 times)

ben_g · « **on:** June 04, 2011, 07:33:52 pm »

I don't really get this:

Clears ram	doesn't clear the ram
Code: [Select] `ld hl, (screenx) ld d, 1 ld e, 0 call SubFP ld b, h \ ld c, l ld de, 94 call MulFP ld (screenx), hl ld hl, (screeny) ld d, 1 ld e, 0 call SubFP ld b, h \ ld c, l ld de, 62 call MulFP ld (screeny), hl ret`	Code: [Select] `ld hl, (screenx) ;ld d, 1 ;ld e, 0 call SubFP ld b, h \ ld c, l ld de, 94 call MulFP ld (screenx), hl ld hl, (screeny) ;ld d, 1 ;ld e, 0 call SubFP ld b, h \ ld c, l ld de, 62 call MulFP ld (screeny), hl ret`

In the left part, it clears the ram, while in the right part, it doesn't clear the ram while i have only comented out a few ld commands.

coul someone help please?

Runer112 · « **Reply #1 on:** June 04, 2011, 07:36:41 pm »

I'm guessing that the problem lies in SubFP. I'd probably need to see what that does to narrow down the problem.

ben_g · « **Reply #2 on:** June 04, 2011, 07:38:12 pm »

it's a very simple routine:

Code: [Select]

SubFP:
  or a
  sbc hl, de

thepenguin77 · « **Reply #3 on:** June 04, 2011, 07:41:39 pm »

Does that have a ret on it? And if so, what does mulFP look like?

One thing I would definitely recommend for you is stepping through your code in a debugger. I feel that this would allow you to see exactly where your code is going wrong. It's much nicer to actually watch the crash take place rather than try to search through all of your code to find the small error.

So, assuming you are using wabbitEmu. Press F11. Press G. Type 9D95 (assuming you are running it from the homescreen). Press F3. Quit the window. Then run your program. What you did was you placed a breakpoint at $9D95, which is where your code starts. Then just press F7 to scroll through the code line by line to see what is going wrong. Pressing F8 will also scroll, but it will jump over stuff like calls.

ben_g · « **Reply #4 on:** June 05, 2011, 02:37:56 pm »

Yes, that routine has a ret behind it, i just forgot to copy it.

MulFP looks like this:

Code: [Select]

MulFP:
  ;Multiplies 2 16bit fixed-point numbers
  ;IN: de, bc
  ;OUT: de * bc in hl
  ;DESTROYS: af, bc, de, hl
  bit 7, d
  jr nz, _MulFP_FirstNeg
  bit 7, b
  jr nz, _MulFP_AnsNeg
  jr z, _MulFP_AnsPos
_MulFP_FirstNeg:
  bit 7, b
  jr nz, _MulFP_AnsPos
_MulFP_AnsNeg:
  ld a, 1
  push af
  jr _MulFP_Cont
_MulFP_AnsPos:
  ld a, 0
  push af
_MulFP_Cont:
  bit 7, b
  jr z, _MulFP_BCPos
  call NegBC
_MulFP_BCPos:
  bit 7, d
  jr z, _MulFP_DEPos
  call NegDE
_MulFP_DEPos:
  call Mul16  
  ld l, h
  ld h, e
  pop af
  cp 1
  call z, NegHL
  ret

and it uses the Mul16 routine which looks like this:

Code: [Select]

Mul16:                           ; This routine performs the operation DEHL=BC*DE
  ld hl,0
  ld a,16
Mul16Loop:
  add hl,hl
  rl e
  rl d
  jp nc,NoMul16
  add hl,bc
  jp nc,NoMul16
  inc de
NoMul16:
  dec a
  jp nz,Mul16Loop
  ret

The only thing that i was able to find out while debugging was that it repeated some code over and over again. That was by repeating step by step. as soon as i click 'run', the calc crashes.
Further, i found out that when i call the routine twice, it doesn't clear the ram but ends the program.

thepenguin77 · « **Reply #5 on:** June 05, 2011, 07:02:21 pm »

Ok, the problem is definitely in NegBC, NegDE, or NegHL. So make sure that each of those looks the same, except for the actual register you are negating, and post those, because everything you have posted so far won't crash.

And for debugging, you typically want to use F8. So just keep pressing F8 until it crashes, it will crash when you skip over a routine. Then when you go through it again, step into that routine with F7, then repeat. Eventually, in this case, you will probably find a push without a pop.

ben_g · « **Reply #6 on:** June 06, 2011, 02:23:07 pm »

It crashed on adress 0A18, which is a jump instruction

btw, here's the code for the neg instructions:

Code: [Select]

NegHL:
	xor a
	sub l
	ld l,a
	sbc a,a
	sub h
	ld h,a
	ret

NegBC:
	xor a
	sub c
	ld c,a
	sbc a,a
	sub b
	ld b,a
	ret

NegDE:
	xor a
	sub e
	ld e,a
	sbc a,a
	sub d
	ld d,a
	ret

thepenguin77 · « **Reply #7 on:** June 06, 2011, 03:05:13 pm »

0A18 is part of the OS, you want to try to figure out where execution leaves your code. Your code will be in the $9D95 - ~$B000 range depending on program size.

I put together everything you have posted so far and it ran fine. So I'm really not sure what isn't working right. It might not even be related to the code you posted.

ben_g · « **Reply #8 on:** June 06, 2011, 04:00:49 pm »

Quote from: thepenguin77 on June 06, 2011, 03:05:13 pm

0A18 is part of the OS, you want to try to figure out where execution leaves your code. Your code will be in the $9D95 - ~$B000 range depending on program size.

I put together everything you have posted so far and it ran fine. So I'm really not sure what isn't working right. It might not even be related to the code you posted.

Do you mean this could be a bug in latenite?

EDIT: an other assembler does just the same

Quigibo · « **Reply #9 on:** June 07, 2011, 04:36:56 pm »

I remember one time when I was working on Pyoro I had the weirdest bug that seemingly occurred at random and couldn't be traced back anywhere. It took me a week to find but eventually, I found it and fixed it. I had forgotten to back up the ix register during my interrupt routine. If you're using custom interrupts, make sure the routine is working right.

Another thought, is your program nearing 8kb in size? Any code larger than that will cause a crash due to execution protection on the last page. Try replacing the commented out part in your example with nops instead of the loads, I bet it has something to do with program size rather than the particular instructions.

Also, where are screenx and screeny? You're not writing over any OS variables right?

ben_g · « **Reply #10 on:** June 08, 2011, 03:07:31 pm »

Quote from: Quigibo on June 07, 2011, 04:36:56 pm

I remember one time when I was working on Pyoro I had the weirdest bug that seemingly occurred at random and couldn't be traced back anywhere. It took me a week to find but eventually, I found it and fixed it. I had forgotten to back up the ix register during my interrupt routine. If you're using custom interrupts, make sure the routine is working right.

Another thought, is your program nearing 8kb in size? Any code larger than that will cause a crash due to execution protection on the last page. Try replacing the commented out part in your example with nops instead of the loads, I bet it has something to do with program size rather than the particular instructions.

Also, where are screenx and screeny? You're not writing over any OS variables right?

I don't use custom interrupts. I turn interupts off at the beginning of my program, and turn them back on at the end of my program. I never had problems with this, so I don't see why it would give problems now.

Further, my program is only 2kb in size(on the calc), including a large LUT and a list of variables. Also, replacing the instructions with nops (even with a lot of them) doesn't let my program crash

screenx and screeny are variables defined in the program itself, so i'm not overwriting any OS vars.

I also tried to push ix at the beginning of my program, and pop it afterward. This didn't help either

ben_g · « **Reply #11 on:** June 10, 2011, 03:51:39 pm »

I've been debugging for almost 2 hours now, and i still can't find out why my code crashes.

I've now tried to uncomment all of the commented out lines, and to backup the ix register. This lead to an other problem: I get an ERR:BREAK every time i try to run the program, when i don't press on. I don't know what causes the error message-I didn't even knew the OS did error checking on assembly programs, But how can i get rid of the error?

EDIT: It all works now.

EDIT2: screenie

thepenguin77 · « **Reply #12 on:** June 14, 2011, 01:12:53 am »

Glad it finally works. The best part was that the problem wasn't even in the code you posted

Deep Toaster · « **Reply #13 on:** June 14, 2011, 11:14:38 am »

Wow, that's looking awesome, and glad to know it works

Do you still have problems with that ERR:BREAK? If so here's some info on it (search for "OnInterrupt").

ben_g · « **Reply #14 on:** June 14, 2011, 01:23:54 pm »

Quote from: Deep Thought on June 14, 2011, 11:14:38 am

Do you still have problems with that ERR:BREAK?

Nope, That's all solved now.

Many thanks to everybody who helped me!

Author Topic: an other assembly question (Read 7666 times)

ben_g

an other assembly question

Runer112

Re: an other assembly question

ben_g

Re: an other assembly question

thepenguin77

Re: an other assembly question

ben_g

Re: an other assembly question

thepenguin77

Re: an other assembly question

ben_g

Re: an other assembly question

thepenguin77

Re: an other assembly question

ben_g

Re: an other assembly question

Quigibo

Re: an other assembly question

ben_g

Re: an other assembly question

ben_g

Re: an other assembly question

thepenguin77

Re: an other assembly question

Deep Toaster

Re: an other assembly question

ben_g

Re: an other assembly question