--- Log opened Thu Oct 06 00:00:39 2022
02:09 -!- qnexvr [~darsie@84-113-55-200.cable.dynamic.surfer.at] has joined #hplusroadmap
02:22 < juri_> lsneff: these are the problems you want. enjoy them. ;)
02:31 < lkcl> muurkha, it's absolutely astonishing, isn't it? this was *1961* - Cray and Thornton actually had to wait for the low-cost transistor to be invented before they could manufacture it
02:31 < lkcl> and it's still the largest single order in the world of NPN transistors (several million)
02:32 < lkcl> Mitch Alsup only just noticed a couple of years ago that the FPU was a 2-stage pipeline design
02:33 < lkcl> one thing that i didn't appreciate for some considerable time is how closely the 6600 scoreboards rely on rising- and falling- edge clocks
02:33 < lkcl> i knew that the regfiles are read-on-rising and write-on-falling
02:34 < lkcl> but the scoreboards use AND-with-clock to initiate (or reset) some of the SR-Latches
02:34 < lkcl> saving vast numbers of gates
02:35 < lkcl> (there's no DFFs - which are 10 gates - at all - it's all SR-Latches which are only 2 transistors)
03:41 -!- qnexvr [~darsie@84-113-55-200.cable.dynamic.surfer.at] has quit [Ping timeout: 250 seconds]
04:21 -!- codaraxis___ [~codaraxis@user/codaraxis] has quit [Ping timeout: 265 seconds]
04:43 -!- cpopell [sid506802@id-506802.tinside.irccloud.com] has quit [Read error: Connection reset by peer]
04:43 -!- cpopell [sid506802@id-506802.tinside.irccloud.com] has joined #hplusroadmap
05:10 -!- yashgaroth [~ffffffff@2601:5c4:c780:6aa0::1909] has joined #hplusroadmap
05:10 < kanzure> hmph
05:12 -!- codaraxis [~codaraxis@user/codaraxis] has joined #hplusroadmap
05:21 -!- codaraxis [~codaraxis@user/codaraxis] has quit [Read error: Connection reset by peer]
05:21 -!- codaraxis [~codaraxis@user/codaraxis] has joined #hplusroadmap
05:49 -!- L29Ah [~L29Ah@wikipedia/L29Ah] has quit [Ping timeout: 268 seconds]
07:00 < lsneff> juri_: :)
07:14 < kanzure> music https://www.youtube.com/watch?v=GkBaNf-Sapw
07:14 < Muaddib> [GkBaNf-Sapw] Cell Live in "The Place" club Saint Petersburg 2011 (96:09)
07:18 < muurkha> lkcl: do you have good sources on the chronology?  all I really know about the design timeline is that they announced the thing in 01964 and shipped it in 01965
07:19 < muurkha> there are lots of ways of building DFFs and most of them are less than 10 gates
07:20 < muurkha> (this is a little slow to dig into in that timeframe because it was common to use the term "flip-flop" to mean "S-R latch")
07:23 < muurkha> depending on context, I think it's a little bit unfair to count an SR latch as only two transistors.  the two-transistor circuit is bistable (or can be, anyway) but doesn't contain any way to change its state.  you may be able to build the necessary drive strength to change the state into some other transistors, but often you need two more transistors to provide it
07:24 < muurkha> debugging the timing on that design must have been a bear (perhaps why CDC remained the supercomputing champion for years)
07:26 -!- L29Ah [~L29Ah@wikipedia/L29Ah] has joined #hplusroadmap
07:47 < lkcl> muurkha, much worse than that, there was no IEEE91, they used ECL logic for all schematics!
07:48 < muurkha> you have the schematics?
07:48 < lkcl> they're in the book
07:48 < muurkha> Thornton's 01970 book?
07:48 < lkcl> yyep
07:50 < muurkha> the book says they used "DCTL", which looks like RTL to me
07:52 < muurkha> I don't see anything about ECL in it
07:52 < lkcl> squares and circles.  i'm v. busy.
07:53 < lkcl> haven't looked at the book for 12+ months, you'll have to bear in mind i'm going from memory
08:14 < kanzure> "Modular, programmable RNA sensing using ADAR editing in living cells" https://www.nature.com/articles/s41587-022-01493-x
08:14 < kanzure> https://twitter.com/ElliotHershberg/status/1577766742603878401
08:14 < muurkha> ECL did exist, Stretch used it
09:09 < kanzure> .botsnack
09:12 < kanzure> muurkha: have you seen https://fennetic.net/machines/WishList.html
09:20 < muurkha> nope.  fenn, what's the current status of Made from Scratch?
09:21 < muurkha> lots of neat ideas
09:31 < muurkha> pages like https://fennetic.net/machines/patternmaking.html seem to be composed of text from different authors, one of whom capitalizes and punctuates, and contains no experience reports, so it's sort of unclear how much of it is things that are known to work (and under what circumstances) and how much of it is things that would be interesting to try
09:35 < muurkha> on https://fennetic.net/machines/encoders.html, how large was the absolute error in the laser-printed encoder dics?   were inkjet printouts more accurate, as would be expected?
09:53 < fenn> note that the wiki was last updated in 2009
09:54 < fenn> i didn't measure absolute error
09:55 < fenn> does inkjet even work on transparency film?
09:56 < fenn> attachments are broken, unsurprisingly. they can be found in here https://fennetic.net/machines/images/
09:57 < fenn> here's a scan of a laser printed encoder (on paper) https://fennetic.net/machines/images/encoder-60mm-256lines.jpg
09:58 < fenn> if you use a moire mask and an out of focus sensor, it should average the error over several lines at once, so that helps with one class of error anyway
09:59 < fenn> as well as increasing your effective resolution since you get an analog signal instead of a square wave
09:59 < fenn> (i haven't actually used this concept in a motion control system)
10:02 < fenn> the patternmaking page was all written by me
11:15 -!- qnexvr [~darsie@84-113-55-200.cable.dynamic.surfer.at] has joined #hplusroadmap
11:20 -!- spaceangel [~spaceange@ip-78-102-216-202.bb.vodafone.cz] has joined #hplusroadmap
11:23 < heath> https://hackaday.com/2022/10/01/dvd-drives-turned-into-microscopes/#comment-6518111
11:32 < fenn> (pasting the above comment here for posterity)
11:32 < fenn>  Edwin Hwu says:
11:32 < fenn> The optical pickup unit (OPU) can do not only 3D scan….but 3D printing…
11:32 < fenn> Micro and nanoscale 3D printing using OPU from a gaming console (https://www.nature.com/articles/s42005-021-00532-4)
11:32 < fenn> Using DVD OPU for 0.000000001 to 1 Newton force measurement:
11:32 < fenn> https://www.sciencedirect.com/science/article/pii/S2468067222000530
11:32 < fenn> Using DVD OPU for atomic resolution scanning probe microscope
11:32 < fenn> https://iopscience.iop.org/article/10.1088/0957-0233/20/8/084005/meta
11:32 < fenn> Hacking CD/DVD/Blu-ray for biosensing
11:32 < fenn> https://pubs.acs.org/doi/full/10.1021%2Facssensors.8b00340
11:32 < fenn> .t https://youtu.be/5bqujaldaCQ
11:32 < saxo> Hacking CD/DVD/Blu-ray Optical Pickup Unit (OPU) for Fun and Scientific Research - YouTube
11:32 < Muaddib> [5bqujaldaCQ] Hacking CD/DVD/Blu-ray Optical Pickup Unit (OPU) for Fun and Scientific Research (9:14)
11:33 < fenn> i wish at least one of these bots would include the youtube channel name
11:34 < fenn> (Edwin Hwu)
11:39 < fenn> 'I believe that this technology can be applied to laser fault injection attacks on LSI. By controlling the lighting timing of the laser, it may be possible to “invert only a specific bit of memory at an arbitrary timing”.
11:50 < muurkha> there is transparency film that works with inkjet. I think it's actually easier to find than transparency film that works with laser printers because it doesn't have to be heat-tolerant
11:50 < muurkha> it just needs a hydrophilic surface so the ink doesn't bead up
11:56 < muurkha> I think getting a square wave is much better than getting an analog signal under most circumstances because it makes your positional precision dependent on your clock error (±10 ppm typically) instead of your error in measuring illuminance (±1000 ppm if you're lucky, ±500'000 ppm unfortunately often)
11:57 < fenn> i remember having a bad time with inkjet on transparency film, it would bead up and not dry
11:57 < fenn> probably i was not using the correct film
11:57 < muurkha> yeah, there are films that won't work
11:59 < fenn> for moving slowly on one axis, as is typical in diagonal moves on a CNC machine (such as when tracing a smooth curve), analog is preferable. quantization errors that don't sound so bad in terms of part tolerances are suddenly a big glitchy mess when used to regulate velocity, so much so that many older CNC machines had analog "tachometers" which were exclusively for measuring velocity at low
11:59 < fenn> speeds
11:59 < muurkha> yes, that's a case where analog can be preferable
12:00 < fenn> now the approach is to go wild with encoder resolution i guess
12:00 < fenn> if you're decoding quadrature in software with an AVR you can't really do that though
12:00 < muurkha> untreated cellulose acetate or PET film is not very hydrophilic.  I wrote a Wikipedia article about this actually
12:01 < fenn> i didn't want to use a PIC with special purpose quadrature decoder hardware, because it was another thing to learn
12:01 < muurkha> https://en.wikipedia.org/wiki/Drafting_film
12:04 < muurkha> as I understand it, regulating velocities is the case where edge timing can give you much better information than smoothly varying analog levels like the ones that drive a DRO (whether capacitive, glass, or magnetic)
12:05 < muurkha> the problem with edge timing is that when an axis is stopped you don't get any edges so you don't know where it's stopped in between two edges
12:05 < fenn> when it's slowly moving you don't get any edges either
12:06 < muurkha> right, if it's slow enough
12:06 < muurkha> but when you're in motion, the timing of the edge transition gives you extremely precise information about when the axis was at a particular point, which gives you extremely precise velocity information
12:06 < muurkha> average, at any rate
12:06 < muurkha> I guess I should try some of this stuf and see what I can get to work
12:07 < muurkha> *f
12:09 < muurkha> a different source of error is the random deviation in any particular screw thread or sensor line, which you can reduce by averaging over many lines (whether with moiré or with another approach; cheap-shit digital calipers use a differential capacitive moral equivalent of moiré)
12:09 < muurkha> that averaging necessarily gives you an analog signal instead of sharp edges
12:11 < fenn> i was excited about this because it didn't require any fancy optics to get an incredibly good output signal
12:12 < fenn> vs the typical quadrature sensor which has a high magnification lens and slit
12:12 < muurkha> I think a typical quadrature sensor just has a slit ;)
12:12 < muurkha> it's an interesting idea!  I've explored moiré for positional sensing a little bit
12:13 < fenn> there are some amazingly low resolution optical encoders out there, i'm not sure what people expect to do with them
12:14 < fenn> e.g. https://hardware-cnc.nl/wp-content/uploads/2020/10/Encoder2-1.jpg
12:15 < fenn> "The encoders can be easily mounted in front of your Lathe’s spindle pulley to provide full quadrature encoder signals for multi pass threading."
12:15 < fenn> i guess the spindle has enough rotational inertia that you can rely timing precision
12:15 < fenn> i wouldn't trust it
12:16 -!- L29Ah [~L29Ah@wikipedia/L29Ah] has left #hplusroadmap []
12:17 < fenn> https://docs.masso.com.au/wiring-and-setup/setup-and-calibration/masso-optical-encoder
12:20 < fenn> good lord there's still not a generic standardized g-code dialect for CAM output
12:22 < fenn> rely on*
12:23 < muurkha> yeah, the 3-D printer explosion has kind of made that worse
12:24 < muurkha> some popular 3-D printer firmwares repurpose standard G-code commands for totally unrelated purposes
12:24 < muurkha> name collisions happen more often when you name your commands things like M300 I guess
12:26 < muurkha> if you're using a rotational encoder on a system with backlash, it's common that the backlash is the limiting factor in precision, not the encoder.  I suspect what's what's going on here
12:27 < muurkha> and as that page points out, transmitting a 1 MHz quadrature signal is not as easy as transmitting a 1 kHz quadrature signal
12:29 < fenn> ideally you'd mount the pulse counter directly to the sensor diode
12:29 < fenn> then talk to it over some robust serial protocol
12:30 < muurkha> that is certainly a thing you can do and it avoids the problem of insufficiently fast optocouplers or whatever
12:30 < fenn> there is still the issue of noise getting into the power lines and ground loops or RF or whatever disrupting the counter itself
12:31 < fenn> fast AND precise is harder than one or the other
12:31 < fenn> often it's good enough to have a fast mode and a slow mode
12:32 < muurkha> for encoders? or are you speaking about a broader context?
12:32 < fenn> for encoders, in the context of motion control such as cnc machines
12:33 < fenn> a higher resolution encoder means you can only use so much dumb analog filtering before you blur out the square wave signal itself
12:33 < muurkha> makes sense
12:34 < muurkha> so in slow mode you low-pass filter more aggressively to get a more precise position?
12:34 < fenn> you could have two optical encoders in parallel with wildly different resolutions, so that at high RPMs when the high resolution encoder is blurred out, you still have the low resolution signal for coarse positioning, for doing rapid positioning moves
12:35 < muurkha> your crucible page reminds me that I finally found a place to buy silicon carbide.  and, as it happens, ruby by the kilo
12:35 < fenn> garnet*
12:36 < muurkha> they have garnet too, yeah
12:36 < fenn> sapphire!
12:36 < muurkha> it's not sapphire when it's colored red with a little chromia
12:36 < fenn> i just think it's funny, all these gemstone names for what's basically the same substance
12:36 < muurkha> garnet is a different, softer compound
12:36 < muurkha> .wik Garnet
12:36 < saxo> "Garnets ( /ˈɡɑːrnɪt/) are a group of silicate minerals that have been used since the Bronze Age as gemstones and abrasives. /  All species of garnets possess similar physical properties and crystal forms, but differ in chemical composition." - https://en.wikipedia.org/wiki/Garnet
12:37 < fenn> huh ok my bad
12:37 < muurkha> a thing I've been thinking about is using "pseudo-noise" signals like LFSR M-sequences for positional feedback, there are a variety of ways this can work
12:38 < muurkha> one of them is to print the pseudo-noise signal around the rim of a disc like the Masso disc's alternating stripes
12:38 < muurkha> and sense it with two optical sensors, same as you do for a quadrature encoder
12:38 < nmz787> how do I get someone to get this compiled and/or running and package it into a VM image (vbox seems easier for me than docker, since I've never *directly* used docker) https://github.com/chrische-xx/mpw7
12:39 < muurkha> docker is probably actually easier ;) if it's possible at all
12:39 < nmz787> why do say "IF"?
12:40 < muurkha> well, Docker isn't very good at running X11 applications.  I haven't seen it done successfully
12:40 < nmz787> ok, thus vbox
12:40 < muurkha> it's been a year or two since I tried
12:40 < nmz787> a monkey could open a vbox image and boot it up
12:40 < muurkha> and of course you can't run, say, Windows or MacOS applications in docker either
12:40 < muurkha> yeah, the same is true of docker!
12:41 < nmz787> idk about that
12:41 < muurkha> but there are things you just can't do in a docker image
12:41 < nmz787> I tried using docker at least once and got annoying and never tried again.... like 5 years ago
12:41 < fenn> muurkha: that was the idea behind "CHEAP-ENC V1.0" on https://fennetic.net/machines/encoders.html see also https://fennetic.net/machines/import/encoderdesign4b.pdf
12:41 < muurkha> cool!
12:42 < muurkha> I missed the bit about pseudo-random codes
12:42 < muurkha> the disadvantage of a pseudo-noise code of course is that, at the same resolution, you don't have as many edges, and occasionally there's a long run of a single bit
12:43 < fenn> you can curate the "noise" symbols so that you don't have those problems
12:43 < fenn> like a gray code gets around both of those i think
12:44 < muurkha> you can't avoid the problem of not having as many edges; the sequence 0101010101... is unique up to shifts in having that many edges
12:44 < muurkha> any deviation reduces the number of edges
12:44 < fenn> yes but you can avoid having 3 1's in a row
12:44 < fenn> or 3 0's
12:44 < muurkha> yes, but let's suppose you don't do that for the time being
12:45 < muurkha> one potential advantage is that you can still tell where you are when all the edges are blurred out because the signal energy is evenly distributed over the whole spectrum
12:45 < muurkha> including the low frequencies
12:45 < muurkha> another one is that, as you point out, it gives you an absolute position
12:47 < muurkha> a third is that you can get by with a single sensor instead of two, although it may take a few edges to notice a reversal of direction
12:49 < muurkha> the CHEAP-ENC seems to go to the other extreme: instead of two phototransistors it has 132 photodiodes and 5 LEDs
12:49 -!- L29Ah [~L29Ah@wikipedia/L29Ah] has joined #hplusroadmap
12:50 < muurkha> snarfed design doc from https://web.archive.org/web/20061113115434/http://www.taosinc.com/downloads/pdf/encoderdesign4b.pdf
12:50 < fenn> you'd need a fancy code scheme to notice reversal in only a few edges
12:51 < fenn> heh yeah i considered pasting the wayback machine link in case my site goes down
12:51 < fenn> manchester code, not gray code
12:52 < muurkha> manchester code multiplies your signal by a (signed) square wave, which upconverts it to the top of your frequency domain
12:55 < muurkha> this moves a signal that was previously entirely in the lower half of your frequency domain to the upper half
12:55 < muurkha> this is bad if you are trying to be robust against high-pass filtering
12:55 < muurkha> but it's true that it does ensure lots of transitions to give you lots of timing precision!
12:59 < muurkha> I think detecting reversal is trivial if you know the speed (for example because you have another clock track, like the CHEAP-ENC) but detecting speed changes is potentially much more difficult.  Steve Mann's "chirplet transform" seems like it might be relevant
13:02 < fenn> it would be trivial with a linear optical sensor
13:05 < fenn> with a single pseudorandom code reading diode, and a clock track, you'd have to constantly be evaluating several possible reversal points in the code stream, and comparing them to what you actually see, and also be robust against noise
13:16 < muurkha> still, that's just a particle filter
13:16 < muurkha> just like roboticists use for SLAM
13:56 -!- catern [~sbaugh@2604:2000:8fc0:b:a9c7:866a:bf36:3407] has quit [Ping timeout: 246 seconds]
14:24 -!- luna_ [~luna@2a01:4c8:b1:a5a4:d8cf:fba9:4db8:863a] has joined #hplusroadmap
14:24 -!- luna_ [~luna@2a01:4c8:b1:a5a4:d8cf:fba9:4db8:863a] has quit [Changing host]
14:24 -!- luna_ [~luna@user/luna/x-4729771] has joined #hplusroadmap
15:35 -!- Gooberpatrol66 [~Gooberpat@user/gooberpatrol66] has quit [Remote host closed the connection]
15:41 -!- Gooberpatrol66 [~Gooberpat@user/gooberpatrol66] has joined #hplusroadmap
15:59 -!- spaceangel [~spaceange@ip-78-102-216-202.bb.vodafone.cz] has quit [Remote host closed the connection]
16:10 -!- catern [~sbaugh@2604:2000:8fc0:b:a9c7:866a:bf36:3407] has joined #hplusroadmap
16:30 -!- pookahbeeerrr [~pookahbee@2601:643:8c80:860:6544:e598:e95c:c82e] has joined #hplusroadmap
16:31 < pookahbeeerrr> Is there a defacto python lib to input a DNA sequence and get out "Open Reading Frames" from that sequence?
16:33 < kanzure> biopython might have something for that
16:33 < kanzure> .tw https://twitter.com/shaneguML/status/1578074709102497792
16:33 < saxo> Reviewer 2: “this is great work. I reimplemented it and deployed and got 1 million users in 2 weeks. Then founded a startup and got $5M funding. I recommend a weak accept” https://twitter.com/_arohan_/status/1578058662295109647 (@shaneguML)
16:37 < muurkha> .tw
16:37 < saxo> Amazing! I was predicting a good version would take at-least a few months. // (Meanwhile conference is still in reviewer matching mode) https://twitter.com/_akhaliq/status/1578035919403503616 (@_arohan_)
16:37 < muurkha> .tw
16:37 < saxo> A implementation of text-to-3D dreamfusion, powered by stable diffusion // github: https://github.com/ashawkey/stable-dreamfusion https://video.twimg.com/ext_tw_video/1578035808308965379/pu/vid/366x360/EFxWCzJjjGfpwCSl.mp4?tag=12 (@_akhaliq)
16:43 -!- pookahbeeerrr [~pookahbee@2601:643:8c80:860:6544:e598:e95c:c82e] has quit [Quit: Client closed]
17:44 -!- qnexvr [~darsie@84-113-55-200.cable.dynamic.surfer.at] has quit [Ping timeout: 265 seconds]
18:46 -!- yashgaroth [~ffffffff@2601:5c4:c780:6aa0::1909] has quit [Quit: Leaving]
19:51 < heath> https://news.ycombinator.com/item?id=33109979%20VisionFive%202%20RISC-V%20single-board%20computer%20is%20up%20for%20pre-order
19:51 < muurkha> .t
19:51 < saxo> No title found
19:52 < heath> oops
19:53 < heath> https://news.ycombinator.com/item?id=33109979 VisionFive 2 RISC-V single-board computer is up for pre-order
19:53 < muurkha> .t
19:53 < saxo> VisionFive 2 RISC-V single-board computer is up for pre-order for $56 and up | Hacker News
23:35 -!- Malvolio [~Malvolio@idlerpg/player/Malvolio] has quit [Ping timeout: 265 seconds]
23:42 -!- Malvolio [~Malvolio@idlerpg/player/Malvolio] has joined #hplusroadmap
--- Log closed Fri Oct 07 00:00:40 2022