This will be the second OS I have conceived; the other is CybernetIX a POSIX compliant variant of BSD-*IX built around command line and terminal interfaces, full screen task switching vs a desktop and a focus on scientific and industrial computing. Notable packages include BRL-CAD, capable of over 400 commands, many of which can be used from a text prompt.
____________________________________________________________________________________

The Integrity, as discussed here: viewtopic.php?f=4&t=7537

is both a hardware project I am developing for crowdsourcing and production,
and a hardware specification for DIY creators to create a device that can run a variety of common software.
This thread is to discuss the notions of the OS the Integrity portable computer will run and the specifications that might need stated.

We cannot name the OS Integrity, that is used by another company already for an OS.
We can however use the principles of integrity to guide us:

Consistency, the OS will utilize design principles that are consistent across hardware and modes of operation
Trustworthy, the OS will utilize secure computing principles to ensure data and program reliability
Responsibility, the OS will utilize design that allows each component to be accountable for performing its duties

For now, I am calling this the "Oh-Two Oh-Ess", Air or Atmosphere.
and their is an o2 layer.

Target Platform:
While the OS is might be ported to any number of mcu/mpu architectures, it is developed for and intended to be used on a 65816 CPU/MPU and related hardware for the above described Integrity Hardware specification. The Integrity platform is a multiprocessor one by design that mimics Super I/O to a degree, or rather a composite or hybrid architecture. Chips currently considered for use include PIC microcontrollers, various GPUs, a hardware sound system, a likely pen interface, PC-MultiPort/MultiCard and 65SIB connections, various peripherals and connectivity as well as future hardware upgrades or revisions lend themselves to the use of Device Drivers and Software Modules.

____________________________________________________________________________________

Core
The 'kernel' or BIOS is largely the same thing, the Core layer of the OS.
This layer is runlevel 0, or runlevel 1 (TBD)
Given our current hardware, the 65816 and possibly 6502 chips, the use of the 'e' emulation flag bit is of direct interest.

____________________________________________________________________________________

Run Levels
0: 8 bit restricted. 65816 in emulation 'e' mode or 6502. This is Recovery Mode and sets any registers to 8-bit length. In this mode the CPU has locked out as much of the rest of the hardware as it can, and offers a Hex Editor, Process Inspection and User Control over the entire device. Here is possible the device is running on a dedicated subsystem and is writing to the screen directly. This should not be used for normal operation. Writing software for runlevel 0 entails only using the cpu itself and requires RAM banking or switching routines to access all parts of the system. This runlevel is mostly POST, a bootloader and an inspector. It does however include the routines for basic communication, I/O, memory/data CRUD code and the ability to load and run device drivers, and device communication profiles. When the device is powered on or the hardware RESET button is pressed, this is the state loaded by the Reset vector at $FFFC/FD.
This Runlevel may be 'headless', as could runlevel 1 or 3, some aspects may be moved around. Headless operation is a must.

1: 8 bit limited. same as Runlevel 0, with the rest of the hardware running normally. software for a 6502 and a 65816 in e mode should be as binary compatible as possible. This is 'compatibility mode' for 8-bit software, and code written here should be portable between the two chips as much as possible. In this mode, the rest of the chips are running and the system acts as if it had a 6502 and related hardware. In this mode the device acts and functions like a 6502, with all of its normal MMIO and Vectors and limitations.

2: 8 bit unrestricted. all functions of RL 1 and 0. This mode may be useful for its efficiency or power saving capabilities or optimized routines. It allows access to all RAM banks and extended functions of each chip in the system. May be useful for multiple running states on each ram bank.

3: 16 bit restricted. this is the first fully 16-bit 'n'ative mode. while it allows for most 16-bit software to be run, certain functions are disabled and certain chips might be disabled or have their IRQs reduced in priority. Useful for debugging or untrusted software or hardware. May limit RAM or use RAM banks in a protected area.

4: 16 bit unrestricted. this is the normal day to day mode used by most people. Most software will be written for this runlevel.

5: 16 bit extended. this is for multiprocessor type arrangements and is a low priority task for development. Software written for this runlevel can utilize additional processors or cores. reserved.

6+: reserved for higher level 65xx series chips.

____________________________________________________________________________________
Boot Process

given current architecture, we start our boot process after the 7 step RESET sequence and the Program Counter has loaded $FFFC/FD and we start from our relative "0x0000 point" or Base Zero point for our OS image. This might be offset from virtualization and other factors, however, our image and expanded environment will have a reference 0 point.

When the device boots, it basically loads an address and starts loading instructions there.
Power On Self Test Routines and Interchip/Interdevice Reporting, clock sync'ing and testing,
really basic I/O at this point.

Once POST is done, any really basic low level utility READ/WRITE, COPY, LOOK and SET/CLEAR routines should be established, and then a ROM with the actual OS is copied into RAM. There may be a hardware option at this point to read from the 65SIB bus/port to flash the ROM or load an external OS (loading an external OS here may require a hardware jumper or switch, or a software command issued from the software after core ROM is loaded.

64K RAM is not a large limit. It is very likely this will be extended through paging/bank switching. Virtualization of 6502 modes, or 6502 virtual machine images in different areas of RAM is probably a method for the OS to use for multitasking. So each program may be able to think and act like it is the only thing using the hardware, while interacting between these processes may be immediate and shared or act as if through a network or intermediary buss.

The Core of the code should be able to:
Run simple code on itself
have a main loop
handle interrupt and non-maskable interrupts
access ram externally, access a rom (and refresh itself)
load device drivers and device communication profiles
start, stop, pause or otherwise command or control other chips
know what hardware is installed, and what its operating parameters are
know what peripherals are installed on what ports
read and interpret all clocks
if we can control the screen directly here, the Core should:
>>otherwise, if not, we should load the GPU driver and write to screen that way,
>>or load the PIC controller driver and have it do so. this will be determined by the CPU having a DART unit or not, or if shared VRAM >>will operate the GPU/LCD

at this point the cpu should have finished POST, all other chips should be powered up, OS image loaded from ROM, and should be turning on services or having checked any user variables from Disk (after loading a Disk Storage Device), it should be running its lowest level user routines, which are to a degree hardware controlled. Most likely, the PIC or board controller drivers are loaded and run, and the PIC has loaded its code from ROM, which to this point has been to tell it to wait until the CPU says 'ok go', it should be 'in sleep or low power mode' at this point, outside of its own POST startup routines. Likewise with all other chips and peripherals on any ports, unless their specification requires otherwise (looking at USB ). The power management unit may have its own code, and is the real 'gatekeeper', though the CPU should be running the show.
The PIC runs the system, the 65816 runs the PIC, is a general strategy for the device design, though where possible the hardware should act like a multiprocessor system and share tasks if possible. At low run levels, this is beyond the scope of the Core code, though should be planned for. Once the PIC is loaded and the CPU/PIC are processing interrupts and RAM accordingly, the GPU should have loaded its code and been instructed to draw the basic boot up screens or routines beyond its own internal ROM, and should be displaying in a simple low level screen or menu.

If possible, at runlevel 0, the GPU and PIC should largely be in standby mode, with passthrough IRQ and operation. The CPU, in 6502 mode or a 6502, should be very slowly running everything itself, and really only maintaining any chips or IRQ routines as needed.
In 0-level, the display should be either 1-2 bit depth, 2 is better, and be at a resolution the 6502 can directly write to using its MMIO space for video. 200x120 is probable for current designs.

At this time, the system should be 'on' and the most basic of routines running. most software here is going to be for monitoring, maintenance, exploration and basic calculation. Most of the Hardware is only 'standing by' and holding whatever information it had loaded last it can maintain. At boot, this should be pretty sparse, and in recovery mode (when the system 'drops back' to 0-level) whatever it was doing. When the system goes here, basically you should be pausing everything and can explore bit-by-bit, all the hardware, which should not being doing much.
A simple menu of options like:

Begin System
Configuration
Explore 0x00

and not much more is enough, with a user option to bypass this, and return to this mode by use of a menu, or turning on the device with reset held down and releasing after the screen comes on or some similar mechanism is used to unbrick the machine.
Runlevel 0 is pretty basic, and should be running on the CPU, and a local DART unit (dual uart, 6551, 6522, MAX3100, etc. some way for the CPU to communicate with things that bypass the PIC. it is uncertain if this unit is required, though it may be advantageous, see Hardware Specifiction).

At this point, normally, you would then actually load runlevel 1:
Here the PIC is running the board, the USB port, and the PCMP adapter, possibly the 65SIB port, the gpu is running the LCD, and flash drive, etc, while the CPU is running its code, and telling the PIC to tell everything what to do, or possibly the GPU or sound system and power system. the u-FPU co processor is probably run by the cpu, though may be used by both the PIC and GPU or Sound IC as needed if possible.

or runlevel 4 on a 65816 configured to do so, with the CPU in full native 16-bit operation. If certain cards or ICs are installed, the user elects to use certain shells or programs, then other runlevels may be loaded/selected as needed or desired.

This leaves the CPU to focus on running its software, or distributing that software to coprocessors and telling each chip what code to load or sending them instructions as needed. See hardware specifications for IC features.

This completes the boot process, with the system largely running a menu screen with several icons or options and the RAM partitioned, all MMIO mapped and all ICs talking to each other with any diagnostics done. In short we include a simple command prompt or menu in our BIOS ROM code for recovery modes and debugging, with some features possibly moved to a higher intermediary runlevel between 'booting up and post' and 'running normally in full mode'.

Memory partitioning will be discussed in the Memory Management section.
IRQ handling and Hardware control is covered in IC communication.

____________________________________________________________________________________

UI/UX
Input:
The Integrity does not have a keyboard by default. The only hardware required will be a 4-way Directional Pad and 4 Buttons. These should mapped to an 8 bit address to be polled or read. This is handled slightly differently depending on runlevel. At low runlevels, it is read and polled by the cpu during it's interrupt handling routines or ad hoc as required. At higher runlevels the IRQ handling is done by the board controller.

Mouse:
There is a strong likelihood that the Integrity will have a Stylus or Pen and will function as a mouse. Mouse emulation via the D-Pad is a likely support software. All UI must be accessible through the use of a D Pad and button presses. of the 4, two are situated near each other to be pressed with the opposite thumb from the d-pad in a common grip. these should generally be used as "confirm" and "cancel", or similar "select" and "go back" or "left click" and "right click". In any case, consistency to these key ideas should be consistent in all software. The other two buttons are software defined though "menu" or "start" is a probable candidate for use. On that notion, having "system menu" and "context menu" taking the place of Select and Start on our NES controller analogue. All keys are user remappable to facilitate device rotation, screen orientation and likely grip positions.

Screen Orientations:
Therefore in 'standard' viewing mode, the D-Pad is in the top left, , or a 90-CW rotation sets the D-Pad in the top right, another 90 degrees sets the screen 'upside down' with the D-Pad in the bottom right, where the cursor keys are on standard keyboards these days, and lastly there is a position with the D-Pad in the bottom left with the screen in portrait modes. These are Standard, Right Hand Reader, Inverse Interface, and Left Hand Reader orientations depicting common uses of the device in each orientation. St, RH, II and LH screen modes are used as common abbreviations and most notation here refers to the Device in Standard and Portrait modes with minimal distinction beyond this, these are primarily for software developers to reference.

Accessibility:
All software should strive for accessibility including text to speech and possibly tactile feedback devices. Colors for menus should be designed for readability by those with limited color depth perception, and use shape and texture in place of color to represent different options or icons.
https://en.wikipedia.org/wiki/Design_for_All_(in_ICT)
https://en.wikipedia.org/wiki/Digital_A ... ion_System
DAISY, Digital Talking Book, DTBook


Penabled Computing:
the device is likely to have or use a stylus. Menus and system software should use and implement Penabled interaction, though never rely on it. Even drawing software, though tedious, should fall back to using the D-Pad in virtual mouse mode.

Shells and Command Interpreter: depending on runlevel, the shell or prompt may operate differently. In each runmode, the user has a simple menu with icons that is navigated with the d-pad and buttons. This menu is distinct in recovery (and 8bit) mode vs Normal (16 bit) modes. Each icon other than the first, the device settings menu for power and sleep options etc is relocatable. Each icon can be changed and what program is loaded. 4 or 5 "hot commands" can be set to work with the dpad and buttons to quickly load applications.
Beyond extremely limited functionality, the OS allows users to load and run 'shells' or 'command interpreters' as the desire. Some variant of a Card based programming language, features of Sketchpad by Ivan Sutherland, and Forth or Prolog environments or both. It is possible the Forth interpreter/environment may be written in Prolog and the Prolog environment may be written in Forth. Ultimately it will be up to the user community. Some form of visual code environment, and procedural math interpreter are very likely places to start with for a shell, though a lot can be gained from studying the NEO-GEO Pocket Color.
https://external-preview.redd.it/zCpl005RMYYtJZInYmOrE8Lx3D2pnvnn_SGTwJ3Plg8.jpg

____________________________________________________________________________________

Drivers and Device Profiles
each device will have 'drivers' that are meant for that specific device. In many cases, such as the PIC or other board controller, Microchip offers a compiler for that chip. Code the PIC is intended to run is flashed to internal memory on the chip and otherwise loaded during run time from instructions from the CPU. in this case, the Core needs to get information about the board controller, make sure it is ready to operate, give it any addresses, variables or initialization instructions and load any rom or other files to that chip.
The primary code used to operate these chips is our driver.
Each chip and device will have identifiers and parameters that will be encoded and used across many domains. A chips timing, pinouts, addresses, registers, mmio, etc are all recorded in a file that can be loaded or used in a modular fashion as hardware changes or standards update.


____________________________________________________________________________________
References:
https://brlcad.org/wiki/BRL-CAD_Commands

Compiling Prolog to Forth, LL Odette, January 1987
https://www.researchgate.net/publication/234780918_Compiling_Prolog_to_Forth

Compiling and analyzing Forth in Prolog, RD Dixon, David Hemmendinger, August 1987
https://vfxforth.com/flag/jfar/vol4/no4/article3.pdf

SKETCHPAD, by IVAN EDWARD SUTHERLAND, MASSACHUSETTS INSTITUTE OF TECHNOLOGY, January, 1963
https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-574.pdf

[sic] all pages here https://wiki.c2.com/?GraphicalProgramEditor[sic]
and here: https://wiki.c2.com/?GraphicalProgrammingLanguage
especially:
http://www.cs.cmu.edu/~bam/papers/vltax2.pdf
and
https://wiki.c2.com/?HyperTalk
https://wiki.c2.com/?SketchPad
https://wiki.c2.com/?PrographLanguage
https://wiki.c2.com/?HyperCard

Prolog/Forth, ForthLog, ProForth, Forth/Prolog, etc
https://www.complang.tuwien.ac.at/adrian/forthlog.html
https://groups.google.com/g/comp.lang.f ... vaDdjunCPU
https://courses.cs.washington.edu/cours ... asics.html
https://www.computerhistory.org/collect ... /102774700
https://www.sciencedirect.com/science/a ... 9X9390013F
https://dl.acm.org/doi/10.5555/37380.37385
http://www.cse.uaa.alaska.edu/~afkjm/cs ... prolog.pdf
https://ntrs.nasa.gov/citations/19930073450
https://www.youtube.com/watch?v=lssivTr ... erestGroup

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

thank you, I did have that a bit confounded. I have updated the runlevel section to match. what I am trying to do is create a system that allows for software to be run on multiple devices, and offers various modes to solve different problems, configuration and diagnostics, interfacing with other hardware, running software in a multitask environment etc.

rather than have just linear runlevels, which can be called 'system levels', I am looking at branching or parallel runlevels.
So, ideally this is encoded in 8bits, a few for the 'size' of the processor, physical or emulated, if support hardware is running or not, if the system is in a secure restricted mode with independent paged ram or an unrestricted big wide open space etc.

s = size, r = ram mode, c = chips, i = interface
000 = no 65x, 001 = 8 bit, 010 = 16 bit, 011 = 32 bit, 100 = 64 bit, etc
or some similar OS runlevel status information byte.

so once this one thing gets done, it will be added to the OS spec.

appreciate your help.

Ive been thinking a little bit about how the OS should work.
Id like to have a "Headless" mode, for times when you are not using a monitor, or KB or whatever.
65xx get used in a lot of industrial and control applications. so, for the "Oh-Two" operating system, or 'ozone', I guess for now its a nice name...
maybe Air or Atmosphere, since it might have layers. I like that.

So the lower layers, they are very rudimentary. They really are unlikely to provide a Shell, though may provide prompts and get input.
This lowest level is more for chips talking to chips.

This prompts further investigation of how chips talk to chips, and if they use a primary, secondary or tertiary connection to the CPU.

Primary Connections
Only a few chips connect to the 65xx family directly, namely 65xx chips, some UARTS and other I/O chips and a few era ICs that operate on similar protocols and a few other odd chips that provide parallel connection to the CPU that can be interfaced with directly. These chips all operate on basically the same system bus as the cpu, and memory. These chips and devices should have their drivers built into a kernel or such.

Secondary Connections
These are chips connected through a primary IC and not directly to the CPU, this would include a chip that uses SPI and is connected to a 6522 or other UART directly connected to the 65xx. Another example is a 6551 connected to a 6522. A 6551 connected directly to the 65xx would be a Primary connection, it is not about the type of chip, as it is where the metal goes. Many chips may not operate very well in some placements. These might have drivers in the kernel.


Tertiary Connections
This is pretty much anything beyond a primary or secondary. These are removed enough from the CPU they are not going to be working directly with it, though in some cases direct commands may be issued. These might have their drivers loaded from "disk" or have them to give to the system when needed.

These matter because of IRQ, NMI and latency, because of priority handling and how hard it is to process commands and information to and from different chips.

When we talk about a system bus on the software side, it is different from the hardware side. On the hardware side, its about traces and lines and voltages. On the software side it is more to me about information pipelining. As a notion, creating a scalar or superscalar OS, on top of a sub-scalar hardware system. this might not be achievable, however as a principle it should guide the 02-OS codebase and function: "data should flow".

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

well that is a no go, where did I hear oh-2 as ozone? SGI workstation names?

now this as we all know, is important.

so wiki says o2 can be:
https://en.wikipedia.org/wiki/O2

• O2 or dioxygen, the common allotrope of oxygen (there is what I was thinking?)
• O2−, the ion oxide (this makes a cool name for an OS!)
• O2, an EEG electrode site according to the 10–20 system (also cool, and related to my work...)
• O2, the earliest defined spectral class for stars (also a great name for an OS, maybe Ill do something here.)
  
• SGI O2, a Unix workstation computer (this and octane and oxygen and ozone are all in my head together.)
• and an OS for smartphones... (ok, taken)

I think I'll maybe go with "Oxide"? idk
more worried about getting it working though.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Garthwilson mentions this several times.

I also mention that it's not the chip, it's where the chip is located

So identifying driver types is a thought, and I think that devices that use this OS, should probably be "smart",
in that when connected or asked to, they can respond (even if just some bits) with what they are, or where to find it and if they have their own driver, dont need one, or where to get it.

I want to avoid needing to load drivers from disc where possible. Requiring a third party designer or creator to put the code needed for their device on that device, and be able to talk to the system. This might be certain data formats, or some common code provided to developers.

I do not want to focus too much on peripherals right now, more the core OS.

So, in "Oxide" (which I like btw!), you have a runlevel-0; and this is going to be really, really tiny.
This may include POST code.
This will include basic I/O code.
This will have a bootlauncher to raise the system to runlevel-1, and use any shell

RL-0 should be suitable for a chip used for an application specific purpose, like some of the direct 6502 serial stuff or similar.
RL-0 should support device health and maintenance, and may have a monitor program or support an external or virtual monitor program.
RL-0 should support, yet not require, having a display.
The Integrity Device Specification calls for a 4-way direction pad (arrows maybe?) and a few buttons, including Accept and Cancel, or A and B, Red and Blue, Btn1 and Btn2. These controls should be polled from a bit on an interrupt from a counter every 100/th of a second or so, the timing itself is arbitrary, several times a second updates to user Input controls, these are chosen for being represented in 8 bits, thus various boolean masks can be used for things like directional or multiple buttons at once.
Software should ideally support devices having a screen for Runlevel-1 or higher, and where intended for Runlevel-0 only, maintain a virtual I/O screen, even if a simple Run/Stop option to be viewed from an external debugger reading that section of ram, or a plug in device with a screen that can map Integrity Virtual Displays.

So this means if I go up to my 3d printer or desktop router and the are running Oxide devices, like a 65134 on a desktop pcb mill, and it does not have an lcd screen (or its broken), maybe a lathe... in most cases you will have some kind of screen, lets say a network repeater, whatever the device, if I plug in my Integrity tablet, or I have an SBC, whatever, them I can enter that debug mode and display the virtual screen from the headless Oxide device, on my Integrity or other Oxide OS device.

So, runlevel zero devices can exist, yet need a tiny bit of code, possibly just a few lines of text, yes/no, run/stop, etc, a list of variables and names or program options etc and their values in a table. this simplifies debugging and maintenance. In short, Oxide device will be able to talk to each other and offer services (like a display) to each other.

Oxide OS at higher runlevels should operate more obviously
headless modes for 6502 and 65816 should be offered,
Runlevel zero should allow automated tasks to work with minimal configuration
Part of the Oxide startup configuration should include moving to a higher runlevel after RL-0 is stable

Runlevel 1 or higher should allow the user or develop to include or 'boot to' a shell environment of their choice.
Oxide should provide functionality, organization and commonality.
From a developer perspective, their should be a set of routines that simplify tasks, and some protected areas for software to run mostly uninhibited, barring address locations and respecting certain standards.

Adding a check to protected areas of memory on every write could get very expensive.
using ram pages or blocks should make this easier, as each program should see a blank instance of the same hardware as if it were its own, with a system space and a shared space.

as the project develops, multiprocessing becomes a concern.
the 65xx is a subscalar processor, that with good design, can better approach scalar processing across its system with well timed data pipelining.
that is, when one chip is ready, the next is waiting, so each CPU cycle is used across the system, ie 'no wasted cycles anywhere' is the goal, though not always pragmatic

multiprocessing on the 65xx system is determined heavily by the hi-low clock cycles. much of this will require a lot o further investigation, at this point, it is basically a consideration to address. ultimately the hardware design will determine this as much as anything.
that is, to dual processor a system, you can use Phi1 instead of Phi2 on opposite chips for memory access.
on the other side, if you have other devices on the memory bus, having the board controller or other devices operate on Phi1 instead of Phi2, then not having two processors operating on RAM in hi-low cycles means you always have half a cycle to access RAM, because the CPU is not.
rather, it is not writing for certain, because it is addressing during that time.

A final ram management system is yet to be determined, and in some devices, may operate differently.
On the OS side, being able to know what RAM bank you are in, what runlevel you are in, what hardware you have, what vectors go to what interrupts etc. If you have different interrupts, these are things to consider now, going forward.

Nothing to set in stone, just a lot to think about now. At the software side, how can I package the basics, and reuse them everywhere, and what goes on a 1k ROM in a lathe?

I was thinking of getting a basic lathe, and a stepper motor and linear actuator, then you feed it a profile and it moves a knife down the side in and out to cut your table leg or whatever. Maybe instead, just a sound meter to actuator or motor and belt or whatever and move a pen.

The point is, Oxide should run projects like this too, instead of just fancy games and neat hexeditors on a nice screen.
Something simple, then maybe a plotter, or a plotter first, idk, I want to try a PCB mill, maybe a gantry...

Oxide level Zero should run appliances
Oxide level Five(or7) should run some nice games on a 65816 and let you draw pixel art and do math and run code and ...

In between are the 6502 modes and the 65816 headless modes.


I am soon trying to determine if I should use single processors and use COP vectors for 'all the other chips'
or if I should use dual cpu on opposite clocks, or if I should just use 'many processors and design towards cluster suitable problems'
I like the last one I think, to just say "you might have several tiny computers on the bus or network, or you might be alone"
OS wise, there needs to be hooks or stubs for "distributed data or algorithms" at the lowest levels
I have been reading a little on SMP SIMD etc and I am not sure what design to support.

I would ask this,
one: can I use two processors side by side, like to 8 bit cpu, 'to pretend to be' a 16 bit cpu? or 2x 65816 to think like a 32 bit cpu effectively?


two: should I want to use a 16 bit number on an 8 bit cpu, its just a little extra work and you take twice as long (plus a little extra)?
I am of the impression, you can process 128 math on an 8 bit cpu, its just going to take a lot longer, not just a flat multiple, but that multiple (128/8 = 16?) so 16x plus a few extra cycles for the carry, stack and shifting to get it to work. I have a mixed sized system, that has 8 bit, 16 bit, 24 bit, possibly 17 bit or 40 bit, and certainly 32 bit in the gpu, and maybe, a 64 bit math unit...
these can all talk to each other, its just going to take a little work and data manipulation... thats the pipelining bit, to get everything working right, so its effectively, closer to being scalar than any part is alone.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Ok, so this is one more reason to build the os to assign tasks intelligently, like sending a big math problem to a coprocessor or dsp and getting the results back, or doing so by hand if not

I want to os to be able to delegate processes to where they are done best

One one or two devices this might not be too hard to implement in house
Lots of cycle counts for operations and determining if it's better to do it, or offload it and wait

I still want to know about using multiple processors to handle bigger numbers or act like a bigger processor

You can use two register to act like a bigger register, can you get two chips to act like a bigger chip?

Unless you're talking something like bit slice processors, like those from Intel (e.g. 3000 series) or AMD (Am2900 series and successors and imitators), typically not. Parallelizing is a possibility in certain cases. So is using a processor with wider ALU as a coprocessor. But the overhead associated with delegation needs to be small enough that any gains are worth it.

If what you're really looking for is faster math for longer bit widths than the 65C816 supports, there are some discrete logic approaches you can take - Byte had an interesting circuit design back in one of the 1970's issues for hardware multiply using shift registers and adders. There are certainly FPGA options that are possible, too.

In days of yore, math coprocessors or arithmetic IC's (multipliers) were available, but most of the more common use cases for those disappeared when most processors started having integrated math coprocessors and hardware mutiply became more common. Other things, too. But a lot of this stuff went out of production sometime between 1990 and 2005 or so.

yes we are very likely in some devices to have a 32 or 64 bit (or other weird sizes like 40 bits for one of the DSPs) registers. the Micromega um-FPU is 32 or 64 bit math coprocessor and the more I read about it, the better of an idea it seems like having on my primary devices. Maybe not on simple devices and controllers, certainly on anything intended for the field.

I like having the mixed bit-width on the chips, it does complicate things (like is it better to use the coprocessor and copy back, or copy back the half you can use, or just do it local), however I think it teaches a certain way of doing things. Driver code does its job, the GPU is programmed for the most part separately from the main logic, I/O is offloaded, etc. These are common notions today.

So when the OS is running at 'user levels' then the PIC is running PIC code, and mostly organizing or sort interrupts, doing basic memory fetches for stuff, keeping the system running, it is the 'motor cortex' of the system, the more involuntary reflexes. This is all written in PIC code and it should handle commands from the CPU.
The GPU is running its own code too, some are more or less openGL, others are more C like and proprietary. It has the button, tilemap, background, blending, effects, line drawing, shapes, gradients etc all on board on its own in its own language. Each chip has its own language,
epson has application notes on connecting to tianma displays, one of our choices, and runs openGL es 1.1 offering our 'super nintendo' 3d graphics. Each gpu that gets used will need drivers to go back to the OS calls for drawing and games if more than one ever gets used. this is not a requirement its a guideline
all the while, the cpu is basically telling everything else what routines to run or what state to be in for finite state machine stuff (like listen at port, identify/handshake, copying data, closing connection etc), it should be doing logic, and the rest of the system should be working to pipeline data to that cpu, or doing what it delegated them to do.

at this time, I do not want to use dual cpu on shifting clocks, I want the cpu to act normally, and on the 'off half of the cycle' the PIC and everything else, including other chips or processing units, are then doing their thing. from what I read, this is 'cycle steal DMA'? and basically what we get here. I need to read further on memory, it comes up as well for multitasking.
I want to have RAM banks and to be able to switch between them, and have some of them 'protected' or walled off.
I think this lends itself to multitasking where each application thinks its running alone and interprocess communication is almost virtual networking
idk yet...

I do want the OS to handle loading user shells, so people can use whatever interface or prompt-language they want, forth, basic etc
I want the OS to offer utility, and not get in the way of development of apps

my next goal is to start up some emulator code and start getting stuff on "screen", moving data, going through opcodes and addressing modes and seeing how things work at this level. then add some numbers, maybe make a simple hex viewer, things like that.