[J-core] Initial emulator source available.

[BGB]

So, put up what I have thus far here:
     https://github.com/cr88192/bgbtech_shxemu

status:
don't (yet) have Linux working on it (some stuff still incomplete, and 
debugging work is needed, but it is proving difficult trying to track 
down what exactly or where exactly things are going wrong).

I can't say if it will be useful or usable for anyone, thus far still 
working on it.


did put a very minimal CLI on it ("testkern"), may expand with more 
capabilities and add a fancier MM and VFS. hope is that with something 
smaller, maybe bugs will be easier to track down (by being able to more 
readily write and test code to identify the issue and track them down). 
nothing obvious has popped up yet. this is intended to serve a role as a 
simplistic mock-up OS (so, ideally should do basic OS type stuff, like 
have a file-system and probably launch programs). it does a CLI over the 
"uartlite" interface.

I also have an SH-4 variant of this CLI (in addition to SH-2), to allow 
basic tests of memory and FPU features and similar.

basic thinking is that something smaller/simpler may make it more viable 
to try to track down emulator bugs by having smaller/simpler code (but, 
thus far I haven't turned up anything which resolves the issues with Linux).

as noted otherwise, I am more doing this for my own reasons than 
actually having reason to do so, and the code is available under MIT terms.


purely hypothetical thus far, but did start spec'ing up some ideas for a 
possible 64-bit ISA:
https://github.com/cr88192/bgbtech_shxemu/blob/master/sh2emu/2016-09-12_BJ0_64.txt
the design aims to be "reasonably conservative", and tries to minimize 
expanding the opcode space (and aims to be able to be mostly 
backwards-compatible with SH-4 application code).

like with the FPU instructions, things like data width are controlled by 
bits in registers.

some of the policy rules are mostly to try to make things hopefully 
easier to make fast.


some misc observations (regarding the SH-4 mode):
as far as I can tell, C code does not use the XF or XD registers, nor 
FTRV XMTRX or FIPR; these features appear to be fairly specialized to 
tasks like doing a 3D renderer (and the C ABI's seem to leave this stuff 
as "undefined").

I am not sure of the exact handling of the SH-4 address space regarding 
the U0 space.
I am seeing conflicting information as to whether U0 is a single 31-bit 
(2GB) space, or a repeating 29 bit space (its contents repeating after 
512MB).

likewise, it is unclear if P3 corresponds to an alternate view of the 
same 512MB space.
have noted that the memory map seems to limit the maximum contiguous RAM 
to about 320MB.

currently, I have about 192 MB of RAM mapped in.

for the simple CLI / "test kernel", I am currently thinking memory could 
be divided up as:
     16MB (8C000000..8CFFFFFF), kernel space + stack;
     48MB (8D000000..8FFFFFFF), possibly VFS or ramdisk uses;
     128MB (90000000..97FFFFFF), page-allocation and heap.

note, for SH-2 mode, the memory map is different:
     16MB (10000000..10FFFFFF), kernel space + stack;
     48MB (11000000..13FFFFFF), possibly VFS or ramdisk uses;
     64MB (14000000..17FFFFFF), page-allocation and heap.


ramdisk is TBD, current leaning is to use good ol' FAT32.
another possible option for the FS is to emulate an external block 
device (maybe try to figure out the SDcard interface and mock this up), 
because ramdisk makes it too easy (and would be too specific to 
testkern, as opposed to faking a filesystem image on an SDcard)

in SH-4 mode, the MMIO interface is located at 0x0BCD0000, due to the 
'A' getting masked off in address translation (because of 29-bit 
funkiness), vs being at 0xABCD0000 in SH-2 mode (note that in both 
cases, the same address is given by code).

other possibilities:
could do a video framebuffer, and a mock-up of a generic Ethernet 
interface (circular buffers for TX and RX where offsets are updated to 
send and receive packets/frames). not sure what interfaces (if any) 
Linux assumes for these types of hardware profiles (ex: to know what 
hardware to mock up).


any thoughts?...