<eintopf>
oh well, they write that this machine can run PSX emulators. Yea maybe run, but it's more a diashow then
<wpwrak>
i "know" it in the sense that i know what it is, yes
<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)
<eintopf>
wow
<eintopf>
much larger
<eintopf>
then better gaming on ben nanonote :-)
<wpwrak>
yeah :) alas, the pyra will be the same size
<wpwrak>
but they're cramming some more features into it
<eintopf>
yea, hdmi out
<eintopf>
when I was young, I always want to have some of the gamepark holdings handhelds, because it runs linux.
<eintopf>
so now there are many which runs linux and is mostly open hardware
<pcercuei>
have a look at the gcw zero
<pcercuei>
not really a ben alternative though
<pcercuei>
(no keyboard)
atommann has quit [Remote host closed the connection]
xiangfu has quit [Ping timeout: 246 seconds]
fengling has quit [Ping timeout: 248 seconds]
xiangfu has joined #qi-hardware
valhalla_ has joined #qi-hardware
valhalla has quit [Ping timeout: 264 seconds]
xiangfu has quit [Remote host closed the connection]
fengling has joined #qi-hardware
sulky has joined #qi-hardware
atommann has joined #qi-hardware
valhalla_ is now known as valhalla
atommann has quit [Ping timeout: 256 seconds]
dandon has quit [Ping timeout: 252 seconds]
dandon has joined #qi-hardware
dandon_ has joined #qi-hardware
dandon has quit [Ping timeout: 246 seconds]
dandon_ is now known as dandon
<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)
<eintopf>
just because some missing LCD cables?
<eintopf>
maybe I could also play some games with neo900 :-)
<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.
<paul_boddie>
Even though the handlers are installed in the right locations.
<paul_boddie>
Which I checked yesterday, as my loyal audience may remember.
<paul_boddie>
I'm suspecting that the CPU wants to load the ErrorEPC location and jump to it.
<paul_boddie>
Oh well, I guess it's all a mystery. Somehow Rockbox and Linux enable interrupts but I can't figure it out. :-(
<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.
sulky has quit [Ping timeout: 265 seconds]
sulky has joined #qi-hardware
<DocScrutinizer05>
nah, your testbed is too complex
<paul_boddie>
Mine? Yes, probably. Being able to watch the CPU directly would be useful.
<DocScrutinizer05>
you probably got 5 bugs in it and each single one would break stuff
<paul_boddie>
Probably, yes. It's infuriating: I can run programs without interrupts just fine.
<paul_boddie>
I can even see interrupts pending but not serviced because of the status register state.
<DocScrutinizer05>
start with something absolutely simple: an empty IRQ routine that simply returns. Then see if you can enable IRQs without stuff hanging
<paul_boddie>
I did that. A plain exception handler that is just "return from exception".
<paul_boddie>
Now you're going to ask me if it returned. ;-)
<DocScrutinizer05>
I'm going to ask you if it got called
<DocScrutinizer05>
I gather jz47xx has no embedded trace macrocell?
<paul_boddie>
Well, it is possible because my "foreground" program didn't continue after enabling exceptions/interrupts.
<paul_boddie>
But that could mean that the CPU jumped into the unknown.
<DocScrutinizer05>
it is also possible that turingknowswhat got called instead
<DocScrutinizer05>
either on invokation of IRQ handler or when returning from it
<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.
<DocScrutinizer05>
so next step: have some decent tested debug code in your IRQ handler that tells you it got called
<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.
<DocScrutinizer05>
when you know it gets called, try to find out about what it does on exit/return
<DocScrutinizer05>
examining instructions is useless since you don't know if the CPU jumps to them to start with
<paul_boddie>
Well, it rules out them being wrong, at least. ;-)
<paul_boddie>
But I am intrigued to know what the "bootstrap" handlers actually do.
<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
<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
<paul_boddie>
MIPS jumps to dedicated regions upon exception/interrupt. Depending on who you ask, having a table wasn't RISC enough.
<paul_boddie>
Can't remember where I read that, but it is the usual RISC-measuring exercise.
<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.
<DocScrutinizer05>
anyway already setting up the IRQ so it *invokes* your handler is quite intricate
<DocScrutinizer05>
examining code bytes at some (arbitrary) addr doesn't help much
<DocScrutinizer05>
the CPU usually doesn't _stop_ execution, it just continues fetching opcodes and executing them. The question is *where from*
<paul_boddie>
Well, it looks as if it fetches them from a particular address upon reset.
<paul_boddie>
Well, thanks for the hints! May give this a rest, though.