Hi,

Maybe you guys know something about good old turbo pascal :D

Turbo pascal 7 has the 'interrupt' directive which can be placed behind a procedure name to turn it into a interrupt handler.

procedure interrupt_handler(Flags, CS, IP, AX, BX, CX, DX, SI, DI, DS, ES,
BP: Word); interrupt;
begin
end;

All cpu registers will be copied into these parameters.

The documentation says that after the interrupt routine is done all these parameters will be stored back into the cpu registers.

The problem is that these parameters are probably passed 'by value'. So these are only copies.

When modifieing these parameters it is useless (?) because they are not placed back into the cpu registers ???????

Is that true... ?

How does one write a decent interrupt routine for turbo pascal where cpu registers can be modified... since the driver which calls the interrupt routine excepts certain cpu registers to be changed/set. For example to buffers.

Skybuck.

Actually it is for a packet driver in dos.

Maybe I have to manually set the interrupt routine in the interrupt vector table or will the packet driver do that ?

Nope...

It seems the problem was with setting the ethernet card address.

The test program was setting the ethernet address of the network card to decimal:

10:20:30:40:50:60

Just to test it for fun...

Somehow that prevented the network card from receiving any packets.

Hmmm

Now I am not sure anymore... I re-enabled the set address and it still works...

Maybe it is now working because I did a reboot :)

Maybe the old dummy receiver or so fucked something up I dont know.

Maybe constantly changing packet driver settings is not a good idea...

Maybe the packet driver should be unloaded and then reloaded or maybe just a fresh boot.

:)

Ok,

I think I have found the culprit...

The test program calls: 'reset interface' function.

This function is not working properly anyway... (it does not clear multicast list and does not re-fetch address from rom)

Disabling this function from the test program makes it work and receive packets :D

If a send a packet of ethernet/ip/udp and data 395... the test will show 437 bytes received...

( First I thought that can't be right ethernet is only 14 bytes :) but I forgot the other protocol headers :) )

Hmm let's see... 14 bytes for ethernet header + 20 bytes for ip + 8 = 42 bytes.

437 - 42 = 395 matches perfectly !!! :D

Yes !!!

It seems pascal interrupts do work like they should !!! :D

I apologize for this :D lol Stupid me ! :D

Wieeeeeeeeeeeeeeeeeeeehhhhhhhhhhhhhhheeeeeeeeeeeeeeeeee :):):):):):):):)

Skybuck.

Hi,

Harald Houppermans wrote

Actually it is for a packet driver in dos. Maybe I have to manually set the interrupt routine in the interrupt vector table or will the packet driver do that ?

I have no idea what the packet driver does but to your original question yes, you can freely modify registers' values passed to the interrupt procedure and new values will have effect upon return, just like help says, and see the attached example.
No, it doesn't matter whether you use SetIntVec or change interrupt table by hand (though I'd not recommend the latter). HTH.

Ups, forgot to actually attach it, sorry, now goes...

Man... great... :)

It says so in the specification lol:

"
Resets the interface associated with handle to a known state, aborting any transmits in process and reinitializing the -> receiver <- "

Ofcourse I didn't know what that ment ? "reinitializing"

Could mean anything :)

Apperently it just disables the receiver...

Probably nil or so :)

That's why the receiver never gets called...

Also for most packet drivers 'packets lost' will never increase also bytes in will never increase...

For some packet drivers this might still work...

So apperently for most packet drivers the receiver needs to be initialized and working etc... otherwise statistics won't get updated...

( but for some it still will ? or maybe those packet drivers are buggy... who knows :) could be anything :) ) :)

Thanks for your quick reply.... but I already solved the problem :)

It would be interesting to see how hard it would be to use free pascal and 16 bit packet drivers...

( Holyshit... my monitor just did weird... probably a power source... that never happens wow, or maybe the monitor
is about to die hehehehe it's quite old :) 5 to 6 years or so... (Liyama vision master) ohoh :) my very old 15 inc eizo died like after 9 years or something at my brothers place since I gave it to him.. actually he forced me too give it to him lol hehehehehe never again ! :D I still have to get it back lol and the pc too :D he doesnt use it anymore :D it has a very cool 56k6 ISA modem which says: 'MADE IN VIETNAM'.... I bought it specially for him 100 bucks I want it back :D:D:D:D that s so cool )

Anyway...

In wdosx/dwpl it seems like quite a hassle... using real mode callbacks etc... oh well.

Maybe in the future I come back to this mailing :D when I am reallllly disperate to get something working :D

People that write 32 bit compilers must know their stuff :D :):):):):)

Hmmm right after this posted my cable modem went down to lol...

It's dhcp lease probably expired... It seems dhcp leases have been shortened by my isp :) I think... :)

Like 6 days before it expires or so then I get a new one.

It would suck if that happened while testing packet drivers over the internet or so... heheh

I'll be like wtf... why it aint working... damn.

It's like a wireless mouse running out of battery juice... you'll be like huh ? wtf why is my system so slow mouse not responding must be bug in my program hehehe.

I hate this fricking wireless mouses :D hehehe

yes sir !

I have a cordfull mouse ! :D yupyupyup...

They just don't make em anymore like they used too... no mouse balls anymore... the latest mouses have like lasers
which almost blind you... I bought the cheapest one I could find for my parents pc... fortunately it's laser pointed forward so it doesn't blind you when you flip it... but others do/will shine in your face hehe. The original mouse for parents pc's did have wireless mouse I knew that when we bought it but the package was cheap. oh fuck no lol crappy pc hehe. So I was already planning on replacing it. The new mouse does have a wire but it also has a laser... doh.

It was the only one I could find in the local stores.. the rest where all wireless iieeewww. hehe.

Anybody else having that same experience ? shops having wirefull mouses only ? yak.

I hope mouse manufactures stop producing that junk quickly and turn back to wirefull mouses :D

The salesman also said he was barely selling anything from that junk. :D

Anybody else having that same experience ? shops having wirefull mouses

only

? yak.

Oh shit I ment wireless mouses only hehe.

Wow....

Did you just write this from scratch ?

That's a very cool trick you did there...

Replacing the CS ( code segment )

And IP ( instruction pointer )

Seems like a dirty little hack lol... like a hacker could use to execute code hehehe.

Anyway I was also wondering how to proof it...

This will proof it just fine :)

I wonder if you can also write this same example for free pascal 32 bit ?!

HEHE that will probably require a lot more code ?! :)

uses Dos, Crt;
{$F+}
var
  Int8Save: procedure;
const
  count: longint = 0;
procedure Subst;
begin
  writeln('Here we are!');
  repeat until false;
end;
procedure TimerHandler(Flags, CS, IP, AX, BX, CX, DX, SI, DI, DS, ES, BP:
Word); interrupt;
begin
  inc(count);
  asm
    pushf;
  end;
  Int8Save;
  { Uncomment the following 2 lines and see what happens. }
{
  CS := Seg(Subst);
  IP := Ofs(Subst);
}
end;
begin
  GetIntVec(8, @Int8Save);
  SetIntVec(8, Addr(TimerHandler));
  writeln('Press ANYKEY to exit');
  repeat
    write(count, '     '#13);
  until Keypressed;
  SetIntVec(8, @Int8Save);
end.

Skybuck.

Lol now I understand why you placed repeat until false; lol

Without it it crashes :D hmmm

Probably no way to recover from it... hmmm

Or is there ?

Hmm maybe there is :)

Storing the CS and IP and then later going back...

But euhm that would be cheating...

Since it has to call/end the interrupt...

Hmm no it's not cheating.

WOW very interesting indeed

I thought you did it like this:

asm
mov CS, blabla
mov IP, blabla
end

But now I see !!!

You are actually using the parameters:

CS := blabla; :)
IP := blabla; :)

That proofs it works :D

And recovering from it should work as well :D

CS := OLDCS;
IP := OLDIP

No lol that's not possible

var
    OLDCS : word;
    OLDIP : word;

procedure Subst; begin writeln('Here we are!');

    CS := OLDCS;  // this ofcourse cant work since parameter is not
available here. unless maybe it is pushed or so i dont know.
     IP := OLDIP;
    mov CS,OLDCS // cant work
    mov CS,ax // cant work invalid combination

end;

Shit :)

I still wonder if there is a way to make it recover...

Euhmmmm this is very funny.

Those interrupt parameters actually allow something which otherwise isn't allowed ?!

Hmm. :)

    OLDCS := CS;
    OLDIP := IP;

Turbo pascal 7 has the 'interrupt' directive which can be placed behind a procedure name to turn it into a interrupt handler.

forget it, it's a bug
it doesn't save all registers (so your program will crash if it uses longint) and it doesn't provide a stack (so your programm will crash even it it doesn't use longint).

The problem is that these parameters are probably passed 'by value'. So these are only copies.

try trapint.pas from this page:
http://www.brain.uni-freiburg.de/~klaus/pascal/sources/

hope this helps,
Klaus

The CS and IP parameters access the return address stored on the stack. (so after the iretd it will continue executing from there) In 16-bit DOS you can even simulate multithreading using this. Just hook int8 and store the CS/IP and all the other registers for the current thread and load CS/IP/registers of the next thread to be executed. Alas I didn't find a way to do that in 32-bit DPMI. :)

----- Original Message -----

----- Original Message -----

Hi,
Thursday, 18 March, 2004, 18:26:04, Harald Houppermans wrote: [...]

TP7 only uses 16-bit regs, for longints too, hence no need to save/restore higher words.

> and it doesn't provide a stack (so your programm will crash even it it doesn't > use longint).

Of course interrupt handler will have some stack, though it is usually rather small (like all things in 16-bit world ;) Built-in stack checking won't work properly though indeed.

Euhm... why will it crash ? Let me gues... if I call other routines from inside the interrupt routine ?

No. If you re-enter non-reenterable code like DOS services, say try to open some file without special care.
This is getting too much off-topic I guess...

----- Original Message -----

----- Original Message -----

TP7 only uses 16-bit regs, for longints too, hence no need to save/restore higher words.

No, programs compiled with Turbo-Pascal 7 with the $G+ option will use 32 bit registers for longint arithmetic if the program runs on a 386 cpu or higher. They test the cpu-type on startup and store the result in the global variable 'test8086'. Longint library functions test this variable to decide which code to use.

But the programs do not not save the upper half of the cpu-registers in interrupt procedures, so if the interrupted main program is in the middle of a longint calculation and the interrupt procedure uses longint as well, then the calculation in the main programm can get incorrect results.

The attached source demonstrates the problem, however I just noticed that the error happens much less often if the program runs in a dos window than when it runs in plain dos.

I think stack checking does report the problem, but the stack can sometimes be so small that it can hardly store the registers. Yet a Pascal-Program can easily use a lot of stack, for example if it uses a big local record variable or strings or if it passes such variables to another procedure. This can easily overwrite the stack, causing the program to crash. Using the $M option does not help because what the interrupt procedure sees is the stack of the interrupted program, not necessarily the stack of the pascal program.

Summary: If you want your program to be reliable,
don't use the built in interrupt keyword.

I suffered from both problems, that's why I wrote trapint.pas

> Euhm... why will it crash ? > Let me gues... if I call other routines from inside the interrupt routine ? No. If you re-enter non-reenterable code like DOS services, say try to open some file without special care.

It will crash because the return address on the stack is overwritten with other data, so when the interrupt procedure finishes, the CPU doesn't remember to which address it should return.

Klaus

The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.

---- File information -----------
File: Int-eax.pas
Date: 19 Mar 2004, 11:29
Size: 873 bytes.
Type: Binary

Hi,
Friday, 19 March, 2004, 14:10:02, Klaus Hartnegg wrote: [...]

No, programs compiled with Turbo-Pascal 7 with the $G+ option will use 32 bit registers for longint arithmetic if the program runs on a 386 cpu or higher. They test the cpu-type on startup and store the

Ok, I've found you are right essentially.
To be precise though, $G+ have no effect on this, as TP7 compiler itself still generates pure 16-bit code. Math libraries are most probably hand-made and use 32-bit code for intermediate calculations, depending on test8086 variable value.
So, when going to use "interrupt" directive one should do "test8086 := 1" before any interrupt ever happen. Nice to learn this.

----- Original Message -----

No, the 286 is a 16 bit cpu with a 24 bit address bus (so it can address 16MB ram, not 32MB). The width of the address bus is independent of the size of the registers of a cpu.

Jonas

----- Original Message -----

Protected mode pretty much means that the mapping from applications address space to physical memory is not visible to the application.