This topic has been moved to Miscellaneous Discussion.

http://ourl.ca/12780

5) Do not use .tig/.8xo files. Not everyone have the tools to open them or transfer them. 8xg is tolerated, but not recommended either.

.tig is essentially .zip with a different extension, so it's not that bad. However, at that point it's better just to use .zip anyway

6) At least include a copy of your readme in .txt/.html format in your zip file. Not everyone wants to download an extra software (or in .tns case, send the game to their calc) to be able to read the readme. If you add extra formats with more details, I recommend pdf, because it tends to remain cross compatible between versions of Adobe Reader for a longer length than .doc files with their respective softwares.

IMO, PDF is only really necessary over HTML when you're writing something for printing (which, for a calc program, isn't necessary).

Darl, I always find that a fun read

I'm glad there are actually uses for that command.  I like the idea of manipulating nibbles, but I don't like the fact that it modifies the source data.  Can you use it on ROM code without any problems? 

You probably shouldn't be manipulating code by nibble Anyway, A contains the correct result even if (HL) can't be changed, IIRC.

This topic has been moved to News.

http://ourl.ca/12713

I'll just inquire over a general detail: since it works (presumably) on the 83+, I take it that it modifies the certificate and not the boot code?
Also, what's the point of encrypting it? It has to decrypt itself to run, and thus it should be easy to get a decrypted version to study.
Also, does it only work against 1.03, or does it work for 1.02 (and perhaps 1.00) too?
Edit: Moved to News.

Thepenguin77, thanks for the code. I've handled the OP1 issue differently, however. Also, before I integrate your code for the homescreen, would it be possible that it work in all contexts where the OS uses an edit buffer, not just the homescreen?
The more important reason for this post is a minor update. It no longer overwrites OP1 (or OP4) and it won't write to a picvar unless it's at least the required size, so it won't corrupt RAM.
HOWEVER, the code has expanded beyond smallEditRAM, and the mechanism I have used to extend it beyond that requires that you have execution protection disabled for RAM page 0. If it isn't disabled, it might crash your calc. (Personally, I've patched my boot code so I never have to worry about it again, but most people won't do that.) If you can disable the protection yourself, then you'll be fine.
Otherwise, I recommend AGAINST updating right now. I'll probably create a separate version that doesn't need the protection disabled, but it'll be slower (only when taking a screenshot, though, so it won't be awful.)
If you want to (and can) try it out, then the new .8xp is attached. If you want to look at the new source, that's attached too. Have fun!

could someone please provide me a code to check if another program is using the same code
poorly said


Like to make sure, in a 2 player game, that the other person is running the program to.

It's impossible to guarantee this perfectly. Moreover, it doesn't seem very necessary Anyway, you could assign a random number to each of your games and have each copy send its number to the other calc, where it's checked for equality. This would mainly prevent accidents more than anything else.

Adding features requires expanding the hook outside the boundaries of smallEditRAM, which I don't feel like implementing right now
As for also having it install an interrupt, I'll add that to my to-do list. Note that many programs still will di, so it's not perfect.
Most likely you'll have to wait until tomorrow for more features, as I'm not sure how much more opportunity I'll have to work on this tonight.