cyclic rotate of 23 bits

[junki]

Hello,

Can anyone suggest a better way ?

ld hl, # dcs_bits+2 ; 8 msbits here
ld a, (dcs_bits) ; 7 lsbits, leftjust
rra
out (DCSPIN), a ; emit old lsbit, now in A.0
rra
rr (hl) ; rotate the stored bits
dec l ; within a page
rr (hl)
dec l
rr (hl)
....
dcs_bits: .ds 3 ; 23 msbits rotate, lsbit is junk


Thanks,
Juha

[King Harold]

Seeing as it is a constant.. just store the rotated value?

Just a thought, but would it be better to shift 24 bits first, and then do some masking?

What assembler are you using? (never seen .ds before)

[junki]

Seeing as it is a constant

Ha! 23 copies, in each possible position, and only the lsbit
is needed. Boils down to 23 bytes in ringbuffer. Thanks!

The problem is mostly academic, just 134.4 Hz rate.

What assembler are you using? (never seen .ds before)

as-z80 which comes with SDCC compiler.

Juha

[King Harold]

You're welcome
Does this mean that the problem is solved?

[junki]

Solved. Or at least no acute urge to find tighter solutions

[junki]

Code: Select all

    ld hl, (dcs_ptr)    ; 16
    ld a, (hl)          ;  7
    out (DCSPIN), a     ; 11 lsbit is dcs bit
    ld (dcs_ptr), a      ; 13 and it also points to the next

It turned out to be oddly pleasing. Setup routine gets awkward though,
struggling with it now

Juha

[King Harold]

Are you sure about that code?
dcs_ptr appears to be a variable, ok so far so good, then you read a byte from where it points to, and overwrite the low byte of the dw at dcs_ptr with that byte - is this correct behaviour?

Does it work?

looks like it could be part of this (correct if wrong please)

Code: Select all

   ld hl,,(dcs_ptr)
    ld a,(hl)
    out (DCSPIN), a
    ld (dcs_ptr),a   ;will overwrite first byte of the dw at dcs_ptr
    ...
dcs_ptr: .dw dcs_data
dcs_data: .db some bytes here

[junki]

You have it correct. Cannot tell if it works, some soldering yet to be done

The background is "digital coded squelch" in VHF/UHF talkies,
a subaudible addition in the transmission.

In this particular case there was no real need for superoptimisation,
but the method might be useful for other things.

Juha
(I hope this isn't too long snip)

Code: Select all

pio_a_int_dcs:     ; fixed 1968.75 Hz rate
    push hl             ; pusha_some
    push af
    push bc

    ld bc, # 4474       ; 134.4 Hz / 1968.75 Hz * 0x10000
    ld hl, (dcs_bitacc)
    add hl, bc
    ld (dcs_bitacc), hl
    jp nc, 2$           ; not yet time for next bit

    ld hl, (dcs_ptr)    ; 16 here 134.4 Hz
    ld a, (hl)          ;  7
    ld (dcs_ptr), a     ; 13 it points the next byte
    out (DCSPIN), a      ; 11 and lsbit is dcs bit
2$:
   ..
dcs_bitacc:  .ds 2
dcs_ptr::    .ds 2
dcs_bits::   .ds 2*23  ; strange ringbuffer, must not cross pages
   ...
_dcs_start::        ; void dcs_start(int code);
    pop de
    pop hl             ; int code 000 ... 777
    push hl
    push de

    call dcs_frame  ; from int code to dword bits in EHL (23 lsbits)

    ; fill a wierd state machine;
    ; bytes in dcs_bits[46] have
    ; the dcs bit in lsbit and
    ; each byte also points to the next one.
    ; wasteful in many ways, but
    ; the emitter can be very simple.
    ; 
    ; dcs_bits[] cannot cross pages

    ld bc, # dcs_bits
    ld (dcs_ptr), bc

    ld d, # 22      ; not the last bit
1$:
    ld a, c
    rra             ; prepare to suck in databit
    inc a           ; point to next (+= 2 if not the rra)
    rr e
    rr h
    rr l
    rla             ; add databit
    ld (bc), a
    inc c
    ld (bc), a      ; either can be used, depending on previous bit
    inc c
    dec d
    jp nz, 1$

    ld a, l         ; last bit
    and # 1
    or # dcs_bits   ; wraps to first
    ld (bc), a
    inc c
    ld (bc), a

    ; XXY change pio_a vector

    ret             ; later, pio_a_int_dcs will emit them

[King Harold]

I find it a bit worrying that you calculate and set constants though - you could assemble them right in (which would mean you would not have to waste time calculating them on the device)

Once again I must question the use of "ld (dcs_ptr), a", I'm almost certain that that is not doing what you want it to do (which is overwriting part of a pointer with an almost-random variable that doesn't seem to have anything to do with the pointer)

Seriously, I'm not trying to say that it's all wrong, but it's doing something that is stranger than necessary..

Some general tips: avoid the use of BC as pointer, optimizing an increment of a double-reg often isn't worth the risk, store constants as actual constants - assemble-time constants that is

[junki]

worrying that you calculate and set constants

Now I'm confused. Do you mean the bit interval add hl, bc stuff ?
Those @$@^^ fractional Hz make it awkward.

I must question the use of "ld (dcs_ptr), a",

The table contains two equal bytes per each databit. Depending on
the previous databit, another of them is loaded (same value, either will do).
The new byte has next databit in lsbit and 7 msbits are next table index.
If the data was 1 0 1 ... 0
table would be { 2+1, 2+1, 4+0, 4+0, 6+1, 6+1, ... 0+0, 0+0 }
It just replaces increment L, compare and rewind.

H stays the same constantly, table is within 256 byte
page and even aligned.

it's doing something that is stranger than necessary..

Cannot contest that
Or translate the saying about the light motorcycle that broke loose from the driver's grip.

Juha

[King Harold]

Ok well we cleared that up, did you test it in an emulator? (with a breakpoint on the out so that you know whether it's right?)

[junki]

Not with an emulator, but "scoping" with a soundcard.
It looks ok, code 525 (octal) emits the 101 010 101, sync & parity bits follow
and then it repeats. Cannot tell if the parity calculation is correct
or not, but that's another story.

bits look distorted, haven't poked the soundcard to pass DC voltage.
Juha

[King Harold]

Glad it looks ok to you
What is it supposed to output?

[junki]

It's something that some (few) radio repeater equipment require to
hear within a signal before allowing use. Stuff from previous century