[WIP] Pokitto Emulator


#21

Thanks! It has just two dependencies (SDL2 and SDL2_net).
OSX probably won’t like the Makefile, but since there’s nothing special in it you could easily compile using whatever steps are recommended for other SDL2 projects.


#22

this turned out easier then expected

not sure if it will work witout having sdl2 and sdl2_net installed
(edit: it wants both libs installed in a specific location /usr/local/lib/libSDL2-2.0.0.dylib not sure how to overide that)

(macOS build)
PokittoEmu (470.5 KB)

current solution: i wrote a terrible shell script to compile and install the sdl libraries on the system
SDL2INSTALL.sh (419 Bytes)
run this in the terminal sudo sh ./SDL2INSTALL.sh this program will take a while to download and compile everything so be patient
if thats installed you can actualy compile the emulator with the current Makefile


Simple Mac Development Environment
#23

Is there an official compatibility list for the emulator? I know the game I’m working on doesn’t work correctly (not sure it that’s my own fault or not) and I have tested Sensitive, that wont even boot.


#24

Great! :smiley:

If this is a problem, maybe we could try linking to the libs staticly. Doing so shouldn’t be a problem here.

There’s a list of stuff I haven’t implemented yet in the first post. Anything that uses one of those features won’t work, of course. Since I “borrowed” the VBA core I’m still discovering bugs in that. The fastest way to find out what’s broken and fix it is by looking at bin+elf files that don’t behave as they should.

Now with GDB support it’s easy to step through the code and see where it goes wrong.

I think the hardware debugger arrived today (still have to pick it up), that’ll make it so much easier to find bugs by comparing the emulator to the real thing. Thanks again, @jonne! :smiley:


#25

Note: there is a SWD debug connector which you can solder, but: you can easily connect the debugger with a few wires directly to the pex.

This is how (thru the PEX) I program all Pokittos now.

https://talk.pokitto.com/uploads/default/original/2X/7/7fc7f587e0e66618b51c18e10bdbbdae990bf270.jpg


#26

staticly linking sdl seems to be its own can of worms i personaly dont want to deal with.
the shell script should help allot for the moment and might be better for people who build the latest emulator

could probebly port that script to linux aswell for ease of use or modify it to be added to the project


#27

First of all great job @FManga. Compile to bin and debug the result in a single ide will really speed up the develop.

I’m still using an old version of the library and when I run this bin in your emulator the result is too fast
hello.bin (64.7 KB)
On Pokitto the result is just fine. I’ve setFrameRate(30);


#28

This sounds better. I’d probably mess up the soldering. :laughing:

Alright, then. Since the emulator is meant to be used by programmers, a shell script shouldn’t scare anyone away.

I think I have to make SDL wait for vsync then adjust the amount of CPU cycles to emulate per-frame. I tried to do this earlier but SDL broke and I didn’t want to spend too much time figuring out how to get it to work.


#29

I’m trying to get the source to compile on Windows.
I’ve had to change a lot of the existing settings, e.g. removing SDL2.dll from the linker settings (those are for .lib files, not .dlls).

I’ve also made some pull requests to fix some of the issues.
(I’m presuming that either your make system or Linux is trying to automatically include the C headers if they aren’t already included.)

Currently I’m trying to deal with an ‘undefined reference to SDLNet_TCP_Send’ issue.

I’m fortunate because I roughly know my way around the project settings, but what I’m having to do to get it running would be far too much to expect of quite a lot of people here.

If I succeed in getting this working then I’d either like to look into organising a .cbp that works on both Linux and Windows or at least donating a .cbp that works on Windows (relative paths).


#30

I think I forgot to commit the cbp after I added SDL2_net. EDIT: fixed it.

Since I don’t use Code::blocks I don’t know my way around the settings and did couldn’t set the project up in a way that would work smoothly for others.
When I made the Windows build it didn’t complain about printf/rand. :thinking:

On Linux I use just the Makefile and emacs.


#31

I’m still getting problems.
It might be something else causing the issues.
As far as I’m aware the compiler is finding the lib files but for some reason it’s not working.

I’m wondering if GCC doesn’t like the format of the libs.
I grabbed the devel ones for VC because that’s what I used with Visual Studio.
I couldn’t see any other ones for Windows though, and the Linux ones are all .a so I’d be surprised if those worked.

If your Windows build didn’t complain about printf or rand then you must have some extra setup involved because those shouldn’t be present without the appropriate include directives which are certainly missing from master.

I don’t use it regularly either, but a lot of compilers have a similar group of settings.

In my case I’m putting the include and lib directories directly in the project and using relative paths in place of your C:/ paths.

I also have to replace SDL2.dll with SDL2 or I get:

||=== Build: Debug in Emu (compiler: GNU GCC Compiler) ===|
ld.exe||cannot find -lSDL2.dll|
||error: ld returned 1 exit status|
||=== Build failed: 2 error(s), 0 warning(s) (0 minute(s), 1 second(s)) ===|

Despite it being in the same path as SDL2.lib.

The linker handles static library (.lib) files, dynamic libraries (.dlls) aren’t linked until runtime when the OS loads them.


Out of interest, which Code::Blocks version are you running?
I’m on 16.01.


#32

17.12 with the built-in mingw here.

Since the SDL site provides separate libs for VC and GCC I assumed they’re incompatible somehow.


#33

So you’ve been using the .a files in your compiles?

If all else fails I think I’ll either try udating Code::Blocks or just switch to Visual Studio since I know for definite how to get Visual Studio running SDL2.


#34

I think so… I can check in the morning. Aren’t those what GCC uses regardless of OS? I have a vague memory of .lib being a VC thing, but the last time I used that was about a decade ago.


#35

I always assumed GCC used .lib for Windows and .a for Linux.
I tried both and I get the same error from both, so I’m at a loss as to why.

I opened both up in notepad++ and they both have an entry for SDLNet_TCP_Send, so it looks like there’s something else going on.

Is SDLNet even necessary? I’m not sure what GDB is supposed to be doing, but other than sending error reports I can’t think of a reason why you’d need to use the internet in a Pokitto emulator.


#36

The emulator implements a GDB server. It doesn’t use the internet, just inter-process communication. For debugging, IDEs implement a GDB client that connects to the server. The GDB server is the software equivalent of a J-Link.

When you add a breakpoint to your code (F5 in Code::Blocks) this is passed through the GDB client (in this case arm-none-eabi-gdb or gdb-multiarch) then over the local network to the emulator so it knows that it needs to stop there. The IDE can then query/change the value of variables, make changes to the code itself, resume execution or run one line/opcode at a time…

… in theory, at least. I haven’t been able to get Code::Blocks to enable debugging yet, and it looks like PlatformIO charges money for that (though I think VSCode can do with its C++ plugin). I’ve been using GDB directly in the command-line so far.


#37

Using TCP and the local network for that seems a bit overkill.

I would have thought it could be achieved with just stdin and stdout.
And if a network connection was really needed, an intermediary program that just redirects stdin and stdout over a network ought to be able to do the job.

E.g.

debug-server 127.0.0.1:1234
pokitto-emulator | debug-client 127.0.0.1:1234

Where debug-server spawns a new process that must later be killed manually.


#38

No, it’s very necessary. GDB is used in many different configurations, with lot’s of different kind of emulators and hardware targets. Making a TCP server is a very neat way of creating an implementation-independent interface, that does not depend on the actual hardware on which its running on. Furthermore, it’s also used in production settings where multiple instances of JTAG emulators can actually be used for testing and programming over the ethernet.


#39

@Pharap : when I build stuff using SDL2 on Code::Blocks on Windows, I have the following:

##Linker settings

##Search directories, Compiler

#Search directories, Linker

Under the project directory, I have SDL2 set up as follows:

##SDL2 Root

##SDL2/bin

##SDL2/include/SDL

##SDL2/lib


#40

Furthermore, most of the TCP stack is skipped entirely when the client and host are on the same machine. This form of communication has to be optimized since it’s quite common. On *nix systems, applications use it as a fallback to talk to X11, for example.

One thing I’ll have to do eventually is to listen only for connections from localhost so the Windows firewall doesn’t nag at the user. :stuck_out_tongue: