Comparing functions

[Muetze1]

Will you ever try to follow the rules? Will you ever learn the rules about pushing within 24 hours? Will you ever ...?

[Jelly]

Razor...
stop pushing. You have already been told several times, even via ICQ. This is not the way we follow here in DP.

[DevidEspenschied]

I wanted to test your package again but having serious problems with the installation of TcxCPU40 within Delphi 2007.

I load the DPK package and want to install it via the Project Management, but it can't compile and needs the file cxCPU40NVReg.dcr. Currently I'm having only the cxCPU40NVReg.pas and cxCPU40NVReg.dcu files.

Any idea why the package needs a dcr file ?

Because the package is from 2004, maybe there are some compatibility problems in combination with my Delphi 2007...

[Muetze1]

The DCR ist only the Picture of the component for the component palette. Remove the resource-compiler-instruction {$R *.res} from the package and install it.

[DevidEspenschied]

Wow, that was tricky.

Some things to notice. First of all, if you declare a procedure with the name amd64x2, it is better to call it. So the correct FormCreate procedure would be:

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
begin
  isLoadDr := GetInstance.LoadDriver;
  if not isLoadDr then MessageBox(form1.Handle,'Couldn''t Start I/O Driver! Some features will be disabled!', 'Couldn''t Start I/O Driver!', MB_ICONINFORMATION)
  else amd64x2;
end;

The next thing is within amd64x2, where you have the following if line:

cxCpu401.Available.Available=2 According to the TcxCPU40 component this line checks, if there is more then one physical core. But that is not correct, because my AMD Athlon 64 +3400 does have only one core (here the value 1) and that core provides internal temperature readings via #THERMPRIP. So the line should be updated to:

cxCpu401.Available.Available IN [1..2] And the last, but most catastrophically thing, is the exception, which is generated with the line:

GetInstance.IPCIIORef.GetPCIRDWord(0,24,$03,$E4,pdata); within TForm1.Timer1Timer. And I doesn't have the time to check this within the OMCDrv unit, because there are so many types, classes and structurtes. I would suggest, you manipulate this program somehow to read a basic PC port, such as the parallel port ($378) or the CMOS port ($70) to make sure, that your core reading routine works fine. The results from these port readings could be shown via the ShowMessage function, and compared with a simple DOS reading. Herefore you could create a simple DOS application like:

Delphi-Quellcode:

program dosporttest;
uses crt, dos;
begin
  clrscr;
  writeln(port[$378]);
  writeln(port[$70]);
  readln;
end.

At least that is always my way to verify a windows based hardware near function.

[Muetze1]

Zitat von devidespe:

Herefore you could create a simple DOS application like:

Delphi-Quellcode:

program dosporttest;
uses crt, dos;
begin
  clrscr;
  writeln(port[$378]);
  writeln(port[$70]);
  readln;
end.

At least that is always my way to verify a windows based hardware near function.

Only possible if you are using a 16 bit compiler system like turbo pascal. (or - with changes in code - 32 bit windows app unter Win9x)

[Razor]

Yes....any other suggestions to for testing i/o ports...

[Razor]

Okay finally something good from me! Found a delphi port tester program with source

http://www.wideman-one.com/gw/tech/D...m/PortTest.htm


I fixed the stuff and i get 209 C so i think the thing must be working..

Reply please...

[Razor]

I did it HAHA

http://img215.imageshack.us/img215/8...reenie4ob3.jpg friend ran it with with AMD 64 3000+ Just look at it rofl.It changes...


Hahaahh i did it!

[DevidEspenschied]

Congratulations.

Is it possible to tell us something about your future application ? What does it do ? Will it be available as freeware or source ?

Thanks, Devud