stuck on Wii/phone b/c parents took BOTH laptops... Anyway, what is the code?

For the Off stuff that I posted on the previous page? Or the checksumming code?

Edit: Here's the checksum code, courtesy of the great Brandon Wilson:


Code:

Thanks for the code, Kerm. I feel badly because I haven't had a chance to develop in z80 much, and more so because of my failure to reply. I've been caught up in schoolwork and now my laptops have been taken away again. However, now that summer is arriving, I will make sure to pick this back up ASAP. I am also determined to purchase a Prizm sometime before school starts again. [/necropost]

Thanks for the update; in this case it doesn't count as a necropost. I'm glad to hear that you haven't abandoned programming, and I think it will be great to see what you can make with a Prizm.

As of now, I am still without a laptop. However, I may start a small project in Axe until I can program assembly again. I know that I *could* use Mimas, but I can't stand it sometimes. I don't believe I've ever thanked you guys here for your support, so I'm going to thank you now. * technomonkey76 thanks the other Cemetechians for their support

Kerm: I really hope that I can code for a Prizm very soon!

*bump* Still no laptop; I am on my mother's computer at the moment. I am really rusty with assembly after having such a long time away from it. I am, once again, attempting to improve my password program, and am wondering if anybody could provide feedback or assistance. I have added comments for virtually every line as well. My issue was that it wouldn't enter the Error label, but I just changed some code, so I'm unsure. Could anybody help?

The link http://pastebin.com/mw53tTTF

EDIT: I fixed it!!! The main issue (I think) was pop af, because (I think) it restored the OLD flags, and was unnecessary anyway after I moved the cp $FF. Now, if anybody can help me optimize, it would be greatly appreciated.

I am going to send this updated version to my friend if he wants it. He may not, because if he types something incorrectly by accident, and doesn't know where the accident occurred, he'll be waiting a while to gain entrance into his calc, for as one can see, it makes the end user wait for 7 keypresses, then restarts the entire code-entering procedure. If he didn't know the actual point where he mistyped, he could quite easily be pressing keys for a LONG time.

That's why this is so secure, in my opinion (unless disassembled, of course). Somebody doesn't know the keypress sequence, and they aren't notified when they type it incorrectly! The battery would die before they could figure it out, depending on the code length!

Anyway, the code on the above Pastebin is the fixed code.

EDIT 2: Code has been updated again due to a suggestion by none other than _player1537. He made sample code using an array and suggested that I would use it. I still believe that it can be optimized further, but Tanner's suggestion brought the bytesize down to 171 from 217, and I have a feeling that the way he suggested I do it will optimize speed, even though it's not truly necessary for this.

What if your friend decides to pull a battery?

If that happened, it would work, but it would cause a RAM clear eventually. (I tested it.)

With Kerm's code, the compiler is unsure of where to find (RAMChecksum). I am unsure why that is.

Kerm, do you have a pointer to RAMChecksum in hex format to include in my .equ section with GetKeyRetOff?

EDIT:
Okay, so I just had a truly crazy yet epically awesome idea, that would set me apart from all other password programs: remote unlocking via gCn.

First of all, I would need a hub (8 char. max), correct? I would call it PassHub. Would I need a server of my own for said hub?

Second of all, I would need something to set the code on the calculator, and I'd probably use writeback, unless it would be hard-coded into the program during compilation, like the normal passcode currently is.

Thirdly, is there a way I can use some kind of ID during the unlock? I wouldn't imagine this being very popular, but if multiple people have the same password, and one types the code they both use, without this feature, both would unlock, if I'm correct.

Finally (I think), I would need something to wait for a code from the internet in the program.

Does anybody have any thoughts about this, or hopefully, some pseudo-code? I understand that it would be a quite useless feature, but I think it would be cool nonetheless.

You can use the calc's ID as it should be unique enough... Look here for getting it.

1) No 8-char max on virtual hub names, since they're entirely a function of gCn (which is transparent to the connected calculators).

2) AHelper's method is basically what CALCnet does, and as you've discovered, if Cn2_Setup has been called, the ID is stored in RAM for you.

It's time for this topic to come out of hibernation, and I'm going to try my best to stick to it. So, I'm trying to make a tool to work with the Vigenère cipher. I'm going to use the DCS GUI routines for input, and for the ciphering routines, I think I'm going to use a table of values as such:

Code:

If I can find an value for each letter (0-25) in the key, I could go to ({VigenereTable}+([Offset of 0 to 25]*27)) and add the value of the string's letter to get the ciphertext for the letter. (Would it be possible to overwrite the data for a GUIRTextMultiline element (I'm using two for input: one for the plaintext string and one for the key; I would write back to the plaintext string)'s string by doing ld hl,PointerToTextMultilineData \ ld reg16,6 \ add hl,reg16 \ ld (hl),[ASCII Character]? If so, I would have the perfect amount of bytes to write back to.)

Regardless of that, my other, more important, issue arises when I try to use this method of getting letter values (pseudocode-ish):

(A loop mechanism will help account for offsets and the two commands under SomewhereInCode will repeat until it finds the zero terminating the string)

Code:

Those who work with z80 assembly likely know that ld and cp don't like indirect access (Well... for ld, only if it acts as the second argument, which I would need it to). This is where I am having issues, though the "pseudo-psuedocode" may have other issues. How could I work around the indirect access problem? Also, is there a significantly better method than using an array?

It looks to me as if you could do that entire table with the alphabet only once, not 26 (or 25) times. Why not do ({VigenereTableA}+[([Offset of 0 to 25]+[letter_number-1]) mod 26])?

It's about time to post a follow-up, isn't it? Kerm, that is a good idea. I'm thinking of adding the key and plaintext values together, and if the result is ≥26, I'll subtract 26 to get the ciphertext. It will never be more than 50, so I don't need to worry about an entire modular arithmetic solution. As for the ld instructions, I realized I derped and that I can only use indirection with load if the value is being stored to register a. I'm trying to think of a good way to convert the ASCII to characters. I would like to allow for all characters DCS will happily use with GUIRTextMultiline, but to ignore all but letters in the actual conversion. The key would only be used for alphabetic characters, so if other characters exist between the alphabetic ones in the plaintext, the key will continue from its stopping point. (Example: "foo@bar.com" with the key "MJUR" would yield "rxi@sma.wfy". The text "foo" gets MJU, "@" is ignored, "bar" gets "RMJ", "." is ignored, and "com" gets "URM".) I'd also like to allow for case-sensitivity for the plaintext. (Example: One could type "Kerm !s Aw3some" and encipher it with the key "AOM" and the tool would yield "KsDM !g Mw3gams")

Could anybody assist me in coming up with good routines to convert the ASCII values to values usable in the Vigenère cipher?

What I have so far is at http://pastebin.com/RKZ4ruHh.

I also am trying to figure out what is wrong with my ExpandKey section. Any assistance here would be useful.