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:26:28

- reply

Some days, I wish I was simply good enough to get it right the first time, or not care about correctness. Seems like a much easier time to have :P

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-26 20:05:51

- reply

Strangest of all, this is only happening in the write path? The read path just grabs the slightly widened address out and plugs that into the read port, so I end up with a memory that's got a 15-bit read port address, and 270 bits on the write port... It's _possible_ that this is a correct translation of my intent, but it sure looks wacky... Let's see what RTLIL says...

2024-08-20 04:06:09

- reply

silly question, why's it called the clock port? This must be a reference I'm not getting

2024-08-17 20:52:03

- reply

Cool, so assuming enough pins to do the thing, the FPGA could, say, let you inspect/modify RAM on a running machine by pausing the CPU clock, yanking BE to get the CPU off-bus, and initiate I/O with other peripherals itself. That could be fun.
The 65C816S datasheet's architecture diagram does show a bus enable control line on the I/O, so... maybe?

2024-08-17 20:49:09

- reply

Ooh and you mentioned the CPU is static and can be halted consequence-free at any point. What's the builtin debug facilities look like? Because if the FPGA's in charge of the CPU clock, you could maybe have a debug interface on GARY that lets you jack into the machine, halt the CPU on some trigger condition, inspect system state (assuming the CPU can be made to hi-Z its bus outputs, so the FPGA can take over as bus master and query RAM and whatever)...
Another pony for the list!

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-17 20:12:57

- reply

Note synchronized clocks don't have to run at the same rate. One just has to be a divided version of the other. So you can have a 100MHz FPGA talking to a 50MHz CPU, as long as the two clocks stay in phase such that a rising edge from the CPU corresponds to a rising edge of the FPGA clock. That allows the FPGA to latch inputs without having to worry about metastability, because it's doing so within the window where the CPU guarantees stable/valid values.

2024-08-17 20:10:08

- reply

For a 50MHz eZ80... I don't know what its bus discipline looks like, that's key. From the edge that tells the FPGA it can latch an address and do a read, how long does it have to get the right signals on the data bus? And, are the bus and FPGA clocks synchronized? Synchronized clocks can avoid the 2-cycle synchronization delay, which is a pretty huge chunk of the total budget in this case.

2024-08-17 20:07:38

- reply

if I'm reading this right, you can configure the CPU to stretch PHI2 for slower memories, which may end up being required here. Otherwise running at 12.5MHz PHI2, FPGA has to turn reads around at 25MHz, so 75-100MHz internal clock. That _should_ be doable, simple experimental designs clear 150MHz easily, but I don't know what the more complex vera-ish bus frontend will need.

2024-08-17 20:05:55

- reply

Depends a lot on the bus timing requirements from the CPU. Roughly, with an async bus, the fastest the FPGA can turn around a read request is 3 cycles of its main clock (2 for clock domain crossing, 1 for memory access assuming no contention). I think ideally 4 cycles would be better, that'd allow for another layer of registers on the output to shorten the data paths.
On the 65C816, looks like reads need to be turned around in 0.5 PHI2 cycles. So, 3-4 cycles per half-PHI2.

2024-08-17 19:48:06

- reply

Hmm. What's the timing requirements for reads? That is, from the moment the CPU pulses to tell me to latch addresses and execute a read, how long do I have to put the right value on the data lines?

2024-08-13 16:57:23

- reply

Consecutive as in the FPGA would receive first 8 bits on one PHI2 edge, and the other 8 bits on the immediately following PHI2 edge?
Offhand that feels doable. Reads are the harder bit there, if you're clocking at ~12MHz, and the FPGA is at 25MHz, and the bus has no clock stretching mechanism to let the FPGA delay its response.Writes are easier, can just latch the two writes into registers and process them at leisure.
Big Q for ice40 is how fast I can clock the logic...

2024-08-13 16:49:15

- reply

heh, we posted this simultaneously. Yeah, internal block ram as cache is feasible, the caveat there is that doing that could result in some pathological failure states where the CPU can set up a field that hits just the right cache misses to overload the memory bus and make it fail timing.

2024-08-10 22:00:48

- reply

TI would be happy to supply a more complete power management solution, I'm sure :) Their bread and butter is this kind of "anything to everything" power management ICs. For a price of course, this chip's $0.8 in 1,000 quantity ($2 and change in singles, but also TI will send you a couple samples for free iirc), I suspect to get more toys you need to double/triple that to get into the really fancy boys.

2024-08-10 21:59:14

- reply

This particular one doesn't seem to, only overvoltage and reverse current protection. The datasheet describes that it's aimed at applications that have a barrel jack input and would like to switch that over to USB-C as cheaply as possible. So, you don't get data, or much of the fanciness of more fully integrated power management chips, just the bare minimum to turn a USB-C connector into a power source of acceptable specs.

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-10 20:51:31

- reply

For extra fanciness, you could stick a current limiting IC between Vbus and Vcontroller. That way you can document exactly how much power budget they have, and safely shut them off if they go nuts, without stressing the PSU or browning out the rest of the system (which is good because if CPU gets to keep running, it can blink an "overcurrent protection" LED or something to tell the user their hand-tinkered controller's gone wrong)

2024-08-10 20:46:33

- reply

But in general, this plan seems reasonable. Cascade the 3.3V and 1.2V LDOs just so the 1.2V has less to dissipate (i.e. VBus -> 3.3V rail, 3.3V rail -> 1.2V rail).
How much are you okay trusting the controllers? Routing VBus to them directly means you're trusting them to stay within some power limit to not overdraw from the upstream USB port (well designed port will just shut off, less well made... magic smoke/other sadness?)

2024-08-10 20:42:18

- reply

I'm guessing given USB's popularity there might be lightweight ICs that act as reset controllers for those thresholds without being full USB-C power controllers, but I dunno. Depending on mainboard power draw I guess you could also have the CPU in charge of releasing most stuff out of reset, so it powers up on a <500mA budget, measures voltages, and releases reset on the rest if ok

2024-08-10 20:40:37

- reply

Yes and no, sort-of, I believe.
15W would be 5V @ 3A, but the upstream port isn't guaranteed to source more than 0.5A. You need to check the voltage across the CC resistors to know how much you're allowed to pull: >1.31V = 3A, >0.7V = 1.5A, else 0.5A
Only one of the CC resistors will have voltage across it (depending on connector orientation), so you have to check both and pick the max of the two.

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:49:49

- reply

yup for sure. I think the X16 people that led to vera feel that it's not retro if it's not socketed DIP, which is fine but I'm not particularly fundamentalist about that.

2024-08-05 20:47:53

- reply

iirc the X16 vera design was tilted firmly in the direction of authenticity, sure use an fpga but only use it to implement the bits that would have been a RAMDAC asic at the time. Which, you know, nothing wrong with that, these computers aren't about being reasonable 😂

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...