Oxide uses a series of "runlevels" similar to POSIX systems, with runlevel-0 being capable of headless and autonomous operation on an 8-bit mpu acting as keyboard or drive controller, to higher runlevels which offer full color screens with games and drawing applications.
Runlevel 0 is our first goal other than planning and documentation, it is largely a bios and ROM based monitor program.
This is a big undertaking and it will take a long time. Small incremental progress, as time allows, is the way forward.
I have a lot to learn, and many different things to do to see this through.
So our first goals are very simple I/O and getting some basic drivers going for the chips we use, one at a time.
Our main devices at Wayfarer Technologies generally use a 'D-Pad' or 4-way arrow keys, and several buttons similar to the 8 bit consoles, with a 'Menu', 'Option', 'Confirm' and 'Cancel/Back'.
a core polling routine for getting input, and for display, we will probably just move a few LEDs, though having a cursor and icons is the basis of the UI/UX.
Beyond this, we want to explore multiprocessing and pipeline optimizations, though just getting a core system going is enough.
as 65xx chips tend to have an Accumulator, X and Y registers, the notion of 2D plotting devices becomes quickly obvious.
Our earliest devices are likely to include a pen based plotter, mcu controllable enlarging camera and similar devices that are useful for bootstrapping electronics production.
Oxide is going to be open-source in one form or another, though any specific license is to be determined.
At this time guidance, collaboration and general advice is welcome and appreciated.
Oxide is going to start on 6502/65816 with support for the 6522 and possibly to the 6551 or other UART type chips.
Beyond the '02s, Oxide is intended to run on the Wayfarer Technologies "Integrity" mobile tablet and peripherals.
This includes a PIC24 or msp430 to act as a board controller or "RIOT" chip (RAM/ROM, I/O, Timer), a GPU/lcd controller from 4Dlabs, Bridgtek or Epson, and a nice 16-bit sound chip we found a current supplier for. The Integrity is in development and may see a public offering in late 2024, though quality is more important than speed for this kind of mature node technology.
From 6502/org:
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.
____________________________________________________________________________________
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
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, PCMCIA, etc, 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/zCpl00 ... J3Plg8.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/publicatio ... g_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