CodeWalrus

Featured Member Projects => Completed and Inactive Projects => [Inactive] KnightOS (TI-73/83+/84+/CSE) => Topic started by: Vijfhoek on March 22, 2015, 04:29:22 pm

Title: KnightOS Updates
Post by: Vijfhoek on March 22, 2015, 04:29:22 pm
This post has originally been posted by SirCmpwn on TI-Planet (http://tiplanet.org/forum/viewtopic.php?f=10&t=14349&p=179546#p179546) and has been crossposted with his permission.

Hello again! We haven't posted any updates since November so there is a lot of news for you:


Pretty pictures:

(https://codewalr.us/proxy.php?request=http%3A%2F%2Fa.pomf.se%2Fcitcah.gif&hash=de0eb7ac3e649fc5c31167086a78baa5) (https://codewalr.us/proxy.php?request=http%3A%2F%2Fa.pomf.se%2Fmfrxgl.gif&hash=c157684c5e53aa36a99304ccc45b91de) (https://codewalr.us/proxy.php?request=http%3A%2F%2Fa.pomf.se%2Febmccu.gif&hash=16e7b0344dab2a79ba97535226b45748)

(https://codewalr.us/proxy.php?request=http%3A%2F%2Fa.pomf.se%2Fmcyiau.gif&hash=51792fd6770c9cb87c37e4184fe30207) (https://codewalr.us/proxy.php?request=http%3A%2F%2Fa.pomf.se%2Fqckpug.gif&hash=fc36c1f6527f699e50baffd803ae5cad) (https://codewalr.us/proxy.php?request=http%3A%2F%2Fa.pomf.se%2Frsaelj.gif&hash=1c15deacd1dd80cc75e168d6389e343e)

Quote from: SirCmpwn
This time around, I'm pretty sure most of the work was NOT done by me, which is a first :) Thanks everyone!
Title: Re: KnightOS Updates
Post by: Snektron on March 22, 2015, 04:34:13 pm
Awesome :D
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on March 22, 2015, 05:50:59 pm
Good to see this progressing. I can't wait for the day it will become entirely useable by the public. :)
Title: Re: KnightOS Updates
Post by: CKH4 on March 22, 2015, 06:17:08 pm
Thanks for sharing this. I wouldn't have found it and I'm glad to know that knight os is still progressing.
Title: Re: KnightOS Updates
Post by: Duke "Tape" Eiyeron on March 22, 2015, 06:49:47 pm
This is going way more fine than I would expect! Nice work dudes! I hope Axe will soon be ported to KOS and be able to mess with that! (-_(//));
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 22, 2015, 07:04:02 pm
Juju invited me to create an account here for KnightOS stuff. Hi everyone.
Title: Re: KnightOS Updates
Post by: Snektron on March 22, 2015, 07:06:35 pm
Ello there, and there is an "introduce yourself" thread :P
Title: Re: KnightOS Updates
Post by: Streetwalrus on March 22, 2015, 07:08:43 pm
Oh wow nice, looks like it's really taking shape now from a user's point of view. :D (well, math aside, but who uses that :P)

And hi Sir, you're welcome to post whatever about KOS here. ^.^
Title: Re: KnightOS Updates
Post by: Juju on March 22, 2015, 07:10:03 pm
Welcome here! Nice to see your project is going well.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on March 22, 2015, 09:38:03 pm
This is definitively coming along well. Hopefully you and contributors have the chance to make this come to fruition in the future so the big public can use it. I was contemplating making a subforum for this if matref, street, vijfhoek or sir himself decides to cross post updates, although updates were slow in recent months so I kinda waited then forgot. Good luck in KOS developement!

Now if only the TI-84+CE didn't use a 2048 bit RSA key, I wonder how fast such OS would have been on that new calc...
Title: Re: KnightOS Updates
Post by: Juju on March 22, 2015, 09:45:56 pm
Yep, we have quite a few KnightOS devs here, so a KnightOS subforum can definitely be doable.
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 22, 2015, 10:21:50 pm
I think a subforum would be valuable. If it sees a good amount of use we could adopt it as an official KnightOS thing.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on March 23, 2015, 12:06:39 am
That could work. Of course it doesn't mean CW would be the official home of KnightOS and it doesn't provide extra privileges but notable community projects that have updates being cross-posted over here are eligible for a sub-forum on the board index for extra visibility (or at least whatever visibility CW board index can provide for the time being).
Title: Re: KnightOS Updates
Post by: Duke "Tape" Eiyeron on March 23, 2015, 04:18:29 pm
Oh. do you have any work done to make something like a C compiler or anything-better-than-asm compiler for KOS?

EDIT : after checking once more the screenshots, I find your UI quite useful and helpful. Do you have any technical infos for doing such graphical UI server like that? I could be interrested into doing such a project for FiXos.
Title: Re: KnightOS Updates
Post by: Snektron on March 23, 2015, 04:33:17 pm
They have their own C compiler :)
Title: Re: KnightOS Updates
Post by: Duke "Tape" Eiyeron on March 23, 2015, 04:44:09 pm
Oooh! You got my interest naow.
Title: Re: KnightOS Updates
Post by: Snektron on March 23, 2015, 05:01:07 pm
https://github.com/KnightOS/kcc
i should try it out too... maybe float multiply works here (it fails with SDCC <_<)
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 23, 2015, 05:01:39 pm
Quote from: Duke "Tape" Eiyeron on March 23, 2015, 04:18:29 pm
Oh. do you have any work done to make something like a C compiler or anything-better-than-asm compiler for KOS?

EDIT : after checking once more the screenshots, I find your UI quite useful and helpful. Do you have any technical infos for doing such graphical UI server like that? I could be interrested into doing such a project for FiXos.


We have a C compiler called kcc (https://github.com/KnightOS/kcc) that's forked from SDCC. We also have a traditional assembler/linker called scas (https://github.com/KnightOS/scas) that is ASxxxx compatible and used for compiling C output. C support is experimental and has known problems, but if you'd like to try it you can compile and install both kcc and scas and then use "knightos init --template=c example" to generate an example project.

We don't have a UI server, but we do have shared code for drawing some parts of the UI. You can read through it here (https://github.com/KnightOS/corelib).

EDIT:

Quote from: Cumred_Snektron on March 23, 2015, 05:01:07 pm
https://github.com/KnightOS/kcc
i should try it out too... maybe float multiply works here (it fails with SDCC <_<)


It compiles but I can't promise that it works. We don't have any means of printing floating point numbers so who knows. Here's some code I just wrote:

(edited:)

(https://a.pomf.se/wetjxm.png)
Title: Re: KnightOS Updates
Post by: Duke "Tape" Eiyeron on March 23, 2015, 07:58:52 pm
Noice. I wonder if fixed points are quite efficient on z80. Kristaba once did a small fixed point utility and I keep upsing it almost everywhere. It gave to FXes a signifiant speed boost for usual cases.
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 23, 2015, 08:08:51 pm
Quote from: Duke "Tape" Eiyeron on March 23, 2015, 07:58:52 pm
Noice. I wonder if fixed points are quite efficient on z80. Kristaba once did a small fixed point utility and I keep upsing it almost everywhere. It gave to FXes a signifiant speed boost for usual cases.


Fixed point is just using integers and wavy hands.
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 23, 2015, 10:25:57 pm
Kernel 0.6.7 released

The biggest change of this kernel is the switch to a monospaced font. Your stuff is probably going to look weird.

Features

    New monospaced font
    RTC starts on boot
    getStreamPos function
    clockSupported function
    drawDecA, drawDecHL, drawDecACIX

Bugs Fixed

    getBatteryLevel works
    Closing writable streams no longer trashes registers
    rectAND and rectOR no longer trashes registers
    CSE keyboard driver delay fixed

Download

kernel-headers-0.6.7.pkg (https://github.com/KnightOS/kernel/releases/download/0.6.7/kernel-headers-0.6.7.pkg)
kernel-TI73.rom (https://github.com/KnightOS/kernel/releases/download/0.6.7/kernel-TI73.rom)
kernel-TI83p.rom (https://github.com/KnightOS/kernel/releases/download/0.6.7/kernel-TI83p.rom)
kernel-TI83pSE.rom (https://github.com/KnightOS/kernel/releases/download/0.6.7/kernel-TI83pSE.rom)
kernel-TI84p.rom (https://github.com/KnightOS/kernel/releases/download/0.6.7/kernel-TI84p.rom)
kernel-TI84pSE.rom (https://github.com/KnightOS/kernel/releases/download/0.6.7/kernel-TI84pSE.rom)
kernel-TI84pCSE.rom (https://github.com/KnightOS/kernel/releases/download/0.6.7/kernel-TI84pCSE.rom)

Kernel 0.6.7 on Github (https://github.com/KnightOS/kernel/releases/tag/0.6.7)

Disclaimer

This release, like all other kernel releases, is only relevant to developers. The kernel also will not run on its own, so if you put this in an emulator you won't get much out of it.
Title: Re: KnightOS Updates
Post by: Ephraim Becker on March 23, 2015, 10:38:24 pm
Where are the Upgrade files? I only see the ROM files.
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 23, 2015, 10:39:50 pm
Quote from: Ephraim Becker on March 23, 2015, 10:38:24 pm
Where are the Upgrade files? I only see the ROM files.


You can get a kernel upgrade file by compiling it yourself (except for the CSE), but for now we don't publish precompiled kernel upgrades since you have to reinstall the entire OS so often anyway when you use KnightOS.
Title: Re: KnightOS Updates
Post by: Ephraim Becker on March 23, 2015, 10:44:50 pm
How do I send the ROM file to my calculator if it's not in .8cu?
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 23, 2015, 10:46:01 pm
Quote from: Ephraim Becker on March 23, 2015, 10:44:50 pm
How do I send the ROM file to my calculator if it's not in .8cu?


Just send the latest nightly to your calculator instead. You can get it from here: http://www.knightos.org/download
Title: Re: KnightOS Updates
Post by: Ephraim Becker on March 23, 2015, 10:47:40 pm
It's still on 0.3.0-43 which is the version before 0.6.7
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 23, 2015, 10:48:28 pm
Quote from: Ephraim Becker on March 23, 2015, 10:47:40 pm
It's still on 0.3.0-43 which is the version before 0.6.7


The userspace version is no longer relevant since we changed KnightOS to a rolling release model. The version on the download page is always the latest version.
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 26, 2015, 11:48:53 pm
Thanks to willem3141, fullly functional date/time support has been merged into the kernel. The settings app has been updated to allow you to set the current time/date, and the castle displays it in the upper right corner. There are also syscalls for working with date/time (http://www.knightos.org/documentation/reference/time.html) that are now fully functional.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on March 27, 2015, 04:34:50 am
Good to hear. Will the clock time remain intact even after the calculator crashes? The fact the TI-OS clock resets to 12 AM on every RAM Clear pretty much renders it useless.
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 27, 2015, 01:18:11 pm
Quote from: DJ Omnimaga on March 27, 2015, 04:34:50 am
Good to hear. Will the clock time remain intact even after the calculator crashes? The fact the TI-OS clock resets to 12 AM on every RAM Clear pretty much renders it useless.


The boot code resets the clock, so if you have to resort to a battery pull then you will lose the time. However, KnightOS offers a better way to recover from a crash. If you press ON+R, so long as interrupts are running, it will immediately reboot.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on March 27, 2015, 06:17:08 pm
Ah ok. I wish it was possible to keep the clock intact. Why TI even bothered implementing one under such circumstances is beyond me.
Title: Re: KnightOS Updates
Post by: jamu on March 27, 2015, 06:27:19 pm
Why they didnt also add a clock to the nspire confuses me
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 27, 2015, 07:51:30 pm
Quote from: DJ Omnimaga on March 27, 2015, 06:17:08 pm
Ah ok. I wish it was possible to keep the clock intact. Why TI even bothered implementing one under such circumstances is beyond me.


I'm not sure if the clock resets when the CPU resets, or if the boot code resets it. If the boot code does it, then it should be possible to patch it out of your boot code.
Title: Re: KnightOS Updates
Post by: Streetwalrus on March 27, 2015, 11:12:26 pm
Quote from: SirCmpwn on March 27, 2015, 07:51:30 pm
Quote from: DJ Omnimaga on March 27, 2015, 06:17:08 pm
Ah ok. I wish it was possible to keep the clock intact. Why TI even bothered implementing one under such circumstances is beyond me.


I'm not sure if the clock resets when the CPU resets, or if the boot code resets it. If the boot code does it, then it should be possible to patch it out of your boot code.

Possible but dangerous. Also TI started write-protecting the boot pages in the flash chip itself.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on March 28, 2015, 04:33:53 am
Streetwalrus do you know when they started doing that? There was Boot 1.03 in 2011 that blocked downgrades, but it was easily circumventable by replacing your boot code. But I don't remember hearing nor reading about any further attempt at locking the monochrome Z80 calcs down afterward. IIRC even the CSE didn't have further protection either, but I could be wrong.
Title: Re: KnightOS Updates
Post by: Streetwalrus on March 28, 2015, 11:45:00 am
I don't remember but it's fairly recent. Probably around when the CSE was released. This particular protection is impossible to circumvent without opening the calc and soldering stuff into it (and it' extremely dangerous of course).
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on March 28, 2015, 04:33:48 pm
Ah that might be it. I wonder if that could explain why the CSE in particular cannot be overclocked higher than 15 MHz? I know the SE could, but not the CSE. I will need to check the Cemetech topic again at some point to get a memory refreshing.


That said, maybe KnightOS could just backup the clock every minute? But then the issue is would developers want such thing to happen via interrupts during the execution of their games?
Title: Re: KnightOS Updates
Post by: CKH4 on March 28, 2015, 04:35:29 pm
Someone did over clock the cse to 20 if I'm not mistaken. The resistors ( i think ) on it are tiny though
Title: Re: KnightOS Updates
Post by: Streetwalrus on March 28, 2015, 07:26:13 pm
Quote from: CKH4 on March 28, 2015, 04:35:29 pm
Someone did over clock the cse to 20 if I'm not mistaken. The resistors ( i think ) on it are tiny though
This. It's feasible, just a very painstaking process.
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 30, 2015, 03:22:06 am
Quote from: DJ Omnimaga on March 28, 2015, 04:33:48 pm
That said, maybe KnightOS could just backup the clock every minute? But then the issue is would developers want such thing to happen via interrupts during the execution of their games?


I know of at least one modded calculator out there running a custom KnightOS kernel that clocks it up to 20 MHz.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on March 30, 2015, 03:29:40 am
Oh in that post I meant the clock as in time, not the CPU frequency. My bad.
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 30, 2015, 03:30:59 am
Quote from: DJ Omnimaga on March 30, 2015, 03:29:40 am
Oh in that post I meant the clock as in time, not the CPU frequency. My bad.


Sounds like a good way to thrash Flash. I don't think it's feasible.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on March 30, 2015, 03:32:16 am
Ah right, forget about the idea then.

In other words, the TI-84 Plus time clock is completely useless except in games that records play time.
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 30, 2015, 03:33:16 am
Quote from: DJ Omnimaga on March 30, 2015, 03:32:16 am
Ah right, forget about the idea then.

In other words, the TI-84 Plus time clock is completely useless except in games that records play time.


Well, KnightOS includes code for doing date/time math regardless of whether or not the clock is present (i.e. convert timestamps to a date/time struct), so there is some usefulness there.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on March 30, 2015, 03:35:59 am
Yeah, I meant due to the fact it keeps getting reset to factory settings, though, unless I am missing or misunderstanding something.
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 30, 2015, 03:36:42 am
Quote from: DJ Omnimaga on March 30, 2015, 03:35:59 am
Yeah, I meant due to the fact it keeps getting reset to factory settings, though, unless I am missing or misunderstanding something.


You're right that it's useless for keeping track of the time if you have a lot of crashes.
Title: Re: KnightOS Updates
Post by: CKH4 on March 30, 2015, 01:39:00 pm
You could probably add the backup clock code to the calculator off code. It'd only back up the clock when you turned it off and on the ram reset it would restore the last clock time. I don't know though because if someone were to constantly turn off and on their calc it could cause issues.
Title: Re: KnightOS Updates
Post by: DarkestEx on March 30, 2015, 01:58:33 pm
How about using different triggers to save the time. Like every 5 min or on power off, but only if more than 5 mins elapsed since the last time.
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 30, 2015, 01:59:41 pm
Sorry guys, but saving the time isn't feasible. It's not happening.
Title: Re: KnightOS Updates
Post by: DarkestEx on March 30, 2015, 02:02:56 pm
Why not?
The OS can back it up to a file.
But if you don't want we can't do anything though.

Knight OS is awesome.
Maybe we can make another version of the shell as I always found it one of the coolest features of it.
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 30, 2015, 02:05:11 pm
Quote from: DarkestEx on March 30, 2015, 02:02:56 pm
Why not?
The OS can back it up to a file.
But if you don't want we can't do anything though.


Writing files can't be done that frequently. The minimum amount of space a file will take up is 256 bytes (for a 4 byte number that's a bit much) and eventually you have to garbage collect. There would be a lot of Flash erasures involved which would wear out your Flash chip and lead to a bricked calculator in a few years of use.

Quote from: DarkestEx on March 30, 2015, 02:02:56 pm
Knight OS is awesome.
Maybe we can make another version of the shell as I always found it one of the coolest features of it.


Are you talking about the app launcher or the old and deprecated command line shell? You can replace the former with your own version very easily, KnightOS is made to be customizable like that. It's as simple as installing a new one and changing the /bin/launcher symlink.
Title: Re: KnightOS Updates
Post by: pimathbrainiac on March 30, 2015, 02:06:20 pm
/me mutters something about KOS being open source


Seriously, if you can do it, contribute! I'm sure if it were feasible and someone made a pull request with that modification, it could happen.

EDIT: ninja'd by sir
Title: Re: KnightOS Updates
Post by: DarkestEx on March 30, 2015, 02:06:54 pm
@pimathbrainiac: do you mean me?
Well, I know a lot of C, but only a little Z80-ASM.
Maybe I can still help one day somehow?

@SirCmpwn: I am talking about the shell.
Can we (the users) make another new version of it as it is soo cool :)
Title: Re: KnightOS Updates
Post by: pimathbrainiac on March 30, 2015, 02:11:40 pm
I mean in general. Although Sir pretty much proved that your feature request can't be done just now.
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 30, 2015, 02:12:06 pm
Quote from: DarkestEx on March 30, 2015, 02:06:54 pm
@pimathbrainiac: do you mean me?
Well, I know a lot of C, but only a little Z80-ASM.
Maybe I can still help one day somehow?


You can write a new shell in C if you like. C support is still experimental but it's getting to the point where it's workable. Of course, if you just want to contribute to KnightOS, there are loads of KnightOS projects in C that run on PCs which you could definitely help with.

Quote from: DarkestEx on March 30, 2015, 02:06:54 pm
@SirCmpwn: I am talking about the shell.
Can we (the users) make another new version of it as it is soo cool :)


I don't understand. Do you mean the command line shell? That was removed because we don't have standard I/O or unix pipes yet.
Title: Re: KnightOS Updates
Post by: CKH4 on March 30, 2015, 02:14:14 pm
I think that he may mean port it to regular tios.
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 30, 2015, 02:15:34 pm
Quote from: CKH4 on March 30, 2015, 02:14:14 pm
I think that he may mean port it to regular tios.


That would be very difficult. It depends on a lot of KnightOS specific features like configlib and reading from files in /var/castle/ and KnightOS threads and spawning model.

Edit: the code for the castle is here if anyone wants to give it a shot: https://github.com/KnightOS/castle
Title: Re: KnightOS Updates
Post by: DarkestEx on March 30, 2015, 02:16:42 pm
Quote from: SirCmpwn on March 30, 2015, 02:12:06 pm
You can write a new shell in C if you like. C support is still experimental but it's getting to the point where it's workable. Of course, if you just want to contribute to KnightOS, there are loads of KnightOS projects in C that run on PCs which you could definitely help with.

Okay. I will see where I can help.

Quote from: SirCmpwn on March 30, 2015, 02:12:06 pm
I don't understand. Do you mean the command line shell? That was removed because we don't have standard I/O or unix pipes yet.

Oh, when will there be Unix pipes and POSIX?
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 30, 2015, 02:18:50 pm
Quote from: DarkestEx on March 30, 2015, 02:16:42 pm
Quote from: SirCmpwn on March 30, 2015, 02:12:06 pm
I don't understand. Do you mean the command line shell? That was removed because we don't have standard I/O or unix pipes yet.

Oh, when will there be Unix pipes and POSIX?


There will probably never be POSIX support. There will be Unix-like pipes sometime after kernel 1.0.0 (i.e. in a very long time).
Title: Re: KnightOS Updates
Post by: Streetwalrus on March 30, 2015, 02:19:32 pm
POSIX compliance isn't planned, the goal is to implement the general concept but not to make a full blown unix. That'd be overly complex and it's not needed anyway.

Woops another ninja.
Title: Re: KnightOS Updates
Post by: DarkestEx on March 30, 2015, 02:30:19 pm
So we can try implementing parts of posix in the libc, right?
I mean we could need stdin, stdout, stderr and arguments, right?
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 30, 2015, 03:04:43 pm
Quote from: DarkestEx on March 30, 2015, 02:30:19 pm
So we can try implementing parts of posix in the libc, right?
I mean we could need stdin, stdout, stderr and arguments, right?


There's no formal support for arguments, but there's some proposals. There is no stdin, stdout, or stderr. The file API is currently hardcoded on KFS operations and hasn't been abstracted out to allow for things like that yet.

You are welcome to help implement parts of POSIX in libc, though. Keep in mind that C support is still experimental in KnightOS and there are several important problems with it, and you will run into frustration if you try to embark on serious C projects on KnightOS.
Title: Re: KnightOS Updates
Post by: SirCmpwn on April 22, 2015, 03:59:28 am
C support continues, and is starting to become something usable for actual projects. More sophisticated programs are working now:

(https://a.pomf.se/dqqhqh.png)

Bonus: I got it to work for the most part on TIOS, and I plan on adding support for writing programs in C for TIOS formally. Also, since KnightOS's libc is statically linked, you can use (most of) the POSIX functions provided by KnightOS on TIOS.

(https://a.pomf.se/oyghtx.png)
Title: Re: KnightOS Updates
Post by: Snektron on April 22, 2015, 10:21:48 am
Ooh nice :D
Title: Re: KnightOS Updates
Post by: Duke "Tape" Eiyeron on April 22, 2015, 11:34:21 am
Mmh, puts is supposed to insert a newline after the string. :-°
Title: Re: KnightOS Updates
Post by: SirCmpwn on April 22, 2015, 02:21:49 pm
Quote from: Duke "Tape" Eiyeron on April 22, 2015, 11:34:21 am
Mmh, puts is supposed to insert a newline after the string. :-°


Yeah, I didn't bother looking into why it didn't work, that was just a proof of concept.
Title: Re: KnightOS Updates
Post by: Duke "Tape" Eiyeron on April 22, 2015, 04:55:53 pm
Yeah and it looks very good. I can't wait to have some test runs on this sdk.
Title: Re: KnightOS Updates
Post by: SirCmpwn on May 07, 2015, 08:12:30 pm
Minor updates:

Ivoah contributed a change to the castle that prevents it from showing the "you might lose work" warning on shut down if there are no running threads other than the castle.

libc is progressing. I've added support for SDCC built-ins from string.h (like memcpy), as well as adding a little bit more to ctype.h. C support in general is improving steadily, with bug fixes in scas and kcc going on. Handling for include paths for C programs has also changed a bit in the SDK to be more flexible and less stupid.

Also, the TI-73 explorer was tested with KnightOS. I expected it to work, and it did, so that's good. No updates on the 84+ CE front - I still don't own one and there are still no public exploits for installing unsigned operating systems.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on May 07, 2015, 09:30:54 pm
Glad to hear about those updates. As for CE support I hope it's not like the Nspire and doesn't require nLaunchy.
Title: Re: KnightOS Updates
Post by: CKH4 on May 07, 2015, 09:53:19 pm
I may be able to test knight os when you get the ce version going. I don't have one yet but I'm planning on getting one soon.
Title: Re: KnightOS Updates
Post by: SirCmpwn on July 19, 2015, 12:26:10 am
Kernel 0.6.8 released

This kernel adds mature date/time support and improves filesystem support.

Features



Bugs fixed



Deprecated



Download

kernel-headers-0.6.8.pkg (https://github.com/KnightOS/kernel/releases/download/0.6.8/kernel-headers-0.6.8.pkg)
kernel-TI73.rom (https://github.com/KnightOS/kernel/releases/download/0.6.8/kernel-TI73.rom)
kernel-TI83p.rom (https://github.com/KnightOS/kernel/releases/download/0.6.8/kernel-TI83p.rom)
kernel-TI83pSE.rom (https://github.com/KnightOS/kernel/releases/download/0.6.8/kernel-TI83pSE.rom)
kernel-TI84p.rom (https://github.com/KnightOS/kernel/releases/download/0.6.8/kernel-TI84p.rom)
kernel-TI84pSE.rom (https://github.com/KnightOS/kernel/releases/download/0.6.8/kernel-TI84pSE.rom)
kernel-TI84pCSE.rom (https://github.com/KnightOS/kernel/releases/download/0.6.8/kernel-TI84pCSE.rom)

Kernel 0.6.8 on Github (https://github.com/KnightOS/kernel/releases/tag/0.6.8)

Disclaimer

This release, like all other kernel releases, is only relevant to developers. The kernel also will not run on its own, so if you put this in an emulator you won't get much out of it.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on July 19, 2015, 06:05:19 pm
Good to see updates. :) Do you know approximately how much percentage of the project is done so far? (by approximate I mean something like 20-30% not a specific percentage :P)
Title: Re: KnightOS Updates
Post by: SirCmpwn on July 19, 2015, 06:06:30 pm
It's a bit weird to ask for a percentage. I don't even know how I'd begin to calculate that. I don't even know what "done" means.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on July 19, 2015, 06:07:56 pm
Oh I mean until it's ready for public use in class and stuff, like Axe Parser 0.2.0, for example (the one that made ticalc.org front page), unless it already is? I didn't install it yet, since I needed to run TI-BASIC programs.
Title: Re: KnightOS Updates
Post by: SirCmpwn on July 19, 2015, 06:14:21 pm
Depending on your use-case, it's ready now. It runs on all of my calcs and the same can be said for several other people. The important milestone is probably math, and that depends on several other things being in place. Kernel 1.0.0 will be the biggest milestone the project has seen so far, and that requires USB support, I/O networking, fully fleshed out filesystem support, better compression support, a mature C API, and some major refactoring projects (refactoring internal kernel data structures, for the most part). For math, we first need to flesh out the package manager and add support for transferring files to calculators post-install, as well as bringing some kind of BCD support in the form of kernel support or a userspace library (or both). corelib should also see more development before we embark on that.

Before I'm willing to call it "1.0", we also need kpy support, a settings manager (in progress now), fileman needs to be fleshed out more, the castle needs to be finished (it's nearly done, but depends on kernel 0.7.0 features), and bed needs to be finished (it's not even close to done), along with all of the things mentioned in the last paragraph.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on July 19, 2015, 06:17:41 pm
Thanks for explaining. That gives me a better idea of how much needs to be done yet. As for math I wasn't sure if 100% of it was up to the developers to add as third-party apps or not, since KOS was originally not gonna include anything and have everything ranging from maths, graphing (eg that grayscale 3D grapher) to games as separate, third-party softwares to keep KOS as small as possible. Including maths could probably make it easier for KOS to be accepted at exams, though, in a more distant future. :)
Title: Re: KnightOS Updates
Post by: SirCmpwn on July 19, 2015, 06:30:17 pm
Quote from: DJ Omnimaga on July 19, 2015, 06:17:41 pm
Thanks for explaining. That gives me a better idea of how much needs to be done yet. As for math I wasn't sure if 100% of it was up to the developers to add as third-party apps or not, since KOS was originally not gonna include anything and have everything ranging from maths, graphing (eg that grayscale 3D grapher) to games as separate, third-party softwares to keep KOS as small as possible. Including maths could probably make it easier for KOS to be accepted at exams, though, in a more distant future. :)


KnightOS is built like a Linux distribution. There's "KnightOS", which refers to the official KnightOS distribution, built on top of the "KnightOS kernel", which is independent and comes with nothing. Basically, "KnightOS" is a collection of software that runs on the KnightOS kernel distributed in one big package. You can add new software, replace the built-in software (with your own castle or file manager or whatever), or remove things you don't need. KnightOS is actually built in a very similar fashion to the Arch Linux distribution. All of the software available on KnightOS can be found at packages.knightos.org (https://packages.knightos.org), including the built-in things like fileman (https://packages.knightos.org/extra/fileman), the castle (https://packages.knightos.org/core/castle), and corelib (https://packages.knightos.org/core/corelib) (by the way, if you search with "!pko" in your duck duck go search terms, it'll redirect you to a search on packages.knightos.org).

So even though the official upstream KnightOS distribution will include enough things to be productive (math, kpy, fileman, etc), you can remove them or replace them. Additionally, it would be extremely easy to make another KnightOS distribution (WalriiOS?) that uses the same kernel but has different packages installed by default.

By the way, just because there's a lot left to do doesn't mean that we haven't come a long ways. Things that are "done" include a filesystem driver, multitasking, dynamic memory management (malloc, realloc, calloc, etc), color support with legacy emulation, packaging tools, image conversion tools, an assembler and linker, a C library and compiler, library support, a KEXC loader, kernel support for compression and sorting, a file manager, an app launcher, thread switcher, calendar, several games, three websites, an extremely good SDK, an emulator (+emscripten), a config library, the community's best 8xu creation and signing tools, filesystem generation tools, a documentation generator and excellent documentation, a mature Flash driver, SHA-1 and CRC16 support, filetype associations, standard concurrency models, signaling, date/time support, and more.
Title: Re: KnightOS Updates
Post by: SirCmpwn on July 27, 2015, 12:19:02 am
(https://sr.ht/a929.png)

Icons in the app listing.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on July 27, 2015, 12:53:40 am
Nice. I wonder if you plan to add descriptions in there? (maybe a pop-up?)
Title: Re: KnightOS Updates
Post by: SirCmpwn on July 27, 2015, 12:54:27 am
Quote from: DJ Omnimaga on July 27, 2015, 12:53:40 am
Nice. I wonder if you plan to add descriptions in there? (maybe a pop-up?)


No plans for that.
Title: Re: KnightOS Updates
Post by: Snektron on July 28, 2015, 07:46:04 pm
Looks pretty sweet :) Also there wouldn't be enough space for a description.
Unless you can like, fit it under the name when you select it. Depends on how the menu handles scrolling
Title: Re: KnightOS Updates
Post by: Luxen on September 30, 2015, 09:59:11 pm
Quote from: SirCmpwn on July 19, 2015, 06:30:17 pm
Quote from: DJ Omnimaga on July 19, 2015, 06:17:41 pm
Thanks for explaining. That gives me a better idea of how much needs to be done yet. As for math I wasn't sure if 100% of it was up to the developers to add as third-party apps or not, since KOS was originally not gonna include anything and have everything ranging from maths, graphing (eg that grayscale 3D grapher) to games as separate, third-party softwares to keep KOS as small as possible. Including maths could probably make it easier for KOS to be accepted at exams, though, in a more distant future. :)


KnightOS is built like a Linux distribution. There's "KnightOS", which refers to the official KnightOS distribution, built on top of the "KnightOS kernel", which is independent and comes with nothing. Basically, "KnightOS" is a collection of software that runs on the KnightOS kernel distributed in one big package. You can add new software, replace the built-in software (with your own castle or file manager or whatever), or remove things you don't need. KnightOS is actually built in a very similar fashion to the Arch Linux distribution. All of the software available on KnightOS can be found at packages.knightos.org (https://packages.knightos.org), including the built-in things like fileman (https://packages.knightos.org/extra/fileman), the castle (https://packages.knightos.org/core/castle), and corelib (https://packages.knightos.org/core/corelib) (by the way, if you search with "!pko" in your duck duck go search terms, it'll redirect you to a search on packages.knightos.org).

So even though the official upstream KnightOS distribution will include enough things to be productive (math, kpy, fileman, etc), you can remove them or replace them. Additionally, it would be extremely easy to make another KnightOS distribution (WalriiOS?) that uses the same kernel but has different packages installed by default.

By the way, just because there's a lot left to do doesn't mean that we haven't come a long ways. Things that are "done" include a filesystem driver, multitasking, dynamic memory management (malloc, realloc, calloc, etc), color support with legacy emulation, packaging tools, image conversion tools, an assembler and linker, a C library and compiler, library support, a KEXC loader, kernel support for compression and sorting, a file manager, an app launcher, thread switcher, calendar, several games, three websites, an extremely good SDK, an emulator (+emscripten), a config library, the community's best 8xu creation and signing tools, filesystem generation tools, a documentation generator and excellent documentation, a mature Flash driver, SHA-1 and CRC16 support, filetype associations, standard concurrency models, signaling, date/time support, and more.


Wow. KnightOS has gotten lots of updates since I last looked at it up close. Any time i check the "changes" on github, it looks like all thats happened is changes to thanks, not any of ... ~that~.
Title: Re: KnightOS Updates
Post by: Ivoah on September 30, 2015, 10:00:24 pm
Quote from: Luxen on September 30, 2015, 09:59:11 pm
Wow. KnightOS has gotten lots of updates since I last looked at it up close. Any time i check the "changes" on github, it looks like all thats happened is changes to thanks, not any of ... ~that~.


That's probably because you're just looking at changes for the KnightOS repo, not all of the other repos in the KOS project (kernel, z80e, kcc, scas, etc)
Title: Re: KnightOS Updates
Post by: Luxen on October 01, 2015, 01:31:33 am
For a while, it seemed like all changes were posted to the main changes listing. Anyways, thanks for the info, ill check those from now on.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on October 01, 2015, 02:06:32 am
Yeah generally the changes are all posted in the KOS repo or other repos related to KOS. When there is major progress, sometimes Vijfhoek, Matref or SirCmpwn cross-posted some updates here, but I don't know if KOS progressed much since the last update since I didn't have time to check the repos nor the official site.
Title: Re: KnightOS Updates
Post by: semiprocoder on October 01, 2015, 03:22:15 am
More people should start making knightos apps, cause it's practically devoid of them atm, and they should make the sdk easier to install on windows, cause I have 0 linux skills whatsoever. I should probably do something about that sometime though...
Title: Re: KnightOS Updates
Post by: Max Leiter on October 12, 2015, 02:38:02 am
Quote from: semiprocoder on October 01, 2015, 03:22:15 am
More people should start making knightos apps, cause it's practically devoid of them atm, and they should make the sdk easier to install on windows, cause I have 0 linux skills whatsoever. I should probably do something about that sometime though...

Kinda late, but you can make it run with Cygwin pretty easily
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on October 12, 2015, 02:53:39 am
Hi and welcome to the forums Max Leiter. Do you know if it's 100% compatible with Cygwin?
Title: Re: KnightOS Updates
Post by: SirCmpwn on October 12, 2015, 02:54:32 am
Quote from: DJ Omnimaga on October 12, 2015, 02:53:39 am
Hi and welcome to the forums Max Leiter. Do you know if it's 100% compatible with Cygwin?


Everything but kcc works on Cygwin.
Title: Re: KnightOS Updates
Post by: Streetwalrus on October 12, 2015, 03:09:39 pm
Quote from: Luxen on October 01, 2015, 01:31:33 am
For a while, it seemed like all changes were posted to the main changes listing. Anyways, thanks for the info, ill check those from now on.

The main repo was split since the package manager works. Originally only the kernel was included as a submodule but now the main repo is just a config file to build a ROM from packages. Nightly builds are rolled from that.
Title: Re: KnightOS Updates
Post by: SirCmpwn on October 18, 2015, 09:24:18 pm
Kernel 0.6.10

Quote
This is another mostly maintenance related kernel release.

Features
New syscalls:

  • createSymLink (http://www.knightos.org/documentation/reference/filesystem.html#createSymLink)

  • getNextThreadId (http://www.knightos.org/documentation/reference/threading.html#getNextThreadID)



Bugs fixed

  • Incorrect copying of data in realloc under certain conditions



Quoted from Github (https://github.com/KnightOS/kernel/releases/tag/0.6.10)

Downloads

Headers
kernel-headers-0.6.10 (https://github.com/KnightOS/kernel/releases/download/0.6.10/kernel-headers-0.6.10.pkg) (PKO version (https://packages.knightos.org/core/kernel-headers))

Kernels
TI-73 (https://github.com/KnightOS/kernel/releases/download/0.6.10/kernel-TI73.rom) TI-83+ (https://github.com/KnightOS/kernel/releases/download/0.6.10/kernel-TI83p.rom) TI-83+ SE (https://github.com/KnightOS/kernel/releases/download/0.6.10/kernel-TI83pSE.rom) TI-84+ (https://github.com/KnightOS/kernel/releases/download/0.6.10/kernel-TI84p.rom) TI-84+ SE (https://github.com/KnightOS/kernel/releases/download/0.6.10/kernel-TI84pSE.rom) TI-84+ CSE (https://github.com/KnightOS/kernel/releases/download/0.6.10/kernel-TI84pCSE.rom)

KnightOS running on kernel 0.6.10: Download upgrade files (http://builds.knightos.org/job/KnightOS/70/artifact/KnightOS-0.3.0-55-gd4c3f3a.zip)
Title: Re: KnightOS Updates
Post by: Ivoah on October 18, 2015, 09:30:07 pm
Glad to see some progress on KOS! I wish I had some more free time so I could help with stuff, but school has been busy lately. I hope this update signals the coming of future bigger updates in the near future, keep up the good work SirCmpwn.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on October 18, 2015, 09:31:14 pm
Once I fix my old 83+ I'll give this a try. I'm glad that KOS is still progressing. :)
Title: Re: KnightOS Updates
Post by: Max Leiter on October 18, 2015, 09:33:45 pm
Really glad KOS is still moving forward, really hope I can help with kernel dev at some point in the future. Should be a little easier now that I have a physical calculator to run it on d:
Title: Re: KnightOS Updates
Post by: SirCmpwn on October 18, 2015, 09:35:17 pm
I've been working on bed (the KnightOS text editor) over the last few days. Here's a video of it editing its own source code:

Title: Re: KnightOS Updates
Post by: garvalf on October 19, 2015, 06:52:39 am
KnightOS looks cool, and while I know it's not the purpose of it, I find it strange there is not even a simple 4 operations calculator included with it...
I've seen https://packages.knightos.org/community/progcalc but I have now clue for how to install it within an emulator.
Title: Re: KnightOS Updates
Post by: utz on October 19, 2015, 08:32:51 am
I'm starting to drool more and more over this... hmm, perhaps I should attempt a KOS port of HoustonTracker 2? I assume it would be a relatively simple matter of changing the header, reassigning the saferam areas, and replacing the one bcall (clearlcd) with the according KOS function. Can someone give me a quick run-through of the most important things to know? I'd prefer to include a minimum set of tools in my own toolchain rather than use the KOS SDK, though.
Title: Re: KnightOS Updates
Post by: Streetwalrus on October 19, 2015, 08:49:33 am
Quote from: garvalf on October 19, 2015, 06:52:39 am
KnightOS looks cool, and while I know it's not the purpose of it, I find it strange there is not even a simple 4 operations calculator included with it...
I've seen https://packages.knightos.org/community/progcalc but I have now clue for how to install it within an emulator.

There is no floating point support in the kernel yet, which is why there's no proper calculator for it.

Quote from: utz on October 19, 2015, 08:32:51 am
I'm starting to drool more and more over this... hmm, perhaps I should attempt a KOS port of HoustonTracker 2? I assume it would be a relatively simple matter of changing the header, reassigning the saferam areas, and replacing the one bcall (clearlcd) with the according KOS function. Can someone give me a quick run-through of the most important things to know? I'd prefer to include a minimum set of tools in my own toolchain rather than use the KOS SDK, though.

You have to use the SDK to build KOS programs, because it has to be built into the ROM for now since there are still no file transfers. You'd have more to change than just the header. KnightOS executables are position-independent and you should use the syscalls to access the LCD. Not sure if it does anything with the link port.
Title: Re: KnightOS Updates
Post by: utz on October 19, 2015, 09:25:14 am
Oic. It won't be possible then. HT2 is not position-independant due to huge amounts of self-modifying code and page-aligned lookup tables, and all the gfx are done through direct LCD access via port 10/11.
Title: Re: KnightOS Updates
Post by: SirCmpwn on October 19, 2015, 11:59:14 am
Quote from: utz on October 19, 2015, 09:25:14 am
Oic. It won't be possible then. HT2 is not position-independant due to huge amounts of self-modifying code and page-aligned lookup tables, and all the gfx are done through direct LCD access via port 10/11.


Phoenix is the same way - lots of LUTs, SMC, and direct LCD access, but I was still able to port it.
Title: Re: KnightOS Updates
Post by: utz on October 20, 2015, 05:03:58 pm
I think I'm a bit too busy to really dig into KOS enough to pull it off at this point. Well, you can always give it a try of course, the code is on my github. Though I'd say it's probably best to wait till the next release, when a few more bugs have been ironed out.
Title: Re: KnightOS Updates
Post by: SirCmpwn on October 23, 2015, 11:50:09 pm
Got a special something in the mail yesterday. Was a nice distraction from the KnightOS stuff I'm supposed to be doing. Check it out:



That's right! TI Keyboard support, baby. I started by implementing the TI link protocol, and then decoding packets from the keyboard to pull out scancodes. I made a generic interface from the kernel to expose raw scancodes to userspace (http://www.knightos.org/documentation/reference/input.html#getScanCode) from any sort of keyboard as well. The old keypad driver is still in place and hasn't been moved to this model, but I expect to change that fairly soon and move most of the keyboard handling to userspace (this will allow us to do things like support USB keyboards with whatever non-English keymap you prefer, for example). I hardcoded the TI Keyboard's keymap into corelib so that the getCharacterInput function would return ASCII characters from the keyboard. This means that any userspace app that already took text input now supports the keyboard with no changes (no need to recompile, either). It's not done yet, but it's pretty good. Also, this forced me to establish partial link protocol support in the kernel, which is a good head start for eventually implementing file transfers from PCs to calcs.

If you want to play with this yourself, a TI keyboard is about 10 bucks on Amazon (http://www.amazon.com/Texas-Instruments-Keyboard-Graphing-Calculators/dp/B00007K7JE). The relevant changes to the kernel and corelib have not been released in a stable version yet, but you can compile them yourselves if you want to try it out.
Title: Re: KnightOS Updates
Post by: Streetwalrus on October 24, 2015, 12:01:57 am
Nice, that was pretty fast. I like that you are supporting official peripherals, gives KOS even more value to switch over to.
Title: Re: KnightOS Updates
Post by: Max Leiter on October 24, 2015, 12:09:06 am
Really cool to see some kernel work being done on KOS, also surprised at how fast you added it. +1
Title: Re: KnightOS Updates
Post by: SirCmpwn on October 26, 2015, 01:26:27 pm
Spent all weekend working on this:

(https://sr.ht/li5c.jpg)

It's still pretty buggy, but the code is up here: https://github.com/KnightOS/iofsd. The relevant kernel code is here: https://github.com/KnightOS/kernel/blob/master/src/00/link.asm

This is a daemon, "iofsd", that I'm going to make run at boot (it'll be added to /etc/inittab). It makes it so that a computer can talk to KnightOS about its filesystem over the I/O port. Running as a daemon means that it's kept in the background and silently does its job while the rest of the OS gets on with life. It also spends most of its life suspended, which means that it's not taking up CPU time except for the handful of milliseconds it spends responding to queries over the I/O port. The end result is that I can plug my calculator into my PC while I'm playing Phoenix and list the contents of a directory without any discernable slowdown of gameplay. This depends heavily on the I/O support I've added to the kernel, which gives userspace programs asyncronous access to the I/O port. Given some minor extensions on the TI link protocol, the kernel can listen for packets and notify userspace programs that have requested to be notified about certain packet types as they arrive. Userspace programs can also allocate buffers for bulk transfers and asyncronously send a response. This is also designed for concurrent use of the I/O port - you could plug your calcluator into a friend's calculator and start sending over files, then switch to a chat program and chat with them as the files are being sent in the background. Currently, only the TI-83+ SE and higher are supported. I'll add the TI-73 and TI-83+ after everything settles down, it shouldn't be too hard.

Anyway, it's still buggy, but it works.. Next on my plate is going to be cleaning up the bugs and making it stable, then I'm going to add support for sending and receiving files, and eventually I want to make it so that you can mount your calculator's filesystem on a Linux system with FUSE (which will then make it possible to install packages on your calculator without reflashing the whole OS, finally).
Title: Re: KnightOS Updates
Post by: Lionel Debroux on October 26, 2015, 08:30:41 pm
Looks good :)

Quoteso that you can mount your calculator's filesystem on a Linux system with FUSE

In libticalcs, it's a good thing that since the TILP II 1.17 release train, I moved static variables scattered into multiple source files to CalcHandle...
Title: Re: KnightOS Updates
Post by: SirCmpwn on October 26, 2015, 08:36:34 pm
Quote from: Lionel Debroux on October 26, 2015, 08:30:41 pm
In libticalcs, it's a good thing that since the TILP II 1.17 release train, I moved static variables scattered into multiple source files to CalcHandle...


Nice :) this just uses libticables, not libticalcs.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on October 28, 2015, 05:38:50 pm
So basically, does it mean that in the future, it could be possible to launch KnightOS-compatible calculator programs from a computer, with the program being temporarily copied in the calculator RAM then if writeback is enabled, its copy sent back to the computer upon exiting? No matter what, this is very cool, though. I always kneew that KOS aimed at supporting multitasking but I didn't realize that multitasking could continue working in an ASM game.
Title: Re: KnightOS Updates
Post by: SirCmpwn on October 28, 2015, 05:43:02 pm
Quote from: DJ Omnimaga on October 28, 2015, 05:38:50 pm
So basically, does it mean that in the future, it could be possible to launch KnightOS-compatible calculator programs from a computer, with the program being temporarily copied in the calculator RAM then if writeback is enabled, its copy sent back to the computer upon exiting? No matter what, this is very cool, though. I always kneew that KOS aimed at supporting multitasking but I didn't realize that multitasking could continue working in an ASM game.


I guess that sort of thing could be possible, but that's not really the intent of this feature nor would it be possible without significant further development. Also, KnightOS doesn't really use writeback - instead, you're encouraged to create files on the filesystem to save your data. Phoenix uses writeback on TIOS, but the KnightOS port of Phoenix stores its saved game data in /var/phoenix/.

The secret to having the game remain playable while remote file operations are happening is the asyncronous kernel API for the I/O port. Whenever the daemon takes control to respond to packets, it runs a relatively small and fast amount of code that ends with asyncronously sending a packet, which then returns control to the game while the packet is sending, and the daemon only gets control back again once the packet is done.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on October 28, 2015, 05:46:11 pm
I see. Also good move about the save files. I wasn't sure if you used those since you were playing Phoenix, so I thought that some old ASM games would still rely on SMC.


Also I assume that the asyncronous kernel API for the I/O port uses something like interrupts, right? Would it make it had to port games such as Desolate and the ASM remake of Reuben Quest 2, which uses interrupt-based grayscale?
Title: Re: KnightOS Updates
Post by: SirCmpwn on October 28, 2015, 06:16:27 pm
Quote from: DJ Omnimaga on October 28, 2015, 05:46:11 pm
I see. Also good move about the save files. I wasn't sure if you used those since you were playing Phoenix, so I thought that some old ASM games would still rely on SMC.


Also I assume that the asyncronous kernel API for the I/O port uses something like interrupts, right? Would it make it had to port games such as Desolate and the ASM remake of Reuben Quest 2, which uses interrupt-based grayscale?


Yes, it uses the link assist interrupts. The hardware is responsible for sending/receiving bytes, and the kernel's interrupt handler queues up the next byte in a handful of T-states. Desolate and Reuben Quest's way of doing grayscale are not compatible with KnightOS, but I'm planning on making a grayscale library that is interruptable, which the ports of games like Desolate can be modified to use instead of their current grayscale mechanism.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on October 28, 2015, 08:30:44 pm
That's good. Does it mean that grayscale would sometime stop refreshing during gameplay every second or so for a very short period of time?
Title: Re: KnightOS Updates
Post by: SirCmpwn on October 28, 2015, 08:36:43 pm
Quote from: DJ Omnimaga on October 28, 2015, 08:30:44 pm
That's good. Does it mean that grayscale would sometime stop refreshing during gameplay every second or so for a very short period of time?


Too early to say, but of course that would not be the desired behavior and we'll work to avoid that.
Title: Re: KnightOS Updates
Post by: Lionel Debroux on October 28, 2015, 08:58:04 pm
Quotethis just uses libticables, not libticalcs.

I thought you may have been able to leverage some code from libticalcs, especially the lower layers (dbus_send, dbus_recv), or even some commands (now in cmdz80.c), given that you wrote:
QuoteGiven some minor extensions on the TI link protocol, the kernel can listen for packets and notify userspace programs that have requested to be notified about certain packet types as they arrive.


The version in the tilibs Git repository exposes more APIs than the version corresponding to the TILP II 1.17 release train.
Title: Re: KnightOS Updates
Post by: SirCmpwn on October 28, 2015, 09:10:35 pm
The libticables code for iofs is pretty simple, take a look for yourself:

https://github.com/KnightOS/iofsd/blob/master/iofs/src/protocol.c
Title: Re: KnightOS Updates
Post by: Lionel Debroux on October 29, 2015, 06:36:53 am
send_packet() could just leverage dbus_send(), which has been exported for a while. You'd gain progress information.
recv_packet() cannot just leverage dbus_recv(), as that performs protocol checking... but if I refactor dbus_recv() to split the header receive and the data receive code (with progress information) from the main function, then export the two new helper functions, you could use them. This refactoring is a worthwhile change regardless of whether you switch to libticalcs.
Title: Re: KnightOS Updates
Post by: SirCmpwn on October 29, 2015, 11:52:39 am
Quote from: Lionel Debroux on October 29, 2015, 06:36:53 am
send_packet() could just leverage dbus_send(), which has been exported for a while. You'd gain progress information.
recv_packet() cannot just leverage dbus_recv(), as that performs protocol checking... but if I refactor dbus_recv() to split the header receive and the data receive code (with progress information) from the main function, then export the two new helper functions, you could use them. This refactoring is a worthwhile change regardless of whether you switch to libticalcs.


I see. The progress information would probably be useful if I were to make some sort of GUI for managing your filesystem. Also, I'm pretty sure that the protocol in use here is close enough to the dbus protocol that it'll work fine. I probably wouldn't take advantage of them in any case for this project, but you're right that the refactoring may be worthwhile. I would like to see more people using libticables for interesting projects like this.
Title: Re: KnightOS Updates
Post by: SirCmpwn on November 03, 2015, 10:28:53 pm
New contributor jacobly has been making some waves recently in z80e and other places:

(https://sr.ht/cSXD.png)

He has dramatically improved the accuracy of z80e. Now it can boot TIOS, though it's buggy and slow - probably interrupt problems. It can also run this old KnightOS demo, finally:



Thanks to his efforts, z80e passes zexdoc and zexall now, which means that the z80 emulation is spot on. Thanks jacobly!

I'm probably going to jump on the z80e train and flesh it out some more when I'm not working on iofsd or bed.
Title: Re: KnightOS Updates
Post by: Max Leiter on November 04, 2015, 04:57:24 am
Also worth noting, there is now a Dockerfile (https://github.com/knightos/docker) for a Debian machine with the SDK installed thanks to @SirCmpwn
Title: Re: KnightOS Updates
Post by: Lionel Debroux on November 12, 2015, 03:34:26 pm
FWIW, I've now spliced the header receiving code and the data receiving code out of libticalcs' dbus_recv(), and exported both new helper functions, as I mentioned above. The commit lives in the "experimental" branch for now, https://github.com/debrouxl/tilibs/tree/experimental .
Title: Re: KnightOS Updates
Post by: Max Leiter on December 15, 2015, 02:27:12 am
Small update, but I think it's worth a post d:

libc, KnightOS's C library, now has variants of printf implemented!
(https://sr.ht/Fe27.png)


The relevant code can be found in stdio.c (https://github.com/MaxLeiter/libc/blob/master/src/stdio.c) and format.c (https://github.com/MaxLeiter/libc/blob/master/src/format.c)


In other news:
Title: Re: KnightOS Updates
Post by: alexgt on December 15, 2015, 03:39:52 am
Nice ;)
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on December 15, 2015, 08:00:52 pm
I'm curious about how easy it will be to port color games from the CE to the monochrome models, assuming those games can easily be modified for a smaller screen, compared to porting CE ASM games to monochrome calcs?

Also great news about z80e. I wonder if he plans to add ez80 and 84+CE support in the future? That would make z80e the first ever TI-84 Plus CE emulator. We would first need a way to dump 84+CE ROMs, though.
Title: Re: KnightOS Updates
Post by: SirCmpwn on December 15, 2015, 08:07:47 pm
Quote from: DJ Omnimaga on December 15, 2015, 08:00:52 pm
I'm curious about how easy it will be to port color games from the CE to the monochrome models, assuming those games can easily be modified for a smaller screen, compared to porting CE ASM games to monochrome calcs?


Graceful degredation. Design your games for a monochrome screen, then use color instead of avaialble.

Quote from: DJ Omnimaga on December 15, 2015, 08:00:52 pm
Also great news about z80e. I wonder if he plans to add ez80 and 84+CE support in the future? That would make z80e the first ever TI-84 Plus CE emulator. We would first need a way to dump 84+CE ROMs, though.


Not enough is known about the 84+CE to emulate it yet, I'd say. However, if KnightOS is eventually ported to the CE, then z80e will be updated to support CE emulation. That being said, I don't have an 84+CE and I am not going to attempt a port until an exploit for installing unsigned OSes is made public.
Title: Re: KnightOS Updates
Post by: GalacticPirate on January 13, 2016, 01:38:44 pm
@DJ_O and SirCpwn : Well, TI-Converter should soon be able to convert color games for monochrome calcs :)
Title: Re: KnightOS Updates
Post by: Streetwalrus on January 13, 2016, 02:30:23 pm
This shouldn't be needed on KnightOS, programs can use pretty much the same code base with the exception of display/drawing code since the OS is the same (unlike TIOS) and the hardware is also mostly identical. Detecting the host calculator can even be done at runtime.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on January 13, 2016, 05:27:02 pm
Quote from: STV on January 13, 2016, 01:38:44 pm
@DJ_O and SirCpwn : Well, TI-Converter should soon be able to convert color games for monochrome calcs :)
I thought it did the oppisite?
Title: Re: KnightOS Updates
Post by: Max Leiter on January 14, 2016, 01:56:23 am
Relevant video by @SirCmpwn about KOS running on the 84+ CSE
In case the video isn't loading:
https://www.youtube.com/watch?v=Y9iNl8wciiQ
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on January 15, 2016, 07:55:35 am
Glad to see CSE support coming along smoothly. It's also cool to see KOS run some existing color programs. :)
Title: Re: KnightOS Updates
Post by: Streetwalrus on January 15, 2016, 11:46:23 am
CSE support has been in for a long time actually, it's pretty much done.
Title: Re: KnightOS Updates
Post by: Snektron on January 15, 2016, 12:03:26 pm
Quote from: Max Leiter on January 14, 2016, 01:56:23 am
Relevant video by @SirCmpwn about KOS running on the 84+ CSE
In case the video isn't loading:
https://www.youtube.com/watch?v=Y9iNl8wciiQ

That looks really nice. Too bad i have to  use my calculator for math and i don't think they'd allow custom OS's on my finals :P
Title: Re: KnightOS Updates
Post by: Streetwalrus on January 15, 2016, 12:49:53 pm
Well, given the current state of math support... :P
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on January 15, 2016, 05:28:36 pm
Quote from: Streetwalrus on January 15, 2016, 11:46:23 am
CSE support has been in for a long time actually, it's pretty much done.
Yeah I didn't know it ran CSE ASM programs yet, though.
Title: Re: KnightOS Updates
Post by: Max Leiter on January 15, 2016, 05:34:07 pm
Quote from: DJ Omnimaga on January 15, 2016, 05:28:36 pm
Quote from: Streetwalrus on January 15, 2016, 11:46:23 am
CSE support has been in for a long time actually, it's pretty much done.
Yeah I didn't know it ran CSE ASM programs yet, though.

Well, it runs KOS ASM programs. On KOS, a program written for the 83+, 84+, etc can run on the CSE without any extra work. As SirCmpwn said earlier,
Quote from: SirCmpwn on December 15, 2015, 08:07:47 pm
Graceful degredation. Design your games for a monochrome screen, then use color instead of avaialble.
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on January 16, 2016, 06:49:48 am
So it would be like when we develop Nspire Clickpad/Touchpad games? IIRC, most Ndless and Lua games made for the grayscale models required no work to be ported to the CX and you could even implement colors and they would display as grayscale on the grayscale models.
Title: Re: KnightOS Updates
Post by: SirCmpwn on January 25, 2016, 03:17:37 am
Kernel 0.6.11

Quote
This kernel adds experimental I/O support.

Features

  • TI link port protocol support

  • Concurrent link port access

  • TI Keyboard (http://www.datamath.org/Graphing/JPEG_Keyboard.htm) support



New syscalls:

  • ioSendBuffer (http://www.knightos.org/documentation/reference/i_o.html#ioSendBuffer)

  • ioRegisterHandler (http://www.knightos.org/documentation/reference/i_o.html#ioRegisterHandler)



Bugs fixed

  • Mishandled stack in streamWriteBuffer

  • Writing beyond EOF in streamWriteBuffer extends the file as appropriate

  • createDirectory returns Z on success



Changes

  • When there are no active threads, the kernel spins instead of crashing. Note that if there are no threads (not just no _active_ threads), the kernel will still crash as appropriate.

  • Kernel now keeps internal "clock" for I/O timing



Quoted from Github (https://github.com/KnightOS/kernel/releases/tag/0.6.11)


Downloads

Headers
kernel-headers-0.6.11 (https://github.com/KnightOS/kernel/releases/download/0.6.11/kernel-headers-0.6.11.pkg) (PKO version (https://packages.knightos.org/core/kernel-headers))

Kernels
TI-73 (https://github.com/KnightOS/kernel/releases/download/0.6.11/kernel-TI73.rom) TI-83+ (https://github.com/KnightOS/kernel/releases/download/0.6.11/kernel-TI83p.rom) TI-83+ SE (https://github.com/KnightOS/kernel/releases/download/0.6.11/kernel-TI83pSE.rom) TI-84+ (https://github.com/KnightOS/kernel/releases/download/0.6.11/kernel-TI84p.rom) TI-84+ SE (https://github.com/KnightOS/kernel/releases/download/0.6.11/kernel-TI84pSE.rom) TI-84+ CSE (https://github.com/KnightOS/kernel/releases/download/0.6.11/kernel-TI84pCSE.rom)

KnightOS running on kernel 0.6.11: Download upgrade files (http://builds.knightos.org/job/KnightOS/92/artifact/KnightOS-0.3.0-60-g9c07c95.zip)

I have also pushed new versions of libc and corelib. Both have seen lots of improvements from the community, with expanded support for the POSIX API in libc as well as expanded support for KnightOS syscalls from C code, and corelib includes TI keyboard support as well as full coverage of the assembly API from C code.

The I/O layer is unstable and not done, but I have some cool demos that I've put together that can do things like control KnightOS from a PC (by simulating the TI keyboard protocol) and sending/receiving files over the I/O port. I'm working on adding link port/link assist support to z80e so that I can better debug these features and improve the reliability of the kernel I/O layer.
Title: Re: KnightOS Updates
Post by: Ivoah on January 25, 2016, 03:23:19 am
Awesome! It's always great to see new progress on KOS, especially in the field of I/O. How far off do you think installing packages is?
Title: Re: KnightOS Updates
Post by: SirCmpwn on January 25, 2016, 03:26:06 am
Quote from: Ivoah on January 25, 2016, 03:23:19 am
Awesome! It's always great to see new progress on KOS, especially in the field of I/O. How far off do you think installing packages is?


Well, if I can get the I/O to be more reliable, not too far. I have a daemon (on calc) that speaks a custom KnightOS filesystem over I/O protocol, but the kernel layer f***s up sometimes and it quits working. There's a Linux side of this using libticables that I will eventually extend into a FUSE tool for mounting your calculator, and then you can kpack -e packages into the mountpoint. I'm sure someone will write a script that makes a pretty installation interface on top of this. Bad news - it'll be Linux only unless anyone cares enough to port it to something else.
Title: Re: KnightOS Updates
Post by: SiphonicSugar on January 25, 2016, 03:45:43 am
Wait, does this completely replace the operating system?
Title: Re: KnightOS Updates
Post by: Max Leiter on January 25, 2016, 03:49:46 am
Yay! No more dependency hell with C projects!

Quote from: SiphonicSugar on January 25, 2016, 03:45:43 am
Wait, does this completely replace the operating system?

Yep! KnightOS is a full operating system.
Title: Re: KnightOS Updates
Post by: SiphonicSugar on January 25, 2016, 04:19:59 am
And can it calculate math problems just like the regular OS?
Title: Re: KnightOS Updates
Post by: Max Leiter on January 25, 2016, 04:22:28 am
Quote from: SiphonicSugar on January 25, 2016, 04:19:59 am
And can it calculate math problems just like the regular OS?

There is a 4-operation calculator, but currently the kernel doesn't have floating point support (although some FP support is provided by libc, KnightOS's c library) and no one has made a full-calculator application yet. Atm, a system-default calculator is years away.
Title: Re: KnightOS Updates
Post by: SiphonicSugar on January 25, 2016, 04:24:10 am
Oh crap...

Cause I was going to suggest that you find out how to make a CAS from the weak processor it has...
Title: Re: KnightOS Updates
Post by: SirCmpwn on January 25, 2016, 01:31:05 pm
I've occasionally been working on porting gCAS2 (from GlassOS) to KnightOS. I've been spending more time fixing issues with KnightOS's C support than working on gCAS2 code, though. Even once that's ported it'll be more of a tech demo than a classroom-ready calculator app considering the use of binary floats. The calculator app I've been promising for years will eventually come, I just have to deal with other stuff first.

On another note, I just got z80e's link assist working this morning, which will make it much, much easier to debug the kernel's I/O layer (and should also make it possible to do things like sending 8xp files to TIOS at some point). Here's a screenshot of me using the debugger to send keypresses like a TI Keyboard would:

(https://sr.ht/JPfK.png)
Title: Re: KnightOS Updates
Post by: DarkestEx on January 25, 2016, 05:19:00 pm
Sounds good.

@SirCmpwn how portable is the Knight OS kernel?
Could it run on the ZPX-128 with modification or is it impossible to do so?
Some facts about the ZPX-128:
- Full address space belongs to RAM; lower half of memory is always page 0 and upper half can be paged between three pages of 32 KB.
- Everything that deals with I/O is done over the I/O interface; sometimes the PXA (system controller) halts the Z80 to access its memory to copy stuff between it's own RAM and the Z80's e.g. when copying files from SD to RAM.
Title: Re: KnightOS Updates
Post by: SirCmpwn on January 25, 2016, 06:59:36 pm
Quote from: DarkestEx on January 25, 2016, 05:19:00 pmhow portable is the Knight OS kernel?


Not very. It can be ported to other calculators that have a similar architecture to the existing ones, but porting it to anything else would be difficult. It might be possible with a lot of work towards making it more modular and with better drivers and interfaces to hardware. Would be easier once the kernel can be compiled with scas, I think.
Title: Re: KnightOS Updates
Post by: DarkestEx on January 25, 2016, 07:05:59 pm
Quote from: SirCmpwn on January 25, 2016, 06:59:36 pm
Quote from: DarkestEx on January 25, 2016, 05:19:00 pmhow portable is the Knight OS kernel?


Not very. It can be ported to other calculators that have a similar architecture to the existing ones, but porting it to anything else would be difficult. It might be possible with a lot of work towards making it more modular and with better drivers and interfaces to hardware. Would be easier once the kernel can be compiled with scas, I think.

Ah, I see. Well then developing a new OS from scratch might be easier.
Title: Re: KnightOS Updates
Post by: Streetwalrus on January 25, 2016, 07:32:45 pm
Quote from: DJ Omnimaga on January 16, 2016, 06:49:48 am
So it would be like when we develop Nspire Clickpad/Touchpad games? IIRC, most Ndless and Lua games made for the grayscale models required no work to be ported to the CX and you could even implement colors and they would display as grayscale on the grayscale models.

It depends. There are significant hardware differences between the Classic and the CX so if a program uses hardware directly, it needs runtime checks to adapt to the calc or two separate builds. The LCD driver can be configured for monochrome colors on the CX though.

Quote from: SirCmpwn on January 25, 2016, 03:26:06 am
Bad news - it'll be Linux only unless anyone cares enough to port it to something else.

There is a FUSE port for OSX, I don't know if there is one for *BSDs, but that still leaves Windows out of the equation unless a dedicated linking application is written.
Title: Re: KnightOS Updates
Post by: SirCmpwn on January 25, 2016, 08:29:26 pm
It'd also probably be pretty easy to add KnightOS support to TiLP.
Title: Re: KnightOS Updates
Post by: ben_g on January 25, 2016, 08:39:01 pm
Will we also be able to send files by dropping them on z80e, so that we can load new programs on it while it's running? And will wabbitemu's file transfers work, either with or without an update?
Great work, SirCmpwn!
Title: Re: KnightOS Updates
Post by: Lionel Debroux on January 25, 2016, 08:47:08 pm
QuoteIt'd also probably be pretty easy to add KnightOS support to TiLP.

I'd think so, all the more:
* recent versions of libticalcs export far more functions than versions before my time as the maintainer did;
* dbus_recv() was recently split to dbus_recv_header() + dbus_recv_data(), according to our earlier discussion, which happened to match a much older feature request from Benjamin Moody. The corresponding commit is still part of the experimental branch for now (this particular commit wasn't updated beyond the commit message for weeks, though), but won't be for too long;
* even if you implemented a brand-new protocol, libticalcs contains support for 4 protocols: 3 official protocols unofficially dubbed DBUS, DUSB and NSP, and libticalcs' specific ROM dumping protocol.

Even in user-space (libusb-win32 / libusb), Windows USB drivers are such a pain for users (filter driver, ever more offensive signing requirements; a Windows expert and libwdi could help ease the pain) that for KnightOS users' sake, even a brand-new code base really ought to be based on at least the drivers provided alongside libticables :)
Title: Re: KnightOS Updates
Post by: SirCmpwn on January 25, 2016, 08:52:44 pm
Quote from: ben_g on January 25, 2016, 08:39:01 pm
Will we also be able to send files by dropping them on z80e, so that we can load new programs on it while it's running? And will wabbitemu's file transfers work, either with or without an update?
Great work, SirCmpwn!


Well, let me clarify the z80e situation. z80e is presently a debugging tool for KnightOS development. Support for TIOS and Windows and as a general purpose emulator would be great and I would totally review and merge pull requests that add these things, but I'm not personally as interested in working on them as much as I would be interested on helping others work on them. The same goes for integration with tools like Wabbitemu, which is Windows-only. So while eventually someone might add support for sending files to TIOS, don't expect that from me. That being said, I would like to make it possible to mount an emulated calculator's filesystem on a Linux (or perhaps OSX) system and send files through that means, while it's running.

z80e is a great emulator, probably the best, and has a great debugger and great developer experience. I would like to see more people using it, but I need members of the community to step up and help with TIOS and Windows support if that's to be the case.

Quote from: Lionel Debroux on January 25, 2016, 08:47:08 pm
QuoteIt'd also probably be pretty easy to add KnightOS support to TiLP.

I'd think so, all the more:
* recent versions of libticalcs export far more functions than versions before my time as the maintainer did;
* dbus_recv() was recently split to dbus_recv_header() + dbus_recv_data(), according to our earlier discussion, which happened to match a much older feature request from Benjamin Moody. The corresponding commit is still part of the experimental branch for now (this particular commit wasn't updated beyond the commit message for weeks, though), but won't be for too long;
* even if you implemented a brand-new protocol, libticalcs contains support for 4 protocols: 3 official protocols unofficially dubbed DBUS, DUSB and NSP, and libticalcs' specific ROM dumping protocol.

Even in user-space (libusb-win32 / libusb), Windows USB drivers are such a pain for users (filter driver, ever more offensive signing requirements; a Windows expert and libwdi could help ease the pain) that for KnightOS users' sake, even a brand-new code base really ought to be based on at least the drivers provided alongside libticables :)


We use something similar to the DBus protocol, but with our own protocol on top of that which TiLP would have to implement. Right now I implemented that protocol myself in iofs, but iofs is more proof of concept than shippable code so I imagine that can change in the future. I definitely want to use libticables on all platforms for this (iofs does already use libticables).
Title: Re: KnightOS Updates
Post by: SirCmpwn on January 31, 2016, 09:56:42 pm
(https://sr.ht/YNJL.png)

I was going to work on I/O support today, but got off track when I started working on improvements to z80e's debugger instead. Now it can load scas object files and show you the source maps (even in the context of a relocatable KnightOS thread)! It also loads up all the symbols for you to debug with. Prior to this change, you'd just see a straight up disassembly during debugging sessions with no context from your code. I also spent some time working on kcc to try and make it possible to view C source code in the z80e debugger like this, but that's going to require more effort than I was willing to put in today (just some refactoring in scas).
Title: Re: KnightOS Updates
Post by: Max Leiter on February 01, 2016, 06:06:43 pm
If you're interested in trying out the z80e updates, I made a PR to update the install-sdk script yesterday. You can find SDK setup instructions here: http://wiki.knightos.org/index.php/Tutorials/General/KnightOS_SDK
Title: Re: KnightOS Updates
Post by: SirCmpwn on February 04, 2016, 04:58:47 am
(https://sr.ht/Cnwm.jpg)
Title: Re: KnightOS Updates
Post by: Max Leiter on February 04, 2016, 05:13:59 am
For anyone curious, the current source for @SirCmpwn 's program is available here: https://gogs.sr.ht/SirCmpwn/iochat
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on February 04, 2016, 05:15:23 am
That's a good job :)
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 03, 2016, 01:59:47 pm
Hey @Lionel Debroux, I'm working more on iofsd and I'm running into some issues.

(https://sr.ht/9tOG.png)

This is connected to a real calculator. The protocol is DBUS, first the PC sends a packet saying "list /bin". The calc sends a preamble with the number of entries, then that many packets, each with the name and type of one entry. z80e now has support for the link assist and I can confirm that it works perfectly when emulated.

I'm thinking about adding a checksum to each packet to improve the reliability of this. Do you think using libticalc's dbus functions would provide any benefit to reliability as well for the PC side? Also would like to hear your advice in general on this subject.
Title: Re: KnightOS Updates
Post by: Lionel Debroux on March 03, 2016, 04:05:20 pm
QuoteI'm thinking about adding a checksum to each packet to improve the reliability of this.

Yup, on DBUS, you should definitely use a checksum in each packet, like TI's OS for the TI-Z80 and TI-68k series do.

QuoteDo you think using libticalc's dbus functions would provide any benefit to reliability as well for the PC side?

Yup. Using dbus_recv_header() and dbus_recv_data(), which I split out of dbus_recv() a while ago because of the KnightOS use case in this topic (and later found to be a much older idea of Benjamin buried deep down into the todo/wish list), buys you checksum and progress information for the data part of the packet, you don't have to reinvent these on your side :)

In case you want to define your own commands, I'm now thinking that dbus_recv() could be further generalized by replacing the hard-coded switch statement by:
* a uint8_t * pointing to a list of command IDs considered to yield no data part after the header, plus a uint8_t length for said array;
* a uint8_t * pointing to a list of valid command IDs for a data part, plus a uint8_t length for said array
and binary search through these lists to classify packets.
Even if there's precedent for many-args functions in libticalcs (dusb_cmd_s_var_modify), I'd rather avoid adding a 9-argument variant of dbus_recv(): the lists of allowed command IDs could be passed out of band on a per-handle basis by a new API.
I'll write that idea down into the todo/wish list, for a later development cycle because Benjamin and I are currently working on closing down the current cycle. However, if you feel that such a feature is useful to you, and you'd like to take advantage of it in the near future, we could find an agreement.
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 03, 2016, 04:12:01 pm
Quote from: Lionel Debroux on March 03, 2016, 04:05:20 pm
Yup, on DBUS, you should definitely use a checksum in each packet, like TI's OS for the TI-Z80 and TI-68k series do.


Huh, somehow I didn't understand that this was part of the DBUS protocol. How does that work, protocol-wise? Is there a good spec I should read? How does it handle retries?

Quote from: Lionel Debroux on March 03, 2016, 04:05:20 pm
Yup. Using dbus_recv_header() and dbus_recv_data(), which I split out of dbus_recv() a while ago because of the KnightOS use case in this topic (and later found to be a much older idea of Benjamin buried deep down into the todo/wish list), buys you checksum and progress information for the data part of the packet, you don't have to reinvent these on your side :)

In case you want to define your own commands, I'm now thinking that dbus_recv() could be further generalized by replacing the hard-coded switch statement by:
* a uint8_t * pointing to a list of command IDs considered to yield no data part after the header, plus a uint8_t length for said array;
* a uint8_t * pointing to a list of valid command IDs for a data part, plus a uint8_t length for said array
and binary search through these lists to classify packets.
Even if there's precedent for many-args functions in libticalcs (dusb_cmd_s_var_modify), I'd rather avoid adding a 9-argument variant of dbus_recv(): the lists of allowed command IDs could be passed out of band on a per-handle basis by a new API.
I'll write that idea down into the todo/wish list, for a later development cycle because Benjamin and I are currently working on closing down the current cycle. However, if you feel that such a feature is useful to you, and you'd like to take advantage of it in the near future, we could find an agreement.


Right now the way the kernel implements DBUS is that it receives the header and then calls a registered handler based on the machine ID, and passes it the header. The handler is expected to return the number of bytes of data the kernel should receive to finish the packet. This design allows you to use the packet length field for arbitrary data so long as your handler recognizes that and tells the kernel to receive 0 bytes (so the kernel never actually reads the length). This is necessary because that's how the TI keyboard sends packets (with scancodes in the length field).

I think I would like to leave the decision to receive more data (and how much data) up to the user of libticalcs, rather than up to libticalcs itself.
Title: Re: KnightOS Updates
Post by: Lionel Debroux on March 03, 2016, 04:44:45 pm
QuoteHuh, somehow I didn't understand that this was part of the DBUS protocol. How does that work, protocol-wise?

Just like it does in files on the computer side: 2 trailing bytes containing the checksum of the data part (not the header part). See https://github.com/debrouxl/tilibs/blob/experimental/libticalcs/trunk/src/dbus_pkt.c .

QuoteIs there a good spec I should read?

The linkguide is less up to date than the source code anyway. See also the header file with machine IDs and command IDs + descriptions thereof, https://github.com/debrouxl/tilibs/blob/experimental/libticalcs/trunk/src/dbus_pkt.h .

QuoteHow does it handle retries?

Good question. TILP tends to yield a full error in such cases, but other clients may wish to behave differently.

QuoteI think I would like to leave the decision to receive more data (and how much data) up to the user of libticalcs, rather than up to libticalcs itself.

Yup, providing clients the ability to make their own decisions by providing independently the two phases of dbus_recv() was the motivation outlined by both yourself, and earlier Benjamin. The corresponding commit currently is the second from the rewritable "experimental" branch on top of the never-rewritten "master" branch. As such, it will pretty much be part of the master branch upon the next forward of that branch, and in fact, I'm unlikely to rewrite such an old commit :)
The note at the end of my previous post was a wild idea I just had looking at the code, wrote down here and into the wish list.
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 03, 2016, 04:50:18 pm
Quote from: Lionel Debroux on March 03, 2016, 04:44:45 pm
QuoteHuh, somehow I didn't understand that this was part of the DBUS protocol. How does that work, protocol-wise?

Just like it does in files on the computer side: 2 trailing bytes containing the checksum of the data part (not the header part). See https://github.com/debrouxl/tilibs/blob/experimental/libticalcs/trunk/src/dbus_pkt.c .

Ah, that's easy to implement.

Quote from: Lionel Debroux on March 03, 2016, 04:44:45 pm
QuoteHow does it handle retries?

Good question. TILP tends to yield a full error in such cases, but other clients may wish to behave differently.

From what I can tell (see screenshot in previous post), errors are so common that a retry will definitely be necessary. They're so common, in fact, that I'm seriously concerned about things like the header getting mangled frequently, which is difficult to recover from. I'll make up some kind of protocol to handle this. Do you know what I might be doing that could lead to it being so unreliable? I'm just using the link assist. Maybe I should play with the signaling rate (http://wikiti.brandonw.net/index.php?title=83Plus:Ports:09).

Quote from: Lionel Debroux on March 03, 2016, 04:44:45 pm
QuoteI think I would like to leave the decision to receive more data (and how much data) up to the user of libticalcs, rather than up to libticalcs itself.

Yup, providing clients the ability to make their own decisions by providing independently the two phases of dbus_recv() was the motivation outlined by both yourself, and earlier Benjamin. The corresponding commit currently is the second from the rewritable "experimental" branch on top of the never-rewritten "master" branch. As such, it will pretty much be part of the master branch upon the next forward of that branch, and in fact, I'm unlikely to rewrite such an old commit :)
The note at the end of my previous post was a wild idea I just had looking at the code, wrote down here and into the wish list.

Maybe I'm not understanding this. Is dbus_recv/dbus_send shipped with libticalcs right now? Or do I have to build this experimental branch to use it?
Title: Re: KnightOS Updates
Post by: Lionel Debroux on March 03, 2016, 04:58:26 pm
QuoteDo you know what I might be doing that could lead to it being so unreliable?

Nope, I don't know.

QuoteIs dbus_recv/dbus_send shipped with libticalcs right now?

Sure. dbus_recv() and dbus_send() have been directly exported by libticalcs since commit f746457ff6afba7d6211faa009b7594b395c12a2 , Thu Jun 14 06:21:20 2012 +0000, and are therefore part of the libti* corresponding to TILP II 1.17 released 2013/03/31.

QuoteOr do I have to build this experimental branch to use it?

You need to build the experimental branch (for now, soon the master branch) to use dbus_recv_header() and dbus_recv_data(), which is a '2015 change and therefore not part of any released libti* version at the time of this writing.
The usual https://ti-pla.net/tilpinst build script can be requested to build the experimental branch by setting the appropriate environment variable.
Title: Re: KnightOS Updates
Post by: SirCmpwn on March 03, 2016, 06:52:42 pm
Cool, thanks a lot for the help!
Title: Re: KnightOS Updates
Post by: Max Leiter on June 30, 2017, 05:01:03 pm
Figured I'd post what's happened in the past few months:

- SirCmpwn (with a few bugfixes by me) just released SDK v2 (https://github.com/KnightOS/sdk). Notable features include being able to use local packages and an offline cache.
- Decimal floating point support has landed in the kernel! This was a major issue with KOS until a (seemingly) random developer opened a PR here (https://github.com/KnightOS/kernel/pull/179). While certain math operations haven't been implemented just yet, they're being worked on, and once they are SirC's next side-project will most likely be a functioning calculator. I'll release C bindings for the floating point routines once I have some more free time. You can find the math routines here (https://github.com/KnightOS/kernel/blob/master/src/02/fp-math.asm).
- z80e (z80 emulator in C) now compiles on non-linux platforms. Commit: here (https://github.com/KnightOS/z80e/commit/0c3721e745039d896b2006ab7587f61a4b0c31a0). Additionally, @Snektron fixed some errors   and improved windows support here (https://github.com/KnightOS/z80e/pull/43).
Title: Re: KnightOS Updates
Post by: Streetwalrus on June 30, 2017, 06:51:14 pm
This is some really nice stuff, kinda sad that development is slow as ever though.
Title: Re: KnightOS Updates
Post by: Snektron on July 01, 2017, 12:42:03 am
I actually got everything from the SDK to work, even the tool that converted a folder structure into a knightos filesystem. It took a damn amount of research to find out how to tell if a folder is a symlink in windows <_<. I dont think i ever pushed it though...
Title: Re: KnightOS Updates
Post by: SirCmpwn on July 01, 2017, 07:13:48 pm
(https://sr.ht/PUks.png)
Title: Re: KnightOS Updates
Post by: DJ Omnimaga on July 02, 2017, 04:19:13 pm
Glad to see this project is continuing. I was wondering what had happened to it
Title: Re: KnightOS Updates
Post by: Max Leiter on July 08, 2017, 09:15:48 pm
SirCmpwn just posted a blog post regarding SDK v2 here (http://www.knightos.org/2017/07/08/SDK-v2.html)
Title: Re: KnightOS Updates
Post by: Max Leiter on October 24, 2018, 01:39:17 pm
Quick status update in case anyone is interested:

We upgraded our C compiler (KCC) to match the upstream (SDCC), including many bugfixes and optimizations: https://github.com/KnightOS/kcc/pull/11
We've also been working out numerous bugs since the SDK v2 rewrite: https://github.com/knightos/SDK
Additionally, continuous integration is slowly being set up for the projects on https://builds.sr.ht

If you're interested in development and want to come help out or stay up-to-date, feel free to hop into #knightos on freenode.
Title: Re: KnightOS Updates
Post by: DarkestEx on April 18, 2019, 02:57:35 pm
I'm curious how this will continue. I have been watching for a long time now :)