Slick

Very.
I'm even more decided to out-slick @al1. One day...

bah! You outslick yourself nearly every day...

It makes me greedy, I want more ;-)

Nice Done! As for implementing the latch, it is already implemented. The PIC output ports are already the latches you need.
All you need to do is only act when the latch pin is zero, otherwise you simply do nothing.

for (;;) {
   if (latch_pin==0) {         btfsc PORTA,3 \ goto $-1
      A=PORTA & 0b00110011;    movf PORTA,w  \ iorlw 0b00110011  \ movwf A
      PORTB= table_b (A);      rcall table_B \ movwf PORTB
      PORTC= table_C (A);      movf A,w \ rcall table_C \ movwf PORTC
      PORTA|= table_A (A);     movf A,w \ rcall table_A \ iorwf PORTA,f
   }                           goto $-13
}

You will need only 3 tables of 64 bytes but you have plenty space free on your flash.

The latch pin is only not implemented, because it is the most obvious feature. Like you wrote its just an if . I wanted to get the decoding running first.

I agree it's just an if :-)

With the PIC that's 2 instructions, 3 clock cycles, or 700K loops per second.
The problem is with the 3 LUT: the chosen PIC doesn't have enough space. But actually you only need one table because there are holes in it. Once you get one of the byte, add/ior 4 to go to the next entry.

I have played with 2 ideas, one stores the tables in the SRAM, the other in data Flash (a bit slower but simpler in the end).

The pin configuration lets you merge the 2nd table. No need of iorwf to PORTA, just write.

The PIC16F527 is actually a 12-bits core and it doesn't have the RCALL instruction.

Damn, I think I know too much about the PIC. No wonder I invest so much in the YASEP :-D

Hello Yann,  notice that Bits 6 and 7 from 'A' are always zero, hence each LUT takes only 64 bytes from flash. And even the 12bit core can implement LUTs with CALL / addwf PCL,F / retlw .... :)

Hi danjovic :-)

yup, the "old way" to look tables up is possible and I suspect it's used by al1's C compiler. I experimented with a couple of different methods, with the LUT in the Flash and in the SRAM/registers (where it maps nicely and it's fast but it requires a cumbersome preload code).

I know the index only takes 64 byte entries :-) in fact, the A and B/C tables can be merged/interleaved (using an offset of 4 or 8 for example). I suppose you can interleave the CALL-based lookup table as well.

Anyway, thanks to pre-shuffling of the LUT, the code is a bit faster and more compact :-)

Brilliant !

Congratulations :-)

I didn't imagine that this idea of a TIL311 replacement would come to life so quickly !

Thank you.!