Posts

Building SIC-1 in VCB Part 4: Multiplexing clock

Image
 So, last time we built the RAM timing and full-adders, this time i found another important part that we're still missing The Multiplexer, or MUX, This circuit is sort of the opposite of the demuxer, where instead of turning an address into a selection of a RAM bank, we can switch between two signals. As you can see, the circuit has some very nice stacking behavior for the switching input (in blue) which lets us switch between a number of signals (selected in red) with just one input Of course we can also switch between multiple sets of input in a similar way to how we did with the demuxer, though here we get a rapidly shrinking set of data, and lots of inputs Of course, this way of looking at it is somewhat abstract, but it forms the basis for something i think most of us are familiar with but more generally, it allows us to "program" a sequence of outputs if instead of manually changing the selection pins, we attach this to a clock with a small counter circuit, Perhaps

Building SIC-1 in VCB Part 3: Fadder and auto-RAM

Image
 Last time i finished the RAM, an early design for registers and did some initial trial and error with reading data from RAM via registers Next i began some early ALU work, starting from the "traditional" full-adder i made a while back I translated it into a NAND-only version,  which, after some compression, ended up being the exact same size as the original so i could easily hook it into the same test rig Then i started working on automating the RAM read/write cycle, so i could write with registers G/H and read with F/H (H will become the program counter register) This process was somewhat painful since the RAM read signal is just barely long enough to fully store the data, so the write line has to be active before the data arrives, but stop on the same tick that the data line turns off so there's still some leftover wiring from when i tried to have it re-write its own data (which doesn't work since hysteresis can't easily set its own data when the circuit turns

Building SIC-1 in VCB Part 2: DEMUX and Registers

Image
 Last part we built the basic components needed, and a RAM prototype, the next step: a demuxer A demuxer is a circuit that can convert an address into a selection, in this case, it's turning a binary address value into a selection from a "bank" of RAM I then refined the RAM prototype to squash it as much as possible, since i was going to have to find a way to squash 256 cells into a workspace that's only about 2048 cells tall, i ended up with this circuit that's just 8 cells tall, though it meant i wouldn't be able to read the data non-destructively, since the circuit reads and writes simultaneously, destroying the old data, but then trying to separate reading and writing would effectively double the amount of wiring as well  Quite some time wiring later, here's the initial design of the full demuxer plus the RAM bank: Initially i made the "read" bus exit on the bottom, before deciding i'd prefer to have all the inputs in the same place for w

Building SIC-1 in VCB Part 1: RAM

Image
 So i've started a (hopefully) short, and fun side-project again. I'm going to try to emulate the SIC-1 CPU within Virtual circuit board. The SIC-1 CPU is an 8 bit CPU with 256 bytes of addressable RAM i just realized i'm currently making it 256 bits but i'll fix that later (incorrect, turns out i was working on 8*8 bytes) And a single instruction: SUBLEQ A, B, [C] it's a S ingle I nstruction C omputer that should be relatively simple to emulate. As an added challenge, however, i'm also limited to using a Universal gate  to do so,  A universal gate, then, is able to "emulate" other gates, these are the NAND and NOR gates. I've chosen to use the NAND gate, Here's a comparison with their "standard" gates I then added some more designs that might come in handy, a pulse-former seemed useful, and i needed some way to delay signals, an R/S latch also seemed like it'd be needed for RAM, and i also added in a D-flip flop and a manual cloc

On the intricacies of affordance-based interfaces in C++

Image
Well that's a rather obscure title, isn't it, and it'll require some explanation about some non-standard C++ structures i've been building at work. First, i've done a little bit of work in the GO programming language, and i really enjoyed the mechanics of it's non-inheriting interface polymorphism (i've called them affordance-based interfaces) Next, i found this talk explaining how to do type erasure in C++ in order to essentially emulate these affordance-based interfaces: I wrote a prototype of this system such that i could make a set of affordance classes that describe a specific member function, and might serve as a "delegate" for that function, and an interface class that could combine several of these affordance classes into a single type-erasing interface. This part actually uses a bit of "regular" polymorphism to attain it's goal, but since i've written macros that generate all the required code for you, you can effec

A look into the process of refactoring and TDD

Image
Today i figured i'd show, and talk about the evolution of a feature using TDD and refactoring (but mainly show). To start, i already had a tested system for adding nodes, which simply set _currentStrength to whatever node was added, but did not yet add the notion concept that these nodes were arranged in a grid, My goal was to add this feature. Starting off with a few quickfire tests to get the basic concept into place.   Blue arrows: order of steps Squares: Added/changed code. +: new test case Notice how by the end of this process i've written 5 separate test cases, and yet the thing still cannot store more than 1 item at a time ( _currentStrength is not a collection of any kind), This is a sign to "future me" that this feature still needs to be finished. This actually makes life a lot easier, since you have very obvious signs of what still needs to be done embedded into the code. C# also allows you to basically "summarize" the testcases above nicely usin