blog:commodore_c65_dtv_programming

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
blog:commodore_c65_dtv_programming [2023/01/25 15:28] – [Basic DTV Functions] johnblog:commodore_c65_dtv_programming [2023/01/25 17:21] (current) – [Extended DTV Functions] john
Line 1: Line 1:
 ====== DTV (and C64) Programming - Using the CC65 toolchain ====== ====== DTV (and C64) Programming - Using the CC65 toolchain ======
  
 +~~TOC_HERE 2-5~~ 
 +
 +From [[https://en.wikipedia.org/wiki/C64_Direct-to-TV|Wikipedia]]:
 +
 +> The C64 Direct-to-TV, called C64DTV for short, is a single-chip implementation of the Commodore 64 computer, contained in a joystick (modeled after the mid-1980s Competition Pro
 +> joystick), with 30 built-in games. The design is similar to the Atari Classics 10-in-1 TV Game. The circuitry of the C64DTV was designed by Jeri Ellsworth, a computer chip designer who
 +> had previously designed the C-One.
 +
 +These are my notes on programming for the C64 DTV and making use of some of the extended functionality of the hardware from within C, rather than 6502 assembly. I hope you find these useful - whilst I came to the DTV more than a decade after its popularity peaked, I've found it a very capable little system!
 +
 +{{:blog:c64:commodore64_dtv_mugshot-x600.jpg?200|}}
 ===== Basic use of CC65 ===== ===== Basic use of CC65 =====
  
Line 205: Line 216:
  
 ---- ----
 +
 +==== Extended DTV Functions ====
 +
 +These functions raise the DTV above a simple C64 clone and add substantially improved functionality to the system: increased colours, digital sound and a dedicated image blitter.
  
 === Enabling 320x200 Linear Framebuffer === === Enabling 320x200 Linear Framebuffer ===
Line 460: Line 475:
 } }
 </code> </code>
 +
 +== Bugs ==
 +
 +I've seemingly found a bug which manifests when making sequential DMA calls in a tight loop and the transfer length is 182 bytes or greater. 
 +
 +You can successfully DMA copy quite a large region in a single operation and there are no side-effects, however in my testing I have found that if you have a tight loop where you are DMA transferring line by line, I get corrupted transfers with any size over 181 bytes. See the example below:
 +
 +{{: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:
 +
 +<code>
 +screen = FRAMEBUFFER_LOCATION;
 +for (line = 0; line < SCREEN_HEIGHT; line++){
 +    memset(line_buffer, colour, SCREEN_WIDTH);
 +    dtv_DMA(&line_buffer, screen, SCREEN_WIDTH);
 +    colour++;
 +    screen += SCREEN_WIDTH;
 +}
 +</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.
  
 ---- ----
Line 558: Line 596:
  
 {{: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 ==
  
 However, there is a problem. On the **DTV2** systems (the initial PAL models), the blitter is partially bugged and transparent copies result int a vertical banding effect: However, there is a problem. On the **DTV2** systems (the initial PAL models), the blitter is partially bugged and transparent copies result int a vertical banding effect:
Line 563: Line 605:
 {{:blog:c64:c64_dtv_blitter_example_dtv2.png?400|}} {{:blog:c64:c64_dtv_blitter_example_dtv2.png?400|}}
  
-Therefore, //without mitigation//, only **DTV3/Hummer** systems fully support transparent blits.+Therefore, //without mitigation//, only **DTV3/Hummer** systems fully support transparent blits. If you are //not// bothered about transparency, then the blitter functions fine on DTV2, but to support transparency you need to do some type of workaround.
  • blog/commodore_c65_dtv_programming.1674660516.txt.gz
  • Last modified: 2023/01/25 15:28
  • by john