This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Show posts MenuQuote from: Lionel Debroux on March 03, 2016, 04:44:45 PMAh, that's easy to implement.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 .
Quote from: Lionel Debroux on March 03, 2016, 04:44:45 PMFrom 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.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.
Quote from: Lionel Debroux on March 03, 2016, 04:44:45 PMMaybe 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?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.
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.
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.
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!
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
Quote from: DarkestEx on January 25, 2016, 05:19:00 PMhow portable is the Knight OS kernel?
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?
QuoteQuoted from Github
This kernel adds experimental I/O support.
Features
- TI link port protocol support
- Concurrent link port access
- TI Keyboard support
New syscalls:
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
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?
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.
Page created in 0.054 seconds with 26 queries.