this line of thought brought to you by the realization i had earlier that there's really nothing stopping you from running a varvara machine with an emulated game boy CPU (instead of a uxn virtual machine) and i think that would be fun to try!
the benefit of this is that you could use all of the pre-existing tool chains for game boy dev, and keep all the crunchy constraints of an 8bit system, while having a display that doesn't make information design so difficult. also if you kept the clock speed somewhere in a reasonable range (12MHz?) you could even imagine an actual game boy processor at the center of a (non-emulated) system, if you had an external mcu/fpga that handled the new graphics convention
i think a good idea for a fantasy console would be something like: it's literally an emulated game boy, but running at a higher clock rate, and the emulator bypasses the built-in PPU and interprets the VRAM according to a different convention that would allow for (e.g.) higher resolution graphics
after implementing the basics of DMA, my little game boy emulator gets to the title screen of super mario land (colors are weird because i haven't bothered to implement background palettes yet)
“Have magic 8 balls gone too far? Steve Newman, CEO of Open8Ball think we are now only a matter of months away from an 8 balls induced doomsday event.”
(separately, it's wild to me that a part like that TI source selector switch, which is like two mosfets in a trench coat, can be 6x the cost of a whole damn microcontroller)
actually several components on this BOM (for my solar powered alba generator) have gone up 2x–5x since the last time i did a full order (a year ago). not the end of the world, but it's still annoying, especially when it's a part that had been a little treat to simplify the schematic and bring down part count, but is now one of the most expensive parts in the BOM (e.g. https://www.digikey.com/en/products/detail/texas-instruments/TPS2105DBVR/382078)
economies of scale? in this economy?
why does god's most bog standard 16MBit SPI flash IC cost two and a half god forsaken dollars https://www.digikey.com/en/products/detail/winbond-electronics/W25Q16RVCSJQ/29806956
(i suspect the actual answer to this is Some Kind Of Lisp but i haven't been able to find a lisp that seems like it would be okay for doing data-related stuff)
(i would also like to be able to teach classes in this language, and no one has ever dared to teach lisp to artists and designers. it is forbidden, it seems)
(not 100% sure what i mean by "everyday"—just for making little tools, data processing, integrating things, prototypes. not for high performance or high stakes things)
my wishlist for an "everyday" programming language:
- no slop
- well defined, open standard that changes infrequently
- a small team could reasonably re-implement the language from the standard
- interpreted (or works well in a REPL or notebook-style environment, at least)
- basic string type is unicode (not just byte strings)
- performant tabular and multidimensional data support with non-bulky syntax for indexing/slicing/etc (e.g. https://numpy.org/doc/stable/user/absolute_beginners.html)
- coroutines?
- no slop
For years I've been jealous of biologists and astronomers and all their science-themed wear, and now I finally have designed the laser-themed clothing I've always wanted to wear!
But then my cats came along and started photobombing.
https://www.aiweirdness.com/laser-merch-photoshoot-sabotaged-by-cat/
problem with AI discourse is we're trying to use a technical conversation, where we analyse the development and operation of a technology, to discuss people. the real topic is the people: the people that make or use 'AI'. we're trying to understand them. we didn't realize there were people like this. but now we've discovered that there are, so we're trying to figure it out. via debate and insult, we're trying to work out what the fuck is going on with these people. not the technology, the people
having functions would also open up the possibility of transpiling to, say, C, in a readable manner. (I could technically do this now, but it would just be a big main() function with a lot of labels and gotos.) but it would mean that the language would less directly map to assembly, which seems undesirable. i keep going back and forth (no pun intended) on this
so right now my little stack-based language for the game boy (inchl) has no concept of "function": there are only labels, which you can jump to or call (call puts the PC on the call stack so you can ret later). this is nice because it's conceptually simple and it maps directly to the transpiled output (rgbds assembly). BUT having "functions" as a separate syntactic thing would open up some neat possibilities, like static stack effect checking and inlining
my zeugma brings all the boys to the yard, and to tears
of course, five years from now, it will be a federal crime to make an automated tool that doesn't demonstrably prioritize white people's wellbeing
i will bet every byte of my ram that this thing ends up systematically denying care to people who aren't white, and despite thousands of complaints, neither the startup nor state officials will own up to it until the propublica investigation (or whatever) five years from now https://www.statnews.com/2026/10/05/utah-expands-health-ai-sandbox-picks-third-party-auditors/
