[J-core] working on SH-2 emulator.

[BGB]

On 9/5/2016 1:29 AM, BGB wrote:

> but, seems to pass the "testbra" test at least.
> appears to currently be dying in "testmov".
>
> so, will probably go beat on it some more...
>

so, a general status update on this:
   all the boot tests now pass, after a fair bit of debugging.

for some of the tests, it seemed like the solution to PC-relative loads 
in the delay-slot was to recalculate the loads with an offset value of 6 
rather than 4 (can't say for certain that this is correct, but it does 
seem to pass the tests).


then I get this stuff (linebreaks inserted):
$T1e00:00000000;01:abcd0200;02:00000000;03:00000007;04:00000000;05:0000ff8f;06:10000000;
07:00005e7c;08:00000000;09:00001434;0a:00000000;0b:000014a0;0c:0000000c;0d:0000000d;
0e:00000000;0f:0000ff8c;10:00001120;11:00001116;12:00000000;13:00000000;14:ffff8000;
15:00000000;16:00000001;#3b

seems to be GDB related, probably not immediately relevant to my use-case.
that last number seems to vary between runs.

it seems to be in a loop where it reads characters, and I can give 
characters to it.
not sure how to do much with this.
doesn't really seem to be a human-usable interface.


trying to boot the "vmlinux" image still doesn't work, as it still seems 
to go into an infinite loop without it reading any input or producing 
any output (albeit it appears to be going into an infinite loop in a 
different place from before).

possible:
     there are bugs the tests didn't test for (which prevent Linux from 
booting);
     the Linux kernel expects something else in order to start up?...
     there is some mechanism needed to inform the kernel to direct any 
output to the "uartlite" interface?...
         (ex: magic data at magic addresses?...).
         monitoring 0xABCD0000, don't see any activity
             nor does it seem to be trying to access any other address 
ranges
         don't see anything obvious for this in the boot code (like 
stuff for passing kernel parameters/...).

I actually have no idea what the code is doing here.
I guess if I had a linker map for this kernel I could reverse-lookup, 
and try to figure out where in the kernel it is looping. I may need to 
build the kernel from source to get the map though (but don't really 
know the kernel config).

decided to leave out a disassembly and register dump.


but, yeah, at least in a basic sense the emulator seems to be working...