From what I know, someone managed to run Linux on 6502 machine by emulating a 32 bit Motorola CPU. Of course booting it would probably take hours if not days.
Linux was made very early on in the 32bit days, most of the runtime is in 16 bit instructions. (Or well it was). That is, it needs 32 instructions, but really for very few things. Getting from 16 bit to 8 bit is a bit easier. Still yes, there is a boat load of issues. But anyway, getting from 32 to 16 bit might bot be as hard as one imagine. It really boils down to 3 main funktion. Ram, drive and security. And the solution for ram is quite easy just cap it at 1MB. The solution for drive is also similarly easy. Just don't use 32 bit file system. And for security? Who really needs it
@@matsv201This is not accurate. Linux was fully 32-bit from the very beginning in 1991, both the kernel and the userspace. That was one of Linus Torvald's original requirements in his project. The only 16-bit code was in LILO, the bootloader, and it was not part of the kernel.
@@ryanr8364 That is not how neither compiler nore 386 opcodes work. A 386 instruction set is really mostly a 286 instruction set with a few 32 bit added instructiosn on top of the 286 code. Because 386 is not 387 there is no floatingpoints in the 386 op-code, and that is really mostly what 32 bit words are used for. There is a bit of ops added to handle 32 bit ints, but again, those are not really needed. Most of the added ops is for disc and memory acess. Even at that its worth saying that the 286 did have extended memory space over the bit limit of 1MB. (simular to how most 8bit CPU did memory pageing). You might belvie you are writing a 32 bit code, but the compiler don´t care. When its compiled and done most of the code is 16 bit regardless. .... that is.. most.. not all. You have to go all the way to x64 untill there is a full ops base for replacing every single 16 bit instruction. Even at that, its a bit flakey. Even today in a 64 bit windows that support aboslutly none 16 bit aplication, there are still ops that are compiled as 16 bit instructions that is needed. A few yeras back (we talking like 2021-22 or there about) anuounced a project of totaly wiping the cores from x86-16 code. But it turned out that it didn´t work due to some legacy part of the system is still using part of that code base So in stead they was about to implement a 16 bit emulator in hardware via code morthing to remove the 16 bit instructions. If you look at the 386 ops base most of the instructions that is just not totaly new instructions for extended usage or having to do with memory or disc access, are just added clone instructions for 16 bit int in 32 bit. Here is the thing, if you use nothing 32 bit, those instruction isn´t needed in the first place. Even if the compiler in some instances would compile them into 32bit int, you will really just have 16 bit numbers with 16 zeros in front of for basically every calculation. And of cause yes, you would need to recompile it set to 16 bit and some code would need to be removed or modified. But most would just work as is. So its not like because you set the compiler to 32 bit, everything will be 32 bit. Even if it was. Most of the code is not written as bit dependent.
Caught the Star Trek reference you slipped in there where Picard said "He-just-kept-talking-in-one-looong-incredibly-unbroken-sentence-moving-from-topic-to-topic-so-that-no-one-had-a-chance-to-interrupt-it-was-really-quite-hypnotic'
Oh my word, thank you for doing this!! I've use LUnix with a Pi1541 on the C64 before, and it's some serious stuff! (Networking drivers go crazy) I've scoured Teh Interwebz for this kind of idea, and I believe you are now the first to have the NES run Unix! 👏👏👏
I was having vietnamese clone of NES, it has keyboard, mouse and cartridge, which tries to behave like Windows 95. It has mouse cursor, start menu, text editor, "movies". It was more like educational pc. Good memories.
Interesting project, someone linked me this video on Discord and was curious. Since I own a Famicom with the Family BASIC keyboard along with an FDS Stick I was able to run your program on actual hardware and unfortunately I can't seem to get the actual keyboard to work despite it being functional in Family BASIC. When emulating in Mesen the keyboard works fine so I'm a bit puzzled why it isn't working on the actual hardware. Edit: I have since tested newer versions of the program and the keyboard now works on actual hardware. Very interested to see where this project goes from here.
When the system boots does it display the message "No Keyboard" after the "Family BASIC Keyboard module version 0.3" message? if so then the keyboard driver is disabling itself since it can't detecting a keyboard. also, providing tech support for UNIX on a Famicom feels incredibly surreal.
Strange. I implemented the same keyboard detection algorithm that Lode Runner supposedly uses, according to the nesdev wiki. Keyboard detection was the last feature i added so as a quick workaround you could checkout the version before I added that. Commit 8421a70 is the latest version that doesn't have keyboard detection. github.com/decrazyo/lng-fds/blob/8421a706f76c9fe5d4d2b21e627dc74ba9b96fd9/lunix.fds
@@decrazyo got around to testing this one, good news is that the keyboard is fully functional on hardware now but bad news is that they keys do not correspond to the output so T on the keyboard would register as W for some reason at least it's somewhat functional not entirely sure why its so borked on actual Famicom hardware
Ok. This is starting to make sense to me. T and W correspond to the same column on the keyboard matrix, just on different rows. So, for example, when the driver is trying to read row 1 it's actually reading row 2 and so on for every row. That would also explain why keyboard detection doesn't work. I'll see if anyone on the forums has document this behavior or I'll just reverse engineer Family BASIC to see how it handles the keyboard.
Dude, this is amazing. Your understanding of what is running even mean, the fundamental process of how a UNIX like OS works, and what is involved to actually get this code to run on the NES. People who are able to pull this off is few, far and in between. Good job!
I believe the only requirement for "UNIX-like" is just POSIX complicance, which kicks out Windows (in its current form, excluding WSL) right away, and describes most of the things you described.
@@jfbeamthe "posix layer" in this case was actually a sort of malicious compliance scam so Microsoft could bid on US government contracts. NCommander has a good video about it, it was not actually useful. Calling it "posix" is a very, very big stretch. There is cygwin which does that in a more useful way.
This is insanely impressive. If you like the thought of making an NES/FDS run a modern OS, *please* look up information about Contiki. There's an abandoned NES port for that OS which was supposed to have networking hardware and the ability to use the Zapper gun as a makeshift mouse. This OS has a Wikipedia article, so I suppose that plus websearching would be a good place to start.
I’m trying to imagine a Zapper as a mouse. How I understood the zapper to work is a “confirm or deny” the zapper is looking at a predetermined spot on the screen. For this to work to determine aim, I would think it would have to “scan” by moving the white box all over the screen until the zapper hit, which could easily take a good half second to try 16 different regions on the screen and get a low resolution of where the pointer should be. I guess it could then repeat in the smaller region to “refine” the pointer position closer to the aimed spot. Maybe I should just go search for a video of this…
@@cll1outyou could do a binary search actually and get which half screen, then which quarter, wich eigth which 16th, maybe that is fast enough in the nes, i imagine the pixel density is also not that big, also most of the screen might not be interactive
This is good news for NES retro developers, everyone will want the cartridge with the penguin logo, adapted with more memory, SD input peripherals, sound chips, etc. It can help create better games and development platforms to play online.
That's so cool! I completely forgot everdrives were a thing, and thought the endpoint was gonna be an emulated FDS, did not expect the real hardware at the end
The Linux kernel itself requires a memory management unit. Which the 6502 doesn't have. Minix is the most common Unix-like OS that does not require an MMU.
I had the same thought the other day since it's small enough to be baked in every Intel CPU post 2006, but sadly that won't work =/ LUnix is far closer in architecture out the gate so it was definitely a smarter choice for this project and regarding the MMU I found this on OSdev: "Although Minix 3 prior to 3.1.4 doesn't use the MMU, it did use virtual memory and memory protection to some extent. Rather than use paging, it used the segmentation system of x86 processors to achieve similar results." Maybe Minix 2 could be possible if there's no need for MMU and it doesn't rely on x86 specific functions but I'm sure it wouldn't be easy without basically rewriting it
LUnix, and its author "Poldi", was well known in the C64 community in the 90s and 00s, but less known today. As a fan, I appreciate DeCrAzYo showing it some love.
5:44 Wait, what? I just looked that up and that is batshite crazy! Thanks for this, man; I had no idea. This is going to be a fun little rabbit hole for me.
Hands-down the best idea I’ve seen in a very long time I think Nintendo is messing up big time and not hiring people like you best advice I was given think outside the box in this video is a prime example of it
AWE WOT?! Upvotes for seeing how deep this rabbit hole goes. _TRY_ (nobody expects success) to get busybox or toybox equivalent running. AN shell. Get to AN shell. Updoots for continuance!
Nice work! My suggestion would be to utilize a Miracle Piano Keyboard cable to interface a QWERTY keyboard. It was used for cartridge, but it takes the regular port of the NES and has a 25-pin male adapter on the end (assuming you want closer to native hardware..). I would start there.
Very nice - you've given me an interesting idea for a project/video that I have planned for this summer. I'll be thinking about this more, but I may possibly jump into the repo and make a couple of contributions.
In keeping with the premise of using only available hardware of the time. Would it not be appropriate to use memory swapping or what it's called, like how they used to get games like Kirby to run on the NES with the 6 Megabit cartridge?
Awesome work! I haven’t studied the code yet, but if you want less glitching, I’d recommend using the MMC5 mapper, which maps a chunk of cartridge RAM to the PPU, making it more like Commodore hardware. It would also give you a lot more data available for bank swapping, if you want to include more executables, and battery-backed-up memory to save its state or have a rewritable file system. Plus, you’d remove the FDS read bottleneck you mentioned.
thank you for sharing this, it’s really amazing what you did, it’s been a while that I didn’t see anything so cool. “*why you do this? , **because is cool and I can do it “
Deffo got my subscription. Cool project, well explained, definitely interesting. People don't credit old hardware enough. Any one that wants to learn coding or computer science nowadays wants to start with the best stuff. Problem is, best stuff is also the most complex stuff, and at the fundamental level, everything works (mostly) just like their initial counterparts did. Sometimes, it's helpful to learn how an old piece of hardware or software works, because it will help you understand the new stuff.
It should be possible on Gameboy Advance or Nintendo DS. The DS has the RAM requirement for Windows 95 - and more if you install a RAM expansion cartridge.
I would have been really surprised if any version of Linux worked on a 6502 at all, let alone an NES specifically. The very first version of Linux was written for a 386, which is 32-bit. Even the original Unix from Bell Labs would be kind of a stretch, simply because the PDP-11 computers it was designed for were 16-bit systems already. That's basically why it took so long for a Unix-like operating system to be possible on microcomputers... Unix was relegated to the server room and that paved the way for stuff like CP/M and DOS that was designed for single-user microcomputers rather than big expensive mainframes. Even so, the very first version of Xenix from Microsoft did run on an 8088, but that was a 16-bit architecture internally with an 8-bit data bus. Plus it required 256K of RAM. So yeah, I can imagine a lot of compromises would be needed for a Unix-like experience on that CPU, even without the RAM constraints of the NES.
This is so impressive to see, especially considering the limitations of the NES, I wonder if this would also be possible on the SNES and be more usable in some way due to the more powerful hardware or if in the end there wouldn't be that much of a difference running a OS between the two.
0:19 Yes! This is the greatest thing about cartridges, you can just stick whatever you want in, we need more consoles that accept cartridges like this in modern day! What, security risks? Nonsense!
I don't know about Linux, but I'd like to put Nestopia, and my entire library of NES games into one single cartridge and play it an actual NES. That would be pretty cool.
great work! I wonder how much work it would be to eliminate lunix's disk reliance entirely. also, this makes me fantasize about porting the original unix version 6 to the system
I have a Sharp Twin Famicom and a Family Basic Keyboard, with an everdrive. I'm going to give this a shot! The C64 Kernal and BASIC port is super fun to play with, as well!
i think if it existed during the console's lifespan, including extra hardware should be "allowed" in terms of this type of challenge the entire purpose is that the NES should be the one in control, and not, as you say, "a shitty video card" where it basically takes a backseat to its "coprocessor" and instead becomes the coprocessor itself so even if the coprocessor is more powerful than the normal processor, the main processor should be doing all of the management, and using the coprocessor instead as support hardware what this means is that regardless of how fast the coprocessor works, its limited by the instruction processing power of the host processor, and what the host processor can then do with that
"Now that we've stopped moving the goal posts..." Is the most perfect thing I've ever heard describing the hardware hobby.
If only people were more comfortable with this. Sometimes it's better to simply move the goal posts.
I respect that you acknowledge moving the goal posts.
yup, and then when it ran on an everdrive in the end I fully felt that this was legit enough. really shows how honesty is the best policy.
Yeah if he didn’t, I might have added an invisible dislike
Wow. Didn't even run neofetch
Damn. I knew I forgot something!
@decrazyo It's all good, that would have been cool, but this is still as impressive.
@@decrazyo you can post the neofetch in a community post
@@decrazyonow that you remember edit it into the video
What is neofetch?
Hold on, I wrote those TODO labels on the FDS page... 😬
😂 Maybe I'll add some details to the wiki now that I know a bit more about the FDS.
@@decrazyo I'd appreciate that. Not enough people have delved into the FDS' low-level behaviour.
@TakuikaNinja you both are awesome.
@@decrazyohi
I will finally be able to turn my 20 famicom into a k8s cluster
From what I know, someone managed to run Linux on 6502 machine by emulating a 32 bit Motorola CPU. Of course booting it would probably take hours if not days.
Linux was made very early on in the 32bit days, most of the runtime is in 16 bit instructions. (Or well it was).
That is, it needs 32 instructions, but really for very few things.
Getting from 16 bit to 8 bit is a bit easier. Still yes, there is a boat load of issues.
But anyway, getting from 32 to 16 bit might bot be as hard as one imagine. It really boils down to 3 main funktion. Ram, drive and security.
And the solution for ram is quite easy just cap it at 1MB. The solution for drive is also similarly easy. Just don't use 32 bit file system.
And for security? Who really needs it
@@matsv201This is not accurate. Linux was fully 32-bit from the very beginning in 1991, both the kernel and the userspace. That was one of Linus Torvald's original requirements in his project. The only 16-bit code was in LILO, the bootloader, and it was not part of the kernel.
@@ryanr8364 That is not how neither compiler nore 386 opcodes work. A 386 instruction set is really mostly a 286 instruction set with a few 32 bit added instructiosn on top of the 286 code. Because 386 is not 387 there is no floatingpoints in the 386 op-code, and that is really mostly what 32 bit words are used for.
There is a bit of ops added to handle 32 bit ints, but again, those are not really needed. Most of the added ops is for disc and memory acess. Even at that its worth saying that the 286 did have extended memory space over the bit limit of 1MB. (simular to how most 8bit CPU did memory pageing).
You might belvie you are writing a 32 bit code, but the compiler don´t care. When its compiled and done most of the code is 16 bit regardless. .... that is.. most.. not all.
You have to go all the way to x64 untill there is a full ops base for replacing every single 16 bit instruction. Even at that, its a bit flakey. Even today in a 64 bit windows that support aboslutly none 16 bit aplication, there are still ops that are compiled as 16 bit instructions that is needed.
A few yeras back (we talking like 2021-22 or there about) anuounced a project of totaly wiping the cores from x86-16 code. But it turned out that it didn´t work due to some legacy part of the system is still using part of that code base So in stead they was about to implement a 16 bit emulator in hardware via code morthing to remove the 16 bit instructions.
If you look at the 386 ops base most of the instructions that is just not totaly new instructions for extended usage or having to do with memory or disc access, are just added clone instructions for 16 bit int in 32 bit.
Here is the thing, if you use nothing 32 bit, those instruction isn´t needed in the first place. Even if the compiler in some instances would compile them into 32bit int, you will really just have 16 bit numbers with 16 zeros in front of for basically every calculation.
And of cause yes, you would need to recompile it set to 16 bit and some code would need to be removed or modified. But most would just work as is.
So its not like because you set the compiler to 32 bit, everything will be 32 bit. Even if it was. Most of the code is not written as bit dependent.
Criminally underrated this is such a niche but awesome project I hope you learned alot doing it!
It was a great way to learn more about some fundamentals of OS design.
@@decrazyo Would love to see what you can decide to actually run on top of it!
nice pfp
@@Cypryssss Why, thank you!
I must return the compliment, as you're looking just as (if not more) dapper.
Yep, we need more operating systems and software with professionally made, efficient usage of hardware resources.
i love this type of thing.. youtube has been in a sad state lately.... please please keep making videos
dude even included some old internet memes to bring me back to happier days of internetting. :_)
This is the kind of stuff I'm about, esp dealing with the qualifiers of 'not just a raspberry pi in a cartridge'
Videos like this prove to me that there are just everyday people out there who are geniuses. You are one of those people
Caught the Star Trek reference you slipped in there where Picard said "He-just-kept-talking-in-one-looong-incredibly-unbroken-sentence-moving-from-topic-to-topic-so-that-no-one-had-a-chance-to-interrupt-it-was-really-quite-hypnotic'
Oh geez that is really an obscure reference. I get it now.
@@3rdalbum it was quite popular on YTMND back in the early internet ("The Picard Song") but yeah, rather obscure these days.
@@TSDThard to believe YTMND is the “early internet.” Feels like yesterday
Oh my word, thank you for doing this!! I've use LUnix with a Pi1541 on the C64 before, and it's some serious stuff! (Networking drivers go crazy) I've scoured Teh Interwebz for this kind of idea, and I believe you are now the first to have the NES run Unix! 👏👏👏
I didn't even know an 8bit 6502 could do this much. Good video.
Man wrote his own drivers and called it easy
"Professionals have Standards"
@@alface935 Hey, at least he knows they don't have spyware lol
@@jsnotlout3312 True
@@alface935 The red spy is not in the base
@@jsnotlout3312 He could be in this very room
I was having vietnamese clone of NES, it has keyboard, mouse and cartridge, which tries to behave like Windows 95. It has mouse cursor, start menu, text editor, "movies". It was more like educational pc. Good memories.
never expected this from a speed run channel. I'd love to see more cool projects like this!
Ohhh, I KNEW I knew that voice from somewhere!!!
When you dropped the FDS bomb, I got excited. I have the System, the keyboard, and the FDS.
Interesting project, someone linked me this video on Discord and was curious.
Since I own a Famicom with the Family BASIC keyboard along with an FDS Stick I was able to run your program on actual hardware and unfortunately I can't seem to get the actual keyboard to work despite it being functional in Family BASIC. When emulating in Mesen the keyboard works fine so I'm a bit puzzled why it isn't working on the actual hardware.
Edit: I have since tested newer versions of the program and the keyboard now works on actual hardware. Very interested to see where this project goes from here.
When the system boots does it display the message "No Keyboard" after the "Family BASIC Keyboard module version 0.3" message? if so then the keyboard driver is disabling itself since it can't detecting a keyboard.
also, providing tech support for UNIX on a Famicom feels incredibly surreal.
@@decrazyo yeah it's displaying the message, despite the keyboard being plugged in since power on
Strange. I implemented the same keyboard detection algorithm that Lode Runner supposedly uses, according to the nesdev wiki.
Keyboard detection was the last feature i added so as a quick workaround you could checkout the version before I added that.
Commit 8421a70 is the latest version that doesn't have keyboard detection.
github.com/decrazyo/lng-fds/blob/8421a706f76c9fe5d4d2b21e627dc74ba9b96fd9/lunix.fds
@@decrazyo got around to testing this one, good news is that the keyboard is fully functional on hardware now but bad news is that they keys do not correspond to the output so T on the keyboard would register as W for some reason
at least it's somewhat functional not entirely sure why its so borked on actual Famicom hardware
Ok. This is starting to make sense to me. T and W correspond to the same column on the keyboard matrix, just on different rows. So, for example, when the driver is trying to read row 1 it's actually reading row 2 and so on for every row. That would also explain why keyboard detection doesn't work. I'll see if anyone on the forums has document this behavior or I'll just reverse engineer Family BASIC to see how it handles the keyboard.
This is pretty damn awesome. Not that anyone would ever actually NEED to do this, but it's still cool that someone was able to.
Oh wow! That's amazing, especially with reverse-engineering the FDS. One of my friends actually did a full disassembly of the BIOS
Dude, this is amazing. Your understanding of what is running even mean, the fundamental process of how a UNIX like OS works, and what is involved to actually get this code to run on the NES. People who are able to pull this off is few, far and in between. Good job!
That picard / disk reading joke was 10/10 😂
Once you started talking about writing your own routines i knew this video is fire
Yeah you got a sub for "one long unbroken spiral moving from sector to sector" ... (it's really quite hypnotic)
this is awesome, it blows my mind how people like you manage to run an OS in such machines, as a linux fan I'm in love with this
That STNG plug was amazing! :)
I believe the only requirement for "UNIX-like" is just POSIX complicance, which kicks out Windows (in its current form, excluding WSL) right away, and describes most of the things you described.
POSIX does not equal UNIX. (Windows [NT] has had POSIX layers as far back as 3.5. The NT kernel was based on a UNIX system.)
@@jfbeamthe "posix layer" in this case was actually a sort of malicious compliance scam so Microsoft could bid on US government contracts. NCommander has a good video about it, it was not actually useful. Calling it "posix" is a very, very big stretch.
There is cygwin which does that in a more useful way.
this
“excluding WSL”
I mean if you just arbitrarily exclude major parts of windows then sure
@@mattmurphy7030
1. WSL is not installed by default
2. WSL has actual linux installed in it
3. WSL runs via Hyper-V emulation
Um, this is something that I have always wanted to do but never set aside the time to do it. Thanks for sharing this!
"...and more like a shitty video card."
>shows something that basically resembles my current gpu
Can it rin minecraft?
This is insanely impressive.
If you like the thought of making an NES/FDS run a modern OS, *please* look up information about Contiki. There's an abandoned NES port for that OS which was supposed to have networking hardware and the ability to use the Zapper gun as a makeshift mouse. This OS has a Wikipedia article, so I suppose that plus websearching would be a good place to start.
I’m trying to imagine a Zapper as a mouse. How I understood the zapper to work is a “confirm or deny” the zapper is looking at a predetermined spot on the screen. For this to work to determine aim, I would think it would have to “scan” by moving the white box all over the screen until the zapper hit, which could easily take a good half second to try 16 different regions on the screen and get a low resolution of where the pointer should be. I guess it could then repeat in the smaller region to “refine” the pointer position closer to the aimed spot.
Maybe I should just go search for a video of this…
@@cll1out I don't think there would be a mouse cursor. Instead of "point and click" it would probably be "aim and shoot."
@@cll1outyou could do a binary search actually and get which half screen, then which quarter, wich eigth which 16th, maybe that is fast enough in the nes, i imagine the pixel density is also not that big, also most of the screen might not be interactive
@@tatomar001 why randomly guess when you could just look it up
6:35 that music sounds a lot like Star Control II mod files ;)
This is good news for NES retro developers, everyone will want the cartridge with the penguin logo, adapted with more memory, SD input peripherals, sound chips, etc. It can help create better games and development platforms to play online.
Nice, this takes the "computer" in the word famicom to another level.
Incredibly cool, very interesting, and I love your straightforward presentation. Subscribed!
The quiestion now becomes "Can it run doom?"
at a ludicrously low clock speed, maayyybe? 🤔🤷♂
This is an NES/FDS, let's start with Wolfenstein 3D first. Or maybe Curse of the Catacombs.
@@DJBillyQ Well, at a ludicrously low speed (not clock speed), everything runs potentially on the NES.
This is incredible, dude! Thank you for sharing such an awesome project!
Why didn't you get the lead man for The Police to announce this? It would have been perfect.
He's sendin' out a NES OS!
He's sendin' out a NES OS!
I bet you lived at least half of your life wanting to say that... 😁😁
Sting? 😂
Great, now that's gonna be stuck in my head all day hahaha
That's so cool! I completely forgot everdrives were a thing, and thought the endpoint was gonna be an emulated FDS, did not expect the real hardware at the end
"Unix-like is pretty much every contemporary common OS, ... but like all Unixy everywhere". Feels circular to me.
it's more just that unix ideas are so pervasive in modern os design. windows is pretty much the only non-unix and even it takes a bunch from unix
Thank you for answering this question I didn't know I needed answered until seeing this video on my feed.
@1:12 Colonel Space Code is my favorite old sci-fi tv show
The Linux kernel itself requires a memory management unit. Which the 6502 doesn't have. Minix is the most common Unix-like OS that does not require an MMU.
I had the same thought the other day since it's small enough to be baked in every Intel CPU post 2006, but sadly that won't work =/
LUnix is far closer in architecture out the gate so it was definitely a smarter choice for this project and regarding the MMU I found this on OSdev:
"Although Minix 3 prior to 3.1.4 doesn't use the MMU, it did use virtual memory and memory protection to some extent. Rather than use paging, it used the segmentation system of x86 processors to achieve similar results."
Maybe Minix 2 could be possible if there's no need for MMU and it doesn't rely on x86 specific functions but I'm sure it wouldn't be easy without basically rewriting it
LUnix, and its author "Poldi", was well known in the C64 community in the 90s and 00s, but less known today. As a fan, I appreciate DeCrAzYo showing it some love.
I can't believe that I hadn't heard any retro computing youtubers talk about LUnix. I was completely unaware of it before I started this project.
5:44 Wait, what? I just looked that up and that is batshite crazy! Thanks for this, man; I had no idea. This is going to be a fun little rabbit hole for me.
The amazing song is apparently "long time coming" by Kevin mcloadm. Same as in aa/bb
"Well now that we're done moving the goal posts." I really want to get this printed as a quote and toss it in our sales teams area.
this is probably one of the most impressive things ive seen in a while
Hands-down the best idea I’ve seen in a very long time I think Nintendo is messing up big time and not hiring people like you best advice I was given think outside the box in this video is a prime example of it
You are hardcore! Very cool! Must have taken hours to write and figure it all out.
Love these little projects. Some would ask why and what's the point but to me seeing it run on native hardware is brilliant
Nicely put together! Looking forward to your content.
AWE WOT?!
Upvotes for seeing how deep this rabbit hole goes.
_TRY_ (nobody expects success) to get busybox or toybox equivalent running.
AN shell. Get to AN shell.
Updoots for continuance!
Colonel Spacecode was my favourite NES platformer.
We got Linux on the NES before Half Life 3
Nice work!
My suggestion would be to utilize a Miracle Piano Keyboard cable to interface a QWERTY keyboard. It was used for cartridge, but it takes the regular port of the NES and has a 25-pin male adapter on the end (assuming you want closer to native hardware..). I would start there.
You forgot that sweet posix compliance.
The Picard bit was brilliant 🤣
This is a sweet hack! Adapting the C64 version is a nice way to get to linux quickly.
"I use NES btw"
LOL Timescape, such a good TNG ep
That was just incredible... I can't believe someone like you could do something of this scale...
Sounds kinda like a back handed compliment, but I doubt that was intentional.
Lunix is literally Linux, but with the vowels swapped. 😂
5:35 tracks and sectors
got it learned now
simple and intuitive thanks
Very cool! It's clear a lot of work went into this project.
oh man you're insane. I mean it in the positive way
An interesting thing about the NES/Famicom is that is uses a 6502 processor, where were originally released in 1975.
Your honesty, and your ability - instant sub.
Very nice - you've given me an interesting idea for a project/video that I have planned for this summer. I'll be thinking about this more, but I may possibly jump into the repo and make a couple of contributions.
That'd be great.
In keeping with the premise of using only available hardware of the time. Would it not be appropriate to use memory swapping or what it's called, like how they used to get games like Kirby to run on the NES with the 6 Megabit cartridge?
Bank switching? That's to enable cartridges larger than the Cartridge RAM space.
Awesome work! I haven’t studied the code yet, but if you want less glitching, I’d recommend using the MMC5 mapper, which maps a chunk of cartridge RAM to the PPU, making it more like Commodore hardware. It would also give you a lot more data available for bank swapping, if you want to include more executables, and battery-backed-up memory to save its state or have a rewritable file system. Plus, you’d remove the FDS read bottleneck you mentioned.
4:53 A kernel that is running but can't communicate with the world is a terrifying concept 😬
True. It's the technological equivalent of locked-in syndrome. 🙁
Nope just peace like there used to be in computing before it became an algorithmic hellscape.
thank you for sharing this, it’s really amazing what you did, it’s been a while that I didn’t see anything so cool. “*why you do this? , **because is cool and I can do it “
Deffo got my subscription. Cool project, well explained, definitely interesting. People don't credit old hardware enough. Any one that wants to learn coding or computer science nowadays wants to start with the best stuff. Problem is, best stuff is also the most complex stuff, and at the fundamental level, everything works (mostly) just like their initial counterparts did. Sometimes, it's helpful to learn how an old piece of hardware or software works, because it will help you understand the new stuff.
and here I was trying to program my own kernel for a gameboy operating system.
It should be possible on Gameboy Advance or Nintendo DS. The DS has the RAM requirement for Windows 95 - and more if you install a RAM expansion cartridge.
i understood probably 10% but this was amazing. will follow you. thx
The beauty of writing the game is you can indeed move the goal posts.
I lost The Game
I always thought the Question was "Can it run Crysis", but I guess this'll do.
That JonTron clip brought me gleeful laughter. I like that “but why?” a little too much
Music during the executive code is my respect🤙
I was running Lunix for the "lulz" back then the uptime wraps around after something like 37 days as far as I recall.
I would have been really surprised if any version of Linux worked on a 6502 at all, let alone an NES specifically. The very first version of Linux was written for a 386, which is 32-bit. Even the original Unix from Bell Labs would be kind of a stretch, simply because the PDP-11 computers it was designed for were 16-bit systems already. That's basically why it took so long for a Unix-like operating system to be possible on microcomputers... Unix was relegated to the server room and that paved the way for stuff like CP/M and DOS that was designed for single-user microcomputers rather than big expensive mainframes. Even so, the very first version of Xenix from Microsoft did run on an 8088, but that was a 16-bit architecture internally with an 8-bit data bus. Plus it required 256K of RAM. So yeah, I can imagine a lot of compromises would be needed for a Unix-like experience on that CPU, even without the RAM constraints of the NES.
DarkMateria reference... I see what you did there!
This is so impressive to see, especially considering the limitations of the NES, I wonder if this would also be possible on the SNES and be more usable in some way due to the more powerful hardware or if in the end there wouldn't be that much of a difference running a OS between the two.
Subscribed just because of the humor, stayed for the tech knowledge
absolute mad man. Subscribed
0:19 Yes! This is the greatest thing about cartridges, you can just stick whatever you want in, we need more consoles that accept cartridges like this in modern day! What, security risks? Nonsense!
this is the type of shit i love to see from < 1k sub channels
This is so cool!
Just as Sting and the Police foretold...
You sent a NES OS to the world.
This is dope. Great job!
Thank you Sir for your contributions to the advancement of humanity.
I don't know about Linux, but I'd like to put Nestopia, and my entire library of NES games into one single cartridge and play it an actual NES. That would be pretty cool.
great work! I wonder how much work it would be to eliminate lunix's disk reliance entirely. also, this makes me fantasize about porting the original unix version 6 to the system
I have a Sharp Twin Famicom and a Family Basic Keyboard, with an everdrive. I'm going to give this a shot! The C64 Kernal and BASIC port is super fun to play with, as well!
I thought "But can it run Doom?" and "But can it run Crysis?" were what you ask about every computer.
for this kind of thing i'd say qnx would have been perfect, full gui on two floppies would work perfectly.
2:05 at least he leaked the tasteful folder
And here is my mind-blown moment of the day
i think if it existed during the console's lifespan, including extra hardware should be "allowed" in terms of this type of challenge
the entire purpose is that the NES should be the one in control, and not, as you say, "a shitty video card" where it basically takes a backseat to its "coprocessor" and instead becomes the coprocessor itself
so even if the coprocessor is more powerful than the normal processor, the main processor should be doing all of the management, and using the coprocessor instead as support hardware
what this means is that regardless of how fast the coprocessor works, its limited by the instruction processing power of the host processor, and what the host processor can then do with that
Very in depth knowledge, you rock!