Trying to make this basic clock faster for a push effect

[StormWing0]

Yep just the basic clock is nice until you need it faster of course. Any ideas that could fit into the same or less space if able? Keep in mind you have space out the the remote and the armored area too.

 

[CyberTao]

The game by default only supports 0.5 second clocks, you'd need rotors and/or flip flops to speed it up anymore, which takes up a bit of space.

 

[StormWing0]

hmm any ideas for that? Still a bit new to getting logic things fully up and running.

 

[SkaireKrough]

hmm any ideas for that? Still a bit new to getting logic things fully up and running.

I don't know if you know this but for equal numbers of push modules you get better acceleration if you split them up between 2 push computers, one hooked to the 'not' and the other connected to the 'or'.

 

[StormWing0]

Testing that right now and not too sure it is having the effect I want but it does seem to be working.

 

[MrFURB]

There are ways that you can 'overclock' logic. The simplest that I've found (and what I'm using to test some emergent tech) uses a single rotor and an adjacent button linked to it that is hooked up to a chain of not and delay logic blocks. Use a rail speed controller and slave to it any number of activators so long as approximately 40% of them are active (You can mess with the number of activators to get different results). Link the button to the first not, the first not to the first delay, the first delay to the second not, and keep that chain going. Then put down a flip-flop and hook the entire chain up to it.

When the rotor is spinning, it should be sending the button an on signal for 0.5 seconds at the completion of every rotation and an off signal for just barely over 0.5 seconds between cycles. The difference between the on and off signal duration is what overclocks the logic, and the smaller that difference, the larger the not/delay chain can be before signals begin overlapping. Thus, more signals per second are sent to the flip flop and the clock is faster.

I tried combining overclocked logic with a push passive in order to simulate a couple hundred thousand thrusters with a single push module, but the push computer had an internal cooldown of 0.5 seconds, no matter how fast the logic clock is. Schine is a step ahead on this one.

 

[StormWing0]

lol looks faster than that though so it is a game of hook of many push computers to a fast clock and have multiple outputs triggering them.

 

[Crashmaster]

Take Olxinos' simple rotator clock from the smallest fastest clocks thread, have each activation block output through one of Olxinos' pulse shorteners from his instant pulses thread to prevent signal overlap, then finally merge the output from the pulse shorteners into an activation block.
Half decent and compact-ish for logic-firing cannon-cannon systems a bit less slowly. The activation block slaved to the rail speed controller will turn it on and off once it has run.

 

[BlackTangent]

I remember that there's a way to expand that circuit to make it even faster, but I couldn't give you the name of the guy who made the .smet file .

EDIT: Found it when browsing the forums

http://starmadedock.net/content/volksschiff-clock.2991/

 

[Crashmaster]

The two circuits are quite different actually. Your link uses a one-time activation of step-timed rotators to initialize multiple delay clocks on offset ticks that can synchronize over time due to lag but can produce high frequencies. The above circuit produced 8 pulses per 2 second revolution of a single rotator without the eventuality of needing a re-initialization due to synchronization.

While you could combine the two to have multiple rotator clocks started on off-set ticks by an array of step-timed rotators you still suffer from lag-induced synchronization (might use a few less entities though).

 

[amimai]

use flip flop clock multipliers:

basically its a simplification of what Olxinos did
you connect your clock output to a NOT gate
then connect clock output to 2 activation
then connect NOT to 2 activation
then connect all 4 activation to 1 flip flop

presto x2 clock rate (repeat until you reach a satisfactory MHz level)

total blocks:
initial clock : 4
multiplier : 5
multiplier 2 onward : 6
total for 8Hz : 15
total for 256 Hz : 45
total for KHz : 57
total for MHz : 117
total for GHz : 177
total for exceeding the clock rate of any CPU in existence : 201
:D speed daemon are you? :D

this is clocking 8Hz
the 8 flip flops on the side are just a 255 counter, its just there for visualizing how many increments have happened since my CPU doesn't keep up currently 01000110 or 70 in decimal (this was reached in less then 10 seconds)

*edit* not volksschiff, Olxinos

 

[StormWing0]

hmm might be interesting to test.

 

[Fellow Starmadian]

This is incredible! I did some testing and was able to use an AND gate and the old 4 block latch to activate any of the binary numbers that were in the range of the binary counter.
This means that it seems to work fine with advanced logic but only updates visually every half hertz, making it look like it isn't sped up at all.

The download shows this in operation, as the 1 and 3 decimal conversion latches seem to activate at the same time, but the logic I set up connected to these latches shows otherwise. It clearly shows that binary 1 was lit up before binary 3. Now we can make logic recursive without it taking a super long time! As long as we don't need to use delay blocks, that is. Another thing to test is to see how delay blocks react to being activated off of the standard 2Htz that we are used to.

 

[Fellow Starmadian]

darnit! It looks bad for the over clock circuit... I tried to use 3 of the flip flop overclockers, but only the binary digits after the first two seemed to work with other logic blocks. When I try to use the testing method I used with the single flip flop overclock, it did not work, as the first and second binary digits seem completely unresponsive

Hmm, I have yet to test to see if recursive logic for updating things like grids of lights is block effective, but I will keep this thread updated.

 

[Fellow Starmadian]

Ok, I think I have something, but it needs more testing. I'll post about it tomorrow hopefully, but let me tell you now it looks promising!

 

[GRHayes]

Yep just the basic clock is nice until you need it faster of course. Any ideas that could fit into the same or less space if able? Keep in mind you have space out the the remote and the armored area too.

It seems the fastest circuit will not exceed 0.5 seconds. Depending on how they wrote the code you could string a bunch of nots together to cause it to come up with a shorter time. Seeing they actually did a fairly good job with this I doubt it will work. It obviously doesn't fit your same space requirement also.

My primary guess is they did this because of wanting it to get properly updated with server each time. Can you image if everyone on a server was forcing it to update vastly more times than it already does.

 

[Fellow Starmadian]

I think the real problem on a server is this:

That gif is sped up about 10 times. While the circuit takes one second to update, it took about 5 with lag... The server was dying, lol. What I'm testing now is if recursive logic can be used to reduce the amount of logic blocks for this massive circuit.. It's just a theory, but I've gotten about 80 counts on the binary counter so far using only docked entities that send a pulse one right after the other. If I can get it up to at least 81 per second, I can use the logic from a single cell of this circuit to update all of the cells in a second or two, which due to the nature of the circuit, will greatly improve server performance (I think).

edit: grammar

 

[Fellow Starmadian]

Unfortunately I can't test this for a few hours, but when I get back to my home computer I'll set up some performance tests using advanced logic: one task accomplished using the recursive method and the other just standard .5 second pulse logic. Should be pretty easy to see how the server reacts with a 81 pixel CGOF circuit. Hmm, this might actually take a while lol... I have the logic for single cell calculations done, but I still need to figure out how to get it to calculate 81 different pixels, which all interact with each other. even if the recursive method adds a second or two to the logic calculations, I'm hoping that the 8 times optimization of the circuit in regards to block count will stop the lag.

 

[StormWing0]

I could just see the admins on the server cringing at this going on.

 

[Fellow Starmadian]

actually, I got a lot of attention on the old red shift server that went down maybe 6 months ago.. If I remember correctly, I got a warning from the admins after I showed it off to them, :D