converting (.cpp) instructions to (.c) ones

hi all, i hope that someone can help me to sove this problem.

i didn't understand exactly the meaning of these code lines:

Code:

---

14.        [B]char *ecran  = (char *) (0xA0000000L);[/B]
15.       
16.       
17.        char *virtuel = new unsigned char[64000L];
18.       
19.       
20.       
21.        void setmode(unsigned int mode)
22.       
23.        {
24.       
25.        asm {
26.       
27.        MOV AX, [mode]
28.       
29.        INT 0x10
30.        31.        }}
32.       
33.       
34.        //CLS l'ecran.
35.       
36.        void clsvirt()
37.       
38.        {memset(virtuel,0,64000L);}
39.       
40.       
41.        //RAM TO memoire video
42.       
43.        void cpyvirt()
44.       
45.        {memcpy(ecran,virtuel,64000L);}
46.       
47.       
48.        //Ecran virtuel
49.       
50.        void pixel(int x, int y, unsigned char col)
51.       
52.        {virtuel[(y*320)+x] = col;}
53.

---

i need to know exactly what the bold numbers refer to so i will be able to
write a C code similar to these precedent lines . thanks

The code in question has nothing to do with either C or C++.

operator new is to be replaced with the call to malloc... but if you do not know what

Code:

---

64000L

---

this number is, I really doubt you'll be able to make the adoptation...

Code:

---

char *virtuel = new unsigned char[64000L];

---

is basically the same as:

Code:

---

char *virtuel = malloc( 64000L );

---

as for the assembly, I have no idea -- it's not C or C++.

Its ok guys, its just hex. So he wants 0x64000.

Your inlined assembler on the other hand could be a problem unless you are working with DOS or something since you can't just go around calling interrupt 16 in C/C++...

What are you wanting to do? And please tell me you are writing DOS code...

Dealing with asm is a whole nother ball game. Perhaps the below link may guide you in the right direction, if you are using gcc?

http://asm.sourceforge.net/articles/linasm.html

Not only is it "a whole nother ball game." I will strongly contend that you are likely trying to do something that you simply are not allowed to do in the protected memory model.

Quote:

---

Originally Posted by master5001

Its ok guys, its just hex. So he wants 0x64000.

Your inlined assembler on the other hand could be a problem unless you are working with DOS or something since you can't just go around calling interrupt 16 in C/C++...

What are you wanting to do? And please tell me you are writing DOS code...

---

hi, no I m just trying to implement a 3D synthesis code on an FPGA ; there are some instructions that should be modified to adapt the code to the target device.

Quote:

---

Originally Posted by master5001

Its ok guys, its just hex. So he wants 0x64000.

---

64000L == 0x64000? I don't think so.

Quote:

---

Originally Posted by cpjust

64000L == 0x64000? I don't think so.

---

Yeah cpjust, you're right. I guess we are all entitled slow days. Its an signed value. Either way, the point remains the same reguarding what he is trying to do. However, in light of knowing what you are aiming for now, sunshine, I can tell you that your use of INT 0x10 is ok. But there is not a portable equivelant to the assembler, no less. So why not keep the inline assembler? Its not doing any harm.

> no I m just trying to implement a 3D synthesis code on an FPGA
How about starting with a decent and modern 32-bit compiler with a 3D graphics library then.

Not only will you benefit hugely from not having to deal with awfully small (by today's standards) 64K memory segments from DOS, you won't have to deal with getting a lot of 3D graphics code working either.

The code you posted belongs in a museum, leave it there and join this millenium.