2025-10-15 09:57:27 I wouldn't necessarily expect sleep to be in the default main loop for a Forth, because obviously that would impact performance, so it needs to be something you explicitly integrate. I'd hope that the low power states would be exposed via a nice interface or at least easy to add, for when you do add it, as for most applications it makes sense to add. 2025-10-15 09:58:13 Well I guess maybe it would be in the interpreter loop if waiting a while for input? 2025-10-15 09:58:32 But that also makes assumptions about what kind of code is on there 2025-10-15 10:05:43 veltas, the STM32 sleep states can be very complex, a lot of expertise is needed in my experience 2025-10-15 10:06:29 veltas, but Im comparing it to the MSP430 sleep states which are well integrated and easy to use in comparison to STM32 2025-10-15 10:07:28 veltas, STM seem to just throw in all the peripherals they can get and leave the designer to sort it out ... TI by comparison design all their peripherals to be part of a well integrated suite 2025-10-15 10:09:53 veltas, for instance, my favorite STM32 is the STM32F051 (now obsolite), it's a cortex-m0 and Ive never mastered the sleep state in that the minimum sleep with a interrupt to run I can get (that doesnt require a restart) is 3ma at 3.3v, which is terrible 2025-10-15 10:11:02 and the problem needing a restart is that it's slow, and the usart will miss data, unlike a MSP430 which only takes microseconds to restart 2025-10-15 10:59:12 Well sounds like a good reason for the mecrisp not to do this by default then 2025-10-15 10:59:24 But it's there if you want to figure it out 2025-10-15 11:03:24 veltas, absolutely, and Im sure the sleep power with a STM32H7xx series will be very low, it will just take a while to get it right with any OS, even Mecrisp-Stellaris on that SWISS calculator model 2025-10-15 17:17:19 I have a working amd64 ilo-uefi now. It's slow for i/o, but is working under qemu. 2025-10-15 17:23:07 Very nice. 2025-10-15 17:24:31 I think generally the UEFI I/O stuff is slow, I would guess that's not your fault 2025-10-15 17:24:41 Also nice 2025-10-15 17:34:48 Yeah, I'd expect that stuff to be written to be "rabidly portable." 2025-10-15 17:35:11 That is, that would be the highest priority, before all else. 2025-10-15 17:35:31 And that seems appropriate, given that it's not really meant to be anything other than a bootstrap. 2025-10-15 17:38:19 I think it'll be a little better if I switch the disk code to use BlockIO instead of DiskIO and fix some alignment stuff 2025-10-15 18:14:57 Using UEFI's BlockIO is a little faster. Startup is slow because of this (the default startup reads through a lot of blocks), but it's not too bad once it's fully loaded 2025-10-15 18:19:14 That's a shame - I was hoping that one payoff of tossing the OS would be a faster startup. I think the time it takes modern computers to start is practically criminal. 2025-10-15 18:19:43 No real excuse for it, given how much faster the processors are compared to the old days. 2025-10-15 18:55:48 There's probably more I can do on the performance. I've really only just started on this (my prior os dev work was all 16 & 32 bit) 2025-10-15 18:56:51 Using BlockIO, it's very similar in startup time to the polling i/o ata driver I had with ilo-x86-native 2025-10-15 19:01:47 Are you sure it's BlockIO? I also use BlockIO for Dusk's EFI port (both amd64 and i386) and use it in a very dumb one-at-a-time manner and boot is pretty much instant, even though I need to go through a few dozens blocks. 2025-10-15 19:11:03 yes. The DiskIO code was considerably slower 2025-10-15 19:14:41 I'm going to see if caching blocks in RAM during startup will help 2025-10-15 19:15:24 (my startup code reads through the blocks a few times, loading different things, which doesn't help) 2025-10-15 20:07:32 I figure with all the RAM I have on notebooks these days (the one I have right now has 32 GB), most of what I want to do won't need much disk back and forth. Just pull stuff in once and use it in RAM for the most part. 2025-10-15 20:07:52 32 GB is... a lot of storage. 2025-10-15 20:16:50 Caching my active block set (4,096 blocks, 16MiB of data) in RAM on startup makes it pretty comparable to running under a host OS now. 2025-10-15 21:17:21 https://asciinema.org/a/B8rAODb3f9BKxxrNLUMgPvszJ is a recording of the startup & starting `catalogue`.