Aros/Platforms/AROS USB support

Host Adapter USB1 OHCI UHCI USB2 EHCI USB3.0 USB3.1 xHCI USB4 thunderbolt
Please let us know any mistakes or any information to be added, use Prefs/Trident to confirm Vendor and Product IDs Please chat at AROS World

USB transfers can be of the type control, isochronous, interrupt, or bulk.


 * Control    -
 * Interrupt  - Midi 2.0
 * Bulk       - Midi 1.0 ( 'send my data when you can' )
 * Isochronous - USBAudio, Webcams, etc (wip)

IsoChronous code is already in place in poseidon.library BUT transfers are not queued to be later rerouted in the host driver code (needs to be written for each host OCHI UCHI EHCI etc). There seems to be 2 types of isoc transfers that can be used by Poseidon. One is just the normal isoc transfer and the other is realtime implementation of isoc transfer. Setting up the isoc transfer pipe might differ on those two and the driver code might be different as well.

For isoc transfer there needs to be a scheduler that makes sure no isoc transfers are dropped (in or out) and that they happen at the right time. It all gets difficult as the device making use of the isoc transfer may be at any point on the device tree. One needs to calculate the USB bandwidth etc. and base the scheduler on that and other factors.

Poseidon controls the driver and device tree and it provides an API to communicate with the USB devices. Poseidon really doesn't care much about what sort of transfer pipe is opened or used, it only provides the means to do so and forwards the iorequests to the correct driver. Poseidon code is the higher level code for USB communication and drivers are of course the lower level one.


 * Best Hardware - NEC Chipset (OHCI + EHCI), Intel Chipset (UHCI + EHCI),
 * Next Best Set - General OHCI, SIS (OHCI + EHCI),


 * Early support - XHCI USB3.0, USB3.1 & gen 2, USB4 Type-A Type-B Type-C


 * Buggy Chipset - [ Early AMD OHCI], ALi OHCI, VIA UHCI, Nvidia OHCI & EHCI,

OHCI USB 1.1 USB-IF sanctioned standard and hardware physical form removed 2010 replaced with virtual emulation

UHCI USB 1.1 Intel standard and since 2009, no hardware support only virtual (P55 chipset)

EHCI USB 2.0 The USB-IF insisted on only one implementation of EHCI but it creates 4 virtual hcd to cover USB1.1 support. The virtual HCD on Intel and VIA EHCI controllers are UHCI. All other vendors use virtual OHCI controllers. Hardware EHCI USB2.0 ended in most chipsets in 2014/5 and is now virtual through most newer USB3.0 chipsets

xHCI eXtensible USB 3.0 SuperSpeed SS (Speed 5Gbit/s 3.1 gen 1)

USB 3.1 (power up to 100W and data 10Gbit/s USB 3.2 gen 2 - USB-A Full size plug - USB-B micro USB size - USB-C reversible)

USB 3.2 (power up to 100W and data 20Gbit/s gen 2x2 - USB-A Full size plug - USB-B micro USB size - USB-C reversible)

USB 4 (40Gbps thunderbolt, pcie 3.0 tunnelling, )

Keyboard
Cherry MX Blue have tactile feedback with a click (noisy); good for typing. Cherry MX Brown are in between Blue and Red in style and tactile; Cherry MX Clear switches have soft tactile feedback (with no click). Cherry MX Black are linear switches (no feedback); good for gaming. Cherry MX Red are linear (less noise no click) but more squishy;

Gateron Yellows KS-3, KS-3x47 or better Pros have a milky top and black bottom and linear

Mouse
if the USB mouse is non-functional put a USB pendrive in before or add the following to user-startup in s drawer/folder/directory

sys:prefs/trident NOGUI > NIL:

Gamepad
Controllers have mostly decided that the left analog joystick is keyboard equivalent of WASD and right joystick is your mouse. You also have 2 bumpers above the triggers. Shoot could be right trigger (so it doesn't involve taking your thumb off the right joystick). Face buttons for reloading or jump or other non-critical functions. Crank up the sensitivity and practice.

Testing can be done with the TRIDENT Prefs, html5, html5, or Tester

Xinput Xbox Style Plugin
2018 extension added originally called AROSx


 * 1) ifndef AROSX_LIBRARY_H
 * 2) define AROSX_LIBRARY_H


 * 1) include 


 * 1) define AROSX_CONTROLLER_TYPE_UNKNOWN 0x00
 * 2) define AROSX_CONTROLLER_TYPE_GAMEPAD 0x01


 * 1) define AROSX_GAMEPAD_DPAD_UP         0x0001
 * 2) define AROSX_GAMEPAD_DPAD_DOWN       0x0002
 * 3) define AROSX_GAMEPAD_DPAD_LEFT       0x0004
 * 4) define AROSX_GAMEPAD_DPAD_RIGHT      0x0008
 * 5) define AROSX_GAMEPAD_START           0x0010
 * 6) define AROSX_GAMEPAD_BACK            0x0020
 * 7) define AROSX_GAMEPAD_LEFT_THUMB      0x0040
 * 8) define AROSX_GAMEPAD_RIGHT_THUMB     0x0080
 * 9) define AROSX_GAMEPAD_LEFT_SHOULDER   0x0100
 * 10) define AROSX_GAMEPAD_RIGHT_SHOULDER  0x0200
 * 11) define AROSX_GAMEPAD_A               0x1000
 * 12) define AROSX_GAMEPAD_B               0x2000
 * 13) define AROSX_GAMEPAD_X               0x4000
 * 14) define AROSX_GAMEPAD_Y               0x8000

struct AROSX_GAMEPAD { ULONG  Timestamp; UWORD  Buttons; UBYTE  LeftTrigger; UBYTE  RightTrigger; WORD   ThumbLX; WORD   ThumbLY; WORD   ThumbRX; WORD   ThumbRY; };


 * 1) define AROSX_EHMB_CONNECT   0x00
 * 2) define AROSX_EHMB_DISCONNECT 0x01
 * 3) define AROSX_EHMF_CONNECT   (1L<<AROSX_EHMB_CONNECT)
 * 4) define AROSX_EHMF_DISCONNECT (1L<<AROSX_EHMB_DISCONNECT)

struct AROSX_EventHook { struct Node        eh_Node; struct MsgPort    *eh_MsgPort; ULONG              eh_MsgMask; };

struct AROSX_EventNote { struct Message     en_Msg; ULONG              en_Event; APTR               en_Param1; APTR               en_Param2; };


 * 1) endif /* AROSX_LIBRARY_H */

Gamepad Joypad Adapters

 * Most adapters will work in most OS's without installing a driver. Special functions needing drivers will be noted.
 * Some adapters do not work with some dance pads because of voltage issues. Other adapters map the dancemat arrows as axes and not as buttons, causing problems.
 * If using an adapters should be compatible with original PlayStation PS/Xbox Xbox/GameCube GC /Dreamcast DC/Sega Saturn SS gamepads.


 * Metal dance pads with LEDs - My My Box Blue Shark (Nexen), Cobalt Flux (CF) (Let's Groove), Red Octane Afterburner, TX-2000, Logic3 (Dance Dance Dance), Gamerose (Stay Cool),
 * Hard foam mat - Mayflash FutureMax Deluxe 3 in 1 Ignition, Gamerose (Stay Cool), TrinPad orange,
 * Soft foam mat - Logic3 (PS420N), Positive Gaming Impact, Gamerose Miss Daisys Naki (Stay Cool), Pelican, MadCatz


 * PS1 PS2 PS3 PS4 flex ribbon big source of button/trigger issues with all controllers
 * PS2 Phat KSA1Q40A (Board), SA1Q33A (Membrane) SCHP-10010 H
 * PS2 SA1Q42A SCHP-10010 A
 * PS2 SA1Q43-A SCHP-10010 H

The primary axes are either the Control Pad or the left stick. Buttons come in a rough order: face buttons, then shoulder buttons, then Select and Start, then buttons under sticks, and finally Control Pad directions if not assigned to a hat. But the order and number of buttons within a category are unpredictable, as is which button the user expects to use for each action.

Just plug in your digital/analogue joystick or gamepad into USB port. The device will be handled by Poseidon USB stack. Poseidon is the USB stack with Trident adding a GUI (graphical user interface) prefs.

the context sensitive page would come up right on pressing the help key inside the relevant window. The manual is in this archive, just in case it isn't in SYS:Locale/Help


 * How to change joystick mode to analogue?

By default a connected USB joystick emulates Amiga digital joystick. To change this behaviour so that the joystick is presented as analogue you need to use Trident preferences application (System:Prefs/Trident).

Open Trident and go to Devices on the left hand side (mouse click once on it). Select your controller from the list to the right and then click on Settings button below. This will open a new window. On the "General" tab find the "Lowlevel Library Joypad Emulation" section near the bottom. Find ports which are set to "Merge with USB" or "Override with USB" and change them to "Analogue Hack".

Please note that analogue joystick support is an extension of original Amiga functionality, thus an Amiga application must be explicitly written to use it. AROS SDL library uses this functionality, thus all SDL applications that use joystick, can use the analogue joystick feature.

The HID class has several options how to handle the input data:


 * Don't touch: The movement and button data for is not modified by the hid class. This is the default for the ports 0, 2, and 3.


 * Overwrite with USB: This will kill the original  data  that  might  had  come  from  the internal  ports  and  overwrites it with the joypad data for this USB interface. Note well: If you have multiple  joypads  connected,  take care  which setting you have selected for each port, because only the last interface with this option will actually send the joypad data to the game.


 * Merge with USB: This option merges the input data of the lowlevel.library  with  the USB  stream. This only works, if the connected device on the original Amiga  ports  is  NOT  a  mouse  (because  then   the   streams   are incompatible).  Merging  should  be  the preferred method, because it leaves the original joysticks working.


 * Disable: Turns off the port for the application.


 * Analogue Hack: Tells Poseidon to force reporting of  analogue  data  at  the  port. Please  note  that  this only works with programs that understand the analogue  data,  because  it's   an   extension   to   the   original lowlevel.library   standard   made  by  Commodore.  If  you  want  to incorporate this feature in your software, just contact me and I will send you the necessary information.


 * Rumble Port: As addition to the analogue data, the HID class supports  applications and  games  that want to utilize a rumble pack or force feedback motors in the gamepads. This field selects to  which  lowlevel  port  the  hid device responds, when attempting to use the rumble pack. Normally, this corresponds to the port that has  been  set  in  the  actions  for  the joypad.


 * How to change joystick port assignment?

The low level  library  supports up to four ports. Port 0 is usually used by the mouse, port 1 is the standard port for joysticks/joypads. By default a connected USB joystick is present in Port 1. To change its location to Port 0 you need to use Trident preferences.

Open Trident and go to Devices window. Select your controller from the list and then click on Settings button. This will open a new window. On the "General" tab find the "Lowlevel Library Joypad Emulation" section. Port 1 should be set as either "Merge with USB" or "Override with USB". Change this setting to "Don't touch". Change Port 0 setting to "Merge with USB".

Go to "Actions" tab. In the "Reports and collection" select first entry named "Joystick". in the "Usage items" select "X axis". Go to "Performed actions" area. On the left there will be a list of triggers. Each of them should have (port1) in their params. Click on the first trigger and using buttons to the right of the list change port1 into port 0. Repeat this for all triggers and for all items on "Usage items" list.


 * How to make joystick simulate keyboard keys?

With Poseidon it is possible to make the joystick simulate the keyboard pressings. This might enable using joystick for playing games which only have keyboard support. This feature is configured in Trident preferences.

Open Trident and go to Devices window. Select your controller from the list and then click on Settings button. This will open a new window. Go to "Actions" tab. On the right top window select X axis. On the left bottom list select an entry "Digital Joystick, Push left(port 1)". On the panel to the right change "Digital joystick" into "Raw Key". A list of keys will be displayed. Select key you wish to send. Repeat the same procedure for "Digital Joystick, Release left (port 1)" option but this time check "Send key up even instead of key down". Open shell and move your joystick to the left - your selected letter should appear in the shell.

And you should see some axis activity in "Usage items" when you move the analog stick
 * Analogue in Trident Prefs
 * Open the Trident USB Prefs -> Devices -> Select your joypad -> Settings button -> Action TAB
 * See some "axis" listed under "Usage items" in the top right of the window. They are your analog stick(s)
 * Check [x] Track Incoming Events which is half way down the window on the left


 * Actions

HID class item -> Settings -> HID Class Window -> Action Tab -> Action handling area

Reports and collections -> Usage Items -> Performed actions

Qualifier keys are *special*. You don't only need to create the actual keypress but also modify the qualifiers. Go to the keyboard panel and find the windows menu key by enabling key tracking and pressing the windows menu key. Then assign the right amiga key to it.

Go to the actions panel and find the right amiga key (it's called "Keyboard right GUI"). Remember the actions stored there, best write them down in exact order. Then delete them. Find the windows menu item and add the missing qualifier action. Be sure the parameters are exactly the same and the order is right.

Set them to Raw, then assign an up and down button for each character, etc. when you change the settings to RAW so you can assign keyboard strokes. it will always say, KEYDOWN or what ever on the left, it never provides and option for key release.

The problem still remains though that if I try to assign the Directional Pad (Hat) to Arrow Keys, that things will get screwed up and you either can not move with the directional PAD (HAT), or movements are assigned to the Left Analog, and do not work as they should, it's as if the right and down arrow keys are ALWAYS On, regardless of the fact that I did indeed assign a Key release command to each input.

check that by pressing analog directions and see the current values, and the thresholds configured in poseidon to bind them to left/right/up/down.

misconfigured too much stuff in the HID settings, you can always go in poseidon->config list entry and delete the config item related to your device (or the HID class setting itself), back to basics.

Open Trident Prefs and click on the Devices option in the left hand window. Click with the mouse once on your gamepad choice on the right hand side and again on the Settings button below. In the new window, select the General TAB and half way down on the right there is an "Open Now" button in the section "HID output control window". Clicking on that button opens another window (HID Control) with sliders for the two rumble engines inside the controllers and you can test if they work. Sometimes clicking that button does nothing, other times it will open the window and say nothing is detected. The leftmost two sliders do nothing, the third one has a large rumble effect, and the fourth one has a small rumble effect.
 * Rumble in Trident Prefs

Graphic Drawing Tablet
There is a standard in HID for tablets possibly mouse type. If the tablet is HID conforming in that sense, it should work. Aiptek does a fairly good job at this. The other competitor, Wacom, didn't pay too much attention to this and simply adapted their legacy serial protocol into HID in a very awkward way. Older Wacom tablets have worked with the special support in the HID class, but not the more recent ones.

to use graphic tablets fully, applications need to be written that make use of the AmigaOS NewTablet events


 * Entry level - A6 (6x4) work area
 * Medium A5 (6x8) A4 (10x7) size  (recommended but only a few ie years 2000 to 2003 models supported)
 * Semi Pro A3 (12x9)
 * Pro Cintiq


 * 2005/6 Some support added for Wacom tablets
 * 2008 Wacom's patent on battery free pens expires

Tablet has a squared lines of wires which induce a current into the pen which is then detected by the metal grid in the tablet pad. Tablets report pressure (and tilt on expensive models) and are absolute pointing devices (put the pen at the top left and the mouse pointer will go to the top left of the screen). Graphic drawing area, what keys, report rate, resolution lpi lpmm, accuracy, pressure levels (may come from the app), origin position,

Wacom tablets use electromagnetic resonance technology. Since the tablet provides power to the pen through resonant inductive coupling, no power is required for the pointing device. As a result, no batteries are inside the pen (or the accompanying puck), making them lighter and slimmer.

Under the tablet's surface (or LCD in the case of the Cintiq) is a printed circuit board with a grid of multiple send/receive coils and a magnetic reflector attached behind the grid. In send mode, the tablet generates a close-coupled electromagnetic field (also known as a B-field) at a frequency of 531 kHz. This close-coupled field stimulates oscillation in the pen's coil/capacitor (LC) circuit when brought into range of the B-field. Any excess resonant electromagnetic energy is reflected back to the tablet. In receive mode, the energy of the resonant circuit’s oscillations in the pen is detected by the tablet's grid. This information is analyzed by the computer to determine the pen's position, by interpolation and Fourier analysis of the signal intensity.

In addition, the pen communicates information such as pen tip pressure, side-switch status, tip vs. eraser orientation and ID number (to differentiate between different pens, mice, etc.). For example, applying more or less pressure to the tip of the pen changes the value of the pen's timing circuit capacitor. This signal change can be communicated in an analog or digital method. An analog implementation modulates the phase angle of the resonant frequency, while a digital method is communicated to a modulator that distributes the information digitally. The tablet forwards this and other relevant tool information in packets, up to 200 times per second, to the computer.

If you disable (delete all of them except for one that needs to be set to "no action", so that it will not be regenerated as default) the Extra Startup actions, the tablet should remain in relative mouse mode—you will not get pressure information in that mode though. }}

Handheld Barcode Scanner Readers
Types of Barcode

UPC-A      Grocery most common Code 128 EAN-13     Library Books ISBN & ISSN, Code 39 Codabar    blood bank,

2D barcodes such as Data Matrix PDF417e Maxicode Aztec QR Code    old Nokia handsets, MicroPDF417

GPS tracking, running, cycling, biking, walking, hiking, ORIENTEERING, boaters and mapping
Support for OpenStreetMap but not for Ordnance Survey, Map Pilot or National Geographic's Topo maps data gdb,

Data output supported nmea 0183 V1.5 APA, V1.5 XTE and V2.1 GSA formats, gpx, kml/kmz, tracks from tcx files, geo: URIs, NMEA0183(which is RS232, voltages range from -15 volts to 15 volts, 4800 baud), or need NMEA sentences connected to your computer

other method that some units support is a special serial cable that actually emits raw RS232 NMEA. These usually take 10->30 volts input, can run the unit, and have full voltage I/O for RS232 (not like spanner mode, which effectively turns the unit into a USB->Serial adapter inside the case).

Equivalent apps - merkator, mapsource,

USB to NGFF NVMe SDD HDD DVD CD ROM Drives

 * RTL9210B
 * JMS583 rev1 with firmware A2 or A3


 * RTL9210A
 * JMS583 firmware 2.0.9
 * Asmedia ASM2362


 * RTL9201A

The reference Hardware ID for the JMS583 chipset from JMicron is: VID_152D&PID_0583&REV_0209 where "VID_152D" identifies a JMicron product; "PID_0583" is the generation chipset; "REV_0209" is the firmware version installed.

In the same way, the reference Hardware ID for the RTL9210 from Realtek is: VID_0BDA&PID_9210&REV_3100 "VID_0BDA" is for a Realtek product, "PID_9210" is referred to the chipset and "REV_3100" to the firmware.

Cameras
Lens Mounts

Canon EF EF-S Nikon F Panasonic Olympus OM Pentax DA, FA, F, A, M, and K series Fujifilm X mount

Sensors

APS-C S35 Full Frame 43 Four Thirds M43 MFT Micro four thirds

printer.class - PostScript 3 and internal ghostscript drivers
As the only printer driver that AROS supports natively is Postscript, our focus is on applications that generally output postscript formatted data for printing purposes and since the general Joe Public finds postscript capable printer very expensive, postscript interpreters (eg ghostscript) have been developed aas a cheaper option which sit in between postscript data streams and non postscript (HP PCL?) printers.

Set up Printer Prefs for Postscript and set the print to file option.

Ghostscript has internal printer drivers

gs -h

and with something like

gs -sDEVICE=stcolor -r300 -sOutputFile=RAM:tempfile gs813:examples/tiger.ps copytopar ram:tempfile

It checks if in RAM: exists a outputfile (Cinnamon can export to PS postscript) then it sends this via copytopar to the printer. There was only support for parport (parallel) but Terminillis added support for USB and ethernet. A big issue with using ghostscript for drivers is that data has to originate as postscript (.PS) file.

gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=ljet4 -sOutputFile=RAM:tempfile RAM:file.pdf

the ljet4 output device generates PCL

also the pxlmono driver, which generates more generic PXL (PCL 6)

gs -q -sstdout=%stderr -sDEVICE=pswrite -sOutputFile=- -dBATCH -dNOPAUSE -dPARANOIDSAFER testpage-a4.ps > test.pdf

gs -q -sstdout=%stderr -sDEVICE=pxlmono -sOutputFile=- -dBATCH -dNOPAUSE -dPARANOIDSAFER test.pdf > test.pxl

Printers supported by ghostscript...Explanation here or here and here

bit           cljet5          ljet4d          pjxl300         pxlcolor bitcmyk       cljet5c         ljetplus        pkm             pxlmono bitrgb        deskjet         nullpage        pkmraw          stp bj10e         djet500         pbm             pksm            tiff12nc bj200         epswrite        pbmraw          pksmraw         tiff24nc bjc600        faxg3           pcx16           png16           tiffcrle bjc800        faxg32d         pcx24b          png16m          tiffg3 bmp16         faxg4           pcx256          png256          tiffg32d bmp16m        ijs             pcxcmyk         pnggray         tiffg4 bmp256        jpeg            pcxgray         pngmono         tifflzw bmp32b        jpeggray        pcxmono         pnm             tiffpack bmpgray       laserjet        pdfwrite        pnmraw          uniprint bmpmono       lj5gray         pgm             ppm             x11 bmpsep1       lj5mono         pgmraw          ppmraw          x11alpha bmpsep8       ljet2p          pgnm            psgray          x11cmyk cdeskjet      ljet3           pgnmraw         psmono          x11gray2 cdj550        ljet3d          pj              psrgb           x11gray4 cdjcolor      ljet4           pjxl            pswrite         x11mono cdjmono

USB Color
See here for compatibility with TP7 (TurboPrint 7) Last update 2004. Not tested under emulation. Janus-UAE, Emumiga,

OS3.x support via NetPrinter and OS4 drivers and experiences.

usbparallel.device

untested with USB->Centronics - The printer.class is rather 'clever'. It remembers to which unit the printers were connected (until you reboot). So if you first plug in Printer1, it gets unit 0, and Printer2 gets unit 1. If you now remove both printers and replug Printer2, it still will get unit 1 and not 0. This is used not to confuse the programs using the different units (moreover, if some program uses the usbparallel.device unit of an USB printer, and the printer is unplugged, the device unit cannot be freed immediately as the application still keeps it open). Sticking to the same units is generally a good idea I think (and therefore this mechanism is also used with all other classes creating exec.devices).

You may not send a short packet (packet less than maxpktsize == 64) nor zero byte packets until the very last byte of your printout. Otherwise the printer will silently ignore the data you sent. Some printer drivers print very short sequences that never fill the endpoint buffer, so printer ignore them. Bufferize all printer driver writes in the ieee1284.device and send them by epsize packets. So my hppsc2210 works fine with a classic HP560C driver, on a classic A2000 subwayized :)

rawwrap.class - some old flatbed scanners supported
Betascan Bugtracker and Search for Betascan

Epson2 with Betascan

gt68xx - SCANdal with Betascan

Lexmark - needs testing

HP - no driver

Plustek LM983x - no driver

SnapScan - no driver

rndis.class USB Tethering
The rndis class provides support for Ethernet access over Remote NDIS. Most USB based devices should be supported including smartfones.

Before opening Network Prefs, activate USB Tethering on the Smartfon, on Network prefs, type in usbrndis.device and tick "Start Network during system boot" and saved the configuration, the Connection is immediate no reboot is needed.

When restart AROS my Smartphone deactivates the connection and to access the network again, have to reactivate it before starting the browser.

USB &rarr; ethernet lan adaptor

 * 2002 playstation 2 usb1.1 lan era - best support
 * 2006 wii asix era - some support but very much miss than hit
 * 2009 little or no support


 * USB1.1 Up to 010 meg broadband (1.25MBytes/s) - ADM8511, DM9601 best supported
 * USB2.0 Up to 400 meg broadband (60MBytes/s) - MCS7830, AX88172 a little
 * USB3.0 Over 400 meg broadband (60+MBytes/s) - no support

ADMtek Infineon ADM8511 Pegasus II (USB 1.1 and 10Mbit/s - Sony PlayStation 2 network adapter)

Davicom DM9601 eth (USB 1.1 and up to 10Mbit/s)

MosChip MCS7830 (USB 2)


 * Asix Ethernet AX88178A, AX88772C, AX88772B, AX88772A (wii), AX88172A (USB2 and up to 60meg broadband)
 * AX88179A, AX88179 (Gen3.2 to giga)

AX88172A implements 10/100Mbps Ethernet LAN function based on IEEE802.3 and IEEE802.3u standards and integrates an on-chip 10/100Mbps Ethernet PHY. The USB 2.0 to MII controller, provides an optional External Media Interface (EMI) for an external PHY or an external MAC depending on different application purposes.

USB &rarr; SerialPort Converter

 * 2002 some support for early revisions of PL2303
 * 2005 Prolific PL2303H PL-2303X and Pl-2303HX (same usb ids as pl2303) no support

serialpl2303.class make sure you specify serialpl2303.device

FTDI-FT232RL.class

ch341a.class

I2C EEPROMS (3.3V and 5V) compatible and also SPI FLASH memories (3.3V devices) - each having their own 4x2 connection blocks
 * whilst uart bridged if not just normal serial converter

simplemidi.class and CAMD
Currently support includes


 * simplemidi.class for Tracker keymapping emulation which should work without modification
 * camdusbmidi.class follows the rules of the 68k implementation of Commodore's CAMD midi specification and usb class compliant

for


 * usb host like a computer
 * usb device controllers - keyboards, drum machines, djay turntables, grooveboxes, etc
 * interfaces - cables or boxes which convert usb to 5pin DIN plug midi

SimpleMidi maps some keyboard keys to corresponding computer keys as used by music trackers to emulate a musical keyboard.

What is needed is a fully class-compliant USB MIDI keyboard (controller), most brandname ones and especially manufactured in the last 10 years are best


 * Arturia
 * Novation
 * M-Audio
 * Akai
 * Native Instruments

Plugging this in one of your USB ports, the camd.library will make the keyboard's MIDI IN/OUT ports available in the system.

Then select the keyboard's MIDI IN port (known as a "cluster" in CAMD) for input, and the software instrument's cluster as output

ShowCluster (shows midi ports available in and out)

MidiWatch (usually port usbmidi.in.0 less often usbmidi.out.0) (Ctrl-C to end output stream) usbmidi.in.0 Message on channel 01, NoteOn 90  39  08  00 usbmidi.in.0 Message on channel 01, NoteOff 80 39  00  00

MidiThru (forwards messages from one port to another) run >nil: c:midithru usbmidi.out.0 usbmidi.out.2

MidiSendC (sends a middle C to a specific port)

Midi Controller + Sound Module (together aka as a synth) -> Audio Output

USB enabled controllers do not require hardware interfaces to be used by AROS and its' apps.
 * 25, 32, 37 keys for loops and beats
 * 49 keys suit prosumer
 * 61, 88 ideal for pianist / organist

But if you want to connect external 5pin only MIDI devices to USB port(s), you'll need a hardware MIDI interface.... but

Sadly the same can not be said for 5 pin DIN midi USB2.0 interfaces. There was no audio 'class' for USB2 for quite some time, and as a result most of those interfaces need their own drivers. Some interfaces are USB2, but support USB1.1 Class Compliant operation at a lower feature set (16/48 for example).

The difference between midi and midi over USB is that in old school Midi the transmitter transmits whenever it wants and the receiver always has to be prepared to receive data. Easy to do at the rate of a 1990's modem speed these days.

USB over midi.. turns midi into a polled protocol.. So the USB host (typically the computer) has to ask "do you have anything for me" before the remote will send. If the USB host gets busy doing other things or there is a lot of things on the USB bus to get polled, you can get delays.

For its age midi is still a great protocol for music

On AROS Hosted/Linux the hostmidi driver (uses "/dev/midi")) did work at least somewhat with Bars & Pipes Professional. BnP also some trouble with song loading/saving and endianness, because of this external tools which can add additional "data" but the app has no idea of the layout of that data and therefore cannot safely do necessary endianness conversions.


 * USBIF's "USB Device Class Definition for MIDI Devices" document, version 1.0 from Nov 1, 1999
 * MIDI v2.0 from 2020 which AROS still needs, adds support for MIDI 2.0, MIDI-CI, and Universal MIDI Packet

Nearly all synthesizers now use the 16 MIDI channels available on a MIDI bus in one instrument alone, requiring multiple MIDI busses in a typical setup with more than one MIDI instrument. In addition, by handling multiple "virtual" cables, USB offers a solution to go beyond MIDI's 16-channel limit.

MIDI data is transferred over USB using 32-bit USB-MIDI Event Packets. These packets provide an efficient method to transfer multiple MIDI streams with fixed length messages. The 32-bit USB-MIDI Event Packet allows multiple "virtual MIDI cables" routed over the same USB endpoint. This approach minimizes the number of required endpoints. It also makes parsing MIDI events easier by packetizing the separate bytes of a MIDI event into one parsed USB-MIDI event.

Blue Ribbon Soundworks Bars & Pipes Professional (1993/4)

GM (1984), GS (1987), XG level 1-3 (1994-1997), GM level 2 (1999)

GM GM1 imposes several requirements beyond the MIDI 1.0 specification. While MIDI 1.0 by itself provides a communication protocol which ensures that different instruments can interoperate at a fundamental level e.g sound modules. GM goes further in two ways. First, GM requires that all compliant MIDI instruments meet a certain minimal set of features, such as being able to play at least 24 notes simultaneously (polyphony). Second, GM attaches specific interpretations to many parameters and control messages which were left unspecified in the MIDI 1.0 specification. A minimum of 128 MIDI Program Numbers (conforming to the GM 1 Instrument Patch Map) and 47 percussion sounds (conforming to the GM 1 Percussion Key Map). Support for controller number 1, 7, 10, 11, 64, 100, 101, 121 and 123; support for channel pressure and pitch bend controllers.

General MIDI Level 2 or GM2 is a specification for synthesizers which defines several requirements beyond the MIDI standard and is based on General MIDI (GM) and Roland GS extensions. It was adopted in 1999 by the MIDI Manufacturers Association (MMA).


 * Number of Notes: 32 simultaneous notes
 * MIDI Channels: 16
 * Simultaneous Melodic Instruments – up to 16 (all Channels)
 * Simultaneous Percussion Kits – up to 2 (Channel 10/11)

Program and bank change events General MIDI 2 compatible synthesizers access all of the 256 instruments by setting cc#0 (Bank Select MSB) to 121 and using cc#32 (Bank Select LSB) to select the variation bank before a Program Change. Variation bank 0 contains the full GM (General MIDI 1) sound set. Variations using other bank numbers are new to General MIDI 2, and correspond to variation sounds introduced in Roland GS.

Classic 5pin DIN controllers for above interfaces

The MIDI standard was published in August 1983. The inventors, Kakehashi and Smith finally received a Technical Grammy Award in 2013 for their work.

The MIDI files that contained just the note data, velocity and timing meant you could transfer an entire studio session from one place to another on one floppy disk and it could control all the synths and drum samplers. Pass-thru meant that one computer could run an entire bands worth of instruments.

It's bulletproof too. MIDI never goes wrong, it's always a bug in software that causes any issue - you can absolutely rely on it to go gigging with, take your synths, controllers and computers and not crash an entire gig at your 100,000 person venue.

The MIDI hardware specification is very simple (voltage, polarity, screening, protection and a fast enough opto-isolator), it assumes that the data it sends and receives between MIDI devices is to the MIDI data standard and just passes it on. The microprocessor in the hardware does all the work.

The minimum for a computer/MIDI interface is that it meets the MIDI hardware specification. It is attached to the computer bus and handles the electrical conversions required. To meet the MIDI hardware specification, to be class compliant as a USB device all it has to do is report itself properly when plugged in.

The other half of the equation is the MIDI data standard, and for a computer MIDI interface the main issue is the speed of data transmission. The bus speed of the computer is faster than the speed of the MIDI standard so it can generate and send MIDI data faster than a MIDI device can receive it. The MIDI standards have nothing to say on that bottleneck at all. MIDI was designed to be very simple and very open, it just defines a standard for the messages and leaves it up to manufacturers to implement them in the way they want. That's what makes it so powerful a tool, and also what makes it so confusing and frustrating at times.

For midi, the hardware/software combination at various connection points handles the translation to/from midi (or other protocols). Drivers would be needed for midi, including clock and SysEx signal (actually claiming to handle ALL midi quirks transparently

All the important MIDI data types can be sent (CC, NRPN, RPN, MMC, Note On/Off, program change)

There is no official way to solve the data bottleneck. Early software sequencers and librarians tried to solve it by having an option to buffer SYSEX data in software and transmit it at the MIDI data rate. The downside is that hogs the bus and can hit computer performance. Interface manufacturers would add a hardware buffer which would take all the MIDI data from the PC bus and feed it into the MIDI at the slower data rate, but that added cost and created timing issues.

Things have moved on since then, but the principles remain the same. You can buffer in the hardware or in software, whether that is in the application or the interface driver. SYSEX will work perfectly well with that budget cable if your software handles the buffering. And while the cables with hardware buffers make SYSEX easier, they still have potential problems because of the limitations of the MIDI data rate. Your MIDI clock doesn't like being interrupted with a big program dump

The serial / parallel ports were a direct connection, so faster. Now, everything in the computer is virtual and the only thing connected to the hardware is the kernel, hence everything is by default bottlenecked and jittery, regardless of which connection. So by the time the interface gets the information it's already too late.

Ethernet network cable to transport MIDI over large distances, connect 2 MIDI In and 2 MIDI Out ports to patch, remap, filter and merge MIDI flows on a fine channel basis for tight MIDI throughput, latency and jitter

Possibilities for DAWs of the future including a kind of sync reference for timing reference which an interface could sync to, hence all the timings then would be locked between the grid on the DAW screen and the MIDI info.

Preemptible, low latency and accuracy are essential for good communication.

One of the first things you need to do, is make sure your MIDI software sets the interface to the same MIDI channel as your keyboard (usually 1)

Do you want to send just your master keyboard to other synths or to be able to use any keyboard with any synth?

1st option is relatively simple. Just need to send midi from your master keyboard into a midi splitter that redistributes the signal onto your synths. Each synth will be set up to receive midi on a specific channel so the only challenge is to find a way to select to which channel you are sending midi. Some master keyboards can do that although not many that have a dedicated knob or switch on the panel and most require a bit of menu diving. Could use a midi box that offers channel selection but usually this is not very workflow friendly. The software route would require using the mouse.

2nd option is a bit more complex but superior workflow by sending midi messages into a merge box, from there into a hardware sequencer that allows to select midi channel, then on to a midi interface that distributes the signal to the synths.

Master keyboard MIDI-in to computer. External hardware sampler MIDI-out from computer. Audio-out from sampler to audio-in on computer/device.

The camdusbmidi.class may need to be modified to the AROS CAMD MIDI system or src,, testing of CAMD, camd use programming use,

Major WWHWWWH, Minor WHWWHWW scale, Chords,

usbaudio.class (req. rt iso transfer)
USB audio streaming over AHI requires iso and realtime isochronous transfer, still no support in pciusb.device.

AHI does not support six channel playback. It only supports mono, stereo and multichannel (8 channels). Due to the multichannel mode not being used by any application so far, the usbaudio.class does not support multichannel playback, especially not "upchannelling" stereo to six or more channels. If this USB device does not support a two channel mode, you can't use it under AHI.

XDA Forum thread,


 * DACs with standard (adaptive) USB - where the computer controls the data timing.
 * DACs plus an asynchronous USB converter module outputting S/PDIF—where the DAC controls the data timing.
 * DACs with inbuilt async USB capability and an I2S internal feed to the DAC

USB AUDIO CARDS - USB2 UCA Compliant

USB Microphones

USB Speakers

USB Headset Wired/Wireless

Webcameras
A USB camera has two dedicated chips: a controller or bridge and an image sensor.

There is no support for video interfaces, because neither AROS, AmigaOS nor MorphOS define a standard for this. The only commercial, now discontinued application that defined some sort of standard was VHI Studio by iospirit.

OLD standards
See support pages and here and some further compatibility

Pencam STV680

SonixcamTool (Sonix webcams and derivates)

Note some Sonix Webcams with a Sonix SN9C1xx controller and a pas106b or tas5110c1b sensor support bulk mode which works even with pciusb.device!

micromaxx USB Camera 	STM 	1363 	514 	works 	--- USB Tower 	Lego 	1684 	1 	works 	need NCQ Trust Spycam 100plus 	STM 	1363 	514 	works

ov51x.class - no driver

UVC.class - USB Device Class Definition for Video Devices or USB Video Class
AROS needs realtime isochronous transfers in EHCI and XHCI, then a uvc.class usbvideo and then a video ahi (like vhi??) type substructure to be written

$ mplayer rtsp://127.0.0.1:554/sample_300kbit.mp4

MPlayer supports multicast streaming, and rtp/rtsp protocols (it might require live555 library to work with some streams). But you might have to build it where it's disabled. Also, multicast won't work with some AmiTCP-likes. MIAMI supported it, though.

AROS supports IPv4 (old but works) and this includes the needed address space for RTP.

If you mean multicast via RTP - mplayer handles it. You can even force UDP over TCP

-rtsp-stream-over-tcp

If the rtsp Real Time Streaming Protocol server needs authentification:

-user -passwd


 * standalone with sd card - wansview, amcrest, tenvis, keekoon, foscam,
 * needing a dvr or nvr - dlink, hikvision, foscam, trendnet, sony, axis,

PCI-e AVMATRIX VC12-4K

Linux info v4l2-ctl—list-formats-ext or fswebcam—verbose to get output modes

vlc rtsp://user:password@ip/play1.sdp—sout=file/ogg:mystream.ogv

vlc rtsp://192.168.0.21:554/mpeg4—sout=file/ts:mystream.mpg

rtsp_session: unsupported RTSP server. Server type is 'DSS/5.5.4

cdcacm.class - USB modem
The CDC ACM driver exposes the USB modem as a virtual serial modem or a virtual COM port to the operating system. The driver enables sending both data and AT commands, either through ACM (separating data and AT commands over different channels) or through Serial Emulation (passing the AT commands as is and as part of the data stream).

Misc
palmpda.class - no pdalink.library and tools in AROS

Palm PDA (discontinued) synchronisation requires a port of pdalink.library and its tools through virtual usbpalm.device.

bluetooth.class - needs Bluetooth stack to work (not included)

ccid.class - Chip/Smart Card Interface Devices (not implemented)

dfu.class - DFU firmware upgrade

RocketTool (USB Rocket Launchers - Toy missile launchers)

DRadioTool (FM Radios - USB radio devices D-Link/Gemtek)

UproarTool (Valencia MPX mp3 player and others)