Kristopher38
commented
1 year ago Somewhat late to the party, I made KubeJS scripts (sort of a mod) a while back to allow interfacing with TIS-3D peripherals effortlessly using computercraft. It needs KubeJS and KubeJS Computercraft mods and exposes casings as peripherals, with functionality which mostly consists of reading nbt of attached modules, but you can also write code to the execution modules and data to RAM/ROM. This vastly differs on the level of complication from the idea described above but I believe it's the next best thing (because it exists ;)) in terms of automating the mod.
kristibektashi
In theory, it's very easy to write some data to a ROM module - just fill RAM and sneak-click it with a ROM module in hand, or open up its GUI and write the bytes in manually - but things get complicated once you factor in automation. While there are mods out there that provide the ability to imitate sneak-clicking blocks without actual player interaction, those are rare among those that offer only the ability for regular clicks (with Create being among the latter). In my opinion, that actually turns out to be a good thing - after all, if writing to ROMs were as easy was writing in RAMs, that would significantly hamper the usage of the latter. Still, sometimes you want a persistent storage that is as easy to use as a ROM module and can be stored in an item form, and can be automated to a certain degree without being forced to click everything yourself. After all, the major computer mods out there - OpenComputers and ComputerCraft (and likely OpenComputers II, once that hopefully comes out <3) - allow for using disc and disc drives to achieve the same purpose, so why should TIS-3D be left behind?
So, proposed here is a mechanism by which ROMs can be written to in an automatable way, specifically designed to avoid devaluing RAMs and other storage methods, while providing an unusual twist to RW mechanics and encouraging players to come up with creative solutions to work around it.
The design
In real life, programming ROMs often used to be done with the help of strong ultraviolet light. In a semblance of this, a TIS-3D machine could be designed in such a way as to allow the Infrared Module to send its intense beam directly onto a ROM module (rather than to another Infrared Module). When this happens, the latter "staggers" as its sensitive electronics perform a quick safety reset to prevent data corruption, locking down for all reads and writes and then recovering completely after a few ticks (game ticks, not controller ticks).
This would normally result in only in a slight delay and a consumed data packet... unless done within a short time window after ROM receives an address from which to read (thus locking onto a specific byte and exciting its data cell with high currents), but before it gets an actual read request for its value from another module. In that case, the beam gets to directly affect the exposed cell, causing its existing value to be OR'd with the value sent by the infrared beam and rewritten - thus, likely altering was supposed to be read-only memory!
Infrared beams can carry 2 bytes of data, but ROMs store only 1 per cell - so how does this resolve? It'd be natural to assume only lower or higher byte would be taken, or that two memory cells would be written to at once and so on, but remember that the ROM module is locked onto a single memory cell and there're no convenient intermediate circuitry that would strip the extra bytes for us - it's just a raw energy beam facing the exposed circuitry! Instead, what happens is that bits from the beam get "smooshed" together in pairs - each subsequent 0b11 from a source beam acts as a 0b1 for the purposes of OR'ing, while 0b00 acts as 0b0, while 0b01 and 0b10 randomly come up either way with a 50/50 chance each - for instance, 0b00101110 10001101 resolves as 0b0R1RR01R, where "R"'s are random bits, and this is the value that gets bitwise OR'd with the value already in the cell. Thus, in general, an additional processing step is required to prepare data for writing into ROM (unless you want to end up with garbage or, perhaps, are building a convoluted pearl-less noise generator). Yes, this is not very realistic either, but hey. :P
Finally, crafting a ROM module all by itself would reset all its values back to 0x00 - finally allowing for full automation of the ROM writing process, besides just being generally convenient for manual operations.
Writing process
In effect, to write some data onto a ROM module, the following procedure can be followed: 1) Prepare the address space you want to write to, if necessary. In general case, this would mean fully resetting the ROM (either by manually setting all values to 0x00 through its UI, or by reading from a RAM module, or by putting it alone in a crafting grid - it's the last one that can be automated), but can mean lots of other things depending on the specifics of your design; 2) Write an address to it as if you were reading from it, but don't actually read anything yet; 3) Prepare the desired value to survive the bit "smooshing" procedure described above, and send the resulting value by the Infrared beam directly at the module itself. 4) Repeat the process until all data is written - this might take a while, as, remember, the ROM module locks up for a few ticks after getting hit by an Infrared beam.
The ROM module might then be extracted, stored, transferred, reinserted, or cleaned as necessary by any automated means available. Attached below is a mock-up of a simple design that could write to ROM, as well as very basic contraptions from Create which take and reinsert the ROM module (without the cleaning part):
https://user-images.githubusercontent.com/7757500/150199494-f6a902cb-7148-43f9-b0c1-c1fb702ba739.mp4
Design considerations
If the above process seems slow and convoluted, it's because it is - unlike volatile memory like RAM, ROMs are not written to quickly or easily, which is, incidentally, how it is in real life. Such is the price for persistence!
This suggestion was designed with the idea in mind that ROM modules are exceedingly cheap compared to the alternatives, and if writing to them is to be permitted, this has to be done in a way that doesn't deperecate RAMs or any other persistent data storage mediums (anything from simple solutions like dedicated, usually stalled computers with lots of RAM modules, to exotic ones like placed patterns of alternating charcoal and glass blocks that encode individual bits, or any other number of things, really), while is still doable enough to be used in many applications, provided players were willing to meet the design challenges and work around the slow writing speeds and inability to erase individual bits, potentially with the help of things like RAM buffering and parallelization, as well as making creative uses of ROM storage space to minimize the need for full erasures. The concept itself should also tie well into the general theme of the mod and be fun to play with, as well as not disrupt existing creations and reuse the existing items and blocks rather than add any new ones.
I believe the described above design matches all the above criteria and is worth implementing, and it is my hope the readers wiil see it that way, as well. :3