[J-core] Initial emulator source available.
cr88192 at gmail.com
Thu Sep 15 05:03:25 EDT 2016
So, put up what I have thus far here:
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
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:
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
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
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).
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).
More information about the J-core