search

larsbrinkhoff / vector-terminal

General purpose vector terminal
4 stars 1 forks source link

Remote vector display protocol #4

Open larsbrinkhoff opened 3 years ago

larsbrinkhoff commented 3 years ago

Prototype a protocol for a remote vector display slash terminal.

Emulated displays in consideration (more to follow?):

Real displays in consideration:

Input devices:

Use cases:

Transports:

Random thoughts:

CC @aap, @qu1j0t3, @toby5box, @rcornwell

larsbrinkhoff commented 3 years ago

Some kind of compression between successive display "frames" (display lists) is desirable. Delta against previous?

I'd like to investigate something very simple but maybe good enough: No detection of deltas at all, just use zlib. There is an API to "synchronize" points in the compressed stream (Z_SYNC_FLUSH) which is crucial for a receiver to decode a full frame.

larsbrinkhoff commented 3 years ago

@aap made a protocol specific to the 340, but it's just a stream of points.

larsbrinkhoff commented 3 years ago

Graphic primitives:

Need a way to specify intensity. The color scope does colors.

qu1j0t3 commented 3 years ago

I've done a bit of thinking about this. My advice is to focus on the highest priority or most useful historical device and its capabilities and make sure it is well suppported. I wouldn't begin to speculate about advanced primitives like arcs until the new hardware exists to render them. My main focus was polylines since they are the most useful.

The big challenge to me is not defining the protocol, but solving the architectural problem: imho the impedance mismatch between hardware on the other side of USB, and the emulator, which may be emulating a display processor. This means that the properties of the transport (e.g. USB, iso, hid, etc) and the emulation strategy (deltas, display lists, etc) all must be considered when designing the whole solution. And because of that complexity, I think it helps to let a single desirable historical device drive the tradeoffs. My early thinking was around Imlac PDS-1 and PDS-4, for example.

Where there is no display processor, e.g. host driving display HPGL-like, the tradeoffs might be different and the protocol might be different. Or perhaps the protocol could fully support both modes.

(I don't think I want zlib compression for either display lists or deltas.)

My position at the moment is:

larsbrinkhoff commented 3 years ago

I started this https://github.com/larsbrinkhoff/vector-terminal which for now displays using C and SDL2, or JavaScript and HTML canvas. Main test device are III displays; SAIL had six of them.

larsbrinkhoff commented 3 years ago

CC @sebras

larsbrinkhoff commented 3 years ago

For now the protocol has three messages.

I'd like to do something clever to avoid sending the same display list over and over, but the III hardware doesn't have a clear way to signal the start of a new display frame.

For user input, messages send key presses as a message type prefix and a USB key code.

qu1j0t3 commented 3 years ago

I believe you should start with polyline, not an individual line. The latter isn't very useful.

Re: "sending the same display list"—This is what I meant by the "emulation strategy" having to be part of the design process. You can't design a "protocol" independently. The whole system has to be considered.

larsbrinkhoff commented 3 years ago

I'd be happy to add polylines. I don't know how various display hardware handle adjoining lines. Would there be a visible overlap or not? From a software view, some hardware just provides a line primitive. But maybe it would have smarts to draw a polyline when appropriate.

This is at an experimental stage, so I'm not concerned about making a perfect protocol. But I do have a desire to eventually make something useful for many different situations. The "whole system" I'd like to consider includes many different types of hardware at both ends.

larsbrinkhoff commented 3 years ago

CC @isysxp

larsbrinkhoff commented 3 years ago

Maybe UDP would be a better transport than TCP, but apparently in-browser JavaScript does not support UDP (yet). Still, the SDL2 version could use UDP and it would be interesting to compare that against TCP.

larsbrinkhoff commented 3 years ago

I now have a (somewhat) working Vectrex, and a PiTrex. The plan is to implement the protocol on the PiTrex for displaying on the Vectrex, for some real yummy vector goodness.

Side note. The Vectrex games don't care much for polylines. I'd say the overlapping endpoints add a certain flair, although technically it's a flaw.

larsbrinkhoff commented 3 years ago

CC @PontusPih

Isysxp commented 3 years ago

Just to mention this as an alternative .... it is possible to generate a live video stream of a virtual display. The problem here is latency. However, how do the gaming crowd do this for multi-player displays over the net? Then, any display surface can be transmitted via the same stream.

larsbrinkhoff commented 3 years ago

@Isysxp, I have looked into VNC, WebRTC, and similar technologies. My impression is that using one of those is about as much work as rolling a home built protocol of your own design. And they will not work for an output device like an oscilloscope or a Vectrex.

Lesson learned from video streaming is that it's low latency and usually updates regularly. My experiments with TCP transport shows there's a considerable jitter in packet delivery times. Maybe something built on UDP could be better. Although, experience with Chaosnet transports has shown that actually HTTPS can be faster than UDP!

larsbrinkhoff commented 3 years ago

CC @kenrector, here are some thoughts about interfacing between various emulators and vector displays.

larsbrinkhoff commented 3 years ago

Polyline on Adage display. From https://www.espressobuzz.net/Found/GeorgeClark/GraphicsLab/

larsbrinkhoff commented 2 years ago

I had the idea that the protocol should have a way to transmit macro definitions and be able to invoke them later. That might be useful for more efficiently drawing text and similar things.

But then I thought there could be more general purpose programming facilities. Instead of fixed macros there could be a facility to upload subroutines which can be called. Then it would be possible to do things like dashed lines, circles, etc.

qu1j0t3 commented 2 years ago

Update on my hardware:

larsbrinkhoff commented 2 years ago

Thanks @qu1j0t3, that's very cool!

Imlac or Logo, now? I say both.