Hm, my favorites are: çé♥→ I use those fairly often and I know the codes by ♥-- er, I mean by heart. Um, otherwise I like these ones, too: ╔═╦╗░ ╠═╬╣▒ ║ ║║▓ ╚═╩╝█
Ah, well I was wondering if posing under the name of another person and doing things like *that* (meaning posting stuff that could harm a persons reputation and rights) was considered identity theft.
Oh, that is a really d!ck move People should respect the fact that by spamming under another persons name can be very harmful. It is a form of identity theft. Grrrr, I wish I knew some people interested in law.
The sprite automatically overwrites the background, I think, unless you choose some other logic method. And you will need to reload the image, I think.
You just leave the result either in a register or in memory and then the next function uses that. I imagine that you could set up a spot in RAM that holds the address of where the arguments are, but that isn't very useful. Also, I don't know how the stack works on the Prizm, but if it doesn't push PC onto the stack when you use CALL, then you could pass arguments through the stack.
Yeah... but I have been working on a code interpreter and interpreted code is about as fast as compiled code. It is actually all the parsing that slows BASIC down. Like for example, if you did sum({0,1,2,3,4,5} it has to convert all of those numbers that are separated by commas into 9 byte floating point numbers and it has to create a list temporarily that has those elements then it executes the sum( command. If they had made it "tokenize" the way it is done on an 89, the BASIC codes would be interpreted so much faster.
The downside is that tokenizing code for the first time may take a little while, but after that it no longer needs to tokenize (until the program is edited again). Also, tokenizing sometimes shrinks the program a little.
Well, to do some of the math functions, there is almost no difference in speed (like if you were to make your own floating point math routines, it would be similar to the OS codes). However, in almost all cases the speed increase is huge due in part to the fact that we usually don't use floating point numbers on the calc. Plus, we can draw directly to the screen to make sprites instead of using pixels and lines and stuff...
! You said the 6 word! Anywho, your teacher is obviously a spy bent on getting community hopes up in anticipation of a non programmable calc No, I hope it is a good thing for us
Thanks ^-^ And actually, now that you mention it... I do have some code lying around from way back when to convert a number to a string... I'll add that real quick before I forget!
... Yeah, that isn't an exaggeration... I would love working sans OS! Oh and the math thing, too here are some example of math operations in assembly >_> ...
Divide two numbers up to 65535: 3E1011000029EBED6AEBF57AB820027BB938052CEBED42EBF13D20E9C9
Multiply two numbers up to 65535: 1100003E10EB29EB293001093D20F6C9
Rounded division (using a number 0~65535 divided by a number 0~255): 0610AF2917B938022C9110F7CB39B93803239191C9C9
Divide a super large number by a number 0~255: 0600E5092B7907070757AF41B7CB162B10FB1709BB380293341520EFE141577EB720040D2310F87A0600C9 Okay, so that last one is actually an advantage over in BASIC in some situations (like if you are working with a 70 digit number
But yeah, I wanna see what you come up with
Have you ever made an arbitrary precision math program !?! I do that when I get bored... I like to look at the square root of numbers extended to like the bajillionth decimal place