ThomH

I'm not in the slightest bit confident about this, but assuming the big numbers posted are big endian, I wrote the following quick program on top of the arbitrary-precision arithmetic support in OpenSSL (whichever version came with Mac OS X v10.6): #include <stdlib.h> #include <openssl/bn.h> #define BIGNUM_BIGENDIAN #ifdef BIGNUM_BIGENDIAN BIGNUM *load_number(unsigned char *buffer, int numbytes) { BIGNUM *r1 = BN_new(); BIGNUM *r2 = BN_new(); while(numbytes--) { BN_lshift(r2, r1, ; BN_add_word(r2, *buffer); buffer++; BIGNUM *t = r1; r1 = r2; r2 = t; } BN_free(r2); return r1; } void print_number(BIGNUM *number) { BIGNUM *printCopy = BN_new(), *pc2 = BN_new(); BN_copy(printCopy, number); unsigned char *tempBuffer; tempBuffer = (unsigned char *)calloc(BN_num_bytes(number), 1); int arrayPointer = BN_num_bytes(printCopy)-1; while(!BN_is_zero(printCopy)) { tempBuffer[arrayPointer] = BN_mod_word(printCopy, 256); arrayPointer--; BN_rshift(pc2, printCopy, ; BIGNUM *t = pc2; pc2 = printCopy; printCopy = t; } BN_free(printCopy); BN_free(pc2); for(int c = 0; c < BN_num_bytes(number); c++) { printf("%02x, ", tempBuffer[c]); } printf("\n\n"); free(tempBuffer); } #endif int main (int argc, const char * argv[]) { static unsigned char keyfile_1[] = { 0xea, 0x6c, 0xad, 0xb2, 0xab, 0xb1, 0xd3, 0xee, 0x85, 0x6f, 0xd3, 0x36, 0xc0, 0xc1, 0x16, 0x1d, 0x31, 0x44, 0x65, 0x1a, 0x22, 0x81, 0xb5, 0xb8, 0x26, 0xdd, 0xce, 0x0f, 0x8f, 0xbb, 0x25, 0xc8, 0x1d, 0x34, 0x03, 0x1f, 0xb4, 0xb9, 0xae, 0xda, 0xcf, 0xde, 0x75, 0xc1, 0xd2, 0xed, 0x35, 0x4b, 0xcc, 0x11, 0x58 }; static unsigned char keyfile_2[] = { 0x14, 0xd6, 0x30, 0x08, 0x35, 0x57, 0x28, 0xef, 0x2b, 0xa3, 0x25, 0xb7, 0x11, 0x8c, 0x62, 0x2d, 0x16, 0x7a, 0x7d, 0xee, 0x57, 0xe7, 0x37, 0x18, 0xc9, 0x96, 0xe5, 0xa9, 0x63, 0x49, 0x68, 0x15, 0xf6, 0x6c, 0x12, 0x8c, 0x9e, 0xeb, 0xda, 0xef, 0xbd, 0x75, 0x3a, 0x9e, 0x7d, 0x02, 0xe6, 0xe9, 0xfd, 0xd7, 0x97 }; static unsigned char keyfile_3[] = { 0xdd, 0x74, 0xf0, 0xb7, 0xee, 0xe2, 0x6b, 0x6d, 0xb7, 0x75, 0xcc, 0xca, 0x1d, 0x65, 0xdc, 0xd4, 0x35, 0xe2, 0x09, 0xd0, 0x18, 0x46, 0x9b, 0xf5, 0x96, 0xcc, 0x80, 0xfa, 0x44, 0xea, 0xee, 0x0e, 0x23, 0xbb, 0x36, 0xfe, 0x68, 0x22, 0xbf, 0xb5, 0x53, 0x7d, 0xf2, 0xfb, 0x86, 0x82, 0x94, 0x13, 0xd4, 0x24, 0x6c }; BIGNUM *keyFile1, *keyFile2, *keyFile3, *result; keyFile1 = load_number(keyfile_1, 51); keyFile2 = load_number(keyfile_2, 51); keyFile3 = load_number(keyfile_3, 51); BN_CTX *ctx = BN_CTX_new(); result = BN_new(); BN_mod_exp(result, keyFile1, keyFile2, keyFile3, ctx); printf("Result is:\n"); print_number(result); BN_free(result); BN_free(keyFile1); BN_free(keyFile2); BN_free(keyFile3); BN_CTX_free(ctx); return 0; } I've never used OpenSSL before and couldn't find a definitive reference on the intended usage patterns for BIGNUMs, hence the slightly awkward means of byte stuffing and retrieval — though if you insert something like a print_number(keyFile1) then you get exactly the same byte pattern back as you put in, so I'm confident they're correct. Anyway, output is: 90, 53, a4, ab, bd, 77, c6, b3, c6, 58, 5a, 41, 2d, d9, ce, 60, 47, 10, e3, 66, ab, 6b, 90, d8, 1e, ce, 3c, 05, de, 7b, 4f, 9f, 03, b7, 75, 12, 83, 2f, bd, 93, 81, 39, 1a, 41, 50, 34, b5, f8, 9c, 51, dc, Obviously this will be completely incorrect if the 51 byte numbers given are intended to be little endian, in which case you'll need to modify load_number and print_number. Or just reverse the order of the numbers in the arrays then reverse the order of the numbers in the output. Hope I've understood!

Well, it was intended to be a semi-remake of an existing Acorn BBC/Electron game called Starship Command. So you can see a sort of slower version of what I was thinking of in this video (not one of my own): http://www.youtube.com/watch?v=jr0DKvInRyI And I think it was 2001/2002 that I was last around, so it isn't surprising given my usual inability to finish anything that my stuff was forgotten so easily. It's not so impressive (kind of low precision, could be improved), but see here: http://www.youtube.com/watch?v=sVcbyWj3V5k Key "cleverness": Suzy's multiply-with-accumulate is used to calculate the next pixel to fetch simultaneously with the CPU fetching the previous pixel, individual scanlines are assembled in right-to-left order on the stack page because the stack pointer can write a byte and auto-decrement, then the unified memory model is used to blit and stretch the line (this is where some of the lack of precision creeps in — I don't offset the lines left or right according to subpixel accuracy, though it wouldn't cost much to do, being a cheap operation performed only per-scanline) to the correct place on the display. The display is in principle full resolution (ie, it isn't 80x102 or 80x51 or anything like that). As I recall, the response at the time was generally just "it's a nice demo effect, you couldn't use it in a game", which isn't true but was sufficiently disheartening. Poor old me, etc. The weird messy area is because there is no bounds check on fetched pixels, the entire 64kb memory space is used. That'd be fairly easy to fix, but might add a little to the display cost. I originally intended just to mask it out again. I should look into whether the 65sc02 has any of the unofficial 6502 opcodes, especially SAX, as that could kill that stuff for zero extra cost. Though I no longer have the source, so even if it has SAX it isn't like I can suddenly turn up with a fixed version tomorrow... To play with it yourself, grab the binary from my web page (though it's the only Lynx thing currently on there) — direct link is here (~6.5 kb). My email address is on that page in a probably-doesn't-help-much encoded format which your Javascript interpreter will decode for you. That's in case these forums don't allow private emails, and I wouldn't know. No idea what I'll work on if I get back into the Lynx. I just won the Lynx I was bidding on over on eBay, so that's the first hurdle crossed. I'll obviously PM Lynxman as instructed to discuss his product further, will look forward to receiving the manual.

Well, ummm, I don't want to derail the thread with stuff about me. My interest has been re-piqued because I've ended up working on 6502-stuff for another reason (more small hobbyist stuff, nothing interesting), and subsequently found this thread. I still have the source for Command: Starship (actually, so does everybody) and Navigator (ditto, though the stuff in Stardreamer has had some subequent fixes), though I think my Mode 7 is lost to history but for the binary. And, now, the video of the binary that I recently uploaded to youtube. Would almost certainly get back into it if this cartridge is usable on a Mac, and I'm happy to write my own Mac-side stuff if the USB is something odd but at least documented. Still being me, I'm still unlikely to ever actually finish anything significant.

What software do you need on the computer to push information to the flash card? I was a Lynx hobbyist developer a long time ago (ummm, I did a Mode 7 demo that I thought was a clever subversion of the stack pointer and the multiply-with-accumulate, though nobody else much cared, and also the 3d stuff which ended up in Stardreamer) and found this thread by chance today. I've been on OS X for years, which precluded me from the older DOS utility and serial port cart. Would I be able to use this one? Might respark my interest...