

Just in case electronics is not for you try the Virtual Medicine page. For some theoretical and practical links for techniques to improve fuel efficiency click Fuels. Or a personal comentary on Google ANDROID. Or maybe some Beautiful Maths. Or if you have an xda mobile device and would like to help debug (Alpha Test) MIDForth then that would be nice. Or for a general comnentary on Windows Mobile 6 Beta and other things click here.
The Indi processor is being superceded. Nibz will have a higher performance and a lower area. It is BSD licence. The development will be uploaded to google code. The latest Indi design will be placed on the download page of the nibz site. This site is migrating to google code and google sites. This site will then become a MID4th block set distribution service, and a simple index page to redirect people. There is much to do, and progress is slow. The first step will be to reformat this site, and place the respective page content on either my google sites site, or on the correct google code site. This process is complicated due to the mark up limitations and differences of the google code wiki and google sites page format.
The google sites site will contain links on the projects page
Thanks for your patience as the migration takes place.
The ethos of the project was inspired by the realization that a web server could be made very small if only a few pages were served by it, and parallel servers joined to make a whole site server. This then lead to the minimum specification of a 16 bit device with 128K memory access.
A low video resolution of 256 by 256 is not seen as a restriction with multiple simple processors handling segments of larger screens, and a font containing the chemical element symbols would inspire programming useful for environmental elemental recycling.
The extreamly low logic count of the indi processor leads to power efficiency and possible compact SMP arrays using a clock halting scheme. Bus and cache schemes are being imagined which can lead to increased throuput without sacrificing logic simplicity.
The low logic count is suitable for locating on chip next to a static column set in a DRAM architecture. This would allow a prioritized SMP design to be integrated on DDR sticks, using the host PC as an IO processor. Talking of DDR, is a PRECHARGE necessary on a write cycle? I don't think so, as there is no SENSE needed of data which will be overwritten.
The following list covers a general overview of what is and will be available in terms of hardware and software.
Latest: Added Java bytecode instruction names to database with dot prefix. Released character ROM for ASCII and ChemElem 128.
The Altera Quartus II version numbers follow the usual technology.feature.bugfix dotted triad.
Latest: Reading up on Verilog in order to give it a go.
The project aim is full modularity with microcontroller to supercomputer silicon scaling. The processor has a Wishbone bus. A bit reversal memory cell will ease DSP applications. Limited pipelining will be provided in the indi16, to help maximize the throughput.
We'd probably have some space consuming space saving options like 4T state DRAM caches, top of stack write back cache, and instruction prefetch units in the development line, if we get to custom silicon.
The processor features a MISC (minimal instruction set computer) architecture with 4 ALU operations, and an indirect post increment read, pre decrement write addressing mode for stacks (one of the only two addressing modes). Along with a four stack register model, with accumulator (A) and carry flag (C).. Here is the ISA, at two instructions per 16 bit cell. (MSB executed before LSB). Indirect P write is the special null destination. The bit positions are as follows:
Examples of assembly are written using + (add), * (and), - (xor) and / (load). Also . (indirect): and = (direct) indicate addressing modes. Registers are indicated by 0123 or PQRS.
/=p.r /.p=p 'load p and save onto r stack, and then load immediate and save in p reg. (i.e. subrotine call)
$addr '16 bit address to call
/.r=p /.p.p 'load top of r stack and save direct into p, and then load immediate and do not save it (null mode) (i.e. return)
The last /.p.p adds 1 to the program counter, and so steps over the literal address loaded with /.p=p which is not counted in the /=p.r return address saving. The use of two bytecodes per instruction fetch cycle removes quite a lot of stack offset code compared to single byte instruction fetching. Also the .p destination having no writing or pre-decreasement, increases the code efficiency too.
If you wish to contribute to the project please contact jackokring@gmail.com with any comments, contributions, suggestions, bugfix requests.and other errata. The following project files and folders may not be current, but are a random selection of included pre-design information.
OpenSystem - The Main Project Directory for indikernal OS ideas.
Thanx