If you use my serial/hex conversion system, at your scale, it will end up saving u a LOT of space AND speed.
Store data in hex, and right before the write and right after the read, you convert to/from (respecivtly) hex. Allows the density of hex, and the speed + less lag perks of binary transition. Next time ur on do /warp OREboy and look at the memory I'm using, non destructive hex memory that I'm using to pulse serial data in and out. I can explain the stuff I did with it in game or voice if I'd like.
If you used something like that, it would make a lot of stuff easier,, like no complex writeback system, more compact design. And lacks the cons of hex bussing.
With that kinda of system and maybe taking a single plot and putting 4KB on each of the corners of it and use some random part of the address to decide which element data goes to,, (bits 6 and 7 would be pretty good for MC due to my guesses and experiences related to normal program size, packet sizes and such in MC. That spacing could likely allow multiple accesses at once due to the banking) would allow you to do this at 16KB with out AS BAD of lag issues. Or split it up even farther and be even better.
Btw, thanks for understanding about server wide projects. If this gets big, get in touch with me or another admin about moving plots and getting more to have space for this.
^ that actually has a small chance of working, listen to decrapo.
(09-09-2017, 01:35 PM)LordDecapo Wrote: [ -> ]If you use my serial/hex conversion system, at your scale, it will end up saving u a LOT of space AND speed.
Store data in hex, and right before the write and right after the read, you convert to/from (respecivtly) hex. Allows the density of hex, and the speed + less lag perks of binary transition. Next time ur on do /warp OREboy and look at the memory I'm using, non destructive hex memory that I'm using to pulse serial data in and out. I can explain the stuff I did with it in game or voice if I'd like.
If you used something like that, it would make a lot of stuff easier,, like no complex writeback system, more compact design. And lacks the cons of hex bussing.
With that kinda of system and maybe taking a single plot and putting 4KB on each of the corners of it and use some random part of the address to decide which element data goes to,, (bits 6 and 7 would be pretty good for MC due to my guesses and experiences related to normal program size, packet sizes and such in MC. That spacing could likely allow multiple accesses at once due to the banking) would allow you to do this at 16KB with out AS BAD of lag issues. Or split it up even farther and be even better.
Btw, thanks for understanding about server wide projects. If this gets big, get in touch with me or another admin about moving plots and getting more to have space for this.
Hm, I will think about it. I am guessing you are suggesting to me a hex queue? The memory you have at the warp at the moment is more dense than mine (14 blocks / bit without averaging decoder space). However, the decoder averaging may make it around the same. Since the binary model is practically finished, I will work on a hex model and determine if it invokes the speed increases and lag decreases that you say it will.
My write back system is actually fairly simple. It's entirety is contained in the second linked picture. As for lag, I was unaware that hex caused less of an issue than binary. Do you know this for a fact to be true? I am worried about the higher component counts in a hex based system nullifying any lag decreases we get and possibly making it lag more.
Anyway, thank you for the suggestion, and we will see if a hex model promotes a better overall system.
(09-09-2017, 07:57 PM)SpiritTree Wrote: [ -> ] (09-09-2017, 01:35 PM)LordDecapo Wrote: [ -> ]If you use my serial/hex conversion system, at your scale, it will end up saving u a LOT of space AND speed.
Store data in hex, and right before the write and right after the read, you convert to/from (respecivtly) hex. Allows the density of hex, and the speed + less lag perks of binary transition. Next time ur on do /warp OREboy and look at the memory I'm using, non destructive hex memory that I'm using to pulse serial data in and out. I can explain the stuff I did with it in game or voice if I'd like.
If you used something like that, it would make a lot of stuff easier,, like no complex writeback system, more compact design. And lacks the cons of hex bussing.
With that kinda of system and maybe taking a single plot and putting 4KB on each of the corners of it and use some random part of the address to decide which element data goes to,, (bits 6 and 7 would be pretty good for MC due to my guesses and experiences related to normal program size, packet sizes and such in MC. That spacing could likely allow multiple accesses at once due to the banking) would allow you to do this at 16KB with out AS BAD of lag issues. Or split it up even farther and be even better.
Btw, thanks for understanding about server wide projects. If this gets big, get in touch with me or another admin about moving plots and getting more to have space for this.
Hm, I will think about it. I am guessing you are suggesting to me a hex queue? The memory you have at the warp at the moment is more dense than mine (14 blocks / bit without averaging decoder space). However, the decoder averaging may make it around the same. Since the binary model is practically finished, I will work on a hex model and determine if it invokes the speed increases and lag decreases that you say it will.
My write back system is actually fairly simple. It's entirety is contained in the second linked picture. As for lag, I was unaware that hex caused less of an issue than binary. Do you know this for a fact to be true? I am worried about the higher component counts in a hex based system nullifying any lag decreases we get and possibly making it lag more.
Anyway, thank you for the suggestion, and we will see if a hex model promotes a better overall system.
ok... listen to him and not me... i see how it is
Well the decode space can be less then what I have. Mine is optimized for its size and to be simulated dual read, could get a mass storage system smaller.
And yes, we do know hex bussing to be significantly more laggy then binary bussing. Especially if ur sending pulses.
I hope to see what u have so far and to talk to u next time we are both on. I'm curious about a few things
I am abandoning this project due to the advent of item memory research.