External interrupts generated by TCP/IP stacks
 

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.

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 would personnally solve this case by not taking over the machine ;)

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.

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.

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 ;)

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...

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

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

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.

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.

Yes, could be a also solution.

Hmm...

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.

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

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.

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.

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:


I will check this, if I have more time.

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

Try loading bsdsocket.library with loadmodule?

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

FindResident() might be an option.