Bitgrid VS sbts-aru

The BitGrid[1,2] - a novel model of computation, similar to Turing machines in simplicity, except the parallel execution model allows for PetaFlops of performance in a small efficient package, I hope.

MStoical - A fork^3 of the STOIC language, I'm considering scrapping the C version and just going with Pascal, so I can get quick and easy gigabyte string handling. For now, however, it remains in C, OLD C, apparently.

[1] https://github.com/mikewarot/Bitgrid

[2] https://esolangs.org/wiki/Bitgrid

[3] https://github.com/mikewarot/mstoical

I'm learning FPGAs, using the $25 Tang NANO 9K that I bought on Amazon Prime[1]. I just figured out how to use the PLL to generate clocks of arbitrary frequency, rather than the stock 27 Mhz.

I'm interested in using this board as the core of a SDR transceiver for the HF Amateur radio bands. Driving all the phases for a Tayloe polyphase mixer[4] should be trivial. The real question is, how high of a frequency can I get? ;-) Can I do 2 Meter SSB with it? I think I'll be able to do an NCO up to about 400 Mhz.

The reason I bought it in the first place is that I intend to design a BitGrid[2,3] chip, should there ever be another Google Shuttle, and this is my get to know Verilog project. I may break down and spend actual money on TinyTapeout[5] at some point in the future if Google gives up on the shuttles.

---

I help an older friend continue to repair electronics. He's been fixing things since the 1950s, we've tackled everything from a jammed Scotch Thermal Laminator[6] machine through to Cesium Beam Atomic Clocks[7] with "dead" tubes. (Fun fact, usually you can use a high voltage power supply and time to power the ion pump and recover the tubes)

[1] https://www.amazon.com/dp/B0BCXYWV3T

[2] https://esolangs.org/wiki/Bitgrid

[3] https://bitgrid.blogspot.com/

[4] https://www.norcalqrp.org/files/Tayloe_mixer_x3a.pdf

[5] https://efabless.com/tinytapeout

[6] https://www.scotchbrand.com/3M/en_US/p/pc/laminating/thermal...

[7] https://www.cs.cmu.edu/~dga/time/5061/5061B_ops.pdf

I found your previous post - https://news.ycombinator.com/item?id=38170336

I find your ideas interesting, especially your strong interest in routing around any faults, but still ending up with a relatively usable compute fabric.

My approach is much, much simpler.... just a grid of cells, with the programming lines unspecified. Each cell has a 4 bits in from their neighbors, a 4x4 LUT, a latch on each of the 4 bits of output. Clocking on the latch is in 2 phases, like the colors on a chess board.... this makes everything deterministic, but fully Turing complete.

Here's a write up as an Esoteric Language: https://esolangs.org/wiki/Bitgrid

Here's an emulator written in Pascal: https://github.com/mikewarot/Bitgrid

This month I'm going to collide BitGrid[1] (a project stuck in Analysis paralysis forever) with Advent of Code, excitement guaranteed!

[1] https://github.com/mikewarot/Bitgrid

Here's my old blog on the subject

https://bitgrid.blogspot.com/

Here's my github repository where I have an emulator written in Pascal

https://github.com/mikewarot/Bitgrid

Here's a writeup on the idea on the esoteric languages wiki

https://esolangs.org/wiki/Bitgrid

I'm not sure if the idea[1,2] is stupid, or brilliant... and I'm not arrogant enough to assume its brilliant. I've been nerd sniped by it though, since the 1980s. The basics are simple enough, imagine an FPGA without any routing hardware, just a sea of 4 bit in, 4 bit out Look Up Tables (LUTs). To prevent race conditions, I'd latch the outputs of the cells, and clock then in 2 alternative phases. This makes the thing a horrible FPGA, because latency is the one thing they fight hard to overcome, but on the other hand, it makes it very easy to reason about, and immune to race conditions, timing issues, etc. The gain is that you get almost trivial routing, and essentially all of the transistors devoted to compute.

It's what you get when you answer George Gilder's call to "waste transistors".[3]

[1] https://esolangs.org/wiki/Bitgrid

[2] https://github.com/mikewarot/Bitgrid

[3] https://www.wired.com/1993/04/gilder-4/

I've been following home-made semiconductors since Jeri Ellsworth made her own N Channel JFETS in 2010.[1] When Sam managed to make his own ICs, I was happy for him, and for the hobby. Now he seems to be on the verge of democratizing access to semiconductor production in very low volumes. I've got my own project to try out once I can get my hands on it.[2] Who knows, petaflop chips made in the garage could be right around the corner, in less than 2 decades!

[1] https://www.youtube.com/watch?v=w_znRopGtbE

[2] https://bitgrid.blogspot.com/

One of my bucket list items is to bring about a new model of computation, the BitGrid[1]. It's a cross between a systolic array and FPGAs... but it would definitely NOT work as a practical FPGA.

On the other hand, maybe it could bring Exaflop computing to the masses?

[1] https://github.com/mikewarot/Bitgrid/blob/master/WhyBitGrid....

I was working on a BitGrid simulator[1], but I got stuck. I got the emulation running, and at a reasonable speed too. (I can emulate a 1024x1024 bitgrid at 34 Hz on my desktop machine).

I'm stumped as to how I should do I/O. The primary aspect of the bitgrid is that it's an FPGA with zero routing fabric, but clocked to prevent race conditions. This means that results could be skewed. I could either force the outputs in parallel before output, or have the output handler deskew them externally.

It's silly that I'm stumped at this point.

[1] https://github.com/mikewarot/Bitgrid

Unfortunately a Raspberry Pi is a bit ill suited for production environments. Id recommend an RTC module. Otherwise this might be helpful: https://github.com/hcfman/sbts-aru

If you install my sbts-aru project

https://github.com/hcfman/sbts-aru

It will shrink your partitions, add news and install one of these and set up a sub micro second system clock and an audio recorder suitable for sound localization with a single install command.

I recommend primo EM272 microphone capsules for use with https://github.com/hcfman/sbts-aru. They are high quality, very sensitive with high signal to noise ratio, lauded for nature recording use cases. They can be bought assembled for around 65 euros in the Netherlands. However these capsules are often found in much more expensive equipment.

My sound localizing Raspberry Pi installs a resilient base system as part of its install.

https://github.com/hcfman/sbts-aru

https://hackaday.com/2023/12/30/localizing-fireworks-launche...

With one command it for all Pi’s for both Raspbian and bookworm it:

* Shrinks the file system (Gee, how does it do that with just one disk ? ;-) )

I have a sound localization project that can help with that

https://github.com/hcfman/sbts-aru

You need to be able to hear the sound from three or more recorders. And normally localization is better within the polygon of microphones but there’s an area of better localizability extending outside of a vertex.

Interesting history!

And while we are in the subject of sound localizing may I take the liberty of introducing my new raspberry pi sound localizing audio recorder.

https://github.com/hcfman/sbts-aru

It installs with one command on all Raspberry Pi versions and synchronizes the system time to less than 1 microsecond of error with a cheap GPS.

With three of these I’ve been able to sound localize the explosions from illegal fireworks to a specific car park from more than 3km away with lots of houses in between.

When I got to the car park I could smell the sulphur from the fireworks.

This will even run on a Raspberry Pi zero running of a battery with a 6 euro neo 7m gps and a 6 euro usb mic.

Very nice tool!

So grab a spare Raspberry Pi, a GPS, a cheap USB sound card and a mic and get recording with this Pi based Acoustic Recording Unit

https://github.com/hcfman/sbts-aru

And while you are at it, install 3x or more and localize where the birds are.

Sound localizing. I was intensely passionate about it when I saw the possibility to do it well on a Raspberry Pi. There were quite a few more problems than so expected which is why it took five months (of weekends) to complete it well.

But I’m super happy with the result and have a bunch of geeks with recording nodes setup a long distance apart. Localizing large explosions show that it’s possible to localize to a carpets even when some of the nodes are almost 5 away.

For those interested, here is the project:

https://github.com/hcfman/sbts-aru