Can it be done, byte transform using only logic and maths

[Rybags]

I don't quite get your example there.

 

You can do adds on blocks of data but it's only 8-bit adds, you don't get given the Carry to be able to further process it.

 

Byte 1 of source added to byte 1 of dest, byte 2 source to byte 2 dest etc. But you can have overlap so some tricks are possible, or even have identical address ranges.

[Chilly Willy]

Well, the idea was to add a bunch of rotations of the value together to fill the bits... if the original bit was set. Adding something to itself is the same as rotating left. I was thinking of using v-1 to handle all the bits to the right of the original bit, but that fails with the value 0 as then it sets ALL the bits, which wasn't what he wanted.

[Rybags]

While thinking over solution to another problem, I think I've come up with a way to solve the missing 16 bit addition.

 

It would require storing the numbers in a funny sort of way. bits 0-6 in one byte, bits 7-14 in another byte (so in fact we only get 15 bit precision but should still be enough for most cases).

 

The blit has an add function but it only works on single bytes and you get no indication or ability to use the Carry (number just rolls over).

 

For 15 bit addition:

 

2 blocks of data to add to each other: low_source and high_source. 1 temporary block: carry.

 

Add blocks low_source to low_dest as normal. Bit 7 then becomes the carry which we need to use for addition to the high byte.

 

Fill temporary "carry block" with value $7F.

Copy low_dest block to carry block, using AND #$80 XOR #$80 on the data. Carry block will have 00 for no carry entries, $FF for carry entries.

 

Then copy carry block to itself with AND #1. No carry still = 00, carry = 01.

Then copy low_dest block to itself with AND #$7F to remove the carry entries.

 

Then add carry block into dest_high block.

 

A fair amount of work and we end up with a number system that's somewhat unconventional but still usable for many applications.

But given the huge amount of work the blitter can do vs the 6502, worth the effort.

[candle]

Gary, if you don't mind loosing some of palette indexes, then simplest way would be blit with zoom factor 8 (for 1bpp->8bpp) or 4 (2bpp->8bpp) and then do regular blit with and masks 0x80 0x40 0x20 and so on on apriopriate columns with dest = source

if certain pixel in certain colum is not set, it won't pass though AND and will become 0, in other way it will stay with AND mask value, and using few more than required palette entries, you'll get what you want without much thinking about it

overhead is 8 (for 1bpp) or 4*3 (for 2bpp) pallette entries taken by this conversion

[Rybags]

I thought of a similar strategy to that early on - problem is you quickly run out of palette entries and the collision mode becomes unusable.

 

The 15 bit add - this is for something else entirely different. Although for the purpose I want, it looks like it'll be a series of blits with the CPU having to restart the blit each time to be able to generate a table with cumulative additions.