If the bounding box is all that matters, then a reduced metacell is only a small step in the right direction. Is there any need for the "pixel" part of the metapixel? I hope I'm not missing some obvious display-screen part of the actual GoL pattern.
If you only need tiles that can emulate the four VarLife rules B/S, B1/S, B2/S, and B12/S1, you might be able to fit that into a tile size around 256x256, but it will take a lot of fiddly adjusting and welding. 512x512 looks like plenty of room.
It would be a real bonus if the golfed-down version just "happened" to be a pure power of two, because the full GoL pattern will actually run about as well as the VarLife pattern in Golly -- thanks to Hashlife, it would just take a constant amount more memory.
The only real reason why we would need to see the state of a metapixel is if we want RAM to be physically readable. I'm guessing that without this, we might stretch the rules of the original challenge, but it shouldn't affect the actual computer's performance
Depending on the design, it might well be possible to build a "display screen" bank somewhere, and a given RAM location would send an extra signal to a specific pixel in the display screen.
The pixels could even be a different size than your VarLife pixels, and it would still work, as long as the period of the display pixels was the same. Connections would have to be custom-made at the GoL level, though, not the metapixel level.
That was our original plan (that's basically video memory) but when we made the new RAM we decided it'd be simpler to write directly to it since you could see it
@KZhang maybe connected to another bus if we get those working?
Yeah, I don't think a redesign to include video memory ought to be a high priority or anything -- maybe just a longer-term idea to keep in mind. If you keep the metapixels it's not a terribly difficult project.
A couple of patterns just got added to Golly 3.0, that give a better sense of the unreasonable abilities of the HashLife algo when you feed it properly with all powers of two. See, e.g., Patterns/HashLife/triple-Snark-wick-extruder.rle.gz.
For the first cycle, it runs at a pretty good clip, but it has a lot of work to do. But after one 262,144-tick cycle, 95% of its work is already done -- if you give Golly enough memory to save all the hashtiles. So after that it speeds up tremendously.
... Just mentioning this in the hope that, whatever the next "golfing-down" stage turns out to be, optimization will just happen to stop at power-of-two boundaries for both space and time.
It's really easy to write Lua scripts for Golly 3.0 that drop gliders in to change the state of your key metacells, and ... possibly? ... play a kind of slow but real-time GoL Tetris.
Sure, Python scripts work in Golly too -- we're just pushing Lua these days because it's available without any extra installing or worrying about versions or 32-bit vs. 64-bit.
Definitely don't worry about playability, because it might never be playable, I'm not sure -- but it looks to me like the possibility is actually there, after the next golfing-down. I'd love to see the experiment tried.
I didn't add Lua to Golly 2.8, just translated some of the scripts from Python. It's not LuaJIT, just a statically embedded plain-vanilla version 5.3.4 Lua interpreter. Would use it rather than Python for the trivial "drop a glider here" scripts, just because then they'd always work even if Python isn't installed on someone's computer.
8x8 tiles of metacells (or smaller but still vaguely metacell-like circuits) would be a big improvement over 11x11. Oddly enough, 16x16 metacell tiles would be an almost equally huge improvement, from Golly HashLife's point of view.
But 16x16 would have to be combined with a smaller metacell, or it wouldn't count as a golfing-down of the current magnum opus.
And 8x8 circuit tiles actually won't help Golly much, unless you also replace the OTCA metapixels with something with a pure power-of-two period. There will still be too many gigabytes of different hashtiles, so Golly will always end up running out of RAM and garbage-collecting before it hits its super-efficient simulation stage.
2 hours later…
Anonymous
4:56 AM
@DaveGreene Assuming a Python installation isn't that much of an assumption.
Anonymous
@DaveGreene I don't think 8x8 is doable for many of our logic gates with the current wire/electron design.
@Mego Sounds like KZhang is giving it a try, so probably it's within reach if you allow enough grouped tiles, making 8x16 or 16x16 when they're needed (?)
Anonymous
@DaveGreene I don't know how successful a pure 8x8 implementation would be. Many of the logic gates are extremely compact at 11x11. Using a mix of 8x8 and 16x16 tiles would be more feasible.
The other option would be to replace the entire "tile" layer of abstraction with logic gates implemented directly in low-level period-1 CGoL circuitry,
but that's a much bigger job -- not terribly difficult but really tedious. Have to re-solve all the timing problems that the 11x11 tiles have already painfully solved, but using known glider reflectors to do the timing adjustments.
Anonymous
Yeah, that would be a nightmare to design in pure-GoL. Not impossible, but much more work than using the existing metapixel.
There's a scattering of people who would be really good at it -- all the pieces are available. Just a matter of getting a big enough group motivated. (Yes, that's the hard part.)
At a rough guess the whole CGoL replacement for the 11x11s would fit in 512x512 easily, or 256x256 with a lot of painful adjusting and fitting.
But then the state of the circuit wouldn't be very visible, especially zoomed far out, so you'd really need to invent some kind of video memory tiles. That's also been done a bunch of different ways already, some of them even HashLife-friendly.
Meant to mention: to avoid timing problems, each circuit tile should probably have a small high-period CGol "clock" gun in it, to guarantee output(s) at the exact right time. Basically it would wait around until all inputs from neighboring tiles have safely arrived, and are stored as boat-bits or the equivalent. Then a signal from the gun would fire up the required logic circuit and send out the result.
There's also a surprisingly small mechanism called a "universal regulator", that can safely align unknown-timing inputs with a clock signal of your choice. Don't think that will be needed, but it's available.
- make a repo for Metafier and ROM creation tools - make a repo for circuits and the computer - make a repo for Tetris (Cogol source, QFTASM, ROM) - transfer qftasm-interpreter and circuitsimulator to the organization as opposed to having them as forks - delete anything that's literally named "random stuff" (sorry KZhang) - clean up some of the random Cogol source files
cc @Mego @PhiNotPi
also renaming "WriteUp" to "TetrisWriteUp" might be good since in the future we may have more than one write up :P
Anonymous
5:19 PM
@quartata I agree, except that I suggest we just remove the circuit simulator repo. It never got any significant work done, and doesn't really add anything to the project.
