Day changed to 2025-06-01
[22:00] nekoluce: happy first of june :D
[22:17] jfw: thanks nekoluce
Day changed to 2025-06-03
[23:39] jfw: a sad lil loss of innocence: I'd read that the PIC12 runs up to 8 MHz from an internal or 20 MHz from an external oscillator, and "all single-cycle instructions except branches", so I thought wow, it can run an honest 20 million instructions per second. 45 pages into the datasheet, I learn almost accidentally that the "internal instruction cycle clock" is actually 1/4 of the oscillator frequency.
Day changed to 2025-06-05
[18:42] jfw: http://jfxpt.com/2025/jwrd-logs-for-May-2025/#14582 - and just over a week later, my PIC12 says "hello, world" in the form of a ~4 Hz blinking LED, running a 21-word hand-assembled program.
[18:42] sourcerer: 2025-05-28 15:56:46 (#jwrd) jfw: managed to read out the contents of my PIC12, through a $5 locally sourced FTDI adapter board, after designing & building the "extra circuitry" for high-voltage programming which the fpicprog dude wasn't kind enough to describe in his docs.
[18:53] jfw: I'm rather annoyed with the "Intel HEX" format that fpicprog adopted for god knows why; neither human readable nor human editable (because it enforces checksums too) so might as well be a raw binary.
[18:55] jfw: I'm guessing the Microchip tools used it too so he's just following along. With a little extra code I can treat it as an opaque intermediary and not really have to touch it any further.
[18:55] jfw: nothing about the chip itself requires it.
[18:57] jfw: and rolling one's own assembler doesn't look too bad at all
Day changed to 2025-06-06
[18:33] jfw: or maybe I can use https://gputils.sourceforge.io/
[18:37] jfw: which is nowhere in the first 2 pages of google or duckduckgo hits for 'free pic assembler' despite being obviously more relevant than any of those that did make it. cute how that appeasement strategy, "let's implement letsencrypt so google doesn't fuck us" worked out for them
Day changed to 2025-06-08
[03:24] jfw: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14600 - I should emphasize that this my first progam worked *on the first try* - high praise I'd say for the hardware's documentation "datasheet", for whatever minor warts it might have. the same can't be said for any step taken with any of the software items involved.
[03:24] sourcerer: 2025-06-05 18:42:32 (#jwrd) jfw: http://jfxpt.com/2025/jwrd-logs-for-May-2025/#14582 - and just over a week later, my PIC12 says "hello, world" in the form of a ~4 Hz blinking LED, running a 21-word hand-assembled program.
[03:32] jfw: gpasm for instance has been repeatedly punishing me for attempting to RTFM. first "we don't have a normal manual, read the PDF". so I check the PDF and it's got tables overflowing out of the bounding box of the simulated page. I grab the latest unversioned one from their site; looks better but still one overflowing. has a 'print' table of
[03:32] sourcerer: 2025-06-06 18:33:53 (#jwrd) jfw: or maybe I can use https://gputils.sourceforge.io/
[03:32] jfw: contents but nothing clickable and no PDF style sidebar navigation. buncha space wasted on inane error message "explanations" in the vein of: "114 Divide by zero" => "gpasm encountered a divide by zero"
[03:37] jfw: I worked out a couple reasonable details by trial-and-error like selecting the processor and including a standard header to get the register mnemonics defined, but even being familiar with the full instruction set of the processor and having studied their syntax & file structuring info, this still wasn't enough to produce a "valid" program in its view
[03:41] jfw: no, somehow I'm supposed to know that I have to end the program with an "END" directive, corresponding to no actual instruction nor any corresponding "start", apparently purely redundant with the end-of-file and existing purely to avoid an "Illegal condition: EOF encountered before END." Then it still spews warnings, "Message[302] Register in operand not in bank 0. Ensure that bank bits are
[03:41] jfw: correct", even going on to incorrectly list the state of my bank bits.
[03:52] jfw: unless it simply means that the bank bit is set in the literal register address, which it is because that's how it's defined in that standard include file for the PIC in question.
[04:02] jfw: again thanks to intel hex format I can't directly compare the results (different line wrapping), but the disassembly listing comes out matching the handwritten version.
[04:14] jfw: the CONFIG directive really wants to be helpful but didn't work as expected and isn't otherwise explained.
[04:20] jfw: but works when spelled as __CONFIG.
[04:39] jfw: anyways, good news is now those hurdles are cleared, I can write more complex PIC programs and don't have to write an assembler.
[19:51] jfw: http://jfxpt.com/paste/kcg7dxa75x - a 'hello world' of UART transmission, also worked on first try!
[20:09] jfw: http://jfxpt.com/paste/unh2y8jcgm - corrected, removing a stray 'bsf' (left from an aborted attempt at further code deflation). still works.
[20:13] jfw: the sending baud rate and its quantization wrt the PIC clock is hardcoded because the onboard oscillator doesn't evenly divide down to the standard rates, lacking a factor of 3.
[20:16] jfw: if I add a receive routine, then among the many fun possibilities there's replacing the FTDI based programmer with a PIC based one - bootstrapping and cutting the ftdi-ubuntu-libusb-libfti-fpicprog dependencies.
Day changed to 2025-06-09
[03:47] jfw: UART receiver up and running - I've got half-duplex comms!
[14:51] jfw: !E view-height
[14:52] jfw: !e view-height
[14:52] btcexplorer: block_height: 900491
[14:52] btcexplorer: mins_since_last_block: -40
[14:52] jfw: belated happy block 900k, bitcoin
[18:08] jfw: got me a 1-bit, 500kHz PICscilloscope. here's its view of the FG noise source. this is before all the edge-timing and debiasing steps, so not directly fatal that it's showing longer flat runs than one might expect - but I think interesting nonetheless and plausible in light of some prior poking
[18:11] jfw: like most digital oscilloscopes, the sample recording goes faster than the I/O can keep up, so it's not one contiguous waveform but a series with gaps.
[18:32] jfw: it has a 10-bit ADC so I could have it measure analog signals too, but the time per bit can't go much lower so it'd only be around 1/10 the sample rate.
[18:35] jfw: the digital sampling can probably go up to 2.5MHz if I add an external resonator or oscillator module.
[18:44] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14600 -- nice, congrats !
[18:44] sourcerer: 2025-06-05 18:42:32 (#jwrd) jfw: http://jfxpt.com/2025/jwrd-logs-for-May-2025/#14582 - and just over a week later, my PIC12 says "hello, world" in the form of a ~4 Hz blinking LED, running a 21-word hand-assembled program.
[18:46] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14607 -- that appeasement was sooo last decade, the new appeasement is machine generated content, humans can get lost.
[18:46] sourcerer: 2025-06-06 18:37:50 (#jwrd) jfw: which is nowhere in the first 2 pages of google or duckduckgo hits for 'free pic assembler' despite being obviously more relevant than any of those that did make it. cute how that appeasement strategy, "let's implement letsencrypt so google doesn't fuck us" worked out for them
[18:47] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14608 -- nice.
[18:47] sourcerer: 2025-06-08 03:24:13 (#jwrd) jfw: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14600 - I should emphasize that this my first progam worked *on the first try* - high praise I'd say for the hardware's documentation "datasheet", for whatever minor warts it might have. the same can't be said for any step taken with any of the software items involved.
[18:48] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14610 -- html so much harder than msword or something...
[18:48] sourcerer: 2025-06-08 03:32:30 (#jwrd) jfw: gpasm for instance has been repeatedly punishing me for attempting to RTFM. first "we don't have a normal manual, read the PDF". so I check the PDF and it's got tables overflowing out of the bounding box of the simulated page. I grab the latest unversioned one from their site; looks better but still one overflo
[18:50] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14614 -- when's the last time you updated your mind reading firmware ?
[18:50] sourcerer: 2025-06-08 03:41:21 (#jwrd) jfw: no, somehow I'm supposed to know that I have to end the program with an "END" directive, corresponding to no actual instruction nor any corresponding "start", apparently purely redundant with the end-of-file and existing purely to avoid an "Illegal condition: EOF encountered before END." Then it still spews warnings, "Message[302] Register in operand not in bank 0.
[18:50] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14619 -- nuts.
[18:50] sourcerer: 2025-06-08 04:20:54 (#jwrd) jfw: but works when spelled as __CONFIG.
[18:55] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14620 -- win.
[18:55] sourcerer: 2025-06-08 04:39:59 (#jwrd) jfw: anyways, good news is now those hurdles are cleared, I can write more complex PIC programs and don't have to write an assembler.
[18:56] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14622 -- that's slick.
[18:56] sourcerer: 2025-06-08 20:09:31 (#jwrd) jfw: http://jfxpt.com/paste/unh2y8jcgm - corrected, removing a stray 'bsf' (left from an aborted attempt at further code deflation). still works.
[18:57] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14624 -- the loveable terrorist.
[18:57] sourcerer: 2025-06-08 20:16:58 (#jwrd) jfw: if I add a receive routine, then among the many fun possibilities there's replacing the FTDI based programmer with a PIC based one - bootstrapping and cutting the ftdi-ubuntu-libusb-libfti-fpicprog dependencies.
[18:59] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14631 -- pretty cool.
[18:59] sourcerer: 2025-06-09 18:08:20 (#jwrd) jfw: got me a 1-bit, 500kHz PICscilloscope. here's its view of the FG noise source. this is before all the edge-timing and debiasing steps, so not directly fatal that it's showing longer flat runs than one might expect - but I think interesting nonetheless and plausible in light of some prior poki
[19:07] dorion: nekoluce, you back to writing in comments rather than directly in the channel again ? no big deal and better than nothing, just got a chuckled out of it.
[19:45] jfw: heh, sounds like nekoluce's irc client is slumbering while dorion's was merely napping.
[19:56] jfw: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14643 - if it updates then it must be more like mind writing firmware
[19:56] sourcerer: 2025-06-09 18:50:01 (#jwrd) dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14614 -- when's the last time you updated your mind reading firmware ?
[20:00] jfw: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14624 - current thinking is that this might be handy for my own process, but the general recipe for bootstrapping from what's around seems like the more valuable item from the verifiability standpoint. suppose you don't trust your JWRD RNG's programming (as you perhaps shouldn't, if it went through the mail). so you order the JWRD programmer, through
[20:00] sourcerer: 2025-06-08 20:16:58 (#jwrd) jfw: if I add a receive routine, then among the many fun possibilities there's replacing the FTDI based programmer with a PIC based one - bootstrapping and cutting the ftdi-ubuntu-libusb-libfti-fpicprog dependencies.
[20:00] jfw: the same route... now you have two untrusted black boxes.
[20:07] jfw: it's not that the FTDI chip is immune, but the fact that you can get it on a breakout board from various vendors through various channels, map the pins however you want and so forth, arguably makes it a lot costlier to attack the process. of course by the same coin of "non-standard" it makes the process itself costlier and perhaps less likely to be completed.
[20:10] jfw: Thompson's C compiler virus makes a fine illustration of how you'd bug the programmer to fib about the trng's and its own code while appearing to work otherwise.
[20:13] jfw: then again, one could simply get the programmer through a more trusted chain of custody then use it to verify however many future units in the field, like how a preshared key in a trusted channel enables future secrecy in an untrusted one.
[20:34] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14657 -- heh, troo.
[20:34] sourcerer: 2025-06-09 19:56:08 (#jwrd) jfw: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14643 - if it updates then it must be more like mind writing firmware
[20:35] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14659 -- that's a good point.
[20:35] sourcerer: 2025-06-09 20:00:22 (#jwrd) jfw: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14624 - current thinking is that this might be handy for my own process, but the general recipe for bootstrapping from what's around seems like the more valuable item from the verifiability standpoint. suppose you don't trust your JWRD RNG's programming (as you perhaps shouldn't, if it went through the mail). so you ord
Day changed to 2025-06-10
[05:58] lru: jfw: looks like you're having some fun over there! mmmmmm, firmware... gotta love it
[06:00] lru: yeah, I seem to recall that there were two very common binary formats in the firmware world... one intel hex, and the other maybe Motorola S record? it's been a minute since I was burning EEPROM chips for firmware testing
[06:02] lru: I may have missed the original announcement, but what is the job you have for these PIC devices?
[17:21] jfw: lru: I guess the general view is I'm working on becoming dangerous with hardware, being as it is fundamentally upstream of software. the juiciest goal at the moment is verifiable random number generation
[17:22] jfw: for my curiousity, how do you define "firmware"?
[17:23] jfw: (and yeah, I've been seeing that ihex is one of those "we all put up with it so we don't have to rewrite all the existing tools", schelling pointy things otherwise past its sell-by date)
[17:37] jfw: tangentially - I caught wind that there's a new push afoot in the authentication wars, called "passkeys". They're asymmetric keys, but safely neutered of the personal responsibility & empowerment aspects; your Device will hold its keys for you in its Secure Credential Storage (TPM blackbox with biometrics, PIN or the like) and you'll enroll them in your accounts using... a password, email/SMS/2FA
[17:37] jfw: backdoor, ofc, or an existing Device. Like Google & MS got jealous of Whatsapp.
[18:41] dorion: "your" Device
[19:16] lru: jfw: I would define "firmware" as software that has to care about hardware details such as: memory locations, memory types (DMA, flash, readonly, etc), non-standard peripherals (widget X is on pins 5 through 8, etc); and generally the kind of software that needs to be written to some kind of semi-permanent memory on the device or board, such as flash or EEPROM
[19:17] lru: there might be an OS layer,but if it's there, it's usually thin, or something most people have never heard about, such as QNX
[19:18] lru: sometimes the OS layer is written by the same company as made the board, or the same people who wrote the firmware.... write enough firmware and you'll have a library built up of low level utilities
[19:20] lru: my firmware days were fun days, but my hardware experience is limited.... I did some very small circuit play with an ESP32 board a few years ago tho
[19:22] lru: as for passkeys, I haven't look into it, but I'm allergic to this 2FA / MFA hysteria sweeping the industry, but I've managed to use oathtool on linux when I must have it... much better than SMS, and I have more control
[19:56] jfw: it's all about herd management; not an easy task when you think about it, trying to extract some value in an information economy out of actors incapable of protecting information.
[19:59] jfw: I did a python 10-liner to compute the TOTP codes for when I really have to, but otherwise aiming to own enough of my infrastructure so as to not need such accounts.
[20:03] jfw: as to firmware, it seems that kernels would fit the description too (the nonstandard peripheral handling they just call "device drivers"), with HDD as the semi-permanent memory (and nowadays often enough a flash SSD on the board)
[20:04] jfw: what I inferred is more like "software that we'd much rather pretend didn't exist, to be treated as opaquely as the chips it lives in, until the updates come out at which point maybe we load them and pray"
[20:07] jfw: but now that I'm shining a light into it, the "firmware" term doesn't seem of much value anymore. I see it more as working on the kind of software that isn't forced to have the fat buttprint of Intel on it
[20:22] jfw: as to the PIC specifcally, I saw it first as a cheap & stable way to get a programmable logic interface such as the PC's been missing ever since the death of the parallel port. we'd accreted a couple different magic tools for specific chip flashing purposes, like raspberrypi for Thinkpad ROMs and bus blaster (now out of production) for JTAG
[20:28] jfw: but now that I know my way around it, it seems a decent fit for any hardware application that's more demanding in reliability than in clock speed and memory
Day changed to 2025-06-11
[08:55] lru: yeah, that's what's great about firmware... less and less cruft between you and the actual job
Day changed to 2025-06-12
[20:43] jfw: dorion: I've added extraction of random bits by sampling a timer on the pulse edges, as well as von Neumann debiasing; in other words, now got something roughly comparable side-by-side with the FUCKGOATS modulator. it puts out right around 1 KB/sec, or 1/7 the FG rate, with possibly half the difference attributable to using only one noise input board so far and the rest to the lower sampling
[20:43] jfw: speed; so I might even be able to close the gap by boosting the clock speed.
[20:44] jfw: I've more or less worked out in my head why it's a plausible method of entropy collection, but there's more still to read
[20:47] jfw: as to measured output quality, it's not quite satisfactory yet; looks OK to the naked eye and gets pretty close on the arithmetic mean, bitwise or bytewise, i.e. bias is good; but entropy is only 7.893 bits/byte, chi-square and monte carlo pi are lousy, and in general reads a lot worse than the same bit count from FG.
[20:48] jfw: I'm also still using an unshielded input board and don't yet know if that might be hurting the numbers.
[20:49] jfw: I'm actually hoping it does, so that I have some way to know if the shielding is any good. otherwise might need to look for some kind of RF/EMI source to throw it off
[20:51] jfw: also haven't given much attention to power supply stability yet.
[20:55] jfw: also need to figure what's up with the serial correlation method in "ent" because it doesn't behave as I'd expect on pathological inputs
[23:48] jfw: picked up a 12 MHz quartz resonator to play with - the preferred 14.7456 for standard baud rate divisibility wasn't carried and the 20MHz to max out the PIC was out of stock.
[23:49] jfw: also a DIP-20 socket to try making a more-permanent programmer board.
[23:53] jfw: the PIC also has a Capture/Compare/PWM feature that might help by boosting the time resolution of the pulse edge detection as compared with software polling, except it might hurt just as much by having to pick only rising or falling edges
Day changed to 2025-06-13
[19:20] jfw: With a further assembly optimization I found I could squeeze 8x the record length out of the 1-bit PICoscope without loss of sample rate, making 768-bit records at 500kHz.
[19:23] jfw: Looking afresh at the raw noise source data through the lens of hex rather than bits, it seems to show significant patterns beyond just the long runs of 0s or 1s, eg improbably-long repetitions of other byte values.
[19:28] jfw: perhaps that could arise at the boundaries as the amp loop oscillates into and out of its metastable/noisy state; but it does cast doubt on the idea that there's good entropy in the timing of the pulse edges
[19:40] jfw: zooming into the TP1 subcircuit with the 768-bit window seems to lend credence to the idea; it's enough time to see the whole flatline burst in some cases. example, http://jfxpt.com/paste/ki7ni64i5y
[19:42] jfw: as it recovers, it's clearly still biased to zeros, but worse, there's a pattern of two ones, six zeros, repeat. not always but often enough.
[19:43] jfw: I'll try a shielded one soon.
Day changed to 2025-06-14
[01:53] jfw: another 768b record, hexdump format, of TP1 now with full shielding and 3.3V regulated power as provided by the fully assembled FG: http://jfxpt.com/paste/hyvugfntae
[01:54] jfw: and didn't take long to find such an example still having the obvious patterns.
[02:06] jfw: I still can't be sure if it's the noise circuit or my acquisition method that's to blame, given my sampling rate is around 14x lower than FG's. I guess I've pushed it about as far as it'll go with the PIC. Still, "one would think" that a proper noise source would still look noisy at *any* clock speed sufficiently below its highest frequency components.
[02:13] jfw: s/14x/28x/
Day changed to 2025-06-16
[15:54] jfw: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14633 - I've cracked the ADC (which is on the complicated side and the datasheet is quite confusing regarding timing, some experimentation was required); besides the minimum time per bit (ADC clock) there's also a rather sluggish "acquisition time" to allow for.
[15:54] sourcerer: 2025-06-09 18:32:57 (#jwrd) jfw: it has a 10-bit ADC so I could have it measure analog signals too, but the time per bit can't go much lower so it'd only be around 1/10 the sample rate.
[15:57] jfw: thus, the 1-bit 500kHz picoscope now has a 32kHz x 8-bit analog option, complete with CLI frontend showing the real-time sample data in hex.
[15:58] jfw: (technically those are sample rate figures, not signal bandwidth, so possibly shouldn't use Hz.)
Day changed to 2025-06-23
[00:47] nekoluce: hello
[01:54] jfw: hi nekoluce, I'm good, called the parents and otherwise having entirely too much fun with electronics and some graphics programming
[01:56] jfw: nekoluce: give eulora2 a run when you get a chance, your character should be revived now.
Day changed to 2025-06-24
[16:51] jfw: nekoluce: you need to find a way to stay connected longer for me to be able to message you
[22:00] nekoluce: happy first of june :D
[22:17] jfw: thanks nekoluce
Day changed to 2025-06-03
[23:39] jfw: a sad lil loss of innocence: I'd read that the PIC12 runs up to 8 MHz from an internal or 20 MHz from an external oscillator, and "all single-cycle instructions except branches", so I thought wow, it can run an honest 20 million instructions per second. 45 pages into the datasheet, I learn almost accidentally that the "internal instruction cycle clock" is actually 1/4 of the oscillator frequency.
Day changed to 2025-06-05
[18:42] jfw: http://jfxpt.com/2025/jwrd-logs-for-May-2025/#14582 - and just over a week later, my PIC12 says "hello, world" in the form of a ~4 Hz blinking LED, running a 21-word hand-assembled program.
[18:42] sourcerer: 2025-05-28 15:56:46 (#jwrd) jfw: managed to read out the contents of my PIC12, through a $5 locally sourced FTDI adapter board, after designing & building the "extra circuitry" for high-voltage programming which the fpicprog dude wasn't kind enough to describe in his docs.
[18:53] jfw: I'm rather annoyed with the "Intel HEX" format that fpicprog adopted for god knows why; neither human readable nor human editable (because it enforces checksums too) so might as well be a raw binary.
[18:55] jfw: I'm guessing the Microchip tools used it too so he's just following along. With a little extra code I can treat it as an opaque intermediary and not really have to touch it any further.
[18:55] jfw: nothing about the chip itself requires it.
[18:57] jfw: and rolling one's own assembler doesn't look too bad at all
Day changed to 2025-06-06
[18:33] jfw: or maybe I can use https://gputils.sourceforge.io/
[18:37] jfw: which is nowhere in the first 2 pages of google or duckduckgo hits for 'free pic assembler' despite being obviously more relevant than any of those that did make it. cute how that appeasement strategy, "let's implement letsencrypt so google doesn't fuck us" worked out for them
Day changed to 2025-06-08
[03:24] jfw: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14600 - I should emphasize that this my first progam worked *on the first try* - high praise I'd say for the hardware's documentation "datasheet", for whatever minor warts it might have. the same can't be said for any step taken with any of the software items involved.
[03:24] sourcerer: 2025-06-05 18:42:32 (#jwrd) jfw: http://jfxpt.com/2025/jwrd-logs-for-May-2025/#14582 - and just over a week later, my PIC12 says "hello, world" in the form of a ~4 Hz blinking LED, running a 21-word hand-assembled program.
[03:32] jfw: gpasm for instance has been repeatedly punishing me for attempting to RTFM. first "we don't have a normal manual, read the PDF". so I check the PDF and it's got tables overflowing out of the bounding box of the simulated page. I grab the latest unversioned one from their site; looks better but still one overflowing. has a 'print' table of
[03:32] sourcerer: 2025-06-06 18:33:53 (#jwrd) jfw: or maybe I can use https://gputils.sourceforge.io/
[03:32] jfw: contents but nothing clickable and no PDF style sidebar navigation. buncha space wasted on inane error message "explanations" in the vein of: "114 Divide by zero" => "gpasm encountered a divide by zero"
[03:37] jfw: I worked out a couple reasonable details by trial-and-error like selecting the processor and including a standard header to get the register mnemonics defined, but even being familiar with the full instruction set of the processor and having studied their syntax & file structuring info, this still wasn't enough to produce a "valid" program in its view
[03:41] jfw: no, somehow I'm supposed to know that I have to end the program with an "END" directive, corresponding to no actual instruction nor any corresponding "start", apparently purely redundant with the end-of-file and existing purely to avoid an "Illegal condition: EOF encountered before END." Then it still spews warnings, "Message[302] Register in operand not in bank 0. Ensure that bank bits are
[03:41] jfw: correct", even going on to incorrectly list the state of my bank bits.
[03:52] jfw: unless it simply means that the bank bit is set in the literal register address, which it is because that's how it's defined in that standard include file for the PIC in question.
[04:02] jfw: again thanks to intel hex format I can't directly compare the results (different line wrapping), but the disassembly listing comes out matching the handwritten version.
[04:14] jfw: the CONFIG directive really wants to be helpful but didn't work as expected and isn't otherwise explained.
[04:20] jfw: but works when spelled as __CONFIG.
[04:39] jfw: anyways, good news is now those hurdles are cleared, I can write more complex PIC programs and don't have to write an assembler.
[19:51] jfw: http://jfxpt.com/paste/kcg7dxa75x - a 'hello world' of UART transmission, also worked on first try!
[20:09] jfw: http://jfxpt.com/paste/unh2y8jcgm - corrected, removing a stray 'bsf' (left from an aborted attempt at further code deflation). still works.
[20:13] jfw: the sending baud rate and its quantization wrt the PIC clock is hardcoded because the onboard oscillator doesn't evenly divide down to the standard rates, lacking a factor of 3.
[20:16] jfw: if I add a receive routine, then among the many fun possibilities there's replacing the FTDI based programmer with a PIC based one - bootstrapping and cutting the ftdi-ubuntu-libusb-libfti-fpicprog dependencies.
Day changed to 2025-06-09
[03:47] jfw: UART receiver up and running - I've got half-duplex comms!
[14:51] jfw: !E view-height
[14:52] jfw: !e view-height
[14:52] btcexplorer: block_height: 900491
[14:52] btcexplorer: mins_since_last_block: -40
[14:52] jfw: belated happy block 900k, bitcoin
[18:08] jfw: got me a 1-bit, 500kHz PICscilloscope. here's its view of the FG noise source. this is before all the edge-timing and debiasing steps, so not directly fatal that it's showing longer flat runs than one might expect - but I think interesting nonetheless and plausible in light of some prior poking
[18:11] jfw: like most digital oscilloscopes, the sample recording goes faster than the I/O can keep up, so it's not one contiguous waveform but a series with gaps.
[18:32] jfw: it has a 10-bit ADC so I could have it measure analog signals too, but the time per bit can't go much lower so it'd only be around 1/10 the sample rate.
[18:35] jfw: the digital sampling can probably go up to 2.5MHz if I add an external resonator or oscillator module.
[18:44] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14600 -- nice, congrats !
[18:44] sourcerer: 2025-06-05 18:42:32 (#jwrd) jfw: http://jfxpt.com/2025/jwrd-logs-for-May-2025/#14582 - and just over a week later, my PIC12 says "hello, world" in the form of a ~4 Hz blinking LED, running a 21-word hand-assembled program.
[18:46] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14607 -- that appeasement was sooo last decade, the new appeasement is machine generated content, humans can get lost.
[18:46] sourcerer: 2025-06-06 18:37:50 (#jwrd) jfw: which is nowhere in the first 2 pages of google or duckduckgo hits for 'free pic assembler' despite being obviously more relevant than any of those that did make it. cute how that appeasement strategy, "let's implement letsencrypt so google doesn't fuck us" worked out for them
[18:47] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14608 -- nice.
[18:47] sourcerer: 2025-06-08 03:24:13 (#jwrd) jfw: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14600 - I should emphasize that this my first progam worked *on the first try* - high praise I'd say for the hardware's documentation "datasheet", for whatever minor warts it might have. the same can't be said for any step taken with any of the software items involved.
[18:48] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14610 -- html so much harder than msword or something...
[18:48] sourcerer: 2025-06-08 03:32:30 (#jwrd) jfw: gpasm for instance has been repeatedly punishing me for attempting to RTFM. first "we don't have a normal manual, read the PDF". so I check the PDF and it's got tables overflowing out of the bounding box of the simulated page. I grab the latest unversioned one from their site; looks better but still one overflo
[18:50] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14614 -- when's the last time you updated your mind reading firmware ?
[18:50] sourcerer: 2025-06-08 03:41:21 (#jwrd) jfw: no, somehow I'm supposed to know that I have to end the program with an "END" directive, corresponding to no actual instruction nor any corresponding "start", apparently purely redundant with the end-of-file and existing purely to avoid an "Illegal condition: EOF encountered before END." Then it still spews warnings, "Message[302] Register in operand not in bank 0.
[18:50] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14619 -- nuts.
[18:50] sourcerer: 2025-06-08 04:20:54 (#jwrd) jfw: but works when spelled as __CONFIG.
[18:55] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14620 -- win.
[18:55] sourcerer: 2025-06-08 04:39:59 (#jwrd) jfw: anyways, good news is now those hurdles are cleared, I can write more complex PIC programs and don't have to write an assembler.
[18:56] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14622 -- that's slick.
[18:56] sourcerer: 2025-06-08 20:09:31 (#jwrd) jfw: http://jfxpt.com/paste/unh2y8jcgm - corrected, removing a stray 'bsf' (left from an aborted attempt at further code deflation). still works.
[18:57] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14624 -- the loveable terrorist.
[18:57] sourcerer: 2025-06-08 20:16:58 (#jwrd) jfw: if I add a receive routine, then among the many fun possibilities there's replacing the FTDI based programmer with a PIC based one - bootstrapping and cutting the ftdi-ubuntu-libusb-libfti-fpicprog dependencies.
[18:59] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14631 -- pretty cool.
[18:59] sourcerer: 2025-06-09 18:08:20 (#jwrd) jfw: got me a 1-bit, 500kHz PICscilloscope. here's its view of the FG noise source. this is before all the edge-timing and debiasing steps, so not directly fatal that it's showing longer flat runs than one might expect - but I think interesting nonetheless and plausible in light of some prior poki
[19:07] dorion: nekoluce, you back to writing in comments rather than directly in the channel again ? no big deal and better than nothing, just got a chuckled out of it.
[19:45] jfw: heh, sounds like nekoluce's irc client is slumbering while dorion's was merely napping.
[19:56] jfw: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14643 - if it updates then it must be more like mind writing firmware
[19:56] sourcerer: 2025-06-09 18:50:01 (#jwrd) dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14614 -- when's the last time you updated your mind reading firmware ?
[20:00] jfw: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14624 - current thinking is that this might be handy for my own process, but the general recipe for bootstrapping from what's around seems like the more valuable item from the verifiability standpoint. suppose you don't trust your JWRD RNG's programming (as you perhaps shouldn't, if it went through the mail). so you order the JWRD programmer, through
[20:00] sourcerer: 2025-06-08 20:16:58 (#jwrd) jfw: if I add a receive routine, then among the many fun possibilities there's replacing the FTDI based programmer with a PIC based one - bootstrapping and cutting the ftdi-ubuntu-libusb-libfti-fpicprog dependencies.
[20:00] jfw: the same route... now you have two untrusted black boxes.
[20:07] jfw: it's not that the FTDI chip is immune, but the fact that you can get it on a breakout board from various vendors through various channels, map the pins however you want and so forth, arguably makes it a lot costlier to attack the process. of course by the same coin of "non-standard" it makes the process itself costlier and perhaps less likely to be completed.
[20:10] jfw: Thompson's C compiler virus makes a fine illustration of how you'd bug the programmer to fib about the trng's and its own code while appearing to work otherwise.
[20:13] jfw: then again, one could simply get the programmer through a more trusted chain of custody then use it to verify however many future units in the field, like how a preshared key in a trusted channel enables future secrecy in an untrusted one.
[20:34] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14657 -- heh, troo.
[20:34] sourcerer: 2025-06-09 19:56:08 (#jwrd) jfw: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14643 - if it updates then it must be more like mind writing firmware
[20:35] dorion: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14659 -- that's a good point.
[20:35] sourcerer: 2025-06-09 20:00:22 (#jwrd) jfw: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14624 - current thinking is that this might be handy for my own process, but the general recipe for bootstrapping from what's around seems like the more valuable item from the verifiability standpoint. suppose you don't trust your JWRD RNG's programming (as you perhaps shouldn't, if it went through the mail). so you ord
Day changed to 2025-06-10
[05:58] lru: jfw: looks like you're having some fun over there! mmmmmm, firmware... gotta love it
[06:00] lru: yeah, I seem to recall that there were two very common binary formats in the firmware world... one intel hex, and the other maybe Motorola S record? it's been a minute since I was burning EEPROM chips for firmware testing
[06:02] lru: I may have missed the original announcement, but what is the job you have for these PIC devices?
[17:21] jfw: lru: I guess the general view is I'm working on becoming dangerous with hardware, being as it is fundamentally upstream of software. the juiciest goal at the moment is verifiable random number generation
[17:22] jfw: for my curiousity, how do you define "firmware"?
[17:23] jfw: (and yeah, I've been seeing that ihex is one of those "we all put up with it so we don't have to rewrite all the existing tools", schelling pointy things otherwise past its sell-by date)
[17:37] jfw: tangentially - I caught wind that there's a new push afoot in the authentication wars, called "passkeys". They're asymmetric keys, but safely neutered of the personal responsibility & empowerment aspects; your Device will hold its keys for you in its Secure Credential Storage (TPM blackbox with biometrics, PIN or the like) and you'll enroll them in your accounts using... a password, email/SMS/2FA
[17:37] jfw: backdoor, ofc, or an existing Device. Like Google & MS got jealous of Whatsapp.
[18:41] dorion: "your" Device
[19:16] lru: jfw: I would define "firmware" as software that has to care about hardware details such as: memory locations, memory types (DMA, flash, readonly, etc), non-standard peripherals (widget X is on pins 5 through 8, etc); and generally the kind of software that needs to be written to some kind of semi-permanent memory on the device or board, such as flash or EEPROM
[19:17] lru: there might be an OS layer,but if it's there, it's usually thin, or something most people have never heard about, such as QNX
[19:18] lru: sometimes the OS layer is written by the same company as made the board, or the same people who wrote the firmware.... write enough firmware and you'll have a library built up of low level utilities
[19:20] lru: my firmware days were fun days, but my hardware experience is limited.... I did some very small circuit play with an ESP32 board a few years ago tho
[19:22] lru: as for passkeys, I haven't look into it, but I'm allergic to this 2FA / MFA hysteria sweeping the industry, but I've managed to use oathtool on linux when I must have it... much better than SMS, and I have more control
[19:56] jfw: it's all about herd management; not an easy task when you think about it, trying to extract some value in an information economy out of actors incapable of protecting information.
[19:59] jfw: I did a python 10-liner to compute the TOTP codes for when I really have to, but otherwise aiming to own enough of my infrastructure so as to not need such accounts.
[20:03] jfw: as to firmware, it seems that kernels would fit the description too (the nonstandard peripheral handling they just call "device drivers"), with HDD as the semi-permanent memory (and nowadays often enough a flash SSD on the board)
[20:04] jfw: what I inferred is more like "software that we'd much rather pretend didn't exist, to be treated as opaquely as the chips it lives in, until the updates come out at which point maybe we load them and pray"
[20:07] jfw: but now that I'm shining a light into it, the "firmware" term doesn't seem of much value anymore. I see it more as working on the kind of software that isn't forced to have the fat buttprint of Intel on it
[20:22] jfw: as to the PIC specifcally, I saw it first as a cheap & stable way to get a programmable logic interface such as the PC's been missing ever since the death of the parallel port. we'd accreted a couple different magic tools for specific chip flashing purposes, like raspberrypi for Thinkpad ROMs and bus blaster (now out of production) for JTAG
[20:28] jfw: but now that I know my way around it, it seems a decent fit for any hardware application that's more demanding in reliability than in clock speed and memory
Day changed to 2025-06-11
[08:55] lru: yeah, that's what's great about firmware... less and less cruft between you and the actual job
Day changed to 2025-06-12
[20:43] jfw: dorion: I've added extraction of random bits by sampling a timer on the pulse edges, as well as von Neumann debiasing; in other words, now got something roughly comparable side-by-side with the FUCKGOATS modulator. it puts out right around 1 KB/sec, or 1/7 the FG rate, with possibly half the difference attributable to using only one noise input board so far and the rest to the lower sampling
[20:43] jfw: speed; so I might even be able to close the gap by boosting the clock speed.
[20:44] jfw: I've more or less worked out in my head why it's a plausible method of entropy collection, but there's more still to read
[20:47] jfw: as to measured output quality, it's not quite satisfactory yet; looks OK to the naked eye and gets pretty close on the arithmetic mean, bitwise or bytewise, i.e. bias is good; but entropy is only 7.893 bits/byte, chi-square and monte carlo pi are lousy, and in general reads a lot worse than the same bit count from FG.
[20:48] jfw: I'm also still using an unshielded input board and don't yet know if that might be hurting the numbers.
[20:49] jfw: I'm actually hoping it does, so that I have some way to know if the shielding is any good. otherwise might need to look for some kind of RF/EMI source to throw it off
[20:51] jfw: also haven't given much attention to power supply stability yet.
[20:55] jfw: also need to figure what's up with the serial correlation method in "ent" because it doesn't behave as I'd expect on pathological inputs
[23:48] jfw: picked up a 12 MHz quartz resonator to play with - the preferred 14.7456 for standard baud rate divisibility wasn't carried and the 20MHz to max out the PIC was out of stock.
[23:49] jfw: also a DIP-20 socket to try making a more-permanent programmer board.
[23:53] jfw: the PIC also has a Capture/Compare/PWM feature that might help by boosting the time resolution of the pulse edge detection as compared with software polling, except it might hurt just as much by having to pick only rising or falling edges
Day changed to 2025-06-13
[19:20] jfw: With a further assembly optimization I found I could squeeze 8x the record length out of the 1-bit PICoscope without loss of sample rate, making 768-bit records at 500kHz.
[19:23] jfw: Looking afresh at the raw noise source data through the lens of hex rather than bits, it seems to show significant patterns beyond just the long runs of 0s or 1s, eg improbably-long repetitions of other byte values.
[19:28] jfw: perhaps that could arise at the boundaries as the amp loop oscillates into and out of its metastable/noisy state; but it does cast doubt on the idea that there's good entropy in the timing of the pulse edges
[19:40] jfw: zooming into the TP1 subcircuit with the 768-bit window seems to lend credence to the idea; it's enough time to see the whole flatline burst in some cases. example, http://jfxpt.com/paste/ki7ni64i5y
[19:42] jfw: as it recovers, it's clearly still biased to zeros, but worse, there's a pattern of two ones, six zeros, repeat. not always but often enough.
[19:43] jfw: I'll try a shielded one soon.
Day changed to 2025-06-14
[01:53] jfw: another 768b record, hexdump format, of TP1 now with full shielding and 3.3V regulated power as provided by the fully assembled FG: http://jfxpt.com/paste/hyvugfntae
[01:54] jfw: and didn't take long to find such an example still having the obvious patterns.
[02:06] jfw: I still can't be sure if it's the noise circuit or my acquisition method that's to blame, given my sampling rate is around 14x lower than FG's. I guess I've pushed it about as far as it'll go with the PIC. Still, "one would think" that a proper noise source would still look noisy at *any* clock speed sufficiently below its highest frequency components.
[02:13] jfw: s/14x/28x/
Day changed to 2025-06-16
[15:54] jfw: http://jfxpt.com/2025/jwrd-logs-for-Jun-2025/#14633 - I've cracked the ADC (which is on the complicated side and the datasheet is quite confusing regarding timing, some experimentation was required); besides the minimum time per bit (ADC clock) there's also a rather sluggish "acquisition time" to allow for.
[15:54] sourcerer: 2025-06-09 18:32:57 (#jwrd) jfw: it has a 10-bit ADC so I could have it measure analog signals too, but the time per bit can't go much lower so it'd only be around 1/10 the sample rate.
[15:57] jfw: thus, the 1-bit 500kHz picoscope now has a 32kHz x 8-bit analog option, complete with CLI frontend showing the real-time sample data in hex.
[15:58] jfw: (technically those are sample rate figures, not signal bandwidth, so possibly shouldn't use Hz.)
Day changed to 2025-06-23
[00:47] nekoluce: hello
[01:54] jfw: hi nekoluce, I'm good, called the parents and otherwise having entirely too much fun with electronics and some graphics programming
[01:56] jfw: nekoluce: give eulora2 a run when you get a chance, your character should be revived now.
Day changed to 2025-06-24
[16:51] jfw: nekoluce: you need to find a way to stay connected longer for me to be able to message you
An amazing progress JFW.Keep going !
Comment by Luz Fung — 2025-06-09 @ 00:10
Good morning
Comment by Luz Fung — 2025-06-09 @ 14:49