Archive: 17 posts

---

Has anyone figured out any tricks to tune how LBP decides to handle signal propagation within a single cycle? In my case, I have an analog logic chip where I want to run the logic at full speed (30hz). Theoretically it should be able to handle it, as long as the simulation propagates the signal properly. However, the fastest I can run it at stably is 1/3rd clock (10hz). If I run it any faster, it encounters corruption from signals not settling into their stable state yet. This is the circuit in question... (Sorry about my sackdude blocking the picture, but he only blocks wiring which can be still followed behind him, and I didn't feel like re-taking it.) http://i8.lbp.me/img/ft/978c2d0add565a96e44f9c0870843c61e8d6c90a.jpg The incoming signals come from four other identical copies of this chip. Within the chip, propagation seems to work as I want, but the signals from other chips don't come in a timely manner. The top battery is configured 100%, and of the pair the upper one is configured for 50% and the lower 5%. The sequencer is set to positional. The device below the sequencer is a count 1 counter acting as a SR latch. When I step this circuit while watching the sequencer position, I see it bounce around a little before settling on the desired value. (For the curious, this is a fully working unit cell for Conway's game of life. The upper pair of inputs is hooked up to the lower output of the top/bottom neighbor, and the lower pair of inputs is hooked up to the upper output of the left/right neighbor. The upper inputs are summed with this cells value, producing a value of 0-15% on the upper output for the neighboring cells to use in their calculations, then the whole thing is run through a sequencer to apply the cellular automata rules. The signal arriving late seems to be both the non summed and summed inputs, but only from one neighbor. Of course, since the signal has to go through two chips in some cases, that accounts for why two extra cycles are required to settle to a stable state.)

2011-02-15 20:04:00 Author: Tygers Posts: 114

---

The only things I see that would incur latency is the sequencer and possibly the blank chip (since it's being activated and I don't know what's in it). A sequencer has a latency of 1 clock cycle. So does microchip activation (depending on the design). If this blank chip is a relay, I have a trick that will eliminate it's latency.

2011-02-15 20:29:00 Author: Shanghaidilly Posts: 153

---

the blank chip looks to be a counter so should be fine. The sequencer will add latency and possibly the circuitry behind your sackboy will (do you have any loops in there?)

2011-02-15 20:39:00 Author: rtm223 Posts: 6497

---

i have absolutely no idea whats goin on here and what any of this means or even what it would be used for!

2011-02-15 20:46:00 Author: Unknown User

---

Yes, the "blank chip" is a counter, set to max 1. The latency introduced by the sequencer is actually desirable because it introduces a known single cycle latency into the loop. Yes, there is a loop... It goes sequencer -> enable logic -> SR latch (counter) -> analog addition -> sequencer Input into the analog addition comes from external to the chip, in other identical chips analog addition stages. This causes no additional loops, but it does cause the signal to go through two chips. I had some insight while driving; I think I have found a fundamental truth about the LBP simulator. I was treating a chip as purely a device to organize circuitry, but it's possible that LBP uses a chip to order the simulation within a single clock cycle. In other words, the signals on it are fully propagated within it as a unit before any signals on other chips not internal to it are considered. This should be a simple hypothesis to test. However, it also means for my circuit to work as intended at full clock rate, I can not use a chip to organize it. If someone wants to test it, my idea is this... Two chips, one with a NOT and OR gate, the other with a circuit node. Chip 1 Chip 2 +--------+ +-----------+ | | | | | /----<----<- | | | | | | | | | | | | | | | | | | | | | | | +--o<|-- | | O | | | | | | | | | +-------/ | | | | | | __ | | | | | -- | | | | | | > | | ---->---->----/__/ | | | | | +--------+ +-----------+ In an "ideal" simulation, both inputs from the OR gate would flash in sync, producing strobing output from the OR gate. But if my theory is correct, going between the chips will introduce a one clock cycle latency, and the inputs to the OR will flash out of sync, producing a solid output from the OR gate.

2011-02-15 21:27:00 Author: Tygers Posts: 114

---

(For the curious, this is a fully working unit cell for Conway's game of life.) Cheers to a fellow Conway builder. I'll definitely check out your level when it's published. Do you have a feel yet for what kind of grid size you'll be able to accomplish? I know from experience that wiring up the full grid once you've got the cells built can be a bit tiresome (even when wiring things, copy/pasting and then wiring up the two larger blocks) - so I imagine it's possible you don't yet know the answer to that... In LBP1 I managed a grid big enough to run a "Lightweight Space Ship" - 8x7 toroidal IIRC. Of course such a small grid is laughable in LBP2! And it seems to not work right - maybe it needs some timing tweaks or something - not sure it's worth the trouble, though, I'm focusing on LBP2 right now... I'm working on a tag sensor-based version in LBP2 (no wiring! whoo!) but I have been wondering if it might be worth switching to a wired implementation to get a bigger grid... I've managed 38x12 or so - (barely) big enough for a glider gun. But it sounds like you really know your stuff, so I'm betting yours will do better than that!

2011-02-15 21:52:00 Author: tetsujin Posts: 187

---

i have absolutely no idea whats goin on here and what any of this means or even what it would be used for! I'm totally with you dude. I like to think i know a thing or two. At a certain threshold though, my brain just ends up farting binary at me. Seems like some people can take that fart and turn it into a fuel cell for an internal combustion engine... use it to casually fly to alpha centuri on some side project ship their building.... meet otherworldly beings and have perfectly amicable conversations with them. .... i'm off to eat humble pie with a side order of admiration. [edit: on a side note, he is building 'cells' for a re-make of Conway's Game of Life (http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life)> you start a repeating process, each 'cell' has a set number of states, each state is triggered via the state dependency of neighbouring cells. In this system, the majorety of actual processing is carried out automatically by inbuilt paramiters, hence the need for 'automata', ...then the whole thing is run through a sequencer to apply the cellular automata rules... which i believe is entering the realms of emulating turing complete (http://en.wikipedia.org/wiki/Turing_complete) systems. which hurt my brain.

2011-02-15 22:01:00 Author: Epicurean Dreamer Posts: 224

---

The microchip should update it's outputs atomically. but that should then continue to propagate within the same cycle. Loopbacks should add a frame of latency. The bottom inputs on sequncers / microchips / select switches shouldn't (probably), but they do. You can force a frame of analogue latency by using a divider circuit (as per my blog (http://www.lbpcentral.com/forums/entry.php?2409-Analogue-Logic-5-Division-amp-Multiplication)). That's only really useful if you need to delay a signal to correct a race condition and it's not exactly a pleasant solution.

2011-02-15 22:05:00 Author: rtm223 Posts: 6497

---

The microchip should update it's outputs atomically. but that should then continue to propagate within the same cycle. I'm not sure quite what you mean by this... What I am postulating is that given two chips, where there is a connection loop between them, but NOT a logic loop, it still introduces latency. See that ASCII diagram I made; it includes a connection loop between two chips, but the only logic loop is on the pulsing NOT gate to provide a 15hz signal. I will test it tonight if nobody gets to it first, but I theorize that the two signals will arrive at the OR gate out of phase. Do you disagree? (BTW, great blog posts, it saved me a lot of time figuring out analog logic on my own... Also I commented on one of your posts that the analog signal is indeed a single precision floating point, and how I confirmed it.) Cheers to a fellow Conway builder. I'll definitely check out your level when it's published. Do you have a feel yet for what kind of grid size you'll be able to accomplish? I know from experience that wiring up the full grid once you've got the cells built can be a bit tiresome (even when wiring things, copy/pasting and then wiring up the two larger blocks) - so I imagine it's possible you don't yet know the answer to that... In LBP1 I managed a grid big enough to run a "Lightweight Space Ship" - 8x7 toroidal IIRC. Of course such a small grid is laughable in LBP2! And it seems to not work right - maybe it needs some timing tweaks or something - not sure it's worth the trouble, though, I'm focusing on LBP2 right now... I'm working on a tag sensor-based version in LBP2 (no wiring! whoo!) but I have been wondering if it might be worth switching to a wired implementation to get a bigger grid... I've managed 38x12 or so - (barely) big enough for a glider gun. But it sounds like you really know your stuff, so I'm betting yours will do better than that! So far my first revision was 12x12 at 50% thermo, but this simplifies things quite a bit. Someone else's precise grid positioner allowed me to go wireless on the set/reset, and switching from analog to digital logic simplified the circuit a bit as well. Precomputing the addition of 3 neighbors and re-using that 3 times also saved the wiring between cells. I'm thinking of going wireless for the enable signal as well, but I'm not sure if that will have a positive or negative effect on the thermo. As far as wiring it all up, I have a shortcut... I lay out a 2x2 all wired up in an orderly way... Then I just copy and paste it repeatedly overlapping by one row. Afterwards I just detach and re-place in the same spot the chips that are now stacked because of overlap, and it merges the wiring. I should be able to do enough for a glider gun with this chip, but in chip form it is going to run at 10hz. I am going to try running the logic gates bare on the level, to get around the propogation delay from chips. If that works, I should be able to run at a full 30hz.

2011-02-15 22:21:00 Author: Tygers Posts: 114

---

Yes, there is a loop... Any feedback in the circuit may introduce latency (but not necessarily) depending on how the game engine determines the component update order. I still haven't determined exactly how it's done, but I wrote a post (https://lbpcentral.lbp-hub.com/index.php?t=48419&p=769583&viewfull=1#post769583) which vaguely explains how it works, although it's still highly speculative. In addition to feedback, so far, I've determined the following things introduce latency... A Selector's "Cycle" input. A Microchip's "Activate" input. A Sequencer's "Start/Stop" input (although possibly only in Positional mode). ...although I haven't tested everything, and of those, I've found workarounds to eliminate all but the Sequencer.

2011-02-15 22:29:00 Author: Aya042 Posts: 2870

---

As far as wiring it all up, I have a shortcut... I lay out a 2x2 all wired up in an orderly way... Then I just copy and paste it repeatedly overlapping by one row. Afterwards I just detach and re-place in the same spot the chips that are now stacked because of overlap, and it merges the wiring. Yeah, that's what I did for my LBP1 implementation. Make a cell, copy it to make a 2x2 and wire 'em together... Copy that and make a 2x4, etc. It really does save effort - though it did screw with the thermo a bit. IIRC, when I made my LBP1 implementation I actually had to avoid using that approach for thermo reasons. Copy/pasting a group of cells, modifying, and repeating actually ate up more thermo than simply creating all the cells and wiring them up myself. And then sometimes I'd capture a group of cells, and reinstantiate them, and the new instance wouldn't work. LBP1 logic sure was fun. XD With my wireless LBP2 implementation, I have all these wild visions of actually emitting new cells as they're needed - but to make that actually work I think I'd have to scan over the grid on each iteration, which would slow things down, I'm sure. It's a pity you can't create self-emitting emitters in LBP. It is pretty cool that you're expecting 30Hz out of this thing. I can't do better than 5Hz at present - I have the main clock driving the thing and then each cell internally generates a second pulse 0.1s later - first pulse latches the previous value and the second pulse latches the new value. I'm sure I could tighten up the logic there but I'm afraid of eating up more thermo... And, honestly, feeling ready to work on other things.

2011-02-15 22:56:00 Author: tetsujin Posts: 187

---

Any feedback in the circuit may introduce latency (but not necessarily) depending on how the game engine determines the component update order. I still haven't determined exactly how it's done, but I wrote a post (https://lbpcentral.lbp-hub.com/index.php?t=48419&p=769583&viewfull=1#post769583) which vaguely explains how it works, although it's still highly speculative. In addition to feedback, so far, I've determined the following things introduce latency... A Selector's "Cycle" input. A Microchip's "Activate" input. A Sequencer's "Start/Stop" input (although possibly only in Positional mode). ...although I haven't tested everything, and of those, I've found workarounds to eliminate all but the Sequencer. Thank you, your post there was very information, specifically the pretty plainly and simply worded statement that "because each component is only evaluated once per frame, and the microchip's already had its turn for this frame" - that confirms my suspicioun. The main latency I'm seeing here is because the chips each only get one turn to evaluate. I don't think the circuitry within the chip has more than one frame latency, and the circuit is designed around that latency. As long as the latency means that it is evaluating the sequencer last, it should work as intended otherwise. Yeah, that's what I did for my LBP1 implementation. Make a cell, copy it to make a 2x2 and wire 'em together... Copy that and make a 2x4, etc. It really does save effort - though it did screw with the thermo a bit. IIRC, when I made my LBP1 implementation I actually had to avoid using that approach for thermo reasons. Copy/pasting a group of cells, modifying, and repeating actually ate up more thermo than simply creating all the cells and wiring them up myself. And then sometimes I'd capture a group of cells, and reinstantiate them, and the new instance wouldn't work. LBP1 logic sure was fun. XD With my wireless LBP2 implementation, I have all these wild visions of actually emitting new cells as they're needed - but to make that actually work I think I'd have to scan over the grid on each iteration, which would slow things down, I'm sure. It's a pity you can't create self-emitting emitters in LBP. It is pretty cool that you're expecting 30Hz out of this thing. I can't do better than 5Hz at present - I have the main clock driving the thing and then each cell internally generates a second pulse 0.1s later - first pulse latches the previous value and the second pulse latches the new value. I'm sure I could tighten up the logic there but I'm afraid of eating up more thermo... And, honestly, feeling ready to work on other things. I don't think emitter would save you anything. Assuming LBP2 is like LBP1, items in the emitter still count against the thermo. While you would theoretically not need as many cells as there are grid places (I wonder how many cells could get naturally filled given a grid of MxN size...) it would probably complicate the logic. Though an emitter might help PLACING the grid to begin with. My worry is how to deal with keeping all the signals distinct. I think for now I'll stick with hard wired to neighbors. You're right, it does have a cost on the thermo if you copy big chunks, but as long as I keep the base unit around, I can still add in chunks up to a point, then when the thermo cost gets too high, start adding in smaller bits. With my method right now, each cell added takes a second to wire in, thanks to auto-wiring of overlapping chips. The thermo overhead seems to go away once I'm done dealing with the overlapping cells. To get 30hz, I'm actually relying on the inherent delay of the sequencer to produce the clock, and the incoming signal is instead an enable signal rather than a pulsed clock. But because of the way chips are evaluated, that approach will never work on the chip level, and the way this circuit is designed, it needs 3 cycles to fully propagate the signals, hence the 10hz. My previous design with 8 incoming connections instead of 4 allowed me to get 15hz since the propagation delay of the chips exactly matched the clock. I could probably simplify that circuit some, and may try it as a head to head vs this one. I think the only way to get a full 30hz is going to be to go analog, and not use microchips. Wiring up a non-microchipped system will be a pain.

2011-02-15 23:12:00 Author: Tygers Posts: 114

---

I don't think emitter would save you anything. Assuming LBP2 is like LBP1, items in the emitter still count against the thermo. While you would theoretically not need as many cells as there are grid places (I wonder how many cells could get naturally filled given a grid of MxN size...) it would probably complicate the logic. Yeah, probably not. Still, if I managed to trim enough fat to allow twice as many cells to exist as I can manage now - then I could start up that glider gun on the base grid and all the gliders would march away on dynamically-allocated grid cells, until the emitters stopped working from overheat. It'd make me feel a little better about not having a toroidal array this time around. Plus players would be able to place stuff wherever they like, and it would just do whatever until no more cells could be emitted. But I can't even think about emitting new cells at present. So far it's all I can do just to get that 38x12 to run. Having extra bits of holo chasing around, looking for places new cells are going to be needed? No... A system like that would just leave less thermo left for the cells themselves. Hey, I meant to ask. Your cell just connects to 4 neighbors, right? How does that work?

2011-02-15 23:40:00 Author: tetsujin Posts: 187

---

Yeah, probably not. Still, if I managed to trim enough fat to allow twice as many cells to exist as I can manage now - then I could start up that glider gun on the base grid and all the gliders would march away on dynamically-allocated grid cells, until the emitters stopped working from overheat. It'd make me feel a little better about not having a toroidal array this time around. Plus players would be able to place stuff wherever they like, and it would just do whatever until no more cells could be emitted. But I can't even think about emitting new cells at present. So far it's all I can do just to get that 38x12 to run. Having extra bits of holo chasing around, looking for places new cells are going to be needed? No... A system like that would just leave less thermo left for the cells themselves. Hey, I meant to ask. Your cell just connects to 4 neighbors, right? How does that work? It's all there in that picture. But in a nutshell... Given a grid of cells... A B C D E F G H I Cells B E and H all need to take into consideration cells D E and F. So cell E adds up D E and F, and passes the signal onto B and H. Cell B does the same with A B C and passes it on to E, as does cell H with G H I. So the 4 inputs into E are: 1) D 2) F 3) A+B+C 4) G+H+I. This does 2 things. First, it removes duplicate logic; rather than adding the cells up 3 times, it just does it once. Second, it cuts the number of inputs into a cell in half. As a downside though, since this is all in chips, the signals arrive in arbitrary order depending on what order LBP decides to evaluate the cells in. Here is what happens in the 3 cycles it takes to run the simulation, assuming a simple signal light (3 cells in a row) centered around E... The first number is the sum output of it's left and right neighbors, the second number is it's self output. Cycle 1: (Enable high) A) 10 B) 11 C) 10 D) 10 E) 11 F) 10 G) 10 H) 11 I) 10 Cycle 2: (Enable low) A) 10 B) 00 C) 00 D) 21 E) 21 F) 21 G) 10 H) 00 I) 00 Cycle 3: (Enable low) A) 00 B) 00 C) 00 D) 21 E) 31 F) 21 G) 00 H) 00 I) 00 As you can see, if it tried running faster than that, it would be getting incorrect information from the neighboring cells, and because of the shared addition, it can take an extra cycle to propagate.

2011-02-15 23:59:00 Author: Tygers Posts: 114

---

So back on the original topic... It seems that microchips don't run as a unit after all. My proposed simple test proved otherwise; and copying my life circuit off the microchip didn't change the behavior of requiring two clock cycles to settle. Directly connecting everything, to get rid of the adding step, didn't make a difference either. Something else is introducing latency. Unfortunately it didn't matter in the end, as LBP kept crashing whenever I tried wiring them together. So in the end I gave up and converted it to 100% wireless, aside from the display, and promptly laid out a 36x16 grid in about a minute. That left about a bar on the thermo. I might try for a hybrid wired/wireless solution sometime... Something like 8x8 blocks wired together, then connected wirelessly to the neighboring blocks. Maybe using less magnetic keys/switches like that will be nicer on the thermo.

2011-02-16 04:05:00 Author: Tygers Posts: 114

---

Not exactly related to what you're talking about, but I did a Life game in the LBP2 beta. The way I handled the logic was with tag sensors instead of wires, since you can set a minimum number of tags, so I had them set to sense 2, 3 and 4 tags. The other way I had been considering doing it before I knew tag sensors could be set to a minimum number was with a sorting network, which would have needed a total of 34 AND/OR/NOR gates per cell (not counting connection/clock logic). Both of those were before I knew about how analog signals were handled though, and if you can sort out the issues you're running into with syncing things it shows a lot of promise.

2011-02-16 09:23:00 Author: Balorn Posts: 92

---

That's so... simple... Insanely simple, in fact. But I have a feeling it's also slow. I tried a fully wireless approach, and while the thermo was filled up, it ran slow. My timer should have been running at 10hz, but I was seeing more like 1 or 2 on the simulation. When I tried a fully wired digital implementation, I was able to get it in around 20 gates per cell. It only half filled the thermo, but it was fast. Someone even commented on the level comments about how fast it ran. So I'm tempted to blame the magnetic keys. And it makes sense... I'm sure they have some optimization, but the worst case is they need to compare every single magnetic key to every single magnetic switch in the level. The more of them you add, the harder that becomes. At the grid size I was running, that is 331776 comparisons, and it's not just a trivial check, it has to do complex math too. That's why I'm trying the hybrid wired/wireless solution now. It gets around the crash I was running into making a fully wired solution, provides easy to assemble blocks, but doesn't have as many magnetic keys to check. I haven't finished building it yet (I accidentally messed up the wired/wireless border and need to re-do it) but it will be interesting to see how it compares speed and thermo to the wireless method.

2011-02-16 10:45:00 Author: Tygers Posts: 114

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.