Started by Vijfhoek, March 22, 2015, 04:29:22 pm
0 Members and 1 Guest are viewing this topic.
QuoteIt'd also probably be pretty easy to add KnightOS support to TiLP.
Quote from: ben_g on January 25, 2016, 08:39:01 pmWill 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!
Quote from: Lionel Debroux on January 25, 2016, 08:47:08 pmQuoteIt'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
QuoteI'm thinking about adding a checksum to each packet to improve the reliability of this.
QuoteDo you think using libticalc's dbus functions would provide any benefit to reliability as well for the PC side?
Quote from: Lionel Debroux on March 03, 2016, 04:05:20 pmYup, on DBUS, you should definitely use a checksum in each packet, like TI's OS for the TI-Z80 and TI-68k series do.
Quote from: Lionel Debroux on March 03, 2016, 04:05:20 pmYup. 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 arrayand 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.
QuoteHuh, somehow I didn't understand that this was part of the DBUS protocol. How does that work, protocol-wise?
QuoteIs there a good spec I should read?
QuoteHow does it handle retries?
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.
Quote from: Lionel Debroux on March 03, 2016, 04:44:45 pmQuoteHuh, 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 .
Quote from: Lionel Debroux on March 03, 2016, 04:44:45 pmQuoteHow does it handle retries?Good question. TILP tends to yield a full error in such cases, but other clients may wish to behave differently.
Quote from: Lionel Debroux on March 03, 2016, 04:44:45 pmQuoteI 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.
QuoteDo you know what I might be doing that could lead to it being so unreliable?
QuoteIs dbus_recv/dbus_send shipped with libticalcs right now?
QuoteOr do I have to build this experimental branch to use it?
CodeWalr.us 2.0 © 2019, DJ Omnimaga & Juju
Page created in 0.047 seconds with 36 queries.