network adapter / c compiler

[andmarti1424]

hello there! my name is Andrés.
I really like this project a lot!! I only wish its focus not only be just a gaming computer but a productivity machine also for out daily tasks.

from my perspective:

+a network adapter, a C compiler.. both are must.
(Perhaps someday I could even port my sc-im spreadsheet app to here).
+OS shoud support multitasking and why not multiuser as well.

all these would allow development of apps like browser (say lynx or links kinda thing)

btw does the VERA supports 44.1khz 16 bit stereo?
Keep up the good work!

[TomXP411]

A network adapter is in the works. It will be an ESP32 based system that allows you to access various network protocols through basic LOAD, SAVE, GET#, etc.

There may indeed be a simple C compiler on the system; someone created a prototype a while back, but it hasn't been updated for a while. I do agree that a good C compiler and macro assembler would be nice to have on the CX16.

There will not be multitasking or multi-user components to the operating system. The 6502 CPU is just not designed for multitasking, and there isn't currently any hardware method of connecting additional terminals to the X16 or of relocating code in hardware. So multi-user access is not really practical.

[StephenHorn]

+OS shoud support multitasking and why not multiuser as well.

The kinds of machines from that era which supported multi-tasking and multi-user were room-sized mainframes running very specialized OSes, and oftentimes these OSes depended on "cooperative multitasking" -- specifically releasing control back to the OS. And oftentimes, it was possible for a single application to monopolize the entire mainframe if it didn't return control.

I mean, yes, a modern PC does this kind of stuff automatically. Timers can preempt the running process, return control and execution context to ring-0, and the OS can choose a new thread of execution. As a concept, this is... about 20 years early for the Commander X16's late-1970s basis, and there just aren't that many cycles to spare on its 8MHz clock, though I'll grant Windows 95 technically only required a 20MHz cpu... but still a 386 that supported protected-mode operation that could preempt running processes. Even then, however, Windows 95 could not multitask Win16 applications, which did not run in protected mode.

TL;DR: When approaching this machine, you definitely need to think 1970s. Maybe 1980s. Pre-emptive multitasking, on the other paw, is very much mid-to-late 1990s.

[andmarti1424]

I am not an expert on this topic but have you take a look at this:

http://www.6502.org/users/andre/osa/oa1.html

?

[DragWx]

When you say "multitasking OS", what kinds of things were you thinking of? Like, what were some examples of things you wanted the X16 to allow you to do, which would be multitasking?

[andmarti1424]

When you say "multitasking OS", what kinds of things were you thinking of? Like, what were some examples of things you wanted the X16 to allow you to do, which would be multitasking?

kinda like having multiple processes running.
say a text editor, a shell, a text browser..
transfer the control of one program to cpu, save state of another, load a saved state of another process, transfer control to it..

[DragWx]

I'm asking because, depending on what you're trying to do specifically, it might not require a full multitasking OS running underneath it.

Like, a text editor with the ability to have multiple documents open at once can, in many cases, suffice in terms of the user being able to do multiple things at once. I'm also thinking of IDEs built on TurboVision and like QuickBasic, where everything you needed was right in the program so there was no need to switch out for anything.

That's not to say actual CPU-level multitasking is impossible, but it's also not impossible to be productive without it either. It just comes down to identifying what specifically is trying to be accomplished.

[andmarti1424]

Also have you take a look at TEOS in Youtube?

[BruceRMcF]

When you say "multitasking OS", what kinds of things were you thinking of? Like, what were some examples of things you wanted the X16 to allow you to do, which would be multitasking?

kinda like having multiple processes running.
say a text editor, a shell, a text browser..
transfer the control of one program to cpu, save state of another, load a saved state of another process, transfer control to it..

There are several levels of multi-tasking.

There is pre-emptive multi-tasking with operating system control of access to resources like devices and memory. A 6502 based system is not going to have that as the standard runtime that every executable works in. It will, rather, have a single foreground task and then preemptive multi-tasking will be limited to bespoke interrupt driven routines.

There is cooperative multi-tasking, which generally will not be provided by the operating system either, but for different reasons. The problem with relying on cooperative multi-tasking as the default execution environment for every executable is that people will write executables that do not cooperate -- that "hog" system resources either because the author did not know how and when they were supposed to surrender control, or because the author considers their task to be the most important thing that could be running on the system, and thinks it should "hog" the resources of the system until it is done.

However, it is very easy to add cooperative multi-tasking with very low overheads to a Forth system, and in particular to put the core cooperative multi-tasking word PAUSE into every primitive I/O word, so that any task that does any I/O will automatically be cooperating with the task round robin every time they do I/O.

And finally there is multi-tasking without multi-processing ... just having multiple tasks, so the user can set one task to one side to pick up another task, and then when the second task is finished, go back and pick up with the first one.

So long as there is a way to ask the system what HighRAM segments are available when a program starts, then you can build that into a program, where as a program action it saves its system state into one or more HighRAM segments or onto the SD card, has a restart program on the SD card, and then loads and runs a program which itself doesn't have to do more than respect existing allocations of HighRAM segments. When done with that second task, run the restart program and you are back at your original task.

And in a sense, the X16 already supports that: rename any existing AUTOEXEC.X16 to AUTOEXEC.X00 (or if that is present AUTOEXEC.X01, etc.), name the task restart program AUTOEXEC.X16, and after exiting the called program, BOOT will restart the task.

[voidstar]

In the early IBM PC days (early 1980s), there were these options for multi-tasking:

CP/M-86 -> Concurrent DOS 3.x -> DR-DOS
(1982) (1983) (1988)
1984 IBM TopView (motivated concept of overlapping windows)
1986 DESQView

Indeed, CP/M-86 itself wasn't multitasking, but that was a feature Gary was very aware of and did get the capability into a subsequent build (Concurrent DOS) that was just too expensive as a product and just ahead of its time. The general populace was still learning what to even do with a desktop computer, let alone yet have need for multitasking- so Digital Research just never got a mass of developers to make any software for Concurrent DOS. DR-DOS focused back on the single user needs, and was a very fine DOS -- Microsoft was battling IBM at the time about OS/2, so DR-DOS took advantage of that distraction and got a hit product out at the right time (MIcrosoft eventually incorporated a lot of the features of DR-DOS by the mid 1990s, like loading drivers in high memory, etc.).

Anyway, between 1984 and 1986, both TopView and DESQView were two interesting applications that ran on top of PC/MS-DOS and facilitated multi-tasking. I used DESQView, on an 8088 @ 8MHz, to run a BBS in the background. Or while connected on a terminal, if you needed to look up a document or do some file management, you could pop over to another console window to do so. Or I could do light development work (compile code) while users were connected to the BBS. It may be partially why I never jumped onto Linux on the PC in the early 1990s, since I had already been multi-tasking for a few years already on the PC.


None of this really answers or addresses if a 6502-based multi-tasking OS could or should be built. We have a BANKing system that can now swap out, what, an 8K or 16K region of memory? It might be possible-but slow for general purpose processes running. I think the CoCo OS-9 experience is, it'll cap out to about 2MB due to limited number of banks? So it won't be quite a playing Sonic and ALT-TAB out kind of experience...