Xlink xwizard manual

And we launched ExecMode to help organizations solve really ugly technical challenges. Last Modified From To. Reset Search Submit Search. Allows advanced configuration including syncing with Skype. Please note: this rating is from several versions ago, and is considered inaccurate for the latest versions of CrossOver. About Ratings Rating Breakdown Advocates. Install Now. Buy Now. App Id. About the Rating System Once you have CrossOver installed and running you can come back to this page and click the Step 2 button, or follow the manual installation guide , to begin installing your Windows application.

There is no need to update the software in a new XLink purchased from us or through our authorized resellers. They come with uptodate software installed. Please note that you must install the software before connecting your XLink to the computer with a USB cable.

At this time the XWizard runs on Windows 8 and Windows 10 computers. Any other use is stricly forbidded. Xtreme Technologies Corp. Home Products Support Buy now. Developer has developed and licenses to users its software program marketed under the name XWizard PC Software the "Software". Licensee desires to utilize a copy of the Software. Developer hereby grants to Licensee a non-exclusive, limited license to use the Software in the country of residence of Licensee as set forth in this Agreement.

Licensee shall not sell, lease, rent, modify, add to, remove from, change, copy, duplicate, reproduce, license or sublicense the Software, or transfer or convey the Software or any right in the Software to anyone else without the prior written consent of Developer. If the server responds to another ping within three seconds, then the remaining commands if any are executed.

This command requires the server to be installed permanently so that it is available after reset. Use address to specify the start address for the server code. If the address corresponds to the machines default basic start address, then the server can be started with RUN. This is the default if no address is specified. Note that the resulting kernal will no longer support tape IO. This allows patching the combined 16 or 32k roms of the C, which contain the kernal code in the upmost 8k.

The reset procedures of the respective machines have been modified to speed up development cycles. On the C64, the memory check on startup has been made optional and is skipped by default unless the commodore key is held down during reset.

On the C, automatic boot from disk has been made optional and is skipped by default unless the control key is held down during reset. Write random data into memory, then read it back and compare it to the original data while measuring the achieved transfer rates. If no address range is specified, a default range of freely usable ram in the standard memory configuration is chosen for the respective machine.

If an address range is specified that overlaps with rom or io, the data received will differ from the data send, and the comparison will fail. Note that this program will fail silently if an error occurs. The next section describes how to handle errors. Most xlink functions return true on success and false on failure. If debugging is enabled, detailed debug messages will be written to stdout. Returns the library version as an unsigned char, where the high nibble contains the major version and the low nibble contains the minor version.

The API will remain consistent across major versions. Minor version bumps will only occur if new functions are added. Should functions be removed or other breaking changes become necessary this will be reflected by a bump of the major version. Returns true if a device has been sucessfully initialized. Returns a pointer to a string containing the device specification for the device currently in use.

If no device has been initialized yet, the string will be empty. Do not modify the returned string. Sets the device specification to path and tries to initialize the device.

Returns true if the device has been successfully initialized. Sends a strobe signal to the server and returns true if the server responds with an ack signal within ms. Note that this only checks whether something on the C64 side has acknowledged the strobe. This might be an xlink server ready to receive commands, but it might also be an xlink server gone astray hung in a previous transfer , or something else altogether. Currently the xlink server will respond with 0x This works whether or not a server is running on the C If a parallel port cable is used, additional circuity is required for this to work.

Try to make sure that the server is ready. First, the server is pinged. If the server responds to another ping within the next 3 seconds this function returns true. If the initial ping succeeds and a basic program is found running on the C64, a basic warmstart equivalent to pressing runstop-restore is performed prior to returning successfully. Loads a ram-based server to the given address and passes control to it, effectively disabling the currently running server.

Note that no additional checks are performed. The address argument specifies the source or destination address or address range. For transfers involving more than one byte of data, wrapping may occur if the size of the transfer exceeds the machines address space. These arguments are equivalent to the memory configuration options described above. In addition, the most significant bit of the memory value controls whether screen blanking should occur during transfers.

Set this bit to prevent screen blanking for the load, save and fill operations i. Load size bytes of data obtained from the memory area pointed to by data to address in the target machine memory.

Read size bytes of data beginning from address in the target machine memory and store the result in the memory area pointed to by data. The caller has to make sure that enough memory is allocated for data beforehand.

Read the byte at address from the target machine memory and store it in the memory location pointed to by value. Write value to address in the target machine memory.

Fill the target machine memory with size bytes of the constant value value beginning at address. Make the target machine jump to the specified address. Prior to jumping, the stack pointer is reset and the address of the basic REPL Read-Eval-Print-Loop is pushed on the stack, followed by the actual jump address. Then the supplied memory config is applied, clean processor flags and registers are pushed onto the stack and the jump is performed via RTI, leaving the current invocation of the IRQ routine servicing the request.

This is equivalent to issuing RUN on the target machine. The low level API provides a way to implement custom commands or communication schemes in your own programs without requiring changes to the server code running on the users remote machine. This code is then responsible for performing the subsequent low level communication with the client. The client in turn can use the functions of the low level API to communicate with the server.

This will be explained in greater detail later in this document. In order to implement the server side code serving custom commands it is necessary to understand the underlying technical implementation. In this section I will describe the implementation and its implications while offering a simple set of macros that can be used to implement a custom server on the C The section is concluded with a simple example for a custom server and a corresponding client.

The first line is used to send a handshake signal from the PC to the C This bit is set when a falling edge occurs, and is cleared when the register is read. Thus to send a handshake signal to the C64, the PC generates a falling edge on the flag line. We define a macro called wait containing this code. The second line is used to send a handshake signal from the C64 to the PC.

To send a signal to the PC, the C64 simply flips the value of this bit. The PC can thus detect an incoming signal from the C64 by listening for changes on this line. We define two macros called strobe and ack containing this code. See negotiating direction for details. On the client side the port is always kept in input mode unless the port is actually used to send data to the server.

On the server side, we should always make sure that the port remains in input mode unless output mode is actually required. Thus, the code we inject should always initialize the port and our handshake lines correctly first:. We define a macro called init for this. The transfer direction of the data port must be negotiated with care between the two machines.

If both ports were set to output, either port may be damaged by short circuits, depending on the actual levels the individual port lines are driven to. The logic needed for negotiation of transfer direction is abstracted away by the low level functions on the client side.

On the server side, code must follow the assumptions made by the low level functions on the client side. In order to negotiate the transfer direction and to switch the direction during a communication session the handshake lines are used for synchronization.

When the direction should change, the currently receiving side may switch its port to output and thus become the sender only after having received a signal from the current sender acknowledging that is has already set its port to input and thus has become the receiver.

We define a macro called output for this. Likewise, if the C64 is currently sending, it must set its port to input first and then acknowledge the switch to the PC:.

We define a macro called input for this. If the C64 takes the role of the sender, we can use the following code to send one byte of data from the accumulator:.

If the C64 takes the role of the receiver, we can use the following code to receive one byte of data and store it into the X register:. We define macros called send and receive for this. We now have the necessary macros to implement a custom server on the C init , input , output , send and receive.

It will send an identify command and output the results, followed by a quit command to quit the injected server again. The low level functions are based on a concept of communication sessions. This is necessary because at the begin of a session, the roles of the PC and the C64 are not defined yet: while xlink is based on the assumption that usually the PC is a client that sends commands that are served by the C64, a reversal of these roles is possible just as well: in this case the PC could take the role of the server, listening for and servicing commands send by the C To make this possible, the initial setup of transfer direction does not require handshaking.

Instead, it is assumed that both sides are in input mode at the beginning of a session, and that either side may initiate communication by simply setting its port to output and sending a command to the other side. After this initial transfer has been send though, any subsequent change of transfer direction requires proper negotiation through the exchange of handshake signals as described above.

The low level send and receive functions automatically detect whether the transfer direction changes and perform the necessary negotiation.