Index

SheepOS is intended to be nominally 6502/65816 compatible and provide a graphic interface for a portable device. It works best with a minimum of 384KB RAM on bespoke hardware. If you object to these constraints then do not read further and do not suggest different constraints.

• Rationale
• Data-Types
• Character Sets, Strings and Streams
• Portability
• Memory Map and System Calls
• Libraries and System Services
• Default Applications
• Start Sequence
• Interrupt Handling

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

Rationale

Discussion on AnyCPU.org regarding the illusion of progress gave me an epiphany about RISC, CISC, operating systems and object orientation. The RISC philosophy has been to reduce data-types, often to 32 bit integer and little more. The remaining types are common, easy to verify and can be used to implement more exotic types. However, this ignores practicalities such as poor instruction density and the mere problem of running a bus faster to do the same work. CISC has its own problems and the fastest proprietary designs are a toppling tower of technical debt. While many designs are now an ad hoc mix of RISC and CISC (and 6502 has always followed the moderate path), RISC versus CISC obscured Fred Brooks Jr.'s mantra: "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious." It has obscured the function of an operating system. Yes, an operating system allocates memory and storage. Yes, a multi-tasking operating may attempt to isolate tasks. But, fundamentally, an operating system implements data-types, such as memory-space, directory, file, serial port and network socket.

Admittedly, there is a very large gap between integer addition and a useful computer. "Useful" is open ended but I aim for an extended definition of self hosting. This can be reduced to a rather circular memeplex:

• The primary purpose of SheepOS is to run a video player.
• The primary purpose of the video player is to teach circuitry.
• The primary purpose of the circuitry course is to build and repair 8 bit hardware.
• The primary purpose of the 8 bit hardware is to run SheepOS.

These are flexible requirements. For example, there are no fixed requirements for a video player. Indeed, the cheapest implementation may be detrimental to extended objectives. Minimal adjustments are required to make a video player which is also an audio player, a text to speech system, an audio editor, a video editor, a musical game system, a game system which displays pre-defined video frames or a system suitable for running circuit CAD software. The problem is mostly reduced to a layering of properties over feasible and cost effective hardware. I've been heavily influenced by C64OS which is a beautiful 40*25 text mode operating system with optional support for 1KB block copying via Commodore REU. What happens if the display is one or more 1KB blocks? With suitable clock speed, memory map, system calls and display hardware, the result is moderate but not awful. Specifically, 8MHz 6502 can play uncompressed 40*25 tile video and uncompressed PCM audio from MicroSD. Did I mention suitable system calls? Yeah, it'll run in a window, from BASIC.

One notable absence from requirements is support for TCP/IP. While it would be very desirable to access websites, it is not feasible to implement HTTPS/TLS without fast multiplication hardware. Even if third party assistance is provided, requirements collapse to a check-list of contemporary features including high resolution bitmap display, DHTML/HTML5 support, JavaScript JIT compilation, megabytes of linear address-space and at least 100 MIPS processing power. It is vastly preferable for 6502 hosts to peer with their own network protocols. Unfortunately, 6854 chips are obsolete and this hinders extension of AppleTalk or EcoNet. Regardless, a contemporary equivalent can be devised.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

Data-Types

The most fundamental function of an operating system is to implement data-types which are not implemented in hardware or micro-code. This means we should define types and their operations. We may also want to define what is not core functionality because this is probably library functionality. Unfortunately, the placement of micro-kernel, kernel, privileged driver, ABI or library may be shuffled, compromised or forced to match a historical implementation. This is particularly true if an implementation once fit or continues to fit into a 16 bit address-space or smaller. Anyhow, SheepOS supports an eclectic mix of data types:

• Supported: 16 bit integer, 32 bit integer, 48 bit integer (for time, inode and file offset), 64 bit integer, 32 bit float (unconventional format), 64 bit float (unconventional format), application, application class, stack, buffer (including 40*25 text buffer), window, icon, joypad, keyboard, pointing device, interrupt, event, storage volume, partition, directory, inode and 16 bit virtual color-space.
• Not supported in version 1.0: command line parameters, memory allocator, vector, matrix, cipher, hash, random, PS/2 device, SCSI device, parallel port, serial port, network packet, printer.
• Not supported in any planned version: Unicode string, regular expression, XML, JSON, jumbo frame, TCP socket, bitmap display.

The most fundamental operations include arithmetic: addition, subtraction, multiplication and division. Large systems have usually included multiplication and division opcodes. (ARMv1 is a notable exception to include multiplication but not division. I assumed this was due to the scalability of addition, subtraction and multiplication but it was due to the poor interrupt response of NS32032 division being incompatible with floppy disks formatted with 6502.) Anyhow, multiplication and division has been bit of a fudge on 8 bit computers; especially so with floating point. I've suggested that squaring should be be counted as a distinct operation. However, I was unaware that there are many ways to multiply and a large amount of legacy software doesn't use the most efficient method. I would *hope* that an operating system would provide the most efficient primitives. Unfortunately, the most efficient algorithm depends upon the input data. Some algorithms are more efficient if the top 8 bits are zero. Some are more efficient if top bits are sparse. Some are more efficient if bottom bits are sparse. None are the most efficient if both inputs are equal. Since the 1980s, RISC systems with one cycle or two cycle MULS R1,R1,R1 have skipped a large amount detail. Separately, coarse division of 8 bit quality or so is often sufficient for progress bars and similar indicators. No facility for such operation is commonly offered.

Floating point representation is unconventional and is intended to minimize sorting operations. Conversion to and from IEEE-754 may be required, although, unlike IEEE-754, it is in all cases possible to multiply single precision numbers and represent the result as double precision. Use of one's complement or two's complement mantissa is a detailed subject. Two's compliment simplifies addition. One's compliment simplifies multiplication. For Taylor approximation, such as sine calculation, alternating addition and multiplication make either representation moot. However, sort operations are O(n log n) and therefore a representation which minimizes sorting is overwhelmingly important in the general case. Further disregard for convention includes complex input gamma function, inverse square root function, a complete lack of hyperbolic functions and CORDIC working in right angles rather than radians. I am strongly considering base 240 floating point format across BASIC, Forth, C and hardware blitters. Each byte of mantissa allows accurate representation of 1/10 and 1/12. The main impediments are use of float routines for integer division and CORDIC compatibility.

A stack is a fundamental type and I hope to separate call and data stacks in a manner which is compatible with Forth. In particular, this means flag bits returned from the operating system should be a convenience and are not mandatory. I originally hoped to have Z80 compatible stack with 16 bit alignment. Potentially, this allows a processor or virtual machine to switch instruction format. The intention was that legacy applications or libraries could drawn from other processor architectures. In this arrangement, registers are not preserved. Indeed, they may not be visible between switches. Unfortunately, this works really badly with 6502. Instead, I will be following Dr. Jefyll's idea to implement a wider stack across multiple regions of memory. Unfortunately, to satisfy numerous constraints (minimal memory configurations, windowing, legacy ABIs, 6502/65816 compatibility), all of these additional regions are restricted to the range $0000-$01FF. This is not a concern on 65816 outside of bank zero because absolute references to this range never clash with zero page or stack. It is only restricting on other targets. Regardless, it is possible to pass 32 bit, 48 bit and 64 bit parameters to and from the operating system. In particular, the data stack is wide enough and deep enough to perform 64 bit floating point multiplication on 5*5 matrices.

BigDumbDinosaur suggests that time is a fundamental type. While it is preferable to hold time internally as a monotonic integer and use RTC hardware which does same, many battery back-up clocks use the Julian calendar. The implication is that any kernel supporting Julian hardware should perform two way conversion of time formats. Whereas, a kernel which only supports monotonic hardware may delegate conversion to applications. This agnostic arrangement may lead to duplication and error where kernel, library or application have slightly different implementations. 48 bit milliseconds are suitable for 8925 years. 48 bit integers could be upscaled to 64 bit float (16 bit exponent, 48 bit mantissa) and therefore conversion can be performed with floating point MODDIV.

Much effort has been wasted on light mode/dark mode interfaces and this probably began with Apple's transition away from 6502 and to a Xerox interface. To resolve this matter in a manner which is broadly compatible with SheepOS's 16 bit stack architecture, a virtual 16 bit palette will be implemented in which four nybbles have decreasing influence on the resulting color. The bottom eight values ($0-$7) will be 1 bit per channel colors (fully saturated black, red, green, yellow, blue, purple, cyan, white). The next four values ($8-$B) are likely to be warm colors which improve the definition of useful shades. Specifically, gray, orange, pink and brown. This is inspired by snooker and hexachrome printing. The final four colors ($C-$F) will be defined by the class and privileges of the application. Of these, two are highlight colors, one is a neutral color and should contrast with other colors. Enforcement of contrasting colors allows a portable user interface to be constructed without consideration of light/dark mode. The 16 bit palette entry may be expanded to 24 bit color or contracted to 8 bit color. This operation may be processor intensive and therefore caching may be desirable. The cache must be flushed when the settings are changed.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

Character Sets, Strings and Streams

My personal preference for character encoding is a stateful scheme which uses escape symbols to switch between upper and lower case. This is wildly impractical with other systems and does not work well with text display hardware. As a matter of practicality, stateless schemes with 8 bit alignment are much more tractable.

Whatever you do, don't follow PETSCII too closely. PETSCII is a keyboard input format, a stateful cursor system (with color and reverse video) and a graphic character format. Given the conflicting uses, PETSCII is limited to 128 symbols and this creates further conflict between upper case, lower case and graphic symbols. It may be preferable to have text input events (mixed with pointer events, window events and other events) and output drawing where strings of convenient types may be expanded according to the functionality of available hardware. In the trivial case, 1 byte and 2 byte strings would be padded and colored for the same character display.

The next problem is character streams, disk blocks, pipes and network sockets. Ideally, these should all be unified and I've wresled with this problem with little success. The major feature that they have in common is that they should be blocking or non-blocking. However, it may be otherwise preferable for them to be separate by default. If a legacy ABI provides one stream mechanism (Commodore, Acorn) then the ABI is responsible for unifying types with the minimum necessary properties. Also note the mis-match between input events, output drawing and character streams. drogon has similar difficulty with pipes. To boot-strap implementation, I'm considering not implementing any of these types. In particular, that means implementing a windowing system and task switcher *before* implementing a filing system. While this may seem like an act of vanity, it has the distinct advantage that I can implement a debug window for the filing system which responds to keyboard and mouse events. Furthermore, if the contents of a text window is held in the application's memory-space then the only system call for output is "redraw buffer" - and for some targets this is a null call. If all applications (and daemons) are restricted to one window of the same size then redraw is relatively trivial because the maximum number of clipping rectangles is reduced. It is also possible to specify the first line of redraw and therefore console updates on the bottom row require minimal processing power. I understand that others have successfully implemented operating system features in atypical order. For example, Linux implemented task switcher, text display and UART before implementing a filing system. I intend to go much further and implement text GUI before filing system.

Strings are a problem because there are many operations which can be usefully performed over memory, character streams, files or other resources, such as clipboard or database index. However, if these types aren't implemented or unified then string implementation is incomplete. While a subset of functionality, statically bound to application, may seem sufficient, it creates unobvious legacy support problems. Given that it is typical to access files over network, a unified implementation of filing system requires network support. This leads to string operations with considerable latency. Volumes also come and go with regularity. There is also a common hierarchy within POSIX where malloc() uses mmap() which may require USB to access virtual memory via attached storage or USB network interface. Although malloc() was one of the first functions to be implemented in Unix, it has become a façade for the filing system over the network stack over the USB stack. A concise operating system with acceptable functionality requires some of this scaffolding but not all of it. Virtual memory can be avoided, although an overspill for a key/value store remains valuable. I am ambivalent about USB support but NFS and SMB will definitely not be supported. NFS 4.1 is an almost sane protocol - except for cache invalidation.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

Portability

Portability is intended at multiple levels:

• A small subset of legacy applications from Commodore or Acorn may run on SheepOS. This requires re-assembly and wrappers which only work on 65816.
• SheepOS applications linked with a re-locator and portability wrappers may run on Commodore or Acorn hardware. The re-locator allows maximum use of RAM. It also ensures zero page usage never clashes.
• A hobbyist platform may provide a SheepOS wrapper and run SheepOS applications. Support for Commodore or Acorn applications is optional.
• There is an upward compatible path to future hardware.

SheepOS is influenced by AmigaOS and is mostly a collection of libraries. The remainder is a micro-kernel which is specific to target hardware. SheepOS is intended to run on hardware with privileged I/O. Specifically, the preferred implementation uses a door-bell to invoke NMI. However, this is never invoked directly by applications. Optional support for Commodore and Acorn ABIs allow a subset of legacy applications to run on SheepOS. Unfortunately, there is a long list of restrictions. Numerous opcodes are dis-allowed or require feature testing prior to use. Application must use ABI only. This excludes any direct video drawing or memory twiddling. Scope for direct I/O is limited, although some configurations may allow Apple II card support or SID audio. Most importantly, SheepOS applications require a load address of $2000 and therefore re-assembly is overwhelmingly likely to be required. Functionality may be extended to multiple hobbyist systems, although 65816 or other banking scheme will be essential to support conflicting use of page $FF and the sheer volume of library software.

The SheepOS libraries are intended to work with a micro-kernel which provides atomic operations and privileged I/O. The latter is too onerous for some developers and can be skipped. Particuler hardware is assumed and this may also be skipped. Instead, SheepOS may be guest to another ABI and run on foreign hardware. It is highly preferable for target hardware to support 65816 with 48KB RAM in multiple banks. The upper 16KB is far less important. In particular, it should be possible to run SheepOS on wayfarer's Integrity hardware, drogon's Ruby anniversary hardware, BigDumbDinosaur's POC1.x hardware and W65C265. A subset of functionality runs on Commodore64, jfoucher's Planck hardware, AndersNielsen's ABN6502, BBC Micro simulator with replacement ROM and Commander X16 with SheepOS patches. I investigated the possibility of guest ABIs within SheepOS. In particular, I hoped that it would be possible to run C64OS or CopacetOS™ applications within SheepOS. This would be especially useful if SheepOS is used as a compatibility layer on foreign hardware. Unfortunately, C64OS requires 64KB RAM and, ideally, Commodore REU. CopacetOS is more hopeful. The major impediment is POSIX style unaligned block access. This may be slow and unreliable on target hardware. There is also the concern that CopacetOS is being abandoned and that BigDumbDinosaur may pursue compatibility with one of the four incompatible CP/M on 6502 clones. CP/M compatibility is also possible. However, it is vastly preferable to support block sizes larger than 128 bytes.

SheepOS is intended to run in a variety of desktop and portable configurations. Therefore, the following devices may or may not be present:

• One or more 12 button SNES joypads.
• Quinkey (or similar) keyboard connected via SNES protocol.
• Keyboard connected via SNES protocol or PS/2 protocol.
• Mouse connected via SNES protocol or PS/2 protocol.
• 640*480 pixel VGA display or 800*600 pixel VGA display.
• Passive LCD or OLED interface which may or may not be 128*64 pixels.
• Eight button interface located under the LCD or OLED.
• 8/16/24 bit PCM audio (MAGPIE) which only plays sound at 30kHz or 48kHz.
• Battery back-up clock.
• GPS.

Wildly differing configurations may be assembled using a trick popularized by CollapseOS. Specifically, one assembly file makes references to all of the files which must be included to make a functional system. The list will include one micro-kernel, one keyboard interface, one display interface and one sound interface. Some of these options may be a null implementation. Interfaces of one type will be kept consistent but there is no requirement to keep input consistent with output nor make any interface downward compatible.

I/O may be mis-matched. While it may be reasonable to expect keyboard and VGA, keyboard may be used with LCD/OLED only. Likewise, VGA may be used with joypads only. In this case, all keyboard input events should be attainable via joypad. In the converse case of keyboard and LCD/OLED, functionality may be limited to data entry and not much more. The 128*64 interface should operate like a Casio digital watch and cycle around all useful applications starting with time, date and stopwatch. The file browser may indicate volumes mounted, storage available and estimated completion time for file copy operations. On a VGA/LCD system with "media buttons" and keyboard, focus for the primary joypad is determined by preceding use of the media buttons or keyboard. If GPS is absent and VGA is absent, it is possible to set time via the media button interface by holding the modal button when time is displayed.

I am aware that SheepOS may define a growing set of interfaces. Unfortunately, this is similar to Windows with PIF files for icons, Tool Tray, Start Menu, Auto Start, extensible tabs for device drivers under Windows95 and further "enhancements", such as Metro Tiles. Given the hardware targets, it may be more pertinent to suggest unfortunate similarity to the BlackBerry devices which, I understand, had incompatible input events over four generations of hardware before the Research In Motion stopped and switched to Android. In the worst case, the SNES PowerGlove required 22 compatibility modes. Hopefully, no more than two transitions will be required: from stateful text applications to stateless network/GUI applications to stateless virtual reality applications.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!