KnightOS Updates

u/SirCmpwn 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 support

New syscalls:

ioSendBuffer
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

Downloads

Headers
kernel-headers-0.6.11 (PKO version)

Kernels
TI-73 TI-83+ TI-83+ SE TI-84+ TI-84+ SE TI-84+ CSE

KnightOS running on kernel 0.6.11: Download upgrade files

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.

u/Ivoah 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?

u/SirCmpwn 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 cs 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.

u/SiphonicSugar January 25, 2016, 03:45:43 AM

Wait, does this completely replace the operating system?

u/Max Leiter 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.

u/SiphonicSugar January 25, 2016, 04:19:59 AM

And can it calculate math problems just like the regular OS?

u/Max Leiter 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.

u/SiphonicSugar 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...

u/SirCmpwn 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:

u/DarkestEx 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.

Last Edit: January 25, 2016, 05:21:57 PM by DarkestEx

u/SirCmpwn 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.

u/DarkestEx 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.

u/novenary 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.

Last Edit: January 25, 2016, 07:38:22 PM by Streetwalrus

u/SirCmpwn January 25, 2016, 08:29:26 PM

It'd also probably be pretty easy to add KnightOS support to TiLP.

u/ben_g 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!