Simon Cooke wrote: > I was wondering… does anyone have a fully-detailed breakdown of > instruction timings for the SAM? Including at various points in the > screen?
It's hard to have a complete list for anything but the smallest instructions. For longer instructions it depends on how they fall inside, outside or across the contention boundaries, and which memory and I/O locations they access. Internal RAM accesses are rounded to 4T in the border area, or when the display is disabled. They're rounded to 8T when the ASIC is fetching data for the main screen, which begins an 8-pixel block before the main display area. Screen mode 1 adds additional bands of contention, with more 8T rounding (details on my website). External RAM accesses are always rounded to 4T, and ROM accesses are completely uncontended (no rounding). I/O accesses involving the ASIC (ports F8 and above) are rounded to 8T, other ports should be 4T rounded. The total timings for an instruction need to be built up one machine cycle at a time, with the appropriate memory and I/O rounding added, depending on where the raster is. It sounds messy, but it shouldn't be too bad since you'll only have a few fixed fragments of code for the palette changing. I can help you work out the instruction timing breakdown once you've decided on the code fragments to use... > The idea is that it’d generate code to change the palette as the > screen renders, and adjust the bitmap to get the closest it could to > the original source. I was talking about that with someone a year or so ago (Edwin maybe?). Though it was only for a simplified version to change a few palette colours during the border area of each scanline. Your version would be much more effective, but is also far more complicated! Perhaps LCD would be interested in this too? His Retro-X application does a great job with the limited standard palette, so a dynamic palette should be even more impressive. Si
