[J-core] Initial emulator source available.
cr88192 at gmail.com
Thu Sep 15 18:43:15 EDT 2016
On 9/15/2016 4:36 PM, Rob Landley wrote:
> On 09/15/2016 04:03 AM, BGB wrote:
>> So, put up what I have thus far here:
> You have generated binaries checked into the repository. (Could you at
> least put them in a subdirectory?)
prebuilt binaries are possibly useful as they may potentially save
needing to recompile them (having the project in a state where
presumably it works on the dev's machine).
normally binaries are seen as a nicety, given it isn't usually a given
that other people can get stuff to recompile from source, and might just
want the convenience of having it come prebuilt (and otherwise one gets
a lot of "WTF? Where's the EXE?!").
I do have ".gitignore" set to omit the piles of crap Visual Studio likes
to put in the directories.
> The top level readme doesn't say what to do, there's no readme in the
> source dir, there's no "make help" target, there's a build.sh that looks
> like it builds a test file and doesn't have the executable bit set...
the project is still new and small enough that I didn't feel it really
needed a Makefile.
had considered writing a Makefile for it, but hadn't done so yet.
but, yeah, could use a readme, this is an oversight...
the binaries are marked executable on my end, but only "btesh2.elf"
needs to be executable (the others are for SH-2 or SH-4, and so don't
need to be executable). it may be stale though, as I was mostly working
on the Windows version ("btesh2.exe"), so may need to be rebuilt (check,
may also need to disable character echo in the Linux version).
FWIW: on my end, everything is marked executable (due to it being
located on an NTFS drive), but GIT may not necessarily preserve this.
so, yeah, probably run "build.sh" and do a "chmod +x btesh2.elf" or
here is an example command-line:
./btesh2.elf testkern_sh4.elf -sh4
which, with any luck, should give a basic prompt. this prompt is running
inside the SH-4 environment (alternatively, it might not do anything, or
give a disassembly and register dump).
if nothing is given on the command-line, it tries to boot up "vmlinux",
which still doesn't work.
the testkern directory has "tk_build.sh", which builds the "testkern"
binary, and "tk_build_sh4.sh" which builds the SH-4 version, these
assume a cross-compiler toolchain with binaries visible in
"/opt/cross/bin", so may need tweaking if the cross compilers are
elsewhere. generally these are run from the testkern directory.
> Not quite sure where to start. Am I missing something obvious?
build.sh should cause the emulator to compile. it is built from a single
source-file, which includes the other files it needs (it is a "unity
most target-specific features are controlled internally using #ifdef's.
the emulator is pretty small and self-contained, so there shouldn't
really be any external dependencies needed (other than needing
cross-compilers to build the SH parts, and stuff like libc and libm and
More information about the J-core