This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - BrandonW
Pages: 1 ... 3 4 [5] 6 7 8
61
« on: July 21, 2010, 11:27:13 pm »
They want the keys so that they can sign their own boot2 and OS updates, so that they can create their own operating systems instead of using TI's very locked-down ones. In order to do that, they need the RSA factors of the public keys used for validation of said boot2 and OS areas. The calculator only decrypts, never encrypts. Such an attack wouldn't help.
The only way to get by this is to factor the RSA public keys, which will take a very, very, very long time.
62
« on: July 19, 2010, 11:07:38 pm »
You do not need to install Free83P, ever. Despite what you may have heard, it's a normal OS just like any other.
Use TI Connect's dedicated OS installer, an application called TI OSDownloader. It's easier to install if you already have an OS installed and you're at the homescreen, and initiate the transfer from the PC.
Is this serial I/O or direct USB?
63
« on: July 14, 2010, 07:14:30 pm »
It's illegal and TI monitors this and other forums, so we couldn't post a response with where to find such a thing. There was a time where you could e-mail them and ask for the earlier version and they would send it to you, but I think they may have stopped that. It's worth a shot, at [email protected]. Once you get the upgrade, yes, of course, you can switch to any OS version you want. It doesn't prevent you from downgrading like the TI-Nspire does.
64
« on: July 06, 2010, 06:05:28 pm »
Ok, new idea, maybe I can make a group variable in ram and then archive it. That would be much simpler, I just have to figure out how groups work. It is also so anti-TI to have a group in ram.
While it defeats the purpose of having groups (you'd just be duplicating the RAM variables in RAM), you absolutely could have done this using _archiveVar. That's a subroutine of _Arc_Unarc, the latter which has all the checks to make sure you don't try archiving a group or something.
65
« on: July 06, 2010, 02:02:47 am »
I wrote Windows for the TI-81.
66
« on: July 04, 2010, 11:41:14 pm »
I was the one that wrote GroupTool, many years ago. It's poorly coded and if I had the time, I'd rewrite it. It probably sets or resets that lowercase flag without regard to whatever it was before launching it.
Groups are complicated to explain (it's also been a really long time since I looked at them). If I remember correctly, they're a series of VAT entries and variable data, one after the other. You'd just have to pick one apart and look at it in a hex editor.
67
« on: June 27, 2010, 02:22:06 pm »
so, i took your advice, and watched the file handle. I HIGHLY doubt that it's coincidence that the garbage data comes in on the very frame at which the seek pointer carries to the second byte. Also, the 'type' of garbage changes at every carry.
I didn't catch that you said this was happening. That certainly sounds like a usb8x bug...I'll look into it. Perhaps as a temporary workaround, you could change the seek pointer yourself (I can't remember how simple or complex DOS_fileSeek actually is).
68
« on: June 27, 2010, 11:50:36 am »
Not rewriting usb8x, just the mass storage driver (the part I wrote).
Why doesn't your code have $BB, $6D at the start? Nothing else jumps out at me at first glance.
EDIT: MSD_CacheOn attempts to enable sector read caching so that if you try to read the same sector more than once, it won't go to the drive first. If I remember correctly, this uses the extra RAM pages, so it should probably be revisited because of the newer 84+/SEs.
A working demo of Blue8x is mostly dependent on the usb8x update.
You might want to try reading 512 bytes at a time instead just to see if you get the right data. There could be some issue with reading 768 bytes at a time, but it's sounding more like there's memory corruption going on. You might also want to display the contents of the file handle memory both before and after each call, pausing for a keypress each time, and see if it goes wonky while in the call to DOS_fileRead.
69
« on: June 26, 2010, 08:45:00 pm »
I point to you, because msd8x can read and write large variables for myself and many others.
Programs have also been written (not publicly released) that stream video from a flash drive, which it seems like that's what you're doing. They read 512 bytes at a time, which is the size of one sector, and it means the driver doesn't have to span sectors to read a chunk of data.
You might want to post a little more of your code, specifically setting up usb8x itself and where all the equates are.
usb8x can be quirky from an assembly program (versus a Flash application)...perhaps there's some assumption the driver(s) are making that doesn't work in your situation.
70
« on: June 26, 2010, 08:16:28 pm »
"FAT" in Windows is actually FAT16 (or it could be FAT12, Microsoft doesn't distinguish). FAT32 is FAT32.
71
« on: June 26, 2010, 08:14:21 pm »
SirCmpwn: did 8 minutes kill you? well, let's get back on topic, shall we?
Brandon, I've relocated the file handle (and the USBDriverCall and the USBDriverBuf each) to some (isolated) memory inside the program where it couldn't possibly be corrupted accidentally, nor could they corrupt each other, but the same thing happened. Exact same garbage and everything, so I know it's not that.
Am I missing some error checking?
Is there a safe limit on the maximum number of bytes read at once?
(oh, yes, side note, FAT32 would be helpful because WINDOWS DOESN'T LET YOU PARTITION REMOVABLE MEDIA!)
I think Windows actually will let you, it's just that all but the first partition will be inaccessible. I'm really not at all sure what happens with usb8x if you place a FAT16 primary partition at the very end of the drive. I attempted to hack in FAT32 support long ago but failed. It would require a from-scratch rewrite of all the code, which probably needs to happen anyway. Yep, so we can mess around with Blue8x, like I've asked for several times 
I don't remember you asking for that, but yeah, that's the main priority for getting an update out.
72
« on: June 26, 2010, 07:34:23 pm »
It's sheer luck that it works on your newer 84+.
When I find the time, I'll rework it to not use the extra RAM pages.
usb8x itself is also long overdue for an update.
73
« on: June 26, 2010, 07:30:08 pm »
msd8x is just an interface to the MSD driver in usb8x. The MSD driver is only in usb8x. There was a time when the driver was in msd8x itself, but it has since been shifted and integrated into usb8x itself.
So msd8x is just the interface (and it uses the extra RAM pages, which is why it doesn't work on newer 84+/SEs -- the MSD driver itself still works on those models).
As far as what you're seeing, I would check and make sure you're not using the same area of memory more than once (using more of statVars than you should be, for example -- 531 bytes). I've driven myself insane more times than I can count because of strange memory corruption issues because of things like that.
74
« on: June 09, 2010, 11:32:23 pm »
Yes, but I'm not sure how well that would work with the rest of the xLIB code. Using the BCALL, as you know, is a lot slower -- maybe too slow. It's certainly worth a shot, it just may be a little more involved.
75
« on: June 09, 2010, 11:28:24 pm »
It's not exactly impossible to modify xLIB to do this. Just because the source isn't available doesn't mean it can't be disassembled and patched, much like the TI-OS itself. I think it would be relatively trivial to modify a Flash application to include this extra delay, but then again I haven't looked at an xLIB disassembly in quite some time.
Pages: 1 ... 3 4 [5] 6 7 8
|
Show Posts