| 00:04.53 | *** join/#qi-hardware FDCX_ (~fdcx@ceata/consiliu/FDCX) |
| 01:48.32 | *** join/#qi-hardware archang (~archang@111.198.29.54) |
| 02:22.07 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 02:27.03 | *** join/#qi-hardware fengling (~fengling@2002:6fc6:1d35:0:ac58:890e:4104:624b) |
| 03:39.17 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 03:46.37 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 03:49.36 | *** join/#qi-hardware sloantothebone_ (~sloantoth@99-198-2-75.cust.wildblue.net) |
| 03:49.51 | sloantothebone_ | Where do I get a ben nanonote? |
| 04:36.27 | *** join/#qi-hardware fengling (~fengling@2002:6fc6:1d35:0:70b3:b4f0:1bb0:2e7e) |
| 05:30.29 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 06:02.44 | *** join/#qi-hardware atommann (~atommann@63-246-135-194.static.sagonet.net) |
| 06:05.30 | *** join/#qi-hardware archang (~archang@111.198.29.53) |
| 06:31.21 | sloantothebone_ | Hi |
| 06:31.28 | sloantothebone_ | Anybody alive? |
| 06:32.35 | sloantothebone_ | k |
| 06:43.06 | *** join/#qi-hardware archang (~archang@111.198.29.53) |
| 07:12.12 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.54) |
| 07:17.51 | *** join/#qi-hardware archang (~archang@111.198.29.53) |
| 07:30.40 | *** join/#qi-hardware fengling (~fengling@2002:6fc6:1d35:0:d122:4b25:5d01:6ab0) |
| 07:44.59 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 07:46.11 | *** join/#qi-hardware fengling (~fengling@2002:6fc6:1d35:0:5851:3c8a:68c1:84da) |
| 08:02.30 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 08:22.42 | *** join/#qi-hardware fengling (~fengling@2002:6fc6:1d35:0:fd7e:ec61:4613:5fd3) |
| 08:34.21 | wpwrak | (ben) tricky. there are no new ones but maybe there's some 2nd hand to be had. maybe ask on the list if someone wants to sell theirs |
| 08:37.13 | eintopf | wpwrak: do you know the pandora? (not the box from the myth, the I suppose was designed to be a gaming console) |
| 08:37.48 | eintopf | I think it's a little bit bigger than ben, but maybe with some new hardware stuff (?runs little bit faster?) |
| 08:38.29 | eintopf | https://www.dragonbox.de/de/189-pandora-1ghz-megapack-consoles.html |
| 08:38.45 | eintopf | but _maybe_ not open hardware :-) |
| 08:40.04 | eintopf | oh well, they write that this machine can run PSX emulators. Yea maybe run, but it's more a diashow then |
| 08:43.09 | wpwrak | i "know" it in the sense that i know what it is, yes |
| 08:45.58 | wpwrak | could be a ben alternative, yes. not sure if anyone has used it as such. it's considerably larger, though (140.3 x 83.5 x 29.3 mm = 343 ccm vs. 99 x 75 x 17.5 = 130 ccm) |
| 08:48.53 | eintopf | wow |
| 08:48.55 | eintopf | much larger |
| 08:51.15 | eintopf | then better gaming on ben nanonote :-) |
| 08:52.44 | wpwrak | yeah :) alas, the pyra will be the same size |
| 08:53.22 | wpwrak | but they're cramming some more features into it |
| 08:54.07 | eintopf | yea, hdmi out |
| 08:58.14 | eintopf | when I was young, I always want to have some of the gamepark holdings handhelds, because it runs linux. |
| 08:58.35 | eintopf | so now there are many which runs linux and is mostly open hardware |
| 09:02.15 | pcercuei | have a look at the gcw zero |
| 09:02.49 | pcercuei | not really a ben alternative though |
| 09:02.57 | pcercuei | (no keyboard) |
| 11:03.27 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 11:15.43 | *** join/#qi-hardware valhalla_ (~valhalla@88-149-235-148.v4.ngi.it) |
| 11:31.00 | *** join/#qi-hardware fengling (~fengling@2002:6fc6:1d35:0:fd7e:ec61:4613:5fd3) |
| 11:33.50 | *** join/#qi-hardware sulky (~sulky@192.71.247.71) |
| 11:45.33 | *** join/#qi-hardware atommann (~atommann@222.248.66.165) |
| 12:52.58 | *** join/#qi-hardware dandon (~dandon@88.151.72.156) |
| 13:01.02 | *** join/#qi-hardware dandon_ (~dandon@88.151.75.173) |
| 13:15.12 | DocScrutinizer05 | eintopf: pandoras also are not available any longer (though a few will become available shortly since they produced the needed LCD cables for some existing devices with probably broken cables) |
| 13:16.01 | eintopf | just because some missing LCD cables? |
| 13:16.20 | eintopf | maybe I could also play some games with neo900 :-) |
| 13:56.06 | DocScrutinizer05 | sure |
| 14:14.28 | *** join/#qi-hardware paul_boddie (~paul_bodd@cm-84.215.150.4.getinternet.no) |
| 14:46.22 | DocScrutinizer05 | Finally! genuine snakeoil!! \o/ http://www.amazon.de/125ml-Natural-Schlangenöl-Haarwuchs-Haarausfall/dp/B00AFFM1TS |
| 15:15.03 | *** join/#qi-hardware sb0 (~lekernel@x55b4384b.dyn.telefonica.de) |
| 16:36.06 | sloantothebone_ | Hi |
| 16:38.37 | paul_boddie | Hello! |
| 16:39.35 | paul_boddie | On the case of the missing jz4740 interrupts, I can enable them, they are pending (I can see #2 occur), but I still cannot clear ERL without a hang. |
| 16:40.16 | paul_boddie | Even though the handlers are installed in the right locations. |
| 16:40.34 | paul_boddie | Which I checked yesterday, as my loyal audience may remember. |
| 16:41.57 | paul_boddie | I'm suspecting that the CPU wants to load the ErrorEPC location and jump to it. |
| 16:44.45 | paul_boddie | sloantothebone_: I think IDA Systems were the last ones to have the NanoNote: http://www.idasystems.net/products/nanonote |
| 16:44.55 | paul_boddie | Pulster sold out eventually. |
| 17:02.07 | sloantothebone_ | Oh |
| 17:07.04 | *** join/#qi-hardware pcercuei (~pcercuei@95.91.238.68) |
| 17:31.33 | sloantothebone_ | Hi |
| 17:42.33 | *** join/#qi-hardware sb0 (~lekernel@x55b4384b.dyn.telefonica.de) |
| 18:14.46 | *** join/#qi-hardware sb0 (~lekernel@x55b4384b.dyn.telefonica.de) |
| 18:20.40 | *** join/#qi-hardware wej (j@gateway/vpn/mullvad/x-ytgymkatbbpmcobe) |
| 18:28.09 | *** join/#qi-hardware FDCX_ (~fdcx@ceata/consiliu/FDCX) |
| 18:44.28 | *** join/#qi-hardware sb0 (~lekernel@x55b4384b.dyn.telefonica.de) |
| 19:14.50 | *** join/#qi-hardware sb0 (~lekernel@x55b4384b.dyn.telefonica.de) |
| 19:30.59 | *** join/#qi-hardware zrafa (~rafa@170.210.83.36) |
| 19:45.06 | *** join/#qi-hardware sb0 (~lekernel@x55b4384b.dyn.telefonica.de) |
| 19:59.41 | *** join/#qi-hardware zrafa (~rafa@170.210.83.36) |
| 20:11.13 | *** join/#qi-hardware zrafa (~rafa@170.210.83.36) |
| 20:15.36 | *** join/#qi-hardware sb0 (~lekernel@x55b4384b.dyn.telefonica.de) |
| 20:45.23 | *** join/#qi-hardware sb0 (~lekernel@x55b4384b.dyn.telefonica.de) |
| 21:27.46 | *** join/#qi-hardware pcercuei (~pcercuei@95.91.238.68) |
| 21:54.00 | paul_boddie | Oh well, I guess it's all a mystery. Somehow Rockbox and Linux enable interrupts but I can't figure it out. :-( |
| 21:55.43 | paul_boddie | Quite how the CI20 bare metal guy gets interrupts working so easily is a mystery, too. Maybe the jz4780 is more sane or something. |
| 22:04.34 | *** join/#qi-hardware sulky (~sulky@192.71.247.71) |
| 22:18.16 | DocScrutinizer05 | nah, your testbed is too complex |
| 22:18.46 | paul_boddie | Mine? Yes, probably. Being able to watch the CPU directly would be useful. |
| 22:18.49 | DocScrutinizer05 | you probably got 5 bugs in it and each single one would break stuff |
| 22:19.18 | paul_boddie | Probably, yes. It's infuriating: I can run programs without interrupts just fine. |
| 22:19.44 | paul_boddie | I can even see interrupts pending but not serviced because of the status register state. |
| 22:20.16 | DocScrutinizer05 | start with something absolutely simple: an empty IRQ routine that simply returns. Then see if you can enable IRQs without stuff hanging |
| 22:20.52 | paul_boddie | I did that. A plain exception handler that is just "return from exception". |
| 22:21.04 | paul_boddie | Now you're going to ask me if it returned. ;-) |
| 22:21.24 | DocScrutinizer05 | I'm going to ask you if it got called |
| 22:26.27 | DocScrutinizer05 | I gather jz47xx has no embedded trace macrocell? |
| 22:26.28 | paul_boddie | Well, it is possible because my "foreground" program didn't continue after enabling exceptions/interrupts. |
| 22:26.48 | paul_boddie | But that could mean that the CPU jumped into the unknown. |
| 22:27.00 | DocScrutinizer05 | it is also possible that turingknowswhat got called instead |
| 22:27.36 | DocScrutinizer05 | either on invokation of IRQ handler or when returning from it |
| 22:29.01 | paul_boddie | Yes, I suspected the ErrorEPC value to be rogue, which it was, but setting it to a non-rogue value didn't seem to help. |
| 22:29.10 | DocScrutinizer05 | so next step: have some decent tested debug code in your IRQ handler that tells you it got called |
| 22:29.44 | paul_boddie | I examined the instructions at the location the CPU is supposed to visit to invoke the handler, and they were all consistent with my program's disassembly. |
| 22:29.57 | DocScrutinizer05 | when you know it gets called, try to find out about what it does on exit/return |
| 22:30.33 | DocScrutinizer05 | examining instructions is useless since you don't know if the CPU jumps to them to start with |
| 22:31.16 | paul_boddie | Well, it rules out them being wrong, at least. ;-) |
| 22:32.35 | paul_boddie | But I am intrigued to know what the "bootstrap" handlers actually do. |
| 22:32.59 | DocScrutinizer05 | iirc you have a register pointing to a jump table. An IRQ-N jumps to address $table-register + N * 4 byte or sth. On that addr there should be an instruction that looks like JMP @irqhandler |
| 22:33.48 | DocScrutinizer05 | these are already 3 things that could go haywire: the initialization of table-register, and the addr and the instructions at that addr, in jump table |
| 22:34.44 | paul_boddie | MIPS jumps to dedicated regions upon exception/interrupt. Depending on who you ask, having a table wasn't RISC enough. |
| 22:35.03 | paul_boddie | Can't remember where I read that, but it is the usual RISC-measuring exercise. |
| 22:35.45 | paul_boddie | It's possible that the CPU is not even making a decision about jumping to these places at all. That's what worries me. |
| 22:35.50 | DocScrutinizer05 | anyway already setting up the IRQ so it *invokes* your handler is quite intricate |
| 22:36.24 | DocScrutinizer05 | examining code bytes at some (arbitrary) addr doesn't help much |
| 22:38.11 | DocScrutinizer05 | the CPU usually doesn't _stop_ execution, it just continues fetching opcodes and executing them. The question is *where from* |
| 22:39.41 | paul_boddie | Well, it looks as if it fetches them from a particular address upon reset. |
| 23:05.27 | paul_boddie | Well, thanks for the hints! May give this a rest, though. |