AmiVNC - An experimental VNC server for the Amiga

V1.0.0 for planar & chunky screens

V1.0.0 for planar screens only

Stéphane Guillard -


1 - Introduction

1.1 - What is VNC ?

VNC is a truly thin client protocol which enables the use of one computer (the server) from another (the client), by :

More can be found on VNC at the official VNC homepage .

1.2 - What is AmiVNC ?

AmiVNC is the Amiga VNC server. It enables remote use of your Amiga, from any other platform supporting a VNC client (Windows, Amiga, Linux, BeOS etc.).

AmiVNC executables come in four flavors :

If you want to use an Amiga as the client, you can use the Amiga VNC Client (VVA), which is based on an initial work from Joerg Dietrich, and is now maintained by a very talented French programmer, Denis Spach. VVA is available at (

If you want to use any other system as a client, please download the client for your platform at the official VNC download page.

Starting from the documentation available with the source for VNC servers for X11 and Win32, I brought up a prototype VNC server for the Amiga. It does not pretend to be complete (by far), but it works on my setup, and I use it from a Win32 VNC 3.3.3R2 client, and from VVA.

1.3 - What is AmiVNC status ?

AmiVNC is © S. Guillard, freeware, provided with its StormC4 project & source code, and can freely be enhanced, as long as you send me your enhancements :-)

I would be happy to have feedback from testers and developers in order to enhance it. I work on it at spare time.

1.4 - Foreword on my setup

I develop and test AmiVNC on 3 Amigas :

AmiVNC is also tested w/ Picasso96 1.43b & Miami.

2 - Theory

The basics are :

The Amiga has (from AmiVNC programmer's point of view) four display philosophies :

To be usable, AmiVNC has to know how to deal with all these 4 philosophies. Thus, on the "input" side, AmiVNC must know how to make true color pixels (the only ones supported by the VNC protocol) out of planar, palette chunky and true color chunky screens. This is true since v0.0.15. To be efficient, AmiVNC directly reads (when it can) the memory from graphics boards, to avoid conversion functions. Thus, AmiVNC is much faster with 16 bit gfx modes sent as 16 bit pixels to the client than it is with 8 bit planar modes sent as 16 bit pixels, or 32 bit gfx modes sent to VVA as 8 bit pixels.

On the output side, in theory, the VNC client could ask for any arbitrary true color pixel encoding (eg. 8 bit R, 8 bit G, 8 bit B, or 2 bit B, 3 bit G, 3 bit R, or whatever). If we had to support all combinations of input and output formats, AmiVNC would be a monster. So I have chosen to only support 3 output encoding schemes :

Another issue is the encoding schemes. The VNC protocol defines various encoding schemes for screen updates. AmiVNC supports none of the advanced encoding schemes described in the VNC protocol documentation. Instead, it deals with squares called Tiles in the source, of which you can modify the size (constant XDC_TILE in AmiVNC.c). For my setup, 32 x 32 pixel tiles are a good compromise between screen update speed and network efficiency (I use a 16 bit workbench screen and a 10 Mb/s Ethernet link). Tiles are always sent using RAW encoding scheme, which should be supported by all VNC clients. Tile size always should be a multiple of 8.

3 - Operation


Command line (AmiVNC …)

AmiVNC icon Tooltype

Set authentication password, which is encrypted and stored in S:AmiVNC.pwd

-pxxx where xxx is your (8 char max) password (no space between -p and xxx). It will update your password file. Do it as your first step. AmiVNC then exits.


Set port number on which to listen for incoming connections. Default is 5900.

-sxxxx where xxxx is your decimal port number (no space between s and xxxx).


Force log to stdout (verbose). Default is log into logfile.



Limit network blocksize (to limit collisions) when sending initial framebuffer update. Default is no limit.

-lxx where xx is anything between 1 and 0xFFFFFFFF ; I would suggest 1024 if you really have network problems.


Set logfile name. Default is T:AmiVNC.log



Set command to execute when user connects. Default is no command.


PRESTART=<command>. %s will be replaced by client IP address.

Set command to execute when user disconnects. Default is no command.


POSTSTOP=<command>. %s will be replaced by client IP address.

Force Big Endian. Default is little endian. Useless. Will be removed.



Force RGB bitshifts with 3 byte pixels. Defaults are RShift = 8, GShift = 16, BShift = 24. Useless, will be removed.

-rxx, -bxx, -gxx where xx is taken in { 0, 8, 16, 24


Enable BGR233 pixel encoding



Force n ms delay between two screen change scans. Default is 50.



You should at least set the VERBOSE tooltype, to see what happens at the beginning. Then, afterwards, you can remove the VERBOSE tooltype and have a silent AmiVNC running in the back, without a CLI output.

Turn your mouse pointer into a soft sprite (for Picasso96 : set the SOFT-SPRITE tooltype of Devs:Monitors/<your gfx board> to Yes ; for cybergraphics, there must be some env var to set). Then reboot to take this into account.

Efficient use of the Amiga VNC client (VVA) is possible. I added support for the specific 1 byte true color pixel encoding required by VVA (BGR233). To enable this, use -a on the command line or enable VVA tooltype in AmiVNC icon.

VVA specific encoding also works with other clients. As pixels are 1 byte, it is a faster mode than normal 2 or 4 byte pixels.

You can use any RTG screen (8 bit up to 32 bit pixels), or any native planar Amiga mode (1 to 8 bit pixels). 256 color RTG screens ARE supported, as well as all other RTG modes.

 *** IMPORTANT ***

If you have Picasso96 or Cybergraphics installed, and want to use AmiVNC with both planar (native Amiga mode) and chunky (GFx board) screens, use the normal version.

If you try to use this version without either Picasso96 or Cybergraphics installed, AmiVNC will cry about "can not open version 0 of cybergraphics.library".

If you don't have neither Picasso96 nor Cybergraphics, and thus want to use AmiVNC with native Amiga screens, use the version "planar only".

Both versions are built for 68060. I see no reason for which they would not run on 020, 030 or 040.

Launch your TCP-IP stack.

Then you launch AmiVNC on your Amiga (Shell or WB). It should output something more or less like this :

AmiVNC 0.1.0 Mar 1st 2001 (VVA support)
(c) 1999-2001
main.c / main : parameter values :
- listen port set to 5900
- endian set to little
- initial xfer limit set to FFFFFFFF
- color bitshifts : red 8, green 16, blue 24
main.c / main : Creating listener socket
main.c / main : Binding socket on port 5900
main.c / main : Listening set on port 5900
main.c / main : Waiting for client connection

Then you launch a VNC client on another computer (local connections are meaningless and crashfull), and you can remotely operate your Amiga (with limitations due to the experimental nature of AmiVNC, mentioned above). At this step, the server outputs something more or less like the following :

main.c / main : accept()ed connection from on socket 5
main.c / main : Negociating protocol version
main.c / main : Protocol supported by server : 3.3, by client : 3.3
main.c / main : Authentication

An initial phase takes place for establishing the session (mainly authentication by inputting password on the client, protocol version negotiation, pixel format negotiation). If authentication is ok, the server out puts something like the following :

main.c / main : ClientInitialisation
main.c / main : SharedFlag = 0 (multiple clients : No)
main.c / main : Screen set to [Amiga Workbench 1 930 968 RAM graphique 118 959 576 autre RAM] (RTG)
main.c / main : RTG mode Pic96/7 @ 0x410B3290, 1024x768, 2 Bpp, size 1572864
main.c / vProcessIncomes runs on socket 0

When the client is connected, two processes run concurrently :

This dual threaded model is necessary due to the very busy nature of the main process. It enables smooth mouse and keyboard operation, taking place at the same moment as screen updates.

The link between the client and the server is a TCP-IP socket bound to port 5900 on the server (5900 is the VNC default, you can change it using the -s command line argument or the PORT tooltype).

Then, you should be able to play with your Amiga in the VNC client window (although AmiVNC still lacks features, as said above).

You end the session by closing your client. The server then outputs something like the following :

main.c / vProcessIncomes halted
AmiVNC - main.c / main : send() error (32)
AmiVNC session closed
main.c / main : Waiting for client connection

AmiVNC is now waiting for another incoming connection.

You can cleanly halt AmiVNC by sending it a BREAK C when the server is waiting for incoming connections. AmiVNC should then say :

AmiVNC - main.c / main : accept() error (4)
AmiVNC session closed
AmiVNC halted

3 - Requirements

3.1 - To run AmiVNC

You need :

3.2 - To build AmiVNC

AmiVNC is fully written in C. DES authentication is done using 2 C files almost unchanged from the Win32 source distribution : d3des.c and vncAuth.c, and their associated header files. See in these files for copyright information.

To compile it using the source included in the archive, you need :

You may have to change the project options to match your settings for include files and lib directories.

4 - Limitations and future

Before asking me about a VNC problem, read above and read

5 - Version history




Thanks to dspach, solved this longstangind mouse scale bug.

Furthermore, mouse button supoprt is now compatible with MagicMenu and other stuff.

Added 68020 versions in the distribution.

Executable is now 1/2 its previous size (some 35K instead of 70K), faster and more stable ! Thanks to StormC4.


Reworked to compile with StormC4/GCC. Code is faster and more stable.

Added Intuition locking to avoid some race conditions.

Added delay parameter (defaults to 50 ms) between 2 screen scans. Makes your system smoother without too much incidence on the client side.

First attempt at a PPC version : wow, works well. Will be released soon.

I guess there is something weird in some versions of the creat() system call, which are shown above in v0.0.14, which also generate trouble in using StormC4/GCC over a PFS3 partition.


Added some UAE support & help ; You can run AmiVNC in WinUAE (provided you enabled bsdsocket emulation in WinUAE configuration), but it may crash. Strange behavior of ObtainSocket() under WinUAE.

Accept() bug fixed.


Added VVA support : BGR233 pixel encoding (enable this with VVA tooltype or -a on the command line). Reduces all screen modes to 256 colors, speeding things a bit.

Palette refreshing bug fixes for palletized screen modes (planar and chunky).


Bug fix : password setting with S: in an AFS or PFS filesystem did not work. Reason : AmiTCP net.lib (with which I link) strangely alters creat() behavior. Now using Open().

Bug fix : when stopping AmiVNC with CTRL-C signal, memory was freed twice. Reason : I had not understood what CXBRK() is.


Added support for 256 color RTG screen modes (at last !). Indeed, when I saw working 256 color planar modes I thought it would not be that hard to have 256 color chunky modes too ! Now, there should not be that many screen modes not supported.


Added a planar only version, for users who don't have Picasso96 neither Cybergraphics at all. This "planar only" version will only be able to deal with native Amiga screen modes (OCS, ECS, AGA).


Added support for Amiga planar modes (YES, AT LAST !).

Removed the StopAmiVNC tool. To properly stop AmiVNC, feed it with a BREAK C (only when it is waiting for incoming sessions). If you use Executive, you can use Commander for this purpose.

Added icon Tooltypes to set parameters.

Added user commands to be executed when client logs in or logs out.

Added log to file, thus silent mode.

A few bug fixes.

Documentation update.


Added the StopAmiVNC tool, to properly stop AmiVNC (only when it is waiting for incoming sessions).

Enhanced keyboard support (supporting arrow keys, CONTROL, SHIFT, Lamiga = Lalt, Ramiga = Ralt etc.). Better, but still not perfect.

Enhanced mouse support (handles ieQualifier). Better, but still not perfect : in YAM, you can drag your messages but when they come onto a drop area, they are unselected.

Allows screen change IF new screen is the same RGB mode. I did not think it would be very useful, but indeed I use it ! Aborts connection when screen changes if new screen mode is different (as said somewhere above, the VNC clients abort when they receive a mServerInitMsg message in the middle of a session, and this message is necessary to change the resolution).

More command line options :

-e to force Big Endian flag

-(r|g|b)<value> to force red | green | blue bit shift on color encoding, useful if you have color trouble. Legal values are 0, 8, 16, 24. Default is -r8 -g16 -b24.

-l<size> to limit network packet size when sending initial screen update. Useful if you have too many network collisions. Default is no limit.

Speed restored under Picasso96 with screen depth = 16 bit pixels. Still slower under CGFX or with screen depth > 2, because still using ReadPixelArray for compatibility, and sending 4 byte pixels. Will try to fix that.

A few bug fixes.


Deals with active screen, not necessarily Workbench (this does not mean you can open a screen in a session !).

No longer a one shot daemon. You can re-connect. Stop with CTRL-C when the server is waiting for connections (if you break it t another state, you may loose memory).

Corrected acquisition of raster pointer, which worked under Pic96 but not under CGFx. Thanks to Steffen Haeuser.

Changed all color encoders to ARGB (32 bit on the wire), and ReadPixelArray(). This is slower, but works with all CGFx and Picasso96 screen modes with depth > 8. As a side effect, AmiVNC is even smaller than before !

This version is successfully running on my setup, with both AmiTCP, Genesis or Miami as a TCP stack, and Picasso96 or CFGx 4 as RTG system.


Useable with Cybergraphics AND Picasso96 (I use the cybergraphics.library calls for fetching screen info, and it works also with Picasso96 emulation library. I personally use Picasso96, and own both systems). Fetches screen info through cybergraphics.library calls, not directly in the bitmap structure.

Enables setting the port number ("-s" argument), because users reported that Siamese uses the same port as VNC : 5900.

Supports 24 bit pixels. AmiVNC already supported 8, 15, 16, 32 bit pixels, but lacked 24 bit pixels. It is much slower than 8, 15/16 or 32 bit pixels, because of the performance impact of having to make 24 bit pixels become 32 bit pixels for sending them (padding with 1 null byte).

Works with Miami ! I made a bug in the ObtainSocket() call in the child process, which did not trouble AmiTCP. Thanks Xavier. Excuse me Holger !


History really starts there. Previous versions were not really usable releases, even if this one is still far from complete. First version released on Aminet. Does not support 24 bit pixels. Does not enable choosing the port.


Not multithreaded.

6 - Thanks to