erik

Looks like there is currently no RDMA support for thunderbolt, so it's a much higher latency connection. Apple has RDMA over thunderbolt working, so I wonder if it's possible on Strix Halo.

Oh, interesting. I assumed the PPU could pass through video the way the TMS9918 can. My mistake!

There is one obscure product that actually did use the feature. The Sharp Famicom Titler (or Famicom Editor) was a full Famicom that could show an external video input behind the Famicom graphics.

I found this video that shows a Playstation running in the background of Super Mario Bros: https://youtu.be/TCsle-J9YzY?si=oyj_zZCKGionnzLu&t=423

It doesn't seem that bad to me? Most of the problems that I see in that video look like recording issues where the camera isn't handling max brightness well. Recording CRTs is notoriously difficult!

Generally pixel art created for LCDs also looks good on CRTs, with tiny text being an obvious exception.

On top of this, I find ads on app store search results to be particularly bad. It's a business model that comes with all sorts of perverse incentives. It's so bad for users and legitimate developers.

The Mac Studio, in some ways, is in a class of its own for LLM inference. I think this is Apple leaning into that. They didn't add RDMA for general server clustering usefulness. They added it so you can put 4 Studios together in an LLM inferencing cluster exactly as demonstrated in the article.

Inference is almost certainly very profitable.

All the money they keep raising goes to R&D for the next model. But I don't see how they ever get off that treadmill.

Gaming is the only area where I expect plugins have limited permissions.

Do you mean mods on Steam? If you do, then that's down to the individual game. Sandboxing mods isn't universal.

many people have never actually seen the colour "violet" which is a single wavelength of visible light

The violet seen in a rainbow (in nature, not a photo) is legit single wavelength violet. Same with the rainbows created from shining white light through a prism.

It's true that you don't really get to see it in isolation very often though. Maybe some flowers, birds, or butterflies? Or maybe the purple glow you get from UV lights?

The patent on the lockout mechanism has expired and clean software implementations of the algorithm have been created. So the old legal protections no longer apply.

And while Nintendo still aggressively enforces their copyright on their old games, they probably don't care very much about unlicensed games being created for their very old hardware. It's just not commercially relevant to them.

But this means his pro and con opinions don't match typical opinions and this makes him polarizing. And hence some people will flag his articles reflexively or post reflexive dismissals. And Hacker News is heavily weighted to downrank polarizing articles.

I suspect this is it. A subset of users flag and/or downvote daringfireball on sight if it reaches the front page and the HN algorithm treats that as a strong single

That works until you see what appears to be 9 sprites on the same scan line in the border region.

I've seen the same. I don't think it's the reboot. My understanding is that NAND undergoes wear-leveling even when it is read only. The card shuffles data around its storage even when it hasn't been written to. And the firmware is unreliable.

Why mount the SD card read/write. Why not mount read-only.

I have seen dozens of name brand SD cards fail while mounted read only in a medium sized deployment of Pis. The problems mostly come from firmware bugs, not from nand wear.

I've long wondered why it remains the problem only on Raspberry Pi.

SD card firmware is often buggy and only heavily tested with windows. Camera manufactures will specify SD cards that are know to work with their cameras for this reason.

Upper right quadrant would be an 8-bit (or maybe 16-bit) CPU paired with a 3D graphics capable GPU. SNES + the SuperFX chip is the closest example I can think of. Similarly, there is the Genesis/Mega Drive + SVP chip.

I can't name a fully 8-bit machine with a 3d focused graphics chip. Maybe there are arcade boards?

Windows 95 was a big step forward though because it had actual process isolation and preemptive multitasking. While it wasn't very stable compared to Linux or NT, for the most part an application crash wouldn't bring down the whole machine the way it typically happened on classic Mac OS or Windows 3.1.

Larrabee was mostly x86 cores, but it did have sampling/texturing hardware because it's way more efficient to do those particular things in the 3d pipeline with dedicated hardware.

Modern retro computer designs run into the problem of generating a video signal. Ideally you'd have a tile and sprite based rendering. And you'd like to support HDMI or at least VGA. But there are no modern parts that offer this and building the functionality out of discrete components is impractical and unwieldy.

A FPGA is really just the right tool for solving the video problem. Or some projects do it with a micro-controller. But it's sort of too bad as it kind of undercuts the spirit of the whole design. If you video processor is orders of magnitude more powerful than the rest of the computer, then one starts to ask why not just implement the entire computer inside the video processor?

This goes to an impressive level of depth.

The ability to use a PC as a USB device opens up lots of fun possibilities. It's a little bit tragic that the required xDCI option is there in the hardware on this device, but it's not exposed and requires firmware hacking to access.

The hardware is capable, but the vendor has just turned it off and locked away the controls.

Youtube was also an acquisition.

Haven't heard much about successful Google acquisitions lately though.

I vouched for this comment, but it looks like you're shadow banned. You might want to email support.

The current and previous generations of xbox and playstation do use x86 CPUs with integrated AMD GPUs. But they aren't just PCs in a small box. Using a unified pool of GDDR memory* is a substantial architectural difference.

*except for the xbox one & one s, which had its own weird setup with unified DDR3 and a programmer controlled ESRAM cache.

In this case he had 150+ of them, so it wouldn't matter too much if he destroyed a few of them in the process. It would be more nerve-wracking to do this on something you don't have many of.

Throughput yes, latency no.

We were pretty proud that we had a graphical browser running under DSLinux a good 6 months before Nintendo released the Opera cart.

I think wikipedia is wrong. I don’t see how it would make sense to have a mmu in the ram expansion card.

I believe most wifi routers have 802.11b support turned off by default these days. Otherwise, ssh should be doable!

Another quirk: It was pretty common to load your homebrew software from a cartridge in the gameboy port. The cartridges would have some combination of ram and flash based storage or CF Card, and you could tell the cartridge to expose the storage or the ram as they were behind some sort of banking scheme. This meant that the storage system was mapped directly to the bus. So to save on ram, programs were run "in place", executing directly from the storage rather than being copied to ram first.

I made a few small contributions to this a long time ago. Nice to see that the website is still up!

Probably the most interesting feature of this project was how it handled memory. The DS only has 4mb of ram. And there is no MMU, so swap isn't an option. But the gameboy cartridge port has 32mb of address space mapped to the bus. And there are homebrew/piracy cartridges that fill that space with 32mb of ram. Which is great, except that the DS can only write to the cartridge port on 16-bit aligned addresses. And almost all software will assume that 8-bit aligned writes will work. To make use of the expansion memory the developers ended up creating a patched GCC that would convert any writes to unaligned locations to an appropriate read, 16-bit write, and set of shift operations.