Nostr notes by Dave Anderson

My aspirations for computers are modest: I would like to minimize ...

2024-09-11T23:33:14Z

My aspirations for computers are modest: I would like to minimize the number of times I say "what's it doing now??"

Empirically, so far, the single most effective way to achieve this has been to touch the cloud less.

"I'll implement a UART, I already have one so it should ...

2024-09-11T03:07:33Z

"I'll implement a UART, I already have one so it should be easy to copy over and tidy up"

- Me, an idiot, a few moments before going "oh I guess I could implement hardware flow control too, how hard can that be"

ugh I want to keep writing silly FPGA programs but I have to look ...

2024-09-10T17:44:59Z

ugh I want to keep writing silly FPGA programs but I have to look at the bad screen and do cloud shit instead. You can't even see any flops flip from up here, it sucks.

"Well how much can there possibly be in TeXLive anyway" ...

2024-09-08T03:37:45Z

"Well how much can there possibly be in TeXLive anyway"

TeXLive: well, if you want all the things, the ISO's 6GiB

Good grief.

[@mos_8502](https://studio8502.ca/@mos_8502 ) any chance you ...

2024-09-07T19:39:44Z

[@mos_8502](https://studio8502.ca/@mos_8502 ) any chance you found better timing diagrams somewhere for the 65C816 and/or 265 than what's in the datasheets? Pondering how to wire up the external bus interface, and the timing diagrams that smash every operation into one is... hard to follow :/

Basically my line of thinking is: these simple chips have been ...

2024-09-03T17:26:06Z

In reply to nevent1q…ulga
_________________________

Basically my line of thinking is: these simple chips have been getting faster and faster edges as their dies shrink, which in general causes headaches because people have to deal with high-speed design even if they just needed a lil' inverter. Could you flip that around though, and go hot damn, logic gates with sub-nanosecond rise times, that means they can go real fast if I'm careful about board layout?

morning coffee musing: could you make a discrete computer (7400 ...

2024-09-03T17:23:54Z

morning coffee musing: could you make a discrete computer (7400 chips, but the modern versions with fast slew rates and all that) that can run at triple digit MHz?

Most such computers I see top out at low single MHz at best, but I wonder if that's because they're typically built breadboard style, without much attention to transmission lines, signal integrity, EMI, decoupling and all that.

Or is there something more fundamental that makes this so, like lead inductances adding up?...

Swift seems very well put together, though it seems welded deep ...

2024-09-03T02:14:20Z

In reply to nevent1q…zy4g
_________________________

Swift seems very well put together, though it seems welded deep enough to apple stuff that it's probably not for me. Vala, I remember when it first happened and _really_ not getting it... But with another decade or two of experience, I can see what they're going for, and while I don't think it's for me I appreciate the work.

It spans all vocations, imo. It's okay to like good tools, ...

2024-09-03T02:12:51Z

In reply to nevent1q…hkfn
_________________________

It spans all vocations, imo. It's okay to like good tools, and some people end up being tool crafters... but I'd like to hang out with machinists, not people who get into fights about which brand of lathe is the Best Lathe. Same with programming languages.

I bailed around the time Go came along, and it was such a breath ...

2024-09-03T02:10:52Z

In reply to nevent1q…r6yt
_________________________

I bailed around the time Go came along, and it was such a breath of fresh air to have a language and tooling that wants to help you make things that aren't papers. My true happy place is probably somewhere in between the two, I miss richer type systems fairly often... But Go being uninteresting to extreme language design people turned out to be one of its greatest assets, if I can be a little snarky briefly.

Yeah pretty much. At the time I got seriously into it, there was ...

2024-09-03T02:08:26Z

In reply to nevent1q…mmj5
_________________________

Yeah pretty much. At the time I got seriously into it, there was a subculture of "industrial Haskell" that was developing, with a strong focus towards building "real" software with Haskell. The stuff that came out of that subculture was quite pleasant, but it didn't really stand a chance against the research arm of the userbase.

Then again Haskell feels like it's always been honest about not wanting to be "successful" so much as being a breeding ground for academia, so...

And then in an even stranger collision of history, Bluespec's ...

2024-09-03T02:01:45Z

In reply to nevent1q…dey7
_________________________

And then in an even stranger collision of history, Bluespec's original designer was also a major contributor to LPMud. He's been doing languages and runtimes for a long while, turns out.

I'm still not super sold on Haskell as the underlying superstructure for Bluespec, especially after the SystemVerilog surface syntax was added the semantics just feel unhelpfully confusing at times. Hard to argue too much with the result, but I'm definitely more curious about other such experiments now.

From reading about Bluespec's history, TIL there was an ...

2024-09-03T01:55:23Z

From reading about Bluespec's history, TIL there was an object-oriented flavor of Haskell called O'Haskell. I find this very funny and am now picturing Haskell but with an Irish surface syntax. No, I have no idea what that means either, it's the absurdity I find entertaining to some degree.

Some days, I wish I was simply good enough to get it right the ...

2024-08-31T02:26:28Z

In reply to nevent1q…8je7
_________________________

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

This memory is slightly annoying in that it has a zillion ...

2024-08-31T02:15:23Z

In reply to nevent1q…vpwj
_________________________

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

Some test waveforms. The basic configuration of 2x18b ports seems ...

2024-08-31T02:13:40Z

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.

Just this morning I emailed one of the Minuteman historical sites ...

2024-08-30T19:13:47Z

In reply to nevent1q…wllm
_________________________

Just this morning I emailed one of the Minuteman historical sites to ask for dimensions of missile status lights on the commander's dashboard. I think that puts me in the "missiles Georg" bucket on this one

Breakthrough: in this DAG, a node is considering a path which ...

2024-08-28T04:47:00Z

In reply to nevent1q…2pce
_________________________

Breakthrough: in this DAG, a node is considering a path which transits itself, as the non-first node. The algorithm has been cited for wanton disregard of mathematics without a license.

Important leap forward: algorithm now adds back graph edges! The ...

2024-08-28T04:17:56Z

In reply to nevent1q…j9xn
_________________________

Important leap forward: algorithm now adds back graph edges!

The wrong ones mind you, but, baby steps.

Implemented a graph simplification algorithm. So far, it half ...

2024-08-28T03:59:23Z

Implemented a graph simplification algorithm. So far, it half works. In the sense that it deletes all edges. It hasn't yet figured out phase two, in which it's supposed to add back the important edges...

So far it's been crunching for 3 minutes, and is up to 3.6GiB ...

2024-08-26T20:47:10Z

In reply to nevent1q…87qk
_________________________

So far it's been crunching for 3 minutes, and is up to 3.6GiB RAM. This is fine.

And then xdot is going to try and open whatever the hell comes out, which may well just kill the machine.

hahaha oh no I forgot to remove the 'show' from my ...

2024-08-26T20:45:56Z

In reply to nevent1q…08uj
_________________________

hahaha oh no I forgot to remove the 'show' from my script, so now graphviz is trying to figure out how the fuck to organize a graph of 334,000 nodes, F in chat

bahahah I asked yosys to do the full synth run, rather than stop ...

2024-08-26T20:43:56Z

bahahah I asked yosys to do the full synth run, rather than stop at coarse optimization. So now it's having to lower an 18kbit memory to muxes and flops, and hooo boy it's having a bad time lemme tell ya

Strangest of all, this is only happening in the write path? The ...

2024-08-26T20:05:51Z

In reply to nevent1q…vvsx
_________________________

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

Hmm, though at the same time, yosys's optimization passes ...

2024-08-26T20:03:47Z

In reply to nevent1q…vqxq
_________________________

Hmm, though at the same time, yosys's optimization passes have done something quite cursed here it seems. The 9-bit input address is getting concatenated to 0x9, then thrown through a bunch of multiply-accumulates and ALUs to compute... something. I assume that transformation is correct and just optimizing some of the terrible address math that has to take place, but that still fails to explain how I'm ending up with an address that's 27x wider than what I started with...

Hmm, okay, my synthesis of this RAM might not yet be _quite_ ...

2024-08-26T20:00:33Z

Hmm, okay, my synthesis of this RAM might not yet be _quite_ right. I'm pretty sure a 9-bit write address isn't supposed to expand into a 270-bit address by the time it reaches the RAM...

silly question, why's it called the clock port? This must be ...

2024-08-20T04:06:09Z

In reply to nevent1q…9ey5
_________________________

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

"Hmm, I need to get a medium fancy bit of arithmetic computed ...

2024-08-19T02:31:14Z

"Hmm, I need to get a medium fancy bit of arithmetic computed quickly, I wonder what the DSP hard blocks on this FPGA can do"

The FPGA, with unhinged eyes: "did someone say they need to MATH THE SHIT OUT OF SOMETHING"

Ah I see I was confusing myself with the port names, I think. ...

2024-08-17T21:06:24Z

In reply to nevent1q…cjxy
_________________________

Ah I see I was confusing myself with the port names, I think. Re-reading the datasheet's description of the multiplexing on Dn, I think I understand what muxing needs to happen, and it should be easy to implement.

All other peripherals just want separate address and data ports, right? Plus maybe some chip selects so they sit in the right portion of the address space?

Hmm, I think my understanding of the pinout on the 816 may be ...

2024-08-17T21:03:47Z

In reply to nevent1q…r7hn
_________________________

Hmm, I think my understanding of the pinout on the 816 may be off. Is the 7400 logic in one of the kicad designs that I can look at?

This is how I understand the 816's muxing from the block ...

2024-08-17T20:58:02Z

In reply to nevent1q…ryv8
_________________________

This is how I understand the 816's muxing from the block diagram, tell me if this is right?

The 816 has a 16b address port and an 8b address+data port. The I/O cycle starts with a PHI2 posedge, with the address 24b address presented across both ports. Then it turns the 8b port around, and expects the peripheral to deposit 8b data on the next PHI2 negedge.

If that's a correct understanding, demuxing that should be fine. Do you need two separate 8b ports back out?

Cool, so assuming enough pins to do the thing, the FPGA could, ...

2024-08-17T20:52:03Z

In reply to nevent1q…tt92
_________________________

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?

Ooh and you mentioned the CPU is static and can be halted ...

2024-08-17T20:49:09Z

In reply to nevent1q…sr2c
_________________________

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!

A setup where the CPU and FPGA run synchronous would be ideal ...

2024-08-17T20:45:18Z

In reply to nevent1q…4lev
_________________________

A setup where the CPU and FPGA run synchronous would be ideal from the FPGA's POV, for sure. Properly synchronized inputs are much nicer to deal with. Plus, it lets you do overclocking and 6502 compat with a software push! Write to some register for a glitch-free switchover to a slower/faster clock.

Gotcha. I can probably help with the vera core hacking side of ...

2024-08-17T20:41:50Z

In reply to nevent1q…umx8
_________________________

Gotcha. I can probably help with the vera core hacking side of that if you'd like, I _think_ I know my way around the design enough to do that. it might not be done Right in terms of using the builtin clocking elements and stuff vs. just yolo-dividing the internal clock, but it'd work well enough to prototype at least (might just mean the clock phases are a teeny bit off, but fingers crossed not enough to violate timing)

Remind me of how the clock generation happens on 65X? Is the FPGA ...

2024-08-17T20:26:03Z

In reply to nevent1q…wcqu
_________________________

Remind me of how the clock generation happens on 65X? Is the FPGA generating a clock for the 65C826, or are they free-running independently? If the latter, _can_ the FPGA provide a clock signal to put the CPU in lockstep with itself?

Yeah, although as you write out the logic inside the FPGA, ...

2024-08-17T20:25:06Z

In reply to nevent1q…59wu
_________________________

Yeah, although as you write out the logic inside the FPGA, it's annoying how fast cycles creep into the data path. A memory cycle here, a couple cycles for synchronization there, oh no this combinatorial path is too long so it can only run at 40MHz now unless I pipeline it with another register and now the path is another cycle longer, etc.

That's where my lack of confidence comes from atm, I don't know how many cycles things will have to be :/

There's still some clock domain crossing gubbins to square ...

2024-08-17T20:14:24Z

In reply to nevent1q…e9kf
_________________________

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.

Note synchronized clocks don't have to run at the same rate. ...

2024-08-17T20:12:57Z

In reply to nevent1q…nfnh
_________________________

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.

For a 50MHz eZ80... I don't know what its bus discipline ...

2024-08-17T20:10:08Z

In reply to nevent1q…v6wn
_________________________

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.

if I'm reading this right, you can configure the CPU to ...

2024-08-17T20:07:38Z

In reply to nevent1q…vsc9
_________________________

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.

Depends a lot on the bus timing requirements from the CPU. ...

2024-08-17T20:05:55Z

In reply to nevent1q…j8qu
_________________________

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.

Hmm. What's the timing requirements for reads? That is, from ...

2024-08-17T19:48:06Z

In reply to nevent1q…6fa8
_________________________

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?

I think as it happens in my current sketch the lopsided operation ...

2024-08-17T06:18:05Z

In reply to nevent1q…yqjd
_________________________

I think as it happens in my current sketch the lopsided operation latencies wouldn't matter, because all the writes would happen on port A, where the FPGA just needs to run faster than the system bus. On port B where the video pipeline is pulling data, everything is read-only and remains single cycle. Just trying to decide if I care or not, really :)

Yeah I'm mostly dithering on whether it makes any sense. ...

2024-08-17T06:16:28Z

In reply to nevent1q…7vy2
_________________________

Yeah I'm mostly dithering on whether it makes any sense. Implementing a fancy memory controller that has to do RMW and possibly split byte access across two RAM blocks might end up being more gates than just brute-forcing with other RAM primitives to make up the balance.

... Damnit, and the ECP5-25 only has 114KB of block RAM if ...

2024-08-17T06:10:46Z

In reply to nevent1q…y33r
_________________________

... Damnit, and the ECP5-25 only has 114KB of block RAM if you're using power of two widths. I guess that's broadly okay because I can use distributed RAM to make up the balance and claw my way up to 128K, but... damnit, the 128K is in there, just in the most annoying possible shape that I can't use.

Unless I instantiate 18-bit RAM and implement byte writes as a read-modify-write cycle... 2 cycle writes and 1 cycle reads, hmm...

Arguably you can construct a usable topology by making every ...

2024-08-17T06:03:57Z

In reply to nevent1q…78am
_________________________

Arguably you can construct a usable topology by making every write into a read-modify-write cycle... But ugh, it's such an odd layout, why??

I assume the answer to why is another one of the FPGA blocks you can use is a DSP block that can do 18x18 multiplication. And I presume 18b is still a useful width for some DSP-ish things that FPGAs are made to do? Presumably the reason is no longer parity with electromechanical calculators.

Huh ECP5's embedded block RAM is an annoying shape. It's ...

2024-08-17T05:59:35Z

Huh ECP5's embedded block RAM is an annoying shape. It's 18Kbits of ram, and you can configure it to operate in units of 1, 2, 4, 9 or 18 bits.

However, if you configure it for 1, 2 or 4 bit data width, you only get to use 16384 of the bits. The remaining 2048 bits are stranded.

On the flip side 9 and 18-bit widths are awkward, because there's no masked writes, you have to overwrite 9 or 18 bits at once.

yeah, I feel that. On a good day the wisdom is wise and obvious. ...

2024-08-16T21:35:11Z

In reply to nevent1q…2a9w
_________________________

yeah, I feel that. On a good day the wisdom is wise and obvious. On a bad day, well.

I definitely get it, until the 65X kicked me out of the rut, ...

2024-08-16T21:27:10Z

In reply to nevent1q…rqse
_________________________

I definitely get it, until the 65X kicked me out of the rut, I'd not done any of this for a bunch of years out of a general sense of I'll probably just fail. Rebuilding a healthy relationship with failure and iteration is a long road.

Yes! God the number of times I found an unbelievably good little ...

2024-08-16T21:10:09Z

In reply to nevent1q…lr02
_________________________

Yes! God the number of times I found an unbelievably good little regulator or supervisor or whatever, get all excited aaaaand it's fucking BGA only. I'd love to not have to go through that rollercoaster :)

Mostly I look at friends in hardware infosec who have not _that_ ...

2024-08-16T21:08:51Z

In reply to nevent1q…g43d
_________________________

Mostly I look at friends in hardware infosec who have not _that_ much fancier equipment than me on their bench, and routinely pull BGAs off boards they're analyzing, mess with them, reball and reinstall them with surprising ease. I'm sure it's a very acquired skill, but... Not impossible?

I'm told the secret ingredient by far is a board preheater, in addition to the hot air gun. But again, all hearsay.

The easiest route for inspection seems to be to simply git gud ...

2024-08-16T21:06:01Z

In reply to nevent1q…jepk
_________________________

The easiest route for inspection seems to be to simply git gud and not need it. Which, of course... tricky. But especially for home assembly where you can be selective and pick parts that are maybe more forgiving (like, larger pitch and the like), you can get it done maybe?

But I dunno, I've been meaning to try it because access to BGA parts opens up a whole new world of super cheap capable ICs, even compared to QFN and the like.

I'm _told_, though I've never tried, that home BGA is ...

2024-08-16T21:01:59Z

In reply to nevent1q…rhvz
_________________________

I'm _told_, though I've never tried, that home BGA is pretty easy with a hot plate or oven, if you're assembling a new part rather than reworking. plop down the part in a layer of flux, with the balls in approximately the right place (like, 40% overlap is still okay), and bake. When it hits reflow the balls and pads self-align and you're done!

Tricky bits are you can't inspect the solder joints, and if you need rework you're a bit fucked (hot air + reball + reinstall, doable but ugh)

I'd have to look at the exact pinout, but if the thing you ...

2024-08-16T20:53:23Z

In reply to nevent1q…37py
_________________________

I'd have to look at the exact pinout, but if the thing you want is "one whole side of the TQFP is the main bus, with all the address/data pins in the right order", that's probably doable. Usually the constraint is whatever dev board you're using and which pins they decided to hardwire to whatever thing on the board

Quite flexible. The hardware's effectively an ocean of logic ...

2024-08-16T20:52:14Z

In reply to nevent1q…s83r
_________________________

Quite flexible. The hardware's effectively an ocean of logic gates bathed in a routing fabric, with I/O blocks at the edges. If you don't need any special I/O discipline (bespoke DDR voltages, high-speed serdes...) the blocks are more or less equivalent to each other, and you can route signals to any of them.

Ideally, I believe you want related signals going to the same I/O block just so place&route has an easier job with timing, but it's malleable

You can have it either as 144TQFP, or various BGA shapes. I'm ...

2024-08-16T20:48:19Z

In reply to nevent1q…t96f
_________________________

You can have it either as 144TQFP, or various BGA shapes. I'm assuming the former for home assembly, though the BGAs expose significantly more IO pins, 197 for the least horrible home assembly BGA vs. 98 on the TQFP.

Possibly with a hot plate, 0.8mm pitch BGA isn't too horrible to solder on? Routing's fairly horrible of course, although Lattice boast a bunch about how they partially depopulate the BGA footprint to make more room for traces.

Yeah I think it ends up within a $ or two of each other, with ...

2024-08-16T20:45:29Z

In reply to nevent1q…dudh
_________________________

Yeah I think it ends up within a $ or two of each other, with different tradeoffs on how much RAM you get vs. how many GPIOs.

I'll tentatively target the 25k and implement the vram internally, see what that looks like. I might end up trying to prototype my own board with FPGA+external RAM because I've never routed anything with three digit MHz and it seems fun to explore. Or at least fun to fail at, I guess, sob. But it's definitely a step up in complexity.

I note 4-8MB in particular because I think that's enough to ...

2024-08-16T20:42:00Z

In reply to nevent1q…rlaf
_________________________

I note 4-8MB in particular because I think that's enough to get a whole-ass couple framebuffers in there, for more advanced output modes. Really the upper limit is about 64MB before you have to start considering DRAM, but each doubling consumes one more IO pin for the address bus...

[@mos_8502](https://studio8502.ca/@mos_8502 ) so unless I'm ...

2024-08-16T20:40:04Z

[@mos_8502](https://studio8502.ca/@mos_8502 ) so unless I'm counting wrong, the ECP5 25k (second-lowest sku, approx 20 USD) has enough internal RAM blocks for vera's memory footprint. For replicating a vera-type system, that seems like an attractive option vs. the slightly cheaper ECP5 12k and having to bolt on external memory.

After digging, I'm fairly sure only parallel SRAM will have the necessary throughput, not the SPI stuff. OTOH, 4-8MB would be doable in that form factor.

Experimenting continues, just initial thoughts

fpga vendor: "if you don't want to use our $$$$ tool you ...

2024-08-16T20:27:22Z

fpga vendor: "if you don't want to use our $$$$ tool you can instantiate this primitive directly, see <file> for details"

The file: just a blackbox module definition with cryptic input and output names, and zero documentation. As per.

"Electronics isn't magic" "Also, here is the ...

2024-08-16T07:44:17Z

"Electronics isn't magic"

"Also, here is the protective sigil to cast when working with DRAM"

ooh so a bunch of honest to god I/O controllers for peripherals, ...

2024-08-14T17:06:21Z

In reply to nevent1q…gnpj
_________________________

ooh so a bunch of honest to god I/O controllers for peripherals, not just GPIO the CPU can toggle. Interestink. Again, assuming gates, pins and memory can keep up, seems doable.

oh I meant to ask: the GPIOs in the diagram, I inferred you ...

2024-08-14T16:59:01Z

In reply to nevent1q…9m4g
_________________________

oh I meant to ask: the GPIOs in the diagram, I inferred you wanted them for a combination of glue logic stuff, and some inputs for an interrupt controller. Did I infer correctly, or did you have other things in mind for those GPIO? Exposing them to expansion board/headers/something maybe?

I made a repo with some requirements notes in it: ...

2024-08-14T16:48:15Z

In reply to nevent1q…v7g3
_________________________

I made a repo with some requirements notes in it: https://git.sentinel65x.com/dave/gary/src/branch/main/Requirements.md . I also borrowed your diagram, though once plans firm up I suspect both it and the FPGA internals one I made will need redoing - but it's a good guide star.

No gateware yet, I have a couple half-working bits but I'm going to have to start with a couple experiments to see how clever the Bluespec optimizer is, and if I can write "do what I mean" style or if I have to be a bit lower level.

Yeah we'll see. With any luck, it just needs a bit fancier ...

2024-08-14T05:38:10Z

In reply to nevent1q…wp89
_________________________

Yeah we'll see. With any luck, it just needs a bit fancier packing of VRAM data, maybe some caches and prefetching, and it all works out? I don't have a gut feeling for how close/far off from plausible it is right now.

So, I'm going to start with simulation and build up something ...

2024-08-14T05:35:10Z

In reply to nevent1q…72pc
_________________________

So, I'm going to start with simulation and build up something vera-ish, to start with. And see what kind of memory bandwidth the simulator says it needs, and then we can plot further from there?

There's also the insanity wolf option: DDR SDRAM. The ...

2024-08-14T05:34:06Z

In reply to nevent1q…3vdt
_________________________

There's also the insanity wolf option: DDR SDRAM. The ECP5's IO blocks support the relevant electrical standards, and have a bunch of gearing machinery to pull fast DDR data into slower parallel I/O inside the FPGA.

That is _extremely_ out of my comfort zone though, and would require implementing a DRAM controller in the fabric as well. It's, uh, a lot.

ECP5 needs an external flash, same as the ice40. Fast QSPI could ...

2024-08-14T05:30:40Z

In reply to nevent1q…q4zl
_________________________

ECP5 needs an external flash, same as the ice40.

Fast QSPI could work for VRAM, what I don't yet know is whether the bitrate works out. With the VERA design, there's a bunch of 32-bit reads happening during frame drawing, pushing that out over QSPI is a lotta cycles at 4 bits per. Might work though.

External RAM is also pretty spicy from a board design POV, north of 100MHz is starting to be seriously fast, at least for my level of design confidence. But we'll see!

I'll stick S-Video in the list as well. None of these are ...

2024-08-13T20:19:44Z

In reply to nevent1q…secd
_________________________

I'll stick S-Video in the list as well. None of these are "hard" given enough gates and pins, at some point we'll just hit the limit with one or the other and have to start cutting stuff. Or maybe it all fits, I don't have a gut feeling for how full the FPGA will be.

Yeah I always assume VGA to HDMI is doable externally with a ...

2024-08-13T20:17:50Z

In reply to nevent1q…ju8l
_________________________

Yeah I always assume VGA to HDMI is doable externally with a dongle. It just seems a shame to have whole-ass digital signals on the output, and then shovel them through a DAC and ADC on their way to the monitor :) But the low end ECP5s don't have TMDS serdes, so I don't know if the gate cost is worth it.

I have no idea how S-video works in the details, but skimming wikipedia, it'd need a similar YPbPr translator as for composite, and then just different mixing. Maybe!

That's about what I was picturing, yeah. Once I'm off ...

2024-08-13T20:12:50Z

In reply to nevent1q…v7g3
_________________________

That's about what I was picturing, yeah. Once I'm off work tonight I'll try and write up a requirements doc just to remember the list of ponies, and then go off and see what can be done.

In the digital video path, I'd like to squeeze in HDMI as a parallel path to VGA. Just mirrored output, not dual monitor. Just for convenience of hooking into modern monitors. And I guess maybe composite out if anyone cares, can't say I do but 🤷. All nice-to-have only tho, no strong feelings

I guess an option is lower res, or bordered image. 320x200x4bpp ...

2024-08-13T19:22:18Z

In reply to nevent1q…crzl
_________________________

I guess an option is lower res, or bordered image. 320x200x4bpp can double buffer comfortably. Native output is likely 640x480, so needs to be a clean division of that field size, or edge borders.

Ah ok. Monochrome 640x480 double buffered would fit, I think. ...

2024-08-13T19:20:54Z

In reply to nevent1q…w2cm
_________________________

Ah ok. Monochrome 640x480 double buffered would fit, I think. 2bpp, you're down to a single frame with vera's vram size, but if we're entirely abandoning ice40 compat, no reason we have to stick to that if external ram timings work out.

Unless I'm misunderstanding, a full framebuffer would be ...

2024-08-13T19:12:50Z

In reply to nevent1q…4n6f
_________________________

Unless I'm misunderstanding, a full framebuffer would be ~2.5MiB each with 8bpp, which is definitely "fast external SRAM" territory if that's the goal. Or am I not parsing correctly?

If we're talking exposing the address space as ordinary mapped memory, that seems quite doable. TBH I hadn't even internalized how restrictive that external mapping is on the original vera design, wow. Yeah if targeting ECP5, burning 24+8 bits on a direct memory map is a no-brainer.

GPIO and timers easy, I _think_, assuming pins available. GPIO ...

2024-08-13T18:22:57Z

In reply to nevent1q…7j2c
_________________________

GPIO and timers easy, I _think_, assuming pins available. GPIO would be limited to 3.3V and not much current drive so would probably need extra hardware to make robust (e.g. bidi buffer of some kind) if you're thinking of letting people plug stuff into them. I'll have to study the schematic for the 65X data bus, I don't immediately see a difficulty other than pin count and logic element count. Noted as a thing to explore, though I'll delay that and glue logic to after graphics work.

that was my plan, yeah. Even if it ends up being API compatible, ...

2024-08-13T18:14:51Z

In reply to nevent1q…cc4v
_________________________

that was my plan, yeah. Even if it ends up being API compatible, it's a distinct implementation and shouldn't be named the same. Suggestions welcome, my only desire is I'd like to get away from "dude gives a female-coded name to things they make", because it irrationally bugs me. My tinkering folder right now is called GARY, though I don't have a backronym for it 😂 Graphics Adapter for Retro... Something?

danke! I will go learn and ponder. Thanks for the pony request!

2024-08-13T18:01:49Z

In reply to nevent1q…ka7n
_________________________

danke! I will go learn and ponder. Thanks for the pony request!

palette reprogramming on the fly I believe already works on the ...

2024-08-13T17:49:49Z

In reply to nevent1q…nqny
_________________________

palette reprogramming on the fly I believe already works on the existing reference design. Preserving it with the more capable other palette things in this thread would mean it definitely has to be read from main vram in real time, which I don't know if that's possible yet but will try.

Display lists... Got pointers to systems that do this? I don't quite visualize how this works so can't tell if I can do it, or if it's compatible with a tiling+sprite engine.

The other thing I wanted for palette stuff was a cycling option. ...

2024-08-13T17:47:42Z

In reply to nevent1q…z45d
_________________________

The other thing I wanted for palette stuff was a cycling option. Less memory intensive than entire different palettes, I'm picturing just being able to define a few [start:end] ranges in the palette and a cycling speed, and the hardware automatically rolls the values in those slots. That might end up being too pricey in gates, again not sure until I hit the simulator. But I'm a sucker for colour cycling animation!

An easy hack: palette ram is in vram with a base addr, and at the ...

2024-08-13T17:38:22Z

In reply to nevent1q…wcqn
_________________________

An easy hack: palette ram is in vram with a base addr, and at the start of each frame, stream 256 entries out from vram into the dedicated palette output ram before pixel painting starts. Palette writes only take effect on the following frame, effectively. Increases memory cost (have to store the palette twice), but the dead time during vsync should be plenty to do the copy without getting in the way of CPU access. Maybe that works... Unsure, will ponder!

Tricky part with the palette ram in particular is it's ...

2024-08-13T17:35:08Z

In reply to nevent1q…n8yq
_________________________

Tricky part with the palette ram in particular is it's completely timing constrained in my design sketch: if I hand it an address, I _need_ the RGB data to be ready on the next cycle, because it's all being pushed synchronously as each pixel's being output. The other main vram access goes through arbiters and can accept a cycle or two of delay if there's contention... But not the palette ram, at least in my current sketch. But possibly I can adjust where it sits to make that work.

Understood. Big question there is vram throughput again. In the ...

2024-08-13T17:32:48Z

In reply to nevent1q…ugn3
_________________________

Understood. Big question there is vram throughput again. In the vera design, it's already 4 ports (one RW for the CPU, 3 RO for the two layers and the sprite engine), so it's having to push what feels like an uncomfortable amount of bits when a frame is being output. I don't think I saw it using dual-port RAM hw, so that's an option for more margin. The storage might be optimizable, and the whole thing can run at higher MHz... Maybe there's enough space for the palette. I'll see.

Doable, although more or less tricky depending on what you want ...

2024-08-13T17:19:34Z

In reply to nevent1q…75mg
_________________________

Doable, although more or less tricky depending on what you want exactly. Currently palette ram is a separate mem with 256 idx -> RGB vals.

Easy to implement: add offset register to that memory. Example: compositor says output palette idx 3, palette offset register = 100, we output RGB from memory entry 103. If offset register = 254, then output entry 1 (254+3 with wraparound).

Is that what you'd like? Or do you want to be able to put the palette at arbitrary vram addrs?

Yup all good. I explicitly invited asking for a pony, knowing ...

2024-08-13T17:10:00Z

In reply to nevent1q…gndf
_________________________

Yup all good. I explicitly invited asking for a pony, knowing what constraints to aim for is great at this stage!

I should say, the timing I'm worried about here is on ice40 ...

2024-08-13T17:04:28Z

In reply to nevent1q…ne3w
_________________________

I should say, the timing I'm worried about here is on ice40 with its internal RAM only. On ECP5 if external RAM is needed, different challenge: it should be able to comfortably run north of 100MHz internally, but it needs enough cycles to latch the bus request, round-trip to external RAM and put the response back out. So, it can run more cycles per PHI2, but also it would have more cycles of work to do. Not sure how that shakes out.

It has one PLL block, and its datasheet claims that with ...

2024-08-13T17:00:10Z

In reply to nevent1q…cucx
_________________________

It has one PLL block, and its datasheet claims that with carefully designed logic (not too-long combinatorial paths), it can hit a max of 100MHz. Conservatively, derating that to 50MHz that's... Well, with the synchronizers on the bus that still leaves precious few cycles for reads, but it miiiight just about be possible to respond fast enough. Again, when I get to that point, simulation will be able to say for sure.

Consecutive as in the FPGA would receive first 8 bits on one PHI2 ...

2024-08-13T16:57:23Z

In reply to nevent1q…5h68
_________________________

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

heh, we posted this simultaneously. Yeah, internal block ram as ...

2024-08-13T16:49:15Z

In reply to nevent1q…0mvc
_________________________

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.

famous last words but there should be plenty of IO for an SRAM, ...

2024-08-13T16:43:13Z

In reply to nevent1q…4zev
_________________________

famous last words but there should be plenty of IO for an SRAM, either a parallel 8-bit bus or even like a QSPI clocked faster than the pixel clock so that there's enough memory bandwidth. Certainly there are options.

oh yeah if SRAM is necessary I'm assuming it's hanging ...

2024-08-13T16:22:36Z

In reply to nevent1q…se0f
_________________________

oh yeah if SRAM is necessary I'm assuming it's hanging off the FPGA directly and not exposed to the rest of the system bus. From the rest of the machine's POV, the FPGA+its RAM still look like a single memory-mapped device with everything built in.

Note I didn't hunt for the best source, I just reached for ...

2024-08-13T16:11:20Z

In reply to nevent1q…5fnk
_________________________

Note I didn't hunt for the best source, I just reached for digikey because I know they stock them and unlike mouser their search doesn't take 30s+ per. Prices I quoted are CAD not USD.

Potential issue on the lower end ECP5 is the amount of RAM, it only has 73k in dedicated block RAM. Given the higher gate count I may be able to make up the balance with distributed RAM (repurposing the logic blocks as RAMs), or it may require a small external SRAM. Not sure yet.

Using digikey as a pricing reference: the upduino's ice40 is ...

2024-08-13T16:09:39Z

In reply to nevent1q…v88p
_________________________

Using digikey as a pricing reference: the upduino's ice40 is $15.70/ea, the cheapest ECP5 is $22.10/ea. That's for double the logic gates and triple the pins, in a TQFP form factor that doesn't suck too much to solder at home (esp. with hot plate).

Top-end ECP5 (16x the gates and 6x the IO of ice40) is around $100. That's the one of the dev board I have, but I don't think there's any need to go that far.

Ooh, hrm. Okay that may not be able to fly on ice40 then but ...

2024-08-13T16:00:29Z

In reply to nevent1q…2ja9
_________________________

Ooh, hrm. Okay that may not be able to fly on ice40 then but I'll see what I can do. I can definitely keep the CPU interface module well separated so that the interface can adjust in that way (e.g. if you switched to ECP5, or a pair of ice40 one for graphics one for audio+glue or somesuch)

Hmm, those were like that because of the X16's narrow bus, is ...

2024-08-13T15:52:43Z

In reply to nevent1q…ftrv
_________________________

Hmm, those were like that because of the X16's narrow bus, is that right?

Assuming there's enough address bits for it, exposing the entire thing should be less logic, to implement, afaict. Noted, the CPU bus interface is far in the future (I'm starting from the output driver module) but I'll see what I can do.

I also earmarked "try to cram in the 65X glue logic", if I can find some IO ports to scrounge (trivial on ECP5, tricky on ice40).

while I have a background thread ruminating on hardware design ...

2024-08-13T15:44:28Z

In reply to nevent1q…2z2s
_________________________

while I have a background thread ruminating on hardware design stuff, if you have things you wish vera did (aside from you know being correct and not glitching), lemme know. Right now I'm loosely designing to the vera's progammer's interface, but especially at this stage the field is wide open if you wanted it to do something different.

(caveat: things that require more ram would lock us into ECP5-grade fpga + external SRAM, rather than maybe being crammable into the ice40)

Sleep produced what I think is a working superstructure for the ...

2024-08-13T15:37:44Z

Sleep produced what I think is a working superstructure for the gateware I want to write, but I have to put on my serious pants and go do a day job. This sucks.

The especially clever thing it does here, is the middle bit. It ...

2024-08-13T04:37:10Z

In reply to nevent1q…x0g4
_________________________

The especially clever thing it does here, is the middle bit. It wants to get a high VCO frequency so that it can divide back down and hit close to the mark, while also inheriting the lower jitter from that high VCO clock.

Normally what you do is mess with the output divider and the feedback divider, to get an output clock that's a multiple of your reference input. In effect you get to divide your input once, and multiply it once.

But the calculator here uses a little trick to get a 2nd divide!

Wow nextpnr's ECP5 PLL calculator is just wizardry. ...

2024-08-13T03:27:35Z

Wow nextpnr's ECP5 PLL calculator is just wizardry.

"Please make me a 25.175MHz clock from this 25MHz input clock"

"Easy: first, divide that input by 8 for a 3.125MHz reference. Feed that into the VCO with a 145x feedback multiplier, for a 453.125MHz frequency reference. Finally, stick an 18x divider on the VCO, and there you go: 25.1736MHz, 55ppm off from what you wanted."

🤯

Seems reasonable. Alternatively is there some way to add parts to ...

2024-08-12T05:05:12Z

In reply to nevent1q…pddh
_________________________

Seems reasonable. Alternatively is there some way to add parts to the BOM manually? Not sure what the convention is for socketed parts.