Fast bit doubling, how?

[CuriousOne]

Well, screen buffer if 128x64 pixels. That's 16x64 bytes, that's 1KB.
Since I can't keep it in memory, it is "rebuilt" on the fly, each time display updates.
I'm not doing any smooth scrolling or FX, so 5 fps should be enough.

The routine works as follows - text is read from array letter by letter, appropriate location of EEPROM is read, to get font data, which is then sent to display. With "my" method, it takes approximately 1.2 seconds to redraw whole display. I'll check tomorrow this method and post back about the speed.

[HenrikOlsson]

Well, if the screenbuffer is 1kB it means that you're converting 512 bytes to "double bytes". Even at 4MHz that conversion can be done 30 times/second.
If the refreshing the screen takes 1.2s (!) this "bit doubling" is only ~3% of that time. The bottleneck is elsewhere.

[CuriousOne]

Yes, it is in my code, because I was doing manual reading of bits
will fix it today

[tumbleweed]

Even though it looks longer, this should end up almost twice as fast...

outvar = 0
if (invar.0) then
    outvar.0 = 1
    outvar.1 = 1
endif
if (invar.1) then
    outvar.2 = 1
    outvar.3 = 1
endif
if (invar.2) then
    outvar.4 = 1
    outvar.5 = 1
endif
if (invar.3) then
    outvar.6 = 1
    outvar.7 = 1
endif
if (invar.4) then
    outvar.8 = 1
    outvar.9 = 1
endif
if (invar.5) then
    outvar.10 = 1
    outvar.11 = 1
endif
if (invar.6) then
    outvar.12 = 1
    outvar.13 = 1
endif
if (invar.7) then
    outvar.14 = 1
    outvar.15 = 1
endif

[Ioannis]

I think #2 is faster.

Ioannis

[tumbleweed]

It can depend on the device and where the variables end up, but here's a contrast of the two methods (post #2, post #6)

invar    #2    #6
$00      64    34
$01      64    36
$55      64    42
$FF      64    50

That's for an 18F26K22. Results are in instruction cycles.
Post #2 has the "advantage" of always taking 64 cycles, but #6 is always faster.

[Ioannis]

Impressive!

Thanks,
Ioannis