Wait a minute, can I access the second boot page? I can practically read hex...

Oh, yeah, I was starting to write up documentation of the USB ports at one point.  Then I got distracted by something else.  That seems to happen a lot.

Yeah, I have the USB8X source code lying around, but it depends heavily on TIOS routines.  I would also probably write most of that stuff from the ground up, considering that it has no support for hubs, and is a bit outdated.

USB8x doesn't actually use the OS routines for very much - there's not very much interesting stuff the OS routines can do.  The main thing USB8x relies on the OS for is USB interrupt handling, and that's because there isn't any other choice if you're going to use IM 1.  (But that should be pretty easy to re-implement yourself if you want to.)

It does have some basic hub support - if a hub is connected, AutoSetup will turn on the ports one by one and try to connect to the first non-hub device it finds.  I'm not sure how much more is physically possible, as I'm not sure that there's any way to talk to, or listen to, more than one peripheral device at a time.  But I haven't tested anything to do with hubs myself.

Well, we know almost nothing about those ports.  We pretty much have to use TI's routines, which I can't steal and put in KnightOS unless I'm clever about it.  With the information we have, I could probably manage unit-to-unit file transfers, but for advanced stuff like unit-to-PC and peripherals such as flash drives we need more documentation.

Which ports are we talking about here?

And talking to a PC is easier than talking to another calculator: in the former case you only have to deal with peripheral mode, whereas in the latter case you need both host and peripheral modes.  And maybe SRP and HNP.

Oh, I see.  You mean going around behind the USB controller's back, as it were, and controlling the data lines individually.  I don't know if that's even possible - as far as I know, the set of low-level operations that the CPU can control is pretty limited.

And it wouldn't be compatible with the OS or with standard USB devices, and you'd be relying on the least-well-understood parts of the hardware, and it would be much slower than using the USB protocol, but who knows?  Maybe it's worth a try.  I suspect that using the USB protocol would be easier and more rewarding, though.

After seeing USB and hooks documentation added (I could have wrote the hooks page if I had that idea earlier, fortunately someone had the idea) I added some interesting stuff and updated some things... Looking at WikiTI with fresh eyes again makes occur some ideas to add.

Would you look at that. Someone made a hooks page.

Since it is a wiki, feel free to fix any mistakes I made.

(This marks the first time that I linked the word "that")

Nice. I love wikis

That's great to hear.  WikiTI is a great resource already, but there's so much more stuff that could be documented.  It's a shame that it's been inactive lately.  I'll try to do my part.

One day I really should enhance the TI community history part of the site, such as individual teams, and maybe have an article talking about which forum were active over the year and the major releases and events.

Yeah it's cool that every single bit of USB stuff people know is being put together in one place. I am wondering if this wiki could explain the drastic increase in ASM program quality over the last few years? It has been around for 4 years, but back then it often got hacked or spammed by bots so people avoided it. Now it's solved and it seems to get more popular.