skp always

[PK]

Because of the lack of a "skp greater_than_zero" or a "skp not_zero" test condition, I've used a work-around that utilizes "skp run" as a pseudo-branch in a few pieces of code.

Twice now I've had code where the skip was not being taken at runtime after the first pass. It drove me completely nuts until verified that "skp run" as I typed it was not working properly in the hardware. I have not had time to track this bug down to being in the assembler or the FV-1 hardware, but I had no trouble repeating it at the time.

I needed to get my code running with a skip that was always taken, so a little analysis shows the flags (run, neg, zrc, zro, & gez) seem to be ANDed together. For instance, a skip that asked for neg and gez at the same time will never be taken.

In order to construct a skp that will always be taken, simply don't ask for any of the 5 conditions in the instruction.

Code: Select all

equ   always, 0x00          ; This is our binary zero (no condition flags)

skp  always,end_of_skip     ; Ask for skip without conditions
;
; code to be skipped
;
end_of_skip:

[frank]

Please post examples of the code where the 'skp run' fails. We've never seen this happen and would like to investigate.

[PK]

I apologize for not taking a snapshot of things while they were failing. The assembler's trait of saving the current file in the editor for assembly makes it less easy to keep copies of older iterations. Until I can do better, here is the snippet where I experienced the failure twice. The first time I blamed myself, but upon having the same problem a couple days later I was able to use test values to determine which skips were taken. Flipping code back and forth (between skp run and skp 0x00) recreated the error each time the run flag was specified which I tested at least four times Unfortunately, I can't recreate the error at the moment with my code where it is now (128 words long) just by changing the '0x00's back to 'run'. The failure was noticed on the first of the two 'skp run's.

Code: Select all

rdax	pot1,1		;LFO speed
skp	 zro,lfo_stopped
skp	 run,lfo_run

lfo_stopped:
sof	 0,.999
rdax	pot0,-1.555	;use pot0 for manual output
skp	 run,lfo_exit

lfo_run:
;now use the pot1 value in acc for LFO speed 
;

lfo_exit:
wrax	lfo_output,0

[frank]

Hmm, cannot reproduce. Following is my test code, basically it uses POT0 to select either POT1 (POT0 < 0.5) or POT2 (POT0 > 0.5) as a volume control

Code: Select all

clr
rdax	pot0,1
sof	1.0,-0.5
skp 	neg,lbl1
skp	run,lbl2

lbl1:
clr
rdax	pot1,1
wrax	reg0,0
skp	run,outter

lbl2:
clr
rdax	pot2,1
wrax	reg0,0

outter:
clr
rdax	reg0,1
mulx	adcl
wrax	dacl,0

It is operating as expected on my dev board, please try on your board.

[PK]

Your test code operates perfectly here.

I know something was happening... thinking more about it, the Dev board was power cycled but the PC only gets restarted every few days so I'm wondering if something may have confused some XP assembler support DLL. I've also seen some odd behavior if my finger happens to be on the FV-1 crystal when applying power.

If I notice it again, I'll remember to take a snapshot of the machine code listing.

[frank]

If it happens again, please email me the code directly. Does your board have a capacitor on X2 (pin 9)? Your mention of having the finger near the crystal causing a problem makes me wonder if the capacitor is missing. Some crystals don't start clean (may start in an harmonic) if the cap is missing.

[PK]

No cap on pin 9, there's some flux from the X2 connections touching the DVDD supply and GND, and I'm in a marine environment. That seems a much more likely cause than Elvis.

Thank you, Frank. I will mail you directly if I see the behavior again.