It's pretty decent for a graphics card

Quote from: DJ_O on October 26, 2011, 04:32:41 am

From what I remember, they could overclock the calc fine, but the problem is that when we do so, it gets reset, so it's pretty much useless until they figure out how to get around that.

Yes, the code is very CPU specific because the registers required move around in all of the different CPU models and must be accessed from physical memory. Also, we know how to avoid resets. It's just a matter of setting a flag differently.

Here's an Axe backup that I'm fairly sure contains an infix to RPN converter (and I don't have a link cable to restore it to .8xp state). I remember commenting it fairly heavily, so the code should be relatively self-explanatory.

They're all different languages and none of them are actually BASIC. Go figure.

If you stored all the pictures in one GDB variable, the code looks something like this:

While(screen active)
copy(gdb+O,L6,768)
O+768^(768*number of frames) ->O
pause 500
end


Here's my quick demonstration of an incredibly simple "random" space filling method. I wrote it in Axe, although it's easy enough to translate to Assembly.

$0904->A
Repeat getkey(15)     //Loop until user presses Clear
{A} or {A and 511+L6}->{A and 511+L6}
A+1->A
Dispgraph
End

0x0904 is just a location in memory on my calc that has "random" values that are ORed with the contents of the screen. It takes almost no additional memory to implement. The ANDing A with 511 is equivalent to taking A mod 512, which is an arbitrarily chosen constant to prevent A from overflowing the screen and ORing RAM with random values...

All it needs is the appropriate bitmasking to get it to work within a box onscreen.

You can use Mimas if you need to.