### ZPUTA
ZPUTA started life as a simple test application to verify ZPU Evo and SoC hardware designs as they were being developed. It's name is derived from ZPU Test Application and it has evolved over time from a simple program to something of a level of sophistication akin to an OS. It can be built as a single firmware image with all functionality within it or split with most functionality on a connected storage device such as an SD card. zOS was split from ZPUTA and had much of the internal functionality removed, relying on the external storage making it more suited to place into end projects.

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 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 preconfigure BRAM acting as ROM).

More recently, zOS/ZPUTA 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.

The idea behind ZPUTA is mainly that of testing, getting internal access to an embedded hardware system and running codelets to test or try hardware features. Each test would be built as an internal function and an external app, this was paramount due to the development boards being used. The Cyclone V based DE10-Nano FPGA board used to develop the ZPU Evo has more than 600KB of RAM memory wherease a Cyclone 10LP on the tranZPUter has only 120K of which a chunk is used as cache in the Evo design, thus the latter needs an SD card and external applications to test thoroughly. All functionality of ZPUTA can be enabled/disabled within the primary loaded image.

To operate, ZPUTA requires at least one serial connection (physical or usb-virtual), preferably two for debug output. On the primary serial connection it is preferable to have an ANSI/VT100 terminal emulator package connected. 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.
## Using ZPUTA
The ZPUTA 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 emulation was chosen as a suitable candidate (which means you need a VT100 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.
Prior to ZPUTA, I created a bootstrap program called the IOCP (I/O Control Program) which operated at the lowest hardware levels and was able to boot more sophisticated programs, ie. ZPUTA. The IOCP is size sensitive and was designed to bootstrap from any memory device and by including an SD card and the [Petit FatFS](http://elm-chan.org/fsw/ff/00index_p.html) it is able to bootstrap off an SD card. IOCP was originally used to bootstrap ZPUTA, aiding development speed by just copying a ZPUTA kernel onto an SD card when a change was made but eventually I included the low level code into ZPUTA and it was able to boot as the primary software without needing IOCP. IOCP still remains within the project to boot any application not needing ZPUTA or zOS level of sophistication.
ZPUTA will remain with its original purpose, to aid in testing, whilst zOS will over time become more a refined OS for my own projects.
A few months ago the tranZPUterSW project was born as an offshoot from the tranZPUter in order to more rapidly forward the design in softwareapid development. This came in the shape of the Teensy 3.5 development board by [PJRC.com](https://www.pjrc.com/store/teensy35.html) or more importantly the Freescale K64F processor, an ARM Cortex-M4 CPU. This required quite a few changes to the source code to allow for two different processing architectures but it makes the OS more useable by 3rd parties in their own projects given the plethora of ARM development boards. ### 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: ![ZPUTA Startup Screen](../images/ZPUTA_Startup.png)
Interaction with the OS is no different than say MSDOS, you enter a command and get a response. The only difference is that it is within an embedded system not a full blown PC.

The ZPUTA 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 ZPUTA 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 | \