Dave Anderson

Software developer by day, other kinds of nerd the rest of the time. ADHD says current hobbies are 3D printers, building CNC machines, old computers in space, and general shitposting on whatever grabs my interest.

Nazis, TERFs, other terrible people: please go away, there's nothing for you here.

Follow reqs welcome from humans and other sentient entities. Please have at least some evidence of same in your profile!

ASL: 30s / he/they / BC, Canada
Homepage: https://dave.tf
Blog: https://blog.dave.tf
Cats: Two <3

Public Key

npub1mtg38agwglttl7melxnfqphlm95uymnrdedw62h9j7cyquynza0szxwant

NIP-05 Address

danderson_at_hachyderm.io@momostr.pink

Profile Code

nprofile1qqsd45gn758y044lldulnf5sqmlaj6wzde3kukhd9tje0vzqwzf3whc5ml4xt

Author Public Key

npub1mtg38agwglttl7melxnfqphlm95uymnrdedw62h9j7cyquynza0szxwant

Show more details

Last Notes

2024-08-31 02:15:23

- reply

This memory is slightly annoying in that it has a zillion possible configurations, and so far I don't see a way around just copy/pasting the testbench a zillion times and having all the ever so slightly different inputs/outputs enumerated, which is a bit of a slog.
It's _almost_ regular enough that it's tempting to write python to generate the testbenches... But having code write tests always makes me a bit nervous because what if bug in test generator

2024-08-31 02:13:40

Some test waveforms. The basic configuration of 2x18b ports seems to work, with the exception that port conflicts currently aren't handled as well as I'd like: one of the conflicting values gets picked, instead of being set to all X to make the conflict obvious. But the various other output modes seem to work, so far at least.
https://media.hachyderm.io/media_attachments/files/113/054/203/388/185/382/original/8b78d53fc5f143eb.png

2024-08-17 20:14:24

- reply

There's still some clock domain crossing gubbins to square things with the compiler in the FPGA, but sending data across clock domains of clocks that are related and phase-locked can be done with no additional delay cycles.

2024-08-10 21:30:31

- reply

I was thinking even one for both ports tbh. They're to protect the upstream rails from faults, I feel like it's okay if both controllers shut off if either faults. But 2 works as well 🙂

2024-08-10 20:58:48

- reply

Yeah if there's a reset controller that does "USB-C 3A or not 3A", that'd be ideal. It's not much circuitry, but just enough to be annoying to do by hand.
That plus a current limiter on the controller power rail, you'd have a system that draws ~0 until the reset controller is happy, then CPU/FPGA boot up, and at some point one of them brings the current limiter out of shutdown to bring up the ports as well, and voila

2024-08-05 23:33:05

- reply

And that's just the "general I/O" pins! If you get one of the ECP5s with onboard serdes, well then, have 3.2Gbps, with complimentary 8b10b coding, spat out into a manageable speed parallel bus for your logic to look at. Incredible.

2024-08-05 23:28:46

Okay I'd never looked too closely at the I/O configuration options for the ECP5 FPGAs, but it has some pretty sick stuff in there. It's mind-bending that a part accessible to a scrub like me can push north of 400MHz I/O while letting the design run at just 100MHz or what have you. Pretty swell.

2024-08-05 21:54:09

- reply

a variation of this I read somewhere re: community moderation: the culture of your community is defined entirely by the shittiest person you don't ban. Set that bar accordingly.

2024-08-05 20:45:18

- reply

true. That goes back to the old authenticity vs modernism tradeoff. Pack an entire computer into the one chip, or retain the aesthetic of the PLCC sockets and whatnot.

2024-08-05 20:42:29

- reply

yeah this all really feels like you're running up against vera's limits, rather than the limits of what a graphics core _could_ do. Still, "only" 12x faster is nothing to sneeze at.

2024-08-05 20:29:34

- reply

Yeah getting the existing core to not glitch on higher bus speeds is the big deal in the immediate term, you're right. Everything else, well... Lots of possibilities, but it's very much blue sky redesign not incremental tweaks.

2024-08-05 20:26:11

- reply

Yup absolutely. It'd be more or less starting from scratch, and importing some of the interface design and low-level blocks from vera, but much more of a clean slate build than a port.

2024-08-05 20:25:05

- reply

If I were a gentleman of leisure with the time for it, I think I'd approach it similar to the original vera design: a standalone outboard graphics adapter, with somewhat interchangeable "slow" bus interface options (so that during dev you can hook it to SPI or janky UART or something rather than needing a whole computer around it), and build it as its own little black box. But it's no small project for sure.

2024-08-05 20:20:39

- reply

I'm definitely assuming at this point that some of the inner IP cores of vera might get reused, but the top- and mid-levels would change quite drastically. That said, with some more careful design the synthesis could also clock in at a higher rate, and so be able to stay ahead of the faster CPU bus... Maybe. Olympic-level handwaving here.

2024-08-05 20:17:30

- reply

Yes, definitely. The ULX3S board has a 128MByte SRAM hooked up, it's "just" a matter of writing the RAM controller (or borrowing an existing one)

2024-08-05 20:15:38

- reply

hmm, damn, you're right, the block RAMs are smaller. Only 72KByte total on the lower end ECP5. Higher end ones have ~200kB and ~470kB respectively, but with a corresponding price bump.

2024-08-05 20:09:05

- reply

To be clear that could handle 1080p60 _analog_, at least on paper. 1080p60 digital still needs the insane TMDS/LVDS encoding that multiplies the required bitrate 10x. If there's standalone parallel<>TMDS ICs, that could maybe still work, that'd be 150MHz out from the FPGA and then the dedicated IC is doing 8b/10b encoding and squirting out the GHz signals... But I don't know the IC space here enough to know if that works.

2024-08-05 20:06:50

- reply

Hm then again no, at that kind of output rate I'd plump for one of Analog Devices's dedicated video DACs, with the 3 outputs in a single device. AD7125 for example could handle a 150MHz pixel clock just fine (assuming the board design around it isn't a mess for EMI, I've never played at those frequencies before!). I'm _fairly_ sure a carefully designed gateware could clock at those speeds too, pretty sure I've seen solutions in excess of that during synthesis.

2024-08-05 20:01:28

- reply

1080p60 in digital video is a ~1.5GHz I/O rate after the 8b/10b encoding and all that nonsense, which... that's a _lot_. The cost of video scales unintuitively quickly. I'm not sure an ECP5 could do that without the hardware serdes. The IO can be configured for LDVS differential whatnots, but... that's a tall order.
1080p60 analog is a ~150MHz pixel clock, so iiuc that wants a ~600MHz DAC. Those exist, but they're firmly in the $30-100 range per color channel.

2024-08-05 19:47:44

- reply

See the family table at https://www.latticesemi.com/Products/FPGAandCPLD/ECP5 . TQFP limits you to LFE5U-{12,25,45} parts, 98 I/Os and then increasing amounts of gates and memory/DSP blocks. No serdes blocks on the TQFP parts though, if you want I/O that runs at 3Gbps those are BGA only. My dev board is a ULX3S, which runs the LFE5U-85F. Even without the serdes silicon, it can be made to drive the more modest HDMI/DP resolutions.

2024-08-05 19:43:48

- reply

All variants are available in several variations of BGA, and the three lower-end variants are also available in 144-pin TQFP. You lose a lot of I/O that way, 98 for the TQFP vs. 197-365 for the BGAs, but compare 98 to the maxed out ice40 with 39.

2024-08-05 19:37:18

- reply

I'm not sure if I could stand to port it without rewriting the janky bits... But a straight port should actually be pretty easy, just retarget the pin mapping and figure out the magic for the PLL block configuration... ECP5 is basically a superset of ICE40 in every way so I don't think synthesis would break a sweat.
I don't have the bits and pieces to hook up output on my ECP5 board, but lemme see if I can bang yosys into producing a bitstream...

2024-08-05 19:31:05

- reply

an entry level ECP5 has 2x the gates and 3x the IO, unless I'm missing something very expensive about the glue logic, no choice required IMO. Feels like you'd need to come up with even more things to spend pins on!

2024-08-05 19:26:50

- reply

Purely in money terms, it seems worth the pain of trying to cram the three in there, although looking at the PTH prototype board, it'd definitely be... cozy. But again keep in mind I'm going down the rabbit hole of trying do make a much fancier DAC when the existing one is probably fine. Think of it more as a sort of "if v2 had an ECP5 FPGA with the extra I/O, and the goal was 16 million colors, how would I do that" :)

2024-08-05 19:23:25

- reply

One of the advantages the NA manufacturers seem to still have, is they make these DACs in QFN and BGA form factors, so you can pack a lot more for your money in a smaller space. But, alas.

2024-08-05 19:21:43

- reply

Not that I could find offhand, once you get into DACs that can run at the requisite speeds, 8 bits seems to be the floor :( I'll keep looking, but this is the best bang for buck I've seen so far and it's not even close.

2024-08-05 19:09:55

- reply

Yeah most of the high-speed DACs I've looked at do current output, and then give you the ~same two reference designs for converting that back to a voltage, either with load resistors of a buffer opamp.
The functional block diagram is basically identical to the AD and Maxim DACs I looked at, at this kind of sampling rate. Seems to be firmly a solved design, most of the fanciness is trimming the current array and voltage references during manufacturing.

2024-08-05 18:59:46

- reply

Oh and English datasheet: https://www.relmon.com/en/mobile/index.php/welcome/download/279.html

2024-08-05 18:58:06

- reply

MS9708 from Hangzhou Ruimeng Tech, if you want to play along. In stock at LCSC, and from the block diagram looks fairly identical to comparable spec parts from NA manufacturers that want 10x more money...

2024-08-05 18:54:38

- reply

I ended up finding an English(-ish) datasheet on the manufacturer's website! $1/ea 8-bit DAC that should be capable of 60MHz output, well in excess of what VGA-ish pixel clocks need. This is sort of what I assumed these parts would cost, until I discovered Analog Devices's stranglehold on this class of chip...

2024-08-05 18:47:50

Having a very Shenzhen I/O time all of a sudden. Really nice looking part that I could maybe use, I just need to miraculously learn to read Chinese to be able to read the datasheet. Or make educated guesses from the pictures.

2024-08-05 18:22:07

- reply

Anyway, this is why I don't build my own computer, because I'd go "okay time to whack video out on the board" and then spend two years driving myself mad learning the entire spectrum of what you _could_ do... The 65X DAC as designed is totally fine, do not follow me into this abyss 😂

2024-08-05 18:16:22

- reply

er I mean 1/256 of the output swing, not 1/256V, but you know, same thing. I guess hmm, if you take the R output, multiply it up (to increase the contribution of its bits), mix it with G, then divide back to 0.7, maybe?... I'll have to go learn LTSpice and simulate this out, I have no intuition at all for what that does to the signals tbh

2024-08-05 18:14:17

- reply

hmm, maybe? My analog DSP-fu isn't good enough to intuitively grasp what that does to the signals, or if that gets you 1/256V of accuracy in the steps. Hmmm...

2024-08-05 18:09:46

- reply

Definitely doable, question is whether it's doable on the same board with switchable output, for a sensible cost... I think >4 bits per line is definitely where I would reach for an IC DAC instead of doing it with resistors, I'll go shopping and cost that out

2024-08-05 18:08:52

- reply

hmm... So that'd want 8 bits out from the vera, which is definitely doable since it's pushing 12 bits to the DAC right now... With 256 steps it'd have to hit the step values much more precisely, so that might be the point where it makes more sense to whack a single 8-bit "high speed" DAC (in quotes because it'd want like 50MHz sample rate, which isn't really high speed any more but they're still called that...), to not have to deal with hitting 1/256 voltage levels with just resistors

2024-08-05 18:01:39

- reply

Well certainly I'm having fun, as futile as it's turning out to be :) And I did end up picking a book on how digital video work, which has a whole bunch of stuff on the trickiness of analog video as well! I _think_ these resistor DACs that retrocomputing enjoys have "sin(x)/x error" on their output, where the video signals get damaged a little. That can allegedly be fixed with the right post-DAC filter to rebalance the signal, but that's well out of my knowledge sphere atm!

2024-08-05 17:58:25

- reply

I think unless you'd like me to sketch an R-2R DAC on here, the conclusion from a few days ago stands: for factory assembly, the assembler will have no trouble sourcing 1% reels for the E24 values in the original, so it's probably fine. Technically the values specified by vera are out of spec for VGA, but only by a teeny bit in a way that probably doesn't matter much...

2024-08-05 17:57:12

- reply

Allowing for the values already on the board I have (10k, 47k, 1k, 820), I can get the BOM back down to 4 new reels for the DAC + some of those parts... but only allowing for 10 parts total, where some of the lines have 3 resistors on them instead of 2.
The search continues... I'm at the point where running this with E12 resistors takes hours due to using mostly brute force instead of cleverness, and having written it in python it's single-threaded.

2024-08-05 08:16:59

- reply

With E12, can get down to 5 unique parts, but that's still a net increase in BOM in several dimensions, and it has to accept some fairly wide tolerances on the output to make that work. Doesn't feel super worth it. I'll keep trying some variations, but so far... eeeh

2024-08-05 08:08:36

- reply

After more crunching on possible DACs, still not finding anything amazing. Best I have so far, optimizing for reel count, is 8 resistors on the board, with 6 distinct values :/ That's with only E6 resistors as the starting options, running now with E12 to see if it looks better, but the combinatorial explosion looks like it'll run overnight 😬

2024-08-05 02:47:15

- reply

Sure, I suppose. And if such a thing existed where I could audit the added code in a finite amount of time I might even keep such a USB stick around somewhere. Can't say I desperately miss not having one though, thumbdrives are cheap and the internet's reasonably fast these days

2024-08-05 02:40:51

- reply

... but then also yeah, I don't judge what people get up to with their computers, but I just don't really have a use case for carrying a couple dozen ISOs around with me and being able to boot any of them at any time. I'm sure such a need exists, but I don't really have it

2024-08-05 02:39:23

- reply

I genuinely think there would be an argument for someting _like_ ventoy, that discards bios compat and all the weird features, and implements literally just "I'll register a couple UEFI drivers so that your ISOs show up as bootable drives, and then get UEFI to ask you which "drive" you'd like to boot from" kind of thing. I could be (famous last words) much smaller, simpler, easier to audit, and be just about as useful to most people who don't need the esoterica.

2024-08-05 02:35:56

- reply

Oh and I forgot, the repo's also _full_ of checked in binaries, and it's very not obvious to me that a build from source is building from source, as opposed to just shoving a binary whose last commit message is "some fixes" into my boot chain. It could just be unorganized development, which, you know, fine, open source, do what you like, etc.
... but also if I were trying to get people to load malware into the preboot environment...

2024-08-05 02:29:02

- reply

I came away with the conclusion that it's an impressive tech demo, but that I doubt anyone can claim to know exactly how/why it works. It also has what I find to be distasteful feature creep, where there's a lot of knobs that should have been a closed(WONTFIX), because please stop doing whatever this is you're trying to do. But that's again personal preference. I guess in general my values for good software and ventoy's seem at odds. It gets results, but at what cost

2024-08-05 02:26:41

- reply

I'm reluctant to rubbish other peoples' open source work, but here goes: the impression I got was that it's 15 other OSS projects smashed together and patched haphazardly, to whatever extent necessary, to make stuff boot. There's a patched grub in there, some UEFI drivers that interpose other EFI APIs to make stuff work, a lot of logic implemented in thousands of lines of grub configs, and everywhere I looked concerning hacks like "break the RNG to make <random ISO> work"

2024-08-05 02:21:35

- reply

Quite aside from the weird fans, I peered inside to see how it ticks, and hoo boy. Decided to stick to the safe shallows of being able to tell whose code I'm executing.

2024-08-05 00:18:04

- reply

I'm neither but I can tinker! And I've been looking for reasons to muck about with bluespec again...

2024-08-04 23:48:21

- reply

okay that helps give me an idea what to expect as I read more. Thanks!

2024-08-04 23:02:07

- reply

hmmkay, yeah. Debug SPI bus is taking up 4 pins, switching to some form of 1-wire bus could free up 3 IOs, gate count permitting... Bus wow these parallel busses sure do eat pins don't they

2024-08-04 22:58:54

- reply

hm, annoying. The pin map is in swetland's repo right?

2024-08-04 22:55:46

- reply

Are you very I/O limited on the vera right now? How many more pins would you need for the glue logic? All my recent experience was with ECP5s, which are comparatively huge in pin count and gates.

2024-08-04 22:54:54

- reply

But I'll stop writing fanfic now, need to run off to dinner soon. I'll read the verilog and try to get my head around how it's organized, see if I can get a clearer idea of what's happening.

2024-08-04 22:53:51

- reply

Hmm, another possibility, in the vera verilog I see a worrying amount of stateful logic that seems to trigger on level rather than posedge/negedge... I wonder if the issue you hit is because vera as-is is grabbing the bus data when the write signal is at the enable _level_, rather than only on transition. That would keep it latching repeatedly all the way to the end of the bus cycle, which, with unsynced clocks, now I can see where a delay in dropping /WR would lead to sadness

2024-08-04 22:51:02

- reply

certainly getting all the signals processed in the same place can't hurt, synchronization wise. I still find it puzzling because the ATF's datasheet claims ~10-20ns delay, and 8MHz clock leaves a solid ~60ns before the bus risks changing again... Sure feels like the timings should be lining up fine, but staring at the various timing diagrams doesn't leave me _certain_ of that.

2024-08-04 22:44:14

- reply

mkay so, gated on the same clock and producing the same final result... Just, delayed by the CPLD's propagation delays, assuming it's not itself clocked implicitly

2024-08-04 22:41:22

- reply

oh huh I missed that this only happens when doing this from the glue logic... Is it generating /RD and /WR outputs in lockstep with PHI2 itself?
Without synced clocks I'd have expected 8 vs. 25MHz to keep glitching regardless... But the CPLD does add some amount of propagation delay (do you know how much offhand?), so, could be...

2024-08-04 22:34:37

- reply

I think given what I remember of the observed glitch behavior, it does have a feeling of clocks sliding about and "oops latched an indeterminate state" to it... But I'm not confident enough of my verilog to diagnose from a crystallized program, I think I'll need to hammer the bus on an actual board and probe/poke on there...

2024-08-04 22:32:08

- reply

My question remains: this sort of clock domain crossing is a Well Known Thing FPGAs have to worry about, so my hot take is vera should not be glitching in this way to begin with... But there's much to dig through before I can convert the vague feeling into something solid.

2024-08-04 22:30:30

- reply

What I can say prior to that... If you make the vera generate FCLK from its own reference, I could see that helping by keeping the two domains phase-locked somewhat (modulo propagation delays across the board etc.). Assuming the glitch is indeed caused by clock phases sliding around due to not being multiples of each other, locking them together would do the thing. Fingers crossed!

2024-08-04 22:25:12

- reply

Well, allegedly the upduino and 65X parts show up next week, so once I have a booting machine maybe I can have a tinker. I don't have a clean picture of the featureset being implemented here, I need to have some play time on that, plus a refresher in corners of verilog I haven't touched much, before I can have decent opinons about how it operates.

2024-08-04 22:23:11

- reply

If the core only acts upon the write data register once the write signal has crossed clock domains, that... might? Be fine? But I'm not left with a strong sense of "yup definitely fine", or a clear idea of where one clock domain ends and another begins, tbh. Given gateware whose entire job is mediating across CPU, internal and video clock domains, I was hoping for much more brightly drawn lines around each one

2024-08-04 22:21:11

- reply

Hmm, and PHI2 is clocked at 8MHz when it's talking to vera, correct?
Looking at the verilog, I see it synchronizing the read and write signals across the clock domains... But not the data bits itself, those get latched into a register based on CPU signals (i.e. driven by CPU clock), and I'm not seeing any further domain crossing gubbins there... But this code also seems to play quite fast and loose with synchronization, so I'm having some trouble following the bits around...

2024-08-04 22:06:48

- reply

I think it does (caveat: not expert). You'd still want to make sure the vera only samples the bus every 3rd cycle or whatever it is, so that it's only pulling values when the CPU's got the bus in a settled state. But having the two clocks in lockstep should make that doable.
Can't really opine more until I go figure out what the verilog's up to. One more thing for the stack...

2024-08-04 22:03:10

- reply

Oh for sure, in terms of input hardware I'm fairly sure I'll do north of 50MHz (haven't looked at the spec sheet though). My recollection is the problem is more clock domain crossing when there's no synchronized sampling, because the receiver may sample the signal when it's in the forbidden zone between 0 and 1, which if you're unlucky causes a cascade of gates floating at an indeterminate state rather than latching to a binary level.

2024-08-04 21:59:40

- reply

Feel free to answer RTFM, I've been meaning to go ponder vera's verilog for a bit now. Until the ICE40 shows up here I don't have a target to play with, but this sure feels like something the FPGA should be able to handle without the system needing to make special efforts...

2024-08-04 21:58:13

- reply

Aah, I see, there's clock domains to cross and I guess vera either isn't bothering with that, or not getting it quite right. Hmm.
Crossing from a slower domain into a faster one should be doable with a couple buffers if I remember my tiny amount of synthesis correctly. I wonder why it doesn't do that... Do you know what other users of vera do? Surely this should be a common problem if it's working with an unsynchronized clock...

2024-08-04 21:36:22

- reply

I missed the story with vera timing. Is it not behaving itself? Would it be something fixable in gateware?

2024-08-04 01:45:31

- reply

Assuming no sync pulses on the color lines, and assuming black==blank, then in practice the GPU is driving 0V to 0.7V outputs, and that's either exactly what the monitor wants, or for the very rare monitors using the NTSC voltage levels, it's a teeny bit shy of the nominal 0.714V high level, but still well within tolerance so who cares.
Okay I'm going to stop dissecting VGA now, I promise I'm done. I can pop one layer back up the stack, compute resistors for the VGA DAC.

2024-08-04 01:43:08

- reply

And kinda regardless of what sync modes the monitor offers, who the hell in this day and age is making a VGA output driver and isn't going to use the 5-wire form that is utterly universal and doesn't require extra conditionals to maybe decide to gratuitously scream NTSC every now and again. If the drivers even look for any of this any more, I wager they ignore the advertised signal level entirely and just panic if black-is-blank and separate-sync aren't set in EDID.

2024-08-04 01:40:29

- reply

Some of the monitors advertise that they will understand sync pulses sent on separate wires, or in the NTSC-style composite form, or in the "Sync on Green" form where the green analog line behaves differently to red and green.
But most say they only understand separate sync signals. Making the advertisement of supporting full 1Vp-p swings irrelevant, because they then immediately say "oh but I don't understand the thing you'd do with 0.3V of that range, so, uh, I guess 0.7Vp-p really"

2024-08-04 01:38:32

- reply

... But modern graphics cards don't send composite sync pulses on the pixel lines, they all use separate TTL wires for those. So, the -0.3 to 0.7 and 0 to 0.7 EDID values are functionally identical in practice, as long as your EDID also tells the sender that "Separate" sync signals are supported. Which these EDIDs all do.

2024-08-04 01:36:50

- reply

Hahaha wait no, I have a better, much worse theory.
They're all reporting the 1Vp-p variant that ranges -0.300V to 0.700V. Which is the bit value `000` in EDID.
My new theory is those monitors just didn't bother setting a value in that field, because the monitor worked fine with the default so who cares.
Which, yeah, it does, because they also all specify "blank level equals black level", meaning the pixel data swings 0V through 0.7V, with -0.3V being used only for sync pulses.

2024-08-04 01:33:29

- reply

more scripts later, no obvious pattern other than the monitors advertising 1Vp-p seem cheaper and nastier, which makes me wonder if there's some popular legacy VGA decoder chip that they all slap on the board to get an extra port to sell and that chip just doesn't give a fuck?

2024-08-04 01:20:46

- reply

One awk script later, date seems irrelevant: from 1995 through 2022 manufacturing dates, 0.7Vp-p and 1Vp-p monitors are represented in approximately equal amounts in the EDID database. Certainly same order of magnitude. Which I find completely bemusing for several reasons, one being: wait people are still _making_ new analog monitors??

2024-08-04 01:00:33

- reply

Not much of a pattern in the non-0.7Vp-p ones so far. Samsung and Dell account for a large number of them, but they account for a large number of monitors of that era generally. Maybe manufacturing date?...
Not really! There are EDIDs from monitors manufactured in 2022 that request 1V p-p output! What the hell?

2024-08-04 00:53:19

heh and I found linux's EDID database, and a quick grep later wouldn't you know it, monitors are all over the place in what signal levels they report.
12895 report IBM VGA 0.7V p-p.
10566 report PAL 1V p-p, -0.3V to 0.7V.
62 report NTSC 1V p-p, -0.286 to 0.714V

2024-08-04 00:31:33

- reply

And the answer: eeeeh sort of. Most affordable in small quantities that I can find is the Intersil HI1178, but all these parts give off big "last orders please, we're shutting down the line" vibes. Except for the Analog parts, but unless you're buying reels of 2500, the one DAC would end up being a large chunk of the BOM cost...
It's annoying because I don't love the yolo-ness of the resistor DAC from a robustness POV... but it's quite hard to beat "about 1 cent in medium quantity".

2024-08-04 00:07:40

- reply

In particular I was looking at the ADV7125, which does all the RGV analog crap in a single chip, driven by parallel inputs. More than vera currently outputs, but that's fine just tie the low bits to gnd and it's all fine. Just need to somehow want 1000 of them and they're $5.59 each.
That does lead me to wonder if regular single-output DACs are just cheap enough these days to not play games with resistors and whack down three proper video drivers on the board...

2024-08-04 00:05:52

- reply

ok coming back to this: seems 0.7V is the right target full brightness level, so the values from above are... Well, still mediocre, but correct, I think. I'll look for better alternatives.
One more alternative to ponder: Analog Devices still make VGA-compatible video DAC chips. Not cheap, around $10 in unit quantities and down to $5-6 in larger quantities and lead times from Analog directly, so probably not really viable, but... they exist.

2024-08-03 23:12:15

- reply

source btw, now that I'm back on computer: https://archive.org/details/bitsavers_ibmpccardseferenceManualMay92_1756350/page/n411/mode/2up
Page 4-2. The rest of 4 is all about timings rather than electrical levels, and 1-3 is the programmer's reference for driving the IBM VGA adapter's memory mapped registers, BIOS API, and so forth.

2024-08-03 22:23:40

- reply

Deeply annoyingly, the source itself fails to specify any fucking tolerance on anything, so I still don't have an answer to my original question, only evidence that there may not be an answer.

2024-08-03 22:19:19

I found it, the true source. 1992 programmer's reference for VGA and XGA on IBM PS/2.
VGA is 0 to 0.7V, regardless of what messy reality did
https://media.hachyderm.io/media_attachments/files/112/900/402/687/383/065/original/2147647365b877aa.png

2024-08-03 20:19:58

- reply

I guess if you happen to have a vintage CRT with VGA input... can you dump its EDID and see what it says?

2024-08-03 20:18:48

- reply

It _seems_ likely that only one of the 4 voltage levels was actually popular in VGA's heyday, but the EDID standard doesn't hint at which one it might be. 0.7/-0.3V is listed first, but I don't think it's valid to assume that first == default, because if you interpret the rest of the block like that, it translates to "don't send my any sync pulses", which... that ain't right

2024-08-03 20:15:54

- reply

Yeah. Strictly speaking the transport is DDC2, which is I2C with some well known hardcoded addresses for stuff.
EDID is also how you discover if the connected display is in fact digital and wants you to stop all that DAC nonsense and output LVDS or TMDS digital signals (for DVI/HDMI/DP)

2024-08-03 20:07:46

hahaha damnit, the actual answer to "what voltage levels does VGA use" is, in fact, "fuck you".
More precisely, if the monitor supports EDID, then one of the many "basic display parameters" the monitor provides is what white and sync voltage levels it wants from you, and you have 4 options: 0.7/-0.3, 0.714/-0.286, 1.0/-0.4, or 0.7/0.
This is also where the monitor advertises if it understands sync-on-green, or if it wants a separate sync signal.

2024-08-03 03:30:24

- reply

Then the timeline gets a bit fuzzy for me, because we go from that to RS-330, or possibly RS-343, or both. I can't find copies of either, only people summarizing what it says. Its major change compared to RS-170 is that the peak to peak signal level is reduced from 1V ±0.05V, to 0.714V ±0.1V.
In parallel, color TV was happening, and so component video (not the same as composite video) was a thing. Component video just means you carry color information as multiple separate signals.

2024-08-03 03:25:18

- reply

RS-170 was published by EIA, which has ceased to exist and seemingly all its documents have gone into the ANSI memory hole. But various papers and manuals over the years reproduced bits of it, so I can say it has a bunch of things that look familiar if you've ever looked at analog TV/computer signals.
Notably, it defines the receiver's load impedance as 75 ohms ±5%, and that the signal amplitude from the "blacker than black" blanking signal level to reference white is 1V ±0.05V.

2024-08-03 03:22:36

- reply

OKAY SO is all begins with standard RS-170 for monochrome broadcast television. RS-170 describes what a monochrome composite display signal looks like. Composite in this case means it includes both an analog signal describing the intensities of image pixels, as well as framing like sync pulses to help the recipient figure out where frames start and end.

2024-08-03 03:19:00

- reply

Even better, if we assume that standards which inherit from each other silently inherit anything not explicitly overridden... then VGA has to tolerate up to 2V on the signal lines. Or maybe 1.4V, depending on how the inheritance works.
Problem here is VGA is partially defined by reference to a standard whose standards body ceased to exist a decade ago, and seemingly took all its documents to the grave.

2024-08-03 03:16:42

- reply

Okay so there's a bunch of missing dots on my big board, and I bet as soon as I spell this out someone's going to go "oh yeah, did you not know that, idiot", but here goes...
https://media.hachyderm.io/media_attachments/files/112/895/861/139/460/081/original/bd0c319c35e41c7d.mp4

2024-08-03 03:00:40

- reply

But either way, I've been targeting 0.7V in that generator run, and from this current horrible bit of research I _think_ the target is supposed to be 0.714V. Further, if these things come together like I think, the tolerance on that signal is a _ludicrous_ ±0.1V (no missing zeros there), in which case god is dead and I can absolutely find you more convenient values that save on reel count because lol that's a fourteen percent tolerance

2024-08-03 02:57:02

- reply

I don't think this DAC has any particular name, it's still a binary weighted DAC, just with the individual resistors constructed from parallel pairs. The theory is exactly the same, each parallel pair's equivalent value just makes this a binary weighted DAC, it's just a manufacturing hack

2024-08-03 02:55:14

- reply

Assuming those are the values from the screenshot, yeah it's something like that. I've been tinkering with the generator, but I haven't found a good set of values that reduces the number of distinct components, so best I can offer is only needing the more common values, so far.
However, if my rabbithole here is right, both vera and I are targeting the wrong full deflection voltage for all on, so may want to tweak this a bit...

2024-08-03 02:34:49

I think I just found the origin of why VGA signals are 0.7V, and if this is right, it's another fucking legacy code situation.
But sources are very thin on the ground, I'm having to infer some of this from contemporary sources that seemed to think everyone knows the thing already.

2024-08-01 20:57:32

- reply

Hot damn! Another win for hoarding packing material in a shame pile in the corner.

2024-08-01 20:54:54

- reply

The suspense is killing me, did the screen survive the trip?
Also guess I'm glad I did all that padding, the box's corner was very much of the un-kicked in variety when I dropped it off 😬

2024-07-31 20:28:25

- reply

Makes sense! Other than enjoying the hardware of it, I'm not terribly deep into the aesthetics of old computers aside from the Atari ST, so didn't know if you had a specific "kinda like this other thing" vibe you were picturing.
One of my 3D printers is finally in vaguely working order, so maybe I'll add that to the list...