Foxi Project

[-=Fox=-]

OK! (LONG Post with LOTS of info)

Here's the low down.

I've gotten the updates to Foxi (the original Menu system) working and its only missing a single program from the original "Next" Foxi version (Data Finder). Be before release it WILL have a working version of Foxi Chat (which now works!) which IS compatible with the WSR (God willing that horrible bug garry introduced can be worked with somehow..). All the other bugs that were in the original Foxi program have been fixed! (to my knowledge)

I've reworked a lot of code so you should be able to use the system, albeit its not seriously useful as it still lacks an actual file system, currently the only supported "Files" are Console formatted data pages (ASCII,Char Params) that are saved by the Foxi Text Editor which only creates files. The ability to Modify files will be in the next release, which is just a bit of code that is pretty simple to work with.

An actual File System will likely be release with FoxCI (CI for Command Interpreter) and Foxi will be a program within FoxCI, however the File System (for Foxi) will need to be updated for it to be fully compatible.

NEW!

The Foxi Modem is the first actual peripheral that will be usable by any High Speed Device (including the E2!) it is basically an arbitrary data transmission system, at the moment it's ONLY peer-to-peer so it will only talk to ONE other Foxi Modem. The Modem is a SECOND version of the original modem that incorporates new features that make the modem faster.

The Foxi Modem uses SDRP (Serial Data Routable Protocol) which was developed specifically for transmitting data "Serially" using only one input and one output, I did this because it was difficult and keeps the system remarkably simple to hook up and use. Yes, the data is routable because it uses "addresses" (999,999 possible) to establish connections and direct data, however the routing will be done with an external device which will use a type of "Token-Ring" protocol to eliminate "collisions" between data (when clients try to talk over each other).

SDRP is currently limited by the speed of Wire, and I am continuously looking for a way to increase the data transmission speeds. A "high-speed" variant will be coming out when the "Serial" version is finished as much as possible.

Foxi Chat is the first program to use the modem, once a connection is established the chat program will send lines of chat to the other client, it will take about 2 - 3 seconds to send the data, the next major version of Foxi Chat should bring that down to under 2 seconds (for 30 Characters). The exact speed in bytes per second hasn't yet been measured, I'll try to get that info so I can benchmark the system.

Another Peripheral is coming when I get a file system, you can prolly guess what it is, but I won't say until I have a prototype working ^_^

I am currently away from home and I won't be back until next week, I will try to get Dupes out so that you guys can play with the system and gimme bug info. The current dupe in the O.P. is WAY out of date I'll try to adjust the O.P. when I get done here so that information will be Current!

It's COMING!

[-=Fox=-]

Updates motherf***ker do you got them?

[KyouLi]

Hey Fox i like your computer but do you mind that you can release the CPU code so i can learn more? cuz i want to make a computer and nothing in this forum is related to that, they are too old and all the links are taken down and deleted. Thx

[-=Fox=-]

I haven't had much time to dev code for the zCPU...


However! My latest work involves an actual Shell, which is "reasonably" close to an Operating System.

It's called FoxCI (CI for Command Interpreter), It has the ability to execute arbitrary code, and programs can be installed into it, to perform ANY action by simply typing in the name of the program.

I'm working on the ability to enter parameters for the program etc.

This first version works and has a couple of OS calls.

I would also say it is "likely" to be one of the fastest methods for program execution from a shell possible on the zCPU (other than one button press etc).

I quit working on Foxi in favor of FoxCI and my modem is busted due to changes in the CPU/Gmod.

But I'm still alive and working on stuff when I can.

^_^


Also I'll try to release Foxi source as soon as I can... its REALLY difficult to get to the data at the moment...

[-=Fox=-]

Whew! Were going on two posts within a week! It's only slightly easier to get on the computers to get out, so I'll try to keep you guys posted.

I have some updates! I'll give you a run down on what went on with the modem and give you some more details on how FoxCI works

First off the Modem. When all the new stuff went on the last couple of months something happened to either Gmod and/or the zCPU compiler and my modems quit working completely.

You can skip to the section labeled FoxCI if your uninterested in the Modem.

Modem!
(Skip to FoxCI if your more interested in that!)

As a refresher, the Foxi Modem (called that because it was going to go with the Foxi system), is a simple serial I/O device that is interacted with using the CPU or E2 Highspeed inputs and outputs.

There's prolly a whole page more I could say, but for simplicity I'll point to the first page of the thread that has more details about the modem.

The problem that it developed is that it would no longer communicate with another device. I rebuilt the device and compiled the code for the modem, but it did not transmit the data.

After futzing with it for about a days worth of time, I was able to trade out the IDLE opcodes for a delay routine and changed a few opcodes for completeness and magically... it seems to work... however...

It's about as slow as dead chipmunk trying to climb a tree... only when the transmission speed is extremely slow... it actually gets the data... any faster... and it doesn't even work right, barely any data gets through...

So I'm not sure exactly whats wrong with it... my next idea is to try and run the I/O part of the system though the E2 to use as a "filter" and let it handle the wire data and feed it back to the CPU for processing and vice versa.

So that's the low down on it, it works but... extremely slowly.

FoxCI

FoxCI is an interesting system since it uses a fairly interesting Idea on how to execute programs, the idea kinda works like this.

It takes the string (array of bytes) and converts it into a single number that is "relatively" unique, the method is what I call "hashing" but that would be kind of a misnomer as told by someone who is in to cryptography...

Well... the point is that it generates "unique" numbers for an array of bytes.

A "hash" is equivalent to the command a user would enter into the command prompt, ie the actual string the user types in is what is hashed before hand, pre-generated data.

I then generate a table that combines the "Hashes" with the location of the data that is to be executed so the table looks like this.

I call it the "Command Array". This Data is pre-generated, before the command prompt is displayed.

[Start Table][Hash][Location][Hash][Location]....[End Table]

The table can be of almost any length and the hashes can be as big as what Lua can handle.

So as you can see, were getting to the execution system. You might actually tell now how it works! But I'll tell you anyways

There is a simple program that deals with the I/O of the keyboard and outputs that to the screen as a Command Prompt. Obviously where you type commands.

From there, when you hit the Enter/Return key the system takes the string that you typed and converts that into a single number (the "Hashing"), from there the CPU compares the generated Number to the number in the array that contains locations (Command Array). If there is a match the system executes data at the location in the next cell.

So then that begs the question "Why not just use a String compare function instead?"

1. Its slower execution time
2. It uses up more memory

With a string compare function you need to compare data cell by cell, byte by byte, for however length the string is... and I really didn't want to do that. Even though the code would probably have been simpler.

With the string compare you'd compare byte to byte from start to finish and execute code if the string matches, you could probably use fancy methods to improve the comparing... but you'd still be comparing an array of bytes to another.

With the Hashing method, the results are pre-generated for the installed programs, and instead of comparing the byte of the input string directly you only compare the generated hash from user input to the array of hashes already done...

Which is only one byte * (the number of programs installed) + Overhead (2 bytes), instead of comparing multiple bytes.

So I could have 100 programs installed and get decent execution speed, as the code is only an pointer increment, a compare and a jump to the code.

All installed programs must have an "exit" with a RET opcode. So the system actually CALLs the code, but Jumping would work too, as long as the program jumps back!

There ya have it, a very simple method for program execution which should be pretty quick.

If your REALLY interested in seeing the code, LET ME KNOW, I can pass out the basic code base for the system which currently only has a couple of basic OS calls you can use... of course you could call any function you see in the code by simple calling it, as most of the code is portable (saves registers, then puts them back before returning) and you can use the code anywhere.

Ideas are always welcome!

[Mat000]

You should implement a filesystem with memory (of course) and make really basic executable files.
So that the command line will search for the file located in programs/[cmd].exe or something like that, and those "programs" would be able to interfere with other programs, etc... And have their own "execution context", like a real program.

You'll be able to rather easily add programs, delete them, give permissions to them, edit them and more. But I guess it's not that easy to do

[-=Fox=-]

Actually in theory, the only filesystem modifications needed to the system are access to the program.

The command array was designed to be modified so that you could add a program very easily by inputting a number for the program and its location, wherever it was at! It's a matter of 2 bytes.... seriously.... "hash" & location.

So in theory the system already has that ability. For programs that are not on attached ram or in the CPU directly... well that's for another program to deal with.

In terms of actual Files such as ASCII data or Images etc, there is several different ways to implement which aren't terribly hard... all you need is a way to keep track of what data is what and give a way to access the data in a useful way.

The simplest way I've used was used when storing image data or ASCII data in the form of "Pages" exactly the same size as the file. Loading one was a matter of selecting the location of the stored data + Offset and then just an Mcopy later and BAM, you got your data. Foxi used this method for retrieving ASCII data saved from the Writing Program, all you needed was the "page number".

But for anything else... It's not hard, just a lot of little steps, it is assembly after all. :P

[Drunkie]

HL-ZASM performance and speed has increased significantly since the older versions of CPU and GPU. The code is compiled to Lua and runs client-side so I don't think you need to worry about the speed of stuff like string comparisons. The only thing that appears to be slow is compile time.

[-=Fox=-]

The code is compiled to Lua and runs client-side so I don't think you need to worry about the speed of stuff like string comparisons.

Well yeah... but that doesn't mean a whole lot, code is code, no matter how its optimized. I'm used to working on very slow CPUs where even with all of the optimizations and Lua... speed does matter. It probably doesn't matter the faster you go, but that's not the point. :P

The point is, it's different, and "likely" to be faster than a plain string compares.

[Drunkie]

I'm saying the difference is negligible and insignificant (Unless you are comparing it to super long strings). You have to sacrifice a little bit of performance at some point for code that is easier to read, maintain and helps you be more productive with more important functionality.

That's just my opinion on the matter.