SeaGtGruff 128 Palette Example as Full Color Playfield

[+Gemintronic]

I don't think SeaGtGruff truly recognizes how awesome some of his stuff is. One example is the recently rediscovered 128 palette example posted here:

http://www.atariage....e/#entry2497191

 

SeaGtGruff effectively made a "mini kernel" that allows for an 8x16 playfield with each pixel allowed its own unique color! I experimented with replacing the static values in the "COLUBK = $xx" statements with variables and that cut the resolution down - only allowing about 5 pixels per row. Adding more "COLUBK = $xx" statements created a venetian blind effect such that each row had a background color.

 

A big tradeoff is that the standard kernel called with the DRAWSCREEN command doesn't play nice due to fighting for CPU time. This is OK and can be worked around. Possible uses:

 

* Map screen

* Object close-ups

* Puzzle games

 

I'm sure this could be enhanced further. I thought I'd just reiterate how cool this example is given a different perspective on its uses.

Edited May 9, 2012 by theloon

[+Gemintronic]

Okay, sorry to bump my own post but I've found that different colors or maybe sequence of colors have different lengths on the screen.

 

Check out this example "Maryo" sprite.

 

 

hue_0_loop

WSYNC = 0 : x = x + 1 : if x = 12 then hue_1

COLUBK = $0E : COLUBK = $0E : COLUBK = $0E

COLUBK = $0E : COLUBK = $0E : COLUBK = $46 : COLUBK = $45

COLUBK = $46 : COLUBK = $0E : COLUBK = $0E : COLUBK = $0E

COLUBK = $0E : goto hue_0_loop

 

Just to be clear the first 3 "COLUBK = $0E" and last "COLUBK = $0E" seem to just be wasting time until the next line. The inner 8 "COLUBK =" statements should be the actual "playfield pixels" displayed.

SGTMARYO.bas

Edited May 9, 2012 by theloon

[+Gemintronic]

I have figured out more on SeaGtGruffs multi-color playfield mini kernel.

 

Turns out I was right about colors being a factor in pixel width. Basically, two or more of the same colors shrink the size of the pixel. Meaning that you MUST have a different value for each pixel! This is not as bogus as it first seems. Thankfully, all TIA colors are +2 away from eachother. So $0E and $0F give the same result (white) on-screen. Any time two pixels have the same color the second same-color pixel needs to be given a value higher than the first pixel by one. The third same-color pixel can revert back to the original value.

 

So two white pixels in a row look like:

COLUBK = $0E : COLUBK = $0F

 

Three white pixels in a row look like:

COLUBK = $0E : COLUBK = $0F : COLUBK = $0E

 

I also figured out what value determines the pixel height and made it a constant at the top of the example. Maryo looks damn good now!

SGTMARYO2.bas

Edited May 10, 2012 by theloon

[RevEng]

I have figured out more on SeaGtGruffs multi-color playfield mini kernel.

 

Turns out I was right about colors being a factor in pixel width. Basically, two or more of the same colors shrink the size of the pixel.

 

Ah, this makes sense now.

 

Normally bB creates something like the following assembly code for assignments...

 

; COLUBK=$48 : COLUBK=$08
LDA #$48
STA COLUBK
LDA #$08
STA COLUBK

 

...except when it sees two or more variable assignments getting the same value on the same line, in which case it optimises the unnecessary LDA commands away...

 

; COLUBK=$08 : COLUBK=$08
LDA #$08
STA COLUBK
STA COLUBK

 

Because this optimisation takes less time in your kernel (which is changing colors as they're being drawn on the screen) it makes any double, tripple, etc., pixels smaller.

 

The work around is either to use different values as you've done, or split up the variable assignments on to separate lines.

[SeaGtGruff]

theloon, I'm glad you're getting some use out of it. It's really nothing special, just your standard mid-line color-changing kernel, which has been done before by other people to display all 128 colors. The main thing I did different was write it with batari Basic instructions instead of assembly, which was mainly to prove that such a thing is possible. The reason for the extra repeated statements was so the timing would work out the way I wanted; in assembly I would have just used the SLEEP macro, because when I wrote the program batari Basic didn't have the "callmacro" instruction yet-- so that's another way to do it, replace the redundant statements with "callmacro SLEEP" to wait as long as you want to make the color changes occur where you want them to.

 

In order for this sort of kernel to be of more general usefulness, it should be rewritten in assembly for optimum speed, and the colors should probably be stored in RAM-- or maybe loaded from some DPC+ queues. For a few months now I've been toying with ideas for a tile-based kernel that would allow multiple color changes per line, but I've yet to produce a decent kernel. One version I tinkered with would have about 6-and-a-half tiles per row, with color changes every 8 machine cycles or 24 color clocks, but I couldn't get it to work out the way I wanted (with an asymmetrical playfield). Another version would have about 4-and-a-half tiles per row, with color changes every 12 machine cycles or 36 color clocks. The reason I'm picking these sorts of numbers is so the color changes will line up to coincide with playfield pixel boundaries.

[+Gemintronic]

I think it's particularly awesome since you bothered to make it in bB. A novice readable "mini-kernel" like display that does something very cool: more than one color per row! I can't wait for what you cook up on the tile based front. You really want me to make an Ultima clone for the 2600 don't you?

 

I've already tried replacing the static values used in the COLUBK statements with variables. Seems to reduce the number of pixels per row to 5 (before the Venetian blind effect happens). Is this because I'm just randomly hacking your code or some fundamental limitation?

[RevEng]

...

I've already tried replacing the static values used in the COLUBK statements with variables. Seems to reduce the number of pixels per row to 5 (before the Venetian blind effect happens). Is this because I'm just randomly hacking your code or some fundamental limitation?

 

Its a fundamental limitation.

 

Loading a variable to store in COLUBK takes 3 cycles, and loading an immediate (constant) value to store in COLUBK takes 2 cycles. More cycles per color-change means less colors per line.

[abaudrand]

I have figured out more on SeaGtGruffs multi-color playfield mini kernel.

 

Turns out I was right about colors being a factor in pixel width. Basically, two or more of the same colors shrink the size of the pixel.

 

Ah, this makes sense now.

 

Normally bB creates something like the following assembly code for assignments...

 

; COLUBK=$48 : COLUBK=$08
LDA #$48
STA COLUBK
LDA #$08
STA COLUBK

 

...except when it sees two or more variable assignments getting the same value on the same line, in which case it optimises the unnecessary LDA commands away...

 

; COLUBK=$08 : COLUBK=$08
LDA #$08
STA COLUBK
STA COLUBK

 

Because this optimisation takes less time in your kernel (which is changing colors as they're being drawn on the screen) it makes any double, tripple, etc., pixels smaller.

 

The work around is either to use different values as you've done, or split up the variable assignments on to separate lines.

 

thats frackin awesome ! I dont understand how did it work but it s really nice

[abaudrand]

Err... I cant managed to get more than 8 columns and 16 rows. each time I add COLUBK, I got venitian blind effect. If I change the value of X to be check, it only increase the heights of each rows... Is there a way to push the limits further?

[+Gemintronic]

Did you try adding more hue_ loops? Also, decreasing the pixelheight constant should give you more room.

 

Here is an example of adding an additional line between hue_14 and hue_15:

hue_14
  x = 0
hue_14_loop
  WSYNC = 0 : x = x + 1 : if x = pixelheight then hue_b
  COLUBK = $0E : COLUBK = $0E : COLUBK = $0E
  COLUBK = $0E : COLUBK = $42 : COLUBK = $43 : COLUBK = $0E
  COLUBK = $0F : COLUBK = $42 : COLUBK = $43 : COLUBK = $0E
  COLUBK = $0E : goto hue_14_loop
hue_b
  x = 0
hue_b_loop
  WSYNC = 0 : x = x + 1 : if x = pixelheight then hue_15
  COLUBK = $0E : COLUBK = $0E : COLUBK = $0E
  COLUBK = $0E : COLUBK = $14 : COLUBK = $23 : COLUBK = $0E
  COLUBK = $0F : COLUBK = $44 : COLUBK = $43 : COLUBK = $0E
  COLUBK = $0E : goto hue_b_loop
hue_15
  x = 0
hue_15_loop
  WSYNC = 0 : x = x + 1 : if x = pixelheight then hue_15_end
  COLUBK = $0E : COLUBK = $0E : COLUBK = $0E
  COLUBK = $42 : COLUBK = $43 : COLUBK = $42 : COLUBK = $0E
  COLUBK = $0F : COLUBK = $42 : COLUBK = $43 : COLUBK = $42
  COLUBK = $0E : goto hue_15_loop
hue_15_end
  for x = 1 to 50: WSYNC = 0 : next : goto kernel_loop

[abaudrand]

thanks for the quick reply !!! I'll try it right away !

[abaudrand]

ok for those who are interested: It work fine as long as you don't call the DRAWSCREEN command. this command will use the last stored playfield data and you will have a flickering between both. (tested on a 32SC kernel). I still can't use for a map but it's nice for still screen. Thanks the Loon for the trick