Phot ROM Writer by motaywo
A demo showcasing a prototype ROM programmer that uses FRAY and writes filt data to a PHOT Stack. The incrementer is courtesy of mark2222, and can be replaced with any filt source. This is still a work in progress so feedback is welcome. Changes too!
Comments
-
motaywo 27th Oct 2017
@Schmolendevice, here's a link to the demo of the 'Trigonic' reader. I can't make it work yet, but it actually tries to adress some of the things you've mentioned here. The three FRAY nodes would cycle PHOT between them, with the upper bits of data used to track the index of each data packet. When the desired packet is reached, the device would recording at the next node, one frame later. A lot of cases you simply read my mind! id:2203514 -
Schmolendevice 27th Oct 2017
@motaywo Here, an accessing device must literally "track" the PHOT drive until the counter reaches the desired address and then stream the desired number of ctypes to an FRAM. The same goes for writing, except that the FRAM or some other device would be sourcing the data while the SET FILT write head is "engaged". Here, PHOT is neither created nor destroyed and the particles', hence ctypes', orders are preserved. A literal hard drive. -
Schmolendevice 27th Oct 2017@motaywo The writer, SET FILT, could be lowered in place at one of the "corners" of the reading loop. So long as the number of PHOT is a power of two, we can easily hook up the switch to activate the FRAYs with a counter of n bits' enable signal to precisely count the number of times the "track" has been advanced. DTEC is positioned nearby appropriately for constant reading.
-
Schmolendevice 27th Oct 2017@motaywo Another possible solution would be to just go straight to implementing something like a little hard drive track by creating the equivalent of a "PSTN rotator" with FRAY. Start with a blank slate containing a certain number of 2^29 ctype PHOT cells. As demonstrated here, you can use FRAY to stop PHOT in its tracks instead of bounce or splice in order to make 90 degree turns. Use a lower temperature FRAY to control the velocity of the PHOT and hence the reader/writer's width.
-
Schmolendevice 27th Oct 201710/26/17 @motaywo Indeed. Although I haven't looked at the code myself, it looks like the particle IDs are being placed into an ArrayList of whatever C++'s equivalent is with free IDs added to a stack that must be emptied before new IDs are added. So of course, the "quantum mechanics" here is quite predictable, but only if you know the entire state of the complex system. Could you briefly describe this "trigonic" system?
-
motaywo 26th Oct 2017Thanks for all the feedback everyone! @Schmolendevice: This only works because the photons are being created predictably by the one particle of DRAY. The system breaks down after you read the data 'cause the particle ordering goes to lolz when you start destroying photons. In the 'next steps' save I mention a "trigonic read/recorder" that could solve that problem. I'm working on a prototype and will explain what exactly that is
-
Schmolendevice 26th Oct 2017Here. id:2203100.
-
Schmolendevice 26th Oct 2017I ran into this problem with earlier designs of my 2D FRAMs when I was trying to use DRAY to copy another DRAY into a position where its particle ID needed to be higher than all the particles around it; I could never get this to work reliably. At any moment in a complex circuit undergoing arbitrary particle creation and destruction, your PHOT beam could suddenly start outputting "memory cells" in the wrong order. I am going to try testing this phenomenon.
-
Schmolendevice 26th Oct 2017Thing is, this, and your StorFrame tech, rely on what I call "creational particle ID coaxing" where you are assuming that the order of creation of a set of particles guarantees the order of their assigned particle IDs. In this save, it seems to work reliably and in theory you would plug in any datasource at any time, but once you introduce a complex subframe computer with thousands of particle IDs being freed and assigned simultaneously, we literally enter TPT quantum territory.
-
Schmolendevice 26th Oct 2017Oh my goodness, are you actually using the predictability of FRAY's velocity vector addition to stop incoming PHOTons in place and dynamically layer them? *faints