Quote Originally Posted by THE_RB View Post
Wow Darrel! You don't mess around hey? You did that so quick and quite neat and professional too. Maybe I should start coding in basic!
Maybe you should.

But having done it before, made it real easy to do again.
The first time took much longer, but this one turned out better. "Good Dog".

So what is the difference between 8/14/16 as in your comment? What do I need to code up as export options for BTc Encoder??

Maybe the btc_wordbits var might be more beginner friendly as "PIC_core_type" var of 14 or 16 for 14bit core PIC and 16bit core PIC respectively?
That's what I started with too, (PIC_type) but then I realized it wasn't really dependant on the Core.
  • An 18F would be able to play files encoded with any of the 3 formats. Although 16-bit data is the most efficient, using the least amount of flash.
  • Many 16F's will be able to play either the retlw or 14-bit encodings. It depends on whether that PIC can read it's own flash or not.
  • For the 16F PIC's that can't access their flash, you're stuck with retlw. But frankly, those PIC's are so small, they wouldn't be able to hold more than a quick "Ding-Dong" sound. Or maybe just the "Ding".
And that's why I went with btc_wordbits. To reflect the number or bits per word, without giving people the impression you had to use 1 specific type depending on the chip you have. Sound encoded with 14-bit can still run just fine on an 18F.

Umm, now I'm getting more confused! With .asm data tables in 14bit core pics they still only store 8 bits (as a "retlw" instruction). Unless you have a different system in mind?
I DO!

There are a couple ways to do the 14-bit encoding, using the MPASM opcodes DA or DW. You end up with the same thing either way.

With DA, it takes two 7-bit numbers and packs them into a single 14-bit Word.
If you were to convert 8-bit data to a 14-bit packed stream, it might look something like this ...
Code:
btc_wordbits = 16          ; 8=retlw, 14=16F's, 16 for 18F
;---------------------------------------------------------
    DB  0xB5,0x6A,0xAA,0x52,0xCA,0xA9,0x4B,0x35,0xAD,0xB6,0xB5,0x9A,0xDB,0x56,0xAA,0xAA

  0xB5  = 1011010 1      ; Shift Right 1 and save the LSB
        = 0x5A
          
  0x6A  = 1011010 10     ; Rotate extra bit into next value
                         ; Then shift right again for only 7-bits
        = 0x5A

  0xAA  = 1010101 010    ; Rotate 2 in, and 3 out
        = 0x55

  0x52  = 0100101 0010   ; 3 In, 4 out
        = 0x25

      This continues on for another 3 bytes.
      Every 7-bytes, there's an extra byte, and no extra bit's.
      Then you can put the data in a "DA" statement which packs each 2 bytes in a 14-bit word.

btc_wordbits = 14          ; 8=retlw, 14=16F's, 16 for 18F
;---------------------------------------------------------
   DA  0x5A,0x5A,0x55,0x25,...
Of course, since you may have the data in a binary stream in your encoder.
You may just need to take 7-bits at a time, and put them in Bytes.

Using DW is very similar, except you break the data into 14-bit words, instead of 7-bit bytes.
Then you can make the data like this.
Code:
btc_wordbits = 14          ; 8=retlw, 14=16F's, 16 for 18F
;---------------------------------------------------------
    DW  0x2D5A,0x2AA5, ...
And just a quick note on the retlw format.
All those ORG statements make it impossible to use with PBP because those addresses are occupied by PBP's System Library.
The problems of Locating the data, and Page switching if it crosses a boundary can be handled in the software. But the data should be allowed to go anywhere in the PIC. Not at predetermined addresses. So there's no real need to have the ORG's in there.

Anyway I'm very impressed with what you have put together so quickly and I will link to it on my web page when you are happy that it is all done etc.
And I am impressed with the quality of the sound with such small encoded btc files.
So we're even.

While this program is currently written for PBP. The same thing can be made to work in straight ASM too.
So not only will you get a PicBasic version, you'll get a new ASM one too.

Once we have it all working, I'll optimize it down to ASM, which should speed it up a bit. Right now it putters out on 44100bps unless using 20mhz crystal or higher. It should be able to play 44100 with a 4mhz crystal, but that'll come later.

Thanks alot for all your effort. And please take your time.
I'm sure we both have other things to attend too as well.
But if you have questions, don't wait.

Best regards,