Support for some unix-like environment?
First of all, this looks awesome! It's great to someone nowadays to play with such stuff! It reminds me of https://monster6502.com/ .
A year ago I saw https://collapseos.org/ . Few weeks ago I saw https://github.com/EtchedPixels/FUZIX . Today I see q2.
Have you thought of some unix-like interactive environment for q2 or something like the Collapse OS?
Btw. what were your thoughts of constructing own memory from "discrete" parts? I'm asking because that was the first thing I was looking for when I saw the description "12-bit single-board discrete transistor computer" :wink:.
Yeah, the MOnSter 6502 is a cool project. It would be neat to have a high-level language and small OS environment, but for now I'm more focused on the actual hardware aspects. I think having external storage in the form of EEPROM would be necessary to make something like an OS useful (which is why I'm looking into an I2C interface now).
As far as RAM is concerned, it's tricky because it would use so many transistors. Even just the address decoder would be a lot of transistors. Of course, creating the PCB would be fairly easy (just replicate the same thing 2048 times or whatever), but it would be huge (and/or many), expensive, and power-hungry. This is why old computers used core memory, Williams tubes, delay lines, etc. Also, having the RAM be non-volatile is a must I think, so that also limits power consumption or forces the use of something like core memory.
which is why I'm looking into an I2C interface now
I2C sounds pretty complex for such a simple device - but probably worth it considering you want to connect modern chips to it :wink:.
Regarding RAM - I was first thinking of delay lines, but that wouldn't scale. Second thought was core memory which I thought would be possible to completely redesign for PCB manufacturing. And that's what I was first looking for in your schemes :wink:. And thanks for the pointer to Willliams tubes - they seem extremely power hungry and sensitive to the environment, but it's an interesting piece of technology. Not sure though whether the decoder could be slimmed down - will think about it a bit ;)
Btw. regarding delay line RAM there are some interesting attempts to make it work as a DIY product:
http://www.decodesystems.com/delay-line-memory.html http://jhallenworld.blogspot.com/2014/01/acoustic-delay-line-memory.html https://www.youtube.com/watch?v=tQyX3F4ggM8
To me it still looks a bit easier than to immitate core memory with SMD parts on a PCB (if even possible).
Also the only thing I know of which is "fast" (in terms of "useful for a CPU from discrete components") and non-volatile is bubble memory. But its consumption is also non-negligible (because its operating temperature is around 45 Celsius if I'm not mistaken which means also tens of seconds delay when "booting"). It's though IMHO rather impossible to construct bubble memory from discrete components as many parts of it aren't manufactured for any existing product. Twister memory (predecessor to bubble memory) could work, but it's essentially a smaller variant of core memory which again means it's rather impossible to manufacture.
Maybe we could think of some capacitor memory - two PCBs (with very fine cell-like etched structures) on top of each other with some thin insulator in between and refreshing oscillator. IDK, just crazy brainstorming ...
After discovering http://www.northdownfarm.co.uk/rory/tim/tim-8.htm I think capacitor memory (in an SMD miniaturized form perhaps on doublesided PCBs) is a viable option even for many kilobytes of memory.
Thoughts?
I've put some thought into using a DRAM like structure using two NMOS transistors and a capacitor per bit. The implementation is pretty straightforward and it uses about as few components as I think one can get away with. The diode version might be somewhat cheaper to implement, though I haven't done much experimentation with it.
For a DRAM of say, 1024 words, which is probably about the minimum number that would be useful I think, it would take 2 * 12 * 1024 = 24576 transistors and 12288 capacitors just for the storage. Assuming we could somehow share the sense amplifiers, the extra transistors for that would be negligible (probably nor more than 10 or so transistors?). I would guess this would have to be divided among multiple (hopefully identical) PCBs, and each would end up with its own sense amplifier. Implementing an address decoder would take lg(1024) = 10 transistors per word or 10240 transistors assuming the obvious implementation, though that could be reduced to slightly more than 5120 by re-using the outputs of some transistors. So the whole thing would come to something like 30k transistors. Getting that many transistors on a single PCB probably isn't realistic, but 2k would probably be doable. So that comes to 16 PCBs each with around 2k transistors to handle 64 words (768 bits).
Of course, the more complicated part would be adding extra states to handle pre-charge for each memory access and a periodic refresh. For the refresh, each DRAM board could potentially be refreshed in parallel during ALU operations (assuming each board had its own sense amplifiers). This would require the addition of a 6-bit counter. Then again, if we add a sense amplifier for each 8 words, we could get away with just using the ALU state machine to drive the refresh.
In any case, it's a neat idea.. though I don't particularly like the idea of making the ram volatile.
In any case, it's a neat idea.. though I don't particularly like the idea of making the ram volatile.
It is definitely risky. But really neat as you say. If I found some time in the coming years (yeah, family life is very unpredictable :wink:), I will think about building such memory with refresh.
Some "modern" apps for low-memory devices: https://github.com/hundredrabbits .