+- Forums - Open Redstone Engineers (https://forum.openredstone.org)
+-- Forum: ORE General (https://forum.openredstone.org/forum-39.html)
+--- Forum: Build Discussion (https://forum.openredstone.org/forum-50.html)
+--- Thread: intOREnet (/thread-11366.html)
Pages:
1
2
RE: intOREnet - LambdaPI - 12-09-2016
hmmmmmmmmmmm
if so, then analog serial is feasible
RE: intOREnet - Koyarno - 12-10-2016
Be careful with how you treat 1 tick serial. For example the repeater lock for saving the serial needs redstone dust instead of a block for it to be reliable.
RE: intOREnet - Chibill - 12-10-2016
So we need to make sure all the crazy different systems are not mixed... There is like 3 different internet projects.
RE: intOREnet - LordDecapo - 12-19-2016
Ya... that has been done for like 2 yrs now... that's a very old way to get 1tick working.
Dylanrussel made it back in 1.7.9
RE: intOREnet - LordDecapo - 12-22-2016
(12-20-2016, 12:00 AM)EmpirerBAD Wrote: So... how is 1 tick serial done now then? Haven't seen anything which can replace its functionality.
This way:
![[Image: PmiWxNH.png]](http://i.imgur.com/PmiWxNH.png)
i just tested this moments ago in 1.11 and it works fine still, its like 2+ yrs old and has worked ever since it was made. Dylanrussel made it a while back when i was wanting to use it in one of my systems. I realized that 1 tick is only good for super large transfers, but even then, the size of the memory needed for 1 tick is much much larger than 2 tick, so the memory will lose a good portion of its speed gains from just the added delay of larger unit sizes and the 15 block signal.
Also no one uses 1 tick serial in serious computation due to its difficulty to process. For instance in my CPU i have a packet sniffer that can process 2 tick serial as its flowing. It merely branches off and uses comparator and repeater logic so u never have to stall the data stream, but can still extract needed data. The way i use it in my system in my Instruction Control unit. the slower speed of 2 tick serial transfers end up being faster than 1 tick, saving it, then decoding and doing logic with it... although timing for the sniffer is rather complication, yet 1 tick serial has its own bugs and has to be handled like a toddler in a candy store.
^ the key word in both of those is "computational" and "memory", RAM that needs access to be super fluent and compact to not take bussing delay and cause more chunk updates. And packet sniffing is faster with 2 tick. YET for super massive storage like 1KB or larger.. if u have the right controller, then it can be the best thing around.
These are all just my thoughts based on past experiences, if u find a way to make 1 tick better in any case i mentioned that I personally couldn't, that's awesome! and you definitely have to let me know.!
RE: intOREnet - LordDecapo - 12-24-2016
(12-22-2016, 01:55 PM)EmpirerBAD Wrote: I see why 1 tick serial is difficult for binary processing applictions, and why many times it's best to abandon it altogether. But if you're working in analog, then every bit is received at a 0.4 s interval, making on-the-fly processing manageable, as well as it's easier to save.
Reason I work with it myself, in the chat system-project, is to broadcast a steady pixel stream from server to client over a network with minimal overall equipment, and maximum number of clients. Let's say I use it like a display cable (a kind of "super massive transfer").
Looks like the basic tech is still the same (?). Dylanrussel's receiver looks quite huge/overvomplicated tho.
ah, i have some old repeater only 4bit/tick analog serial system that still works, its just laggy and buggy as all heck xD.
it looks more complicated then it is, its just in a diag system and the pic angle sucks xD
RE: intOREnet - slugdude - 12-24-2016
Update:
I have the final part of the router in place, the collision handling shizzle, and am moving on to testing and debugging. I already know the main router part works as I tested that thoroughly already but now I need to test the collision shizzle,
If nothing major pops up then it should be a go for Christmas Day launch.
That said, I haven't made LAN hardware yet. while you *can* plug your device directly to intOREnet in the long run a LAN will be better but for basic functionality it should work.