Sorry that subject line was a bit obtuse, I meant what mods might be needed to upgrade the USB 2.0 driver to utilize 3.0/3.1 hardware.

OK, we have discussed this as a possibility.
What would be the next step, picking out a target with NEC 2.0 compatible legacy functions?
Also, does anyone know who wrote the USB 2.0 drivers?

[ Edited by Jim 28.05.2018 - 17:18 ]

> does anyone know who wrote the USB 2.0 drivers?

Initial EHCI support for MorphOS 1.x (ehciusb.device) was created by Nicolas Det:

https://morph.zone/modules/news/article_storyid_1235.html

For MorphOS 2.0, UHCI/OHCI/EHCI support was reimplemented from scratch into pciusb.device.

pciusb driver was written by platon42 with later contributions by cyfm and bigfoot.

What would be the point of USB3 before going NG?

Quote:

Other than PCI-E systems can use them?
Although, yes, that's a limited number of users.
And they still have PCI slots if a USB 2.0 card if needed.

Then again, the same could be said for the majority of the new video cards Mark has added to the
support list. Why support them if only a few can use them?

Anyway, I'm keeping a couple of PPCs systems with the last updates as a high water mark for what happens on this ISA.

And its been almost twelve years since USB 2.0 support was released in beta form.
USB 3.0 has been a standard for almost ten years.
Just because our PCI based systems can't handle that transfer rate (actually the 64 bit PCI and faster PCI-X slots might be able to, but I haven't seen the hardware).
Why not support the cards?

Also you're the first developer I've heard use that term, NG, Jacek.
I kind of like the idea of MorphOS NG (or whatever its going to be called). NG, NG, heh.

Anyway, development hasn't stopped, although the next move would normally be a bug fix.

And actually, what I was suggesting was merely adding USB 2.0 support for some available USB 3.0 cards (they're easier to source than USB 2.0 cards for PCI-E).

It's possible that Renesas USB 3.0 controllers might be backward compatible with our NEC drivers with a limited amount of tweaking).

Nowhere near as big a project as Mark's Javascript JIT that he just recommitted to, and both ought to be pretty straight forward ports to X64.

And it could provide a logical stepping stone, even if full 3.0/3.1 operation isn't implemented until the ISA switch.

Asking why not is a little like asking "Why are you still coding for that ISA?", as I notice you are.

I guess its just a "throw it up in the air and see who shoots it down" kind of question.
Sorry for the disjointed reply.

[ Edited by Jim 28.05.2018 - 23:13 ]

> our PCI based systems can't handle that transfer rate
> (actually the 64 bit PCI and faster PCI-X slots might
> be able to, but I haven't seen the hardware).

Indeed, I couldn't find any USB3 cards for 64-bit PCI or PCI-X (while there are some for 32-bit PCI).

> Mark's Javascript JIT that he just recommitted to, and
> both ought to be pretty straight forward ports to X64

I doubt a JavaScript-to-PPC JIT compiler can be ported (rather than rewritten from scratch) to any other ISA. Besides, there'd be surely no need for another JavaScript-to-x86(_64) JIT compiler when there are so many already (like for instance the one used in Odyssey on AROS/x86).

>I doubt a JavaScript-to-PPC JIT compiler can be ported (rather than >rewritten from scratch) to any other ISA. Besides, there'd be surely no >need for another JavaScript-to-x86(_64) JIT compiler when there are so many >already (like for instance the one used in Odyssey on AROS/x86).