Multi-terminal

[Josh Kemp]

This may be a stretch, but multi-terminal would be a thing of amazement.  Similar to early versions of Unix, you could switch between a few terminal screens by using the function keys.  You could edit a program on one terminal, and run it on another without having to constantly exit the editor.

[SlithyMatt]

Problem is, there's nothing to connect those terminals to. Unix was built as a terminal-based OS, with support for multiple terminal sessions and proper multi-tasking. So the first question really is, can we have such an OS for the X16? Some may think the answer is "yes" when they see something like GeckOS: https://github.com/fachat/GeckOS-V2

[Scott Robison]

1 hour ago, SlithyMatt said:

Problem is, there's nothing to connect those terminals to. Unix was built as a terminal-based OS, with support for multiple terminal sessions and proper multi-tasking. So the first question really is, can we have such an OS for the X16? Some may think the answer is "yes" when they see something like GeckOS: https://github.com/fachat/GeckOS-V2

They do offer virtual terminals, which I think is the function key switching that is being described. I use that feature in my FreeBSD server all the time.

[Scott Robison]

I actually have been designing something sorta kinda vaguely like that, but not 100% native. I'll be posting something later about it, but my idea is to have a virtual machine that provides a more linear address space with more useful VM p-code instructions, but it would allow multiple tasks and sharing of the display between multiple processes.

Xenon, or Xe for short: X Environment. Details forthcoming, though I've not written a line of code for it really. Well, I have written enough code to make sure I can embed it in ROM so it takes the place of the native BASIC if desired... At the moment it is 100% vaporware, but I envision it as being the "better BASIC replacement" that multiple threads have discussed.

[BruceMcF]

1 hour ago, SlithyMatt said:

Problem is, there's nothing to connect those terminals to. Unix was built as a terminal-based OS, with support for multiple terminal sessions and proper multi-tasking. So the first question really is, can we have such an OS for the X16? Some may think the answer is "yes" when they see something like GeckOS: https://github.com/fachat/GeckOS-V2

There's the User port serial port, but rather than "multi-terminal" that would be a "dual terminal" system. Dual tasking is a lot easier to accomplish than arbitrary multi-tasking.

[Josh Kemp]

4 hours ago, BruceMcF said:

There's the User port serial port, but rather than "multi-terminal" that would be a "dual terminal" system. Dual tasking is a lot easier to accomplish than arbitrary multi-tasking.

On other OS's you can create virtual ports (serial or otherwise) that don't point to actual hardware, and then those sessions could connect to that.  I'm not looking for 12 of them.  Just 2 or 3.  I know it still take RAM, and still uses resources.  Just thinking of cool features

 

[kelli217]

The 128 had a really primitive version of this; information sent to the 80 column screen was not duplicated on the 40 column screen, and vice versa. But you couldn't run two different programs; all you got were two different places for the one program to display information. This was made possible by the hardware, because there were actually two video chips on the system, each with their own memory space. And each with their own physical output to a monitor, so you could see both screens.

VERA doesn't support multiple different outputs; it's only one chip. But you could still do screen switching by flipping between pages in VRAM. You'd still just be running one program... unless you used a multitasking OS. Alternatively, it might be a useful function for flipping between a data screen and a tools screen. For instance, in a word processor, you could dedicate an 80×60 screen in ISO mode to display the text being edited, and use a hotkey to bring up a tools screen in 40×30 PETSCII mode.

[BruceMcF]

5 hours ago, Josh Kemp said:

On other OS's you can create virtual ports (serial or otherwise) that don't point to actual hardware, and then those sessions could connect to that.  I'm not looking for 12 of them.  Just 2 or 3.  I know it still take RAM, and still uses resources.  Just thinking of cool features

An OS is something for the User to add, the CX16 has a BIOS. But the Kernel numbered device calls can be redirected at the Jump Vectors in page $0300. Device 0 is the keyboard, device 1 is the datasette in the C64, the SD card in the CX16, device number 2 is the serial port, device 3 is the screen.

So if the Kernel API vectors catches calls to devices 1 and 3 and redirects them to different code, it is possible to have multiple terminals at a basic system level. The simplest, as I noted, would be to be doing this for the serial port ... since it involves trapping calls to devices 0 and 3, doing whatever you are going to do to them when the active terminal is the serial port, and then making the appropriate call to device 2. If Golden RAM does not suffice for the whole driver code and buffers required, you'd need to acquire a High RAM block for your buffers, extended routines, etc. and have a smaller launchpad routine in Golden RAM.

Each device is single tasking, but with two distinct terminals that both work the same, including the switch between terminals as part of the task switch in a dual tasking system would then give dual tasking terminals.

[EMwhite]

It's unlikely that an X16 will be called upon to have multiple users connected over serial port connected terminals in manufacturing, one in accounting, and a third in engineering; so multi-session (verses multi-tasking versus multi-user) is what is needed; similar to when Apple first supported Multifinder on OS7.1.

From Wikipedia: "Switcher works by designating a number of fixed slots in memory into which applications could be loaded. The user can then switch between these applications by clicking a small button on the top of the menu bar. The current application horizontally slides out of view, and the next one slides in. Though awkward, this approach does fit well with the existing system's memory management scheme, and applications need no special programming to work with Switcher."

Otherwise, all of that context switching just adds overhead and complexity with no MMU to support it.

Instead, session-switch to different sets of blocks of memory only when the user switches from editor to compiler to whatever.

Will that fit the bill?

[BruceMcF]

16 minutes ago, EMwhite said:

It's unlikely that an X16 will be called upon to have multiple users connected over serial port connected terminals in manufacturing, one in accounting, and a third in engineering; so multi-session (verses multi-tasking versus multi-user) is what is needed; similar to when Apple first supported Multifinder on OS7.1.

Seems like you are building toward what X16 will not be called upon to have, instead of what it MIGHT be called upon to have.

It might be more productive to ask whether there is any use case for having a session for a person connected to the serial port and a session for a person sitting at the keyboard, because it will have both a serial port and a keyboard available.

For a switcher between a person running the CX16 in their basement workbench and the same person checking in on the CX16 from their laptop upstairs, support for switching between the keyboard/screen as a terminal and a serial port connection emulating being the keyboard and screen would still be required.

And obviously if it is sitting idle waiting to see where the next input is coming from, that's a task that needs to be able to switch between those two terminals.

As far as a use for both at the same time ... that fact that it WON'T be someone at a terminal in manufacturing, someone in accounting and someone in engineering is entirely useless for working out whether you might want to have two people typing at the same CX16 at the same time.

Bear in mind, "I could have done this a different way, but I did it with a dual tasking system because .... doing a dual tasking system on the CX16 was more likely to get the project featured on Hackaday" is a perfectly valid programming decision for a hobbyist system. Also, "because ... I thought it would be fun to do it this way." ... indeed, that is arguably the MOST valid programming decision for a hobbyist system, if you were correct and it was, indeed, fun.