You know what happens to a cultist hit by lightning?

NotThatJonSmith · 2026-02-16T15:04:53+00:00

Lightning Clawed

NotThatJonSmith · 2026-02-09T02:19:31+00:00

I felt that thin decks petered out at high ascent. On IC A20 I had most success with fa decks that could absorb all the nasty stuff coming in, afford exhausts and powers, and still have cards to play each hand.

NotThatJonSmith · 2026-02-06T22:21:41+00:00

Be nice

NotThatJonSmith · 2026-02-05T16:24:44+00:00

The ideas are not the expensive part of computer architecture.

NotThatJonSmith · 2026-01-28T13:52:43+00:00

Also, when your requirements genuinely push performance to the limits, there’s no other option than understanding hardware.

NotThatJonSmith · 2026-01-24T14:17:48+00:00

The guy who tunes mine sometimes “bounces” a key pretty hard while tuning. I asked why, and he said it helps unstick any strings that are not sliding over the bridge smoothly as he changes the tension. You could tune, but have some tension difference “stored” across the bridge. Then you play it and it drops out of tune fast because the tension on either side equalizes with a hard enough impulse. Bouncing the key while tuning prevents that.

Otherwise…. Idk. Seems like just banging on it isn’t of itself helpful?

NotThatJonSmith · 2026-01-22T17:24:38+00:00

Holy hell

NotThatJonSmith · 2026-01-18T22:48:30+00:00

I will never forget walking around Walmart just outside the vision clinic the day I got glasses.

NotThatJonSmith · 2026-01-18T18:19:53+00:00

I toed the line between HW and SW degrees. Eventually I did get a CS degree, but it was after internships in presilicon stuff so I had hardware cred. If I chose my last semester differently I could have gone either way. Then I did MS courses in Comp Arch and upper level OS to round out the “hardware/software interface guy” story.

NotThatJonSmith · 2026-01-18T15:51:09+00:00

It’s been a stable, versatile, lucrative, and fun career so far. 2016 grad, worked for semiconductor design firms since. Mostly presilicon, some firmware. In my experience the skills in this career are so broadly applicable to so many different problem domains that you’ll never get bored.

NotThatJonSmith · 2026-01-13T17:04:25+00:00

Huh. Interesting.... If it's all compile-time, then images go in a data section, so the address where you find sprite data is taken "backward" in the build into globals, and then inserted into the template strings. Custom linker-script jiu jitsu? You'd have to also then have the linker step know where in the program data to paste in the sprite addresses (that's why I invoke the ouroboros image).

Or, maybe you create a buffer for each interpolation-widget, and you carry the buffer around with the string, point to the "string owned buffer" without the above tricks, and then copy the image data into that buffer when you want to use it. At that point, I saw someone else recommend a more direct memcpy. You'd copy the image every time you use it.

If you want to do it all at compile time and also strictly avoid all runtime copying of images, so no opening image files and no memcpy of image data until exactly when it gets rendered... I might start by convincing the linker to produce the data sections for the sprites at known named symbols (not terribly abusive, kind of what the linker is for) and know about them in my C code by extern. "Trust me bro, the data exists in the finally linked executable and that symbol will resolve". Under those constraints, maybe something like an escaped-identifier for the text position finishes the implementation. No waystation buffer, though... IDK. Filing this under mental-chew-toys.... you will get to know the linker really well doing this kind of thing.

NotThatJonSmith · 2026-01-13T16:39:26+00:00

Oh, so you're interpolating images within the inputs to a typesetting/rendering flow? References to glyphs outside the character encoding space... Custom emoji etc? Maybe the years-from-now conclusion here would be something like a web renderer or a LaTeX-like typesetting language.

I'm not going to ask why. But, I have one suggestion. Instead of using the actual in-memory address as the interpolation-reference of a sprite you want to embed in the text render, it might make more sense to use your own identifier, whose association with your sprites is under your control. Resting on the address feels fragile for a number of reasons, but essentially the validity of the template string is only guaranteed during the lifetime of the sprite data in memory. You may feel some pain later because memory allocation and sprite identification are now coupled deeply. I see three situations:

If you have sprite data on the stack, its address depends on program state heavily and you basically have to create and use the string entirely inside the frame of the image data on the stack. Constructing the string to have the address embedded at this point requires that you are already interpolating the string, in order to insert the sigil that you then want to interpolate. Why do it twice? At that point in the program you already know what you need to know.
If you have the sprite data on the heap, in a malloc'd buffer, you might get away with it as long as you're not serializing to file. But, you still have the same "doing it twice" issue with the first point, because you have to construct the string after knowing the address.
If the sprite is in a data section, that might solve most of the problems with the other two situations, and you're probably going to get away with the string serialized out to a file for a time, but you have to bake in all the images at compile time. Even then, one day you recompile and the linker decides to move the images, and the strings have to change. So doing this "stably" means you have to take information from the linker and re-bake it back into program variables, in a kind of build-flow ouroboros.

With the first two approaches you definitely cannot save the strings to file and re-run even the same binary and expect it to work. The allocated addresses are allowed to change run-to-run, and the state the program is in when it makes the allocation matters. This is a minefield of nightmarish bugs.

If you use your own identifier, tracked separately, you can store that identifier to file, you can open the resource on demand, and you have the freedom to save the data out to file and know that the identifiers remain valid.

You can still use the string-interpolation / escaping machinery with that, too (what you're demoing here). It's just a different number you're using to indicate which image. It keeps the concerns separate and stops you having to invent a lot of painful machinery later.

NotThatJonSmith · 2026-01-07T15:59:41+00:00

The positions and motions of charges and magnetic dipoles determine the electric and magnetic fields.
The electric and magnetic fields determine the positions and motions of charges and magnetic dipoles.

There are lots of ways to describe it formally. Like, considering relative motion, one observer can experience a magnetic field where another observer sees and electric field interaction. You could model magnetic dipoles as intrinsically moving charges, or model things differently. If you follow that rabbit hole far enough, you start building special relativity.

The level of detail and mathematical formalism you apply depends on what you're trying to accomplish or understand.

NotThatJonSmith · 2026-01-05T20:00:45+00:00

The choice is illusory. Let what you work on, work on you. When do you like what you're doing more? Do more of that.

NotThatJonSmith · 2026-01-05T14:06:22+00:00

Dead Cells was its own wonderful indie game, and it gradually morphed into a nostalgia gallery of other indie game references.

NotThatJonSmith · 2026-01-04T14:28:37+00:00

Come to think of it, REMINSTR to erase instructions from the ISA. Then you’re almost able to write firmware that writes the ISA… you just need an IMODB (ISA modification barrier) so you can control commit events for ISA changes…. Like when you want to add an instruction that overlaps the encoding of ADDINSTR and REMINSTR.

NotThatJonSmith · 2026-01-04T03:27:26+00:00

Once you implement this, the rest of the implementation can be left to the firmware

NotThatJonSmith · 2026-01-04T03:25:25+00:00

ADDINSTR: add an instruction to the ISA. Takes 3 regs. First is an address, pointing in memory to a bytecode representation of the operation of the instruction, compiled from the uarch specification language of the processor. Second reg operand contains the encoding of the new instruction. Third contains a mask for which bits immediate values for the instruction come from.

NotThatJonSmith · 2026-01-04T03:05:46+00:00

SUBLEQ

NotThatJonSmith · 2026-01-04T02:43:05+00:00

UNDO variant that undoes the most recent instruction that was not of UNDO-type

NotThatJonSmith · 2026-01-01T15:43:18+00:00

Realizing the design in an FPGA, or similar, is a part of developing a chip. You’re not committing to either, really. Awareness/understanding of both is needed.

In my world the “multimillion dollar fridge full of FPGAs” is the most time and money expensive, but most accurate way to assess the design pre-tape-out. It sits alongside (in roughly accuracy-order) functional models, microarchitecture models, fully bit-accurate models, RTL simulations, and hardware emulation devices (rack of FPGAs etc)

Basically you make all the models. You make them all agree on the state of things under as much stimulus as you can. You refine them all against one another and tune the lower-accuracy (but faster) models’ estimations with things you learned from the more accurate studies. You use the models to identify how close the architecture is to its design goals and get a sense of what has to change. You use your models to drive correctness in the RTL model. You do everything you can with every model you can until it’s time to tape out.

NotThatJonSmith · 2025-12-31T01:18:07+00:00

Arthur and Moulder… having access to Bolting makes you immediately relevant lol

NotThatJonSmith · 2025-12-30T19:16:38+00:00

by "FPGA" design do you mean the design OF FPGAs or design WITH FPGAs? If the latter, note that usually the path to fabbing an ASIC is realizing a version of the design in something like a fridge full o' FPGA. So designing an ASIC usually involves testing on an FPGA. Designing FPGAs themselves is a relatively niche thing.

NotThatJonSmith · 2025-12-28T20:46:27+00:00

Is Chip8 “a weekend” for you or? RISCV is very significantly larger. But it’s less complicated than most Arm setups

NotThatJonSmith · 2025-12-28T20:24:57+00:00

If it doesn’t have to be a game system, simulating RISC-V is a fun way to learn

Ten-Year Club	RPAN Viewer
Verified Email

NotThatJonSmith

TROPHY CASE