Two files are logged simultaneously:
cpu.log contains the locations jumped to at each INT and IRET, as well as the source location of the INT instructions(if any, depending on the errorcode(-1 for normal INT instructions, othe values for Protected mode exceptions, it's the error code pushed on the stack if not -1).

debugger.log contains the full instruction log, which includes a copy of cpu.log interleaved at the points they occur(before the originated instruction, except when caused by fetching instruction errors(e.g. a exception raised by the opcode fetching routine, like instructions fetching out of CS limit bounds)). It contains the writes and reads from memory before every instruction, as well as the instruction executed and the current register states before that instruction is executed. Since I don't know which point the faults is caused by, I've simply made a full log(to have all neccesary information included). Although I could leave the register data out, this would omit nessecary information(e.g. when multiple registers are used to index into memory(e.g. [BX+SI] operands). I think you might find the problem by using the cpu.log file to find the first error location, then finding that entry in the full debugger.log file and backtracing the error through backward search operations on that piece of memory and related parts.

The cpu log does not seem to have proper log. It only shows INT 6? Unless I read it wrong. In the debug.log I see towards the end INT 1C

100:09:05:92.00704: Interrupt 06=F000:00001BD0@0B61:11A8(FE); ERRORCODE: -1
200:09:05:92.02368: IRET to 0B61:11A8
300:09:05:92.03008: Interrupt 06=F000:00001BD0@0B61:11A8(FE); ERRORCODE: -1
400:09:05:92.04608: IRET to 0B61:11A8
500:09:05:92.05120: Interrupt 06=F000:00001BD0@0B61:11A8(FE); ERRORCODE: -1

100:08:38:35.08720: F000:4BD5 (CD1C)INT 1C

Actually I just realised something, you are somewhere in timing interrupt, not even in some driver code. I am not sure why that is.

But anyway, the best log you can get would be something like this (instructions+IP) (the number after ; is cycles, that is from my emulator, you can ignore that):

1fe0bf b0 MOV AL, 0x1; 4
2fe0c0 ee OUT DX, AL; 6
3fe0c3 b8 MOV AX, 0x40; 6
4fe0c5 8e MOV DS, AX; 4
5fe0c9 8b MOV SI, [0xfe0c9]; 19
6fe0cb 33 XOR AX, AX; 4
7fe0cd 8b MOV BP, AX; 4
8fe0cf 8b MOV BX, AX; 4
9fe0d2 ba MOV DX, 0x55aa; 5
10fe0d3 fc CLD ; 3
11fe0d5 33 XOR DI, DI; 4

I've made a new log, although this time of a hard disk with OAKCDROM.SYS on it instead(probably an older disk image I used). Although it might be the exact same problem causing problems:
https://www.dropbox.com/s/ridqx9ldbq8mehs/deb … 4_1859.zip?dl=0

It still has the floppy disk logs, due to the debugger being enabled, but it now omits register state and misc. state(VGA CRT information and PIC state).

FYI,

the NEC_IDE.SYS (OAK Tech OTI-011Rev D011V111) cdrom driver found on the Microsoft Windows Boot Disk 95 OSR2.x
https://winworldpc.com/product/microsoft-wind … t-disk/95-osr2x
or
just this plain zip file
http://ftp.mpoli.fi/hardware/CDROM/NEC/NEC_IDE.ZIP (OTI-011 Rev D011V110)
and
http://ftp.mpoli.fi/hardware/CDROM/NEC/NEC4XIDE.ZIP (OTI-011 Rev A1.2_K12B)
and
http://ftp.mpoli.fi/hardware/CDROM/NEC/NEC8XIDE.ZIP (OTI-910 D910V310.CHANGER-14B 2.5)

all work on a real 80286

Well, VIDE-CDD.SYS runs fine on my 286 emulated machine(IBM AT within UniPCemu). That's better than OAKCDROM.SYS, which will hang because it's using 80386+ instructions.

true, the oakcdrom.sys (OTI-91X ATAPI CD-ROM device driver, Rev D91XV352) from the w98 bootfloppy hangs on my 286.

All those NEC ones I've listed all work on a 286.

Can EMU386 solve the issue with oakcdrom?
I mean, it was made for such situations, according to its readme..

Jo22 wrote on 2021-12-20, 11:33:

Can EMU386 solve the issue with oakcdrom?
I mean, it was made for such situations, according to its readme..

perhaps but why bother? it will certainly be slower than using one of the provided drivers like VIDE-CDD that works natively on a 286

maxtherabbit wrote on 2021-12-20, 15:01:

Jo22 wrote on 2021-12-20, 11:33:

Can EMU386 solve the issue with oakcdrom?
I mean, it was made for such situations, according to its readme..

perhaps but why bother? it will certainly be slower than using one of the provided drivers like VIDE-CDD that works natively on a 286

Is that certain ? oakcdrom has more features/knows faster transfer modes than vide-cdd, doesn't it ?
Emulating just a few 386 opcodes isn't that hard for a 286 CPU, I suppose. 😀

Why bother emulating when the nec cdrom drivers, which are just slightly older version of the oakcdrom driver work fine on a 286 ?

also... faster transfer modes... on a 286... in dos. 😒

I use VIDE-CDD on all my retro systems, 286 and 386+ alike because of its small memory footprint. Can't say I've ever done a direct speed comparison to OAK but I'm also not sure if I care all that much. VIDE performance is more than adequate

Why are you guys so negative ? You make me feel as if I was asking something that's a sacrilege. I don't get it. (´･_･`)
Forums used to be a platform for discussing all sorts of things. And this is a harmless afair. Why we don't just try both and find out ?

jo22
why don't you try both and find out, and please stop projecting your feelings unto others.
I will not reply to anything else coming from you that is not related to the subject matter.

Okay. I get it. I'm silent now. However, I still don't understand that atmosphere.
Years ago, people at Vogons usually would have had replied with "thanks for the tip", "interesting idea" etc..
To my defense, I merely came here to help. I haven't posted at Vogons for a longer time, also. Never mind.

Would speed really be that much of an issue? Since the main bottleneck would be the CD-ROM drive itself (seeking and reading the data off the disc)?

Jo22 wrote on 2021-12-20, 17:34:

Okay. I get it. I'm silent now. However, I still don't understand that atmosphere.
Years ago, people at Vogons usually would have had replied with "thanks for the tip", "interesting idea" etc..
To my defense, I merely came here to help. I haven't posted at Vogons for a longer time, also. Never mind.

It is sad indeed to see some newcomers bringing down this forum to the level of other forums infested with millenial-mindset.

Coming back to the topic, those people who have problems with OAK or VIDE should use QCDROM.SYS. It takes up less memory and it's very compatible, compared to even OAK or VIDE.

QCDROM.SYS doesn't work on a 286.

Jo22 wrote on 2021-12-20, 17:34:

Okay. I get it. I'm silent now. However, I still don't understand that atmosphere.
Years ago, people at Vogons usually would have had replied with "thanks for the tip", "interesting idea" etc..
To my defense, I merely came here to help. I haven't posted at Vogons for a longer time, also. Never mind.

For what it's worth, I think you're one of the most wholesome regulars here on Vogons, and I appreciate your enthusiasm and friendliness, Jo22. 🤗

And it's honestly not a crazy question to wonder whether there is a noticeable performance difference between the two ATAPI CD-ROM drivers.

One would have to go through the trouble of benchmarking it, both on a 286 running emu386 and on a 386 system.

Personally, I'm more interested in finally seeing ATAPI compatibility being added to the XTIDE BIOS. But that's a different matter, of course.

Jeez all we said was we're not particularly interested in testing it out and y'all are acting like we told the dude to jump off a bridge. Grow up