Quote:someone who has absolutely ZERO knowledge concerning computer technicalities could operate perfectly.

Quote:a kind of BIOS/bootstrapping program will run from ROM to start up the OS in the instruction RAM, and you're off. All of this software will be stored in a 2 Kibibyte (2048 byte) piston tape hard drive modified for speedy access (for a piston tape). Along with this massive hard drive, there will be 128 lines of RAM for programs to run off of, and 128 lines of data RAM for those programs to manipulate.

Quote:Sapia II is not pipelined, so I don't think i'll be able to get the clock speed under 20 ticks.

Quote:It could easily sport a basic GUI for selection pages, and display text and graphs on the same screen.

Quote:A multi-user OS (multiple users can have separate accounts, and have their own files), a virus-detection program along with the file-downloading program

(06-24-2016, 11:08 PM)Hawk49 Wrote: PNW! It's been so long! Good to see you again! Anyways, I'll try to address each of your comments/questions as thoroughly as possible.

Of course there will be some kind of manual included around the user interface, as my only goal was that one wouldn't need any technical computer knowledge, like what binary is, or how adders, or any kind of technical part of the computer works. All a user needs deal with is software. Also, I'm hoping that really most of the directions of use will be given to the user via text from the actual computer, so that all you need to know is "press the startup button and wait for the computer to tell you something", though that process might take a while.

There is only 1 instruction RAM block, and it's 128 lines. I might have been a bit unspecific and ambiguous, but the BIOS is stored in ROM, not the hard drive. It's also quite a small program. All it does is, at startup, it locates the "file selection program", loads it to the instruction RAM, and then runs it. The file selection program will obviously be smaller than 128 lines. What i'm calling my "OS" simply refers to my file system, along with a program for organizing those files, and a program for navigating through them. Both of these programs must be less than 128 lines, or else they would not be able to run efficiently in the instruction RAM. The OS programs will not be running while a "third party" program is running, i.e. paint, grapher, calculator, web-surfer, etc. From startup, an OS program is used to select a 3rd party program, and they trade spots in the Computer's memory, i.e. the 3rd party program goes to instructionRAM, and the OS program lies dormant in the hard drive. Once the 3rd party program is done, and the user wishes to select another program, the OS program for file selection is put back into the instruction RAM and the cycle continues. The process by which this quite simple, and involves something I call a page manager.

As for Sapia II not being pipelined, I just looked at how many pipelined computers have actually successfully been made in minecraft so far, and I'm discouraged. What I want more than anything is to make this thing a *reality* on the server, even if that means sacrificing a bit of performance. I might experiment a bit with pipelining, but I feel like that is be more of a possibility for me in a hypothetical Sapia III.

I would be willing to have a separate text screen, but I just haven't found any... it's basically just easier for me at this point to program the text into a normal (x,y) screen rather than invent a kind of ASCII display. If I come across one, or find the time to make one, I will. Hopefully I will be able to make the coding for text output easily adaptable between cartesian screens and segmented displays.

I do not think that a multi-user OS is overboard at all. In fact, I believe it will be one of the easier things to make. Allow me to explain how this will work. The user-specific partitioning of the data in Sapia II will take advantage of its file system, so to give a full explanation, I will explain how the file system will work.
In memory, a file before it is accessed is simply two pointers (values of other memory addresses) of adjacent addresses, the one with a smaller address corresponding to the lower bound, the other to the upper bound (both ends inclusive) of its contents' addresses. The contents contained within these bounds are either a list of pointers (each, again giving a range of addresses), or data to be used in some other way (i.e. a single program, or a data save related to a program, such as a graph, or important numerical values). This way, files have other files in them, which could have other files in each of them, and so on and so on, until the cycle terminates with a file's contents not being another file, but actual data (that is again either itself a program, or related data). It will be a standard of version 1 of the operating system that the first file contained in any given file will lead to a chunk of data that records its name. In the case of terminating files, that contain only program-related data, their name is the name of their parent file. How will the contents of a terminating file be distinguished from a simple cone all-encompassing file called "computer". The immediate children of this file will be "user 1" "user 2" "guest" or whatever names people wish to choose. All data that is associated with them, i.e. they are allowed to edit that data, as they downloadeollection of pointers? Programs that access files simply have to remember which names correspond to data, and which names correspond to files. Doubtless, all of this information will be included in some OS files, like "pathway files" and "terminating files".
All of this being said, back to how the multi-user OS functionality will work. All files in the computer will be included in d it or made it, will be included in these files. Also included under the "computer" file will be the "OS" file. This contains all information not related to any one user, but to the smooth functioning of the whole underlying computer. Included here will be files that contain all kinds of system information, like privileges allowed to each user, data allocation information, OS programs, and other stuff like that. Basically, users who don't have permission will not be able to edit any data that is not part of their user file, or that they don't have permission to use. A password system will be used to allow a user on to a given user file, or to edit certain important programs, like the OS.

I'm excited to make some IntOREnet related programs as well

As for antivirus, it will simply be a program, toggleable in a user's "system preferences" file that will look at the code for each line of imported, 3rd party executables, and see if any instructions attempt writing to the Hard Drive, or to the instruction RAM of the computer, which is not hard, it just looks at the OP code. If a program does, it is a sign that it is attempting to damage the data structure of the computer (it might be trying to copy itself a billion times and overwrite a user's data and programs, or other crap like that). If a program does pose a threat, all that will happen is the user will receive a warning, and an option to proceed anyways. I can make it more complex in the future If I feel the need though
A virus can do quite a bit if you value the data stored in your files. A virus could destroy the OS program and make the computer spout gibberish. The only fix for this would be to completely (manually) rewrite the OS to the hard drive, if the downloading program or any program leading to it is a gonner, that is.

Thank you so much for your words of encouragement. I fully intend to finish this project. Right now, I'm done with the hardware, and I'm just working on making all of the data structures, and the startup sequence. Once the computer is completely functional, with OS and all, on logisim, I will begin building in minecraft. I too hope I can stay sane...