External interrupts generated by TCP/IP stacks

[dissident]

Hi,

I've got a problem that perhaps the program MiamiDX causes using a TCP/IP stack and generating spurious interrpts, maybe the PORT-int. See also http://eab.abime.net/showthread.php?p=675900&styleid=4

My demo takes over the machine and uses INT6 & TNT2 generated by the CIA-timers for the tracker-replay-routine. If the CIAs are not the source of the inerrupts, then the INT2/6 is acknowledged and the routine returns by a NOP + a RTE.

I guess the only way to handle this, is to close MiamiDX and starting my demo after that. Otherwise my demo freezes but the music keeps playing.It seems that the CPU doesn't reach a user mode any more to execute my effects.

[Galahad/FLT]

Originally Posted by dissident

Hi,

I've got a problem that perhaps the program MiamiDX causes using a TCP/IP stack and generating spurious interrpts, maybe the PORT-int. See also http://eab.abime.net/showthread.php?p=675900&styleid=4

My demo takes over the machine and uses INT6 & TNT2 generated by the CIA-timers for the tracker-replay-routine. If the CIAs are not the source of the inerrupts, then the INT2/6 is acknowledged and the routine returns by a NOP + a RTE.

I guess the only way to handle this, is to close MiamiDX and starting my demo after that. Otherwise my demo freezes but the music keeps playing.It seems that the CPU doesn't reach a user mode any more to execute my effects.

Common problem, WHDLoad needs TCP/IP stack closing down for the same reason.

I would make a note at the start of your demo to request user temporarily halts the process so that your demo can run.

[phx]

The TCP/IP stack shouldn't get cpu cycles anymore, when the demo has taken over the system. I guess the problem is that the network card's device driver has enabled interrupts on the chip (for sending/receiving packets), which still happens. And as you never acknowledge these interrupts they will immediately occur again, after leaving the interrupt routine.

Difficult to fix, as you don't easily know which network interface chip is running.

[meynaf]

I would personnally solve this case by not taking over the machine

[dissident]

Originally Posted by phx

The TCP/IP stack shouldn't get cpu cycles anymore, when the demo has taken over the system. I guess the problem is that the network card's device driver has enabled interrupts on the chip (for sending/receiving packets), which still happens. And as you never acknowledge these interrupts they will immediately occur again, after leaving the interrupt routine.

Difficult to fix, as you don't easily know which network interface chip is running.

I understand, it's like the CIA-Chip interrupt behaviour. The card generates different interrupts itself which lead indirectly to level 2 or 6 interrupts on the amiga. So if I only acknowledge the level 2 / 6 interrupts on the amiga it's not enough. The same would happen, if I don't clear the CIA-ICR register.

[dissident]

Originally Posted by meynaf

I would personnally solve this case by not taking over the machine

Well, no risk no fun. For a maximum of performance I have to take over this machine. But I know, banging the hardware directly is always a risk.

[meynaf]

Originally Posted by dissident

Well, no risk no fun. For a maximum of performance I have to take over this machine. But I know, banging the hardware directly is always a risk.

Of course you may just want to do os killing demos for the fun of it.
But doing it for performance is IMO not worth.

If you're running a TCP stack and in the same time have enough system resources to run a demo then the machine is obviously not an unexpanded A500. There is little benefit in killing the OS with fast enough machines having lots of memory, as AmigaOS isn't exactly a cpu hog. So if you just leave multitasking on you should not see a difference.

[dissident]

Originally Posted by meynaf

Of course you may just want to do os killing demos for the fun of it.
But doing it for performance is IMO not worth.

If you're running a TCP stack and in the same time have enough system resources to run a demo then the machine is obviously not an unexpanded A500. There is little benefit in killing the OS with fast enough machines having lots of memory, as AmigaOS isn't exactly a cpu hog. So if you just leave multitasking on you should not see a difference.

The thing is, my demo is written especially for a vanilla amiga 1200 as a minimum config. No fastmem, no 68060. So I need every free cycle for the effects to run in full frame rate. During a test on an expanded A1200, the error occured.

Talking about an expanded amiga, you are right. There, the AmigaOS isn't exactly a bottleneck as on slower systems.

[meynaf]

Originally Posted by dissident

The thing is, my demo is written especially for a vanilla amiga 1200 as a minimum config. No fastmem, no 68060. So I need every free cycle for the effects to run in full frame rate. During a test on an expanded A1200, the error occured.

Talking about an expanded amiga, you are right. There, the AmigaOS isn't exactly a bottleneck as on slower systems.

You're quite courageous running a TCP stack on a vanilla A1200

[dissident]

Originally Posted by meynaf

You're quite courageous running a TCP stack on a vanilla A1200

Thanks for the praise, but this is a misunderstanding. The TCP stack ran on a friend's expanded A1200/060 with fast memory where he tested my demo started from the workbench. I wanted to know if it also works fine on an expanded system.

[meynaf]

Originally Posted by dissident

Thanks for the praise, but this is a misunderstanding. The TCP stack ran on a friend's expanded A1200/060 with fast memory where he tested my demo started from the workbench. I wanted to know if it also works fine on an expanded system.

Ok, so let's examine possible solutions.

You could check if some TCP stack is running, and if it's the case, don't take over the system. Or check memory size to see if the A1200 is expanded or not.
Alternatively, if you detect a spurious interrupt, transfer control to the previous interrupt vector so that it can be handled. Of course if you completely destroy the system then you're locked !
Or, leave the OS running and set task priority to max, while eventually disabling all interrupts you're not using.
Or else, detect the case and restore the system if it happens, so you can display some error message.

But the simplest way is probably to show some popup asking the user to close the relevant apps. Or just say that in the readme.
Because you can never know what kind of hardware has been plugged in and the interrupts it might cause...

[dissident]

Hey, many thanks for your ideas, meynaf. I nearly had the same thoughts:

Originally Posted by meynaf

You could check if some TCP stack is running, and if it's the case, don't take over the system.

Could you please give me a hint how I could do this?

Originally Posted by meynaf

Or check memory size to see if the A1200 is expanded or not.

Yes, a CPU/memory-check. IF CPU=68030 or greater AND fastmem=yes then don't turn off the system and initialize my own interrupts with a high priority in a system friendly way.

Originally Posted by meynaf

Alternatively, if you detect a spurious interrupt, transfer control to the previous interrupt vector so that it can be handled.

Yes, this would be the old way used on the A500. Deforming the original autovector to the own interrupt routine and after this routine is finished executing the original interrupt routine.

Originally Posted by meynaf

Or, leave the OS running and set task priority to max, while eventually disabling all interrupts you're not using.

Yes, could be a also solution.

Originally Posted by meynaf

Or else, detect the case and restore the system if it happens, so you can display some error message.

Hmm...

Originally Posted by meynaf

But the simplest way is probably to show some popup asking the user to close the relevant apps.

Yes, the message could be displayed after a positive TCP stack test by the AutoRequest() routine. After closing the relevant apps, the user could confirm there to proceed.

Originally Posted by meynaf

Or just say that in the readme.
Because you can never know what kind of hardware has been plugged in and the interrupts it might cause...

Yes, this should be generally done for file-demos with or without a WB-icon.

[meynaf]

Originally Posted by dissident

Could you please give me a hint how I could do this?

Sorry I don't know exactly. I know it is possible because mailers and web browsers can check it, that's all. Perhaps it's by checking the presence of bsdsocket.library in memory.

[frost242]

Hello,

I also had to same issue with a subway USB card in my A1200, with the Poseidon stack. Some more hints on how to deal with it with Poseidon in this topic.

[dissident]

Originally Posted by frost242

Hello,

I also had to same issue with a subway USB card in my A1200, with the Poseidon stack. Some more hints on how to deal with it with Poseidon in this topic.

Thanks for the hint, but that doesn't answer my question how to detect a running TCP stack.

[dissident]

Originally Posted by meynaf

Sorry I don't know exactly. I know it is possible because mailers and web browsers can check it, that's all. Perhaps it's by checking the presence of bsdsocket.library in memory.

You are right meynaf. Your hint is confirmed in this thread: http://www.amiga.org/forums/showthread.php?t=50466

So I guess I only have to try to open this library:

  CNOP 0,4
check_tcp_stack
  move.l  $4.w,a6                       ;Exec-Base
  lea     bsdsocket_name(pc),a1         ;Name of the bsdsocket.library
  moveq   #0,d0                         ;Any version
  jsr     -552(a6)                      ;Open bsdsocket.library
  tst.l   d0
  beq.s   no_active_tcp_stack           ;If pointer to library = zero -> branch
  move.l  d0,a1                         ;Pointer to our library
  jsr     -414(a6)                      ;Close bsdsocket.library
  moveq   #0,d0                         ;Returncode = OK
  rts
  CNOP 0,4
no_active_tcp_stack
  moveq   #-1,d0                        ;Returncode = FALSE
  rts

bsdsocket_name
  DC.B "bsdsocket.library",0

I will check this, if I have more time.

[nogginthenog]

Probably won't work with RoadShow. RoadShow (IIRC) is the only stack to have a physical bsdsocket.library. Running OpenLibrary() might actually start RoadShow!

[McTrinsic]

Try loading bsdsocket.library with loadmodule?

[dissident]

Originally Posted by McTrinsic

Try loading bsdsocket.library with loadmodule?

What do you mean by this? I don't know the loadmodule command for libraries.

[StingRay]

FindResident() might be an option.