Thanks, crash reports are interesting to know.

I've updated SNOOP (v.Aug 25 2023) with a new command line option,

1SNOOP debug

which will interactively ask before running each sub-test. That allows you to run the program one action at a time to help figure out where it crashes. You can also do

1SNOOP debug logfile

to leave behind a trail of activity in file SNOOP.LOG, in case that might give a clue.

clb wrote on 2023-08-25, 15:04:

...reports are interesting to know...

I will test my 2 problematic cards today.

Ok. I have testes the Siemens PC with the Matrox chip.

This is the last test i confirm with y, then it goes to the first line of the snoop display like in my other picture here wich is also the point it crashes.
The logfile it created is 0 bytes.

So you see it briefly printing "CRT Terminator: Not Detected. SNOOP v. Aug 25 2023" and then crash?

clb wrote on 2023-08-25, 15:48:

So you see it briefly printing "CRT Terminator: Not Detected. SNOOP v. Aug 25 2023" and then crash?

Yes it showed the first line of the Snoop screen like in my previous post (just with the new date).

DerBaum wrote on 2023-08-24, 23:55:

2023-08-25 01.45.45.jpg

Perfect, thanks, thank you for the information, that is really helpful.

That does give me a clue that it would be the PCI bus accessing that causes a crash. Pushed more diagnostics and a PCI 2.0 BIOS availability test for PCI before attempting to do PCI adapter reads: https://github.com/juj/crt_terminator/commit/ … 2afbeb09b54a30f . New version in the zip file. I would expect that to print at least a "PCI not supported" error now, if nothing else. (maybe more info in SNOOP.LOG file if "logfile" parameter is passed)

This is the point where it crashes 9/10 times

One time it went past this point and then crashed on the next one.

The logfile is 0 bytes again.

Thanks!

Ouch, so it is crashing right when calling the BIOS function INT 1Ah/AX=B101h to do a PCI BIOS installation check: https://github.com/juj/crt_terminator/commit/ … a87f179ab164R20

http://www.ctyme.com/intr/rb-2371.htm . So intriguing. The part "This function may require up to 1024 byte of stack" is something I need to check, although I would've assumed the default would've been more.

Hmm, http://computer-programming-forum.com/47-c-la … 30c9c01d2ae.htm suggests stack should be 4K by default.

I just tried to skip the test where it crashes (PCI2.0 Check) by pressing n ... and it passed.

Great, so that means that only accessing the PCI BIOS functions is crashing, and the other bits are ok.

clb, when SNOOP goes into 80x50 I cannot see first line(s) of the text from it.
1. Why not use this mode of operation: SNOOP.EXE > SNOOP.TXT. If you use printf() to stdout this should work.
2. Use a command line key to force set of 80x50 before log creation process otherways stay into 80x25.
3. Some notes: on one card I get 17 lines with video modes and PCI vendor id could fit in 1 line.

b_w wrote on 2023-08-26, 05:08:

clb, when SNOOP goes into 80x50 I cannot see first line(s) of the text from it.

That is curious. It would be nice to see a video or a screenshot of how that looks like in action. When switching from 80x25 to 80x50, there is no practical mode change, it is just changing the active font and its height. So active screen contents should not be changed. The first line going missing sounds like some other issue that I have. (Maybe I am letting the text screen scroll one line too much and that causes the first line to disappear?)

b_w wrote on 2023-08-26, 05:08:

1. Why not use this mode of operation: SNOOP.EXE > SNOOP.TXT. If you use printf() to stdout this should work.

If printing is done with printf, then that works. Unfortunately I was unable to use printf() because of this Borland Turbo C++ bug: https://forum.vcfed.org/index.php?threads/pro … -c-3-0.1244275/ and because it did not support color printing. With "logfile" I want to have a mechanism where I can dump much more verbose output to file than what would be displayable on screen.

I'll see if I can make my own Printf() support command line ">" redirection.

b_w wrote on 2023-08-26, 05:08:

2. Use a command line key to force set of 80x50 before log creation process otherways stay into 80x25.

I think the root issue for the missing first line should not be the transition from 80x25 to 80x50, so the timing of transitioning to that mode earlier is not expected to help with the missing line. I'll check different cards to see how it behaves.

b_w wrote on 2023-08-26, 05:08:

3. Some notes: on one card I get 17 lines with video modes and PCI vendor id could fit in 1 line.

Did you intend to write "... and PCI vendor id couldn't fit in 1 line"? Or maybe I am confusing something here.

Now I think I understand. A print is wrapping around the screen width, causing an extra line to be inserted, and as result the outputted printed screen height count is miscalculated. Fixed that issue, new build in the GitHub URL.

v.Aug 27 2023:
- improved CRT Terminator mode scanning, and added primitive save/load long scan results to disk
- fixed Printf() wrapping text beyond screen width
- improved Headland VGA adapter detection

I am experimenting with an idea of using CRT Terminator to scan all the CGA, EGA, VGA and SVGA video modes space to also print out what kind of video modes are provided there. Looks something like shown in the attachment. Without a CRT Terminator installed, this (S)VGA mode matrix will not be present in the log.

Not sure if that is the final form of visualization, or how to make it view best. Tried printing all the SVGA + VESA modes in one big chart, but that looked messy, and felt like it lost something in the presentation.

Last version of SNOOP.EXE doesn't work with my s7 motherboard's SiS 5597/8 integrated video. Just blanks the screen and there's no more response (Alt-Ctrl-Del doesn't work).

HSHIFT.EXE works fine without error and no jittering -filly straight line from bottom to top of the screen.

Hey, thanks for the report!

Does running SNOOP DEBUG LOGFILE give any hints as to what is the last thing that passes before the crash?

clb wrote on 2023-09-24, 16:27:

Does running SNOOP DEBUG LOGFILE give any hints as to what is the last thing that passes before the crash?

"SNOOP DEBUG LOGFILE" produces empty zero-length logfile, but blackens screen and hangs on "pci-snoop" test.

I have a UMC 85C418F-GP display adapter with 12 ram chips pictured here: Re: UMC UM85C418F RAM - 2MB possible + desirable?

I wanted to find out if it really thinks it has 1.5MB ram.

"SNOOP DEBUG LOGFILE" produces empty zero-length logfile, but blackens screen and hangs after the XGA bios detection, regardless of choosing Y or N at the prompt.

I'm happy to run any new code that you are willing to whip up.

douglar wrote on 2024-01-21, 21:14:

I have a UMC 85C418F-GP display adapter with 12 ram chips pictured here: Re: UMC UM85C418F RAM - 2MB possible + desirable? […]
Show full quote

I have a UMC 85C418F-GP display adapter with 12 ram chips pictured here: Re: UMC UM85C418F RAM - 2MB possible + desirable?

I wanted to find out if it really thinks it has 1.5MB ram.

"SNOOP DEBUG LOGFILE" produces empty zero-length logfile, but blackens screen and hangs after the XGA bios detection, regardless of choosing Y or N at the prompt.

I'm happy to run any new code that you are willing to whip up.

Hey, thanks for giving SNOOP at test douglar.

I uploaded a new version of SNOOP now that adds more fine-grained debug checks when running with "SNOOP DEBUG", and also added two more command line options "nopcitest" and "novgatest" that can be used to exclude some tests.

Hopefully this should give a better clue when running "SNOOP DEBUG" for which step the execution would be hanging.

SNOOP has gained so many checks that managing all of them is a bit overwhelming.. I'll need some kind of a better system to scale more tests into the harness in the future.

analog_programmer wrote on 2023-09-26, 05:45:

clb wrote on 2023-09-24, 16:27:

Does running SNOOP DEBUG LOGFILE give any hints as to what is the last thing that passes before the crash?

"SNOOP DEBUG LOGFILE" produces empty zero-length logfile, but blackens screen and hangs on "pci-snoop" test.

Ops, missed this from before.

I think that the crash here might be due to distinct "PCI configuration access space" mechanisms used on different PC motherboards (https://wiki.osdev.org/PCI#Configuration_Space ). SNOOP now only implements one that I know that is possible to do from a real-mode Borland C++ compiler, and that might not be compatible.

The new "SNOOP nopcitest" option allows skipping the PCI part of the test, that should hopefully get past the crashing part for now, until I figure how to do the other tests from Borland code. (or migrate to a 32-bit version e.g. with DJGPP or similar)

clb wrote on 2024-01-21, 22:16:

The new "SNOOP nopcitest" option allows skipping the PCI part of the test, that should hopefully get past the crashing part for now, until I figure how to do the other tests from Borland code. (or migrate to a 32-bit version e.g. with DJGPP or similar)

Curiously, it is the 16bit -data-decode test that I have to skip.

1[vertical-retrace] Before test start, enabled hardware interrupts:
2[vertical-retrace] IRQ0 IRQ1 IRQ2 IRQ6 IRQ8 IRQ9 IRQ13 IRQ14 
3[vertical-retrace] Prev IRQ2 handler: F000h:EF5Ah
4[vertical-retrace] Vertical retrace interrupts are already enabled before test start.
5[vertical-retrace] Saw vertical retrace interrupt fire 0 times.
6[vertical-retrace] Saw 3C2h/80h vret status bit high 0 times and low 0 times.
7[XGA] Not detected.
8[PCI2.0-check] INT 1Ah/AX=B101h check failed: BIOS is not PCI 2.0 compatible. Error code: B1h
9[vgapalettesnow]   CRT Terminator: [vgapalettesnow] $8Not Detected.[vgapalettesnow] $8SNOOP v.Jan 21 2024.$7
10[Cirrus] 3C4h/06h contains 0h, not a Cirrus
11[S3] 3D4h/47h is not writable. Not a S3 card.
12[Tseng] Port 3D4h:36h is read-only even after unlocking Tseng KEY register. Cannot be a Tseng card.
13[Trident] 3C4h/0Eh is not magic Trident-bit-flipping register.
14[Trident] SRE: 0h, SRE read again: 0h, chip_version: 0h. Not a Trident
15[Paradise/WDC] PR5 is not writable, not a Paradise/WDC card.
16[ATI] VBIOS does not contain magic number. Cannot be an ATI card.
17[Oak] String "OAK TECHNOLOGY" not found in VBIOS.
18[Video7] "Video Seven" not in VBIOS, not a Video 7 card.
19[Ahead] Vbios does not have "AHEAD", cannot be an Ahead card.
20[Genoa] No "GENOA" in VBIOS, not a Genoa card.
21[Chips] INT10/AX=0x5F00 not supported (returned AX=5F00h,BX=0h
22[vbios]       Video BIOS: [vbios] $BC0000h-C5FFFh [vbios] (24 KB)[vbios] $7VBIOS CRC32: $BF2295440h$7
23[vbios] $7[vbios]      Option ROMs: [vbios] $3C6800h-C7FFFh [vbios] (6 KB) [vbios] $3C8000h-CBFFFh [vbios] (16 KB) [vbios] $7[vbios] 
24[DCC]    Display (DCC): [DCC] $308h$7 - VGA on color analog display
25[DCC]     Adapter Caps:[DCC] $8[DCC]  [ ] IRQ2[DCC] $8[DCC]  [ ] lp-rng[DCC] $8[DCC]  [ ] XGA[DCC] $7
26[VESA]             VESA: [VESA] Not supported.
27[VESA] $8Not supported.$7
28[VESA] 
29$EThis system does not support fast $6rep outsb/insb$E asm instruction
30[VESA] sequences to program the VGA palette. Palette animation performance is slower.$7
31[VESA] 
32[VESA] $EHorizontal Pixel Shift Count register is latched in nonstandard manner, at
33[VESA] $6start of vertical retrace$E. Expected it to be latched at end of v.retrace.$7
34[VESA] $EDisplay Start Address register is latched in nonstandard manner, at
35[VESA] $6end of vertical retrace$E. Expected it to be latched at start of v.retrace.$7
36[VESA] 
37$EVGA card is fast enough to do more than ten (16) VGA Status port reads in one
38[VESA] hblank, and scroll register latching is not synchronized. Keen 4-6 games may
39[VESA] stutter even with the Fix Jerky Motion setting. Use a community patch.$7

Looking through the BIOS, I see the string "TEST ROM FOR UM82C418"

That could be a good test for this chip.