Steem experiments with Visual C++ 2010 - DrCoolZic Build

[DrCoolZic]

I am looking at the feasibility of adding IPF (from Software Preservation Society) file support in Steem by first looking at the way it is done with Pasti STX files.

Therefore I first need to compile the Steem source using my development environment. I am using Visual Studio 2010 Ultimate and therefore I have tried to compile with this environment.
I have first used the original Steem code that I have got from the Steven Segal site. There were so many problems that I have immediately given up and tried the source 3.3 from Steven.
It is much better but it still does not compile.

As mentioned by Steven in another thread, the fact that the cpp sources are included from 3 “central” files is rather unusual and therefore it is not obvious to know what is compiled and browsing sources from the solution explorer is not really easy

What I had to change in order to compile:
In conditions.h close to line 270+ there is a conditional define of ASMCALL to __cdecl if WIN32 is defined. Later this is used in source like this:

Code: Select all

extern "C" ASMCALL void m68k_trace()

This translate to

Code: Select all

extern "C" __cdecl void m68k_trace()

and this does not make sense ? as it should be either

Code: Select all

extern "C" void __cdecl m68k_trace()
or
extern "C" void m68k_trace()

__cdecl is the default calling convention in C and C++
Therefore I ALWAYS define ASMCALL as nothing.

In mymisc.cpp on line 64 we have
if (n>0) val*=(unsigned long)pow(16,n);
this is an ambiguous call

Code: Select all

1>m:\atari\steem\_source\segalsource\include\mymisc.cpp(65): error C2668: 'pow' : ambiguous call to overloaded function
1>          c:\program files (x86)\microsoft visual studio 10.0\vc\include\math.h(583): could be 'long double pow(long double,int)'
1>          c:\program files (x86)\microsoft visual studio 10.0\vc\include\math.h(535): or       'float pow(float,int)'
1>          c:\program files (x86)\microsoft visual studio 10.0\vc\include\math.h(497): or       'double pow(double,int)'
1>          while trying to match the argument list '(int, int)'

This can easily be fixed with

Code: Select all

if (n>0) val*=(unsigned long)pow(16.0,n);

Having done this modification allow to compile and generate the four object files.
However the link fails!

If I look at the configuration property the linker is specified to use:

Code: Select all

"kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" "dinput.lib" "dxguid.lib" "winmm.lib" "ComCtl32.Lib"

Most of these libraries can be found in:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib
But the following lib are missing: Dinput.lib, dxguid.lib
Google seems to indicate that these libs are coming from DirectX SDK and not from Windows SDK. So I have downloaded the latest SDK from: http://www.microsoft.com/download/en/de ... px?id=6812
and installed it.
The SDK contains the dxguid.lib file but not the dinput.lib? However there is a dinput8.lib is this equivalent ???

I have replaced the dinput.lib with dinput8.lib
Now the linker complains about:

Code: Select all

1>LINK : fatal error LNK1104: cannot open file '..\..\steem\asm\asm_draw_VC.obj'

This seems to come from the fact that it is specified in the solution browser in a directory called “Object files” with 3 files defined but nothing on the real file system?
I am stuck here any help is welcome

Anyone with a working build using Visual Studio 2010 Ultimate ?

[Steven Seagal]

I think you must assemble those asm files using the bat files that may be or not included in the source I uploaded.
Here they are just in case (use NASM):

Code: Select all


nasm -fwin32 -dWIN32 -d_VC_BUILD -oasm_draw_VC.obj -w+macro-params -w+macro-selfref -w+orphan-labels asm_draw.asm


and

nasm -fwin32 -oasm_osd_VC.obj -dWIN32 -d_VC_BUILD -w+macro-params -w+macro-selfref -w+orphan-labels asm_osd_draw.asm



About modularity, I notice it compiles fast on my relatively slow computer, and I won't mess with it at once.
But it certainly doesn't help debugging.
Normally my source can be compiled with VC6 and with BCC5.
If you're very patient, one day I'll implement your system in Steem anyway (but all buggy).

[DrCoolZic]

I have successfully build your version of steem with information you provided on nasm plus with modifications I have indicated above it seems to work.

As I already said I do not like the fact that all the sources are hidden by the includes. Therefore I have started to "un-include" the files.

After several hours of work I have finally splited steem.cpp and main.cpp and I got everything compiling!

But to muy surprise the linker is finding zillions of multiple definitions ?!? and to my surprise I have found that several of the .h file contains function and variable definitions

The define IN_MAIN convert from declaration to definition ??? !!!
Never seen something like that. I will see tomorrow if it makes sense to try to go further or not? For now I am going to bed

Steven would you be interested by a version without the sources included so you can use the IDE normally?
To facilitate work I am thinking of removing some conditional used for port that I do not care like Linux
Would you be interested by a Visual C++ only version ? you can get VC++ 2010 for free from Microsoft

[Steven Seagal]

But to muy surprise the linker is finding zillions of multiple definitions ?!? and to my surprise I have found that several of the .h file contains function and variable definitions

The define IN_MAIN convert from declaration to definition ??? !!!

Yeah, h files contain compilable code and cpp files are included. The behaviour of h files depends on macros like IN_MAIN, IN_EMU. I think the Steem authors should be tried before a C/C++ jury. It's hard to undo. I haven't tried yet.
But apart from that, at least there's almost no assembly. Back when I was looking at improving WinSTon, it was full of assembly. I just don't know that "language". And their code is very readable. Of course, I would have liked more comments as well.

Steven would you be interested by a version without the sources included so you can use the IDE normally?
To facilitate work I am thinking of removing some conditional used for port that I do not care like Linux
Would you be interested by a Visual C++ only version ? you can get VC++ 2010 for free from Microsoft

Of course, I would like a normal C++ project we can explore in the IDE.

But I wouldn't ditch the Linux part. There's no reason all my mods wouldn't work in Linux. I just need to copy one or two options in Linux. And I use VC6, but also BCC, so a VC-only version doesn't appeal to me. VC2010 is totally out of the question, I keep using VC6.

[DrCoolZic]

Yeah, h files contain compilable code and cpp files are included. The behaviour of h files depends on macros like IN_MAIN, IN_EMU. I think the Steem authors should be tried before a C/C++ jury. It's hard to undo. I haven't tried yet.
But apart from that, at least there's almost no assembly. Back when I was looking at improving WinSTon, it was full of assembly. I just don't know that "language". And their code is very readable. Of course, I would have liked more comments as well.

I also do not know assembly
I do not want to sound bad for the huge (and excellent) work they have done. Steem is still my favorite ST emulator and yes the code in seems seems to be well written ...
The only bad thing is the way it is organized
Some .cpp included in .cpp included in .cpp (and sometimes more) !!! I have been able to get rid of includes successfully using steem.cpp and main.cpp as examples.
The tough part comes mainly from the .h files as they contains definition as well as code combined with conditional. There is a file include.h that include every .h files plus some code but difficult to use because of the IN_MAIN conditional placed everywhere. As already mentioned the results is that everything get included in everything if used like it is and this results in multiple definitions in multiple modules ... and to make things worse some definitions are hidden in .cpp.
So the normal split between.h and .cpp is all wrong and as mention in some of your comments it also preclude to use prama once as it is included with IN_MAIN defined and not defined ...

Therefore I have started to clean code especially .h file
For example the code:

Code: Select all

#ifdef IN_MAIN
#define EXT
#define INIT(s) =s
#else
#define EXT extern
#define INIT(s)
#endif

#define T(s)       Translation(s)
#define StrT(s)    Translation(s)
#define CStrT(s)   Translation(s).Text
#define StaticT(s) (TranslateString=Translation(s))

EXT EasyStr TranslateString,TranslateFileName;
EXT char *TranslateBuf INIT(NULL),*TranslateUpperBuf INIT(NULL);
EXT int TranslateBufLen INIT(0);

EXT EasyStr Translation(char *s);

#ifdef IN_MAIN
EasyStr StripAndT(char *s)
{
  EasyStr Ret=Translation(s);
  for(;;){
    int i=Ret.InStr("&");
    if (i<0) break;
    Ret.Delete(i,1);
  }
  return Ret;
}
#else
extern EasyStr StripAndT(char*);
#endif

#undef EXT
#undef INIT


Has to be spitted into a .h

Code: Select all

#pragma once // JLG

#define T(s)       Translation(s)
#define StrT(s)    Translation(s)
#define CStrT(s)   Translation(s).Text
#define StaticT(s) (TranslateString=Translation(s))

extern EasyStr TranslateString,TranslateFileName;
extern char *TranslateBuf,*TranslateUpperBuf;
extern int TranslateBufLen;

EasyStr Translation(char *s);
EasyStr StripAndT(char*);

and a .cpp

Code: Select all

// JLG FILE
#include "easystr.h"

EasyStr TranslateString,TranslateFileName;
char *TranslateBuf=NULL, *TranslateUpperBuf=NULL;
int TranslateBufLen=0;

EasyStr Translation(char *s);   // JLG => defined in gui.cpp ???

EasyStr StripAndT(char *s)
{
  EasyStr Ret=Translation(s);
  for(;;){
    int i=Ret.InStr("&");
    if (i<0) break;
    Ret.Delete(i,1);
  }
  return Ret;
}


So in some cases I have to create a corresponding .cpp or to push code in an existing one
in other cases I have to create a .h file for places where globals are not defined
Also some external def are not matching the corresponding .cpp. In the example above some of the declaration are in fact for another module ?!?
So this is really a mess but I will try to see if I can get to something ... already spitted about 30% of the .h for main.cpp
BTW I am not at all a GUI person so I feel more comfortable in the emu that in the steem so I work a bit blindly here

Of course, I would like a normal C++ project we can explore in the IDE.
But I wouldn't ditch the Linux part. There's no reason all my mods wouldn't work in Linux. I just need to copy one or two options in Linux. And I use VC6, but also BCC, so a VC-only version doesn't appeal to me. VC2010 is totally out of the question, I keep using VC6

Good because the linux is adding complexity.
For VC: version 6 or 2010 should accept (almost) the same source so this is OK. the only diff will be in the config files but not a problem.
Why do you need BCC if you have VC? one is not enough? Or BCC has an IDE or capability that you like?
Does BCC implies differences in sources? How different?

I will continue for few days before giving up
I will probably also add doxygen minimum info so documentation for code can be generated but this is low priority (this is very handy to navigate through code)

[Nyh]

I am interested in a version that compiles good under Visual C++ 2010. There are some instruction timing bugs I want to fix in STeem to make one of my unreleased demos work.

Hans Wessels

[DrCoolZic]

I am interested in a version that compiles good under Visual C++ 2010. There are some instruction timing bugs I want to fix in STeem to make one of my unreleased demos work.

Hans Wessels

Progressing slowly lots lots of work to cleanup the organization

[DrCoolZic]

Steven would you be interested by a version without the sources included so you can use the IDE normally?

Of course, I would like a normal C++ project we can explore in the IDE.

Done and working

Much much much more work than anticipated but it works (or seems to work) for _DEBUG_BUILD on/off and STEVEN_SEAGAL on/off with VC++ 2010

I have only done very basic tests so far and therefore I do not intend to release publicly.

More info to come soon

Attached Doxygen doc of current code. Unrar and inside the html folder double click the index.html file to start browsing.

I have also found some problems with the code you have modified see viewtopic.php?f=94&t=21634&p=197429#p197429

[DrCoolZic]

Steven I did a huge work to "split" the code correctly. This is almost 2 weeks of work

This makes things much more easy to follow in the IDE. I really like your build and new functionality you have added and therefore I would love if we could merge your current work with the work I have done.
This can be either way I take your latest and try to see what has changed compared to 3.3b or you take my 3.3c and put your new change in it.
If your changes are localized I can do otherwise it might make sense that you do it.

My next step is to remove the non WIN32 code and eventually to get rid of the macros?
My code compile under VC and I do not know if there are some specific requirements for BCC
Currently the build in VC are done with warning off but turning it on gives some alarming info and I would like to clean it. Turning warnings off is usually not a good idea

Let me know what you think

Attached my current source tree 3.3c for VC++ 2010 you should not have any problem to adapt to VC6 look at doc/jlg for build info

Some information also here http://info-coach.fr/atari/software/pro ... m.php#v33c
lots of nice graphics on the current build here http://info-coach.fr/atari/software/pro ... index.html (llok at the include graphs and the call graphs!)

[Marakatti]

...and eventually to get rid of the macros?

Please don't do it!!! It's an excellent feature which I think should be in every emulator. So easy to reset, stop and rewind etc... Being able to reconfigure things is essential especially for laptops.

[DrCoolZic]

...and eventually to get rid of the macros?

Please don't do it!!! It's an excellent feature which I think should be in every emulator. So easy to reset, stop and rewind etc... Being able to reconfigure things is essential especially for laptops.

I am not sure I understand what you mean by reset/stop/rewind?
Apart from easy define/undefine for debug or not I do not see why it is more practical than functions?

[jruark56]

DrCoolZic,

You may be talking apples and oranges with Marakatti. There is a function within the application labelled "Macros". These are not compiler macros, but instructions that can be given to the emulator to perform various functions without user intervention.

Marakatti,

Please feel free to correct this post, if needed.

Russ

[jokker]

Yeah I think Marakatti is confused about what macros you are talking about.

DrCoolZic, let me know when that src becomes available. I had certainly thought about trying to organize the code in a more standard way when it came out. It's awesome what you've done so far and I'd be happy to try and lend a hand to the cleanup and further development efforts.

[Marakatti]

Yeah I think Marakatti is confused about what macros you are talking about.

Indeed, had no idea there are other kind of macros that are invisible to front-end users. No need for me to advertise that I can't code a single line, I guess

[DrCoolZic]

Yeah I think Marakatti is confused about what macros you are talking about.

DrCoolZic, let me know when that src becomes available. I had certainly thought about trying to organize the code in a more standard way when it came out. It's awesome what you've done so far and I'd be happy to try and lend a hand to the cleanup and further development efforts.

First thanks for the clarification

If you look above I already released it

This tree is based on Steven Seagal release and still contains the UNIX code. This is released so that if someone wants to create a UNIX tree from this it is still possible (but will require to fix the code).

The next release to come soon will be Windows only and all Unix code will be removed. I hope to be able to merge the new development made by SS to keep only one tree

As far as the source tree organization and how to compile this new tree look at the attached documentation.

[DrCoolZic]

Just tried few other areas of the program:
1 - the ONEGAME compile option is totally broken ? not sure if want to fix it ?
2 - The segal build was using the NO_ASM_PORTIO removing this defined was braking my build now fixed
3 - I have tried to compile the C version of the drawing routines

As provided the draw_c.cpp code does not compile because there are several macros like this one:

Code: Select all

#define OSD_DRAWPIXEL(c) *(((WORD*)dadd)++)=(WORD)c;

which expand to wrong code! It does not compile with error C2105 '++' needs l-value under VC++
This source may compile on some C++ compiler but it is wrong because this suppose that an intermediate variable is created and destroyed by the comp (not C++ compliant)
Here is an example of right and wrong:

Code: Select all

BYTE* dadd = 0;
WORD* tmp= (WORD*)dadd;
tmp++;  // OK
((WORD*)dadd)++ // Wrong error C2105

I have fixed the problem by changing the above macro with

Code: Select all

#define OSD_DRAWPIXEL(c) dadd_w=(WORD*)dadd;*(dadd_w++)=(WORD)c;dadd=(BYTE*)dadd_w;

Of course this also requires to add the dadd_w var declaration in the functions using this macro.

The problem is allover the place in draw_c.cpp and in in some cases it is less intuitive . for example

Code: Select all

#define DRAW_2_BORDER_PIXELS *(((DWORD*)(draw_dest_ad))++)=*(DWORD*)(PCpal);*(((DWORD*)(draw_dest_ad))++)=*(DWORD*)(PCpal);*(((DWORD*)(draw_dest_ad))++)=*(DWORD*)(PCpal);*(((DWORD*)(draw_dest_ad))++)=*(DWORD*)(PCpal);

needs to be replaced by

Code: Select all

#define DRAW_2_BORDER_PIXELS draw_dest_ad_dw=(DWORD*)draw_dest_ad; *(draw_dest_ad_w++)=*(DWORD*)(PCpal);*(draw_dest_ad_w++)=*(DWORD*)(PCpal);*(draw_dest_ad_w++)=*(DWORD*)(PCpal);*(draw_dest_ad_w++)=*(DWORD*)(PCpal);draw_dest_ad=(BYTE*)draw_dest_ad_w;

Another problem was 4 wrong functions declarations:
extern "C" void ASMCALL osd_black_box_8(void*,int,int,int,int,long,long){}
defined in some other place (osd.h) with only 6 parameters.
This results in error: second C linkage of overloaded function 'osd_black_box_8' not allowed (functions declared extern C cant have different # of param as undecorated name is used)
Looking at the code this function is assigned to function pointer osd_black_box and latter on call are done with 6 param
Therefore needs to be changed to
extern "C" void ASMCALL osd_black_box_8(void*,int,int,int,int,long){}
Need to do that on 4 functions

When all this was done I recompiled the complete project including the draw_c.cpp file (and included files) and linked it WITHOUT the assembly equivalent (otherwise multiple definition)
and the program was generated correctly

I have tested the program in high/medium/low resolution and it seems to work correctly. So now the draw_c.cpp file is included with conditional macro.

The draw_c.cpp includes many times some cpp files with many redifinition of macros and it seems therfore very difficult to change this. As the C code is almost as unreadable as the assembly code it probably does not make senses to change this.

[DrCoolZic]

Yeah I think Marakatti is confused about what macros you are talking about.

Indeed, had no idea there are other kind of macros that are invisible to front-end users. No need for me to advertise that I can't code a single line, I guess

Do not worry problems for me are different: No need for me to say that I am a novice in emulation technology

[Steven Seagal]

I'll check this. It never was my plan to remove the Unix part. Likewise, I left the ONEGAME macro as is, it could be interesting one day.

Not to whine or anything, but I would also like to remind you the scepticism and little interest met by my approach (larcenies and hacks). It is supposed to be just a questionable branch, even if I have much fun with it. Maybe you should start from Steem 3.2 instead so as to make a new base for other branches.
But if I can take advantage of your fruitful efforts be sure I will.

[DrCoolZic]

I'll check this. It never was my plan to remove the Unix part. Likewise, I left the ONEGAME macro as is, it could be interesting one day.

Not to whine or anything, but I would also like to remind you the scepticism and little interest met by my approach (larcenies and hacks). It is supposed to be just a questionable branch, even if I have much fun with it. Maybe you should start from Steem 3.2 instead so as to make a new base for other branches.
But if I can take advantage of your fruitful efforts be sure I will.

I have ABSOLUTELY no problem with your pragmatic approach (you even have the blessing from original author!). I am totally amazed (I really mean it) by the modifications that you have done in a such complex (and not documented) code and even better succeeded to merge the best of both world Steem/Hatari.

Originally I started to look at the code to see if I could integrate the SPS library in Steem (to be able to read IPF game files) by looking at the way Pasti integration has been done.

Steem is a huge project with a lot of code difficult for me to understand: I have a reasonable good knowledge of C++ (I started around 1984) but I am not familiar with emulation technique and I have very basic knowledge of Windows GUI.
This is why I have decided to create a version that is easier for me to understand by removing the UNIX/LINUX and other features for which I have no interest (I am fed-up of UNIX!)

As of tonight I have completed a correctly organized Windows only version that works correctly for all major flags: DEBUG_BUILD on/of - SEAGAL on/off - PORTIO on/off - NO_ASM on/off ...
As turning the ONEGAME flag breaks a lot of code and as I have no interest in this option I will probably remove the related code also. This option cluter the code all over the place!

Therefore I fully understand that we have different goals and that you have probably no interested for my "branch".

If you decide to have a tree that contains everything (I mean UNIX / Windows) but have a clean separation of .h .cpp you can probably use the version released above: "the Steem-111205" as it should still contains almost all the UNIX code (apart from mistake). But as already mentioned none of the UNIX defined code has been tested. But it may already be too much work?

Therefore it is probably not interesting for you to catchup with me .... but I hope I will be able to catchup with your next release. I will use a recursive difference program to check all the things changed in the new tree you will release (hope it will come soon)

But please keep doing what you have started as there is a lot of interesting features that you have added and do not worry about jealous people It is always easier to criticize than to do

But you should probably also keep an eye on what I am doing because you may benefit from it. For example the new version of draw_c.cpp that fixes the macros etc.

[Steven Seagal]

As long as I'm having fun, I continue. But there's no need to talk of jealousy. Unless jealous of Steven Seagal the great actor, musician, and sex symbol. That I could understand. For ST emulation, I think the concerns expressed were legit.

Edit: Or maybe my style of bragging each time I have one more program running is irritating (after all the Steem authors didn't do that!), but this isn't gonna change, I'm afraid.

[DrCoolZic]

Unless jealous of Steven Seagal the great actor, musician, and sex symbol.

Not to forget that he is a great Aikido specialist

Just wandering how you have been able to pickup so quickly the inner working of Steem?
Newbie GUI question. What tools are using to modify the Steem GUI?

[Steven Seagal]

Just wandering how you have been able to pickup so quickly the inner working of Steem?

I haven't, I started modding blind. I still only understand some parts of Steem, in which I was active (like video).
But interrupts, sound, fdc (pasti!), etc., not really.

Newbie GUI question. What tools are using to modify the Steem GUI?

That I got quickly. Except graphics, it's in C++ code, but in a way that makes it easy to change. For example adding the STF/STE switch in the GUI was very easy.