Possibly a bit tediously realpolitik, but surely it'd be easiest just to write a routine that shoots out new palette values as quickly as possible for at least as long as the pixel area, set it to alternate between black and white, do a quick frame grab using a TV capture card and write a hasty program to thereby detect exactly which regions you need different bits of the palette to be consistent across?
I assume that palette changes can take effect only outside of an 8 pixel block owing to the contended timings - that should eliinate any problems you might get as a result of the capture card being on a slightly different dot clock. Actually, it might be easier to see if you get the same result in Sim Coupe then just frame grab from there if so. On Mon, Feb 23, 2009 at 10:28 AM, Simon Owen <[email protected]> wrote: > 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 >
