> The other problem we need to solve is swap. Linux, or at least not this Linux, won't let you use a swapfile hosted over NFS; swapon will give you an illegal argument error and refuse to enable it.
No swap on nfs is strange. Mainly because as far as I can tell swap over nfs has always been a thing on bsd.
here is the openbsd manual on setting up a diskless system(note the bootparams swap line), however it picked up it's netbooting sequence from bsd which if I had to guess picked it up from sun who invented nfs. I was curious if sunos also has it and it does. I choose sunos as a sort of early snapshot of a commercial bsd system. As netbooting was an important thing to Sun I would guess swap over nfs was a day one thing. Anyone know where to go for very early manuals to confirm this?
Oh, I know it works today; I was just surprised that it might possibly be an option on a 2.4-6 kernel, as I had assumed that Linux didn't get NBD until... I dunno, I would have guessed late aughts?
Yes, or via the (very slow) built-in serial port. The broadband adapters are quite rare.
Interestingly, for a long time there were no publicly available tools for or docs on dumping GD-ROMs. New releases from Echelon and Kalisto would appear promptly, so there was obviously a way, but you could only partake in the rampant piracy by downloading the (occasionally-massaged to fit on a CD) disc images online.
A lot of discussion in the (tbf probably quite young and inexperienced) community was around how this was possible. A popular theory/rumor at the time was that they were using CD drives with modified firmware, for example.
This probably also helped keep the piracy amd homebrew scenes fairly well separated on the Dreamcast, as there was a lot of info and examples around running your own code. This is in contrast to eg. the Xbox scene, which was in many ways the equally vibrant successor to the DC scene, but where piracy and homebrew seemed much more intertwined. Not least because all the homebrew binaries were built using the off-limits Microsoft SDK, so you had to go to some shady FTP site via links found on IRC to download them.
Iirc the Katana devkit could be used to play commercial games so I wouldn't be surprised if some developers were part of the groups and if so writing a dumper was probably not hard.
There was even a preview version of the game I worked on that got leaked so either someone in our office was part of the cracking scene or someone at Sega/QA (they were our publisher) since AFAIK no-one else had any copies.
If memory serves, the first (at least publicly disclosed) interface was the "Dreamcast Debug Handler", created by a member of Hitmen. This worked by adding a breakout connector to the expansion port terminator (which came with some Asian Dreamcast systems instead of a modem), then connecting that to some homebrew hardware to adapt the bus to a parallel port.
Another alternative that was reasonably-priced for a short while was the Japan-exclusive "LAN Adapter", which was in lower demand because it was only officially supported by the Dreamcast web browser app and was only 10Mbps instead of 10/100.
From all the variants mentioned across the comments, the PS2Linux was the best one, being officially supported by Sony.
Originally they had though as a means to foster indie development, instead people got to use it for emulation, thus PS3 Linux Other OS no longer supported graphics acceleration, and then was completly dropped in a firmware upgrade.
On the PS2, we had official Linux CDs from Sony, a hard drive, connection cables, and a whole development environment, a GL like API, another more low level console like, both with hardware acceleration (although the actual one used on the devkit wasn't exposed).
The XBOX would do it better; but sadly current ports are abandoned.
An XBOX with 128MB of RAM would run Fluxbox or whatever light env with ease, and with Dillo
and a PSP user agent you could even post into HN. Gemini and Gopher would do it fine,
even with clients written in TCL/Tk. It would be a fine backup PC for either thinkering
or rescueing.
With ZRAM you could almost mimic a 192MB of RAM based device, good for maybe a browser like Seamonkey/IceApe if it could be built without SSE2.
It lives on today as Kodi, including the GUI hacks, the weird flaky add-ons, browsing file shares on the LAN, and the strange piracy-adjacent community.
It's all there, and on all kinds of devices -- just not on OG Xbox hardware.
> Never put a console running DC Linux outside of a firewall: it is an intentionally insecure system. Any bot scanning your network will get root immediately.
Yeah, that's really important advice. They'll get root, and then they'll... ummm... they'll... hmmmmm.... ahhh.... Be really confused? Start mining monero? Sideload Crazy Taxi and start playing it on your Dreamcast?
Well, a known problem with pre v4 NFS is that it uses and trusts client side UIDs I believe, In fact I believe even v4 does this by default. So if I understand correctly, it treats root on the client like root on the server, and since NFS gives direct access to the block device this is even worse than it initially sounds.
Yeah, with all those Hitachi SH-4 32-bit RISC payloads running around in malware you can't be too protective. With the mighty power of 200MHz just imagine all the RISC malware it could run.
Crazy to think that we've go the Steam Deck now, as our front-line Linux-based gaming console .. I guess I shouldn't be surprised to find out that the Dreamcast emulator is probably available for SteamOS ...
> The other problem we need to solve is swap. Linux, or at least not this Linux, won't let you use a swapfile hosted over NFS; swapon will give you an illegal argument error and refuse to enable it.
To my shock, https://en.wikipedia.org/wiki/Network_block_device says
> The protocol was originally developed for Linux 2.1.55 and released in 1997.
so I wonder if you could use that? It's better suited to swap anyways.
Hold on now. Swap over NFS? I’m amazed this is viable. I guess the difference between line and device speed wasn’t as vast as it is now.
Having read the article it makes more sense. They need additional capacity for the RAM disk.
In this context, it is less about viability and more about just getting things to work at even the slowest of speeds.
Nobody does swap over things like NFS or NBD unless they have to.
(Even in the Dreamcast days, common home networks were vastly slower than local disk.)
No swap on nfs is strange. Mainly because as far as I can tell swap over nfs has always been a thing on bsd.
here is the openbsd manual on setting up a diskless system(note the bootparams swap line), however it picked up it's netbooting sequence from bsd which if I had to guess picked it up from sun who invented nfs. I was curious if sunos also has it and it does. I choose sunos as a sort of early snapshot of a commercial bsd system. As netbooting was an important thing to Sun I would guess swap over nfs was a day one thing. Anyone know where to go for very early manuals to confirm this?
http://man.openbsd.org/diskless
Yes, NBD works. I use it to give my 256Mb Pi a swap off the sdcard. You could also use iSCSI now.
Oh, I know it works today; I was just surprised that it might possibly be an option on a 2.4-6 kernel, as I had assumed that Linux didn't get NBD until... I dunno, I would have guessed late aughts?
And this is how GD-ROMs got ripped. Broadband adapter and the shoot out the data over Ethernet
Yes, or via the (very slow) built-in serial port. The broadband adapters are quite rare.
Interestingly, for a long time there were no publicly available tools for or docs on dumping GD-ROMs. New releases from Echelon and Kalisto would appear promptly, so there was obviously a way, but you could only partake in the rampant piracy by downloading the (occasionally-massaged to fit on a CD) disc images online.
A lot of discussion in the (tbf probably quite young and inexperienced) community was around how this was possible. A popular theory/rumor at the time was that they were using CD drives with modified firmware, for example.
This probably also helped keep the piracy amd homebrew scenes fairly well separated on the Dreamcast, as there was a lot of info and examples around running your own code. This is in contrast to eg. the Xbox scene, which was in many ways the equally vibrant successor to the DC scene, but where piracy and homebrew seemed much more intertwined. Not least because all the homebrew binaries were built using the off-limits Microsoft SDK, so you had to go to some shady FTP site via links found on IRC to download them.
Iirc the Katana devkit could be used to play commercial games so I wouldn't be surprised if some developers were part of the groups and if so writing a dumper was probably not hard.
There was even a preview version of the game I worked on that got leaked so either someone in our office was part of the cracking scene or someone at Sega/QA (they were our publisher) since AFAIK no-one else had any copies.
If memory serves, the first (at least publicly disclosed) interface was the "Dreamcast Debug Handler", created by a member of Hitmen. This worked by adding a breakout connector to the expansion port terminator (which came with some Asian Dreamcast systems instead of a modem), then connecting that to some homebrew hardware to adapt the bus to a parallel port.
Another alternative that was reasonably-priced for a short while was the Japan-exclusive "LAN Adapter", which was in lower demand because it was only officially supported by the Dreamcast web browser app and was only 10Mbps instead of 10/100.
From all the variants mentioned across the comments, the PS2Linux was the best one, being officially supported by Sony.
Originally they had though as a means to foster indie development, instead people got to use it for emulation, thus PS3 Linux Other OS no longer supported graphics acceleration, and then was completly dropped in a firmware upgrade.
On the PS2, we had official Linux CDs from Sony, a hard drive, connection cables, and a whole development environment, a GL like API, another more low level console like, both with hardware acceleration (although the actual one used on the devkit wasn't exposed).
I had that kit and it was really good.
I actually used it to write a small game to demonstrate the PS2 architecture in my CS undergrad capstone project.
It was slooooooooow even by the standards of the time.
I still have mine.
Unfortunately not seen a use in years now.
Did you use PS2GL, or the low level one with what is now kind similar to what devs are exposed to on Metal, Vulkan, DX12?
The XBOX would do it better; but sadly current ports are abandoned.
An XBOX with 128MB of RAM would run Fluxbox or whatever light env with ease, and with Dillo and a PSP user agent you could even post into HN. Gemini and Gopher would do it fine, even with clients written in TCL/Tk. It would be a fine backup PC for either thinkering or rescueing.
With ZRAM you could almost mimic a 192MB of RAM based device, good for maybe a browser like Seamonkey/IceApe if it could be built without SSE2.
XBMC was so good at the time. Haven't been superseded yet in UX. Locate the movie in some network folder and go.
XBMC4Xbox seems to be a spinoff but I guess it can't play HD.
Edit: And it seemed to have been running the original Xbox win32 interface, not Linux.
XBMC was stunningly amazing at the time.
It lives on today as Kodi, including the GUI hacks, the weird flaky add-ons, browsing file shares on the LAN, and the strange piracy-adjacent community.
It's all there, and on all kinds of devices -- just not on OG Xbox hardware.
Ye I'm thinking about trying that one. I need to setup a Linux box as media center and game emulator for the TV to replace the crappy 'smart TV' OS.
I use a Raspberry Pi 4 for all of that stuff, that I got back before things turned weird(er) in the small computer space.
oh the days of xbox-linux, the cromwell bios and stuff.
I remember some guy soldering additional memory as well. Can't recall if it was 64 to 128mb or 128 to 256mb.
This dude does CPU and RAM upgrades: https://computerbooter.com/modules.php?name=Content&pa=showp...
He also streams the process live on youtube: https://www.youtube.com/channel/UCPWknjnQNOwSD15nNh4rhLg
Excellent article, it really takes me back. You can still access the old linux-sh.org website on archive.org: https://web.archive.org/web/20080705101211/http://www.linux-...
> Never put a console running DC Linux outside of a firewall: it is an intentionally insecure system. Any bot scanning your network will get root immediately.
Yeah, that's really important advice. They'll get root, and then they'll... ummm... they'll... hmmmmm.... ahhh.... Be really confused? Start mining monero? Sideload Crazy Taxi and start playing it on your Dreamcast?
Well, a known problem with pre v4 NFS is that it uses and trusts client side UIDs I believe, In fact I believe even v4 does this by default. So if I understand correctly, it treats root on the client like root on the server, and since NFS gives direct access to the block device this is even worse than it initially sounds.
start mining monero is the most likely outcome. I had a server get hit with this recently through a vulnerability I was never able to track down
> start mining monero
Good luck with that! Even Monero's "light mode" requires 16 times more memory than is available on the system.
Join a botnet, and use your node to log into other devices and/or deliver attack payloads.
Yeah, with all those Hitachi SH-4 32-bit RISC payloads running around in malware you can't be too protective. With the mighty power of 200MHz just imagine all the RISC malware it could run.
Crazy to think that we've go the Steam Deck now, as our front-line Linux-based gaming console .. I guess I shouldn't be surprised to find out that the Dreamcast emulator is probably available for SteamOS ...
It's called Flycast and it's very good.
Nice, will have to dig the Dreamcast collection out of the attic ..