• 3/9/12 9:51 pm
- 778 views • 0 today
- Progress
- 100% complete
- 4
- 0
- 7
1
This is the original MCTP router built on the Redstone Development Foundation by Elseagoat and myself. it has four ports (one outbound and three local), and uses a combination of buffers and serial encoders/decoders to route data throughout the device.
More like this
Minigame - Minecraft in MinecraftRedstone Device Map
MrZeffoes
•5/16/14 2:35
24.3k 2.7k 20x 1166
![[1.8+]Minecraft In Minecraft Minecraft Map & Project](https://static.planetminecraft.com/files/resource_media/screenshot/1416/2014-04-15_230653_thumb.jpg)
luluty55655882
2
AkiroMC
Janss_33PL
Hardmuscle
Have something to say?
Next time, maybe try using Serial tech ; )
The multiple lines had-me confused, it's for additional speed i see.
I wonder also, how does the system detect a start-of-packet ?...
If packets are each 24-bits and you have 3-cables which are all running on unique data, how does it time receival?, or perhaps put more clearly, how does your MCTP differentiate no-packet from a packet which happens to have 0's in all fields.
It's a very interesting project indeed; and i have two great devices which could be hooked-up to such a thing.
The first is a bi-directional 'real-internet' interface so you can send e-mails, maybe even develop a basic web-browser.
I've developed the technique quite a bit recently and the speed is very compatible with this device ( 6-8 bps ), I'll upload a tutorial on the technique if your interested.
The second idea is to build a compatible device with the new wireless-technology which could allow packets to be routed wirelessly (perhaps for routers on a server which might be too spatially separate to connect conventionally )
I like the idea of sending files, and i wonder; are you using addressed memory circuits or piston hard-drives?... because for streaming files back-and-forth; piston-drives would have some very useful properties.
Thanks again,
the way we time the recieval is the same as the first part of my reply, everything is tied to the first byte, our buffers, sipo, and everything else require the first line be active to pass on, so you can't recieve half of a packet and have it get out of sync, the system just maintains the order of the packets so you don't run the risk of losing data.
That'd be a very interesting device to see hooked up to this, as of now the project is sort of on hold, but we do have most of a working file server and client built that allow for uploads and downloads of 16 byte files, we ended up using standard ram instead of piston tape due to the read/write speed limitations on the piston tape, althoughwe did consider it for the size/space ratio.