This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision |
| blog:commodore_c65_dtv_programming [2023/01/25 17:00] – john | blog:commodore_c65_dtv_programming [2023/01/25 17:21] (current) – [Extended DTV Functions] john |
|---|
| {{:blog:c64:vice_dtv_256_speed2x.png?400|}} | {{:blog:c64:vice_dtv_256_speed2x.png?400|}} |
| |
| | The colour bars in the image should be continuous for the entire screen width, but they glitch at two points. |
| The above example was generated by the following pseudocode: | The above example was generated by the following pseudocode: |
| |
| } | } |
| </code> | </code> |
| | |
| | If you reduce the transfer size to 181 bytes you do not get the glitching, and if you have a //reasonable-number-of-cycles// between DMA operations you also don't get the glitching... but I don't know what that //reasonable-number-of-cycles// value is. It's clearly a timing issue between DMA operations - due to the time it takes for transfers over a centre number of bytes, but all I know is that the documentation says that checking bit 0 of 0xD31F should indicate whether the transfer has finished or not. It's possible (though unlikely) that this is an emulation bug - until I have a working, physical DTV, I won't be able to confirm. |
| |
| ---- | ---- |
| |
| {{:blog:c64:c64_dtv_blitter_example_dtv3.png?400|}} | {{:blog:c64:c64_dtv_blitter_example_dtv3.png?400|}} |
| | |
| | Notice that the transparent (aka //black//) pixels in the source region are preserved when copying to the destination, and that the original content of the destination is preserved for those areas. Where the source is not transparent, those pixels then overwrite the destination. The mode of operation can be customised - see the [[https://www.c64-wiki.com/wiki/C64DTV_Programming_Guide#BLITTER_DATAPATH|DTV Programming Guide]] for more details; specifically the ALU mode set for register **0xD33E**. |
| |
| == Bugs == | == Bugs == |