Sega Master System / Mark III / Game Gear|
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew
Weird StuffPosted: Mon Jan 03, 2000 2:36 pm
This makes absolutely no sense to me. Check out this program:
a = 0x4000 * 2;
As you can see, I'm simply multiplying a fairly large number, 16k, by 2 which should return the value
of 0x8000 or 32k to a. But, instead, I get back -32768. So, I decided to change it to an
unsigned int which as a limit of 4 billion but the same exact thing happens. This program was
compiled under Borland C++ for a DOS-Based (16-bit) program with a Large memory model.
I created a Windows (32-Bit) Console application under Visual C++ 5 and included the source
above into the project. When I ran it, it returned the right value. 0x8000. What's the deal?
Why did that happen? Is it because I'm using DOS (16-Bit)? Could this be the cause as to
why many emulation authors use DJGPP (32-Bit) or pure assembly in (32-Bit) when it comes
to DOS emulators?
|Posted: Mon Jan 03, 2000 4:25 pm|
... Clipped Rest ...
Ok to fix your problem in the above code replace the %d with a %u and you shall see that you do get 65535 (0x8000) when you do the print.. Reason being. %d treats the value as a signed int. %u will treat it as an unsigned value.
Jose Manuel Delgado
|Posted: Mon Jan 03, 2000 4:32 pm|
First off all, i can say bad answers.
The correct value was displayed. This is because a int uses the "complement for two" (i´m not sure how it´s named in english). You say the compiler to put a deimal number, an because 0x400 are -32768, 2*a= it´s the correct answer. Try : printf("%4x", a) in both compilers.
In console mode windows 32, the int size is four bytes, this is, 32 bits. This is because console aplications are "32 bits" aplications. Visual C++ is Microsoft, so don´t use it at all if possible. The "complement of two" of a number it´s not the same depengind of the number of bytes: for example, -5 in 16 bits it´s represented: 0x4004 (you have to complement the bits and add 1 to find the two complement). But in 32 bits it´s represented 0x40000004. So if you manipulate the bits directly you can alter the format the PC (defintively, the Intel Microprocessor) "storages" the numbers.
This is augly, sorry. Try to find more docs on a digital electronics book.
DJGPP also uses 32 bits for int´s, so you have to obtain the same that Visual C++.
PD: Check out the new version of Calypso :)
|Posted: Mon Jan 03, 2000 8:44 pm|
Thanks. That does fix the problem of it not showing me the
correct values but I still cannot store values greater than
32768 or it will reset back to -32768.
||Posted: Tue Jan 04, 2000 6:34 am|
The size of an int varies by implementation. On any 32-bit PC compiler (dos or windows) an int will be 4 bytes, giving you a range of -2147483648 to 2147483647 (any thing lower than the first number, or higher than the second, will wrap around and give you an invalid answer).
On a 16-bit compiler, ints will default to 2 bytes, giving a range -32768 to 32767. If your result is larger than 32767, it will wrap around to -32768 and count up from there. If it goes less than -32768, then it will wrap around to 32767, and count down.
This assumes that your ints will be treated as signed. if you declare your int as unsigned, then it will have the functional range of 0-65536. Note, however, that:
unsigned int number;
number = 32768;
will still print -32768. C cannot do any type conversion on 'number' for you, since it's a variable argument function. So it will find the argument passed to it and intepret it as a signed int, since that's what %d means to printf.
will interpret number as a unsigned int as intended, and print "32768". It would also print a -signed- int with a value of -32768 as "32768", or "-1" as "65535". So be warned.
You can declare 16bit int as a short, and a 32bit int as long, regardless of which compiler you're running.
As to why emu authors use 32-bit mode... well, it's blamed silly to deliberatly code eusing an archaic and inefficent CPU mode that exists only for backward-compatibility, when you know nobody's going to be able to run a genesis emulator on an 8086 or 286 anyway.
P.S. don't void your main.Posted: Tue Jan 04, 2000 6:36 am
main returns an int (usually '0').
most compilers will let void main() go by with a warning, but it's not ANSI, it's unprofessional, and other programmers will pants you and steal your lunch money.
Sorry for the late responsePosted: Wed Jan 05, 2000 7:21 am
Don't worry. It's the 2's Complement (Two's Complement. Hey,
I got this out of a hardware manual.) That's exactly what
I did and it worked for a while, but eventually it reset
back. It would multiply up to $8000 and then reset.
Why should I stay away from Microsoft's Visual C++? That's
what I was planning to code under all along. I was coding
under the old warhorse (DOS) for simplicity and debugging
and then I was going to re-code it for Windows and add
in some Direct X stuff. I sorta made a personal New Year's
resolution; which was to complete any project I started.
And one of them was my NES emulator Visual NES but now
I changed the name to BlueNES (one of my favorite colors).
My other project was to create a SMS and SG1000/3000
emulator called SG1K but that damn processor, the Z80 takes
so much time. Personally, I'm a NES head by heart. That's
what I grew up with. There weren't a lot of SMS games
here in the US and it wasn't as popular. But, I do know
that the SMS has a better graphics engine and I still like
Don't worry. I understand you perfectly fine. If I can
search as Swedish ROM site, examine German emulation
documents, and decifer poorly written source code, I
can easily understand your English. Your English is
written very well. If you never would've told me, I
wouldn't have noticed.
I know. But, I've always wanted to learn Direct X and
Windows stuff anyway. Very few people seriously develop
software for DOS anymore and it's time I finally move
into the Windows revolution.
I'm sorry if all this explaining bothers you but that's how
I am now. I hate it when people on the net tell me
simplistic garbage or when I read poorly written documents.
I don't want to do the same thing that I hate. This
bothers some people and they say I'm too "personal". Hey,
I'm sorry if I like to express myself.
PS. This is straight from the heart. If Meka had never been
created, then Calypso would be the very best SMS emulator
out right now. The graphics engine is solid and the
debugger is pure gold! I don't care what anybody says.
Brsms is okay, Massage is dead, and I don't want to pay
15 or 30 dollars just to play an incomplete emulator
that's not even in English.
Jose Manuel Delgado
Re: Sorry for the late responsePosted: Wed Jan 05, 2000 8:17 pm
Happy new year
Try to port a program from Windows, with DirectX, to Unix. Calypso is designed like a collation of emulation functions, so can be easily ported to other systems, Object oriented (KDE, the GUI currently it has, Windows (using OWL or MFC), etc...) or don´t object oriented (the no GUI version). All the thing you have to do is to write an interface module in any language capable of importing C objects. I thing this is the best way of program. If you make a program for Windows with DirectX, say goodbye to portability. Don´t surprise if the same version are for all Systems Allegro is capable of compile (bufff, there is a lot of work to program the main module, specially for GUI Object oriented systems).
Don´t find the well again and again. There are a lot of Z80 engines, better or whorse
Yes, it has several marvelous games. I think all systems have some piece of software that you have to check it
Yes. But a emulator must be a portable software. If you can emulate a system in a lot of othes systems, it´s better that make a perfeclty accurate emulator for one platform only. I think.
Ohhh, not. I´m very well talking with you, because not a long time before I was the same situation like you.
I had the same problems you have.
PD: Thanks for your words about Calypso. They help me to improve and work on the emulator.