AmiVNC

0AmiVNC - An experimental VNC server for the Amiga - V0.0.10

Stéphane Guillard - stephane.guillard@steria.fr

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 :

Enabling remote view of the server screen in a window on the client screen
Enabling the use of the keyboard of the client in place of the keyboard of the server
Enabling the use of the mouse of the client in place of the mouse of the server

More can be found on VNC at the VNC homepage at http://www.orl.co.uk/vnc/index.html

1.2 - What is AmiVNC ?

I felt frustrated when I saw on a French magazine ("Dream") a CD including clients & servers for VNC for nearly all platforms, excepted a server for the Amiga !

Starting from the documentation distributed 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 clien t.

1.3 - What is AmiVNC status ?

AmiVNC is © S. Guillard, freeware, 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 2 Amigas :

An A4000 with Cyberstorm 060 MKII, 150 MB RAM, AriadneII, Picasso4, Paloma, Concierto, OS 3.1, MUI, MCP, NetConnect 2sp3 (inc. AmiTCP), Picasso96 1.43b, SAS/C 6.58, SDK AmiTCP4.3, SDK CGFx 4.0
The same machine, booting on another partition, identical except NetConnect -> Miami, Picasso96 -> CybgerGraphics 4
An A2000 with GVP-m G-Force 060, 150 MB RAM, A2065, CyberVision 64/3D, OS 3.1, MUI, MCP, NetConnect 2sp3 (inc. AmiTCP), Picasso96 1.43b, SAS/C 6.58, SDK AmiTCP4.3, SDK CGFx 4.0

2 - Theory of operation

The parameters available are :

The authentication password, which is encrypted and stored in S:AmiVNC.pwd. You can change it in a shell, entering AmiVNC -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 fir st step.
The port number on which to listen for incoming connections. The default is 5900, you can change it on the command line, entering AmiVNC -sxxxx where xxxx is your decimal port number (no space between s and xxxx).

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. Set up your Workbench to 1024x768, 15 or 16 bits (the most efficient depth). Launch your TCP-IP stack.

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

AmiVNC 0.0.10 May 17 1999
(c) 1999 stephane.guillard@steria.fr
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 like the following :

main.c / main : accept()ed socket 4
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 : RTG mode 7
main.c / main : @ 0x410B3290, 1024x768, 2 Bpp, size 1572864
main.c / vProcessIncomes runs on socket 0

When the client is connected, two processes run concurrently :

The main process, "AmiVNC", constantly (thus busily) searches for screen changes (it compares the screen to a buffer), and when it detects changes, it makes up "tiles" (squares) and sends a frame buffer update message to the client. This process eats much CPU, this is why this software requires Executive, which does a perfect job of making your system perfectly useable even with such tasks.

The child process, "AmiVNC handler", non-busily waits for incoming messages from the client, and processes them.

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).

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

You exit 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 halt AmiVNC by selecting its message output window on the Workbench screen, and entering CTRL-C.

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). Tiles are always sent using RAW encoding scheme, which should be supported by all VNC clients.

3 - Requirements
3.1 - To run AmiVNC

You need :

a 15 or 16 or 24 or 32 bit true color Cybergraphics or Picasso96 RTG display for your Workbench screen, which resolution has to be a multiple of 32 (e.g. 1024 x 768).
a TCP-IP stack (AmiTCP or Miami or any bsdsocket.library compliant stack),
enough free ram to hold buffer which size is screen X x Y x 4 (during initial phase) then true screen size,
a fast processor (a 060/50 will be perfect), otherwise the client screen update will be slow,
a computer with a VNC Client (Mac, Unix or Linux box, PC, Amiga)

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 :

SAS/C (I use 6.58)
AmiTCP 4.3 SDK (which can be found on Aminet)
Cybergraphics SDK (I use the one which can be found on the Cybergraphics V4 CD-ROM)

You may have to change SCOpts file to match your settings for include files and lib directories. Edit these files with an editor.

4 - Limitations and future

AmiVNC only deals with the active screen (the screen active when the client connects). It does not bring you the topmost screen when you switch screens. In fact, I don't feel the need for this as I use always the workbench screen for my apps (web tools, development tools etc.). It may be done, but AmiVNC might anyway be limited to RTG chunky screens. The major difficulty here is that the VNC clients do not support changing resolution (a serverinit message sent in the middle of a session makes them crash). I don't know how to handle this… Any taker ?

The active screen should not be moved in memory (ie. You should not open other screens), because AmiVNC relies on the GFX board RAM address of the screen bitmap, which it acquires once when the client connects. If the screen is moved in the GFX board RAM, you will face strange displays on the client ! This is a serious limitation, linked to the previous one. AmiVNC closes the client connection when it detects a screen change.

If you want AmiVNC to show you the mouse cursor, you have to make it a soft sprite (SOFTSPRITE tooltype of Devs:Monitors/<your gfx board>) because it usually is a hardware sprite, and as such, is not fetched in the screen raster. May be fixed by faking a soft mouse cursor even with a hardware sprite, but would have serious impact on performance.

AmiVNC only updates the client screen with a multiple of the tile size (constant XDC_TILE in AmiVNC.c, currently 32). This will be fixed later. This means that if you use a 800 x 600 resolution, a small horizontal band (width : 800 - height : 24) at the bottom of the client screen won't be updated, because 600 is not an integer multiple of 32.

AmiVNC only supports correctly 15, 16, 24 and 32 bit per pixel screen modes. The lack of support of native (non-RTG) Amiga screens and 8 bit screens is due to :

The VNC protocol itself supporting correctly only 15, 16 & 32 bit pixels,
The performance impact of having to "planar 2 chunky" non-RTG Amiga screens before comparing,

AmiVNC handles 8 bit pixels (alias 256 colors, also called Color Lookup Table mode, CLUT), but won't set up a color table for your client. Thus, it may be usable, but your client will have color troubles :-) An ugly color table generation routine could be done... It seems to be only partially supported in the VNC protocol definition. For instance, the usual Win32 client hangs when told 8 bit pixels. Important remark : a client displaying 256 colors does not imply a 8 bit / pixel client / server relationship ! Example : VVA only displays 256 colors, even if on the network, the pixels are 15 or 16 bits.

Executive is highly necessary to lower the priority of the processor-hungry AmiVNC screen update process. With Executive, you don't feel when AmiVNC is running. Without it, I should put a low priority in the code for the main process.

AmiVNC should be turned into an inetd compliant daemon.

AmiVNC does not rely on the TCP stack password file. It could be done. Don't know if it has an interest.

AmiVNC does not properly handle special key events (a few accents like ^, CTRL, Alt, Meta, cursor and Shift). This is not difficult, but yet has to be done.

I have not tested all the RGB mode combinations made available by Picasso96 and Cybergraphics. If you have wrong colors with an untested mode, send an email, I'll fix it (please notify me with your RTG system version, e.g. "Picasso96 1.43b"). Here is a table of the modes and their test status :

Mode	Picasso96 id	CGFX id	Tested	By
8 bit (256 c) - CLUT 24 bit true color R8G8B8 24 bit true color B8G8R8 16 bit PC hi color R5G6B5PC 15 bit PC hi color R5G5B5PC 32 bit true color alpha A8R8G8B8 32 bit true color alpha A8B8G8R8 32 bit true color alpha R8G8B8A8 32 bit true color alpha B8G8R8A8 16 bit hi color R5G6B5 15 bit hi color R5G5B5 16 bit PC hi color B5G6R5PC 15 bit PC hi color B5G5R5PC 15 bit hi color B5G5R5 16 bit hi color B5G6R5PC	1 2 3 4 5 6 7 8 9 10 11 12 13 (none) (none)	0 9 10 7 3 11 (none) 13 12 5 1 8 4 2 6	Y Y Y Y	Author (see above 8bpp) Author Author Author

Even if it lacks a lot of features, AmiVNC is only 24 K in size, which is about 1/10^th the size of Win32 and Unix servers !

5 - Version history

Version	Updates
0.0.10rpa	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.
0.0.9	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 be come 32 bit pixels for sending them (padding with 1 null pixel). 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 !
0.0.8mt	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.
0.0.6	Not multithreaded.

6 - Thanks to

My wife for her supporting many Amigas at home, their fans whirling late at night, my children for the love they give everyday,

The ones who made the Amiga what it is now and which I really LOVE : the perfect nerd platform ! (Hardware : Commodore original design team, VillageTronic, Phase 5, GVP, Janal crew - Software : authors of the jewels : MUI, MCP, SAS/C, Aztec C, Picasso96, Cybergraphics, NetConnect, AmiTCP, Miami, IBRowse, Yam, AmIRC, Microdot, MakeCD and a few other)

Gilles Roy for the tiles idea

Xavier Peyrin for testing with Picasso II and Miami

Stephan Splitthoff for moral support

Geo Amiga for requesting a CyberGraphics version (was done in 10 minutes, thanks to the cybergraphics emulation library in Picasso96)

Steffen Haeuser for a tip about CGFx RTG SDK

Others I forget !