Linux Running on an NES? 

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?

If only people were more comfortable with this. Sometimes it's better to simply move 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

😂 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

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.

"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

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.

dude even included some old internet memes to bring me back to happier days of internetting. :_)

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

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.

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

Ohhh, I KNEW I knew that voice from somewhere!!!

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

That'd be great.

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

Bank switching? That's to enable cartridges larger than the Cartridge RAM space.

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.

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

Sounds kinda like a back handed compliment, but I doubt that was intentional.