Here is a sqrtL routine:
SqrtL:
;Inputs:
;     L is the value to find the square root of
;Outputs:
;      C is the result
;      B,L are 0
;     DE is not changed
;      H is how far away it is from the next smallest perfect square
;      L is 0
;      z flag set if it was a perfect square
;Destroyed:
;      A
     ld bc,400h       ; 10    10
     ld h,c           ; 4      4
sqrt8Loop:            ;
     add hl,hl        ;11     44
     add hl,hl        ;11     44
     rl c             ; 8     32
     ld a,c           ; 4     16
     rla              ; 4     16
     sub a,h          ; 4     16
     jr nc,$+5        ;12|19  48+7x
       inc c
       cpl
       ld h,a
     djnz sqrt8Loop   ;13|8   47
     ret              ;10     10
;287+7x, x is the number of bits in the result
;min: 287
;max: 315
;19 bytes
Also, in case anybody needed a small GCD (Greatest Common Divisor) routine, I have this:
GCDHL_DE:
;Outputs:
;     DE is the GCD
GCDLoop:
     or a
     sbc hl,de
     ret z
     jr nc,$-3
     add hl,de
     ex de,hl
     jp GCDLoop
(a faster one is a few posts up)
If you need a fast way to see if a 16-bit number is divisible by 3 (without actually dividing)
HL_mod_3:
;Outputs:
;     Preserves HL
;     A is the remainder
;     destroys DE,BC
;     z flag if divisible by 3, else nz
     ld bc,030Fh
     ld a,h
     add a,l
     sbc a,0   ;conditional decrement
;Now we need to add the upper and lower nibble in a
     ld d,a
     and c
     ld e,a
     ld a,d
     rlca
     rlca
     rlca
     rlca
     and c

     add a,e
     sub c
     jr nc,$+3
     add a,c
;add the lower half nibbles

     ld d,a
     sra d
     sra d
     and b
     add a,d
     sub b
     ret nc
     add a,b
     ret
;at most 132 cycles, at least 123


Yeah, I noticed the issue, too. I made it so that my characters were 7x7 to avoid the issue, but what is your code for converting the hex? If data is the 64-bit data and a holds the value of the current character:

(in Python code)
if a>64:
    a=a-7
data=(data<<4)-48+a
Just iterate that through each hex digit and overflow shouldn't be a problem. (this also requires that data be a 64-bit unsigned int).

@AssemblyBandit:
I feel that if you ran such a super computer simulation, you would need to slow it down to keep up with all of the 'problems' that need fixing. It would be like running Conway's Game of life and trying to preserve every pixel. As well, you would have to ask if you would even recognise intelligence emerging from your construction, and you would have to recognise when something bad happens or when something good happens. You could not expect human forms to come from your simulation or recognisable forms of communication. If you could recognise each instance of pain that needs remedying and prayers that need answers, and life that needs saving, would you not then automate the process through algorithms? Or modify your universe to be 'perfect' by including code to right the wrongs or preempt them? And you have a finite life. When you die, if you have not made an automated 'God' then your universe will suddenly lose its repairman. And if the universe evolved at a faster rate than ours, what would happen if a being in your created universe created their own universe? If you decided not to preserve their life, then would you be the 'God' responsible for the universe created inside your universe?

This is actually pretty cool to think about

I once wrote an algorithm that I originally generated from a fractal. It was a lot easier for me to come up with the rules for the fractal and then use the image for the algorithm than it was to solve the algorithm problem directly. However, yesterday, after nt touching this problem in almost a year, it randomly popped into my head with a solution, so I have the algorithm below in TI-BASIC (since I had my calculator nearby, I tested it on that). What I am wondering is how to optimise it. I tried to generate it with a binary expansion because ultimately, that is what I will be using it with, but it got too messy without the fractal I was using as a crutch:

Input A
Input B

"A must be odd
While not(remainder(a,2
.5A→A
B-1→B
End


2A/2^B→A
"constraints on A and B will always cause this to be on [0,1)
B-2→B
".→Str1

While B
B-1→B
2A→A
int(A→R
A-Ans→A
If not(R
1-A→A
Str1+sub("01",R+1,1→Str1
End
Except for the first character, Str1 will be a sequence of 0s and 1s. Any ideas? It essentially maps an odd binary number  to another binary number and the map is 1-1.

EDIT:
;given a,b such that a/2^(b+1) is on [0,1) and a is odd
a/2^(b+1)→a
b-2→b
""→string
While b>0
  b-1→b
  2*a→a
  string & str(int(a))→string   ;int(a) will either be 1 or 0, so append this to the string
  if a<1
    1-a→a
  a-int(a)→a


The graffiti game idea sounds fun and the variable tile heights are an awesome feature!

And thanks for the tips, links, and optimisation! Optimisation is one of my favorite things to do for the Z80 calcs (I am primarily a Z80 assembly programmer). I think I found the routine on the Prizm Wiki, though I may have modified it more (I cannot remember). I also never tried testing for periodicity, though I am quite familiar with it (I even took a semester course in fractals and chaotic systems). I planned to write a program for the platform I am more familiar with and then port it to the Prizm to try out the optimisations.

I haven't gotten to look at the code much, but I imagine that it is the difference between using integer or fixed point math and floating point.