Jump to content

Multi-terminal


Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Posted (edited)

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.

Edited by Scott Robison
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

Posted (edited)
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

 

Edited by Josh Kemp
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Posted (edited)
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.

Edited by BruceMcF
Link to comment
Share on other sites

None of that.

Only asking if it would be easy enough to implement a task switch where the current 'task' / program is pushed into the background (and stops executing) and a new workspace exists to start another task of say, the next 128K bank.  Copy/paste between the two would be nice.  That's all.

 

Link to comment
Share on other sites

2 hours ago, EMwhite said:

None of that.

Only asking if it would be easy enough to implement a task switch where the current 'task' / program is pushed into the background (and stops executing) and a new workspace exists to start another task of say, the next 128K bank.  Copy/paste between the two would be nice.  That's all.

 

Multitasking has been discussed, and it's not going to be part of the hardware. 

You could implement your own multitasking operating system, using the banked memory, but that's something you'd have to do on your own or as a group with other users. It doesn't sound like the X16 team is interested in implementing any sort of multitasking (and I agree - that's far outside the scope of what this machine is.)

Link to comment
Share on other sites

A simple task switcher wouldn’t be hard to implement for a particular set of programs that you know exactly what parts of RAM they do and don’t use. You could drop the code to do the swap somewhere in memory and hook it with an IRQ that watches for a particular keystroke or something.

Link to comment
Share on other sites

Posted (edited)
10 hours ago, EMwhite said:

None of that.

Only asking if it would be easy enough to implement a task switch where the current 'task' / program is pushed into the background (and stops executing) and a new workspace exists to start another task of say, the next 128K bank.  Copy/paste between the two would be nice.  That's all.

In your prelude to your question, when you say "so multi-session (verses multi-tasking versus multi-user) is what is needed; similar to when Apple first supported Multifinder on OS7.1.", that's a claim that someone who has a use case for multi-tasking would dispute. Sorry if I did not catch your drift, but I can only read the words, and sometimes they may leave intention a bit invisible. 

A switcher would be easy if you have a system for allocating space in Golden RAM and for allocating High RAM blocks ... grab a High RAM block for the switcher, and as many bytes as you need in Golden RAM for the launchpad to call the switcher, copy the Low RAM and the system High RAM blocks into a file to switch one application out, load the equivalent from the other application to load it in, away you go. That'd be much too slow for multi-tasking, but multi-tasking would need to be either in user space or else in a middle layer added by some programming language.

To bring that back to the topic raised at the start of this thread, if you had a task switcher, you could add a routine that when the system is idle, it checks both the local terminal and a serial terminal for activity, and if one of them starts inputting, it switches to a specified task.

 

Edited by BruceMcF
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use