Cool, thanks a lot for the help!

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.

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?

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.

Hey @Lionel Debroux, I'm working more on iofsd and I'm running into some issues.



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.

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).

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).

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

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.

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:

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.

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.

FWIW you can ask kcc to use C99 mode, but it's not entirely implemented.

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.