Logic gates & electrical stuff

[Mister Webwyre]

After searching for logic gates, electronics / cpu scripting etc, it seem no one is doing this in SecondLife ?

The one example I've found is the "Fetch Decode cycle"  / Sloodle app for the University of Ulster :

http://www.youtube.com/watch?v=N5wjrRkh57Y

http://vrlcom.com/tutorials

So, maybe I won't be "re-inventing the wheel", but rather will have to invent it  ?  :)

I found the timer()  / llSetTimerEvent   scripting elements, which is a start for a cpu / clocked circuit.

Now I'm trying to figure out how to construct logic gates.  It would seem that linked prims might be something I should be looking at ? 

llMessageLinked also looks like it might be useful

I'm looking  at the example TicTacToe game on the wiki, to try to get up to speed on the elements I mentioned above, as it seems to have most of them.

Any ideas / tips / suggestions are appreciated.

Mike

 

[Rolig Loon]

All of scripting is just an exercise in logic.  If you want to apply it to the problem of creating electronic circuits, that's fine. It's certainly been done enough times, but there's always room for a fresh approach.  I'd suggest starting with a few of the basic tutorials at http://wiki.secondlife.com/wiki/LSL_Tutorial to see how LSL compares to other languages that you may be familiar with.  Because it is an event-driven language, you may find that it is better suited to the sort of problem that you have in mind.  When you've written something that you want to share or if you run up against problems while you;re writing, feel free to post your work here.  Someone will be glad to help.

[Madelaine McMasters]

Mike, both examples you cite are highly constrained, which makes them feasible in SL. Do you intend to offer a demonstration of a pre-wired system, as in the Fetch Decode Cycle demo? Or do you intend for people to wire the gates themselves?

[Mister Webwyre]

>If you want to apply it to the problem of creating electronic circuits, that's fine. It's certainly been done enough times, but there's always room for a fresh approach

Done enough times in SL ?

(As I haven't been able to find any examples)

Or with programming languages in general ?  In that case, yes I know there are dedicated languages like Verilog and VHDL, but I thought an interactive"walk through a CPU" might be educational and interesting.

Mike

 

 

[Freya Mokusei]

These are the specific parts of LSL code that may interest you. LSL supports 'basic' boolean logic (which combined with AND and OR mostly expands this range) and also bit-wise/hex-based comparison.

http://wiki.secondlife.com/wiki/LSL_Operators

http://wiki.secondlife.com/wiki/Category:LSL_Flow_Control

It would be fun to see how 'modular' you could make a logic gates system, as well as how expandable. For the most part however, LSL deals with logical comparisons and other operations within a single script.

e.g.:-

if(inputA == TRUE && inputB == TRUE)

{

llOwnerSay("AND pass");

}

else

{

llOwnerSay("AND fail");

}

[Mister Webwyre]

---

Madelaine McMasters wrote:

Do you intend to offer a demonstration of a pre-wired system, as in the Fetch Decode Cycle demo? Or do you intend for people to wire the gates themselves?

---

Ideally, I'd like to do both.

Prewired examples, using scripted "building blocks" (logic gates), as well as maybe using the Sloodle / Moodle framework or maybe just LSL scripting to create interactive / testing / learning / game / quiz like situations.

Heh, but first I need to build some basic logic gates, or even a "lever"  / switch.

It's too bad that apparently links cannot have child links, as that would possibly simplify things, from the little I've read about LSL scripting so far.

Mike

[Mister Webwyre]

---

Freya Mokusei wrote:

These are the specific parts of LSL code that may interest you. LSL supports 'basic' boolean logic (which combined with AND and OR mostly expands this range) and also bit-wise/hex-based comparison.

http://wiki.secondlife.com/wiki/LSL_Operators

http://wiki.secondlife.com/wiki/Category:LSL_Flow_Control

It would be fun to see how 'modular' you could make a logic gates system, as well as how expandable. For the most part however, LSL deals with logical comparisons and other operations within a single script.

e.g.:-

if(inputA == TRUE && inputB == TRUE)

{

llOwnerSay("AND pass");

}

else

{

llOwnerSay("AND fail");

}

---

Freya,

Thanks, yes I've already read those parts of the wiki, and have written code similar to yours.

What I'm trying to figure out now, is how to "graphically" illustrate it with (linked?) prims, e.g three prims for an AND gate, the two inputs and the output, and how to show gates connected and their states.

I'm wondering if an entire CPU / or circuit would have to be one linkset (is there a limit to how many prims in a linkset ?), or if I can make each logic gate a linkset, and then use chat to communicate between the linksets ?

Mike

 

[Freya Mokusei]

---

Mister Webwyre wrote:

What I'm trying to figure out now, is how to "graphically" illustrate it with (linked?) prims, e.g three prims for an AND gate, the two inputs and the output, and how to show gates connected and their states. 

---

As research for this, you may want to look at Minecraft's 'RedPower2' mod, which includes a lot of interesting graphics for circuitry already.

http://nemesis.evalq.net/RedPower2/recipes.html

Bear in mind that prims that are rezzed count towards your prim limit on land, therefore fewer is better than more. If you're looking to simulate complex circuits (100+ gates/steps/etc) I would stick to 1 'tile' shaped prim with a unique, stylised or animated texture denoting its role.

 

---

Mister Webwyre wrote:

I'm wondering if an entire CPU / or circuit would have to be one linkset (is there a limit to how many prims in a linkset ?), or if I can make each logic gate a linkset, and then use chat to communicate between the linksets ?

---

Yeah the SL link-set system leaves a lot to be desired. I would avoid it so that moving the components remains easy. You can still move objects in groups of course with shift-drag/shift-click in edit mode. The maximum number of prims within a link-set is 255.

Chat is definitely how it's going to be done. Take a look at the commands for llListen and llRegionSayTo. One strong method of accomplishing 'pairing' or connection is to generate this small sequence within 2 unlinked prims:-

1. User touches PRIM1, PRIM1 sets to 'awaiting connection'.

2. User touches PRIM2, PRIM2 broadcasts 'I need a connection'.

3. PRIM1 listens to PRIM2, and assigns it as a 'paired' prim with it.

From this point on, you can use llRegionSayTo to make sure chat commands pass explicitly between PRIM1 and PRIM2, without creating confusing 'noise' for other prims in the same circuit.

[Rolig Loon]

---

Mister Webwyre wrote:

---

[...]

What I'm trying to figure out now, is how to "graphically" illustrate it with (linked?) prims, e.g three prims for an AND gate, the two inputs and the output, and how to show gates connected and their states.

I'm wondering if an entire CPU / or circuit would have to be one linkset (is there a limit to how many prims in a linkset ?), or if I can make each logic gate a linkset, and then use chat to communicate between the linksets ?

Mike

 

---

Visit the fourth floor at the College of Scripting, Music & Science at http://maps.secondlife.com/secondlife/Horsa/52/221/113 to run through their panels on representation of logic in LSL.  It's a short step from there to creating modules that you can use as linked objects in a model.  You cannot daisy-chain child links in LSL.  As you've already read, we do not have hierarchical linking.  However, objects can certainly communicate with each other, so you can daisy-chain separate modules to create a logic board.  I have run across several like that in the last few years, but I don't find a current valid LM to recommend at the moment.

[Freya Mokusei]

In addition to my last reply, I should add I'm not going to be monitoring this forum for too much longer today. If you'd like a hand, a demonstration of any of the systems I've talked about (I handle electronics, logic, comms, analysis and a good bunch of other things based in scripts) or even just a chat, your best bet is to IM me in-world.

Further to Rolig's answer, I do have a demonstratable 'pairing system' I can show you if interested.

[Madelaine McMasters]

---

Mister Webwyre wrote:

It's too bad that apparently links cannot have child links, as that would possibly simplify things, from the little I've read about LSL scripting so far.

Mike

---

Sadly, hierarchy is a powerful concept which appears to have escaped LL entirely. Imagine how lovely building would be if we could link things hierarchically.

I don't think llMessageLinked is the right way to pass logic levels between gates, as the ID of a prim is determined by the link order at the time the linkset is created. This is an operation which is outside of, and invisible to, the scripts. The result is that the wiring of your logic system is obfuscated.

I think it makes more sense to have your logic gates respond to messages directed to specific chat channels (so the channel number becomes the gate ID), or broadcast messages on a common channel (you could use llMessageLinked for this) and parse them for gate ID.

The important idea here is that the identity of a gate should be something you can easily observe and control.

[Innula Zenovka]

At risk of sidetracking the discussion, I would never use link numbers to identify prims.   Instead, I use integer variables, with meaningful names, to which I give a value in state_entry, changed, on_rez and anywhere else that seems sensible.

Something like this:

integer intGateA;integer intGateB;integer intGateC;find_prims(){	integer i=1;	integer max = llGetNumberOfPrims()+1;	while (i<max){		string s = llStringTrim(llToLower((string)llGetLinkPrimitiveParams(i,[PRIM_DESC])),STRING_TRIM);		//use PRIM_DESC rather than PRIM_NAME so you can include the root prim		if("a"==s){			intGateA = i;		}		else if ("b"==s){			intGateB = i;		}		else if ("c"==s){			intGateC = i;		}		i++;	}}

 

 That way, you can link it up how you like, and just send link messages to intGateA or whatever, without worrying about what the actual link number is (though you need to remember which prim it is, of course, but you can just look at the description field for that, and move the prim if necessary).

 

[Madelaine McMasters]

I agree that link numbers are the wrong way to ID a gate, for the reason I described. The right way to do it will depend on Mike's overall goal. If he invisions a system in which people can rez and connect gates "on the fly", llMessageLinked is off the table as there will be no linkset, just individual gate prims. This would require a way for gates to find each other, after which they could chat via distinct channel numbers. I might be wrong, but I think using channel numbers to identify gates would reduce the logic system's messaging load.

The script could have two listen filters, one on a "global" chat channel (used for gate discovery) and one on a channel that is unique to the gate (and so would be considered the gate's ID), which could be set during the discovery process. After discovery, the gate's logic functions would respond only to input on the specified channel and the gate would speak its output on whichever channel was set by whatever controls the wiring (which could also be setup on the global channel used for discovery).

On top of all this, if the system is clocked, the clock rate can't be so short that messaging delays would result in race conditions.

[PeterCanessa Oh]

Translate OP please :-(  What's wrong with telling a prim which other prims are its inputs and then having it use llGetObjectDetails() to find out their values, applying the local logic to those values and setting this prims value?  I must be missing a lot of the requirements or something.

[Madelaine McMasters]

---

PeterCanessa Oh wrote:

Translate OP please :-(  What's wrong with telling a prim which other prims are its inputs and then having it use llGetObjectDetails() to find out their values, applying the local logic to those values and setting this prims value?  I must be missing a lot of the requirements or something.

---

Peter, wouldn't your method require something to periodically trigger llGetObjectDetails()? If Mike's system has the user as the ultimate input, perhaps touching "bit" prims to set ones and zeroes, then sending output messages to the inputs of other gates only when an input message or a touch is received minimizes the processor load. Absent any change from the user (or any feedback that could result in oscillation) all the logic scripts would be laying in wait for touch or listen events. Each user touch would cause a cascade of events as the logic "flowed" through the system, eventually coming to rest again.

 

[Rolig Loon]

Good question, Peter.  The physical analogy would be a chip on which you can read a voltage or a milliamperage at each pin and feed that information to whatever is hardwired to it.  Here, each of the "chips" is an autonomous object of one or more prims -- a black box that takes an input signal and yields an output.  You dump that output information as a comma-delimited string to an object's Description field and then let the script that controls the full logic circuit use llGetObjectDetails to read the information and use it as appropriate.  No communication channels needed at all, and you can rearrange the "chips" by simply addressing them in a different order in your script.  I'm no engineer, but if a chemist can figure out how to do that, it can't be all that hard. 

[PeterCanessa Oh]

Right, so I wasn't missing anything except the 'control' prim.  That makes it even easier.

Name each gate prim with a unique number, its logic and each of its inputs' numbers, eg; 27, XOR, 15, 21

Starting from the terminal (output) prims, perform a depth-first graph traversal.  That is, for each iteration, the control prim starts with an empty stack.  It then visits each of the terminal prims.  To visit a prim:  push it to the stack, visit each of its inputs, calculate its state based on its logic and (now visited) inputs, pop it from the stack.  Use the current state of any visited prims instead of pushing them to the stack.

Now I'm in danger or being distracted from the diversions that are postponing my procrastination.

http://www.algolist.net/Algorithms/Graph/Undirected/Depth-first_search may help if this doesn't make sense.

[Mister Webwyre]

---

Freya Mokusei wrote:

As research for this, you may want to look at Minecraft's 'RedPower2' mod, which includes a lot of interesting graphics for circuitry already.

 Chat is definitely how it's going to be done. Take a look at the commands for llListen and llRegionSayTo. One strong method of accomplishing 'pairing' or connection is to generate this small sequence within 2 unlinked prims:-

1. User touches PRIM1, PRIM1 sets to 'awaiting connection'.

2. User touches PRIM2, PRIM2 broadcasts 'I need a connection'.

3. PRIM1 listens to PRIM2, and assigns it as a 'paired' prim with it.

From this point on, you can use llRegionSayTo to make sure chat commands pass explicitly between PRIM1 and PRIM2, without creating confusing 'noise' for other prims in the same circuit.

---

 

I've actually used Redpower quite a bit.

I found something even better (for my purposes) for Minecraft :

http://eisental.github.com/RedstoneChips/

Thanks for the tip about "llRegionSayTo".   Looks like another useful function.

 

For all who've commented on the link strategy ... thanks ...  

I'm a novice at LLscript .. though I've programmed in many other languages.  I guess it's not the best way to proceed with this.

With all the suggestions of chat / transmitting etc, I'm thinking now of a central prim, that when gate prims get rezzed, will transmit to the "center / master", and will then receive their pin frequencies, etc.  

As well, when a gate is connected into the network, there will be a way of the connecting / receiving nodes to send their status / receive frequencies from the master prim.

I'm lookin at the on_rez and  object_rez events now which look handy for triggering initialization code, when items will be dragged from inventory (rezzed ?)

 

Mike

[PeterCanessa Oh]

(off-topic but then everything you need is in my previous post)

llRegionSayTo() is great :-) It's almost the only function I use for same-sim communications now.

[llRegionSayTo(), llMessageLinked(), llSetLinkPrimitiveParamsFast(), llHTTPRequest()  and, of course, llLinkParticleSystem().  Everything else is just filler, hehe]

[Mister Webwyre]

---

Rolig Loon wrote:

Visit the fourth floor at the College of Scripting, Music & Science at

http://maps.secondlife.com/secondlife/Horsa/52/221/113

to run through their panels on representation of logic in LSL. 

Thanks, I've been to that site before.

Someone spent a lot of effort making those panels.

Too bad, they're not interactive.   Would be nice if you could  touch a panel, and it would create a prim(s) with an example script.

Mike

 

 

[Helium Loon]

I would say a single prim per gate (or element, for those composed of multiple gates), with particle emitters for the various connections to other prims.  Anything but a simple circuit is quickly going to get VERY prim heavy.  But, you can have examples of the 'building blocks' as individual gates, to show HOW they work, then have ICs that do the work of multiple gates that are a single prim.  So you show how a single-bit adder is built, then you have a 'single bit adder with carry-out' IC......which you show how it can be chained to make an n-bit adder.  Then you have a, say, 8-bit adder IC which you use in the actual CPU.

Each prim has a script which scans for nearby scripted objects, and filters based on name, and presents that as a list for connections.  It shouldn't be hard to script most gates and elements.  And by switching the texture on the particles that show connection, it can change appearance to show whether it is at high logic or low logic.

 

[Madelaine McMasters]

---

Helium Loon wrote:

I would say a single prim per gate (or element, for those composed of multiple gates), with particle emitters for the various connections to other prims.  Anything but a simple circuit is quickly going to get VERY prim heavy.  But, you can have examples of the 'building blocks' as individual gates, to show HOW they work, then have ICs that do the work of multiple gates that are a single prim.  So you show how a single-bit adder is built, then you have a 'single bit adder with carry-out' IC......which you show how it can be chained to make an n-bit adder.  Then you have a, say, 8-bit adder IC which you use in the actual CPU.

Each prim has a script which scans for nearby scripted objects, and filters based on name, and presents that as a list for connections.  It shouldn't be hard to script most gates and elements.  And by switching the texture on the particles that show connection, it can change appearance to show whether it is at high logic or low logic.

 

---

I like this!

[Mister Webwyre]

---

Helium Loon wrote:

I would say a single prim per gate (or element, for those composed of multiple gates), with particle emitters for the various connections to other prims. 

---

Particle emitters for "virtual" wires sounds cool !

I haven't used particles before, but I just tried this script from the wiki, and got a "local" (around the prim)  "burp"

I created another prim and put this in it :

 

//// nodeRegister//key uuid;default {   state_entry() {      uuid =   llGetKey();      llSay(0,"(node1) state_entry uuid-key: " + (string) uuid );//      llRegionSay(800,(string)uuid);  } touch_start(integer num)    {    llSay(0,"(node1) touch_start : sending  uuid on channel 800 " + (string) uuid );    llRegionSay(800,(string)uuid);  }}

 

I added this to the "example" script :

    state_entry(){        llOwnerSay("(particles1) state_entry : listening on channel 800");        llListen(800, "", NULL_KEY, "");        updateParticles();    }   listen(integer channel, string name, key id, string msg) {        llOwnerSay("(particles1:listen) Received msg: " + msg);        llOwnerSay("(particles1:listen) channel =  " + (string) channel);        if(channel == 800){        llOwnerSay("channel = 800, setting target to : " + msg);        target = (key) msg;        }   }

 But the particles are not going to the target prim.

I'm looking for  "laser beam" scripts,  (wire scripts ?) now.

 

Mike

[Rolig Loon]

Visit the Particle Lab in world, do all their tutorials, play with the freebies in their sandbox, and have fun. That's the way we all learn.

[PeterCanessa Oh]

[@ Rolig - I need help to say this]

Mister Webwyre, particles are .... not .. the way to do this. **Agghhh it hhurtss!**

Consider that each prim can only have a single particle-emitter.  Almost every gate will have two or more inputs so you'd need at least 2 prims (= 2 emitters) to show where the inputs came 'from'.  But that won't look very good.  What you really want is a display of where the output goes 'to'.  And that sounds fine, since  each gate only has one output.  But that output could feed into any, variable, number of other gates' inputs.  So you'll need lots more prims, on average, but won't every know how many apart from 'LINK_ALL_CHILDREN'.  And then you'll have trouble with the particles all going straight to their targets anyway.

Wires are going to be far harder to represent easily than gates are but I think just putting lines of prims with animated textures for when they're '1' and still for '0' will be the only practical thing.