Richard Smith schrieb:
No way, after the first int I have wait 5min and captured 5MB of ff. However, I have disabled the inb printf and all works fine for the rest :D
I'm afraid its the in's that I am interested in seeing. You have said earlier that the long delay is during the first couple of int10's. Thats where I want to see what its waiting on.
To clear this:
normally with disabled debug for the inTree emu there are three lines like
int10 vector at c000:xxxx short after each line normally the run_bios_int function is called.
the long delays are after the first call (20-30s) and after the second call (60-70s) The second delay is divided in two parts, because at the middle there is a flickering.
I know the log will be huge. Go ahead and run the user emu with the IO enabled for say 10 seconds and then quit. That should be enough to start with. It should compress down alot since its all text.
I have send the log to you, yesterday. Or not ??
Also did you run the user emu with the if (port < 0x53) filter on the IO? I want to first rule out that its an issue with reading the system timer.
I have tried this, but remember there was no debug outbut for port < 0x53 for the inTree emu.
However, I will do it for the userspace emu.
chris
-- Richard A. Smith