It looks a little different and it's smaller.

I lost:
Project M (restored the binary, though)
Latest version of OTBP Assembler (gives me an excuse to rewrite it)
My interrupt-based sound routine (not too hard to remake, I guess)
The small progress with GSM2
Most of the SMB2 sprites I made over the past couple of weeks
Xtravar Beta 2 source code (salvaged the binary, that's all I need I guess)
...anything else on that calc, pretty much.

No, it uninstalls itself after being used once. I used it with RAM Clear. It uninstalled. I used Reset All. Kaboom.

I just tried a http://brandonw.net/calcstuff/fake.zip and I tried out resetting all. And guess what... IT RESET ALL!!!! :paf:

Byebye, all projects.... *loud sigh*

QuoteBegin-Liazon+10 Sep, 2007, 17:14-->

QUOTE (Liazon @ 10 Sep, 2007, 17:14)

jim e?

QuoteBegin-Goplat+1 Aug, 2007, 18:28-->

QUOTE (Goplat @ 1 Aug, 2007, 18:28)

I've thought about this subject a bit and I don't think a C compiler for Z80 would really be practical. The Z80 architecture is badly suited for C (or any other compiled language, really) for several reasons: in C, the normal way to pass arguments to a function is on the stack. On most modern processors, you have a stack-relative addressing mode, so this is fine. Z80 has no easy way to access elements of the stack below the topmost, so the only sensible way to pass things into a function is through registers. But the question of which registers are best to use is dependent on the function itself, and to some extent its callers. C requires standardized calling conventions in order to be able to have separate compilation of multiple source files; a compiler can't generate the code to call an external function if it doesn't know how that function expects its arguments passed. Register allocation on the Z80 is a very complicated problem. On most processors, registers have few if any differences between them - if it works on "R0", it works on "R7". On the Z80, every register has its own special purposes, so deciding what to put where becomes more complicated. When C programmers want an integer, they usually just type "int". This poses a problem for the Z80, since "int" has to be at least 16 bits long. On today's processors, 8-bit, 16-bit, and 32-bit operations are all the same speed, but on the Z80 anything bigger than 8-bit takes up more time and space. Also, in C integer types are signed unless you explicitly say "unsigned". More often than not, it doesn't matter whether a variable is signed or unsigned so programmers just use signed integers to save typing. Unsigned comparisons can be done easily on the Z80 (just use the carry flag), but signed comparisons require that the sign flag and parity/overflow flag be XORed together. Modern processors have conditional jump instructions that do just that; the Z80 doesn't. I strongly doubt that a C compiler could ever produce Z80 code anywhere near as well as a person writing assembly could. As a result, C games would require a lot more memory, which is in short supply on the Z8-based calculators.

jr average=(7+12)/2=9.5, jp average=(10+10)/2=10. Assuming that there's about a 50% chance that it will do the jump.

Just so you know, jr is actually faster than jp on average if there's a 50% chance of jumping...