#include "projInfo.h" //Don't include in main.h 'cause that's included in other .c's?

#include "main.h"

#include <util/delay.h> //For delay_us in pll_enable

#include <avr/pgmspace.h>

#include _TIMERCOMMON_HEADER_

//#include "../../../_commonCode/charBitmap/0.10/charBitmap.h"

#include _CHARBITMAP_HEADER_

#include "fbColors.h"

#include _SINETABLE_HEADER_

#include "mainConfig.h"

#include "delayCyc.h"

#if (defined(ROW_SEG_BUFFER) && ROW_SEG_BUFFER)

#include "rowSegBuffer.h"

#endif

//Nope, can't be removed yet...

//#define ROW_BUFFER FALSE

//#define LOADROW TRUE

#if (defined(ROW_BUFFER) && ROW_BUFFER)

#include "rowBuffer.c"

#endif

#if (defined(SEG_TET) && SEG_TET)

#include "tetStuff.c"

#endif

// a/o v59:

//PSEGS are the "pixel segments" addressable in RowSegmentBuffer

// e.g. one could load a single row-segment NUM_PSEGS long, and it would

// reach from one edge of the screen to the other

// or any number <=NUM_SEGMENTS of row segments whose lengths all add up to

// <=NUM_PSEGS. (It's possible to extend beyond NUM_PSEGS, which would draw

// beyond the edge of the screen, but it may affect the screen's ability

// to sync properly)

// This value isn't exactly adjustable, it's a characteristic of the

// ratio of the pixel-clock and the system-clock, along with the number of

// system clock cycles used to draw each pixel.

// This value was determined by experimentation with the very specific

// configuration currently in use, though it could probably be calculated

// from other #defines elsewhere.

// (and probably *should* be, at some point, especially with

// experimentations with PLLSYSCLK, LVDS_PRESCALER, SLOW_LVDS, etc...)

// For now, changing this doesn't really do anything except scale some

// drawings horizontally (E.G. SEG_RACER)

//These notes were determined long ago when developing SEG_RACER:

// Wasn't sure where 357 came from... and now I'm wondering where the

// notes I wrote regarding it disappeared to...

// Anyhow, from line 72, if ROW_SEG_BUFFER && !LVDS_PRESCALER

// "ROW_SEG_BUFFER uses 20cyc/pixel" (doesn't match the math I've

// elsewhere) 1024/20*7 = 358.4... so maybe that's something to do with it

// TODO: If it was 21cyc/pixel, wouldn't we have perfect alignment with

// color-transitions and segment widths?

//#define NUM_PSEGS (1024/3+16) //357

#define NUM_PSEGS (1024/3+16)

#include "delayCyc.c"

#include "lcdDefines.h"

//Yes, I know #including C files is bad-practice...

// and yes, this has to be here... for now.

#if(defined(SEG_RACER) && SEG_RACER)

#include "seg_racer.c"

#endif

// a/o v60, this note is OLD, and actually is the whole point behind

// ROW_SEG_BUFFER's current implementation.

// TODO: Between OSCCAL_VAL and FRAME_UPDATE_DELAY

// it seems the speed (at least for the LTN) isn't so important after all

// This could be used to my advantage...

// Maybe bump OSCCAL_VAL all the way up, but use a slower "bit-rate"

// Thus, pixels could be skinnier, thus higher-resolution.

// Or more instructions could be used for the same resolution

// allowing, e.g. sprites from program-memory, without necessitating a

// large (or any?) frame-buffer...

//This used to be handled by TOOFAST_TEST, but now can be configured here

// 0xff sets the processor to run as fast as possible

// (~16MHz? ~128MHz bit-rate)

// 0x00 sets it as slow as possible (~4MHz, ~32MHz bit-rate)

// good for testing whether odd colors

// or bad syncing is due to bits being shifted, etc.

// Maybe due to slow "LVDS" conversion chips, or whatnot.

// This seems to be the case right now... 0xff: black is appearing green

// There should be *some* green in it, but not this much.

// Likely due to different propagation delays between my under-driven

// 74LS86's (running red and green), from 3.3V!

// and the happier and newer 74AHC XOR and OR currently driving the

// clock and DVH/Blue signals

// Highly dependent on the screen itself, some may not run at all with

// such slow bitrates... heck, some may not run at all even at the fastest

// If SLOW_EVERYTHING_TEST is true, this value is overridden

// LTN last used 0x20

// a/o v59:

// 0xD8 is the lowest value that syncs reliably, a few glitches from time

// to time.

// The effect of lower values isn't *quite* what I was expecting, but

// definitely suggests that using ROW_SEG_BUFFER at this bit/refresh-rate

// is dang-near right at the minimum required for this display.

// This might be why the other (same model) display didn't work, but its

// flakeyness at 0xff appeared different than this one's at lower OSCCALs

// --Later note... actually retrying the "flakey" display with the same

// configuration. Actually, yes, the problem looks dang-near identical to

// the "reliable" display's being run at OSCCAL_VALs lower than 0xD8

// Both displays are of the same manufacturer/model.

// "reliable" has the chip: LXD91810 VS252AG

// "flakey" has the chip: LXD91810 VS242AC

// The only bit I don't get is that I'm dang-near certain I had both

// displays working at one point, and from the same code...

// but this OSCCAL value is the maximum, and the only other way to speed

// up the bit-rate changes the resolution; which I haven't done

// for quite some time.

// Also different about this test than when I originally determined it

// "flakey": I've since switched the 74LS00 and LS32 out for LS86's

// (These are wired such that one chip is responsible for the + side of

// every LVDS signal, and one chip is responsible for the - side.

// The best-practice, probably, would be to have the + and - sides of

// an LVDS signal on the same chip. It's also plausible that my test was

// so long ago that it was on the old board which had this configuration

// but I doubt that, since that board was so hokily-implemented (with

// chip-clips and grabbers all over the place) that I can't imagine it

// was ever running again after all those months of disuse. Though...

// if that *was* the case... it could also be that I'm using a different

// ATtiny861... in which case, maybe the RC oscillator and/or PLL aren't

// capable of running as fast...

// Not that I have a ton of these things lying around (three total, in

// various projects already)

// BUT the end-result may be that I just happen to have the one display

// and ATtiny861 on the planet that will work together. That'd be lame.)

#define OSCCAL_VAL 0xff//0xDB//0xDC//0xE0//0//0xff//0x20//0xff //0x00

//a/o v60: These are old experiments...

// they *are useful* for testing new displays...

// but I can't recall off-hand how to use them instead of (or with?)

// rowSegBuffer...

// They're defined and better-described in lcdStuff.c...

//These three are mutually-exclusive (BLUE_VERT_BAR overrides DE_BLUE)

// (BLUE_DIAG_BAR overrides both...)

//#define BLUE_DIAG_BAR TRUE

//A single black bar, followed by a single blue bar... ~1/3 and 2/3's width

//#define BLUE_VERT_BAR TRUE

//#define DE_BLUE TRUE

// OLD NOTE:

// NONE SELECTED DOESN'T SYNC!!! DE not detected???

// Default is drawPix, from program memory...

// a/o v60: drawPix() has since become the de-facto function for drawing

// a row of pixels, regardless of the method.

// It's defined as necessary...

//This is where COLOR_BAR_SCROLL and PIXEL_SCROLL were, in part.

#include "pll.c"

#include "lvds.c"

static __inline__ \

void loadRow(uint16_t rowNum) \

__attribute__((__always_inline__));

#include _LCDSTUFF_CFILE_

//#include "../../../_commonCode/lcdStuff/0.50ncf/lcdStuff.c"

//Nearly everything display-related happens in this interrupt

// It even calls the functions that load (and calculate!) the data for the

// next row.

// So basically, the entire project is running via timer-interrupt.

SIGNAL(TIMER0_COMPA_vect)

{

static uint8_t frameCount = 0;

//Could insert a delay of sorts for scopability...

// (otherwise there's not much guarantee that register-assignments

// later will align with the LVDS frame... though ALIGN should help)

// see scopeHsync.c

if(updateLCD())

{

frameCount++;

//updateLCD() returns TRUE when the frame is complete

// which can be used for whatever purposes

// (e.g. FRAME_COUNT_TO_DELAY)

}

#if(defined(LOADROW) && LOADROW)

//Load the next row into the row(seg)buffer

//data is enabled after T_VD+T_Vlow...

//a/o v60: Rereading this is confusing...

// Basically, there's no reason to call loadRow for display-lines

// which don't display data (e.g. V-Sync)

if((hsyncCount >= T_VD+T_Vlow) && (hsyncCount < T_VD+T_Vlow+V_COUNT))

loadRow(hsyncCount - (T_VD+T_Vlow));

#endif

// a/o v60: This is a funny old note... I can't recall a time when

// loadRow was written, then removed, then added again. Weird:

// Here is where loadRow used to be called

// it has been moved to oldNotes.txt, but it would make more sense

// to look at LCDdirectLVDS <25 or LCDdirect

// loadRow used the time between DE inactive and the next Hsync

// to load a row to a row-buffer (as opposed to a frame-buffer)

// thus, DE could gain more pixels because there would be fewer

// calculations to determine the memory location to write from

// This effect has since been minimized

// BUT loadRow might be necessary for program-memory-based images...

}

#if(defined(SEG_HFM) && SEG_HFM)

#include "seg_hfm.c"

#endif

#if(defined(SEG_QUESTION) && SEG_QUESTION)

#include "seg_question.c"

#endif

#if(defined(SEG_SINE) && SEG_SINE)

#include "seg_sine.c"

#endif

#if(defined(LOADROW) && LOADROW)

// whatever this means... it's OLD.

//#warning "loadRow is currently in an intermediate phase..."

void loadRow(uint16_t rowNum)

{

#if(defined(ROW_SEG_BUFFER) && ROW_SEG_BUFFER)

#if (defined(SEG_RACER) && SEG_RACER)

racer_loadRow(rowNum);

#elif (defined(SEG_HFM) && SEG_HFM)

segHFM_loadRow(rowNum);

#elif (defined(SEG_QUESTION) && SEG_QUESTION)

segQuestion_loadRow(rowNum);

#elif (defined(SEG_SINE) && SEG_SINE)

segSine_loadRow(rowNum);

#elif (defined(SEG_LINE) && SEG_LINE)

//Left here for an example...

// Draws a diagonal line

//OLD NOTE:

//syncing issues due to recursion overflowing the stack???

// Apparently was

//Isn't BLAH = 1 necessary so we don't get a row with no data?

// *looks* like it's working, but I dunno...

#define BLAH 0

segClear();

newSeg(3,0x06, (6<<4) | 3); //W

newSeg((rowNum&0xff) | BLAH, 0x06, (4<<4) | 0); //R

newSeg(1,0x06, (6<<4) | 3); //W

newSeg((255-(rowNum&0xff)) | BLAH, 0x06, (4<<4) | 0 ); //R

newSeg(3,0x06, (6<<4) | 3); //W

segTerminate();

#elif (defined(SEG_TET) && SEG_TET)

//This isn't particularly functional, anymore

// it used to be an intermediate stage between rowBuffer and

// rowSegBuffer... Left here for an example of how it could be done...

#if(!defined(SEG_STRETCH))

#define SEG_STRETCH 5 //(((NUM_PSEGS-6)+RB_WIDTH-1)/RB_WIDTH)

#endif

//3-5 = white + cyan

//6 = letters alternating with above

//7-9 = ditto, stretched

#define TET_VSTRETCH 16

if(rowNum == 0)

{

//Probably not best to put this here, as we're still in the interrupt

// extra-long calculations might cause syncing issues with displays

// that require rows to be a constant time

tetUpdate();

}

if(rowNum % TET_VSTRETCH == 0)

{

uint8_t i;

for(i=0; i<RB_WIDTH; i++)

rowBuffer[i] = fb_to_rb(_K);

// rowBuffer[i] = fb_to_rb((i+rowNum/TET_VSTRETCH)&0x3f);

tet_drawRow(rowNum/TET_VSTRETCH, rowBuffer);

}

segClear();

//Good for syncing to have white on both borders...

newSeg(3, 0x06, (6<<4) | 3);

uint16_t i;

//TET_OVERLAY alternates rows between the TETRIS board and

// an rgb "gradient" The only purpose is to test the idea of

// using the high vertical-resolution to essentially increase the

// number of colors available to a low-resolution image

// sort of like "dithering" in the ol' days of 256 colors in Windows

// but easy to implement in this case with very little overhead

// row-by-row

// The effect, from a ways back, looks like the colors are blended

// (like the Text and Game-board are translucent)

#define TET_OVERLAY TRUE

//TET_GRADIENT takes that a step further and attempts to create a

// gradient between each color in that rgb-gradient.

// It's not as pretty as I'd hoped... though it makes sense...

// first we're alternating between TET's color and the background color

// then the background color is (roughly) alternating between a couple

// colors, several rows between...

// so if a color is stretched 16 rows vertically, that only leaves 8

// rows for the color-gradient... might work better over more gradual

// color-changes

#define TET_GRADIENT TRUE

#if (defined(TET_OVERLAY) && TET_OVERLAY)

if(rowNum & 0x01)

{

#endif

for(i=0; i<RB_WIDTH; i++)

{

//i+1 because we don't want to overwrite the white border...

rbpix_to_seg(rowBuffer[i], i+1, SEG_STRETCH);

}

#if (defined(TET_OVERLAY) && TET_OVERLAY)

}

else

{

#define ROWS_PER 64//(V_COUNT/NUM_COLORS)

uint8_t fbColor;

#if (defined(TET_GRADIENT) && TET_GRADIENT)

static hfm_t hfmGradient;

if(rowNum%ROWS_PER == 0)

hfm_setup(&hfmGradient, 0, ROWS_PER/2-4);

//It's worth it to experiment with changing the range of the

// hfmGradient, ('-4' above and '+4' below).

// to try to avoid one or two stray spikes

// (e.g. power = 1, maxPower = 15, there'll be one bright row

// and 14 dark, it sticks out like a sore-thumb)

// These values are experimental, and entirely dependent on the

// values used...

hfm_setPower(&hfmGradient, (rowNum/2)%(ROWS_PER/2)+4);

if(hfm_nextOutput(&hfmGradient))

fbColor = rgbGradient(ROWS_PER-1 - rowNum/(ROWS_PER)+16-1);

else

#endif

fbColor = rgbGradient(ROWS_PER-1 - rowNum/(ROWS_PER)+16);

addSegfb(RB_WIDTH*SEG_STRETCH, (fbColor));

//newSeg(SEG_STRETCH, fb_to_seg((rowNum*64/768)&0x3f));

}

#endif

//white...

newSeg(3, 0x06, (6<<4) | 3);

segTerminate();

#elif (defined(SEG_GRADIENT) && SEG_GRADIENT)

static hfm_t hfmGradient;

#define ROWS_PER (255) //(V_COUNT/3) == 256

if(rowNum%ROWS_PER == 0)

hfm_setup(&hfmGradient, 0, ROWS_PER);

uint8_t color;

uint16_t power;

if(rowNum < ROWS_PER/16)

rowNum = 0;

else

rowNum -= ROWS_PER/16;

//Since there are four shades, there will be three gradients...

if(rowNum < ROWS_PER)

{

//The ROWS_PER/16 stuff is to help alleviate sharp color-spikes

// which occur early-on... see the explanation in SEG_TET.

color = 0;

//hfm_setPower(&hfmGradient,

power = (rowNum); // + ROWS_PER/16);

}

else if(rowNum < ROWS_PER*2)

{

color = 1;

//hfm_setPower(&hfmGradient,

power = rowNum-(ROWS_PER); // + ROWS_PER/16;

}

else

{

color = 2;

//hfm_setPower(&hfmGradient,

power = rowNum-(ROWS_PER*2); // + ROWS_PER/16;

}

if(power < ROWS_PER/16)

power = 0;

hfm_setPower(&hfmGradient, (power <= 255) ? power : 255);

if(hfm_nextOutput(&hfmGradient))

color++;

color |= color<<2 | color<<4;

segClear();

addSegfb(3, _W);

addSegfb(NUM_PSEGS-6, color);

addSegfb(3, _W);

segTerminate();

#elif(defined(SEG_GRADIENT2) && SEG_GRADIENT2)

#error "Heh, never did implement this..."

#else

#error "Gotta select a SEG_... option, or create your own"

#endif //SEG_ selection

#endif //ROW_SEG_BUFFER

}

#endif //LOAD_ROW

#include "timer0Stuff.c"

#if (defined(ROW_SEG_BUFFER) && ROW_SEG_BUFFER)

void drawPix(uint8_t rowNum)

{

//Note that rowNum isn't really used here...

// and it's only a uint8_t!

rsb_drawPix(rowNum);

}

#else

#include "nonRSB_drawPix.c"

void drawPix(uint8_t rowNum)

{

//This hasn't been used in quite some time...

// it may not work at all anymore.

nonRSB_drawPix();

}

#endif

int main(void)

{

#if(defined(SEG_RACER) && SEG_RACER)

racer_init();

#endif

#if(defined(SEG_TET) && SEG_TET)

tetInit(3);

#endif

init_timer0Hsync();

//This starts pretty late... watch out for WDT

init_heartBeat();

setHeartRate(0);

lvds_timerInit();

// MUCH Of this is outside the screen...

uint8_t imageNum = 0;

uint8_t colorShift = 0;

while(1)

{

heartUpdate();

}

}

#include "rowSegBuffer.c"