Field mover
pedward
Posts: 1,642
I wanted to be clear about how the field mover works.
So I've got an 8x8 bitmap font, 2 longs per character.
The font is/will be arranged so that I can use a counter to handle scanlines, scanline 0 will have 0 byte field, scanline 7 will use the 7th byte field, this arranges the font so top byte is the lowest byte in the first long, so the top of the font is the 0th scanline.
33333333_22222222_11111111_00000000
77777777_66666666_5555555_44444444
I can use a mask on the scanline counter to mask the upper long or lower long.
To assemble a long to push into the CLUT for display, I would use MOVF to shift D by 8 bits, shoving the Nth byte of S into the lower position.
So I take the ascii value of the screen buffer from HUB ram, multiply it by 2 to get the base offset of the character, add the shifted upper masked bit of the scanline counter, then load the masked lower 2 bits of the scanline offset into the SETF command, and call MOVF to read the correct byte from the font and shift it into the buffer long I'm assembling.
So 2 instructions (SETF, MOVF) will allow you to move bytes or words from any arbitrary source register+offset to any destination register+offset, optionally shifting the data.
Am I understanding this instruction correctly?
I assume this was written to facilitate a shift register for serial comms?
It sure would make byte wide access to QSPI flash work fast, and eliminates the Prop1 requirement of having the data lines on pins 0-7 (the GCC guys know about this).
So I've got an 8x8 bitmap font, 2 longs per character.
The font is/will be arranged so that I can use a counter to handle scanlines, scanline 0 will have 0 byte field, scanline 7 will use the 7th byte field, this arranges the font so top byte is the lowest byte in the first long, so the top of the font is the 0th scanline.
33333333_22222222_11111111_00000000
77777777_66666666_5555555_44444444
I can use a mask on the scanline counter to mask the upper long or lower long.
To assemble a long to push into the CLUT for display, I would use MOVF to shift D by 8 bits, shoving the Nth byte of S into the lower position.
So I take the ascii value of the screen buffer from HUB ram, multiply it by 2 to get the base offset of the character, add the shifted upper masked bit of the scanline counter, then load the masked lower 2 bits of the scanline offset into the SETF command, and call MOVF to read the correct byte from the font and shift it into the buffer long I'm assembling.
So 2 instructions (SETF, MOVF) will allow you to move bytes or words from any arbitrary source register+offset to any destination register+offset, optionally shifting the data.
Am I understanding this instruction correctly?
I assume this was written to facilitate a shift register for serial comms?
It sure would make byte wide access to QSPI flash work fast, and eliminates the Prop1 requirement of having the data lines on pins 0-7 (the GCC guys know about this).
Comments
More font resources: http://nfggames.com/games/fontmaker/
A number of us wanted something like this instruction as we found that we were often rearranging bytes. Some of the uses were to do with interfacing external memories, the endian issue with emulators, strings, and other things. To assemble those took many instructions whereas we can now do this simply. I am sure the GCC guys wanted this feature, perhaps more than the rest of us. I think Bill had a lot of input here too. We have Chip to thank for not only just providing us with a basic instruction, but one that is far more powerful.
As to your actual question regarding the movf instruction, I will leave that for Chip to answer.