*This is going to be a long one.

Sigh, I got a little too impatient to see if my request exactly exists in the past posts since certain limits to DRAY and CRAY have been frustrating my progress on a high speed computer design, most noteably the graphics. The following are suggestions for relatively simple improvements to CRAY and DRAY for purposes in computing under the hope that these haven't been considered or debunked before.

Pretty much in the past few weeks I've been stocking up on knowledge concerning the FILT/BRAY ctype logic operation mechanics, DTEC, CRAY and DRAY mechanics as well as the sub frame order of execution of particles. Having had played TPT since grade 7 2011 and gradually accumulated knowledge on computer engineering and microprocessor design since the summer of that year, I've been itching to be able to apply what I've learned both into TPT and the real world with digital logic chips whereby FILT technology opened up the ability for me to finally start making decent and compact CPU designs in TPT.

The technology I've been developing, one consisting of powder toy mechanics that other users may have already explored, is called Advanced Solid Spark Sub-Frame Timing Technology, or A3SFTT ('Aesfet' sounds like MOSFET, the high speed, low power transistor technology succeeding the old BJT tech for TTL, hence I felt it to be an apt name for the advancements to Powder Computing I am trying to introduce.) My proposals for A3SFTT are that of being able to bump up the present 0.7 Hz (instructions per second) TPT CPU clock frequency limit up to 30 or even 60 Hz since A3SFTT with the use of Solid Spark and Sub-Frame Timing will be able to send data through a TPT computer as well as perform operations up to ever 1 or 2 frames. As every FILT particle is capable of storing up to 30 bits, or space for 3 8-bit bytes, and supports logic operations on up to 29 bits at a time, designs can be made much more compact giving the TPT community access to multi-core parallel processing CPU technology.

Now onto the CRAY and DRAY requests. Now, if you ever want to see 2 to 4 FPS 120 by 100 pixel graphics games or basic arrow key operated Operating System GUIs on TPT without having to download a mod of my creation, then these slight additions are the solution. Plus with this, you can happily feel that the TPT computer you are using is as small as can be and was technically made with the vanilla content.

CRAY:

- I'm happy that CRAY when sparked by PSCN can have a boundary defined by a DMND particle in its way. I am also happy that CRAY sparked by INST allows spark to go through elements and fill up spaces with a certain number of particles. tmp2 is used for LIFE supposedly. But for conductors could we spare to allow it to use tmp2 or some other variable to define where CRAY starts producing particles? I'd guess this feature should only work for INST and INWR as the conductors. For example, a value of 5 for this feature will put 5 spaces of enmity between the CRAY and the first particle it emits. This can save the use of elements like INSL to offset where CRAY starts producing particles, and as per my A3SFTT computer designs where these will be under mass use, this will help reduce particle count and give a better chance of running the simulation at 60 fps. On my terms this may also have multiple more complex and useful applications in CRAY circuitry design.

- Another displeasure is that CRAY when sparked by INST and INWR has been left to go through absolutely everything no matter what. Let’s say I had a bunch of vertical CRAY to drop DRIC in a line to build a screen frame. After that let’s say I wanted to fill the spaces with COAL to provide a buffer for producing the next row? One way is to have even more CRAY with inverted inputs that output the COAL on the same frame as the DRIC. The other way is to have INST + CRAY to the side to do the filling. The problem is that this has no bounds and if the row had 60 DRIC pixels already in it, I’d have to clear up the extra 60 COAL using PSCN CRAY circuitry that would double the space the screen circuitry occupies.

- My solution would be to find a free variable, probably in flags depending on what it is presently used for where we could set if we want to activate this ‘INST CRAY boundary’ feature. For now I’d keep the ‘boundary’ as DMND. Using flags is just to avoid breaking saves by ensuring that this can only be activated manually. An alternative is to have an ‘enablespecial,’  ‘enspec’ or ‘spec’ variable for all particles as a standard for enabling and disabling any new added ‘special features/behaviours.’ So yeah, this would help greatly to avoid breaking saves while using the vanilla game mechanics, but perhaps in some cases it would be better just to write a mod.

- The DMND INST + CRAY beam boundary option and the use of tmp2 or another variable to set and initial offset would also help in making more directed clearing of particles in specific locations. Otherwise it would be easier to have an option to have tmp or tmp2 instead mean the number of spaces to add particles to instead of the max number of spaces to fill or particles to replace.  

- So in this case the improvement would be mostly for space saving and lag reduction.

DRAY:

- I’d guess that a perhaps recent scene construction issue is with layered solid spark PSCN-DRAY contraptions (mecha-man’s design) for the quick replacement of conductors. This is what allows me to send signals, spawn particles, relay ARAY/DTEC/FILT data across a circuit or perform calculations every frame. With DRAY I’d find it nice to be able to set how many spaces before it starts copying. So setting this property to let’s say two means that the first particle it starts copying before applying tmp or tmp2 is the third particle away from the DRAY. This would allow me to copy a specific part of a line of let’s say data storing FILT particles without copying all of the particles before it. Unless this is just ultimately a helpless act of ‘cheating’ to circumvent present TPT limits, it would be a great help. Other than that, DRAY is great.

CRAY, DRAY, or even ARAY too, ‘ignore property’:

- One idea is to allow all the ‘beam emitting’ electronic elements to make use of a property or variable in tangent with its ctype to define any additional elements to ‘ignore’ or be able to pass through. One reason that the desire for this feature came up for me was with AS3FTT and how to efficiently replace every INST in a row of alternating INST and INSL. Would you rather use a bunch of particles each individually doing copying for this, or would you rather use just two particles, an INST and a CRAY that runs on these proposed features. With this ‘ignore’ property incorporated, we could replace a whole bunch of ‘lag contributing’ particles with the CRAY and the DMND or property based bounds.

Ideas for FILT (killjoy logic operations set by tmp just for taking Powder Computing ‘to the next level’) will be discussed in a separate thread.

Conductor Conduction Direction Set:

- To make circuits more compact, it would be helpful to have a way or exploit a variable to input a number in to define which of its corners it can conduct from. This could be done with an 8 bit number, each bit defining one of the 8 adjacent locations to the particle, hence the direction. With this we can now have lines of INST with CRAY, ARAY or other electronics that each have individual in line activation separate from their adjacent neighbours. Right now it’s all just for convenience and once again trying to lower the particle usage of my final computer designs as well as other who may come to integrate some form of A3SFTT into their own high tech designs. It’s the TPT version of the introducing of MOSFET CMOS logic family technology to replace the old TTL that has been there for 5 years. TPT is sort of like a family, and we all move together with it. “Just like the real world, some absolute defines some rules for particles and how they behave, then we discover them and find new ways to put them together to our collective benefit, enjoyment and happiness.”

Why support these improvements?

- Speed up the ‘deployment’ of A3SFTT computing systems and bring the application of these advancements closer to us on the calendar.

- Jump from single core, hard to understand binary/digit display or limited graphics displace computers that run at less than 1 Hz and take minutes to complete their program to fully fledged TPT Personal Computers (AS3FTT Powder PCs) with up 49 KB FILT memory hard drives for storage of multiple programs, integration of multiple simultaneously running high speed 30 to 60 Hz small CPU cores with 192 byte instruction caches and L1 cache, high speed, high capacity, high access frequency and bandwidth FILT RAM devices and FILT/DTEC/BRAY bus sytems AKA your new TPT motherboard, high speed, multi core GPUs (yes with what I see, graphics processors with a bunch of 8 bit adders and multipliers for handling multiple shapes and character glyphs are possible and can be made even smaller than your iPhone on fullscreen) and high speed 4 fps (as I’d most hope depending on how compact and ‘lag free’ we can get the designs) 120 by 100 pixel resolution display, all this just to support a basic 4 fps Operating System with a GUI that can allow you to meaningfully interact with your computer, selecting menus for info, settings, programs to run, program creation, memory access and more.

- “Who wouldn’t want to go home and open up their computer just to open up their Powder Toy just to open up their save just to open up their computer just to boot up their operating system just to open up powder toy _again_.”

- If magical  things happen and I can get the computer to be that fast and make great use of its 49 KB of FILT memory as well as make high speed designs for IEEE-754 single precision floating point units (for division and rational/real number calculations), there shall be no more trolls to condemn this computer for not at least being able to run 2D Minecraft or simulate at least one 3D block!

- So I don’t have to spend the next few weeks amidst high school and exam studying programming a mod… (Sigh, how selfish of me; if you can program it, “why not do it yourself?”)

So that’s that. Hope you guys like the idea and would like to see a boom come to the world of Powder Toy computing.

Thank you.

1/8/14 12:23 AM ET NA

That's one spacing solution. But yeah, the first was a problem and that's why I had issues. PSCN + CRAY I'm fine with; still would be pleased to have an initial offset for where it starts beaming. Also learned that supposedly INWR + CRAY should allow me to set the bounds of the beam. I guess the usage of FILT for alternated clearing and perhaps programming and the DMND bound should do. Some of these I still feel would help with convenience of design as in some might wish they were there and the conductor conduction direction select would help to better push towards more compact, hence less laggy, designs. Once again, pushing for new features only brings us closer to a TPT elements equivalent of programming which is both good and bad depending on your desires. It removes past challenges some people still want to take or overcome but also creates new ones that push towards a new limit.