This is a thread I decided to start up going through my present progress and work on 60 Hz TPT computing meaning that the devices planned in this project will be capable of running or performing operations every frame. The following goes through various demonstration saves that implement a technology perhaps adapted by some which I generalize under the term, A3SFTT, or Advanced Solid-Spark Sub-Frame Timing Technology, as well as describing the principles at the base of its functionality.

~

How it works: (The following is for those who really want to understand how it works and achieves this, else you can skip to the saves and see them in action.)

Past Limitations: Throughout the history of TPT as new electronics elements were added to the game, multiple users went out of their way to put these switching elements together to produce a computer. These designs were limited by a feature of Powder Toy where conductors can only be sparked every 8 frames. This is due to a propert called life which you can view by pressing 'D' to activate debug mode and hovering over the desired conductor particle on screen. Because of this feature, electronics or SPRK signals could only be transferred to other conductors or let's say parts of a computer in a certain number of frames. 

Past designs made use of SWCH, WIFI, ARAY, INST and other electronics elements and allowed for computers to run at rates from multiple seconds per instruction to an instruction every 16 frames (at 60 fps sim speed that's aout 3.75 instructions per second!?). Anyways, pleasantly as with the real world we can find that TPT has experienced its own sort of 'Moores law' in terms of speed as well as compactness. Today we reach another iteration in the trend push the world of Powder Computing to the limit.

What is A3SFTT?

A3SFTT is a TPT technology that takes advantage of deeper aspects of the TPT mechanics to circumvent the limitations put on normal SPRK based electronics. The first important feature is that of particle IDs and how TPT processes all of the elements on screen.

Particle IDs and execution order: Once you save and open a save, your TPT program will assign particle IDs in 'reading order' from left to right then top to bottom. On 'debug mode' on the HUD you should be able to see a # followed by a number representing the currently selected particle's ID. These increase from left to right then top to bottom. As a frame of TPT physics is processed, TPT iterates through all particles. If a particle is an 'active element' like CRAY or ARAY, it will check its adjacent squares for a conductor like METL to see if its life, which is decreased by one every frame, has changed to 3 in this current frame. If so, the conductor at its location with its assigned ID will appropriately perform its function. Likewise, conductors will only be sparked on the frame that a 'source particle' like BTRY, ARAY or CRAY (consult more advanced game mechanics and features) is activated or detects a conductor with life 0 that it can spark. 

Making ARAY spark every frame: We already know that putting FILT between ARAY and a destination conductor allows ARAY to send sparks over distances every 8 frames, but this could still be done faster. As we know, the element CONV will convert the type of all adjacent particles (except CONV apparently) to its current ctype. The question for speed was how to make a conductor spark more often, or rather how to 'reset' it every frame. This can be done with CONV. Place some METL in the vicinity of a CONV with a ctype of METL, spark the METL and advance a frame (by pressing 'F') and you'll see a new and fresh particle of METL with life 0 appear in place of the sparked one. Now place some BTRY in the vicinity such that the CONV(METL) is to the left of the conductor and BTRY is to the right, press play and what do you see? The magical thing called solid spark which has been at the head of some of the fast electronics or PSTN animations you've seen 'lately.'

Having conductors 'conduct' every frame: Now on its own this CONV, METL and BTRY contraption won't be able to spark ARAY every frame. In this set up our conductor doesn't have a chance... (just figured something out). Actually it will, hehe. Place some ARAY on top of the BTRY, reload the save, let it place then hold right click on the BRAY directly in front of the ARAY. Watch the 'magic' as 'intersected BRAYs' extend along the beam every frame? The base principles for making this 'effect' work are that in a single frame:

• Giving note of particle execution order, the desired 'active element' must be able to sense when an adjacent conductor has made the change from 'sparked life' 4 to life 3 and hence activate. 
• After the 'activation step,' there must be a way to reset the conductor. This can be done with CONV put in the right place given the right ctype or DRAY (if you know how to use DRAY) copying a 'fresh' element or life 4 conductor into the location of the desired element.
• Once that's done, there must be a way to 'respark' that element so in the next frame the conductor can activate, reset, and be sparked again, over and over.

The three steps of the 'activation cycle' at the base of nearly all A3SFTT components during each TPT simulation frame are activate, reset and respark. With this in combination with TPT's 'sub frame timing' we can put together a wide variety of complex contraptions that operate as fast as your current simulation speed.

Applications and conclusion:

~

Technological Demonstration Saves: Within the following days and weeks I will be posting a number of saves demonstrating the current features I've been able to implement into my designs using A3SFTT fabrication methodologies.

Demonstration 1: Base technology and high speed read/write access.

ID:1751002

This save features at the center a set up with buttons you can spark for storing and reading data from a demonstration FRAM, or FILT RAM. A RAM, or Random Access Memory, is a device that stores memory in the form of a collection of digital electronic states called bits. What modern computers as well as the computers on TPT need this for is the storage of data wheter it be the patterns of ones and zeroes constituting a computer program or numbers stored while performing a computation.

To operate this demonstration, first spark the red buttons on the input panel labelled 'DATA' then press ENTER. After that, set the ADDRESS, or a binary number defining which location in memory to access, to 'move' the 'reading/writing arm' to appropriate location then press ENTER for that input panel. Lastly you can spark WRITE under the output panel to store your data. Spark READ to read the current data stored at that location. Setting new addresses changes the location in memory you are accessing and setting the DATA input changes what data you want to store. Modern CPUs make these kinds of access from RAM millions of times a second.

Above that you can see two vertically arranged 'counters,' one incrementing the address being written to and read from, another setting the values to be stored into memory. This shows you how fast this technology can store and read data which in our case may be synonymous to how fast it can execute instructions. Fast RAM means fast computing, and fast computing means your enjoyment.

Demonstration 2: High speed GOTO/JUMP operations.

ID:1751171

This, alongside a more 'user friendly' set up for the manual data storage and access demonstration, is a demonstration of my current technology executing its first instruction! :D. CPUs or computer programs in general when running need to be able to 'make decisions' or branch. A goto operation tells a computer to jump between different locations in memory or start executing program from a different location in memory. This can be done 'conditionally' or 'unconditionally.'

In this demonstration (on the bottom of the scene) you can see a memory device with some extra circuitry attached to it running on some more advanced applications of A3SFTT. In each bit of a simple 'program' stored in memory are goto operations and NOP instructions (where the CPU does nothing and continues to the next instruction in memory). Hovering over the FILT particles in memory will show you the binary instruction stored inside. If you see a light blue line or 'on bit' in an instruction, that instruction is a goto which jumps to the binary address specified to the left of it. This design at present can conduct up to 20 gotos a second (at 60 fps) because each goto takes three frames to 'propagate' or be 'carried out.' On the other hand this computer would happily execute 60 'single frame' register access, addition/arithmetic, logic or NOP operations a second.

Once you press START, after a few frames you will see the reading head advance and the CPU take on different states. You will see that the reading arm will advance two 'invalid instructions' before it finally jumps to another instruction. The same goes with the goto it just landed on. Then you can have fun watching it at full speed. :D.

From the '7.5 Hz computing' some have worked towards, this technology makes a speed improvement by a factor of 8. Plus for the future, considering how compact these designs may come to be (you already saw the relatively compact high speed counters, plus a high speed adder design I'm working on; id:1743359), we might even be able to have multiple 'CPU cores' of these working and running on the same save boosting instruction execution to 120 instructions per second or more! 

That's that to hopefully hype folks up for what's to come after our most recent progresses in TPT computing.

*Update into SCHM A3SFTT Computing*: https://powdertoy.co.uk/Discussions/Thread/View.html?Thread=20354

@tjitte (View Post)

(I'm still a noob at embedding my saves, hehe) Well, the first and 'easiest' way to achieve that is by having a multicore system. Two small cores running different programs simultaneously and you'll have 120 instructions per second assuming I fix the goto operation. As per one core, due to the single frame operation of most instructions, either I support high speed operand retreival in a CISC architecture as to hopefully fetch operands, conduct an addition and store the results in the same frame, else with a complex decoder for an instruction set I'm working on, I might have it so that short instructions don't 'waste' bit space and are decoded in the same frame as another instruction stored in that single 24 bit throughput. At this point, having more than one instruction executed per frame is only possible at the level of core or instruction level parallelism.

Either way there will always be the 60 Hz or single frame per read limit to instruction throughput. The only way to make that faster is to have multiple parallel memory devices outputting to decoders at a time and either having more decoders or more complex ones to dispatch all those instructions to their corresponding functional units at once.

* Also, just a question. Does anyone know the exact order in which DTEC checks the BRAYs adjacent to it? As in if multiple BRAY ctypes were around it, how would you deterministically find out which BRAY's ctype the DTEC will transfer? 

@jacksonmj (View Post)

Yeah, did a little experimentation to see how things are iterated. Tell me their's some for loop in there in code doing some lovely coordinate iteration and getParticle(int x,  int y)s?

Yeah, non-ordered particle simulation or from what I know 'storing changes and then applying them' instead of doing such as you go would be more realistic whilst the prior iteration method in 'accurate' simulation wouldn't be viable. I still think that storing changes before appearance makes for two simulation iterations per frame and theoretically I'd think it would take longer(?), hence ordered particle sim was the 'easier and simpler plus faster' way/programming solution. But I wouldn't know having had not had any experience contributing to TPT source code or anything. Yeah, compatibility mode or a way of robustly setting 'sim processing mode' or modes of particle iteration would help. Perhaps, contrary to what I might think if writing a program, making a button for 'switching modes' isn't as simple as one would think.

Yeah, people have all kinds of uses for different versions of processing in the game. At present 'A3SFTT' is the one 'vanilla' thing we've found. But personally having a way to switch between 'A3SFTT supporting' sim modes and 'realistic iteration' would be the only way to ever see a multi-core TPT CPU calculating and rasterizing a 3D rotatable scene onto a 120 by 100 pixel DRIC/COAL display. And the only way we could ever say yes to folks demanding that they play minecraft on the machine.