AmiVNC

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 - stephane.guillard@steria.com

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 viewing 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 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 :

RTG and planar : use these 68020 or 68060 versions if you have a RTG system installed (Picasso 96 or Cybergraphx). It is compatible with RTG and native screenmodes.
Planar only : : use these 68020 or 68060 versions if you have no RTG system installed. It is compatible with native screenmodes only.

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 http://dspach.free.fr (mailto:dspach@free.fr).

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 :

An A4000 with Cyberstorm PPC 060/233, 150 MB RAM, AriadneII, CybervisionPPC, Picasso4, Paloma, Concierto, OS 3.9, MUI, MCP, NetConnect 3 (inc. AmiTCP/Genesis), CyberGraphics 4.2p8, StormC4/GCC, SDK AmiTCP4.3, SDK CGFx 4.0
An A4000 with Cyberstorm MK2 060/40, 150 MB RAM, A2065, Cybervision 64/3D, OS 3.9, MUI, MCP, NetConnect 3 (inc. AmiTCP/Genesis), CyberGraphics 4.2p8, StormC4/GCC, SDK AmiTCP4.3, SDK CGFx 4.0
An A2000 with GVP-m G-Force 060, 150 MB RAM, A2065, Picasso 4, OS 3.5, MUI, MCP NetConnect 3 (inc. AmiTCP/Genesis), CyberGraphics 4.2p8, StormC4/GCC, SDK AmiTCP4.3, SDK CGFx 4.0

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

2 - Theory

The basics are :

One process (the main one) waits for incoming connections. When one comes in, an authentication phase takes place, a child process is created, then the main process scans for screen changes and feeds the client with these changes (in theory, when the client requests these changes, but also works when the server unattendedly sends changes to the client, which is the case of AmiVNC).
The child process processes incoming queries from the client : key hits, mouse moves etc. Events from the client are inserted into input.device as if they were really coming from the server's mouse & keyboard.

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

Planar screens, made by the original Amiga chipsets (OCS, ECS, AGA). In these screens, there is a palette associated to each screen, giving the red, green, blue true color values for 2 to 256 color definitions, and each pixel is spread over several (1 to 8) bitplanes. To actually display a pixel, the chipset fetches one bit per bitplane, combines these bits into a color number, looks into the palette to obtain the corresponding RGB values, and finally sends these values to the monitor.

Chunky palette screens. These screens are available with graphics boards and RTG systems like Picasso96 or Cybergraphics. They are the "8 bit" modes. It is globally equivalent to planar screens : you have a 256 entries palette, and to display a pixel, the board fetches its color number from the display memory, and looks into the palette to get the RGB values. The difference is the memory organization : you only have one byte plane, and a pixel color value is one byte in the byte plane. This eases the process.

Chunky true color screens, with Picasso96. In these 15, 16, 24 and 32 bit modes, the RGB values are directly stored in the display memory, thus there is no indirection using a palette. The programming functions are in the "picasso96api.library".

Chunky true color screens, with Cybergraphics. Same as above… except some differences which make programming more difficult. The programming functions are in the "cgxsystem.library".

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 :

BGR233 for compatibility with the Amiga VNC client, VVA, which knows this efficient format,
RGB16 and ARGB32 for all other clients. The mode selection here depends on the server screen format : planar and chunky 8, 15 and 16 bit screens are sent as 16 bit pixels. All other screens are sent as 32 bit pixels.

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

Parameter	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).	PORT=xx
Force log to stdout (verbose). Default is log into logfile.	-v	VERBOSE
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.	LIMIT=xx
Set logfile name. Default is T:AmiVNC.log		LOGFILE=<name>
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.	-e	BIGENDIAN=TRUE \| FALSE
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	RSHIFT=xx GSHIFT=xx BSHIFT=xx
Enable BGR233 pixel encoding	-a	VVA
Force n ms delay between two screen change scans. Default is 50.	-dxx	DELAY=xx

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 stephane.guillard@steria.com
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 168.0.128.53 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 :

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 runs fine with 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 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 :

Any Amiga screen (native planar mode as PAL or NTSC, or RTG (Cybergraphics or Picasso96) 8 (256 color, now supported), 15 or 16 or 24 or 32 bit modes (the screen which is considered is the frontmost one when the client connects (Workbench screen or Dpaint or any other one).

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 byte (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 :

StormC4/GCC
AmiTCP 4.3 SDK (which is included in StormC4)
Cybergraphics SDK (which is included in StormC4) (not necessary for the planar only version).

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 http://www.uk.research.att.com/vnc/faq.html.

Even if it lacks a lot of features, AmiVNC is only around 70 K in size, which is about 1/3^rd the size of Win32 and Unix servers !

AmiVNC may switch screens, but only if the new screen is the same format as the one which was active when the client connected. VNC clients do not support changing resolution (a serverinit message sent in the middle of a session makes them crash). We will have to wait for a protocol evolution (attn ATT ?-). Same format means same Width & Height for planar Amiga screens, and same Width, Height and Depth for RTG screens.

If you want AmiVNC to show you the mouse cursor with a gfx board, you can make it a soft sprite (SOFTSPRITE tooltype of Devs:Monitors/<your gfx board> with Picasso96) 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.

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 could be turned into an inetd compliant daemon relying on the TCP stack password file. Don't know if it has an interest.

AmiVNC does not fully handle certain mouse events and certain key combinations.

I have not tested all the RGB RTG mode combinations made available by Picasso96 and Cybergraphics. If you have wrong colors with an untested mode, send an email, I'll try to fix it (please notify me with your RTG system version, e.g. "Picasso96 1.43b" or "Cybergraphics 4.1").

A PPC / WarpOS version exists (not finished). Works faster, and eats no CPU on the 68K side ! Wonderful.

5 - Version history

Version	Updates
1.0.0	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.
0.1.0	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.
0.0.16	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.
0.0.15	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).
0.0.14	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.
0.0.13	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.
0.0.12c	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).
0.0.12	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.
0.0.11	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.
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 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 !
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, special mention to Dave Haynie, 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)

Denis Spach for kindly giving me access to its mouse handling source code

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

Matthias Scheler for tips about mouse events and color encoding and coding "the Right way".

Magnus Eriksson, David "The millis Cats", izod@smail.com, Francis Labrie, Nicholas Piper, and a few others to ask for native Amiga screenmode support : indeed, it was not that hard.

Francis Labrie for requesting user commands at log in / log out : good idea !

Others I forget !