2025-10-29 09:30:09 Start menu Windows 11 uses React Native? Honestly I'm more surprised the task bar isn't using it. I'm amazed there isn't a web browser instance per HWND. 2025-10-29 14:36:02 don't give them ideas... 2025-10-29 15:24:07 a small update on the ilo-amd64-uefi: I've implemented the multi session bits from the milo.c variation, so I can switch between 5 sessions (only the current is actually active, just as with milo.c), have fixed some bugs, improved detection of the blocks partition, and tested on a few more physical machines without any issues. 2025-10-29 15:33:10 Awesome 2025-10-29 15:33:24 What do you think of UEFI so far? 2025-10-29 15:35:59 To me the whole thing feels like "please don't make me implement dynamic linking", if EFI had started a few years later I suspect they would have based it all on ELF and had dynamic linking 2025-10-29 15:37:01 But in a weird way the structs-of-function-pointers inside structs-of-function-pointers approach seems to solve a lot of external namespace issues outright 2025-10-29 15:37:50 And GUIDs galore 2025-10-29 15:47:28 I probably haven't gone as far as crc in my EFI Forth implementation (but still, I boot, I have storage, console, graphics, keyboard, mouse), but properly wrapped, UEFI is convenient to use. It's nice to have access to an API that covers such a wide range of hardware 2025-10-29 15:48:18 what I suspect is that UEFI implementations are nightmarish in complexity. I wouldn't want to see what's under that hood. 2025-10-29 15:59:32 I'm looking really forward to getting mine far enough along to use, but that's a ways to go yet. I've barely started. I'm leaning really hard into the metacompile angle right from the start, so I'm moving slow and careful here. 2025-10-29 16:13:40 vdupras: You might have gone further than crc already, if you've got graphics and mouse input 2025-10-29 16:14:25 I think a lot of the UEFI firmware is based on open source stuff, the firmware writers just make essentially 'drivers' for that 2025-10-29 16:14:44 I think a lot of the intel chipset 'drivers' are open source, you can see how they implement some of the core CPU features 2025-10-29 16:15:15 UEFI isn't everything that your BIOS firmware does, and I suspect the UEFI drivers may be the better part of those codebases 2025-10-29 16:16:13 As opposed to their ring -1 interrupts that run when the OS has booted doing only God knows what and try to hide their activity by rewriting the CPU timers 2025-10-29 16:16:38 I have limited graphics, but no mouse 2025-10-29 16:16:56 "already" happened a while ago, it's just that I stopped as soon as it was barely working 2025-10-29 16:17:25 it's not because it's open source that it can't have a nightmarish complexity :) 2025-10-29 16:17:29 "I stopped as soon as it was barely working" story of all my projects :) 2025-10-29 16:18:27 "one day, I'll go back to it and polish it" is the lie we all tell ourselves 2025-10-29 16:20:07 I haven't ever tried to look at any uefi implementations 2025-10-29 16:42:12 I hope it's not considered as spam, but I'd like to show off a 300 lines of code application designed to run on the TI-84+ today: https://git.sr.ht/~vdupras/hp16c-ti 2025-10-29 16:45:14 When compared to something similar (but with a wider scope) like https://github.com/bxparks/rpn83p I think it shows well how Forth, doing its usual "cheating", can end up achieving a lot while taking a radically simpler path 2025-10-29 17:05:01 That's on topic, no worries 2025-10-29 17:08:01 Interesting code 2025-10-29 17:47:57 changing the word size is like the main feature of hp16c 2025-10-29 17:50:32 even rpn83p doesn't implement it, since it's not trying to emulate an hp16c. but the hp16c lets you set any word size from 1 to 64 2025-10-29 17:54:05 yeah, I agree that word size is important, but for the uses I have in mind for my own use, simply ignoring the left half (for 32-bit, for example) of the screen is sufficient 2025-10-29 18:08:04 lmt: I'm curious. Have you actually used a HP-16C? do you have a few examples of cases where usage of esoteric widths was important (as opposed, for example, to simply ignore the overflow shown on the screen)? Me, I can only think of rotation and conversion decimal representation. 2025-10-29 18:53:16 I haven't used it, only read the manual 2025-10-29 18:53:31 the intent is clearly to reproduce exactly what your hardware does which is why it also has three signedness modes 2025-10-29 18:54:19 maybe you want the numbers to overflow. or are trying to reproduce something happening on the hardware 2025-10-29 18:54:59 i agree it doesn't seem super useful but i'm not a hardware engineer circa 1982 2025-10-29 18:57:04 there's probably some fancy code that does some operations quickly by relying on overflow 2025-10-29 19:16:28 See the book "Hacker's Delight." It's just chock full of such interesting little tricks. One of my favorites is to divide (by a known fixed value) by multiplying instead, which is substantially faster. 2025-10-29 20:50:56 compilers usually optimise for that, except when it's GCC and you're compiling Thumb-1 code 2025-10-29 20:51:37 and when i say optimise i mean even with optimisations disabled 2025-10-29 20:53:03 but for Thumb-1 code, GCC would rather defer you to the software implementation of division, even though on every not-super-weird ARM CPU ever made that's actually slower than a multiply, even if you have the slow multiplier on a Cortex-M0/M0+ 2025-10-29 20:53:52 thankfully a divide by a power of two gets optimised 2025-10-29 22:01:42 GreaseMonkey: I've found on Z80 for instance it's faster to multiply with shifts than it is to do software divide for most fixed divisors 2025-10-29 22:02:17 I'm guessing that's just lack of attention to the Thumb-1 code generation more than a conscious decision 2025-10-29 22:07:42 I guess technically the fixed shift multiply method could be faster than a bad multiply