Commander X16

desertfish wrote: ↑Mon Oct 30, 2023 7:04 pm There is no concept of loading multiple programs at the same time on the x16.
The shell doesn't "gosub" into the programs you launch from it, it replaces itself with the program and starts it.
So there's no shell left to return to if the program exits.

I would word it differently, though I certainly get the gist of what your saying. When you LOAD a program using the system routine it assumes you have all free lower/BASIC Ram to yourself. Anything else there is gone. That doesn't remove System ROM routines. Or code in certain other areas. The only slightest glimmer of preemptive multitasking is code called via Hardware Interrupts and that is severely time limited in execution, and has to be careful to preserve states for other software. That being said, if you write a system of programs that agree on a calling convention and have them run in cooperation with each other, some sort of multi program multi-tasking would be POSSIBLE, but severely constrained because of the hardware limitations. Bringing in ANY software from outside the self-contained infrastructure ? The commander X16 doesn't really have the hardware capabilities to make that safe, You would be best to make a graceful exit and just execute that code, if you want to even allow that path.

ahenry3068 wrote: ↑Mon Oct 30, 2023 7:53 pm

desertfish wrote: ↑Mon Oct 30, 2023 7:04 pm There is no concept of loading multiple programs at the same time on the x16.
The shell doesn't "gosub" into the programs you launch from it, it replaces itself with the program and starts it.
So there's no shell left to return to if the program exits.

I would word it differently, though I certainly get the gist of what your saying. When you LOAD a program using the system routine it assumes you have all free lower/BASIC Ram to yourself. Anything else there is gone. That doesn't remove System ROM routines. Or code in certain other areas. The only slightest glimmer of preemptive multitasking is code called via Hardware Interrupts and that is severely time limited in execution, and has to be careful to preserve states for other software. That being said, if you write a system of programs that agree on a calling convention and have them run in cooperation with each other, some sort of multi program multi-tasking would be POSSIBLE, but severely constrained because of the hardware limitations. Bringing in ANY software from outside the self-contained infrastructure ? The commander X16 doesn't really have the hardware capabilities to make that safe, You would be best to make a graceful exit and just execute that code, if you want to even allow that path.

Just now realized I'm describing Windows version 1.0 to just before 3.0 and really mostly 3.0 as well .

So we could mostly clone Windows 1.0 or 2.0 on the X16 .............roflmmfao.

ahenry3068 wrote: ↑Mon Oct 30, 2023 8:06 pm

ahenry3068 wrote: ↑Mon Oct 30, 2023 7:53 pm

desertfish wrote: ↑Mon Oct 30, 2023 7:04 pm There is no concept of loading multiple programs at the same time on the x16.
The shell doesn't "gosub" into the programs you launch from it, it replaces itself with the program and starts it.
So there's no shell left to return to if the program exits.

I would word it differently, though I certainly get the gist of what your saying. When you LOAD a program using the system routine it assumes you have all free lower/BASIC Ram to yourself. Anything else there is gone. That doesn't remove System ROM routines. Or code in certain other areas. The only slightest glimmer of preemptive multitasking is code called via Hardware Interrupts and that is severely time limited in execution, and has to be careful to preserve states for other software. That being said, if you write a system of programs that agree on a calling convention and have them run in cooperation with each other, some sort of multi program multi-tasking would be POSSIBLE, but severely constrained because of the hardware limitations. Bringing in ANY software from outside the self-contained infrastructure ? The commander X16 doesn't really have the hardware capabilities to make that safe, You would be best to make a graceful exit and just execute that code, if you want to even allow that path.

Just now realized I'm describing Windows version 1.0 to just before 3.0 and really mostly 3.0 as well .

So we could mostly clone Windows 1.0 or 2.0 on the X16 .............roflmmfao.

Anyone for doing a "Microsoft Windows Version 1.0, clone, On the X16 coded in Prog8"

desertfish wrote: ↑Mon Oct 30, 2023 7:04 pm There is no concept of loading multiple programs at the same time on the x16.
The shell doesn't "gosub" into the programs you launch from it, it replaces itself with the program and starts it.
So there's no shell left to return to if the program exits.

Well yes, but...for example the sieve program or byte-sieve as you named it. I modified it to run at $4000, it executes and returns to the shell, to be run over and over again. Somewhat different, but not dissimilar to BASIC 'running' user code and then doing what it always does in immediate mode, when the user program terminates. I recompiled Tehtriz to execute from $4000 also, so as not to interfere with the shell and it's not clear to me why, when it exits, using sys.exit(0) like neofetch or the modified sieve program, the shell doesn't resume. As far as I can tell, it isn't using 'shells' program space, I don't see that shell is doing anything with irq vectors, although tehtriz does, but even removing the sound code from tehtriz, including the irq stuff, it still exits to BASIC. I'm missing something.

Ah I see, I didn't pick up that you modified tehtriz.
But, have you also added a "%option basicsafe" to it? Otherwise it will have the prog8 default behavior of just happily overwriting everything in zeropage and resetting the machine on exit.

ahenry3068 wrote: Anyone for doing a "Microsoft Windows Version 1.0, clone, On the X16 coded in Prog8"

Kind request to stay on topic

desertfish wrote: ↑Mon Oct 30, 2023 10:19 pm Ah I see, I didn't pick up that you modified tehtriz.
But, have you also added a "%option basicsafe" to it? Otherwise it will have the prog8 default behavior of just happily overwriting everything in zeropage and resetting the machine on exit.

Independently figured out just before coming back here! But good to know! I really need to print a new copy of the manual...for bedtime reading to reinforce things, my current printed copy is from version 7.something...

I'm sorry, got off on a Tangent. It was "only slightly" off topic.

desertfish wrote: ↑Mon Oct 30, 2023 10:22 pm

ahenry3068 wrote: Anyone for doing a "Microsoft Windows Version 1.0, clone, On the X16 coded in Prog8"

Kind request to stay on topic

Well, he did say "in Prog8".

Irmen,

A request. I don't think this is a Prog8 issue...but to be honest, it doesn't make any sense at all to me! In playing around with the shell 'environment', I discovered an issue with some old established code, involving the mouse and sprite positioning. This code was developed in R43 and earlier and behaved...and still does behave in R43 at least. However, it does not in R44 and R45....except...

In the attached zipfile are two sources, the program in question and a stripped down program (mouse.p8) that is only for testing the functionality of mouse input (left button click) to locate a sprite. The test program works as intended in R44 and R43. The full version program (julia) only works as intended in R43. In R44/R45, left clicking places the sprite at the click spot, but then it is 'rubber banded' back to screen center. It does this because the in the repeat loop, where I check if the mouse button is pressed...it stays 'pressed'....endless loop. Only in the full program and only in R44/R45....it doesn't make sense!

Could you take a few minutes to look at it? It's likely to be something stupid on my part.....but I'm too stupid to find it!

Thanks!