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 - tangrs
Pages: 1 ... 12 13 [14] 15 16
196
« on: April 02, 2012, 12:19:10 am »
Good job tangrs. You may want to create a new topic for the bFLT loader and leave this for you standalone relocator.
Also I know this is going to sound newbish but what exactly do things like bFLT and relocators let you do?
There's a detailed explanation if you look in the README for the ELF loader ( https://github.com/tangrs/ndless-elfloader/blob/master/README.md). But simply speaking, not everything is adjusted correctly when you load an ordinary Ndless binary - some bits get left behind and contain incorrect values. There are Ndless functions to help solve this but they are manual methods. By using one of these loaders, it simply patches up whatever remained automatically. @edit: bFLT discussion now moved to http://ourl.ca/15736
197
« on: April 01, 2012, 08:35:20 pm »
198
« on: April 01, 2012, 07:34:19 am »
Would it be easier just to write a bFLT loader from scratch? I don't know.
Most likely, this will be abandoned at one point for bFLT anyway Maybe, but for this to happen, other people than ExtendeD or I need to work on the task 
Neither ExtendeD nor I have enough time to move bFLT forward at the required rate.
I looked at the specifications for bFLT and it's insanely simple. It's not worth trying to port a loader. I spent a few hours today and wrote a basic bFLT loader from scratch. It's really a trivial task compared to ELF loading. Spend a little extra time on it and dynamic libraries should be easily supported too. I put up the source code on Github ( https://github.com/tangrs/ndless-bflt-loader) with a README with all the information needed to get the loader and a elf2flt toolchain working. Please tell me if this is okay to use. @edit: if there's a place with comprehensive documentation about the structure of bFLT files, please do tell me. Most of the 'documentation' I've read are header files and comments in code of existing implementations.
199
« on: March 31, 2012, 07:33:28 pm »
@edit2
If you could send me the ELF file you're trying to link, I can take a look at it for you.
Here it is, I'm just trying to troubleshoot this: http://ourl.ca/14975/294135
That's really weird, it works perfectly on my machine. I added some extra debugging lines into the latest commit. Could you check it out and recompile and see where it conks out?
200
« on: March 31, 2012, 07:20:24 pm »
Wow, great work here! I'm looking forward to seeing this I've also been trying to get USB OTG working except I've had no success 
201
« on: March 31, 2012, 08:05:53 am »
FWIW, I had started to look at porting a bFLT loader to the Nspire platform: http://ourl.ca/14975/284471 . bFLT is simple, can easily be converted from ELF, and does the job we need, AFAICT. It can handle dynamic libraries, too.
But as I mentioned in that topic, I can't handle the port alone 
Would it be easier just to write a bFLT loader from scratch? edit: From a brief look, a bFLT loader looks easy to write - I'll have a crack at it tomorrow For the ELF loader, I did try to port libelf to the calculator at one point but gave up and ended up just writing the whole thing from scratch. [edit]
One thing I would like to be improved: the relocator currently replaces Ndless's crt0.S. Which means any startup feature non-related to relocation (such as __crt0_savedsp's initialization) will be lost when switching to ndless-standalone-relocator. What could be done to keep Ndless's crt0.S, and use startup.S as the program entry point?
Looking closer: is crt0.s actually kept, and startup.S added before it?
[edit2]
I'm trying to use it on my Windows computer, but I'm always getting the error:
makeself.exe: Unable to parse ELF file "testlibm.elf".
I'm using libelf v0.8.13 and GNU v2.21. How can we diagnose this?
I only finished writing it today so I haven't had time to extensively test it. It does pass the unit tests though. One thing that did require a hacky fix was for the __got_size symbol. The linker saw that symbol as an address to something and adds it to the relocation list. Of course we know it's not an address and attempting to 'fix' it will cause a lot of problems. The temporary fix I used was just to blacklist that offset but obviously, that's no long term solution. Most likely, this will be abandoned at one point for bFLT anyway @edit1 Yep, startup.S is simply tacked onto the executable. The memory region looks like this: P R G \0 [ branch instruction ] [number of relocation entries ] [relocation code ] (startup.S finishes here) [array of relocations ] [ original tns file ] @edit2 If you could send me the ELF file you're trying to link, I can take a look at it for you.
202
« on: March 31, 2012, 12:18:23 am »
I had another thought on how to tackle the problem of relocation and instead of loading ELF files, I made the programs relocate at runtime. See this topic for more details: http://ourl.ca/15714This new way of loading will (naturally) solve the issue of massive ELF files.
203
« on: March 31, 2012, 12:16:28 am »
As I was using Ndless-Elfloader for one of my projects, I realized a problem. I spent more time working out problems in the ELF loader than actually working on my problem. The ELF loader was clunky and wouldn't work on the newer OS's and it was a huge problem to maintain. That aside, prototyping a program to work using it just took way too long. I started developing a new, lighter loader similar to Ndless's binary loader to use in my projects. It's in it's early stages right now and probably useless to most people but I have included the source in case any developers are interested in using it. Read up the README for more information, advantages and disadvantages. Source code
204
« on: March 30, 2012, 09:19:42 pm »
Nice
You may be interested by Ndless's new builtin function nl_set_resident() (on the SVN trunk, to yet upload as a release): http://hackspire.unsads.com/wiki/index.php/Ndless_features_and_limitations#Resident_programs
I'm planning to extend the support for hooks by Ndless, any ideas are welcome. It would include:
- Hook installation detection (something similar to your is_already_hooked())
- Standard hook points, to avoid programs having to include themselves the hook adresses (switch on/switch off would be one of them)
- Multiple hooks at this point
- Hook uninstallation
Thanks. I did have a look at it but it seems that the calculator crashes when it is called. Otherwise, I'm very pleased to see a lot of new features in the newer Ndless releases! On the hook points, I'm curious as to your method to finding hook addresses. My method was to create a custom emulator that enters debug mode when a certain register is written to (i.e. to turn off the screen), make a memory dump and backtrace it using IDA. It is hard to tell however, where is the best place to install the hook - most of it comes down to trial and error. Do you have a better way? This is in C, right? How did you edit memory values to add the hook?
The source code is included if you want to poke around with it. However, I believe the hooking macros are all defined in common.h in the Ndless SDK. You can check out a copy of Ndless source code and look how it's implemented.
205
« on: March 30, 2012, 07:06:13 am »
I don't think a clock program had ever been made for the nspire. Had 3hrs of spare time today and made a simple one.  Source code and ReadmeBinary is attached
206
« on: March 25, 2012, 04:12:39 am »
While making the movie player, I had realised one problem and that was that the frames could not decode fast enough. So I decided that multithreading was needed so it could continue to decode frames in the background while occasionally waking up to update the screen. Of course, Ndless provides no such features. You have to write it yourself! So, without further ado, I present to you a proof-of-concept of multithreading on the Nspire calculator. After I refine it a bit, I'll integrate it into the movie player. It's BSD licenced so feel free to take it, hack it, modify it, improve it, use it in your own projects or rip it to shreds. Source code
207
« on: March 17, 2012, 05:21:10 am »
Sorry for the lack of updates, I've been busy in the past week So basically, here's an update on the situation so far: The movie player work but it lags... Like a lot. There's two ways out - optimize the compression routines or decode ahead of time somehow and cache the frames. Both ways, it'll take some time. I'm looking into both options right now. When we get that sorted, we can start working on stuff like fast forward and rewinding. The other thing on the TODO list is support for the older calculators. This might come a bit later though seeing as I don't have an old Nspire to test with and the emulator image is lost somewhere on my hard drive. Basically, top priority right now is optimizing the damn thing. Sound 'may' be a possibility through the serial port but given how annoying it is to make a dock connector, I doubt it will be feasible any time soon. Oh and about the video converting thing, I'll look into a way to make that easier. I'm a Mac/*nix user so most of the instructions were for *nix users.
208
« on: March 10, 2012, 04:06:17 am »
New version.
Esc key ends movie instead of '5' and movie rewind issue fixed. Also included a binary version of moviecompile for Windows.
209
« on: March 09, 2012, 05:57:29 pm »
A very early version is ready for use!
Yay ! Thanks 
However, my calc crashed 
I sent the player, the test video you included and a new ndless.cfg.tns (so it works with file associations) then ran the video. The calc played the video then shut down, and no key responded, except the reset one
edit: also, the quitting key is not that obvious
edit: also, not everybody has a working Ndless SDK  . Wouldn't it be possible to have another way to convert videos ?
Haha, like I said, it's a very early version. Which calc did you run it on? I have yet to test it on classics. Yep, more polish coming up! I'll change the quitting key on the next release. You don't need the Ndless SDK to convert videos, you just need a working C compiler to compile the helper program. I understand not everyone has one installed on their system though so I'll try to compile the helper program for Windows and release a binary.
210
« on: March 09, 2012, 04:58:36 am »
It's very doable but you're going to have to do quite a lot of the leg work yourself. I would be looking into Ndless's startup hook and start by modifying that to create a custom Ndless with password protection. The password could simply be stored in a plain text file - possibly away from the documents folder so it can't be easily replaced. If I had the time, I would write it myself
Pages: 1 ... 12 13 [14] 15 16
|
Show Posts