Experimental VNC (Remote Desktop) Server for the Classic Macintosh

[eharmon]

That looks great! Does it ever hang the system for you? I have a theory that on the Mac Plus MacTCP is freezes the computer occasionally simply because it can't keep up and likely has some sort of race condition somewhere related to that. It would be nice if it were more stable on faster systems.

At least from basic testing, I haven't had any problems with it locking up.

A couple issues I did note:

- The native macOS VNC client is confused by miniVNC, it prompts for a password and I get a TCP error on the System 7 side.
- Reconnecting doesn't work. Whenever the VNC view exits, I get a TCP error on the System 7 side.

Might be known issues though . Having a "restart server" button would help reset in those situations.

 

[marciot]

At least from basic testing, I haven't had any problems with it locking up.

A couple issues I did note:

- The native macOS VNC client is confused by miniVNC, it prompts for a password and I get a TCP error on the System 7 side.
- Reconnecting doesn't work. Whenever the VNC view exits, I get a TCP error on the System 7 side.

Might be known issues though . Having a "restart server" button would help reset in those situations.

My implementation isn't exactly standards compliant, I cut several corners to make it more efficient, so this is not entirely surprising. But I might implement password authentication in a future version, that shouldn't be too hard, and at that point it would be nice to see how it performs.

Yeah, I need to work on allowing it to reconnect. I've been sort of sloppy about closing things down properly... up until recently it would simply crash at the machine on exit and I just recently fixed that. So at least now if you want to reconnect, you can quit the app and restart it, which is way better than it was before!

 

[eharmon]

My implementation isn't exactly standards compliant, I cut several corners to make it more efficient, so this is not entirely surprising. But I might implement password authentication in a future version, that shouldn't be too hard, and at that point it would be nice to see how it performs.

Yeah, I need to work on allowing it to reconnect. I've been sort of sloppy about closing things down properly... up until recently it would simply crash at the machine on exit and I just recently fixed that. So at least now if you want to reconnect, you can quit the app and restart it, which is way better than it was before!

No complaints here, great work so far!

 

[marciot]

As a test report, just tried this on my Mac SE with a 40MHz accelerator and a Dayna Pocket SCSI/Link this is actually....usably quick!

Nothing lightning speed but it's certainly tolerable for navigating the file system, running stuffit, etc. This is really awesome!

What processor does your accelerator use? While 40MHz is very, very quick I also suspect an instruction cache and data cache will make a huge difference.

One of the tricks I use in this VNC server is that instead of duplicating the frame buffer to detect changes in the screen, I use checksums over the rows and columns, which is a technique I do not think has ever been used on a VNC server before. Due to checksum collisions, it's an inexact technique that means the VNC server will totally miss some types of changes to the screen, but it is very efficient in memory and speed. On a 68030, I suspect the column checksums could be stored entirely in cache, which would make the change detection blazingly fast.

 

[eharmon]

What processor does your accelerator use? While 40MHz is very, very quick I also suspect an instruction cache and data cache will make a huge difference.

One of the tricks I use in this VNC server is that instead of duplicating the frame buffer to detect changes in the screen, I use checksums over the rows and columns, which is a technique I do not think has ever been used on a VNC server before. Due to checksum collisions, it's an inexact technique that means the VNC server will totally miss some types of changes to the screen, but it is very efficient in memory and speed. On a 68030, I suspect the column checksums could be stored entirely in cache, which would make the change detection blazingly fast.

This is a 68030, indeed. That's a pretty cute trick, what checksum are you using?

 

[marciot]

At first I tried a plain XOR with interesting results on menu items. I then tried a plain ADD in the mistaken assumption it would be better than XOR. It actually is, but only because it means the carry causes the sum of one column to spill into the next, so effectively 32 columns are treated as a group, effectively increasing the odds of detection. However, since I am able to send change rectangles aligned on an 8-pixel boundary, using a 32-bit grouping causes unnecessary waste on the side of the change rectangle, and more network traffic. I tried to be clever by using one 32-bit ADD and an AND with 0xEFEFEFEF to try to get something like four 8-bit ADDs in parallel, but on later reflection, I found out this was wrong in many ways. So effectively my checksum right now is rubbish that probably still chunks things in 32-bit groups, while ignoring every eighth row.

All this was before I read about Flectcher's sums, which is what I probably want to try next, although it would consume twice as much memory as I am now using. Another idea I had was to try a simple XOR again, but intentionally set or clear a single bit on each byte at different positions for each row. This would effectively apply some position dependent noise to the image and make it so things like highlighting or scrolling generated different results without requiring the extra storage a Fletcher sum would require. So, a lot of ideas -- I just have to try them and see what works best.

 

[cheesestraws]

I use checksums over the rows and columns, which is a technique I do not think has ever been used on a VNC server before

That's a good trick. I'm enjoying these techniques you've found .

 

[marciot]

I wonder if it would work with 640x480 at at most 16 colors?

@Nixontheknight: I've been working on this a bit. Here is the first try of a version that runs at 640x480x16. Under Basillisk II emulation, it was sluggish but usable enough for me to complete the System 8.0 Jigsaw app remotely from my smartphone.

Let me know how it performs on your LC II.

 

[Nixontheknight]

@Nixontheknight: I've been working on this a bit. Here is the first try of a version that runs at 640x480x16. Under Basillisk II emulation, it was sluggish but usable enough for me to complete the System 8.0 Jigsaw app remotely from my smartphone.

Let me know how it performs on your LC II.

In my testing (LC III ++ 33MHz) it’s sluggish as well but fairly usable. I imagine 8-bit color would be unusable (if you coded it in) though, as I tried to run it at thousands of colors but it freaked out on VNC, so I’d say the translation of the screen to 16 colors in RAM needs some work but this seems to work well, I’m satisfied. Only other problem is that when you disconnect, it throws up TCP error -23005, but I’m not sure if the error is a red herring.

 

[marciot]

@Nixontheknight Right now, I send the screen data entirely uncompressed, but the VNC protocol provides many compression options. Those would vastly conserve bandwidth on the 256 or thousands of color modes (and maybe even the 16 color mode), but the CPU has to do work to compress a particular region of the screen. Ultimately, it needs to spend less time doing the compression than it would spend sending the data uncompressed. I am going to try implementing some compression and see if I can improve things. That you say it is "fairly usable" right now is a good sign and my guess is that the performance can be improved further by some degree.

The reason it is freaking out with thousands of colors right now is that I don't do any color translation right now. So there needs to be a separate MiniVNC application for each specific color mode or resolution -- this comes from me trying to have it operate as fast as possible. The -23005 error is just what happens when the client disconnects. On my version, I already modified it to restart the server to allow multiple successive connections.

 

[marciot]

@Nixontheknight: Here is a new version that runs in 640x480 resolution at 256 colors. It's fairly slow, but this version is written in C and I still haven't rewritten it in optimized assembly language. Today I picked up a 68020 assembly manual and there are a lot of new instructions on the 68020 and later chips that I can take advantage of. I believe I should be able to push performance quite a bit from this version.

EDIT: Opps, this version is actually for 1024x768 at 256 colors. I'll upload a new file with 640x480.

 

[marciot]

@Nixontheknight: This is the corrected upload that runs at 640x480 at 256 colors.

 

[nottomhanks]

This is super cool! I recently was using Timbuktu on my 2015 Retina to control Timbuktu on an SE/30. It works very well.

 

[Skate323k137]

If you need a plain old http server that is not the macintosh repository so you can grab these without SSL, let me know, I have plenty of server space. Given recent requirements in SSL/TLS the small part of the web we can still browse on HTTP is only going to get smaller. I already have to right click and save, and bypass warnings, in Chrome to download any file from a non SSL host on modern systems.

Anyway awesome stuff here OP!

 

[marciot]

Okay, so I've spent an ungodly amount of time rewriting a lot of this in 68020 assembly language and implementing various encoding strategies for color Macintosh computers. This project has become an unhealthy obsession . Much to my dismay, it still performs poorly in Basillisk II, but I am hoping maybe it performs better on real hardware?

@Nixontheknight: Could you try out this release and let me know how it goes? Do you see any improvement from the previous versions? Is it usable or at least better than Chromium VNC?

I would welcome testing on other color Macintosh computers as well -- these builds should work on any Macintosh with a 640x480 display, but I can make it for other resolutions upon request. Anyhow, I'm thinking of aiming for an official release for #MARCHintosh

 

[marciot]

The source code is now on GitHub, along with the first release! One major improvement is that it is no longer necessary to use a specific executable for each display size or video mode. It now supports whatever resolution or color Mac the machine is running at.

GitHub - marciot/mac-minivnc: A VNC remote desktop server for vintage Macintosh computers, including the Mac Plus.

A VNC remote desktop server for vintage Macintosh computers, including the Mac Plus. - marciot/mac-minivnc

github.com

 

[marciot]

New video update, showing latest performance tweaks and a demonstration on a Macintosh LC II I borrowed from a friend:

 

[LaPorta]

Where's the compiled Mac Application? Wasn't able to find it in there.

 

[mmu_man]

You made it to Hackaday

 

[lisa2]

Nice Job! I wish this supported other resolutions on 68000 black & white systems. I tried running on my Lisa ( 720 x 364 display ), got no errors, but on the client side the display was garbled. My Lisa's are either ( 720 x 364) or ( 608 x 432 screen mod rom ), and yes they are running system 7.5.5
Also like to try this on my Mac Portable ( 640 x 400 ).
Thanks,
Rick