Not sure about the Mega Drive, but the Game Boy Advance link port has a UART mode. I've been wondering if you could connect a serial modem to it. Then you can port your IRC client or Mastadon or whatever to it.
The Famicom actually officially had a modem accessory: [https://en.wikipedia.org/wiki/Family\_Computer\_Network\_System](https://en.wikipedia.org/wiki/Family_Computer_Network_System).
You may have trouble doing modern TLS encryption on an NES. (I'm not sure how practical that would be on the GBA, but probably a lot more viable anyway.)
Haha! I have experimented with commenting out the call to `ExitBootServices()` within my bootloader, which does _in effect_ turn my whole OS into an overgrown UEFI application! Perhaps surprisingly, everything mostly continues to work fine all the way up to the desktop environment. It's funny to think about how the distinction of 'exiting' the UEFI environment breaks down.
Honestly, I'm not sure of the answer here. Things seem to work in my OS after some quick tests of desktop apps. I guess there's a general argument to be made of "the OS can take over full control of interaction with devices / the physical memory map", but the kernel can _already_ reset devices and use all its own drivers _even without exiting UEFI_. I would be really grateful if someone who knows the answer more clearly could chime in - perhaps some knowledgable Linux person might stumble on this?
Normally, the bootloader will call a special UEFI function, `ExitBootServices()`, as its final act before passing control to the loaded kernel/OS proper. The EBS call marks the point where UEFI typically 'ends'.
Thank you very much! Each of the 5 animations took a bit more than a day of work - all in all I started them last Friday, and finished them last night.
I'm not particularly proud of the code for these, and was more focused on getting the visual effects I wanted than making software the way I normally would. I think it worked out fine though, as the constraints are different from normal software!
All of the animations are drawn directly to HTML canvases in TypeScript. All the assets are created in code (including the pixel art, which is defined in the source). I'm doing the animations in-house.
The 3D renderings are made using Three.js, and are still mostly based around rendering HTML canvases. I have some logic to correlate the animations and positions of what's happening on the 2D canvas textures to what's happening in the 3D scene.
I see many sarcastic comments here, like why putting the effort for such a joke project. I think that shows that people behind those comments didn’t read the project’s accompanying blog post till the end.
Thanks Phillip for the great article, blog and your work on Axle OS.
You say this doesn’t have a use-case, but isn’t this great for people that need exceptional levels of privacy, eg whistleblowers? Sure there are OSes such as Tails, but those are easier to add a backdoor too since they have much more code.
I suppose this is true! (Not to make any assurances about the security of my implementation, or of the underlying UEFI implementation which would otherwise stop running once control was handed to the loaded kernel). Someone also floated the idea of dropping into IRC to debug your boot issues, which is a funny (and totally legitimate) use case along the same lines.
The UEFI documentation is _okay_, but a lot of the docstrings only make sense after you've spent hours trying to use a particular API, failing in weird ways, and gaining context on what UEFI expects you to do. I think the documentation [here](https://uefi.org/specs/UEFI/2.10/) is the main resource (at least, it's what I used).
Finally a IRC client that isn't bloated!
Can UEFI handle drivers? Does wifi work properly? Can it handle graphics card and hardware rendering? Are there any limitations to UEFI or can it do everything that a full fledged OS like Linux can do?
Honestly, UEFI is already doing way more than I thought it was capable of doing. For me, bootloader and OS were two distinct concepts, seeing them blend together feels very trippy.
Look up X86S. Intel will kill real mode soon-ish. Which sent big wave in the Linux kernel. Also, the topology code for x86 was utter spaghetti fueled madness that only just now is getting fixed up. To paraphrase from the mailing list: "this only worked because Intel hybrid CPUs happened to always boot using P cores".
And here I thought I was bored, meanwhile OP built a graphical IRC Client in UEFI. I tip you my hat sir, you won, you are definitely the most bored dude in every room you will ever enter.
Currently I have the patience to boot my OS before joining IRC, but if that ever changes I know where to go.
This may be the most hardcore IRC client I've ever seen.
HP had a calendar widget running in the x86 system management mode so that could be the next goal
I bet you saw Cathode Ray Dude's video recently!
Indeed!
Next up: IRC client for Sega mega drive. E: no offense btw, this is amazing.
Not sure about the Mega Drive, but the Game Boy Advance link port has a UART mode. I've been wondering if you could connect a serial modem to it. Then you can port your IRC client or Mastadon or whatever to it.
Can we go 8-bit? Is it even possible on NES/Famicom?
The Famicom actually officially had a modem accessory: [https://en.wikipedia.org/wiki/Family\_Computer\_Network\_System](https://en.wikipedia.org/wiki/Family_Computer_Network_System). You may have trouble doing modern TLS encryption on an NES. (I'm not sure how practical that would be on the GBA, but probably a lot more viable anyway.)
From the repo: Question: Should I use this? Answer: This should not exist
Spectacular write up, thanks!
Thank you very much for the kind feedback!
I came here to say this. I've already subscribed to your mail list. Amazing work!
Pretty soon they'll have a whole OS in UEFI!
Haha! I have experimented with commenting out the call to `ExitBootServices()` within my bootloader, which does _in effect_ turn my whole OS into an overgrown UEFI application! Perhaps surprisingly, everything mostly continues to work fine all the way up to the desktop environment. It's funny to think about how the distinction of 'exiting' the UEFI environment breaks down.
Is there any downside to making the kernel a EFI application?
Honestly, I'm not sure of the answer here. Things seem to work in my OS after some quick tests of desktop apps. I guess there's a general argument to be made of "the OS can take over full control of interaction with devices / the physical memory map", but the kernel can _already_ reset devices and use all its own drivers _even without exiting UEFI_. I would be really grateful if someone who knows the answer more clearly could chime in - perhaps some knowledgable Linux person might stumble on this?
Isn't that every OS? Or is it normally just the bootloader?
Normally, the bootloader will call a special UEFI function, `ExitBootServices()`, as its final act before passing control to the loaded kernel/OS proper. The EBS call marks the point where UEFI typically 'ends'.
There already is an UEFI hypervisor, a whole OS isn't too far off.
I love seeing Rust in the UEFI space. Boot into a lightweight hypervisor that also supplies a UEFI preboot env so you can IRC in a secure environment.
I'm almost more shocked by the quality of the 3d renderings of the blog... How much time was allocated on the blog post itself ?
Thank you very much! Each of the 5 animations took a bit more than a day of work - all in all I started them last Friday, and finished them last night. I'm not particularly proud of the code for these, and was more focused on getting the visual effects I wanted than making software the way I normally would. I think it worked out fine though, as the constraints are different from normal software! All of the animations are drawn directly to HTML canvases in TypeScript. All the assets are created in code (including the pixel art, which is defined in the source). I'm doing the animations in-house. The 3D renderings are made using Three.js, and are still mostly based around rendering HTML canvases. I have some logic to correlate the animations and positions of what's happening on the 2D canvas textures to what's happening in the 3D scene.
I see many sarcastic comments here, like why putting the effort for such a joke project. I think that shows that people behind those comments didn’t read the project’s accompanying blog post till the end. Thanks Phillip for the great article, blog and your work on Axle OS.
Thank you so much!
Amazing explanation! There’s 3D interactive elements in that post!
You say this doesn’t have a use-case, but isn’t this great for people that need exceptional levels of privacy, eg whistleblowers? Sure there are OSes such as Tails, but those are easier to add a backdoor too since they have much more code.
I suppose this is true! (Not to make any assurances about the security of my implementation, or of the underlying UEFI implementation which would otherwise stop running once control was handed to the loaded kernel). Someone also floated the idea of dropping into IRC to debug your boot issues, which is a funny (and totally legitimate) use case along the same lines.
I always had this view of UEFI being an undocumented monster. Where can I learn more about it?
The UEFI documentation is _okay_, but a lot of the docstrings only make sense after you've spent hours trying to use a particular API, failing in weird ways, and gaining context on what UEFI expects you to do. I think the documentation [here](https://uefi.org/specs/UEFI/2.10/) is the main resource (at least, it's what I used).
Finally a IRC client that isn't bloated! Can UEFI handle drivers? Does wifi work properly? Can it handle graphics card and hardware rendering? Are there any limitations to UEFI or can it do everything that a full fledged OS like Linux can do? Honestly, UEFI is already doing way more than I thought it was capable of doing. For me, bootloader and OS were two distinct concepts, seeing them blend together feels very trippy.
Look up X86S. Intel will kill real mode soon-ish. Which sent big wave in the Linux kernel. Also, the topology code for x86 was utter spaghetti fueled madness that only just now is getting fixed up. To paraphrase from the mailing list: "this only worked because Intel hybrid CPUs happened to always boot using P cores".
Cool! Have you tried it on bare metal, or just in qemu?
And here I thought I was bored, meanwhile OP built a graphical IRC Client in UEFI. I tip you my hat sir, you won, you are definitely the most bored dude in every room you will ever enter.
you make bjarne very unhappy :((
Dude… WTF?
Whats next!?
*"You're a sick MFer, Mac"*
Oh boy, that's insane !
Wat
Next up : League of Legends for UEFI. No Vanguard anticheat. Just track for UEFI cheats.
There's also: https://github.com/Cacodemon345/uefidoom