MestreLion

Hey, dude, thats an awesome tool! Dunno about the pros, but for this humble n00b here your utility is great! Looks very professional, its easy, simple and well polished... can't figure out why no one commented your work yet.. Here are 2 snapshots taken using you cute tool... one is a test file with geometric forms, and the other is... try to guess! btw... to use the table, i simply copy and pasted Andrew's snippet (Session 20, 4th code) in my kernel, replaced PFxData for PFData_x, and... voilá! it worked! frawlessly! and the most incredible thing is: theres no need to adjust the delay! no need to calculate any noop, sleep or whatsoever. The way it is, with no delay, the timing is already perfect! Just adjust the # of lines (to correspond to your actual image) and be happy! Very well done, man!

StartOfFrame ; Start of new frame - VBLANK is still ON lda #2 sta VSYNC sta WSYNC sta WSYNC sta WSYNC ; 3 scanlines of VSYNC signal ;------------------------------------------------ ; 37 scanlines of vertical blank... ldx #0 ; Tuning off VSYNC stx VSYNC VerticalBlank sta WSYNC inx ; 2 cpx #37 ; 2 bne VerticalBlank ; 2 ;------------------------------------------------ ; Do 192 scanlines - Begin of the 1st line ldx #0 ; 2 this counts our scanline number stx VBLANK ; 3 and this turns VBLANK off Picture sta WSYNC SLEEP 16 ; H blank - any change here would not be seen lda #$0F ; 2 sta COLUPF ; 3 = 21 adc #$10 ; 2 sta COLUPF ; 3 = 26 adc #$10 ; 2 sta COLUPF ; 3 = 31 adc #$10 ; 2 sta COLUPF ; 3 = 36 adc #$10 ; 2 sta COLUPF ; 3 = 41 adc #$10 ; 2 sta COLUPF ; 3 = 46 adc #$10 ; 2 sta COLUPF ; 3 = 51 adc #$10 ; 2 sta COLUPF ; 3 = 56 adc #$10 ; 2 sta COLUPF ; 3 = 61 adc #$10 ; 2 sta COLUPF ; 3 = 66 inx ; 2 cpx #192 ; 2 bne Picture; 3 ;sta WSYNC ; 3 = 76 ;------------------------------------------------ ; 30 scanlines of overscan... sta WSYNC ; 3 = 75 lda #%01000010 sta VBLANK ; end of screen - enter blanking ldx #0 stx COLUPF Overscan sta WSYNC inx cpx #29 bne Overscan jmp StartOfFrame Thats 9 different playfield colours per scanline. If I add 1 more adc/sta pair, the screens gets really screwed up. I know a loop would be a LOT more elegant, but i would waste precious cycles with it, and would get no extra colors. As for the actual theorical limit... humm, lets see: - we have 76 cpu cycles - theres no reason to change color while in horizontal blank, because new colour would not be visible. So, all we can do in the first 22 cycles is to set a colour for free and wait till it comes visible. - For the remaining 76 - 22 = 58 cycles, 10 are used for housekeeping and loop maintance (inx, cpx, bne and sta wsync). Yes, i know that experienced programmers use less then 10 cycles, but as im not a Jedi Master (yet), I'll use 10 for my math. So we actually have 58 - 10 = 48 cycles to change colour like crazy. - As far as I know, you cant change playfield colour in less then 5 cycles. 2 to set the desired colour (either by inx, iny, adc, whatever) + 3 to store that colour in COLUBK register - 48 remaining cycles / 5 cycles per colour change = 9.6 Rouding down, thats 9 color changes So, we have 1 initial colour + 9 changes = 10 different colors per scanline at most. Correct? A Jedi Master that could reduce the loop maintenance to 8 cycles would achieve 11 colors, but thats as good as it gets. Isnt it? PS: Why the hell my 1st scanline is screwed up after the first color change?