| 00:20:56 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 00:25:48 | | Quit dconrad (Ping timeout: 268 seconds) |
| 00:26:38 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:06:02 | | Quit b0 (Quit: Ping timeout (120 seconds)) |
| 01:06:18 | | Join b0 [0] (~b0@user/b0) |
| 01:09:23 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 01:13:41 | | Quit dconrad (Ping timeout: 244 seconds) |
| 01:33:28 | | Quit massiveH (Quit: Leaving) |
| 01:57:52 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 02:00 |
| 02:02:13 | | Quit dconrad (Ping timeout: 248 seconds) |
| 02:26:40 | *** | Saving seen data "./dancer.seen" |
| 02:30:35 | | Quit melmothX (Quit: reboot) |
| 02:35:19 | | Join melmothX [0] (~marco@amusewiki/marco) |
| 02:46:20 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 02:51:20 | | Quit dconrad (Ping timeout: 268 seconds) |
| 03:00 |
| 03:24:35 | | Nick jacobk_ is now known as jacobk (~quassel@47-186-65-73.dlls.tx.frontiernet.net) |
| 03:34:48 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 03:38:13 | | Quit othello7 (Ping timeout: 268 seconds) |
| 03:39:08 | | Quit dconrad (Ping timeout: 245 seconds) |
| 03:58:55 | | Quit PheralSparky (Quit: Leaving) |
| 04:00 |
| 04:04:18 | | Quit jacobk (Ping timeout: 248 seconds) |
| 04:04:44 | | Join jacobk [0] (~quassel@47-186-65-73.dlls.tx.frontiernet.net) |
| 04:23:10 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 04:26:44 | *** | Saving seen data "./dancer.seen" |
| 04:28:09 | | Quit dconrad (Ping timeout: 268 seconds) |
| 05:00 |
| 05:11:46 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 05:16:00 | | Quit dconrad (Ping timeout: 252 seconds) |
| 05:50:12 | | Join qf [0] (~qf@user/qf) |
| 06:00 |
| 06:07:08 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 06:11:17 | | Quit dconrad (Ping timeout: 244 seconds) |
| 06:26:48 | *** | Saving seen data "./dancer.seen" |
| 06:55:35 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 07:00 |
| 07:00:10 | | Quit dconrad (Ping timeout: 260 seconds) |
| 07:03:20 | | Quit Bonks (Remote host closed the connection) |
| 07:07:28 | | Quit qf (Ping timeout: 252 seconds) |
| 07:38:50 | | Join qf [0] (~qf@user/qf) |
| 07:48:35 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 07:53:14 | | Quit dconrad (Ping timeout: 272 seconds) |
| 08:00 |
| 08:00:23 | | Join Bonks [0] (~Bonks@97.115.202.186) |
| 08:11:16 | | Quit qf (Ping timeout: 252 seconds) |
| 08:26:51 | *** | Saving seen data "./dancer.seen" |
| 08:37:00 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 08:41:20 | | Quit dconrad (Ping timeout: 252 seconds) |
| 08:58:24 | | Join qf [0] (~qf@user/qf) |
| 09:00 |
| 09:25:57 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 09:30:23 | | Quit dconrad (Ping timeout: 245 seconds) |
| 09:36:55 | | Quit qf (Ping timeout: 244 seconds) |
| 09:41:01 | speachy | OlsoFR: Am I correct in understanding that "Special characters" effectively means "anything not ascii letters+numbers" ? |
| 09:41:19 | speachy | if so that is broken for anything that's not english. |
| 09:42:32 | speachy | IMO it's reasonable for non-english speakers to expect that letters of their alphabet not be considered "special" |
| 10:00 |
| 10:01:09 | | Join qf [0] (~qf@user/qf) |
| 10:06:53 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 10:15:12 | _bilgus_ | I don't think that fits into A-Z though either |
| 10:16:54 | _bilgus_ | I did some toying around with a binary earch over the tag data and its not hot enough to use the speed and it only saves 2-300 bytes of ram over the naive string walker |
| 10:17:42 | _bilgus_ | not worth the complexity, although it wasn't crazy but still I think I can find 300 bytes elsewhere |
| 10:21:59 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 10:23:07 | _bilgus_ | I was thinking get_tag was called each time you do the database but its only on load and tagnav reload, I knew this at one time... well I guess I do again :p |
| 10:26:12 | | Quit dconrad (Ping timeout: 252 seconds) |
| 10:26:54 | *** | Saving seen data "./dancer.seen" |
| 10:28:30 | speachy | oh, the old "A-Z" was definitely afflicted the same way, but when you're browsing "By first letter" I'd expect it to actually respect _all_ letters. :D |
| 10:45:55 | | Nick f_ is now known as funderscore (s-fun@user/f-:38077) |
| 10:45:59 | | Nick funderscore is now known as f_ (s-fun@user/f-:38077) |
| 10:51:08 | speachy | #alllettersmatter |
| 10:51:16 | Ctcp | Ignored 3 channel CTCP requests in 17 days and 21 hours at the last flood |
| 10:51:16 | * | speachy runs away in shame |
| 10:53:02 | _bilgus_ | LMAo |
| 10:53:59 | _bilgus_ | well with what OlsoFr has now tht should be trivial to implement you just need to figure out what you want in there |
| 10:54:48 | _bilgus_ | and how to signal that at I guess boot I Wouldn't bother doing it on lang change just because it'll be large |
| 11:00 |
| 11:06:13 | | Join chris_s [0] (~chris_s@2a09:bac3:2855:1b4b::2b8:10d) |
| 11:22:38 | | Quit Bonks (Remote host closed the connection) |
| 11:22:56 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 11:24:23 | | Quit kugel (Ping timeout: 244 seconds) |
| 11:26:44 | | Join kugel_ [0] (~kugel@ip4d146a3a.dynamic.kabel-deutschland.de) |
| 11:27:03 | | Quit dconrad (Ping timeout: 246 seconds) |
| 12:00 |
| 12:22:22 | | Join Bonks [0] (~Bonks@97.115.202.186) |
| 12:23:58 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 12:24:03 | speachy | I think "letters" should be "everything but numbers and basic punctuation" |
| 12:24:27 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 12:24:33 | speachy | there's no meaningful way to sort or case-fold though. |
| 12:24:44 | speachy | (the utf8proc patch in gerrit brings case folding but not sorting IIRC) |
| 12:26:04 | OlsroFR | special characters means "not numbers and not a-z". Why not include numbers ? Because there's already an entry for them, and I did not want to delete it since it was working fine. Japanese characters are utf and it is clear to me that they can be considered as special since they are non ascii |
| 12:26:58 | *** | Saving seen data "./dancer.seen" |
| 12:27:12 | OlsroFR | if we want to support other alphabets, we will need to pick the alphabet from the language file. Can be done fairly easily if there's interest, I think |
| 12:28:33 | | Quit dconrad (Ping timeout: 268 seconds) |
| 12:30:27 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 12:38:53 | | Quit OlsroFR (Quit: Client closed) |
| 12:40:21 | speachy | no, it's not terribly easy. and it's also routine to have files/medatada from a different language than the one selected |
| 12:42:15 | speachy | the way it was expressed before ("A-Z") was at least implicitly English-only, "first letter" (especially translated into different languages) implies it covers at least the current language, if not others |
| 12:44:37 | speachy | granted there are other problems we have, eg we can only spell out ascii letters+numbers. |
| 12:44:47 | | Quit qf (Ping timeout: 252 seconds) |
| 12:45:11 | speachy | and changing that is not practical given that fixing it would arguably require voicing nearly every utf code point. |
| 12:45:31 | speachy | but I'd at least like to do what we can |
| 12:45:43 | speachy | and get incrementally better where practical |
| 13:00 |
| 13:01:23 | _bilgus_ | I'd argue this is better and english still gets some of the stuff in the special chars menu that previously ended up in numeric |
| 13:01:57 | _bilgus_ | I think thats the bug OlsroFR was reffing the other day |
| 13:02:25 | _bilgus_ | we could just make numeric 'Other' |
| 13:24:59 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 13:29:50 | | Quit dconrad (Ping timeout: 260 seconds) |
| 13:30:20 | speachy | Hmm. I wonder if we should pull spelling clips out of LANG entirely, and move it to standalone on-disk clips. |
| 13:31:30 | speachy | when spelling out things, we can look for .rockbox/lang/clips/<codepoint>_lang.talk for each, and fall back to <codepoint>.talk if not present |
| 13:32:25 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 13:33:25 | OlsroFR | _bilgus_ Before I fixed it, numeric was showing some special characters, but only a small portion of them (just anything that was before "A" in the ascii table https://www.asciitable.com/ ). |
| 13:33:52 | speachy | each language can include a complete set of clips for its alphabet, leaving CJK (and similar ideographic) as the long tail |
| 13:37:46 | | Quit OlsroFR (Quit: Client closed) |
| 13:54:43 | | Join othello8 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 13:56:33 | | Quit othello7 (Ping timeout: 265 seconds) |
| 13:56:33 | | Nick othello8 is now known as othello7 (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 14:00 |
| 14:13:05 | tertu2 | hey, are EROS Ks all HW1? |
| 14:13:15 | | Nick tertu2 is now known as tertu (~tertu@user/tertu) |
| 14:18:17 | tertu | I just tried to do an updated build and run it on my eros k and got a white screen. that being said i had a little patch (different random number generator) |
| 14:18:24 | tertu | but i think that probably shouldn't matter |
| 14:18:45 | tertu | my old build also had the random number generator patch and worked fine (i think it was from october of last year) |
| 14:19:19 | speachy | tertu: As far as we know, the ones branded as "Eros K" are all HW1 |
| 14:19:37 | speachy | you'll need an updated bootloader build for the HW1 targets |
| 14:19:46 | tertu | that's likely what happened then, that was my other thought |
| 14:19:47 | speachy | the wiki page has a link to an installer |
| 14:19:56 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 14:20:16 | speachy | the changes we've made to supoprt the newer hardware targets with a single binary required customizing the bootloaders |
| 14:20:17 | tertu | didn't try it yet though because i need to reboot into linux to build |
| 14:21:25 | | Join rwhoops [0] (~rien333@217-123-19-102.cable.dynamic.v4.ziggo.nl) |
| 14:23:53 | rwhoops | How long is building the initial database supposed to take on a iPod classic, in case I've added a couple of thousand songs? Are we speaking minutes or hours? The thing is, I have a spinning wheel that is just no going away. |
| 14:24:09 | | Quit dconrad (Ping timeout: 252 seconds) |
| 14:24:27 | tertu | iirc i would expect closer to minutes, but i haven't used mine in a while |
| 14:25:18 | speachy | I'd expect closer to minutes than hours, much worse on the original hard drive |
| 14:25:20 | tertu | that being said the reason i'm trying to rebuild rockbox is on my eros it felt like rockbox was constantly doing disk access to the point where it had no time for anything else |
| 14:25:46 | speachy | make sure it's running a recent daily build instead of 3.15, especially if it's been modded with an SSD of some sort. |
| 14:25:48 | rwhoops | minutes is also the impression I get from my searches; must be something weird going on, then. Thanks! |
| 14:26:15 | rwhoops | Yea I'm using a SSD mod and I like to stay on the bleeding edge generally |
| 14:26:16 | | Quit desowin () |
| 14:27:00 | *** | Saving seen data "./dancer.seen" |
| 14:28:05 | | Join desowin [0] (~desowin@rockbox/developer/desowin) |
| 14:28:10 | rwhoops | That being said, any ideas what else the spinner could be indicating? I see it in every menu I'm in |
| 14:32:36 | | Quit desowin (Read error: Connection reset by peer) |
| 14:32:42 | | Join desowin_ [0] (~desowin@rockbox/developer/desowin) |
| 14:35:56 | _bilgus_ | rwhoops, its doing disk access it needs to check the disk I assume you still can browse and stuff |
| 14:36:14 | _bilgus_ | if you want debuggin messages see the db_commit plugin |
| 14:36:46 | _bilgus_ | and or go into the debug menu it should give you an indication of status |
| 14:37:47 | _bilgus_ | Debug menu->View Database Info |
| 14:37:47 | | Quit desowin_ (Read error: Connection reset by peer) |
| 14:38:06 | | Join desowin [0] (~desowin@rockbox/developer/desowin) |
| 14:38:21 | _bilgus_ | and it should have progress % and current track / dir or progress% and ERROR |
| 14:38:53 | _bilgus_ | it doesn't tell you the error so for that need to run the plugin and see what it spits out |
| 14:41:13 | tertu | also as an aside has anybody talked about an rp2350 port... i'm not asking people to do it and it would also need a newer version of gcc i think so |
| 14:41:15 | tertu | losts of work |
| 14:41:18 | tertu | *lots |
| 14:42:08 | rwhoops | _bilgus_: thanks for the tips! I'll investigate now |
| 14:43:26 | rwhoops | And indeed, I can still browse the database/file system. It just hangs sometimes (which I it didn't do yesterday, when I had far less songs) |
| 14:43:48 | rwhoops | I added a bunch more songs, but not a crazy amount (like 3000 max) |
| 14:44:05 | _bilgus_ | it still has to check ever song in there and the new ones |
| 14:44:12 | _bilgus_ | every |
| 14:44:28 | _bilgus_ | that takes time and then it has to write the new ones too |
| 14:44:38 | _bilgus_ | debug menu should say |
| 14:46:01 | _bilgus_ | and even once it says -1 (ie complete) it still takes a bit to write everything to disk its something like 11 db files |
| 14:46:55 | _bilgus_ | I could truly see that taking some time on a spinning disk moving between separate files and such takes time |
| 14:47:51 | _bilgus_ | and not exactly a powerhouse processor either |
| 14:51:04 | rwhoops | hm it was at -1% when I went into the menu, and now it seems to be (re)building. |
| 14:51:18 | tertu | -1% is "done" right? |
| 14:54:46 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 14:56:42 | rwhoops | hm, it went through all my entires (it says "Total entries: 7200", but "Process:" says 9200), hit the -1% again, and now its doing it again? |
| 14:57:26 | rwhoops | lol its going for the third round now; maybe I should delete the database and let it startover? |
| 14:59:13 | | Quit dconrad (Ping timeout: 248 seconds) |
| 15:00 |
| 15:01:31 | speachy | tertu: The RPi microcontrollers don't have sufficient RAM. |
| 15:11:53 | _bilgus_ | rwhoops, I'd try the commit plugin |
| 15:12:42 | _bilgus_ | apps/db_commit |
| 15:13:14 | _bilgus_ | itll allow you to make a backup and start over |
| 15:14:00 | speachy | about 1/4th the RAM of the lowest-end targets we (barely) support. |
| 15:14:27 | _bilgus_ | and let me tell you 8mb is usable but not great |
| 15:14:40 | tertu | you can attach up to 32MB of ram to it |
| 15:14:58 | speachy | there's plenty of CPU power but.. no onboard audio, USB1 only, etc. |
| 15:15:14 | speachy | ("plenty" == still relatively low end by our current standards) |
| 15:15:16 | _bilgus_ | by the time you do that does it make sense from a $$ perspective though? |
| 15:15:44 | _bilgus_ | rather than just going with a soc that starts out capable? |
| 15:16:12 | _bilgus_ | by all means do what ever scratches your itch. |
| 15:16:54 | tertu | i mean the only thing you could still get is an X1000 right? |
| 15:17:09 | tertu | that rockbox already supports |
| 15:17:22 | _bilgus_ | well the only thing that we already have ported |
| 15:17:23 | speachy | there are plenty of SoCs roughly equivalent to the X1000 sold today |
| 15:17:33 | speachy | (even with on-package RAM!) |
| 15:18:01 | _bilgus_ | what i'm getting at is the same amount of work to make a new port why not aim higher? |
| 15:18:30 | _bilgus_ | unless its to ride on the raspi name but meh |
| 15:18:45 | tertu | i mean if there's something with widely available dev boards sure |
| 15:19:56 | _bilgus_ | everyone seems to see their own yes but that still gets you not too far on a actual carry-able mp3 player |
| 15:19:58 | speachy | it's up to 16MB of PSRAM per bank (max 2 banks) and it's _slow_. |
| 15:20:28 | speachy | PSRAM is what the tangara uses, for example (with an EFR32) |
| 15:20:53 | _bilgus_ | ^I was going to say usually ram off the side has switching timing penalties |
| 15:21:13 | tertu | oh i hadn't heard of that thing (the tangara) |
| 15:21:25 | speachy | it's not too bad for sequential access but random access is awful due to the relatively slow+narrow SPI bus vs even DRAM would be. |
| 15:21:51 | _bilgus_ | more $$ might negate some portion of that |
| 15:22:14 | Xogium | afaik psram is pseudo ram, emulated with a portion of the flash storage ? |
| 15:22:24 | speachy | high-end microcontrollers support DRAM, but by the time you put all that together it makes far more sense to just use an x1000 or one of the allwinner (eg V3s) parts. |
| 15:22:29 | tertu | no, it's "pseudo SRAM", i.e. dram you don't need to refresh |
| 15:22:36 | Xogium | ohh right |
| 15:22:49 | speachy | attached via (usually-quad-)SPI. |
| 15:22:52 | _bilgus_ | like implementing bank switching on top and preloading stuff aggressively but that is prob more trouble than worth |
| 15:23:17 | Xogium | yeah I mean like there are stm32 cus that have ddram, but |
| 15:23:33 | Xogium | it'd be too expensive by then to be worth it |
| 15:23:33 | speachy | yeah, the higher-pinout STM32s support native SDRAM |
| 15:23:38 | tertu | oh yeah the v3s seems decent |
| 15:24:01 | speachy | https://www.shaftnet.org/~pizza/rb-wishlist.txt |
| 15:24:08 | Xogium | it's... Okay, for an allwinner thing |
| 15:24:58 | Xogium | I personally don't trust allwinner after one of their SoC almost caught fire for no reason at all than, it had been running for a while |
| 15:25:15 | Xogium | right on my desk if you please |
| 15:26:07 | _bilgus_ | eh shit happens |
| 15:26:12 | Xogium | indeed |
| 15:27:04 | Xogium | the pcb went so warm it melted the sourrounding plastic case |
| 15:27:12 | Xogium | *surrounding |
| 15:27:25 | speachy | that's impressive for a low-voltage device |
| 15:27:40 | Xogium | yeah, I know right |
| 15:27:56 | Xogium | I have absolutely no clue what happened |
| 15:28:32 | Xogium | it ran fine for a while, and then after some time it seemed to have gone in some form of thermal runaway ? Good thing I hadn't yet gotten a battery fixed on it |
| 15:29:09 | tertu | tbh i didn't realize how much of a problem the qspi psram would have been, my thought was kind of yeah this would be bad but enough of the hot stuff could be in SRAM that it would be OK |
| 15:29:40 | | Quit Bonks (Ping timeout: 240 seconds) |
| 15:29:54 | _bilgus_ | mainly jus for playback |
| 15:30:02 | Xogium | now I'm going to possibly sound like a dummy, but what about XIP ? |
| 15:30:06 | _bilgus_ | you really notice underuns there |
| 15:30:34 | speachy | XIP will work for the main binary but plugins, codecs, etc are designed to operate as overlays |
| 15:30:41 | Xogium | ah, crap |
| 15:30:47 | _bilgus_ | and thats why they had the HW codec players back in the day |
| 15:30:48 | Xogium | there goes my plan |
| 15:30:50 | speachy | it's a solveable problem but... a ton of work. |
| 15:30:51 | tertu | also wouldn't that have the same problems |
| 15:31:02 | tertu | like, it's also qspi memory |
| 15:31:08 | speachy | yeah, all of the ram-constrained devices use HW codecs and very limited SW features. |
| 15:31:19 | speachy | XIP from main onboard flash |
| 15:31:36 | _bilgus_ | I wonder if you could leverage the tiny FPGA deals to do something |
| 15:31:53 | Xogium | and even from qspi, it would be faster in a sense because it wouldn't have to wait to be loaded into the ram |
| 15:32:15 | _bilgus_ | like make 15 different micro decoder for each codec type and load them with their own ram |
| 15:32:53 | speachy | _bilgus_: what was it you said... by all means do whatever scratches your itch.. :D |
| 15:32:56 | tertu | okay that doesn't quite make sense to me, because from what i'm getting the problem with the QSPI PSRAM stuff is that the qspi interface is too slow |
| 15:33:03 | Xogium | am I bored enough to try and see if porting rockbox to something like the stm32f7 dev kit is a fun distraction ? :p |
| 15:33:09 | _bilgus_ | I think ATM its only a few hundred transistors |
| 15:33:35 | speachy | rockbox was ported to one of the STM32-based Zishan DAPs, never saw any sources |
| 15:33:43 | Xogium | aw, no fun |
| 15:33:47 | _bilgus_ | but the number you have to buy has gone down to like 100 or less in the last year or so |
| 15:33:48 | tertu | so now rather than just having to pay that penalty for just reading the encoded data and writing back out |
| 15:34:10 | tertu | you now have to pay that penalty for code too which would make performance way worse? at least this is what i'm gathering |
| 15:34:46 | speachy | tertu: performance (especially random access) is the primary problem. |
| 15:35:01 | _bilgus_ | yeah I doubt I'll be alive long enough to make custom asics to scratch an itch |
| 15:35:16 | tertu | yeah I was just saying that i thought that xip flash would make things worse rather than better |
| 15:35:24 | _bilgus_ | but IDK its getting pretty crazy the limits |
| 15:35:30 | speachy | "Memory is like an orgasm. It's a lot better if you don't have to fake it." −− Seymour Cray |
| 15:35:37 | _bilgus_ | lol |
| 15:35:44 | Xogium | OMFG |
| 15:35:51 | Xogium | XD |
| 15:36:43 | tertu | oh does rockbox have remote debugging support, i've never checked |
| 15:37:29 | _bilgus_ | it has a terminal mode for (some?) devices |
| 15:37:31 | Xogium | well in theory, XIP should be better. Because instead of loading whatever resource from the flash, then passing them to the qspi ram, and loading them in there and *then* executing, what you do is you execute. Straight from the flash. No loading of the code anywhere |
| 15:37:42 | _bilgus_ | never tried it |
| 15:38:12 | speachy | either way XIP means no use of overlays |
| 15:38:20 | Xogium | true enough |
| 15:38:57 | _bilgus_ | logf to serial and usb_serial bu I would argue thats probably not exactly what you mean |
| 15:39:03 | tertu | oh you mean XIp flash that isn't hooked up via QSPI |
| 15:39:11 | Xogium | yes |
| 15:39:30 | Xogium | the internal flash inside a mcu if it has some, is usually lightning fast |
| 15:40:14 | _bilgus_ | doing stuff with flash has its own issues though |
| 15:40:28 | Xogium | also true |
| 15:40:32 | _bilgus_ | mainly lifetime concerns |
| 15:40:47 | Xogium | although if it's only read and not written |
| 15:40:58 | _bilgus_ | sure if you have enough |
| 15:41:31 | _bilgus_ | but also figure we aren't optimized to use readonly |
| 15:42:15 | _bilgus_ | sure its marked static and such but its still in ram and very few constraints on how it actually gets used |
| 15:42:23 | Xogium | still, it was an idea that came into my brain totally at random, after I amused myself following the series on lwn.net about shrinking the linux kernel and working on a tiny userspace, both of which used XIP, to fit on the 2 mbytes of storage of the stm32f7 and to run with only its 512 kb of sram |
| 15:42:49 | _bilgus_ | did they list the time it takes to boot? |
| 15:42:59 | Xogium | unfortunately no, but |
| 15:43:03 | _bilgus_ | BUT |
| 15:43:04 | Xogium | I should record that |
| 15:43:09 | _bilgus_ | big letters lol |
| 15:43:30 | Xogium | because I was shocked, but it actually booted faster than even a raspberry pi or typical linux pc would |
| 15:43:52 | _bilgus_ | but if you rip a raspi down that far it will run circles |
| 15:44:06 | Xogium | I think like, from plugging in the power cable to the login prompt showing up, there was barely 4 seconds, if that |
| 15:45:22 | Xogium | I should use that program again, grabserial or something ? That lets you measure the time between each line on the serial console and the over all time from point a to point b so to speak |
| 15:45:38 | _bilgus_ | or running in arduino and going bare metal |
| 15:45:45 | Xogium | oh boy |
| 15:45:50 | Xogium | more fun |
| 15:46:25 | _bilgus_ | point is that you leave a lot of nice to have on the table but its faster because its direct and to the point no frills |
| 15:46:58 | _bilgus_ | but linux is a generalist |
| 15:47:16 | Xogium | that said yeah bare metal is... Well, nearly instant, I'd guess ? I did toy with a demo program that used the microphones on the board and looped the audio back to the headphone jack, and booting that up took so little time. I mean, I know that sort of mcu is fast, but I guess I did not realize just how fast |
| 15:48:34 | _bilgus_ | whats more surprising to me is how back in the day they did so much with so little but a lot of that is because they HAD to |
| 15:48:45 | Xogium | I know right |
| 15:48:58 | Xogium | still impressive either way |
| 15:50:43 | Xogium | I really do like to toy with embedded systems and things, and messing about with old players like this ipod is reminding me a bit about that too :D |
| 15:51:12 | Xogium | also in other annoying news, the person that was supposed to change my battery won't be coming here... Sooo, I guess I'm kind of stuck |
| 15:52:43 | Xogium | really not easy to even figure out how to open this thing when it's so well shut and put together. I know there are retaining clips sure, but they are impossible to find with your your fingers |
| 15:53:44 | Xogium | so even if I could get it open... I don't feel too confident moving ribbon cables around... And on top of this I'm guessing the battery ribbon surely has a polarity to take into account |
| 15:55:33 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 15:56:38 | speachy | it only goes together one way |
| 15:56:47 | speachy | (and still fit together) |
| 15:57:00 | Xogium | you mean the battery connector is keyed ? |
| 15:58:23 | | Quit ats (Ping timeout: 252 seconds) |
| 15:59:52 | | Quit dconrad (Ping timeout: 252 seconds) |
| 16:00 |
| 16:00:00 | | Quit SammysHP (Quit: *wuff*) |
| 16:00:22 | | Join SammysHP [0] (~SammysHP@faol.sammyshp.de) |
| 16:02:01 | speachy | it's not keyed but if you route it along the wrong side of the case (ie because it's backwards) it has nowhere to go. |
| 16:02:17 | Xogium | ah, that makes sense |
| 16:02:19 | speachy | (permanently attecd ribbon cable) |
| 16:02:38 | Xogium | yeah, I don't like those things much |
| 16:02:40 | speachy | older models used more traditional wires+connector that's keyed |
| 16:03:05 | | Quit chris_s (Quit: Client closed) |
| 16:03:40 | | Join chris_s [0] (~chris_s@2a09:bac2:2a1c:246e::3a1:1d) |
| 16:13:32 | | Join ats [0] (~ats@cartman.offog.org) |
| 16:27:01 | *** | Saving seen data "./dancer.seen" |
| 16:28:34 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 16:33:09 | _bilgus_ | well I managed to get within 80 bytes of my previous best using binary search by splitting the data structures to remove padding and allow me to store symbols in a uint_8 |
| 16:33:21 | | Quit dconrad (Ping timeout: 268 seconds) |
| 16:41:09 | _bilgus_ | and no hoops just a little more runtime processing instead of a whole bunch more sorting strings and such so I like this much better |
| 16:42:31 | _bilgus_ | so thats ~200 another 800 and I can add another feature :p |
| 16:44:14 | _bilgus_ | Running callgrind I did find that most of our wall time is actually processing strings |
| 16:45:14 | _bilgus_ | and not strlen or anything like that its the font conversion parts |
| 16:45:21 | _bilgus_ | well and the actual drawing |
| 16:47:00 | _bilgus_ | quite a bit of time setting up viewports repeatedly too but the problem there is that you don't actually know who will be calling you next so caching is probably minimally valuable |
| 16:51:07 | _bilgus_ | the place where I really spent a lot of time trying to speed up (bringing up entries in Tagnavi) really didn't pan out, bigger cache for writing the control file did make it ever so slightly faster but not enough to justify the bin size taken up by the buffer and the code to use it |
| 16:51:45 | | Join PheralSparky [0] (~S|h|a|w|n@user/shawn/x-4432647) |
| 16:54:43 | | Join qf [0] (~qf@user/qf) |
| 16:55:59 | _bilgus_ | Last week I was toying around with loading the data from the end of the list so you get equal from the back and front ( i tend to scroll up when I'm looking for tracks ) but the issue is that you still have to walk the whole db file to do it which just makes the initial load that much longer |
| 16:56:59 | | Quit chris_s (Quit: Client closed) |
| 17:00 |
| 17:05:53 | | Quit lebellium (Quit: Leaving) |
| 17:12:55 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 17:17:03 | | Quit dconrad (Ping timeout: 245 seconds) |
| 17:18:40 | | Quit jj5 (Quit: Konversation terminated!) |
| 17:19:44 | | Join jj5 [0] (~jj5@100.80.216.139.dynamic.dsl.dv.iprimus.net.au) |
| 17:39:57 | | Quit rwhoops (Ping timeout: 252 seconds) |
| 17:43:31 | user890104 | speaking of rockbox ports, I have a stupid hosted port idea, waiting for the device to arrive in the mail in the coming days |
| 17:57:40 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 18:00 |
| 18:01:51 | | Quit dconrad (Ping timeout: 246 seconds) |
| 18:06:53 | Xogium | oh, what device? :D |
| 18:27:02 | *** | Saving seen data "./dancer.seen" |
| 18:36:29 | user890104 | https://play.date/ |
| 18:42:30 | _bilgus_ | pretty light on details regarding the audio |
| 18:42:46 | _bilgus_ | 16 mb and 170 MHZ will work though |
| 18:43:44 | _bilgus_ | nothing about an sdcard either |
| 18:46:09 | _bilgus_ | maybe the usbc is OTG? |
| 18:46:28 | _bilgus_ | they make some pretty small flash drives now |
| 18:50:13 | user890104 | _bilgus_: I'm going for a hosted port, not native :) |
| 18:50:31 | user890104 | basically https://sdk.play.date/2.6.2/Inside%20Playdate%20with%20C.html#_api_reference |
| 18:51:02 | user890104 | they have a bunch of filters and synth stuff |
| 18:52:06 | user890104 | I still haven't found a way to draw a pre-rendered framebuffer to the display |
| 18:53:02 | user890104 | there's graphics->setPixel() but that's gonna be too slow |
| 18:58:37 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 19:00 |
| 19:02:50 | | Quit dconrad (Ping timeout: 252 seconds) |
| 19:05:47 | _bilgus_ | esp if you want doom |
| 19:06:02 | _bilgus_ | does it actually list a refresh rate on the screen? |
| 19:36:07 | | Quit SammysHP (Quit: *wuff*) |
| 19:36:27 | | Join SammysHP [0] (~SammysHP@faol.sammyshp.de) |
| 19:59:32 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 20:00 |
| 20:03:43 | | Quit dconrad (Ping timeout: 245 seconds) |
| 20:10:40 | | Quit qf (Ping timeout: 252 seconds) |
| 20:27:03 | *** | Saving seen data "./dancer.seen" |
| 20:32:00 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 20:36:15 | | Quit dconrad (Ping timeout: 252 seconds) |
| 21:00 |
| 21:33:05 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 21:37:59 | | Quit dconrad (Ping timeout: 268 seconds) |
| 21:40:19 | | Join Bonks [0] (~Bonks@97.115.202.186) |
| 21:44:58 | | Quit _bilgus_ (Remote host closed the connection) |
| 21:45:47 | | Join _bilgus_ [0] (~bilgus@syn-162-154-213-134.res.spectrum.com) |
| 21:51:39 | | Quit _bilgus_ (Remote host closed the connection) |
| 21:52:55 | | Join _bilgus_ [0] (~bilgus@syn-162-154-213-134.res.spectrum.com) |
| 22:00 |
| 22:04:16 | | Quit _bilgus_ (Remote host closed the connection) |
| 22:06:56 | | Join _bilgus [0] (~bilgus@syn-162-154-213-134.res.spectrum.com) |
| 22:14:19 | | Join massiveH [0] (~massiveH@2600:4040:a982:5400:882e:ad76:bcd4:4805) |
| 22:27:04 | *** | Saving seen data "./dancer.seen" |
| 22:43:36 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 22:48:29 | | Quit dconrad (Ping timeout: 260 seconds) |
| 23:00 |
| 23:00:20 | _bilgus | well that was weird got a data abort on two boots restarted again and now works fine |
| 23:09:03 | | Join paulk-bis [0] (~paulk@2a02-8428-1d63-2401-0081-87ff-fed5-e402.rev.sfr.net) |
| 23:11:01 | | Quit paulk (Ping timeout: 248 seconds) |
| 23:18:52 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 23:23:30 | | Quit dconrad (Ping timeout: 265 seconds) |
icon identifies that the person is a core developer (has commit access).