[Not a Issue] Just a demo of a VNC (Remote Server) for Classic Macs using the RaSCSI as an Ethernet bridge

[marciot]

Hi everyone,

This is not a bug, it's just a demonstration of a project I have been working on since last year that makes use of the RaSCSI. It is an experimental remote desktop server for classic Macintosh computers:

YouTube

To my knowledge, it is the first VNC server that can run on a Macintosh computer with a 68000 processor (there was at one point something called ChromiVNC but that required Open Transport and at least a 68030 CPU).

Anyhow, this project is pretty much a work-in-progress and it's not tremendously stable or usable for real work. Not sure whether it's my code or whether MacTCP is inherently unstable. Does anyone here have any development experience with MacTCP and can tell me whether they've had problems with it crashing under load?

Anyhow, if you want to learn more about how I accomplished this, please subscribe to my channel. I had to rely on a lot of technical hacks to get this to work and I've definitely gone down some very deep rabbit holes.

If there is interest, I might post a video with a more behind-the-scenes look at this project and the coding hacks I had to do to make this work :grin:

[uweseimet]

@marciot Wouldn't it be better to place information like this on a website or in Discord, for instance? The ticketing system should be used for bugs and enhancement suggestions only.

[marciot]

@uweseimet: I'm sorry. I just thought maybe some folks here might be interested in seeing what could be done with the RaSCSI and I didn't mean for it to come across as spam.

[uweseimet]

@marciot I am sure some folks are interested, but the ticketing system is meant to be used for development purposes. I (and others) regularly scan it for issues (bugs, suggestions), and finding videos instead is not so nice. @akuker Maybe it makes sense to have a section in the Wiki where information/links on projects that make use of RaSCSI can be placed? This would also make it easier for users searching for this kind of information to find it, without interfering with development-related issues.

[marciot]

@uweseimet or @akuker: GitHub also has a Discussion board feature that might be appropriate. It can be enabled via Settings -> Features.

[uweseimet]

@marciot Maybe it is appropriate (I don't know this board feature), but I wonder whether it is a good idea to have additional channels for discussions besides Discord. I don't have any strong opinion on that (I don't use Discord anyway), but just want to point out that several locations/tools for similar things (discussions) will not necessarily be an improvement.

[marciot]

@uweseimet: I know some open source projects use Discord, but I've never used it myself. It's one more thing to sign up for and it also appears to be tailored for "live" chat, sort of like IRC. While I might be mistaken about that, it has never appealed to me for that reason.

[rdmark]

@marciot This seems like a great topic for a new thread under https://tinkerdifferent.com/#the-lab.115 or https://68kmla.org/bb/index.php?forums/hacks-development.32/ ! The RaSCSI project itself started on the latter, so you'd be in good company. :)

[uweseimet]

@marciot I also don't find Discoard appealing; IMO it's very intrusive. But anyway, if you have several forums for discussion some users use this forum, others use that forum. All in all a small community might split into even smaller communities ;-).

[marciot]

@rdmark: I had already posted to 68kmla. Thanks for reminding me about tinkerdifferent.com.

@marciot All in all a small community might split into even smaller communities ;-)

@uweseimet That's true. I'm perfectly content if you guys rather redirect discussions to 68kmla or thinkerdifferent. That probably gets the RaSCSI project more exposure anyway.

[marciot]

Anyway, to make this topic somewhat more relevant to RaSCSI, I would like to eventually implement something like the ScuzzyGraph II. This would necessarily involve have more processing done on the RaspberryPi and writing a new target device for RaSCSI. Writing the VNC server was an excuse in learning how to write low-level driver code for classic Macs.

[uweseimet]

@marciot If you want to add a new device type (i.e. a processor device with features not covered by an existing device type) you might want to have a look at the implementation of the SCRA device type in the "feature_scsi_shutdown" feature branch for an example.

One thing that should be addressed soon is to rewrite the object inheritance hierarchy, so that non-disk devices do no inherit from the Disk class anymore. That fact that this is (still) the case is becoming more and more of an issue. There is already a corresponding ticket: https://github.com/akuker/RASCSI/issues/179.

[marciot]

It might be nice to have the capability to add custom SCSI target devices without re-compiling RaSCSI. I could see this done via a generic SCSI target that created either a network socket or a named pipe on the Linux file system, which another process would then read and write to. Something like this would allow targets to be written in languages such as Python or even via node.js, which would accelerate development. I was browsing through a SCSI book yesterday I read about a generic “communication device” that might make sense in this context.

Of course, that’s only one way to solve the problem of getting data in and out of the Mac fast. Another might be to implement a high performance MacTCP replacement for the Mac that offloads all the extra work of packet fragmentation, reassembly and error checking to the RaspberryPi. This may perform faster than the DynaPort/MacTCP solution, which I think has the Mac performing those tasks (or not, I don’t know exactly how the DynaPort works)

Using TCP/IP rather than a custom protocol is nice because Basillisk II supports it, so you can do software development and testing there, which is way more convenient than having to use real hardware.

[marciot]

Ummm, I just looked at the RaSCSI DaynaPort emulation code and it appears to pass whole packets via SCSI, leading me to conclude the DaynaPort was in fact an Ethernet accelerator in its heyday. This may explain why I am not seeing packet fragments in my app and may also explain why the DaynaPort installer patches the MacTCP file itself -- its probably replacing it with a pass-thru driver and discarding most of the functionality. Interesting.

Anyhow, I might consider writing directly to the DaynaPort SCSI target from my app to see if I can eek out some more performance out of it. This might do as well as a custom SCSI target and simplify my life during development. No use reinventing the wheel...

[akuker]

I would like to eventually implement something like the ScuzzyGraph II.

I'm one step ahead of you!! I have a very early implementation of the Radius PowerView emulation: https://github.com/akuker/RASCSI/wiki/PowerView---SuperView

Several users have been able to get the PowerView emulation working on their systems. You need to use "wish-i-were" for some machines to trick the PowerView drivers into thinking you're a Classic II. (This is a limitation of Radius's driver)

I'm happy to open the discussions option in Github. It would be a good way to communicate with the folks who aren't on Discord.

[marciot]

I'm one step ahead of you!! I have a very early implementation of the Radius PowerView emulation: https://github.com/akuker/RASCSI/wiki/PowerView---SuperView

Interesting! I'll definitely have to check this out!

I don't really have the space to hang an extra monitor off my Raspberry Pi, so I was going for a remote desktop solution. But it might be interesting to take the work you did, tweak it to write to a VNC framebuffer instead and then add an INIT that runs in parallel to the PowerView driver to handle mouse and keyboard control via a separate SCSI target.

[marciot]

@akuker I am browsing through the code for the "feature_powerview" branch and I am a bit confused. I see some framebuffer and palette init code in "src/raspberrypi/devices/scsi_powerview.*" but couldn't find any code related to the TMS34010 emulation. Am I missing something?

[marciot]

Oh, so it looks like the magic happens in CmdWriteFramebuffer. So it appears the TMS34010 is just being used as a remote framebuffer and the host does the heavy lifting. That’s quite surprising, considering the TMS34010 is a full 32-bit processor and it could be doing so much more. I guess I now see why it isn’t necessary to emulate the TMS34010 at all :shrug: