Not sure where that comes from. The original release box art [1] says it will work on any PC with 512KB of ram. So that's an 8088 running at just 4.77 MHz.

But that's far from the lowest spec port of the game. The Commodore 64 version might have been missing quite a few features (like stadiums, police/fire stations and railways), but the main city simulation loop was there in just 64KB of ram and a 1MHz 6502.

And the BBC Micro/Acorn Election port was even more impressive. Had basically all the features of the full Amiga/PC/Mac version, only missing Music/Sound/Animation. With a 2Mhz 6502 (or 1Mhz on the Election) and just 32KB of ram.

[1] https://images.launchbox-app.com/79861ce4-75ea-46dd-b46e-521...

IMO, the main reason Sony are discontinuing ps5 disc manufacturing now is so by the time they get around to launching the ps6, the move away from optical discs is old news. They know the move is unpopular and they don’t want the drama associated with the launch of their new console.

I’m less sure about what will happen to bluray movies. But this is not a good sign.

Besides, even with the automated start system, the actual spin-up time of the turntables would have been a little chaotic. I suspect they were only aiming to get the four turntables within about 100ms of each other. The decrypted signal itself could then be used for the final fine-tuning of the timings (which also included adjusting for any speed-of-light delays)

If you weren't within 20ms, the operator would only hear noise (like a radio). Once they were within ~20ms, the operator would start hearing silence and would tune the phase until all noise went away.

You don't really need exact synchronisation because like a radio, the operator could just scrub the tuning to find the silence.

The synchronised clocks meant that once the operators had locked on, it would stay locked for a long time.

[1] https://www.nsa.gov/portals/75/documents/about/cryptologic-h...

It was in development for a long time at a critical point in history. It seems to have started off as a software-first project (or possibly even software-only), then switched to hardware-first near the end of development. And not every effect was implemented in the hardware renderers.

Half-Life has a lot of grid textures that really need bilinear filtering and mipmapping to look decent, and they look even better with anisotropic filtering.

Many other games that released a little later (like Decent III) actually fully removed their software renderers before release because games needed to be hardware-only if they actually wanted to compete on visual quality.

And while hardware image decoders might be dubious, hardware video decoders are very much worth it.

Media encoding is actually an FPU workload, and a pretty brutal one at that.

Media encoding might not use much floating point arithmetic, but it does use massive amounts of packed integer SIMD. And all SIMD instructions (both integer and floating) execute on the shared FPU, not the integer unit. It's only scalar integer instructions that execute on the integer unit.

Which leads me to believe that Bulldozer's shared FPU is not a bottleneck at all. Most evidence seems to point to the shared frontend being the primary bottleneck (which is why steamroller puts some effort into duplicating the instruction decoding, for some pretty large IPC wins)

Steamroller did see 30% IPC improvements over Bulldozer (all the design work would have been done before they switched to Zen), but AMD canceled the full FX version, and only ever shipped the APU version of Steamroller (with only 2 modules, aka 4 threads).

If they had shipped a Steamroller FX cpu, the generational improvements would have looked similar to many of the generational improvements that Zen received... but didn't really matter as Bulldozer started so far behind.

I actually remember media speculating that Sun didn’t want to take the next step and actually file a lawsuit, because they didn’t have enough resources to go up against Google in court.

Then Oracle bought Sun, and suddenly the unproductive negotiations transformed into a lawsuit.

While it was difficult to make it follow instructions, GPT-2 was still reasonably good at generating SEO-spam websites, and reasonably easy to make it do so. AI slop was a very obvious usecase for LLMs as capable as GPT-2, and we are talking about an era were everyone was already concerned about the way "fake news" on social media was being used to manipulate people. Perhaps even more concerned than we are today.

But all evidence suggests OpenAI also had strong ulterior motives. They were busy readying the API groundwork for monetising it, and wanted to delay any competition by as much as possible.

Otherwise most modern CPUs would be labeled as either 256-bit or 512-bit.

These days we generally label CPUs based on the width of the general purpose registers (though, it gets messy with things like the 68000). I personally suspect we won't ever see GPRs wider than 64 bits.

They aborted the go-around attempt because they were literally at the end of the runway; Probably because they thought it would be "safer" to run off the end without the engines rapidly reaching full thrust.

If so, it’s tight… but i feel like they should have made it if they had stuck to that plan. They commanded full power 15 seconds before the crash, and were pretty close to (if not slightly above) their stall speed (depends on load). I suspect they just needed another 10-20 knots and enough energy to climb.

And for all we know, it might be officially supported in their internal builds of Visual Studio.

The "how" it does dual-issue is not documented at all, so I'm speculating. There is no smoking gun saying "register renaming". While it would be possible to implement its known capabilities without any kind of renaming, it would be so much simpler to implement it with register renaming.

The thing is.. once your forwarding network and hazard detection gets complicated enough, it basically becomes a janky form of register renaming. So it's cleaner to just implement proper register renaming, and actually saves hardware.

While the A53 might issue in-order, the pipelines have different lengths and they don't finish executing in order.

I find the fact the A53 can speculate a few instructions past a cache miss to be very interesting, along with the fact it can issue two writes to the same logical register in a single cycle.

Also, the smoking gun is that the A510 (same lineage as the A53) is documented to do out-of-order issue (see chipsandcheese again [1]), so it must be doing register renaming. ARM still insist on still calling it an in-order core because it's OoO is so much more limited to modern OoO cores, but it's more OoO than early PowerPC designs (including the G3) that everyone is happy applying the OoO label to.

[0] https://chipsandcheese.com/p/arms-cortex-a53-tiny-but-import... [1] https://chipsandcheese.com/p/arms-cortex-a510-two-kids-in-a-...

And while courts might have ruled that a CAPTCHA might count as a "technological measure" they haven't gotten as far as ruling them as "effective" yet.

But in general yes. The protection scheme doesn't need to be well designed or free of design flaws to count as "effective". But from what I can tell, it does need to be a valid attempt at some cryptographic scheme requiring a secret known only to the copyright holder.

[0] https://law.justia.com/cases/federal/appellate-courts/F3/387...

But the original question was asking why disabling data prefetching to a memory region didn't automatically disable instruction prefetching at the same time.

And the answer is that speculative execution is a completely different mechanism that I'm not even sure can be disabled, at least not per memory region.

I really hope not. My understanding is that to be "effective" it needs to at least be a form of encryption with a secret key. At least, I'm not aware of any case law that allowed anything less than that.

IMO, "dummy notes" are nothing more than a form of obfuscation. If it's obvious how to filter them out, then I don't think it comes close to meeting the bare minimum of what might count as an "effective technical measure".

Of course, who knows what way the courts will rule if it ever reached that far.

It's simply speculative execution. Which doesn't look any different to regular execution. The fetcher has no idea that its predicted branch is about to invalidated and flushed, otherwise it would never have issued that fetch.

Actually, on a modern OoO core, [0] it's very rare for the instruction fetcher to not be doing speculative fetches. Even when it's not predicting a branch, the fact that it has "predicted" the lack of a branch is speculative in itself. It assumes it didn't fetch a branch in the last cycle, but it can't be sure until after instruction decoding, which takes at least 2 cycles (more on larger L1i caches).

About the only time the instruction fetcher is not doing speculative fetching is for a single cycle after each miss-predicted branch.

[0] Or even something technically in-order, like the Cortex A53 cores here. They might issue in-order, but because of how they implement dual issue, they look somewhat close to a simple OoO core... I suspect they actually do register renaming. And (most importantly) importantly they have a branch predictor.