### zOS
zOS is a spin-off from the ZPUTA test application which was created to verify ZPU Evo and SoC operations. ZPUTA evolved as different FPGA's were included in the ZPU Evo scope and it became clear that it had to be more advanced due to limited resources. Once ZPUTA had evolved into something of a level of sophistication akin to an OS, it was split and zOS was born.

Originally the ZPUTA/zOS developments only targetted the ZPU architecture and they had two primary methods of execution:
* as an application booted by IOCP, * standalone booted as the ZPU Evo startup firmware.
The startup mode is chosen in the configuration and functionality is identical. When booted as an application by IOCP, zOS is stored on an SD card and loaded at boot time. When 'standalone' zOS is stored in the onboard Flash (or preconfigured BRAM acting as a ROM).

More recently, zOS was ported to the ARM Cortex-M4 architecture for use with the Freescale K64F on the tranZPUterSW project. As the K64F is a fixed architecture CPU / SoC only one method of execution exists, 'standalone', it is stored in the onboard Flash and started when the CPU powers up.

In zOS, all non-OS functionality is stored as applications on an SD Card. If an SD Card isnt present then it is better to use ZPUTA as it has the ability to cater for limited FPGA BRAM resources as all functionality of ZPUTA can be enabled/disabled within the primary loaded image.

Originally zOS only operated with a Terminal Emulator via a serial line, but with the advent of the tranZPUter SW-700, zOS now To operate, zOS requires a serial connection (physical or usb-virtual) with preferably an ANSI/VT100 terminal emulator package connected to it. The requirement for an ANSI/VT100 terminal emulation package is to allow commands such as the editor or readline to function correctly. A dumb serial terminal will work fine but at reduced application functionality. If no serial connection is available or an interactive OS is not needed, just the ability to boot an application on power up, then the IOCP would be the better choice (albeit not yet ported to the K64F).

A recent hardware development, the tranZPUter SW-700 v1.3 sees zOS operating as a host OS where the keyboard and display are under its direct control. In order to maintain backward compatibility with the serial based applications, an ANSI terminal emulator has been developed and embedded.
## Using the OS
Throughout my career I have used or designed systems where you had live interaction with the end product to either monitor, change the logic flow according to market changes or fix problems real-time. This has normally been through an embedded command processor using the TCP client-server interconnect. The benefits of this approach are enormous and done correctly mitigate security risks. Companies such as Reuters and TibCO use this technique (ie. their 'Hawk' product) and I have crafted it into my own developments such as the trade execution and pricing module I wrote at Morgan Stanley and the Options trading system at Chase Manhattan with great effect.

When working on some of my projects in this repository it has always been at the forefront of my thoughts that I wanted a similar environment, even on an embedded system with limited resources, where I could monitor, change or fix on the fly. This requirement started off with the IOCP which has basic monitoring, uploading and execution functionality and was further enhanced when I started writing ZPUTA with its enhanced functionality and external applications.

Time scheduling, at least a basic level will soon be implemented which will allow an embedded application driving the hardware to run as required yet still leave processing resource to run the OS and provide services to a connected user/developer. The K64F version of zOS uses threads for tranZPUter board control but this needs to be encapsulated in defined API's and made available on the ZPU and NIOS II architectures.

The projects dont have a network stack as most dev boards I've used dont have ethernet which limits connectivity to the serial line. I'm considering adding an ESP32 module onto future tranZPUter cards and so networking will remain under consideration until this addition is realised.

The advantage of asynchronous serial communications is it is simple and can be connected to a terminal on nearly every PC, either direct via a USB adapter or via RS-232. I could implement SLIP but keeping it simple at this level is my preferred alternative. So long as you can connect a serial line between the dev board hosting zOS and a PC you can use it's functionality.

The OS interface has been written keeping in mind that only a serial text based terminal is available. Some components such as the Editor need more advanced capabilities and to this end the venerable VT100/ANSI emulation was chosen as a suitable candidate (which means you need a VT100/ANSI emulator sat in front of the serial line in order to use the Editor). Interaction is keyboard and text based, (no nice GUI interfaces!) with the sections below providing information needed to use the interface.
### Command Line The first introduction to the OS is a sign-on message which details the CPU, version etc and issues a prompt for command input, ie: ![zOS Startup Screen](../images/zOS_Startup.png)
Interaction with the OS is no different than MSDOS, you enter a command and get a response. The only difference is that it was originally within an embedded system not a full blown PC. This is now changing as zOS is evolving to work as a User OS on the Sharp MZ-700 under the ZPU/NIOSII processor.

The zOS command line is not a shell interpreter just a basic text interface provided for the issuing of built-in commands or commands stored on the SD card. It does include a cutdown readline capability with history to aid in command entering and retrieval and generally follows the GNU readline functionality, the recognised keys at the command line are:

| Key | Action | | --- | ------- | | CTRL-A | Go to start of line. | | CTRL-B | Move cursor one position to the left. | | CTRL-C | Abort current line and return CTRL-C to calling application. | | CTRL-D | Not defined in shell, passed to running application. | | CTRL-E | Go to end of line. | | CTRL-F | Move cursor one position to the right. | | CTRL-K | Clear the line. | | CTRL-N | Recall next historized command. | | CTRL-P | Recall previous historized command. | | HOME | Go to start of line. | | END | Go to end of line. | | INSERT | Not yet defined. | | DEL | Delete character under cursor. | | BACKSPACE | Delete character to left of cursor. | | PGUP | Not defined in shell, passed to running application. | | PGDOWN | Not defined in shell, passed to running application. | | ARROW UP | Recall previous historized command. | | ARROW DOWN | Recall next historized command. | | ARROW RIGHT | Move cursor one position to the right. | | ARROW LEFT | Move cursor one position to the left. | The readline mechanism also recognises a few internal commands, namely: | Command | Action | | ------- | ------ | | !\ | Recall and execute given historised command identified by \. | | hist\[ory\] | List the history buffer. | ### Applications
The applications currently provided by zOS reside on an SD card and are summarised below. For more detailed information please refer to the Application section (on the left navigation bar) or the Application README file.
- #### Disk IO Commands | Command | Parameters | Description | | ------- | ------------------------------------- | ----------------------------------------------- | | ddump | \[ \] | Dump a sector | | dinit* | \ \[\] | Initialize disk | | dstat* | \ | Show disk status | | dioctl* | \ | ioctl(CTRL_SYNC) | - #### Disk Buffer Commands | Command | Parameters | Description | | ------- | ------------------------------------- | ----------------------------------------------- | | bdump | \ | Dump buffer | | bedit | \ \[\] ... | Edit buffer | | bfill | \ | Fill buffer | | blen | \ | Set read/write length for fread/fwrite command | | bread | \ \ \[\] | Read into buffer | | bwrite | \ \ \[\] | Write buffer to disk | - #### Filesystem Commands | Command | Parameters | Description | | ------- | ------------------------------------- | ----------------------------------------------- | | falloc | \ \ | Allocate ctg blks to file | | fattr | \ \ \ | Change object attribute | | fcat | \ | Output file contents | | fcd | \ | Change current directory | | fclose | | Close the open file | | fconcat | \ \ \ | Concatenate 2 files | | fcp | \ \ | Copy a file | | fdel | \ | Delete an object | | fdir | \[\] | Show a directory | | fdrive | \ | Change current drive | | fdump | \ \[\] | Dump a file contents as hex | | fexec* | \ \ \ \ | Load and execute file | | finit* | \ \[\] | Force init the volume | | finspect | \ | Read part of file and examine | | flabel | \