cyclic rotate of 23 bits
Moderator: MaxCoderz Staff
cyclic rotate of 23 bits
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
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
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
Ha! 23 copies, in each possible position, and only the lsbitKing Harold wrote:Seeing as it is a constant
is needed. Boils down to 23 bytes in ringbuffer. Thanks!
The problem is mostly academic, just 134.4 Hz rate.
as-z80 which comes with SDCC compiler.King Harold wrote:What assembler are you using? (never seen .ds before)
Juha
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
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
struggling with it now
Juha
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
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)
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
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)
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
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
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
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
Now I'm confused. Do you mean the bit interval add hl, bc stuff ?King Harold wrote:worrying that you calculate and set constants
Those @$@^^ fractional Hz make it awkward.
The table contains two equal bytes per each databit. Depending onI must question the use of "ld (dcs_ptr), a",
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.
Cannot contest thatit's doing something that is stranger than necessary..
Or translate the saying about the light motorcycle that broke loose from the driver's grip.
Juha
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
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
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
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am