2019-12-26.html

Last modified: .

Back

Since this is the first blog post, there isn't much technical stuff I can put down here. At this point, I have some nitty gritty stuff planned out, but most of the planning I have done is high level. Over the next few blogs, I'll probably work out some part lists, because then I can start ordering and assembling. However, I do need to work out some kinks in planning.

First, I'll lay out the goals I have in mind. The architecture is the computer is described as: a 4x4 grid of nodes. Each node can send a number to any of the adjacent nodes, and each node is programmable. Nodes can be hotplugged, but empty node slots can obviously not be communicated with. Each node can only process data; i.e. there is no long-term storage available per node, only registers. Additionally, each node's RAM does not store integers in a given address. Instead, each address contains an opcode, which may or may not contain an integer.

An example program loaded into a node's RAM could be

    
      MOV UP, ACC
      ADD 24
      MOV ACC, RIGHT
    

MOV UP, ACC and MOV ACC, RIGHT are different opcodes, btw. Also, there would be no opcodes that allow for writing to RAM. The RAM that is available to each node would be used exclusively for storing the program.

As for opcode specifics, here's a list that I invisioned:


      MOV <INTEGER>, ACC // Copies an integer into the accumulator 
      MOV <PORT>, ACC // Copies the input register to the accumulator 
      MOV ACC, <PORT> // Copies the accumulator into the output register
      MOV <PORT>, <PORT> // Copies the input register to the output register
      SAV // Copies the contents of the accumulator to the NAR (Non-Addressable Register)
      SWP // Switches the contents of the accumulator and the NAR
      NEG // Multiplies the ACC's contents by -1 (flips the sign)
      JMP <LABEL> // Unconditionally jumps to code marked with <LABEL>
      JEZ <LABEL> // Jumps to <LABEL> if ACC contents are equal to zero
      JNZ <LABEL> // Jumps to <LABEL> if ACC is not zero
      JGZ <LABEL> // Jumps to <LABEL> if ACC is greater than zero
      JLZ <LABEL> // Jumps to <LABEL> if ACC is less than zero
      JRO <INTEGER> // Jumps to line of code <INTEGER> away from the current line, essentially adds <INTEGER> to the program counter
      ADD <INTEGER> // Adds <INTEGER> to ACC
      ADD <PORT> // Adds the contents of the input register to the ACC
      SUB <INTEGER> // Subtracts <INTEGER> from ACC
      SUB <PORT> // Subtracts the contents of the input register from the ACC
    

For brevity's sake, I left out all the combinations of ports (last time I checked, I counted 56 separate opcodes). The ports I imagined were UP, RIGHT, DOWN, LEFT, LAST, and ANY. While the directional ports are self-explanatory (i.e. they recieve and send data to the nodes at that position), LAST and ANY are a little less clear. These are ripped straight from TIS-100 (the Zachtronics game I mentioned on the home page of this website).

ANY is a "pseudo-port" that halts the machine and waits for the first port that receives data (it should be noted that all of the commands that involve ports halt the computer until the specific input/output register receives the ready signal, it's just that ANY looks for any ready signal). LAST is another "pseudo-port" - this one refers to the last port that was accessed by the node (every time that the node communicates over a port the node records that node, probably in a register, and that is the port that last accesses).

That's pretty much it for the ports, but as for other features of the machine, I have a couple stretch goals.

For user interface, I want a VGA display that can display the RAM contents of each nodes and the line of code that is being currently executed per node. If that ultimately fails, I could settle for 16 separate screens that each display the RAM contents of each nodes. A second strech goal is a PS/2 keyboard interface that allows you to edit the RAM contents (which are displayed on the VGA screen) and then upload the changes to each node. A final strech goal is a some sort of mass-storage device where you can store your programs and load them back again.

I don't think I've covered everything about my ideas for the NBCS, but I've used up all my energy typing this tiny blog post out. I'll try to update with more details in the coming days, as I have waaaay too much time over winter break. Merry belated Christmas.

--- END ---