Please buy me a coffee if you find my facts to be mildly amusing.

Please ignore this post if you are a serial puppy kicker.
https://buymeacoffee.com/lowqualityfacts

i dedicate this to all fops critters here on fedi

Yeah, I'll be goofing with this all weekend.

FOSS software is not free as in beer or free as in freedom, it's free as in free kittens. You have to take care of them forever.

This is a story that started more than 25 years ago, when I was an student of computer sciences.

In 1987, when software was distributed through USENET newsgroups in split text files, Edward Barlow posted something special to comp.sources.games: "conquest – middle earth multi-player game, Part01/05"

Fast forward to 2006: Discovered this pioneering strategy game was trapped in legal limbo. What started as a "simple" relicensing project became a two-decade quest

https://vejeta.com/reviving-classic-unix-games-a-20-year-journey-through-software-archaeology/

@Taweret I’m definitely interested to see where they go with it.

You can tell that Carol sees it as a loss of individuality. Since we don’t know what kind of “hive of mind“ this is, we can’t say for sure if she’s correct or to what extent she’s correct. From what I can tell at the very least they were forced into a consensus.

So I’m sure a continuing theme throughout at least the first season will be “is the loss of individuality worth world peace?“.

My lord, to be able to write science this well. This is like the opening of an econ or law paper.
From Donald Hoffman's "The Interface Theory of Perception",
https://sites.socsci.uci.edu/~ddhoff/interface.pdf

Finishing my exploration of how I'd (re)design a control unit, not all the opcodes neatly fit within the classifications described yesterday. Some because there's not enough addressing-space (lets ignore this issue as uninteresting), others because they have special needs.

One thing we can do to free up opcode space is to half or quarter how many of the 32 registers can be operands, which yesterday suggested doing for multiplication.

1/4?

It'd certainly be appropriate to half the number of registers available for moving a value between any register pair, which incidentally I needed to repurpose the operand-fetch buses for.

To avoid weird bugs I'd specifically want opcode 0 to be noop.

For the sake of structs it'd be handy to include an offset-fetch opcode. With a read/write bit, a bit for which 16bit register holds the address, 5bit register ID, & 6bit literal offset... Leaves 3bits for the opcode.

2/3?

Control-flow in particular requires special operands!

I'd have a no-operand opcode for jump/call opcode expecting to find the address in certain registers, & possibly an I/O register. Include a couple bits to tweak this opcode's behaviour.

Or I'd have a jump-to-literal with 7 address-bits inline & fetches a further 16 from the next instruction-word, to cover the entire instruction ROM with plenty of room to grow.

Or have a 12bit inline offset with a call/jump opcode.

3/4

For conditional branches we could have 3bits identify to check, 1bit for expected value, & a, say, 7bit offset. Leaves a 5bit opcode.

A couple opcodes could add or subtract a 6bit literal from a value in of 4 register pairs.

A shorthand opcode could read/write a 6bit I/O address. With 5bits for the register, leaves a 5bit opcode. Another address an individual bit in the I/O address & set it to a given value (6bit opcode), whilst similar opcode skip the next if that bit wasn't as expected.
4/5!