[WIP] Pokitto Emulator


#141

I Am agree, it’s my personal choice in non domestic environment.
I’m using Chrome at home only for the great integration with Google services.


#142

That’s annoying.

Really though, GCC should be giving an error.
Are you using the weird GNU++ setting instead of C++ by mistake?

It’s probably worth finding out why it isn’t giving an error in some cases,
because that implies there might be other valid errors that it’s hiding.


#143

I’d call it more than annoying. I don’t know how they can get away with it if MS got sued for simply including IE with Windows at one point.

I’m using -std=c++17. Not sure why 17 specifically, I think I was planning on looking at the new features and never actually got to it. :stuck_out_tongue:


#144

At some point people stopped caring.
The ‘dodgy practices’ of yesteryear are the modern ‘everybody’s doing it’.

I’d like to use 17 more often, but it’s hard enough to drag everyone into 2011, let alone 2017 :P

That doesn’t explain why the error wasn’t turning up though.
Maybe there’s some other flag preventing it?


#145

There aren’t any others, other than the usual -I..., -O3, and -l.
I’m guessing it’s the outdated GCC (7.3.0) that ubuntu packs.


#146

By the way, here’s why the error is a good thing:

A board of inquiry investigated the causes of the explosion and in two weeks issued a report. It turned out that the cause of the failure was a software error in the inertial reference system. Specifically a 64 bit floating point number relating to the horizontal velocity of the rocket with respect to the platform was converted to a 16 bit signed integer. The number was larger than 32,767, the largest integer storeable in a 16 bit signed integer, and thus the conversion failed.

A.k.a. the Ariane disaster. Be careful with conversions, else your rocket could explode :P

According to the changelog:

The C++ front end has experimental support for all of the current C++17 draft with the -std=c++1z or -std=gnu++1z flags, including if constexpr, class template argument deduction, auto template parameters, and structured bindings. For a full list of new features, see the C++ status page.

So perhaps you’re trying to use -std=c++17 in a version that doesn’t support it,
which is causing it to fall back to -std=gnu++11?


#147

I think I’d get an error if GCC didn’t support std=c++17, but I’ll try switching to 14 or 11 to see what happens. :thinking:


#148

I have one person reporting an issue in another place. They tried to follow my how-to and somehow the emulator crashes. Quote:

…/PokittoEmu/BUILD/PokittoEmu BUILD/firmware.bin
Segmentation fault (core dumped)

Same thing with 2048.bin or pokitto-puzzles firmware.bin

(gdb) where
#0 0x00007ffff7165337 in std::locale::~locale() () from /lib64/libstdc++.so.6
#1 0x00007ffff71b8dba in std::basic_ifstream<char, std::char_traits<char> >::~basic_ifstream() () from /lib64/libstdc++.so.6
#2 0x000000000040535b in loadBin(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) [clone .cold.3] ()
#3 0x0000000000000000 in ?? ()

EDIT: Weird. I hacked the PokittoEmu loadBin function to use FILE* functions instead of ifstream. It works now. Wonder why ifstream fails?

I know you’ll probably need to know the details, I’ve told the person to come join us here, so let’s see :slight_smile:

Anyway, the interesting part is that changing ifstream to the other file API makes it work.

I tested the latest code from the repo and no crashes for me.


#149

I’m going to go out on a limb and say it’s probably a bug in the specific implementation of std::locale::~locale().

A crash coming from a destructor is a bad sign.
That usually implies that it’s trying to dispose of a resource that’s already been disposed of.
Most of the time you get a segfault from dereferencing a pointer that’s either nullptr or not pointing to a valid object.

(Segfault’s a bad name really, I think it ought to be called a RAM access violation.)


#150

I think so, I’m thinking he might have fiddled with the libraries and have a bad installation or using headers for the wrong version or something. We probably won’t know without more details about the OS etc.


#151

Would also be good to know exactly which version of GCC he’s using. :thinking:


#152

It’s caused by -O3. I’ll see about filling a bug with Fedora.

All I know for now. Maybe it’s not worth hunting the bug until further details.


#153

SD card is not supported yet?

For my text editor I am trying to access SD, and disk_initialize() hangs the emulator, but not Pokitto.

EDIT:

I dunno if I’m using it correctly, should I rather use FileIO? It’s weird, in master branch there is only a simulator version of this lib, while in other branches there is also a HW version. Is it WIP?


#154

SD card support is still a bit rough. To make it work you need an SD card image.
Don’t make an image that is too big, the entire file is loaded into RAM so make sure to allocate just what you need, not 128gb.

Once you have a formatted image, run the emulator like this:
PokittoEmu game.bin -I card.img

With this you should be able to read from the SD. Support for writing has an issue I’m still working on.


#155

Awesome, thank you very much :slight_smile:


#156

Hi,
I’m quite sure it has been already asked so be patient.
I’d like to know if can be possibile to attach a debugger to Pokitto Emulator from VS Code (platformio) or Embitz from windows.
I see PokittoEmu support GDB debugging but I don’t know what is need to complete the setup.

Ideally I’d like to write software in VS Code, then (pushing a shortcut) build and deploy to PokittoEmu, attaching source code to allow breakpoints, step by step execution and watching variables. Is this possibile?

Thanks.


#157

It’s possible, though it still needs a bit of polish and I haven’t tested that exact setup recently.
If I remember correctly:

  • install the Cortex plugin for VSCode
  • configure the plugin to connect to port 1234.
  • start the emulator with the -g flag. You’ll see a blank screen as the emulator waits for GDB to connect.
  • start the debugger in VSCode

I think we’d need to make our own VSCode plugin if we want to have a quicker/simpler deploy process. :thinking:


#158

I’ll love it.

Should I start the emulator with the compiled bin? Or will it be flashed by the debugger?


#159

With the compiled bin… letting the debugger flash it was problematic, I think.


#160

But really cool, isn’t it?