Project Logs

Collapse

• Sense "Amplifier" Circuit...

  Eric Hertz • 09/26/2023 at 13:51 • 5 comments

  Ken Shirriff did a writeup on DRAM...

  https://www.righto.com/2020/11/reverse-engineering-classic-mk4116-16.html?m=1
  

  check this baby out... looks a heck of a lot like what I came up with!

    

  In my case I'm essentially measuring a small *resistance* difference, rather than voltage. But, of course, the voltage-divider created by those resistances is what's responsible for which relay "wins." The 50 ohm (calibratable) resistor is essentially our reference resistance. If the bulb resistance is higher than 50 ohms, it's considered "on" and the lower relay turns on faster than the upper relay, cuting it out of the circuit. (The bulbs measure roughly 10ohms cold, 100 hot).

  [The 10ohm resistor is an addition for the refresh circuit to self-reset when it advances from one bulb to the next.]

  Simulations, long ago, showed that a bulb could be determined as having been "on" when its resistance had dropped *dramatically*. Real-world tests were not expected to go as well, yet really did far better than I expected, "bits" retaining their value for upwards of a second [of course, that also means that *clearing* a bit to zero also takes upwards of a second], while only being refreshed for a fraction of that. This, too, was a bit of a surprise; I kinda figured I might have to use higher voltages than the bulb's rating to get it to heat fast enough. But, instead, I was able to get a functional system running at less than the bulbs' rated voltages. Increasing the voltage, then, might allow for longer durations between shorter refreshes, which would mean more bits could be handled by the same sense/refresh circuit. [This "sense" circuit also "refreshes" the bulb.]

• Overboard

  Eric Hertz • 06/09/2022 at 04:08 • 3 comments

  Today I worked out most of how to interface with a Z80... Hah!

  It's about 11 relays per data-bit.

  Seeing as how I think I might be able to handle 8 bulbs per refresh-circuit (one refresh circuit per data bit), we're coming out a bit behind.

  So... Hmmm...

  The idea was to have read and write be random-access; completely independent of refresh. There are a couple cases where the refresh and read/write circuits might glitch when run simultaneously... Nothing a couple more relays couldn't fix!

  The next idea was a write-circuit which automatically tests whether the bit is fully-written, before releasing the Z80's "Wait" line. Only a couple/few more relays!

  Right, these things add up!

  ...

  Scaling back, well... An earlier thought was to use the refresh circuit to also handle reading. That might save a couple/few relays at the cost of an additional pole on the rotary-switch/drum. It also means the data will only be available when the drum gets around to it.

  Which, actually, I kinda dig... The idea of hooking this to a Z80 is so utterly ridiculous, but yet, also a *great* demonstration of the Wait signal, which for some reason I'm rather fascinated by.

  Writing... Well... I could save a few, maybe several, relays by just using an RC circuit timed a bit longer than it should actually take to write a bit. Heh, why not?

  I guess, realistically, since writing a *byte* will almost always contain both ones and zeroes, it'll seldom if ever write all the bits faster than it takes for a bulb to cool.

  OTOH, this use of Wait, I'm not as fond of... I'd almost rather write each bit in sequence, as fast as possible, (even if just using separate RC circuits for writing highs and lows), even though it'd be *significantly* slower, because, I guess, I'm fascinated by Wait. This'd demonstrate it better, taking varying amounts of time, depending on the data being written.

  Then, of course, there's the question of where do I draw the line between semiconductors and relays? Wait, itself, will almost certainly have to be driven by a bit of automatic logic; a relay can't switch fast enough! But, Even though that'll likely involve a flip-flop (and some glue logic) I'm not sure I want to use e.g. a 7400-series shift-register to load the bits in/out.

  I dunno, we'll see if this actually goes anywhere. It didn't *start* with thinking to interface with a Z80... it got there when I realized my Write/Verify circuit would take differing amounts of time, and would go well into that Wait pin. 

  That inkling was already there, though, when I realized the Read circuit has two separate outputs, two separate relays, for high vs low. Thus, its data output is guaranteed valid when one of those relays is switched-on. It inherently tells you (or the next circuit) when its data is valid, when the operation is complete.

  I kinda dig that. Especially since its speed may vary depending on things like ambient temperature, or even the shapes of the contacts in the rotary-switch/"drum." Which, actually, are not all identical. Some are skinnier due to the trace connecting the pole to its solder-tab. Those skinnier contacts will likely result in bulbs that average just a slight bit cooler-when-hot than the others. Thus their resistances will be slightly lower, which would make for lower voltages on the output of the voltage divider, making for more slowly-transitioning relays... And, then, leaving even less time, while sliding across the already skinny drum contact, to do the actual reheating. Thus, some bits will inherently take longer to read than others, which, again, I kinda dig the idea of a system that gets it out there as fast as it can, and inherently "clocks" the next process when it's ready (deactivating Wait).

  I'm not certain, by any means, but I think 16 bulbs per refresh circuit is probably pretty close to the limit, based on how much time they'd need to reheat. I was thinking maybe 8, for this project. Then 8 of those in parallel for 8 bytes...

  Read more »

• Refreshing 4 bits

  Eric Hertz • 06/07/2022 at 03:48 • 0 comments

  We now have Incandescent DRAM and a refresh controller!

  (Note, I have since moved the 10ohm resistor such that RyC is now connected directly to C1 and C2. This resistor allows writing at any time, regardless of the refresh circuit's being plausibly already latched at the opposite value. In the schematic, as drawn, it allows a little bit of current to flow through the bulb, heating it up, even when Relay2 has latched low. Moving it as I described prevents any current from flowing through the bulb after Relay2 latches. The drawback is that if the relays are already latched when a write comes through, it will not automatically unlatch them, and instead just waste power through the resistor until the refresh circuit moves on to the next bulb. Still, beter than warming a cold bulb!).

  Do-Refresh resets the latches in the refresh circuit (shown in the last post) when the "drum" rotates between two bulbs.

  The "drum" is a rotary switch removed from an old 6-way Parallel-Printer switchbox, and modified slightly to remove the detents as well as the endstops. Also, it handled 2 poles of six positions each on each "disk", but was easily modified to handle 1 pole of 12 positions, by removing one of the two  sets of brushes, and tying the poles together.

  I had four identical bulbs to work with, so each is handled by three of the 12 positions. The Do-Refresh signal is handled on another rotary-switch disk, tying all its positions together to generate a reset pulse when switching to the next position. So each bulb gets refreshed three times before it moves to the next. I did it this way, rather than doing all four in sequence three times, because I was unsure about the timing... e.g. whether Do-Refresh might hold the previous bulb's value onto the next, due to the layout of the switch wipers. Three refreshes in series would help assure that even if it held the previous bulb's value onto the next, it would have two more tries to switch over to the current bulb's value. It also means all the relays are switching three times as often as they need to. Heh! It's really quite amazing how fast these things are!

  Do-Refresh is questionable, to say the least; if it occurs *before* the bulb is switched-in, it'll think the bulb is hot, so latch (and write) it high, even if it was low (cold). I tried adjusting the wiper a bit so it'd be later in the rotation, but it wasn't really assurable, and also meant that it might be more prone to holding the previous bulb's value onto the next, so eventually I scrapped the wiper-adjustment and gave it a go with the normal wiper arrangement...

  Basically, I'm saying this was thrown together not expecting the timings to be accurate-enough to actually function... but it does, surprisingly well, considering!

  So, the circuit allows for writing any bulb asynchronously to the refresh circuit; a Write overrides the refresh.

  The only "cheat" in here, as far as to its being implementable in the era of the telegraph, is that I added flyback diodes on the relay coils, which, really, was just a quick test that may not really have been necessary.

  Calibration is finicky, but not impossible with a rheostat. And, I think if I had the timings better-aligned (make contact with the bulb first, then Do-Refresh, then maybe even break Do-Refresh before switching out the bulb) it'd be far more reliable.

  (Note that since these bulbs retain their heat for so long, it's actually a bit less finicky than I'd expected. Earlier simulations suggested that the appropriate resistor value was highly dependent on the refresh rate and duration, nevermind the coil resistances, and more. But in the video you can see its working despite the slowing of my drum rotation, etc.)

  If I was making a drum, maybe with magnets and reed switches, or even bumps and microswitches, assuring proper timings would probably be quite doable. 

  But, I've come up with a circuit, adding two DPDT relays, that should delay switching-in the Refresh...

  Read more »

• Refresh Circuit - Concept Proven

  Eric Hertz • 06/03/2022 at 23:58 • 0 comments

• ToPonders:

  Eric Hertz • 01/17/2019 at 02:03 • 0 comments

  AGC, in-circuit... oscillator:

  https://electronics.stackexchange.com/questions/78388/what-is-the-function-of-the-bulb-in-a-wien-bridge-oscillator

  https://hackaday.com/2019/01/16/the-embroidered-computer/

  magnetic beads -> relays... hmmm.... (latching, even?)

• Status - backburner

  Eric Hertz • 01/15/2019 at 05:04 • 0 comments

  From memory, as it's been 'a minute':

  Next Time, probably, to start building a prototype... The full write/read and measure/refresh circuit is now simulated with relays, resistors, lightbulbs, switches, and a rotating drum with magnets and reed switches (to sequence through the bulbs, refreshing each). No Silicon, this coulda been built in 1901.

  The relay count has gone down *dramatically* since the last sims uploaded (TODO: upload!). Reliability seems surprisingly good.

  There's a handy trick could be done to reduce the circuitry-requirements some more: Presently it's necessary to *stop* a refresh of a "1" bulb before switching to the next bulb. Inserting a current-sensing relay in series between the refresh-circuit and the bulb-sequencer/selector switch/drum might do the job. When the selector switch selects the next bulb, it first breaks contact with the previous, current stops flowing, the relay cuts-out, resetting the refresh-circuit for measurement-mode, which as I recall, might work fine if active with no bulb connected. As soon as current flows, the measurement is taken, refreshing begins... all based on the "sequencing" inherent to one relay's actuating causing the next and the next... (no clocking necessary!) Similar to Propagation-Delays in TTL/CMOS, maybe, but since it actually relies on actuation of relays, rather than logic levels which are always "on" in one form or another, there should be near-ziltch as far as intermediate-states during switching/glitching. it's either off or on, and the next stage *cannot* be on until the previous is, and *cannot* remain on when the previous begins to release. It's kinda groovy thinking this way after all the parallel synchronization circuitry necessary for clocked/synchronous systems. Anyhow, an aside.

  The current-sensing relay I imagined was surprisingly hard to find. Seems a simple idea: it's not uncommon to find e.g. a 5V reed-relay actuated at 5ma, or thereabouts... 1kohm winding... So, beef up that wire a bit, winding-resistance down to 1ohm... now a 150mA current flows through the winding, dropping a negligible voltage and actuating while 150mA lights my bulb. Somewhere, thereabouts, anyhow. If they can make tiny little solenoids that run off watch batteries, surely a reed switch could be actuated in these, or similar, conditions... And, surely, there are uses for such all around, no? Lots of searching, seriously, lots. It got to the point I was debating whether the winding in earbud-headphones would trigger a reed switch. Eventually *one* result came up... then two, but only two. Allegedly used in land-line phones/faxes/modems to detect when the line is open(?). Well, shit, if that's the use-case, surely at one time they were plentiful! Surely they have a name! Surely if such exists for phone systems, similar must exist for other common systems, in different ratings and specs. Surely they have a name! "current-sensing relay" Exactly as I'd originally thought, returning results *nothing* like I'd originally thought. Still, only two such models found. WTH. Oh well, I know they exist, and they both happen to be spec'd within my needs, I'll continue to ponder its use, here. What else to do but chalk it up to bad search-fu?

  Anyhow, another aside was coming up with an edge-triggered D-flip-flop. A few of these, if simple enough, could be used instead of the rotating drum. Maybe more worth it, now, per the last "D'oh!" wherein I realized I'd need switch-contacts for every bulb, as opposed to every *column* as I'd originally thought... 4Pole relays exist, 4 rows handled by each.

  So I managed to whittle-down the Master-Slave edge-triggered flip-flop (in the falstad simulator) down from 4 NANDs and 2 inverters down to 2 spst and 2 spdt relays and two resistors... might be feasible. Though 4 per column still seems a bit much, I've other plans for edge-triggered d-ffs, as well. And, still, might be worth pondering, here, when 35 reed switches (and associated magnets/drum-size)...

  Read more »

• d'oh!

  Eric Hertz • 12/17/2018 at 00:19 • 0 comments

  And now we need one reed-switch (or rotary-switch contact) for every bulb. 5x7's not sounding nearly as fun, now.

  
  

• QuickOff Relay-Read/Refresh!

  Eric Hertz • 12/05/2018 at 00:36 • 0 comments

  UPDATE: Circuit Comparisons at the bottom

  UPDATE2: Whoops, noted, and thresholds, at the bottom...
  

  UPDATE3: more thoughts at the bottom.

  -------

  Relay-Logic is *really cool*.

  There are *So Many* ways to implement a simple circuit, each having different benefits.

  Here I've been working on a "Quick-Off" Read/Refresh-circuit.

  In the long-run, this'll help in several ways... Not the least of which is that it won't heat up "Off" bulbs nearly as much (not that it was particularly a problem).

  It also removes the "dead-zone" between high and low measurements. At the end of a measurement, the circuit will either output high or low, no weird inbetween/floating-states.

  BUT, I got on this redesign-tangent because... one of the design-goals, overall, has been the idea that the Refresh-circuitry could run in the background, periodically refreshing a whole slew of bulbs, and Reads/Writes of a particular bulb will not be interrupted by this process. The previous design of the Refresh-circuit allowed for a tiny glitch-case, wherein a refresh perfectly-timed with the end of a write would cause a bulb's being refreshed-high even though it was *just written* low.

  I've gotten so side-tracked, that I honestly don't know whether this new circuit solves that. I'll have to revisit that later. But, here's the quick-off circuit:

  (Click here for the simulation-file, which can be run in the falstad circuit simulator)

  OK, first: The diode is only there for shunting the relays' voltage-surges when turning off, which isn't a problem in the circuit, but makes viewing on the 'scope difficult. (I'm trying to do this whole thing sans-silicon).

  The potentiometer represents the lightbulb. My christmas-lights are 6V 0.48W, so roughly 5ohms on, 75ohms off. I didn't go to a tremendous effort, here, to optimize for those values (by changing the 50-ohm measurement resistor), this is just a proof-of-concept.

  OK,, the circuit:

  The key-concept is making use of the intermediate-stage when a relay is switching from one Throw to the other. The upper relay, when Off, allows measurement of the bulb-resistance by creating a voltage-divider. If the upper-relay has even just-barely enough voltage across its coil to just-begin to pull-in the contact, it immediately breaks the Normally-Closed contact, turning off the voltage-divider. Now the upper-relay gets even more current through its winding, as it goes straight through the bulb without the "upper" resistor limiting the voltage. Thus, causing the upper-relay to pull-in even more-quickly.
  

  Also, as the voltage-divider was turned-off, the lower-relay is effectively shut-off, So, imagine a case where, say, the measurement results in exactly 2.5V, both relays would activate (slowly/slightly, but the same speed/amount, initially)... The *breaking* of the NC contact on the upper relay forces the lower-relay off., mid-swing.

  Similarly, if the lower relay is "faster", then as soon as it makes-contact, it forces the upper-relay off. This was the case in previous designs, but the key, here, is that for one measurement a *breaking* of the contact causes that measurement to be made (and accelerated), so there's less dead-time waiting for the two relays to race each other.
  

  In this system/simulation, then, it can be seen that a measurement can occur *extremely* quickly, And get on to refreshing the bulb, or *not* refreshing the bulb, as the case may be. (Note, again, that *measuring* the bulb-state causes current to flow through it, causing it to heat up, which *could* cause it to eventually switch from "Low" to "High."  (Though, realistically, that hasn't been much of a problem, after some calibration).

  This system does, however, rely on some calibration depending on the relays, themselves... E.G. even though they were spec'd to turn on at something like 2.8V, it seems they actually begin to break...

  Read more »

• Indeed...

  Eric Hertz • 12/02/2018 at 07:08 • 0 comments

  Draft wasn't published, whoops.

  -----

  Been all gung-ho on this circuit [sims]...

  Relays everywhere, no more TTL/CMOS, no diodes.

  Actually, in a lot of cases the complexity has *reduced*.

  Am discovering that there's a lot to learn with relay-logic that is seldom considered for boolean logic... E.G., there are *three* states with an SPDT relay... NC-open/NO-closed, NO-open/NC-closed, and *both* NO and NC open (while switching). And, similarly, an SPST-relay can be "on" in its coil, but still (briefly) be "off" at the contacts.

  This, then, leads one to consider the previous logic operation's output and the next stage's input a little differently than for TTL...

  Combined-with: a string of logic may be *significantly* simplified by changing things like "active-high" vs. "active-low" in intermediate stages... even if, intuitively, it seems odd... 

  But, even still, it's not a simple matter of "here's three ways to implement AND, choose one", since it's really less about the boolean-logic and more about the end-result.

  E.G. The write-verification circuit is simple: XNOR the read-back-value with the write-value, if the two are the same, then XNOR is 1, and the write-process is complete. Simple!

  This is as simple as throwing a SPDT relay coil across those two signals. If they're equal the relay will remain off. OK!

  But, now I need a bunch of logic between that output and the End-Write relay (or before its inputs) because: It should only end-writing if it's writing AND we're verifying. But our X[N]OR signals read/write equality by remaining in its default state... so will always have a "write-complete" output except for the brief moment *when testing* (and the values differ). Thus, additional logic.

  OR: note that what I really want is a relay that turns ON when the two signals are equal. Now we can't just throw a winding across them. But we can invert one signal at the input.

  Handily, the read-back circuit is already out of the picture except when verifying... its output *floats*. That won't turn on our "inverter" relay until we're in verification-mode. AND, even more-handily than gating with the mode, this relay *can't* be active until the value is actually properly read-back, which takes some time.

  So, now, we know that if that relay is on, we are in fact in "verification" mode AND its value is legit. Feeding that sorta signal into an XNOR with an inverted-input, and using the normally-open contact, then, can go directly to our "end-writing" relay... 

  ...which we no longer need, because that relay was normally-closed, to allow the "writing" relay to latch... and now our "values equal" relay is ON when equal, and OFF (normally-closed) at all other times.

  Bam.

  Major reduction.

  But, one problem... our "inverter relay" connected to our read-back circuit remains off both when the read-back circuit output is floating and also when 0. Nope. But our Writing-circuit's value *never* floats under normal conditions, it's value comes from a SPDT switch which is either high or low (except when switching, which shouldn't happen *during* a write). So, placing our inverter-relay there, instead, (or using another pole with opposite wiring) assures that its output is always valid.

  Then, swapping back to the read-back circuit, its value always being "valid" or floating, we can wire that directly to the X[N]OR relay-winding, and now that relay will only ever turn on (breaking the NC contact, stopping writing) when the data's valid, we're writing, we're verifying the write, and the read-back value is opposite the inverted write-value.

  BAM. A shitton of logic removed, and no need for added delays or synchronizers to wait until the read-back system has valid data.

  Tri-state FTW!

  I gotta say, There are some impressive relay-projects out there, many here on .io. Some relay-computers, even. I never really considered 'em anything more than just a pile of gates implemented with relays instead of TTL... An impressive feat alone,...

  Read more »

• RAMdom updates

  Eric Hertz • 11/27/2018 at 19:25 • 3 comments

  Bought a string of "holiday festive lights" from the dollar-store. $1, 20 bulbs, 120V. These may be darn-near perfect. 

  My original experiments were with a 120V 100W bulb... This was measured to be ~10ohms cold, and calculated to be 144ohms hot.

  I ran some other experiments on a couple 12V bulbs in my home... One looked to be ~0.1ohms cold, ~1.5ohms hot... that'd be hard to work with. Though, it heats and cools at a rate measurable with my multimeter, which is handy... about 3sec->cool.

  But, those resistance values would be tough to measure with my old-relay-tech idea, nevermind the power per bit, WATTS/bit! Nevermind, also, the $/bit.

  These festive bulbs are actually specified in the manual (!) ($1!) as 6V 0.48W. Math: 75ohms hot, 5ohms cold. These numbers are darn-near spot-on for the sims I'd been running.

  But, of course, they're tiny in comparison, and have a comparatively tiny heat capacity, which makes measurements difficult, and means the refresh-circuit will need to cycle quickly. (No 'scope presently!)

  Am-thinking of an AVR circuit to measure the characteristics... Which, then, is just a fancy logging ohm-meter with a synchronized "charger"... Heat the bulb, measure the resistance (inductance? thermocouple voltage?!) as it cools.

  And then.., since that's essentially the refresh/read circuit, why not just implement the whole blasted rotating-drum multiplexer, and the write-select rotary-switch (2-pole!) and the write-complete circuitry (relayS, gateS) in the darn uC...

  and then, yahknow, the stupid uC already has 512 Bytes of RAM, so who needs incandescent-RAM anyhow?

  ...

  But that's an aside... I don't have relayS (mayyybe one) with me, so if I'mma do this, a uC is a good proof-of-concept, if y'all would believe it's doing what I claim and not just twiddling GPIOs from internal RAM...

  ...

  Next thing:

  Turns out this isn't really RAM at all... it's only 1/2RA-Memory; Writing is random, but reading is sequential-access.

  This just won't do!

  So, debating a new relay-circuit...

  AND, I think if I implement Read and Write in the same circuit, separate from Refresh, then things will actually get cleaner/simpler.

  Then write-complete-testing is no longer reliant on synchronization with the refresh circuit, which might remove quite a few gates and maybe a few relay/switch poles.

  Duh.(?)

View all 18 project logs