For those unaware, the "SSL Added and removed here!" image is a reference to a diagram describing unencrypted communications between Google datacenters that leaked from the NSA in 2013 [1].
Once I had a professor who had a top secret clearance and did some government work. He couldn't reference this because it's never been unclassified. But in one of his courses, he had an image of these two circles aligned just like this when discussing a relevant topic, and I don't know if anyone in my section picked up on it.
Still kind of insane to think about the US government using underwater submarines or something to hack into the communications of US companies to spy on Americans and that not being, like, a bigger deal in 2013.
I am convinced [1] most people can fall into handling anything with levity. You see the same thing happening in the medical field, and undoubtedly in more macabre organisations as well (see WW2 testimonies, for example).
[1] Unsourced learned experience, consider with a grain of salt.
One of the coolest revelations to me, just looking at the status page [1] is that the Wii only had 88 MB of RAM - split between 24 MB built in to the SoC and 64 MB of GDDR3.
Given that this is the case, ntpd using 15% of the system memory means it was using about 13 MB of RAM - hardly a huge chunk by today's standards but not small either. I wonder if reducing the number of time servers would improve this much? On my system I can see I'm tracking about 9 servers from the debian pool.
Compare this to the XBox 360 which even at the time had 512 MB, it's really amazing how much they managed to squeeze out of such a tiny chip.
> Rebooting NetBSD reboots the whole console, and not just the NetBSD ‘app’, so you’ll find yourself back at the Wii Menu after any kernel patch or system upgrade.
This can be mitigated by installing Priiloader, and having it autoboot into either the Homebrew Channel or the NetBSD .dol file
Based on previous experience with Wii homebrew, you could probably circumvent the (expected) reliability issues of the smaller SD by swapping to a regular USB thumbdrive post exploit, ports are only 2.0 but you're bound by processor anyway
I love this sorta stuff! I once had my blog hosted on a docker container on my Robot Vacuum. I switched back to a saner host when I started getting uptime alerts when the vacuum went under my bed and lost wifi signal!
I had the awesome, yet terrible experience to work on an obscure Nintendo feature.
By networking, I am assuming you mean console stack... which I had experience with myself, and yeah... not great. But even more, their web services (more than 10 years ago at this point, hopefully better now) were so, so bad.
The thing that struck me then, and continues to seem true, is how much they just don't really seem to care and that they singularly focus at being good at innovating where it matters: games and differentiated hardware.
Young me thought they were silly for being so "behind the times". Older me respects it more.
> The thing that struck me then, and continues to seem true, is how much they just don't really seem to care and that they singularly focus at being good at innovating where it matters: games and differentiated hardware.
You'd think they'd just admit that and outsource their network-related needs to a company that specializes in that sort of thing.
It has been awhile, but from what I remember Nintendo was extremely skimpy with the memory allocated to the TCP stack on the Wii meaning it couldn't open the window up hardly at all and had a tiny bandwidth delay product. This is why updating the system took absolutely forever, even when your local network and the Nintendo servers had ample bandwidth.
Beyond that the servers were also badly implemented and from what I understand they had to call in a third party company to install TCP PEPs[1] in front of the servers to get acceptable performance.
The Wii has ample compute power and memory to max out a Fast Ethernet (100Mbps) port, but due to the design decisions it was barely able to push 1Mbps in real life. This was becoming a problem as system updates were getting larger and the built-in "channel" games were moving beyond NES and SNES ports to actual third party indie titles that sometimes got rather large.
Yeah also in general the WFC code is a bit dated and not very secure.
This actually reminds me of two very interesting bugs which used together basically make it so that you can play WFC games (basically just Mario Kart Wii, nowadays) as simple as changing the DNS settings on your Wii
1. Firstly, as long as you set a particular field in the certificate, it just is completely happy with an invalid cert. (This was fixed by the NWC library by the time it was released In Korea, notably, although this bug was present in DWC for a long while.
(Aside:
I actually suspect that this bug was present in the RVL SDK (used by games and such on the PPC), but also is caused by the same cause as the signing/Trucha bug[1]. While the latter is a IOS specific exploit, it wouldn't surprise me if the same code was used in both this and DWC (the networking library). Given that Mario Kart Wii has an associated IOS version of IOS36[2], but DWC code isn't part of IOS, my hunch is that they used either the same or similar validation logic OR both bugs were squashed a part of some security related cleanup.
I haven't actually gone through the reverse engineering effort to confirm this yet, but given that this doesn't work on the Korean version of MKW, which notably uses a later version of IOS and other libraries, my hunch is that those bugs are one in the same. The fix timing at least seems interesting to me. Anyway side note over.)
2. The networking library also has an RCE caused by a buffer overrun, basically from the first message it has a length that's unchecked and the DWC library blindly memcpys data from the packet. This is kinda why it's important to have some sort of patchset that fixes these bugs (because the operating system and libraries ship with the game and you can't update those except for in memory).
The culmination of this is all you have to do is
1. Change your DNS settings on your unmodified Wii to point to a specified DNS server.
2. Start Mario Kart Wii (probably, although some other games work too), open up WFC
So that the game...
3. Does a DNS lookup for the WFC server which intentionally links to a 3rd party server
4. Passes validation of a bad cert which intentionally sets one of the fields to a null value in order to make the Wii accept it
5. Receives a message that contains an exploit which patches the game in memory to fix the known RCEs and setup URLs to resolve to different domains instead of using the old WFC ones among other things (such as cheat reporting that is all client-side based, etc)
all so you can play Wii games (probably Mario Kart Wii) online 11 years after WFC shut down for good :)
The author should have just disabled TLS! It would have been perfectly reasonable under the circumstances, and then the website would have been fully Wii-hosted, no caveats!
https://blog.infected.systems/status/ for a plaintext status of what the Wii's doing load-wise (if it's still up, updated every ~15 minutes according to the blog).
Unfortunately the time you get to the point of even valid HTTP responses it will look less like a SNES and more like whatever-you-plugged-into-a-snes-for-power. E.g. the original Family Computer Network System addon already had more RAM and CPU power than the original console it attaches to just to interface as a modem at all, let alone something "basic" like CGI.
The Wii is probably the first Nintendo console where all the hardware you need to do this is fully built in (though maybe the Nintendo DS, depending how much you're willing to try to get Linux + your server to fit in memory without plugging in a RAM expansion pack to the GBA slot).
This leads to an interesting philosophical debate about where the line to "cheating" is. I'd imagine the NES is more than capable of handling HTTP. I own a small managed network switch with a Web UI (and CGI) all running on an 8051 built into the switch ASIC, and if that can do it, it doesn't seem like such a far fetch that the NES can. The hard part is storage and I/O.
This is purely theoretical, but a 6522 could be used to bitbang SPI, opening the possibility of adding an SD card and Ethernet controller (with a chip like the Wiznet W5500). Add a small amount of SRAM (~16/32Kbit) and a loader ROM, and you'd be able to make the NES into a workable general purpose computer using only the cartridge slot. If needed, one could steal an interrupt from the expansion slot.
Admittedly, this could still be considered "cheating" because the W5500 has a built-in TCP/IP stack, but personally I would feel comfortable saying the NES is hosting the site.
I feel like this would definitely be possible. I was reminded of https://mitxela.com/projects/kiloboot, which uses an ENC28J60 for the ethernet stuff. I feel like you could probably quite easily bitbang SPI, given it's quite a forgiving protocol, just dedicate a couple of addresses in the memory space to interact directly with the bus (maybe with a separate shift register chip if you want to make things a bit easier). If you give up writing anything to the screen, I'd imagine you could just spin until something happened on the ethernet side, then read the requested path, pull some data off the ROM that corresponds to that path and send it back again
Yeah, the DS probably is the first one that has enough inbuilt support since it has support for Wi-Fi out of the box although Linux seems a bit heavyweight for this perhaps(?)
DSLinux exists but you need the RAM expansion cartridge. from what I found it supports networking but you've only got 8MB minus the space used by the system. and an ancient binary-only toolchain to wrangle with
> The Wii is probably the first Nintendo console where all the hardware you need to do this is fully built in
Even though accessories were required, you could probably do this with both the N64 Disk Drive or GameCube network adapter. Both were network interfaces that still dispatched to the underlying system.
The N64 Disk Drive [1] would be a fun case, because the storage medium is a glorified floppy disk drive. It does connect over a modem, so there'd be some fun middleware.
The Super Nintendo had a network adapter as well, and both the NES and SNES [2] had satellite networking adapters in Japan. IIRC, there was also a network adapter for the Game Boy. I'm not sure how or if those would work, or how much control was surrendered to the hardware/software of the network adapter itself to let it do all the driving.
DSLinux absolutely runs in 4 MB (i.e. w/o a RAM expansion pack), it's just going to take a bit of work to also fit the web server + whatever CGI they wanted without a pack.
The EZ-Flash V 3-in-1 actually added a whopping +16 MB (128 Mb) of PSRAM! Growing up I only ever had the +8 MB pack from Opera... what a weird bit of history that browser port was :).
For SNES - absolutely, if you get an FXPAK PRO and proxy over USB. It would be slooow, though, the transfer rate isn’t amazing (limitation on the firmware side, probably due to ancient USB standard?). Basically though - write incoming packets to a well known place in RAM, read another well known place in RAM for outgoing packets. The good news is that you have 12MB of ROM to work with. The bad news is that you really don’t want to transfer too much data at once, and you only get 128Kb of RAM. Not sure if you could do this easily with an NES, I don’t know if the everdrive supports RAM access over USB (it doesn’t on GB* which makes me super sad).
I don't know if this is cheating, but there were a few NES games that had extra RAM on the cartridge. Pretty easy to do as the cartridge slot directly breaks out the data and address lines from the CPU.
Whatever you end up doing on the NES would end up not being a website anymore. You want to interface with joystick port 1? Not TCP/IP anymore. Whatever gateway you would use to connect to the custom protocol would have a lot more oomph than a NES.
I don't think so without significant work, NES has only 2KB of RAM and an 8 bit CPU without MMU or many niceties taken for granted in General Purpose OS's
I doubt you can go much further back than Fifth Gen (of consoles) or so
You would have to burn a cart that contained the webpage and TCP stack, as well as having the ethernet hardware, but there are tricks you can do to reduce the memory requirements. It's not going to be able to handle more than a packet or two at a time, but I've seen TCP stacks squeezed onto really low end hardware. Obviously you won't be able to open much of a TCP window so performance will be lousy, but it's a 1.8Mhz CPU so that was always going to be the case. Just don't have any misconceptions about being able to run TLS on it. Remember that TCP was developed on machines that did not have a lot of memory or even CPU cycles.
An Atari 2600 might be a bridge too far, but a NES should be able to do it.
Fair enough, seems a lot simpler than what I had in mind with expansions and custom software, but also a far cry from OP's "flash" a general purpose OS and more or less get to working
All the mainstream 6th gen consoles had first party support for wired ethernet; although only the Xbox had it built in (well, the slim ps2 had it built in too). I'd expect they've all served web pages at one time or another.
5th generation could probably make it happen, but without ethernet, you're looking at a modem or serial interface, and in today's world that's almost certainly talking to something else in your house that's a better host. :P Wikipedia categorizes the Apple Pippin as 5th gen, and it's more or less a Mac with a weird pinout for the PCI slot, so I'd guess it's the easiest to get ethernet with; without resorting to something that has more smarts than the 'host'
Most of my switches are unmanaged, so probably not. Maybe the dsl or cable modem or whatever can serve pages, but especially if it's isp owned, it might not be easy to.
Working from the fact that the NetBSD sees the OHCI controllers which are on the Starlet's AHB this runs with AHBPROT disabled (as does most homebrew), so NetBSD can in theory not only interact with Starlet mailboxes (as any normal game), but can also do pretty much anything to it as the entire Starlet address space is R/W accessible from Broadway (which on the other hand makes interacting with Starlet pretty much irelevant for normal use, as you can interact with the hardware directly using normal drivers instead of going through IOS)
Giving the author the benefit of the doubt, that's probably how I'd do it. Not hosting the Wii in a datacenter, but set up a VM as a proxy, as to not expose my home internet connection to the world.
You're not going to win an points with the family when they can't stream Disney+ because you had to expose a webserver running on that old Wii to the internet, using your home internet connection.
For those unaware, the "SSL Added and removed here!" image is a reference to a diagram describing unencrypted communications between Google datacenters that leaked from the NSA in 2013 [1].
[1] https://arstechnica.com/tech-policy/2013/10/new-docs-show-ns...
Once I had a professor who had a top secret clearance and did some government work. He couldn't reference this because it's never been unclassified. But in one of his courses, he had an image of these two circles aligned just like this when discussing a relevant topic, and I don't know if anyone in my section picked up on it.
Still kind of insane to think about the US government using underwater submarines or something to hack into the communications of US companies to spy on Americans and that not being, like, a bigger deal in 2013.
That :¬) face makes for a great custom emote in security-related channels.
It’s so funny so see a top secret label below what’s clearly a hastily scribbled diagram
I am convinced [1] most people can fall into handling anything with levity. You see the same thing happening in the medical field, and undoubtedly in more macabre organisations as well (see WW2 testimonies, for example).
[1] Unsourced learned experience, consider with a grain of salt.
Looks like a design interview round
I used to have that as a shirt, but I think I lost it: https://philkast.com/2013/10/30/spying-tshirt.html
>SSL Added and removed here!
And CloudFlare!
One of the coolest revelations to me, just looking at the status page [1] is that the Wii only had 88 MB of RAM - split between 24 MB built in to the SoC and 64 MB of GDDR3.
Given that this is the case, ntpd using 15% of the system memory means it was using about 13 MB of RAM - hardly a huge chunk by today's standards but not small either. I wonder if reducing the number of time servers would improve this much? On my system I can see I'm tracking about 9 servers from the debian pool.
Compare this to the XBox 360 which even at the time had 512 MB, it's really amazing how much they managed to squeeze out of such a tiny chip.
[1] - https://blog.infected.systems/status/
> Rebooting NetBSD reboots the whole console, and not just the NetBSD ‘app’, so you’ll find yourself back at the Wii Menu after any kernel patch or system upgrade.
This can be mitigated by installing Priiloader, and having it autoboot into either the Homebrew Channel or the NetBSD .dol file
This reminds me of a project I saw more than 24 (!) years ago. Someone made a webserver for the GBA.
It seemed magical to me at the time and I still remember going to this site often to see updates (that's why I remember the URL).
Thankfully the Wayback Machine still has it:
https://web.archive.org/web/20030204043536/http://fivemouse....
Based on previous experience with Wii homebrew, you could probably circumvent the (expected) reliability issues of the smaller SD by swapping to a regular USB thumbdrive post exploit, ports are only 2.0 but you're bound by processor anyway
I love this sorta stuff! I once had my blog hosted on a docker container on my Robot Vacuum. I switched back to a saner host when I started getting uptime alerts when the vacuum went under my bed and lost wifi signal!
Haha what? I simply must know more about how you achieved that!
See, I would have just put a WiFi extender near my bed...
FYI - instead of Photo Booth you can use Quicktime Player and "create new movie recording". I believe that should fix the image flipping problem.
Yeah or OBS.
>I was doing this bit using a capture card and Photo Booth on macOS which doesn’t actually support disabling the image-flip on the video feed
Please use OBS
I was surprised at the Photo Booth usage as well. I would have just recorded it with the QuickTime Player as if it were an iOS device.
Performance is not bad. It's clear they aren't using Nintendo's TCP stack, as it was notoriously terrible on the Wii.
Nintendo's networking is bad no matter what console somehow
I had the awesome, yet terrible experience to work on an obscure Nintendo feature.
By networking, I am assuming you mean console stack... which I had experience with myself, and yeah... not great. But even more, their web services (more than 10 years ago at this point, hopefully better now) were so, so bad.
The thing that struck me then, and continues to seem true, is how much they just don't really seem to care and that they singularly focus at being good at innovating where it matters: games and differentiated hardware.
Young me thought they were silly for being so "behind the times". Older me respects it more.
For a while they told you open all UDP ports for the Nintendo Switch. Now they just tell you to open 1024 to 65535.
Source for everybody not believing this:
https://en-americas-support.nintendo.com/app/answers/detail/... (Point 4 under "On a PC or smart device")
> The thing that struck me then, and continues to seem true, is how much they just don't really seem to care and that they singularly focus at being good at innovating where it matters: games and differentiated hardware.
You'd think they'd just admit that and outsource their network-related needs to a company that specializes in that sort of thing.
Interesting! Can you perhaps elaborate a bit more on what you saw at the time, in the sense of why it was so bad (Nintendo lawyers, look away)?
It has been awhile, but from what I remember Nintendo was extremely skimpy with the memory allocated to the TCP stack on the Wii meaning it couldn't open the window up hardly at all and had a tiny bandwidth delay product. This is why updating the system took absolutely forever, even when your local network and the Nintendo servers had ample bandwidth.
Beyond that the servers were also badly implemented and from what I understand they had to call in a third party company to install TCP PEPs[1] in front of the servers to get acceptable performance.
The Wii has ample compute power and memory to max out a Fast Ethernet (100Mbps) port, but due to the design decisions it was barely able to push 1Mbps in real life. This was becoming a problem as system updates were getting larger and the built-in "channel" games were moving beyond NES and SNES ports to actual third party indie titles that sometimes got rather large.
[1] https://en.wikipedia.org/wiki/Performance-enhancing_proxy
I respect the prioritization. It doesn't actually need the best web services, it really only needs enough to play Mario kart online.
Yeah also in general the WFC code is a bit dated and not very secure.
This actually reminds me of two very interesting bugs which used together basically make it so that you can play WFC games (basically just Mario Kart Wii, nowadays) as simple as changing the DNS settings on your Wii
1. Firstly, as long as you set a particular field in the certificate, it just is completely happy with an invalid cert. (This was fixed by the NWC library by the time it was released In Korea, notably, although this bug was present in DWC for a long while.
(Aside:
I actually suspect that this bug was present in the RVL SDK (used by games and such on the PPC), but also is caused by the same cause as the signing/Trucha bug[1]. While the latter is a IOS specific exploit, it wouldn't surprise me if the same code was used in both this and DWC (the networking library). Given that Mario Kart Wii has an associated IOS version of IOS36[2], but DWC code isn't part of IOS, my hunch is that they used either the same or similar validation logic OR both bugs were squashed a part of some security related cleanup.
I haven't actually gone through the reverse engineering effort to confirm this yet, but given that this doesn't work on the Korean version of MKW, which notably uses a later version of IOS and other libraries, my hunch is that those bugs are one in the same. The fix timing at least seems interesting to me. Anyway side note over.)
2. The networking library also has an RCE caused by a buffer overrun, basically from the first message it has a length that's unchecked and the DWC library blindly memcpys data from the packet. This is kinda why it's important to have some sort of patchset that fixes these bugs (because the operating system and libraries ship with the game and you can't update those except for in memory).
The culmination of this is all you have to do is
1. Change your DNS settings on your unmodified Wii to point to a specified DNS server.
2. Start Mario Kart Wii (probably, although some other games work too), open up WFC
So that the game...
3. Does a DNS lookup for the WFC server which intentionally links to a 3rd party server
4. Passes validation of a bad cert which intentionally sets one of the fields to a null value in order to make the Wii accept it
5. Receives a message that contains an exploit which patches the game in memory to fix the known RCEs and setup URLs to resolve to different domains instead of using the old WFC ones among other things (such as cheat reporting that is all client-side based, etc)
all so you can play Wii games (probably Mario Kart Wii) online 11 years after WFC shut down for good :)
[1]: https://wiibrew.org/wiki/Signing_bug
[2]: https://wiibrew.org/wiki/IOS36
Not to be a stickler, but the blog isn't actually FULLY hosted on the Wii until you move that Caddy instance to it or drop it :)
Nice work.
The author should have just disabled TLS! It would have been perfectly reasonable under the circumstances, and then the website would have been fully Wii-hosted, no caveats!
lol rare wowfun sighting made me happy (hi from nacho@atmosphir)
:)
The writer's post on the fediverse announcing this post gave me a good chuckle when it came across my feed.
https://infosec.exchange/@alexhaydock/114377262481451962
got hugged.
Maybe the next post will say "Blog is hosted on a Nintendo Wii (running Varnish)"
It puts up a bit of a fight.
https://blog.infected.systems/status/ for a plaintext status of what the Wii's doing load-wise (if it's still up, updated every ~15 minutes according to the blog).
https://archive.is/6QvVA
Loads for me at the moment
OP's been preparing for this moment: https://blog.infected.systems/posts/2024-12-04-hugs-of-death...
Very cool and fun. Regarding power draw, later Wii revisions improved this. My OG Wii runs much "hotter" than my later one.
Really impressed by how low the load average is (0.06 @15 min).
The status page doesn't seem to be updating....
Depending on how often you are refreshing - the status page only updates every 15 minutes:
> So I put together a simple shell script that runs from the crontab every 15 min, outputting some system stats to a basic HTML file in the webroot.
I checked it again and it seems to update every 15 minutes.
https://web.archive.org/web/20250421184947/https://blog.infe...
this is pure beauty. Do you think something like this can be done on a NES? like a simple CGI website
Unfortunately the time you get to the point of even valid HTTP responses it will look less like a SNES and more like whatever-you-plugged-into-a-snes-for-power. E.g. the original Family Computer Network System addon already had more RAM and CPU power than the original console it attaches to just to interface as a modem at all, let alone something "basic" like CGI.
The Wii is probably the first Nintendo console where all the hardware you need to do this is fully built in (though maybe the Nintendo DS, depending how much you're willing to try to get Linux + your server to fit in memory without plugging in a RAM expansion pack to the GBA slot).
This leads to an interesting philosophical debate about where the line to "cheating" is. I'd imagine the NES is more than capable of handling HTTP. I own a small managed network switch with a Web UI (and CGI) all running on an 8051 built into the switch ASIC, and if that can do it, it doesn't seem like such a far fetch that the NES can. The hard part is storage and I/O.
This is purely theoretical, but a 6522 could be used to bitbang SPI, opening the possibility of adding an SD card and Ethernet controller (with a chip like the Wiznet W5500). Add a small amount of SRAM (~16/32Kbit) and a loader ROM, and you'd be able to make the NES into a workable general purpose computer using only the cartridge slot. If needed, one could steal an interrupt from the expansion slot.
Admittedly, this could still be considered "cheating" because the W5500 has a built-in TCP/IP stack, but personally I would feel comfortable saying the NES is hosting the site.
Bitbanging SPI with the 6522 -- https://wilsonminesco.com/6502primer/potpourri.html#BITBANG_...
I feel like this would definitely be possible. I was reminded of https://mitxela.com/projects/kiloboot, which uses an ENC28J60 for the ethernet stuff. I feel like you could probably quite easily bitbang SPI, given it's quite a forgiving protocol, just dedicate a couple of addresses in the memory space to interact directly with the bus (maybe with a separate shift register chip if you want to make things a bit easier). If you give up writing anything to the screen, I'd imagine you could just spin until something happened on the ethernet side, then read the requested path, pull some data off the ROM that corresponds to that path and send it back again
This reminds me SO much of Atari's "Graduate Computer" attachment for the 2600.
Unfortunately, I can't find an accessible link from where I am right now. Maybe when I get back home...
Some links for the curious:
- http://www.atarihq.com/museum/2678/graduate.html
- https://atarimuseum.ctrl-alt-rees.com/videogames/consoles/26...
Yeah, the DS probably is the first one that has enough inbuilt support since it has support for Wi-Fi out of the box although Linux seems a bit heavyweight for this perhaps(?)
DSLinux exists but you need the RAM expansion cartridge. from what I found it supports networking but you've only got 8MB minus the space used by the system. and an ancient binary-only toolchain to wrangle with
> The Wii is probably the first Nintendo console where all the hardware you need to do this is fully built in
Even though accessories were required, you could probably do this with both the N64 Disk Drive or GameCube network adapter. Both were network interfaces that still dispatched to the underlying system.
The N64 Disk Drive [1] would be a fun case, because the storage medium is a glorified floppy disk drive. It does connect over a modem, so there'd be some fun middleware.
The Super Nintendo had a network adapter as well, and both the NES and SNES [2] had satellite networking adapters in Japan. IIRC, there was also a network adapter for the Game Boy. I'm not sure how or if those would work, or how much control was surrendered to the hardware/software of the network adapter itself to let it do all the driving.
[1] https://en.wikipedia.org/wiki/64DD
[2] https://en.wikipedia.org/wiki/Satellaview
The Genesis also had Sega Channel (IIRC?).
Are you sure the Satellaview was available for the Famicom (NES)?
I was wrong about the satellite integration [1]. It was dial-up.
I'm almost certain I remember a similar effort for the Game Boy Pocket, though it might not have entered the market.
[1] https://en.wikipedia.org/wiki/Family_Computer_Network_System
4 megabytes* ought to be enough for anybody, and if you're any depth into DS homebrew, you probably have a 3in1 which expands it to 8 megabytes.
Can it run Linux? Ehhh....... can it run a web server? Absolutely.
* we don't talk about using the 0.6MB VRAM for purposes other than video (even though it should work fine).
DSLinux absolutely runs in 4 MB (i.e. w/o a RAM expansion pack), it's just going to take a bit of work to also fit the web server + whatever CGI they wanted without a pack.
The EZ-Flash V 3-in-1 actually added a whopping +16 MB (128 Mb) of PSRAM! Growing up I only ever had the +8 MB pack from Opera... what a weird bit of history that browser port was :).
I believe DSLinux is uCLinux, not real Linux. And it has to be, because there's no MMU.
Is that PSRAM? For some reason I thought the bigger storage was Flash.
For SNES - absolutely, if you get an FXPAK PRO and proxy over USB. It would be slooow, though, the transfer rate isn’t amazing (limitation on the firmware side, probably due to ancient USB standard?). Basically though - write incoming packets to a well known place in RAM, read another well known place in RAM for outgoing packets. The good news is that you have 12MB of ROM to work with. The bad news is that you really don’t want to transfer too much data at once, and you only get 128Kb of RAM. Not sure if you could do this easily with an NES, I don’t know if the everdrive supports RAM access over USB (it doesn’t on GB* which makes me super sad).
See also https://youtu.be/bsMV0EAF25o?si=Q6i8EH0HMMPa8xA3 for doing this (sorta) via serial over the controller ports (basically…)
Ohh https://github.com/mupfdev/SNESoIP exists too
if you can run a web server on a C64, you can in theory run one on the NES, but you'd have to find a way around the NES's relative RAM constraints
you can run a C64 OS on the NES because of the shared CPU features, with limitations: https://github.com/calcwatch/nes64
which means you can port C64 LUnix NG to NES by adding the Famicom Disk System, which adds more RAM: https://hackaday.com/2024/02/11/running-unix-on-a-nintendo-e...
LUnix NG comes with an experimental web server: https://github.com/ytmytm/c64-lng/blob/b76b0470e28ec20d08c37..., https://github.com/ytmytm/c64-lng/blob/b76b0470e28ec20d08c37...
So in theory you could serve HTTP 1.0 from a NES. ("to whom" would be the big next question)
I don't know if this is cheating, but there were a few NES games that had extra RAM on the cartridge. Pretty easy to do as the cartridge slot directly breaks out the data and address lines from the CPU.
Whatever you end up doing on the NES would end up not being a website anymore. You want to interface with joystick port 1? Not TCP/IP anymore. Whatever gateway you would use to connect to the custom protocol would have a lot more oomph than a NES.
I don't think so without significant work, NES has only 2KB of RAM and an 8 bit CPU without MMU or many niceties taken for granted in General Purpose OS's
I doubt you can go much further back than Fifth Gen (of consoles) or so
You would have to burn a cart that contained the webpage and TCP stack, as well as having the ethernet hardware, but there are tricks you can do to reduce the memory requirements. It's not going to be able to handle more than a packet or two at a time, but I've seen TCP stacks squeezed onto really low end hardware. Obviously you won't be able to open much of a TCP window so performance will be lousy, but it's a 1.8Mhz CPU so that was always going to be the case. Just don't have any misconceptions about being able to run TLS on it. Remember that TCP was developed on machines that did not have a lot of memory or even CPU cycles.
An Atari 2600 might be a bridge too far, but a NES should be able to do it.
Fair enough, seems a lot simpler than what I had in mind with expansions and custom software, but also a far cry from OP's "flash" a general purpose OS and more or less get to working
Funny how that works. It's almost impossible on fifth gen but trivial on sixth gen (at least on the Xbox, which pretty much was a PC).
All the mainstream 6th gen consoles had first party support for wired ethernet; although only the Xbox had it built in (well, the slim ps2 had it built in too). I'd expect they've all served web pages at one time or another.
5th generation could probably make it happen, but without ethernet, you're looking at a modem or serial interface, and in today's world that's almost certainly talking to something else in your house that's a better host. :P Wikipedia categorizes the Apple Pippin as 5th gen, and it's more or less a Mac with a weird pinout for the PCI slot, so I'd guess it's the easiest to get ethernet with; without resorting to something that has more smarts than the 'host'
Even with Ethernet, aren't you're plugging the console into a switch that can probably serve webpages as well as the console?
Most of my switches are unmanaged, so probably not. Maybe the dsl or cable modem or whatever can serve pages, but especially if it's isp owned, it might not be easy to.
You would be surprised with what a Jupiter Ace could do with few KB of RAM. Add a external module for serial <> PPP and the fun begins.
Interesting how the times don't update with each refresh... CDN?
If you’re taking about the status page:
It only updates every 15min which is why you’re getting stale data.Anyone knows if the Starlet co-processor is accessible from NetBSD?
Working from the fact that the NetBSD sees the OHCI controllers which are on the Starlet's AHB this runs with AHBPROT disabled (as does most homebrew), so NetBSD can in theory not only interact with Starlet mailboxes (as any normal game), but can also do pretty much anything to it as the entire Starlet address space is R/W accessible from Broadway (which on the other hand makes interacting with Starlet pretty much irelevant for normal use, as you can interact with the hardware directly using normal drivers instead of going through IOS)
AFAIK, it's not, but it'd be fun to expose it and do silly things with it.
this is so dope
Hey, if anyone wants Wii colo on public address space in New York, get in touch. We gotchu.
https://wtfhost.onefreecomputer.org
We also have android dedis.
incredible! great job!
Cool, but I sense a slowdown!
Are you still looking for PS2 Linux?
edent, my question is what tool did you use to make the Wii ASCII art?
beautiful
Try using ZZ to exit vim ;)
...Then the hardest part is only remembering what layout you're on if you regularly swap keyboard layouts between QWERTY and QWERTZ
..or wait are you even on a keyboard there?
Interesting work! Definitely deserved the #1 spot on HN
That Wii just happened to be running inside a Hetzner data center?
Giving the author the benefit of the doubt, that's probably how I'd do it. Not hosting the Wii in a datacenter, but set up a VM as a proxy, as to not expose my home internet connection to the world.
You're not going to win an points with the family when they can't stream Disney+ because you had to expose a webserver running on that old Wii to the internet, using your home internet connection.
Couldn't one use cloudflare tunnel to prevent that issue?
He wrote that there's Caddy adding TLS between Wii (which runs lighttpd) and the viewer.
You should read the actual post.