I might upload updates to some of my recently released programs, just to make a profit off of the noobs.

I have a ton of programs in my out folder that I'm too lazy to readme and zip.

I have two unfinished projects that would rake in a chunk of dl's/day, if I ever get them finished.

lol, at least there are friends in the same boat as I am...

Oh? What are they?

Yeah, I have updates to all my programs... Just need to find motivation to get them zipped and update them.

I used to do that night and day, hence my #1 busiest status, but I've been lazy about it of late.

1. BASIC tetris
2. Pic<->real var (or as close as I can get to it) converter

REAL?! Surely you mean real list...

Lists? Storing pics to lists is probably the slowest and least efficient way to do it. Yes I mean real VAR.

wow, big number

/me thinks it can't be done, but I may be wrong

If it can, it will be via a long and complex algorithm that creates a strange number.

It cannot be done. Here's my reasoning:
1. A picture has 94 * 62 = 5828 pixels
2. This can be represented by a 5828 bit-long binary number.
3. However, we can halve this number to make it smaller by taking NOT pic_number (if indeed NOT # < #), resulting in a 2914 bit number.
4. The most efficient way to represent a binary number in decimal is a change of base.
5. The largest possible size would have half the pixels on and half off (more than half would result in taking NOT # as described above, thus inverting the colors while retaining the pic), or 2914 1's in a row.
6. 2^2914 = 15900374921180024507551649642395308849445241952773992137822085201103401780828214953112876160248225685473896100341872069253368982131602671798576344238663618516170769835946743909016486230146556668052296081251161967006887061849933797911063013807373529033195243716060454162184701305363612527976964106712121726618087487990750875249127278969653687256428853655722239730536109680311944193457087190275482476129596963814577131909421307877360101204494848926714812636576401096497099782526820264069331539706427621462006802750830526074658457452265860424141122995258588016867103608954524293121919424607284749476942351143904925120035997069184575149594059854538514351592616524148140677590424128744490378249571839920626744892457683863427985737248167074665539336272972123849317473894496512770077493372729861286041808150610536271764397699360992564847629665140898792731567442068195675865905453072384
7. QED.

Interesting. This is essentially what I have been messing with:
1. Take a section of length 4 pixels and height one pixel.
2. This section can be represented as a hexadecimal character according to how many pixels in that section are on.
3. Store hex char to a string
4. Repeat until entire pic is coded
This results in a string of about 1400 bytes and takes about 5 minutes to complete. The length of the segment can be modified to be up to 7 pixels long (after this you run out of symbols to use), but it doesn't save much memory and the last segment will overflow the screen.
What do you mean by NOT #?

he means rather than storing the pixels that are on, store the ones that are off - that way you will never have to store more than half the screen, because if over half the screen is black, then you just store the white's and vice versa

The problem with that would be finding how many pixels are on and off in the picture before compressing it.

Just from a hardware standpoint, a real var takes up only 14 user-storable byte/digits of 9-9 each + a 2-digit exponent = 10^16 possibilities. A pic var can store ovre 2^6100 different combinations, a VASTLY larger number. The most you can store in a real is _perhaps_ an 8x8 sprite.

kinda. You could just start encoding for BLACK = 1, and then once you hit a limit, simply invert the number and continue with WHITE = 1

I used that in the DGF compression scheme, here's the ticalc.org url:
http://www.ticalc.org/archives/files/fileinfo/285/28585.html

What do you mean by limit?