Join us on Discord!
You can help CodeWalrus stay online by donating here.
Menu

Show posts

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.

Show posts Menu

Messages - nspiredev500

#1
While programming for my Nspire CX CAS CR4 I thought that either my calculator is weird, or the documented timer frequency for the watchdog timer isn't right.
I also found out you can set the frequency of the other timers.
But right now, this is only tested in my calculator.
To help, you only need a Nspire CX and a stopwatch.
I compiled a version of my project to test the timers and print out the result.
You just have to follow the instructions on the screen and post the values.

Instructions:
Make sure you don't need the contents of the scratchpad and saved the opened document, as you can only exit the test by using the reset button at the back.
Copy the charset.tns and the timertest file for your hardware revision to your documents folder.
The hardware revision is the letters on the top-right of the back of your calculator.
First is a series of 10 flashes of red, green and blue with (what should be) one second of delay between them.
You have to record the time between the flashes and post them (or just take the average time like I did).
Then you just have to write down an post the values it shows on the screen.

Thanks in advance

My results are:
msleep: 1.002 seconds between the flashes on average
initial clockselect: 0
timer: 33031944
timer+clockselect=0xa: 31958
timer+clockselect=0x9: 11704931
#2
Do you think the performance difference between the Numworks and the TI-Nspire lies in the software or in the hardware?
If it's in the software, I looked at the Numworks firmware and they internally use an hardware abstraction layer.
So you would only need to implement that abstraction layer on the Nspire platform.
Or if they have a better Python interpreter, you could just take it out and adapt it for the Nspire.

I'm amazed at what the people at Numworks managed to cram into the tiny Flash and RAM.
The RAM is literaly only twice the size the Nspire uses for a single thread stack (after Ndless expands it), and in the Numworks all the data lives in that, including the Python heap.
But I don't know if the firmware is executed directly from Flash or from RAM, that would save much space in RAM.
If I had the money to do it and not had a calculator, I would buy a Numworks calculator.
But I already have my TI-Nspire CX CAS I had to buy for school, and I don't need two.
For now I just try to make the most of the one I had to buy.

About the TI-83 and 84, the Nspire had no assembly support since the beginning, and Ndless came to add it.
I think the community rage is big enough for some people to start a similar project for those calculator models, if it is only to rebell against TI.
But that will take time, in which people who have to buy calculators with the new OS version are out of luck.
Or a miracle happens and TI listens to the community.
#3
Just a small Hotfix release, now OSExt works with the Ndless feature for running programs from HW<W on HW-W+.
I forgot about that, and it crashed when trying to run these programs when OSExt is installed.
#4
Quote from: lights0123 on June 10, 2020, 03:40:02 PM
Quote from: nspiredev500 on June 10, 2020, 01:58:34 PMNucleus writes "initializing POSIX layer" on the uart sometime during boot I think, so it should have the fcntl syscall.
The problem is to know which system call number it has and what arguments it takes.
You could assume normal linux arguments and just fuzz all the system calls in firebird until it works.
Any suggestions on how to do that?
You could compile a program that tries to call each syscall number with the specified arguments, and check if it crashes.
I don't know if there is a nspire emulator that can be controlled via console options and gives the UART output on the console, but then it could be optimised.
Here is a list of emulators. You could make a script that compiles the program with a syscall number, opens the emulator, checks the output and builds the program with the next system call number.
This is basically the last option you could use if you absolutely need a specific system call.
I think you could better make small blocking I/O calls and check the time between them.
Quote from: lights0123 on June 10, 2020, 03:40:02 PMI could switch to your timer syscalls if you provide a way to detect it. I'd still like to get the raw ticks if possible, for the nice 30 μs precision. I don't know how much overhead there is in a syscall--would it be worth it replicating vsyscall or vDSO since you apparently already have separate userspace memory?
System calls are basically just C functions called by an index in a table. You just have some memory accesses to get the number and save some state, run the function, and then return. There should not be much overhead.
I technically have userspace memory, but nSLD and libndless are hardwired for supervisor mode, as the whole OS runs like that.
Before proper userspace I have to implement at least a simple scheduler, mmap and I/O syscalls. Running Rust (which should already be pretty safe) in usermode isn't worth the overhead and modifications to the libraries.
Detecting OSExt is easy, I use this in OSExt itself to detect if another version is already installed:
register uint32_t control_reg asm("r0");
asm volatile("mrc p15, 0, r0, c1, c0, 0":"=r" (control_reg)::); // reading co-processor register 1
if ((control_reg & (1 << 13)) == (1 << 13)) // if bit 13 is a 1, interrupt vectors are mapped high. I don't think anything other than OSExt does this
{
 register uint32_t tt_base asm("r0");
 asm volatile("mrc p15, 0, r0, c2, c0, 0":"=r" (tt_base)); // get the translation table base register
 
 tt_base = tt_base & (~ 0x3ff); // discard the first 14 bits, because they don't matter
 uint32_t *tt = (uint32_t*) tt_base;
 if (tt[(0xe0000000) >> 20] != 0) // if there is something mapped at virtual address 0xe0000000 it should be OSExt, I haven't seen any other program map memory like that
 {
 // OSExt is installed
 }
}
It should be very unlikely that anything else maps the exception vectors high and maps something at 0xe0000000, so this should be reliable.
You can make a variable like bool osext_installed and only do the check once.

I already have a UNIX millisecond function to get the time. I use int64_t for my millisecond time.
I can also use the watchdog timer for sleeping, it has a frequency of 33 MHZ, if you need more precision.
I could write functions to handle sleeping for longer times than the timer.
So you only need getting the time and sleeping?

By the way, in your timer code I noticed the threads only support sleeping, because threads aren't supported by ndless.
I already thought about kernel threads and a separate kernel scheduler.
If you want I can work on thread syscalls.

EDIT: I now have working microsleep and microsecond unix time.
You can specify what functionality you need and I can wrap it in a syscall.
Do you know how to call specific syscalls or do you use the wrappers ndless provides?
I know how to do it in C with inline assembly. It seems Rust supports GCC-style inline assembly, so that's good.
Is there a way to formally specify and API?
Maybe we should move this to a github issue or a separate thread.
#5
Quote from: lights0123 on June 09, 2020, 01:45:42 AMBasically, I'm trying to figure out how you're going to make a faster file browser, as I'd assume that it's I/O bound and you can't really speed it up.
I don't think it's I/O bound, basically it only needs to iterate over the directory entries and stat them.
It should not take that long to do, even on the calculator.
I think it gets slower to open the more files you have (and i have quite a few), even if they are in directories that aren't open. (or that's just my perception, I don't want to delete all my files right now)
It also doesn't cache that information, and reloads every time you open the file explorer.
That is some room for improvement.
I ran a quick test on my calculator, just iterating over the documents folder and stating everything, took only a fraction of a second. I don't know why the document browser takes so long.
Maybe it actually reads the files until EOF to get the size?

Also I'm working on USB support by writing an EHCI driver, writing the device drivers on linux with libusb to test them and then port them to my project.
If I get USB mass storage drivers to work, I can actually do async file I/O. But that will take some time.

Quote from: lights0123 on June 09, 2020, 01:45:42 AMI've written Rust bindings to ndless
That's cool, I thought about using Rust myself, and I even saw your project on github. My first memory manager didn't work, and I thought Rust could help with that. I ended up just doing a rewrite and it seems to work now, but for other things Rust could still be helpful. But I don't know enough about Cargo to do what I need. Maybe you can help me. I would need to compile the code like with GCC's -fPIC or -fPIE flag. It has to use the global offset table and link into my ELF file.
The global offset table is important, because it self-relocates to a higher base address, and will be mapped like this into every address space created.
I looked at your project now, and it looks great :thumbsup: . In your book you say "Your program will never segfault". Something like this was one of the motivations for my project.
Creating a user-mode wrapper around the OS and the hardware, so no program can crash or brick your calculator.
What timer do you use for your wrapper? I want to remain compatible to as many community projects as possible.
I use the first timer for my millisecond UNIX time, because the OS doesn't use it. If your Rust wrapper also uses the first timer, both cannot work at the same time.
But I can expose timer functions as syscalls, and detecting OSExt is also easy, so you could just do a runtime check.
I remember right now that I also have to make OSExt compatible with the lcd-compatibility feature of ndless  9_9.

Quote from: lights0123 on June 09, 2020, 01:45:42 AMis there any way to talk to the flash chip directly
Ndless exposes a read_nand and write_nand syscall from Nucleus. But you would have to parse the filesystem youself with the information on Hackspire.
I also tried to read the flash chip directly via memory-mapped IO, but it doesn't work right now and I'm very carefull, because I don't want to brick my calculator.

Quote from: lights0123 on June 09, 2020, 01:45:42 AMthis is done with fcntl and O_NONBLOCK
Nucleus writes "initializing POSIX layer" on the uart sometime during boot I think, so it should have the fcntl syscall.
The problem is to know which system call number it has and what arguments it takes.
You could assume normal linux arguments and just fuzz all the system calls in firebird until it works.
#6
The module system is finished.
The clock is now a module, and the background image support too.
There is also a battery charge module, but for some reason it makes the calculator run quite slow and breaks the OS battery charge indicator  ??? .

The charset and background images now have to be put into /documents/osext, to reduce the clutter in the documents folder.

The modules have to be put in /documents/modules
At start OSExt tries to load all modules it finds, but there is also a module manager.
You can get to the module manager by pressing and holding ctrl and ,  .
It displays the currently loaded modules and the memory they occupy.
You can move the selection up and down by pressing the up and down arrows on the touchpad.
The first selection (empty at the start) is for entering a module name.
If you transferred a module to the calculator or uninstalled it, you can type it's name (without .elf.tns), hit enter and it gets loaded.
When you select a module name and hit pi, the module gets uninstalled.
#7
I can now load ELF files, relocate them and execute them.
For now the execution is in kernel mode, but this enables me to split functionality into modules and search for them at the start, load them and run them.
This should make the startup faster if you don't need all features, and reduce the file size.

I will split the clock and the background image support into modules.
There will also be a battery charge module, as I was unsatisfied with the 25% reading the OS provides you from the beginning.

I also made a small configuration program that gets compiled with your system compiler.
It asks you what value options should have before the kernel gets compiled.
The options are documented in config/option_ descriptions.txt.

With that I also changed the compiler from my own arm-osext-gcc to a standard arm-none-eabi-gcc (like the one that is included with ndless), to make it easier to compile OSExt.
Now you only need the ndless-sdk and an arm-none-eabi toolchain.
Together this should allow you to actually use the configurability, but I will also release the precompiled modules and a few option configurations.
For more obscure combinations you would have to compile it yourself.

I'll make the 3 modules I talked about, make a small release and then get back to getting userspace working.
#8
I am mostly done with my finals now, so I can start working on this project again.
I'm now working on the scheduler and some system calls to let user-mode code read and write files, allocate memory and use the framebuffer.
So soon I should have a graphical "Hello user-mode" working, instead of the firebird debugger showing "usr".
Then I want to make a basic input driver, so I can have a first early userspace console.
#9
I won't be able to work on this for the next 1.5 months, because I have my final exams in this time.
But after that, I have plenty of time.
#10
Now you can actually set the time instead of only seeing it. I made a small time setting screen, but I needed the touchpad for the arrow keys, and the touchpad driver turned out be a bit hard.

Now I will start working on the processes and the scheduler.
#11
Other / Re: What kind of project are you working on?
April 12, 2020, 08:56:49 PM
Quote from: DJ Omnimaga on April 12, 2020, 08:30:53 PMIt's cool to see new TI-Nspire CX projects. TI's constant updates that blocks Ndless have discouraged a lot of developers over the years, but if unlocked for third-party development, the TI-Nspire CX series has a lot of potential.
That is another reason why I eventually decided to try to make a whole OS: the POSIX standard gives a consistent environment to developers.
I want to make my own wayland desktop for the nspire, and with that I could port many other libraries and projects.
One thing that I thought would be nice is to port gcc, so you can develop native applications directly on the calculator.
But the compilation time would probably be a bit long  :P
I hope Ndless for OS 5.x releases before the world has forgotten all the great thing native programs can do with a calculator.
Maybe the newer hardware gets some people to write new programs.
#12
Other / Re: What kind of project are you working on?
April 12, 2020, 08:26:10 PM
I am actually working an a TI-nspire project right now.
Sadly I seem to be a bit late with that, but I only got mine for school 2 years ago and didn't find Ndless right away.
Also going from Java to C was a bit hard.
Since linux doesn't seem to work on my calculator (maybe because it is HW-AA), I want to create a POSIX operating system that can run alongside the OS.
My long-term goal is to get a usb mass storage driver working and then just kick the old OS out to use the rest of the RAM, and still be able to load programs.
Currently I finished my memory allocator (hopefully without any bugs), it can display a miniclock on the screen and change the normal black homescreen with a standard Windows 24bpp bmp.

I also made drivers for the keypad and the timers, the touchpad driver doesn't currently work on the calculator.
Now I need to make a scheduler and start to implement all the POSIX system calls, or at least the ones Newlib uses.
#13
small update: You can name bmp files "background2.bmp" to "background4.bmp" and get a slideshow of your images.
They change every 15 seconds currently.
#14
Quote from: Knucklesfan on April 08, 2020, 11:17:47 PMbut I have an Nspire CX II running fw 5.0 so that might not work.
I want to port it to the CX II, but first I need a new Ndless version to do that.
It will probably be a while until the new version is out.
#15
I always didn't like the plain black background of the nspire homescreen, so I added basic background image support for windows bmp files.
Currently it just looks for black pixels and replaces them with pixels from your image, but it vanishes when a menu is opened, because it would colour the text, too.



You just have to put a file called "background.bmp" (.tns, but you don't see that on the calculator) in the documents folder.
I hope the walrus isn't copyrighted  :)
Powered by EzPortal