Cardinal VS Bitgrid

> It’s haven’t bought any Modular’s yet but I’m really looking forward to getting into other on the new year.

http://cardinal.kx.studio

https://vcvrack.com/

The former is libre and gratis, runs as a standalone or plugin and in the browser!! and is based on the latter.

Ther former has a libre and gratis standalone version, the plugin version is non-gratis.

I would look at Cardinal in preference to VCV Rack.

Looked here? You can also download the tar, its like the zip. Follow the instructions how to open it and then install.

I am trying to use rather https://github.com/DISTRHO/Cardinal than VCV and I wonder if I could do a similar thing.

There’s also Cardinal, a free plug-in version of VCV which is very good: https://github.com/DISTRHO/Cardinal

https://cardinal.kx.studio/ https://github.com/DISTRHO/Cardinal/

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