TickNet V1.0:

Ticknet is a wireless communication protocol for CPUs in Minecraft. In this repository you can find all the schematics for all Network Interfaces/Nodes and their respective specifications.

If you have any suggestion, issue or improvements regarding this guide or anything in the available resources, please do let us know via discord. We are excited to have you working with us on developing this technology and expanding the capabilities of TickNet, so be sure to contact us if you are interested!

Head over here for a beginner's guide on Ticknet! (For a complete specification document head over to the wiki)

---

Repository

In schematics/release you can find all the up to date schematics of the different versions of the Ticknet node. The names have a meaning and represent the variations of the different features included in the node. Please refer to the official specification for a more detailed explanation.

The names of the schematics follow a pattern to be easily identified: TN_v<version>_<addressing>_<bits>_<extras>.schem

• <version> represents which version of the protocol it is using
• <addressing> tells what kind of addressing mode it is using. It can be:
  • <static>-> the default
  • <dynamic> -> using the dynamic addressing extension (explained here)
• <bits> represents how many bits the I/O ports are. Currently there is support for: 4b, 8b, 16b
• <extras> are for any other adapters to the interface. There can be multiple ones combined:
  • <stream> it makes the network interface work with streams instead of packets
  • <lports> it uses the version that has less ports for each common command.

---

Ticknet in 5 mins

With Ticknet hardware one can create a cooperative network of Ticknet Nodes and communicate between them by sending and receiving packets. Packets are the combination of data being sent and some header that contains additional information that is useful for nodes to carry out the delivery process.

Payload

Data being sent is called payload and is a sequence of bytes that does not exceed the limit of 24 bytes. The payload can be null, meaning that a packet is only composed by the header. This might be useful for when a signal needs to be sent (acknowledge or ping) but no extra information is needed.

Headers

Headers are automatically generated by the node (so you dont have to worry about them) and include (in this order):

• A magic number. This is is a single byte that is always included so nodes know that the packet format is of Ticknet. Competing protocols will use another magic number.
• The length of the packet. It might be relevant for memory allocation purposes on the receiver side and for compatibility between other competing standards.
• The sender of the packet. That information is a single byte containing the static TN address of the node. Nodes are identified with this.

The length and sender properties can be read out directly on dedicated ports without the user needing to know the structure of the packet.

Packet Properties

Packets sent have a few relevant properties: Consecutive packets sent between TN nodes arrive in the same order they were sent, no packets get duplicated in the process and only go missing in very specific and clearly defined scenarios:

• The destination node is offline (turned off)
• The sender/receiver node does not have enough memory to save the transmission

Transmission Order Queue

The packet properties can be achieved because there is a per channel order queue that tracks which nodes wish to transmit in which channel and provides a signal to the first one on the line (technically every 16th position in the queue, but we are asuming no more than 16 will ever be queueing at a single channel at the same time). This effectively eliminates collisions, duplicates and keeps transmissions in order, which allow for a very reliable and efficient network.

Node Interface

Nodes are controlled using a simple interface based on I/O ports. Each port is generally assigned to execute a type of command, or provide a certain type of information. Ports can be read or written to, these are different actions and will be interpreted differently by the interface.

Whenever a port finished executing a command, the busy bit will pulse. When executing blocking operations, the pulse will indicate when the operation can proceed and stop waiting. If the CPU wants to read without blocking, a simple SR latch that is set upon requests and reset upon busy bit pulses can be used alongside periodic checks.

User Command	I/O Port	I/O operation	Description
start	cmd	write/output 1	Starts listening to incoming packets and starts getting ready to send.
terminate	cmd	write/output 2	Stops listening to transmissions, and resets buffers.
nextPacket	cmd	write/output 4	Any value written to this will skip current received packet and get the next one (if it exists).
packetCount	cmd	read/input	Reads 1 if there are more packets left to read after current one, and 0 otherwise.
putByte	data	write/output	Adds the byte to the current outgoing transmission (capped at 24).
getByte	data	read/input	Gets the next byte from the received transmission (or 0 if none are left).
send	send	write/output	Sets the destination node, and enqueues the current outgoing packet for transmission (0 broadcasts).
getSender	send	read/input	Returns the sender of current received packet (0 if no packets left).
getSize	size	read/input	Returns how many bytes are left of the current received packet payload (0 if no packets left).

Note that if 4 ports are not available for a cpu to control, then a different version is available that only uses 2 of them at the cost of making commands take extra steps. For more information on adapters, what they can do and which are currently available check out the full specification

Usage example

Here is some URCL code that shows how to send a string "Hi" to the node with the address 42 using the network interface:

// Mapping commands to their command codes
@DEFINE SETUP 1
@DEFINE TERMINATE 2
@DEFINE NEXT_PACKET 4

@DEFINE destAddress 42

OUT %TN_cmd @SETUP     // interface is now online and listenning to incoming transmissions

OUT %TN_data 'H'       // sending 'H' to the transmission buffer
OUT %TN_data 'i'       // sending 'i' to the transmission buffer

OUT %TN_send destAddress

//After some time we turn it off
OUT %TN_cmd @TERMINATE

Sending to address 0 would mean broadcasting it to every active node. If we want to print the result on the receiving end we can do so like this:

@DEFINE SETUP 1
@DEFINE TERMINATE 2
@DEFINE NEXT_PACKET 4

OUT %TN_cmd @SETUP    // interface is now online and listenning to incoming transmissions

.busy_waiting
OUT %TN_cmd @NEXT_PACKET  // try to get the next packet
IN R1 %TN_cmd             // save result of operation in R1
BNZ .busy_waiting R1      // if error code != 0 try again

IN R1 %TN_size        // length in R1
IN R2 %TN_send      // sender in R2

.loop
	IN R2 %TN_data    // fetch the byte
	OUT %text R2      // print character
	DEC R1 R1         // decrement the length of remaining message
	//IN R1 %TN_size      
	// length can be fetched directly from interface everytime, but it might be slower, specially in a loop
BRP .loop R1          // if length > 0 go back

//After some time we turn it off
OUT %TN_cmd @TERMINATE

For more detailed and complete examples read the section on the specification

---

How to setup a TN node in minecraft

Now that you know what TickNet is, how it can be used to communicate between nodes, all that is left is to setup your own so you can start experimenting with it. You will need worldedit mod to be installed in order to import the schematic file and pasting it into the minecraft world.

WARNING: the current versions are not rotation invariant, so do NOT rotate the schematic with world edit before pasting as that will break it. It is also important to NEVER leave the interface on while its chunks are reloaded, like moving very far away, or quitting and joining the server. We are actively working on removing these limitations.

WARNING: The node needs direct sky light access in some locations so be sure to not cover it with any solid block (the time of day is irrelevant for the build and it will work regardless). Always paste the schematic in an empty area (delete any previously existing redstone). Similarly, instead of moving it with the move command, you must paste it again in the desired location.

The wireless technology is perfectly vanilla compatible, however some problems might arise in singleplayer, and as such it is recommended that a local server is used or this mod) applied. The safest bet is just a redstone server that has entities enabled as dropping shulkers and items are a requirement.

Here is the step by step process:

1. Browse the schematics/release folder for the available nodes (for a simple default pick TN_v1.0.2_static_8b.schem)
2. Download the selected .schem file.
3. Put the file into the schems folder of worldedit (if folder does not exist, create like shown)
   • In Bukkit/Spigot servers: .minecraft/config/worldedit/schematics
   • In Forge/Fabric/SinglePlayer: .minecraft/plugins/WorldEdit/schematics
   • Use your server's schematic manager if the files are not accessible directly or ask the staff for assistance.
4. Run the following minecraft commands on the console in order:
   1. //perf off
   2. //schem load <schem> where <schem> is the schematic file name.
   3. //paste -a
5. Input a unique static address (how you manage that is up to the server you play on in case of multiplayer). You can find it in the side of the build where it leads to a red concrete wire.

Test some of the above programs by inputting the ports directly and checking for the desired behaviour. If anything goes wrong and you are confident you followed the instructions carefully, you can ask for help directly in our discord server.

If you have any suggestion, issue or improvements regarding this guide or anything in the available resources, please do let us know via discord.

---