People make fun of redditors for never leaving the basement, but then they do and we discover maybe they shouldn't have.
tfw some microcontrollers are more power than most of the desktops you've ever owned
After a frankly unreasonable amount of work, I've updated https://deb.fbxl.net with FreeBASIC FBXL Edition 1.20.1.
I want to say the important part first: this is unofficial, unsupported, experimental, and built mostly by some dummy from the sticks because I wanted it to exist. The FreeBASIC core developers did the real work over the years. I came along later and pushed on packaging, ports, cleanup, docs, testing, and a few new toys. If something here is useful, excellent. If something here is broken, assume my intern who definitely exists and isn't just me probably broke it.
*Universal installer*
The front page has a universal installer that tries to detect what you are running and install the right FreeBASIC package for it.
For Debian, Ubuntu, and Raspbian-style systems, it can add deb.fbxl.net as an apt repo. For other systems it tries to do the least surprising thing for that OS.
Windows users also get standalone installers right up front. There is one for normal Win32/Win64 x86 and x86_64 systems, and one for Windows on ARM64.
*The FBXL FreeBASIC Insanity Matrix (of compatibility)*
There are FreeBASIC packages now for a lot more systems than I ever expected to see in one place before I started working on this: Windows, Linux, macOS, Haiku, the BSDs, Solaris/illumos, Android, JavaScript through Emscripten, original Xbox, Wii, DOS, Cygwin, MinGW, and more.
On Linux in particular, there are packages across a pile of CPU families: x86, x86_64, armel, armhf, arm64, ppc64el, riscv64, and s390x. Not every OS gets every CPU, because emulated builds and testing already took three days and three nights, but the coverage is much wider than it was.
There is also a specific Raspbian repo for the ARMv6+VFP Raspberry Pi 1 and Raspberry Pi Zero world, which matters because those little machines are not the same thing as generic armhf but they also aren't armel.
Most of this was not just "compile it once and throw it on a web server." I wasn't ready to publicly release until the ports were tested with fbctests, example builds, smoke tests, old BASIC programs, graphics tests, sound tests, and whatever strange hardware I could get my hands on. I've got hacked up armhf Chromebooks, and android set top boxes running Linux, I've got an old Motorola telephone running postmarketos, and more odd ducks so I could see it working on hardware and not just in an emulator. Each package was also tested as much as we (I keep saying 'we' but I mean me) could by trying to install and test on a blank docker container or VM (or in the case of arm64 windows, spinning up an azure VM)
*What works and what does not*
Most parts are functional, but there are still limits, since some platforms just don't do certain things.
DOS support does not have threads or TCP support, and its audio support is blocking. JavaScript support also does not have threads or TCP support. Some external libraries are only realistic on certain platforms, and some platforms are always going to be weirder than others.
That said, a surprising amount of this works. I didn't expect for example to get networking working on... well, we'll talk about that in a moment.
*Sfxlib*
FreeBASIC has always had gfxlib, but sound was still mostly a "go find a library and hope it works where you need it" situation.
This edition adds sfxlib, a simple built-in sound library in the same spirit as gfxlib. It gives BASIC programs a straightforward way to make sound, play samples, use wavetable-style audio, and deal with MIDI-style behavior without immediately dragging the programmer into a giant external dependency mess.
It is not meant to replace every serious audio library. It is meant to make sound available in the same plain, beginner-friendly way graphics already are.
*Gfxlib, touch, and gamepads*
Gfxlib got a lot of attention too.
There are new multitouch commands for modern touch devices, plus getxpad support for Xbox-style controllers and similar gamepads. The goal was to make contemporary input feel like it belongs in BASIC because otherwise we would be spending a lot of time pretending screens are mice and Xpads are 4 button joysticks.
This matters a lot more now that FreeBASIC can target phones, odd handhelds, old consoles, little ARM boards, and normal desktop machines from the same general language.
*Native TCP support*
FreeBASIC already had old-school BASIC-style file and device I/O, but networking usually meant reaching for outside libraries.
This edition adds OPEN TCP and OPEN TCP SERVER, so simple network programs can use the same style people already know: print #, input #, get #, put #.
It is not trying to be a full web framework. It is just trying to make basic network communication feel like BASIC.
I was able to port my old network game Duel to the new framework, and got to experience having a game with a windows host, an android client, a Wii client, an Xbox client, and a haiku client playing the same game.
*Android and JavaScript*
The Android and JavaScript ports already existed in some form. The work here was making them much more usable.
Android now has packaging scripts that hide a lot of the Android SDK/NDK nonsense. JavaScript builds are wrapped up better too, so getting something from .bas to a browser project is less of a scavenger hunt.
Both have gfxlib and sfxlib work behind them. Both are still special targets with special rules, but they are a lot less theoretical now.
*Original Xbox and Wii*
This is the part where things got silly.
The original Xbox port is now split out as its own installable target. It builds .xbe files using the descendant of openxdk. It has enough runtime, graphics, sound, and packaging support to be a real target instead of a fossilized curiosity.
The Wii port came out of PowerPC work and a bad idea that turned out to be a good test. It forced us to care about endian assumptions, old-console constraints, graphics behavior, and whether this whole thing could survive outside the comfortable PC world.
Both are separate packages on windows and ubuntu questing and resolute now. If you want them, install them.
*General cleanup*
A lot of this work was boring the way you want your runtime library to be boring.
Warnings were cleaned up. Unsafe C library usage got replaced where it made sense. Build scripts were tightened. Installers were built. Platform code was separated more cleanly.
There was also a lot of work making the compiler less surprised by unusual architectures. Big-endian machines, ARM machines, Windows ARM64, old consoles, tiny systems, and weird Unix-like systems are excellent at finding assumptions.
Along the way, we fixed a lot of little hidden bugs just to pass fbctests properly.
*External libraries*
One thing this work made obvious is that FreeBASIC's external library story has always been a little optimistic.
Some libraries are easy on Windows and annoying elsewhere. Some work on Linux but not on smaller or stranger targets. Some examples compile everywhere. Some are really only honest on one platform/processor combination (usually just ms-dos or windows on x86).
I tried to improve the documentation around that so people have a better sense of what is realistic instead of being handed a list of headers and sent into the woods. The windows installer is so big because I also tried to keep as many library promises as I could, and that means carting around a boatload of library files. It's been a while since I've run the win32 exampleageddon and we've had a lot of work after that, but I believe every non-MSDOS library compiles on win32 at this point, and we've greatly improved the library example situation on windows x86_64 and linux.
*Why I did it*
I did this because I wanted this specific FreeBASIC to be a thing -- easy to install anywhere, easy to run, easy to use, and holding onto a basic set of APIs you can rely on.
FreeBASIC was set up brilliantly to have a lot of secret cross-compatibility. It has a base, then it has code specific to certain OS platforms, then different CPU architectures, and we just get that for free. I wanted to leverage that to keep that promise.
If we can keep that promise, then it becomes easier for the next generation of programmers to get started. Just install and go, whether you're on arm or x86 or for some reason an IBM z-series mainframe (who are you and what are you doing?)
I do not know how much more I will be poking at FreeBASIC after this. This took a lot. I was up late night after night, it's been months of continuous effort. But I am glad it exists now.
Hopefully it'll be useful to someone else as well.
I want to say the important part first: this is unofficial, unsupported, experimental, and built mostly by some dummy from the sticks because I wanted it to exist. The FreeBASIC core developers did the real work over the years. I came along later and pushed on packaging, ports, cleanup, docs, testing, and a few new toys. If something here is useful, excellent. If something here is broken, assume my intern who definitely exists and isn't just me probably broke it.
*Universal installer*
The front page has a universal installer that tries to detect what you are running and install the right FreeBASIC package for it.
For Debian, Ubuntu, and Raspbian-style systems, it can add deb.fbxl.net as an apt repo. For other systems it tries to do the least surprising thing for that OS.
Windows users also get standalone installers right up front. There is one for normal Win32/Win64 x86 and x86_64 systems, and one for Windows on ARM64.
*The FBXL FreeBASIC Insanity Matrix (of compatibility)*
There are FreeBASIC packages now for a lot more systems than I ever expected to see in one place before I started working on this: Windows, Linux, macOS, Haiku, the BSDs, Solaris/illumos, Android, JavaScript through Emscripten, original Xbox, Wii, DOS, Cygwin, MinGW, and more.
On Linux in particular, there are packages across a pile of CPU families: x86, x86_64, armel, armhf, arm64, ppc64el, riscv64, and s390x. Not every OS gets every CPU, because emulated builds and testing already took three days and three nights, but the coverage is much wider than it was.
There is also a specific Raspbian repo for the ARMv6+VFP Raspberry Pi 1 and Raspberry Pi Zero world, which matters because those little machines are not the same thing as generic armhf but they also aren't armel.
Most of this was not just "compile it once and throw it on a web server." I wasn't ready to publicly release until the ports were tested with fbctests, example builds, smoke tests, old BASIC programs, graphics tests, sound tests, and whatever strange hardware I could get my hands on. I've got hacked up armhf Chromebooks, and android set top boxes running Linux, I've got an old Motorola telephone running postmarketos, and more odd ducks so I could see it working on hardware and not just in an emulator. Each package was also tested as much as we (I keep saying 'we' but I mean me) could by trying to install and test on a blank docker container or VM (or in the case of arm64 windows, spinning up an azure VM)
*What works and what does not*
Most parts are functional, but there are still limits, since some platforms just don't do certain things.
DOS support does not have threads or TCP support, and its audio support is blocking. JavaScript support also does not have threads or TCP support. Some external libraries are only realistic on certain platforms, and some platforms are always going to be weirder than others.
That said, a surprising amount of this works. I didn't expect for example to get networking working on... well, we'll talk about that in a moment.
*Sfxlib*
FreeBASIC has always had gfxlib, but sound was still mostly a "go find a library and hope it works where you need it" situation.
This edition adds sfxlib, a simple built-in sound library in the same spirit as gfxlib. It gives BASIC programs a straightforward way to make sound, play samples, use wavetable-style audio, and deal with MIDI-style behavior without immediately dragging the programmer into a giant external dependency mess.
It is not meant to replace every serious audio library. It is meant to make sound available in the same plain, beginner-friendly way graphics already are.
*Gfxlib, touch, and gamepads*
Gfxlib got a lot of attention too.
There are new multitouch commands for modern touch devices, plus getxpad support for Xbox-style controllers and similar gamepads. The goal was to make contemporary input feel like it belongs in BASIC because otherwise we would be spending a lot of time pretending screens are mice and Xpads are 4 button joysticks.
This matters a lot more now that FreeBASIC can target phones, odd handhelds, old consoles, little ARM boards, and normal desktop machines from the same general language.
*Native TCP support*
FreeBASIC already had old-school BASIC-style file and device I/O, but networking usually meant reaching for outside libraries.
This edition adds OPEN TCP and OPEN TCP SERVER, so simple network programs can use the same style people already know: print #, input #, get #, put #.
It is not trying to be a full web framework. It is just trying to make basic network communication feel like BASIC.
I was able to port my old network game Duel to the new framework, and got to experience having a game with a windows host, an android client, a Wii client, an Xbox client, and a haiku client playing the same game.
*Android and JavaScript*
The Android and JavaScript ports already existed in some form. The work here was making them much more usable.
Android now has packaging scripts that hide a lot of the Android SDK/NDK nonsense. JavaScript builds are wrapped up better too, so getting something from .bas to a browser project is less of a scavenger hunt.
Both have gfxlib and sfxlib work behind them. Both are still special targets with special rules, but they are a lot less theoretical now.
*Original Xbox and Wii*
This is the part where things got silly.
The original Xbox port is now split out as its own installable target. It builds .xbe files using the descendant of openxdk. It has enough runtime, graphics, sound, and packaging support to be a real target instead of a fossilized curiosity.
The Wii port came out of PowerPC work and a bad idea that turned out to be a good test. It forced us to care about endian assumptions, old-console constraints, graphics behavior, and whether this whole thing could survive outside the comfortable PC world.
Both are separate packages on windows and ubuntu questing and resolute now. If you want them, install them.
*General cleanup*
A lot of this work was boring the way you want your runtime library to be boring.
Warnings were cleaned up. Unsafe C library usage got replaced where it made sense. Build scripts were tightened. Installers were built. Platform code was separated more cleanly.
There was also a lot of work making the compiler less surprised by unusual architectures. Big-endian machines, ARM machines, Windows ARM64, old consoles, tiny systems, and weird Unix-like systems are excellent at finding assumptions.
Along the way, we fixed a lot of little hidden bugs just to pass fbctests properly.
*External libraries*
One thing this work made obvious is that FreeBASIC's external library story has always been a little optimistic.
Some libraries are easy on Windows and annoying elsewhere. Some work on Linux but not on smaller or stranger targets. Some examples compile everywhere. Some are really only honest on one platform/processor combination (usually just ms-dos or windows on x86).
I tried to improve the documentation around that so people have a better sense of what is realistic instead of being handed a list of headers and sent into the woods. The windows installer is so big because I also tried to keep as many library promises as I could, and that means carting around a boatload of library files. It's been a while since I've run the win32 exampleageddon and we've had a lot of work after that, but I believe every non-MSDOS library compiles on win32 at this point, and we've greatly improved the library example situation on windows x86_64 and linux.
*Why I did it*
I did this because I wanted this specific FreeBASIC to be a thing -- easy to install anywhere, easy to run, easy to use, and holding onto a basic set of APIs you can rely on.
FreeBASIC was set up brilliantly to have a lot of secret cross-compatibility. It has a base, then it has code specific to certain OS platforms, then different CPU architectures, and we just get that for free. I wanted to leverage that to keep that promise.
If we can keep that promise, then it becomes easier for the next generation of programmers to get started. Just install and go, whether you're on arm or x86 or for some reason an IBM z-series mainframe (who are you and what are you doing?)
I do not know how much more I will be poking at FreeBASIC after this. This took a lot. I was up late night after night, it's been months of continuous effort. But I am glad it exists now.
Hopefully it'll be useful to someone else as well.
Honestly, that's always been my problem with a lot of these people -- they spend all day on youtube talking about how bad the people who are making comic books are, but they aren't making the books. If RGE could put out one book a year, sales would probably be growing, and on its way to being a legit business.
Of course, my work barely comes out any quicker, but I'm just dilettanting about. Last year I published the one book and wrote a second I need to finish up and publish this year, but this year I'm doing a lot on open source software. No matter what I'm not about to quit my day job because besides being a dilettante, I'm also obviously putting out not viral-class work. Don't remember if I ever hit that 19 sales mark on Future Sepsis.
Of course, my work barely comes out any quicker, but I'm just dilettanting about. Last year I published the one book and wrote a second I need to finish up and publish this year, but this year I'm doing a lot on open source software. No matter what I'm not about to quit my day job because besides being a dilettante, I'm also obviously putting out not viral-class work. Don't remember if I ever hit that 19 sales mark on Future Sepsis.
I've added a lot, but the main ones are related to compatibility. I basically went out and tried to find anything that remotely supports groups, and also user workflows.
The frontpage is currently dominated by a piefed history community, and I've successfully followed and heard from kbin, mbin, peertube, and a bunch of others including things like hubzilla, fedigroups, discourse, and nodeBB.
The community tab is totally revamped. Before it'd show whatever users were subscribed to, now we actively seek out the different communities, find out if they are active, find out if our server is federated with them, because I figured it wouldn't be easy to find all the different communities we support in one place anywhere else.
The frontpage is currently dominated by a piefed history community, and I've successfully followed and heard from kbin, mbin, peertube, and a bunch of others including things like hubzilla, fedigroups, discourse, and nodeBB.
The community tab is totally revamped. Before it'd show whatever users were subscribed to, now we actively seek out the different communities, find out if they are active, find out if our server is federated with them, because I figured it wouldn't be easy to find all the different communities we support in one place anywhere else.
In trying to somewhat suppress display of instances that defederate from my lotide (no reason to show it on the communities list, and no reason to keep allowing posting, commenting, and lliking to those servers), I saw that a piefed instance, "anarchist nexus" blocked us. That was mildly humorous on it's own, given what anarchist tends to mean. Then i checked out the site's blocklist, and I burst out laughing. 5 pages of blocks! much anarchism! down with the rules!
@realcaseyrollins You might want to take a look at what lotide.fbxl.net looks like these days. I've been doing some (very retarded and thus very on-brand for me) work on lotide for the last while, and my instance presently does some really neat things.
ngl, I'm wishing I had just set up AMT earlier. A lot of downtime could have been avoided on a particular server. OTOH, the security implications of AMT are kinda nuts. You think I'm getting any updated firmware for this thing?
https://www.youtube.com/watch?v=ZUrZHF_WBeI
From the "there's no way that actually happened" department, my little guy just loves this song. It's a long story, but the greek alphabet is one of the things we do in a game we play, totally not about learning but he ends up learning a little bit by osmosis.
From the "there's no way that actually happened" department, my little guy just loves this song. It's a long story, but the greek alphabet is one of the things we do in a game we play, totally not about learning but he ends up learning a little bit by osmosis.
Wish I'd known, I'd have used that. One issue with the goo gone is it's oily.
The adhesive they used on the bed was brutal. I have a sneaking suspicion my bed layers will be better without that thick inconsistently thick layer everywhere it'll be a better print even if you totally ignore the bottom surface.
The adhesive they used on the bed was brutal. I have a sneaking suspicion my bed layers will be better without that thick inconsistently thick layer everywhere it'll be a better print even if you totally ignore the bottom surface.
After owning my tevo tornado for years and years, after the original textured bed came up and was effectively destroyed, then I had to deal with all the adhesive on the glass bed underneath for years, I finally got my hands on some goo gone.
Removing the adhesive from the print bed has imo brought the printer to the next level. It's printing on glass.
Thing is, I simply haven't had the bandwidth to print anything on the revealed glass print bed, because it meant re-levelling the print bed and all that.
Today I'm doing my first print since removing the adhesive. Wish me luck -- it's still a bit dodgy, but the first layer seems to have gone down pretty well. Having a perfectly flat print surface really changed everything.
Removing the adhesive from the print bed has imo brought the printer to the next level. It's printing on glass.
Thing is, I simply haven't had the bandwidth to print anything on the revealed glass print bed, because it meant re-levelling the print bed and all that.
Today I'm doing my first print since removing the adhesive. Wish me luck -- it's still a bit dodgy, but the first layer seems to have gone down pretty well. Having a perfectly flat print surface really changed everything.
https://www.youtube.com/watch?v=BxkfuiMz8-8
You know, I just got FreeBASIC running on PowerPC (Hence running gorilla.bas on the wii in my last screenshot). I wonder if Windows NT for powerpc has anything like current gnu utils and gcc? gorilla.bas for windows nt for powerpc would be really funny.
But no, I'm not adding any more platforms right now, someone else can climb that mountain. Possibly myself another time.
You know, I just got FreeBASIC running on PowerPC (Hence running gorilla.bas on the wii in my last screenshot). I wonder if Windows NT for powerpc has anything like current gnu utils and gcc? gorilla.bas for windows nt for powerpc would be really funny.
But no, I'm not adding any more platforms right now, someone else can climb that mountain. Possibly myself another time.
The greatest white pill to everyone should be the fact that the future is written by those who show up, and most of the enemies of humanity have it as a part of their core ideology not to show up because to take responsibility is to carry a burden and to be burdened is to be a slave. To be clear, some people are just demoralized, or atomized, or confused, and I'm sure that many of them can be redeemed. However, the enemies of humanity do have it as part of that core ideology.
Frens, you can just do stuff. And just think a little bit further ahead, believe in virtue, find disgust in vice, and in a much shorter time than you can imagine, the future will belong to your descendants. Not only are you more likely to reproduce, but you are more likely to pass on a vision of how to live that will result in strong and successful descendants. Even those who are not your direct descendants are eventually going to look around and realize the people who listen to you and followed your example are doing a lot better than the people who listened to their rare parents.
All you got to do is put down the Harry Potter, stop watching the latest Star wars slop, and take on real life with both hands.
Frens, you can just do stuff. And just think a little bit further ahead, believe in virtue, find disgust in vice, and in a much shorter time than you can imagine, the future will belong to your descendants. Not only are you more likely to reproduce, but you are more likely to pass on a vision of how to live that will result in strong and successful descendants. Even those who are not your direct descendants are eventually going to look around and realize the people who listen to you and followed your example are doing a lot better than the people who listened to their rare parents.
All you got to do is put down the Harry Potter, stop watching the latest Star wars slop, and take on real life with both hands.
Screenshot of my old first person space invaders game running on my phone. Considering that game is written entirely in BASIC, I'm pretty excited successfully getting it to run, especially with sound. Mostly still the original code too, and still compiles on other OSes.
Unfortunately, I'm stuck under the long tail of the pareto now. Lots of little things to work through such as pauses caused by the sound driver not being entirely up to snuff.
Unfortunately, I'm stuck under the long tail of the pareto now. Lots of little things to work through such as pauses caused by the sound driver not being entirely up to snuff.
Maybe he was saying it because he thinks it's true, but maybe he was saying it because he thinks it's clearly absurd and it should be clear why the logic makes it absurd.
There's an obvious parallel to the opposite point made routinely by socialists: That Hitler did X therefore everyone who does X is like Hitler and therefore a fascist. Reductio ad Hitlerum was a common logical fallacy before the 2010s and 2020s, but really ramped up in that era to unprecedented heights.
Consider that the entire Earth's establishment media sources decided to claim that Musk raised his arm in salute, Hitler raised his arm in salute, therefore Musk is Hitler. He's been a direct and personal recipient of such fallacious logic.
But I dunno. I was never on Twitter on the first place, and I don't follow tweets by Elon or anyone else. Maybe he's just an absurdly literal person who never says anything but robotic expressions of literal truth. That would be an odd thing for a snake oil salesman to be, however.
There's an obvious parallel to the opposite point made routinely by socialists: That Hitler did X therefore everyone who does X is like Hitler and therefore a fascist. Reductio ad Hitlerum was a common logical fallacy before the 2010s and 2020s, but really ramped up in that era to unprecedented heights.
Consider that the entire Earth's establishment media sources decided to claim that Musk raised his arm in salute, Hitler raised his arm in salute, therefore Musk is Hitler. He's been a direct and personal recipient of such fallacious logic.
But I dunno. I was never on Twitter on the first place, and I don't follow tweets by Elon or anyone else. Maybe he's just an absurdly literal person who never says anything but robotic expressions of literal truth. That would be an odd thing for a snake oil salesman to be, however.
This message is being posted from Haiku on my Chromebook c202s. Probably the first person on Earth to post such a thing using the native keyboard and trackpad.
This chromebook has several show stoppers with respect to using it in any capacity. The first is the touchpad. I needed to enable the C202S's intel I2C controller, and wired the existing Elan I2C touchpad driver to the i2c controler, and playued with the clickpad/report handling enough for basic movement, clicks, and gestures.
The second is the keyboard. I started down a cros_ec route because I was led to believe you needed the microcontroller to work to successfully read the keyboard, but during development of that driver, it became clear we were on the wrong track. The keyboard was actually exposed through the legacy ps2 path, so we fixed the haiku ps2 driver to poll for input when it appears there's keys ready to be delivered but irq1 isn't being delivered consistently.
I believe both the keyboard and touchpad fixes can be easily upstreamed, I'll look more at that later.
The next steps are the emmc support (I'm running off a small usb stick at the moment), and sound support (which is turning out to be really tough because linux drivers and haiku drivers are way different)
In my view, haiku is ideal for this little chromebook (though the chromebook may not be ideal for haiku!) because it has limited memory and limited storage, so a 500MB OS that lives comfortably on a 16GB stick.
Next step is emmc support, which seems to just be a little extension of the existing emmc/sdmmc code, plumbing the quriky chromebook stuff into the existing work. That's been where the most bang for my buck has come from, and that's why the sound has been such a challenge -- You definitely can't just port linux drivers over easily.
This chromebook has several show stoppers with respect to using it in any capacity. The first is the touchpad. I needed to enable the C202S's intel I2C controller, and wired the existing Elan I2C touchpad driver to the i2c controler, and playued with the clickpad/report handling enough for basic movement, clicks, and gestures.
The second is the keyboard. I started down a cros_ec route because I was led to believe you needed the microcontroller to work to successfully read the keyboard, but during development of that driver, it became clear we were on the wrong track. The keyboard was actually exposed through the legacy ps2 path, so we fixed the haiku ps2 driver to poll for input when it appears there's keys ready to be delivered but irq1 isn't being delivered consistently.
I believe both the keyboard and touchpad fixes can be easily upstreamed, I'll look more at that later.
The next steps are the emmc support (I'm running off a small usb stick at the moment), and sound support (which is turning out to be really tough because linux drivers and haiku drivers are way different)
In my view, haiku is ideal for this little chromebook (though the chromebook may not be ideal for haiku!) because it has limited memory and limited storage, so a 500MB OS that lives comfortably on a 16GB stick.
Next step is emmc support, which seems to just be a little extension of the existing emmc/sdmmc code, plumbing the quriky chromebook stuff into the existing work. That's been where the most bang for my buck has come from, and that's why the sound has been such a challenge -- You definitely can't just port linux drivers over easily.
It wasn't really practical, would have been way more work. The driveway is directly attached to the house right to the property line, so to bypass the house, you'd need to jackhammer up most of the cement driveway to dig a 6 foot deep trench. It actually was far more practical and efficient to drill under the house.