-->

• Driver Usb To Lan Win 10
• Driver Usb Lan Rs1081b
• Driver Usb Lan
• Driver Usb To Lan Qts1081b
• Driver Usb To Lan

This package provides USB Ethernet Adapter Driver and is supported on Flex Pro-13IKB, Yoga 920-13IKB, Yoga 920-13IKB Glass and running the following Operating Systems: Windows 10 (64-bit). Driver samples for Windows 10. These are the official Microsoft Windows Driver Kit (WDK) driver code samples for Windows 10. They provide a foundation for Universal Windows driver support of all hardware form factors, from phones to desktop PCs. Apps for Drivers. Drivers are code that help Windows and MacOS recognize the physical components of your computer, like a printer, graphics card, or mouse. For enterprise and industrial customers who need remote or local USB ports and the higher speeds of USB 3.1 Gen 1 and Gigabit/10 Gigabit Ethernet, Digi AnywhereUSB Plus products give you an industry-leading connectivity solution. The driver object represents the instance of the client driver after Windows loads the driver in memory. The complete source code for the driver object is in Driver.h and Driver.c. Before discussing the details of the template code, let's look at some declarations in the header file (Driver.h) that are relevant to KMDF driver development.

In this topic, you'll learn about the source code for aKMDF-based USB client driver. The code examples are generated by the USB User-Mode Drivertemplate included with Microsoft Visual Studio 2019.

These sections provide information about the template code.

For instructions on generating the KMDF template code, see How to write your first USB client driver (KMDF).

Driver source code

The driver object represents the instance of the client driver after Windows loads the driver in memory. The complete source code for the driver object is in Driver.h and Driver.c.

Driver.h

Before discussing the details of the template code, let's look at some declarations in the header file (Driver.h) that are relevant to KMDF driver development.

Driver Usb To Lan Win 10

Driver.h, contains these files, included in the Windows Driver Kit (WDK).

Ntddk.h and Wdf.h header files are always included for KMDF driver development. The header file includes various declarations and definitions of methods and structures that you need to compile a KMDF driver.

Usb.h and Usbdlib.h include declarations and definitions of structures and routines that are required by a client driver for a USB device.

Wdfusb.h includes declarations and definitions of structures and methods that are required to communicate with the USB I/O target objects provided by the framework.

Device.h, Queue.h, and Trace.h are not included in the WDK. Those header files are generated by the template and are discussed later in this topic.

The next block in Driver.h provides function role type declarations for the DriverEntry routine, and EvtDriverDeviceAdd and EvtCleanupCallback event callback routines. All of these routines are implemented by the driver. Role types help Static Driver Verifier (SDV) analyze a driver's source code. For more information about role types, see Declaring Functions by Using Function Role Types for KMDF Drivers.

The implementation file, Driver.c, contains the following block of code that uses alloc_text pragma to specify whether the DriverEntry function and event callback routines are in pageable memory.

Notice that DriverEntry is marked as INIT, whereas the event callback routines are marked as PAGE. The INIT section indicates that the executable code for DriverEntry is pageable and discarded as soon as the driver returns from its DriverEntry. The PAGE section indicates that the code does not have to remain in physical memory all the time; it can be written to the page file when it is not in use. For more information, see Locking Pageable Code or Data.

Shortly after your driver is loaded, Windows allocates a DRIVER_OBJECT structure that represents your driver. It then calls your driver's entry point routine, DriverEntry, and passes a pointer to the structure. Because Windows looks for the routine by name, every driver must implement a routine named DriverEntry. The routine performs the driver's initialization tasks and specifies the driver's event callback routines to the framework.

The following code example shows the DriverEntry routine generated by the template.

The DriverEntry routine has two parameters: a pointer to the DRIVER_OBJECT structure that is allocated by Windows, and a registry path for the driver. The RegistryPath parameter represents the driver-specific path in the registry.

In the DriverEntry routine, the driver performs these tasks:

• Allocates global resources that are required during the lifetime of the driver. For example, in the template code, the client driver allocates resources required for WPP software tracing by calling the WPP_INIT_TRACING macro.

• Registers certain event callback routines with the framework.

  To register the event callbacks, the client driver first specifies pointers to its implementations of the EvtDriverXxx routines in certain WDF structures. The driver then calls the WdfDriverCreate method and supplies those structures (discussed in the next step).

• Calls the WdfDriverCreate method and retrieves a handle to the framework driver object.

  After the client driver calls WdfDriverCreate, the framework creates a framework driver object to represent the client driver. When the call completes, the client driver receives a WDFDRIVER handle and can retrieve information about the driver, such as its registry path, version information, and so on (see WDF Driver Object Reference).

  Note that the framework driver object is different from the Windows driver object described by DRIVER_OBJECT. At anytime, the client driver can get a pointer to the WindowsDRIVER_OBJECT structure by using the WDFDRIVER handle and calling the WdfGetDriver method.

After the WdfDriverCreate call, the framework partners with the client driver to communicate with Windows. The framework acts as a layer of abstraction between Windows and the driver, and handles most of the complicated driver tasks. The client driver registers with the framework for events that driver is interested in. When certain events occur, Windows notifies the framework. If the driver registered an event callback for a particular event, the framework notifies the driver by invoking the registered event callback. By doing so, the driver is given the opportunity to handle the event, if needed. If the driver did not register its event callback, the framework proceeds with its default handling of the event.

One of the event callbacks that the driver must register is EvtDriverDeviceAdd. The framework invokes the driver's EvtDriverDeviceAdd implementation when the framework is ready to create a device object. In Windows, a device object is a logical representation of the function of the physical device for which the client driver is loaded (discussed later in this topic).

Other event callbacks that the driver can register are EvtDriverUnload, EvtCleanupCallback, and EvtDestroyCallback.

In the template code, the client driver registers for two events: EvtDriverDeviceAdd and EvtCleanupCallback. The driver specifies a pointer to the its implementation of EvtDriverDeviceAdd in the WDF_DRIVER_CONFIG structure and the EvtCleanupCallback event callback in the WDF_OBJECT_ATTRIBUTES structure.

When Windows is ready to release the DRIVER_OBJECT structure and unload the driver, the framework reports that event to the client driver by invoking the driver's EvtCleanupCallback implementation. The framework invokes that callback just before it deletes the framework driver object. The client driver can free all global resources that it allocated in its DriverEntry. For example, in the template code, the client driver stops WPP tracing that was activated in DriverEntry.

The following code example shows the client driver's EvtCleanupCallback event callback implementation.

After the device is recognized by the USB driver stack, the bus driver creates a physical device object (PDO) for the device and associates the PDO with the device node. The device node is in a stack formation, where the PDO is at the bottom. Each stack must have one PDO and can have filter device objects (filter DOs) and a function device object (FDO) above it. For more information, see Device Nodes and Device Stacks.

This illustration shows the device stack for the template driver, MyUSBDriver_.sys.

Notice the device stack named 'My USB Device'. The USB driver stack creates the PDO for the device stack. In the example, the PDO is associated with Usbhub3.sys, which is one of the drivers included with the USB driver stack. As the function driver for the device, the client driver must first create the FDO for the device and then attach it to the top of the device stack.

For a KMDF-based client driver, the framework performs those tasks on behalf of the client driver. To represent the FDO for the device, the framework creates a framework device object. The client driver can, however, specify certain initialization parameters that the framework uses to configure the new object. That opportunity is given to the client driver when the framework invokes the driver's EvtDriverDeviceAdd implementation. After the object is created and the FDO is attached to the top of the device stack, the framework provides the client driver with a WDFDEVICE handle to the framework device object. By using this handle, the client driver can perform various device-related operations.

The following code example shows the client driver's EvtDriverDeviceAdd event callback implementation.

During run time, the implementation of EvtDriverDeviceAdd uses the PAGED_CODE macro to check that the routine is being called in an appropriate environment for pageable code. Make sure you call the macro after declaring all of your variables; otherwise, compilation fails because the generated source files are .c files and not .cpp files.

The client driver's EvtDriverDeviceAdd implementation calls the MyUSBDriver_CreateDevice helper function to perform the required tasks.

The following code example shows the MyUSBDriver_CreateDevice helper function. MyUSBDriver_CreateDevice is defined in Device.c.

EvtDriverDeviceAdd has two parameters: a handle to the framework driver object created in the previous call to DriverEntry, and a pointer to a WDFDEVICE_INIT structure. The framework allocates the WDFDEVICE_INIT structure and passes it a pointer so that the client driver can populate the structure with initialization parameters for the framework device object to be created.

In the EvtDriverDeviceAdd implementation, the client driver must perform these tasks:

• Call the WdfDeviceCreate method to retrieve a WDFDEVICE handle to the new device object.

  The WdfDeviceCreate method causes the framework to create a framework device object for the FDO and attach it to the top of the device stack. In the WdfDeviceCreate call, the client driver must perform these tasks:

  • Specify pointers to the client driver's Plug and play (PnP) power callback routines in the framework-specified WDFDEVICE_INIT structure. The routines are first set in the WDF_PNPPOWER_EVENT_CALLBACKS structure and then associated with WDFDEVICE_INIT by calling the WdfDeviceInitSetPnpPowerEventCallbacks method.

    Windows components, PnP and power managers, send device-related requests to drivers in response to changes in PnP state (such as started, stopped, and removed) and power state (such as working or suspend). For KMDF-based drivers, the framework intercepts those requests. The client driver can get notified about the requests by registering callback routines called PnP power event callbacks with the framework, by using the WdfDeviceCreate call. When Windows components send requests, the framework handles them and calls the corresponding PnP power event callback, if the client driver has registered.

    One of the PnP power event callback routines that the client driver must implement is EvtDevicePrepareHardware. That event callback is invoked when the PnP manager starts the device. The implementation for EvtDevicePrepareHardware is discussed in the following section.

  • Specify a pointer to the driver's device context structure. The pointer must be set in the WDF_OBJECT_ATTRIBUTES structure that is initialized by calling the WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE macro.

    A device context (sometimes called device extension) is a data structure (defined by the client driver) for storing information about a specific device object. The client driver passes a pointer to its device context to the framework. The framework allocates a block of memory based on the size of the structure, and stores a pointer to that memory location in the framework device object. The client driver can use the pointer to access and store information in members of the device context. For more information about device contexts, see Framework Object Context Space.

    After the WdfDeviceCreate call completes, the client driver receives a handle to the new framework device object, which stores a pointer to the block of memory allocated by the framework for the device context. The client driver can now get a pointer to the device context by calling the WdfObjectGet_DEVICE_CONTEXT macro.

• Register a device interface GUID for the client driver by calling the WdfDeviceCreateDeviceInterface method. Applications can communicate with the driver by using this GUID. The GUID constant is declared in the header, public.h.

• Set up queues for I/O transfers to the device. The template code defines MyUSBDriver_QueueInitialize, a helper routine for setting up queues, which is discussed in the Queue source code section.

Device source code

Driver Usb Lan Rs1081b

The device object represents the instance of the device for which the client driver is loaded in memory. The complete source code for the device object is in Device.h and Device.c.

Device.h

The Device.h header file includes public.h, which contains common declarations used by all files in the project.

The next block in Device.h declares the device context for the client driver.

The DEVICE_CONTEXT structure is defined by the client driver and stores information about a framework device object. It is declared in Device.h and contains two members: a handle to a framework's USB target device object (discussed later) and a placeholder. This structure will be expanded in later exercises.

Device.h also includes the WDF_DECLARE_CONTEXT_TYPE macro, which generates an inline function, WdfObjectGet_DEVICE_CONTEXT. The client driver can call that function to retrieve a pointer to the block of memory from the framework device object.

The following line of code declares MyUSBDriver_CreateDevice, a helper function that retrieves a WDFUSBDEVICE handle to the USB target device object.

USBCreate takes a pointer to a WDFDEVICE_INIT structure as its parameter. This is the same pointer that was passed by the framework when it invoked the client driver's EvtDriverDeviceAdd implementation. Basically, MyUSBDriver_CreateDevice performs the tasks of EvtDriverDeviceAdd. The source code for EvtDriverDeviceAdd implementation is discussed in the previous section.

The next line in Device.h declares a function role type declaration for the EvtDevicePrepareHardware event callback routine. The event callback is implemented by the client driver and performs tasks such as configuring the USB device.

Device.c

The Device.c implementation file contains the following block of code that uses alloc_text pragma to specify that the driver's implementation of EvtDevicePrepareHardware is in pageable memory.

In the implementation for EvtDevicePrepareHardware, the client driver performs the USB-specific initialization tasks. Those tasks include registering the client driver, initializing USB-specific I/O target objects, and selecting a USB configuration. The following table shows the specialized I/O target objects provided by the framework. For more information, see USB I/O Targets.

This code example shows the implementation for EvtDevicePrepareHardware.

Here's a closer look at the client driver's tasks as implemented by the template code:

1. Specifies the client driver's contract version in preparation to register itself with the underlying USB driver stack, loaded by Windows.

   Windows can load the USB 3.0 or USB 2.0 driver stack, depending on the host controller to which the USB device is attached. The USB 3.0 driver stack is new in Windows 8 and supports several new features defined by the USB 3.0 specification, such as the streams capability. The new driver stack also implements several improvements, such as better tracking and processing of USB Request Blocks (URBs), which are available through a new set of URB routines. A client driver that intends to use those features or call the new routines must specify the USBD_CLIENT_CONTRACT_VERSION_602 contract version. A USBD_CLIENT_CONTRACT_VERSION_602 client driver must adhere to a certain set of rules. For more information about those rules, see Best Practices: Using URBs.

   To specify the contract version, the client driver must initialize a WDF_USB_DEVICE_CREATE_CONFIG structure with the contract version by calling the WDF_USB_DEVICE_CREATE_CONFIG_INIT macro.

2. Calls the WdfUsbTargetDeviceCreateWithParameters method. The method requires a handle to the framework device object that the client driver obtained previously by calling WdfDeviceCreate in the driver's implementation of EvtDriverDeviceAdd. The WdfUsbTargetDeviceCreateWithParameters method:

   • Registers the client driver with the underlying USB driver stack.
   • Retrieves a WDFUSBDEVICE handle to the USB target device object that is created by the framework. The template code stores the handle to the USB target device object in its device context. By using that handle, the client driver can obtain USB-specific information about the device.

   Note You must call WdfUsbTargetDeviceCreate instead of WdfUsbTargetDeviceCreateWithParameters if,

   • Your client driver does not call the new set of URB routines available with theWindows 8 version of the WDK.

     If your client driver calls WdfUsbTargetDeviceCreateWithParameters, the USB driver stack assumes that all URBs are allocated by calling WdfUsbTargetDeviceCreateUrb or WdfUsbTargetDeviceCreateIsochUrb. URBs that are allocated by those methods have opaque URB context blocks that are used by the USB driver stack for faster processing. If the client driver uses an URB that is not allocated by those methods, the USB driver generates a bugcheck.

     For more information about URB allocations, see Allocating and Building URBs.

   • Your client driver does not intend to adhere to the set of rules described in Best Practices: Using URBs.

   Such drivers are not required to specify a client contract version and therefore must skip Step 1.

3. Selects a USB configuration.

   In the template code, the client driver selects the default configuration in the USB device. The default configuration includes Configuration 0 of the device and the Alternate Setting 0 of each interface within that configuration.

   To select the default configuration, the client driver configures the WDF_USB_DEVICE_SELECT_CONFIG_PARAMS structure by calling the WDF_USB_DEVICE_SELECT_CONFIG_PARAMS_INIT_MULTIPLE_INTERFACES function. The function initializes the Type member to WdfUsbTargetDeviceSelectConfigTypeMultiInterface to indicate that if multiple interfaces are available, then an alternate setting in each those interfaces must be selected. Because the call must select the default configuration, the client driver specifies NULL in the SettingPairs parameter and 0 in the NumberInterfaces parameter. Upon completion, the MultiInterface.NumberOfConfiguredInterfaces member of WDF_USB_DEVICE_SELECT_CONFIG_PARAMS indicates the number of interfaces for which Alternate Setting 0 was selected. Other members are not modified.

   Note If the client driver wants to select alternate settings other than the default setting, the driver must create an array of WDF_USB_INTERFACE_SETTING_PAIR structures. Each element in the array specifies the device-defined interface number and the index of the alternate setting to select. That information is stored in the device's configuration and interface descriptors that can be obtained by calling the WdfUsbTargetDeviceRetrieveConfigDescriptor method. The client driver must then call WDF_USB_DEVICE_SELECT_CONFIG_PARAMS_INIT_MULTIPLE_INTERFACES and pass the WDF_USB_INTERFACE_SETTING_PAIR array to the framework.

Queue source code

The framework queue object represents the I/O queue for a specific framework device object. The complete source code for the queue object is in Queue.h and Queue.c.

Queue.h

Declares an event callback routine for the event raised by the framework's queue object.

The first block in Queue.h declares a queue context.

Similar to a device context, a queue context is a data structure defined by the client to store information about a particular queue.

The next line of code declares MyUSBDriver_QueueInitialize function, the helper function that creates and initializes the framework queue object.

The next code example declares a function role type declaration for the EvtIoDeviceControl event callback routine. The event callback is implemented by the client driver and is invoked when the framework processes a device I/O control request.

Queue.c

The implementation file, Queue.c, contains the following block of code that uses alloc_text pragma to specify that the driver's implementation of MyUSBDriver_QueueInitialize is in pageable memory.

WDF provides the framework queue object to handle the request flow to the client driver. The framework creates a framework queue object when the client driver calls the WdfIoQueueCreate method. In that call, the client driver can specify certain configuration options before the framework creates queues. Those options include whether the queue is power-managed, allows zero-length requests, or is the default queue for the driver. A single framework queue object can handle several types of requests, such as read, write, and device I/O control. The client driver can specify event callbacks for each of those requests.

The client driver must also specify the dispatch type. A queue object's dispatch type determines how the framework delivers requests to the client driver. The delivery mechanism can be sequential, in parallel, or by a custom mechanism defined by the client driver. For a sequential queue, a request is not delivered until the client driver completes the previous request. In parallel dispatch mode, the framework forwards the requests as soon as they arrive from I/O manager. This means the client driver can receive one request while processing another. In the custom mechanism, the client manually pulls the next request out of the framework queue object when the driver is ready to process it.

Typically, the client driver must set up queues in the driver's EvtDriverDeviceAdd event callback. The template code provides the helper routine, MyUSBDriver_QueueInitialize, that initializes the framework queue object.

To set up queues, the client driver performs these tasks:

1. Specifies the queue's configuration options in a WDF_IO_QUEUE_CONFIG structure. The template code uses the WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE function to initialize the structure. The function specifies the queue object as the default queue object, is power-managed, and receives requests in parallel.
2. Adds the client driver's event callbacks for I/O requests for the queue. In the template, the client driver specifies a pointer to its event callback for a device I/O control request.
3. Calls WdfIoQueueCreate to retrieve a WDFQUEUE handle to the framework queue object that is created by the framework.

Here's how the queue mechanism works. To communicate with the USB device, an application first opens a handle to the device by calling the SetDixxx routines and CreateHandle. By using this handle, the application calls the DeviceIoControl function with a specific control code. Depending on the type of control code, the application can specify input and output buffers in that call. The call is eventually received by I/O Manager, which then creates a request (IRP) and forwards it to the client driver. The framework intercepts the request, creates a framework request object, and adds it to the framework queue object. In this case, because the client driver registered its event callback for the device I/O control request, the framework invokes the callback. Also, because the queue object was created with the WdfIoQueueDispatchParallel flag, the callback is invoked as soon as the request is added to the queue.

When the framework invokes the client driver's event callback, it passes a handle to the framework request object that holds the request (and its input and output buffers) sent by the application. In addition, it sends a handle to the framework queue object that contains the request. In the event callback, the client driver processes the request as needed. The template code simply completes the request. The client driver can perform more involved tasks. For instance, if an application requests certain device information, in the event callback, the client driver can create a USB control request and send it to the USB driver stack to retrieve the requested device information. USB control requests are discussed in USB Control Transfer.

Related topics

Getting started with USB client driver development
WinUSB
Write your first USB client driver (UMDF)
Write your first USB client driver (KMDF)

• 1General
• 3Software installation

General

The Lightning VME is an internal plug-in card that extends the Atari TT and the Mega STE with two USB 1.1 compatible interfaces.

Features

• new developed in 2018 (Pakman, Tuxie, Czietz, Gaga)
• two USB 1.1 interfaces, expandable by USB-hub
• both ports can be used simultaneously
• no external power supply necessary
• even USB 2.0 devices work, but then at a reduced speed
• currently ca. 600kb/s transfer rate in unaccelerated TT
• also works in accelerated TT, thus further increase in performance (tested with 20MHz bus and 40MHz CPU)
• Transferrate is customizable
• compact design, fits in the original case of both the MegaSTE and the TT
• plug and play - fully pluggable solution
• central elements are a programmable Logic Device (CPLD) from Xilinx and the ISP1160 USB-Host-Controller from Philips
• handmade, SMD in reflow process
• triple protection of both USB ports:
  • electrostatic discharge (ESD) protection when connecting external devices
  • overcurrent protection by self-healing fuses
  • secured against twisting the USB bracket by coding and labeling
• other interfaces, ROM port, ACSI interface and VME slot remain free
• support real USB mice, not only with PS/2 protocol
• finally true support of mass storage even under TOS
• works under TOS 2.06 and 3.06, Magic 5.x and Mint
• only occupies the address range 0xFEFF8000 - 0xFEFF8009 of the VME bus in the TT
• especially suitable in combination with Thunder IDE Interface and / or Storm

Driver Usb Lan

Description

The Lightning is designed so that no soldering is required; it´s is plug and play.

It disappears completely inside the original case.

Currently drivers for mass storage, mice and USB2LAN devices are available. Extensions by new drivers are possible, e.g. USB keyboard or USB floppy.

Now it´s possible to use:

• USB mice
• USB memory sticks
• USB card readers (SD, CF etc.)
• USB2LAN (with Asix 88772 chipset)
• USB CD / DVD drive (note current limitation and installation of ExtenDOS / MetaDOS required)
• USB keyboard (in planning)
• etc.

This finally enables the use of up-to-date hardware as well as the simplest data exchange in the world of Windows or OSX.

Hardwarerevisions and Firmware

As of 17.02.2018, the hardware revisions B with firmware 04 are up to date.

Hardware installation

The installation of the Lightning VME in the TT is very easy. Please follow the instructions below.

The card fits in all 3 known motherboard versions of the TT:

• Daughterboard - CPU (plugged)
• PGA CPU (plugged)
• SMD CPU (soldered on) - this version is particularly well suited for easy installation.

The Lightning VME harmonized well with the Thunder IDE Interface and the Storm. The cards are not hindering each other.

There is a small possibility that after installation of the Lightning VME your existing TT-RAM extension does not physically fit into the TT.

This applies, for example, to the original FAST RAM extension card from Atari (1/4/16 MB).

Then it's time to swap them for a [Storm] (up to 256 MB).

Delivery.

The computer in the closed state, here a little bit yellowed version.

Do not forget: all works without electricity!

After loosening the screws on the underside, carefully fold up the upper shell.

Carefully remove the two front ribbon cables from the backplane of the VME board.

The VME backplane is held by the metal cage.

It is not mandatory to remove the metal cage and / or the backplane.

View after opening the TT, looking at the VME backplane and the VME metal cage.

Here are the ribbon cables removed. That's half done!

Here is a close-up.

It is a TT with SMD CPU.

There is a lot of space for the installation of the Lightning.

The cabling is factory patches from Atari.

Soldering to install the Lightning VME is not required.

Another close-up. The TT is ready to plug in the Lightning VME now.

Gently bring the Lightning VME to the backplane. Page and direction are self-explanatory.

If you are sitting in front of the TT, you should be able to read on the top left 'Atari VME-USB Adapter Rev. B'and the CE sign and two yellow, angular components.

Ensure correct position! No backplane pins should be visible.

Then gently and evenly press the Lightning VME against the backplane with moderate force.

Remember: may force be with you, young padawan!

By the way: please do not use the now visible, angled pins, do not connect either, otherwise there is a risk of damage.

The pins are exclusively for service (uploading the firmware).

That is exactly how it should look.

The TT now has 2 USB ports on the right side towards the internal hard drive / ST-RAM.

Seen from left and right.

Here you can see that the Lightning VME is parallel to the VME backplane, but without touching it at the top.

Closeup of the USB pins, divided into port 1 and 2.

There is no pen on the bottom left - this is the encoding for the USB bracket.

Plug of the USB bracket.

Driver Usb To Lan Qts1081b

Nice to look at, right?

Here with closed top, but missing the so called 'lunch box'.

The bracket can be installed as desired, e.g. to the rear.

How about connecting a Teac FD-CR7 internally to one of the USB ports?

Of course, the lunch box fits on it again, even with a hard drive.

Custom work.

The picture shows the Lightning VME in a Daughterboard TT.

When everything is installed and screwed together, only the software has to be installed.

Software installation

The enclosed floppy disk contains the driver software for TOS / Magic and Mint as well as instructions in text form.

It is divided for Atari TT and Atari Mega STE as follows:

Caution: Do not swap: TT drivers do not run in MSTE and MSTE drivers do not run in TT.

Driver Usb To Lan

Configuration, meanings and contexts

loader.prg (just for Mint)

The Loader is a utility that loads the USB stack and integrates it into the system.

usb.prg / usbxxx.km

This file is the USB stack that makes USB possible at the Atari.

The USB stack manages the USB bus and the devices connected to it.

It provides the necessary basic functions to the following drivers.

storage.prg und mouse.prg / storage.udd und mouse.udd

These drivers are based on the USB stack and communicate with the connected devices, such as a USB stick (storage) or a USB mouse (mouse).

These drivers can be extended as required, depending on availability.

Thus eth.prg (already existing) or a keyboard.prg (planned) can provide the possibility of a network interface and a USB keyboard.

blitz0x0.prg / blitzxxx.ucd

This file is the link between the USB stack and the Lightning VME.

It allows communication between the USB stack and the Lightning VME card.

usb.acc

This ACC under TOS and Magic ensures that the USB bus is hotplug capable.

It therefore detects whether new devices have been connected and integrates them into the system.

Of course, it also shows which devices are currently connected.

additional note on ExtenDOS / MetaDOS in case of using a USB CD drive:

This must be loaded after storage.prg.

The USB driver provides an interface according to the SCSIDRV standard, which can be used directly with ExtenDOS.

In the case of MetaDOS, a driver such as SPIN needed by Julian F. Reschke.

TOS and Magic

Here, the contents of the floppy's Auto folder are simply copied to the boot folder's Auto folder.

Attention: the correct order when copying or booting is essential!

Use this bootorder under TOS:

• USB.PRG
• MOUSE.PRG
• STORAGE.PRG
• BLITZ030.PRG

In case of using Magic, Magic has to be loaded before of the USB programs:

• MAGXBOOT.PRG
• USB.PRG
• MOUSE.PRG
• STORAGE.PRG
• BLITZ030.PRG

Hints:

• a possible bootloader always comes first.
• any additional, optional USB device drivers (ETH.PRG) will come after STORAGE.PRG / before BLITZ030.PRG
• BIGDOS.PRG comes as the first program after the bootloader, in any case [before] MOUSE.PRG

Here's an example of a working order:

If everything works correctly, it looks like this under TOS 3.06 (here with Nova Mach32):

You can see that the USB.ACC has found the Lightning as Root Hub as well as an optical USB mouse and a USB stick.

USB mass storage devices detected by the system can be set up as usual, here using the example of the HDDriver 10.10.

The same restrictions apply as for other drives.

Mint

The installation under Mint is also not difficult.

• Step 1:

The drivers are not loaded from the Auto folder, but via the loader.prg from the USB directory under Mint.

For this, copy all files from the directory a:ttmint from the floppy disk to

C:mint1-19-curusb

If the USB directory does not exist, it must be created.

• Step 2:

In the next step, the file mint.cnf, which is located at c:mint1-19-cur, must be adapted.

To do this, open this file with an editor (for example, QED, Luna, etc.).

Pretty much at the end of mint.cfg there is a line called:

GEM=u:/c/mint/1-19-CUR/xaaes/xaloader.prg

The following must be inserted before this line

exec u:/c/mint/1-19-cur/usb/loader.prg

The CUR may need to be replaced by its existing kernel version number.

When starting Mint, the Driver should bring about these issues.

Then the USB devices are also available under Mint, here the example of MyAES Desktop.

USB2LAN

Note: the following entries are updated continuously.

The following USB network adapters work with the Lightning (driver for Mint):

• DLink
  • DUB-E100, silver, H / W Ver. B1
  • DUB-E100, black, H / W Ver. C1

• ' China-adapter' with ASIX chipset
  • AX88772A
  • AX88772B

Attention: Currently there are USB2LAN adapters for small money (quite small and white housing). Often a different network chip is installed, as it is on offer.

If the name AX88772 stands directly on the device, there is a high probability that this chip is actually installed.

Notes on software installation:

1. ETH.UDD must be in USB folder and ASIX.XIF in MiNT main folder.

2. The device is called 'asx0'.

3. It is configured like any other network card under MiNT, ie with ifconfig, route, etc. pp.

Lightning VME in interaction with other VME cards

Please follow this link and use a translator:

Scroll there to the very end of the post.

last update: 06.03.2018 (Gaga)