So what took so much time? Most files have been reviewed and refactored.
Much of it is not even real refactoring, just a style choice, trying to have the same format everywhere.
For instance:
void edgy() { if(a==2) { b=5; c=6; } else c=7; if(c<6) b=8; }
instead of:
void edgy() { if (a==2){ b=5; c=6; } else { c=7; } if(c<6) b=8; }
Notice the subtle differences! It's just a matter of preferences, this changes nothing but all the source files were modified. Fortunately, the IDE can do a lot automatically.
It's not all however. We integrated the 'SSE' parts in the older parts. For example, a new mmu.cpp file with the former SSEMMU.cpp code and parts of emulator.cpp. Things like that... No more specific SSExxxx.cpp files.
File names change, more modules are compiled... All files that were in /code and /include have become translation units or merged with some. Now the only parts that will still directly include code files are the 6301 emu (based on 3rd party code) and draw_c (64bit).
This makes full compilation quite longer, in part that's why it wasn't done before. Partial builds are quicker, unsurprisingly.
Another aspect of refactoring is to undo what I did before, that is using #define ... switches to protect each and every mod in Steem SSE.
The idea was to be able to quickly find regressions. But with the multiplication of such switches, the source was getting unreadable, and there were even bugs caused by bad switches!
Not to mention it was heavy. For instance, making the Debugger 64bit compatible would have taken much more time with those switches (and this also explains why it was delayed) . Many switches have disappeared, some switches are kept when they really isolate a feature or are new, the same way there was USE_PASTI in older Steem, there's still SSE_DISK_CAPS, SSE_UNRAR, SSE_VID_D3D, etc.
A nice way of wasting your time, you will admit.