What exactly does lar do?

1lar  ebx,bx                                            EAX:0000B101 EBX:00000168
2bt   ebx,16                                            EAX:0000B101 EBX:00CF9200 ECX:0000C000 EDX:00000A3C ESI:00000002 EDI:00000015 EBP:001FB082 ESP:001FB07C DS:0098 ES:0168 FS:0000 GS:0020 SS:0168 CF:0 ZF:1 SF:0 OF:0 AF:1 PF:0 IF:0
3
4jc   00000590 ($+4)             (down)                 EAX:0000B101 EBX:00CF9200 ECX:0000C000 EDX:00000A3C ESI:00000002 EDI:00000015 EBP:001FB082 ESP:001FB07C DS:0098 ES:0168 FS:0000 GS:0020 SS:0168 CF:1 ZF:1 SF:0 OF:0 AF:1 PF:0 IF:0

The docs say Lar is supposed to return an access mask for a segment.
bit 16 is undefined.

Thanks for your help BTW.

Perhaps 16 is hexadecimal? If so, bit 22 (decimal) refers to the D/B (Default operand size/Big) bit from the segment descriptor: 0=16-bit, 1=32-bit, and in your example the bit is set.

AArgh! I'm going nuts here. You're absolutely right.

Sorry about this but:

1mov  eax,[edx+0010]             ds:[001D4642]=00000001 EAX:001D4632 EBX:001FB1CC ECX:00000000 EDX:001D4632 
2
3...
4
5mov  ebx,eax                                           EAX:00000001 EBX:001FB1CC 
6mov  al,00                                             EAX:00000001 EBX:00000001 
7mov  ah,44                                             EAX:00000000 EBX:00000001 
8int  21                                                EAX:00004400 EBX:00000001 

Function 44h- Device driver control (IOCTL)

EBX is supposed to be a handle. How does one set about getting a device handle and how can I identify the device?

[EDIT] AL=0:
IOCTL,0 Get Device Information

Also looking through the trace, I can't find any writes to 0x001D4642 where the device handle comes from.

I don't even know if this is relevant to Speedy3D or whether this is keyboard related.

[EDIT2] I should really think a bit before posting. There're references to EDX:001D4632 all over the dump.

Presumably there is DPMI or some DOS extender that switches to real mode for calling DOS functions.

In any case, you get a handle for a device (probably a character device) by opening (INT 21/3D) its device name as if it were a file name.

Note that support for loaded device drivers (e.g., DEVICE=MYDEVICE.SYS in CONFIG.SYS) is limited in DOSBox's emulated DOS, so you may need to boot real DOS to work with related functions.

Thank ripsaw. I'll plough through the rest of the dump. It's slow going.

Ripsaw, where's the default handler for Int_1A.

I think this is a Rendition specific call with

1AX=0xB101, 
2Bx=0x0000
3CX=C000
4DX=0A3C (entry point for a specific V1000 board).
5Int 1A

On an actual Rendition based system (with a V2200) what comes back is this:

1Int 1Ah on exit (2) AX 0011, BX 0210, CX C001, DX 4350, ES 1B66, DI 0012, DS 1BCE, SI 0000, SP 0F6E

ES, DI, DS, SI and SP are unmodified.

The handler is in bios.cpp, but that call appears to be for PCI BIOS: https://www.delorie.com/djgpp/doc/rbinter/ix/1A/B1.html

Thanks!

Another quick question about dosbox:

if I wanted to set the carry flag on return from an int 10 call setting

1reg_flags |=0x01;

doesn't cut it because of the iret.

This doesn't seem to work either:

1unsigned short flags = phys_readw(PhysMake(SegValue(ss), reg_sp - 4));
2phys_writew(PhysMake(SegValue(ss), reg_sp - 4), flags |=0x00000001);

Also I've seen weird things like mismatched int calls. There appear to be more irets than int's.

[EDIT] It also looks like the entire app runs as an int.

You seem to have the stack order backwards: a push subtracts from SP, a pop adds to SP, so the flags are at SP+4 for code inside an interrupt handler.

Anyway, in cpu/callback.cpp are a few functions: CALLBACK_SZF, CALLBACK_SCF, and CALLBACK_SIF for setting the Z, C, and I flags on the return stack. You can find many examples of their use throughout interrupt handler callback code.

BTW, you only need to use the phys_* functions for writing to ROM areas. For RAM, use mem_* and real_*, with the latter preferred for stack operations because it handles segment wrap.

Thanks for that.

I thought the iret instruction pops 3 16 bit values in real mode so I used sp-4, so that after the iret eflags has sp-4.

[EDIT] Yeah I messed up.

How do I capture IO port reads and writes with DosBox?

Specifically the instructions in and out, not sure whether there're any others?

And capture memory reads and writes (to specific addresses)?

I worked out the port io using handlers, but memory access still eludes me.

This doesn't seem to have an effect:

1MEM_SetPageHandler(renditionMemPageMin, renditionMemPageMax - renditionMemPageMin + 1, &renditionPageHandler);

Are any of the INT 10h calls mouse related?

13CC:000003F9  mov  word [bp-02],0033          ss:[0FA6]=0010         E
23CC:000003FE  mov  ax,[bp+06]                 ss:[0FAE]=847B         E
33CC:00000401  mov  bx,[bp+08]                 ss:[0FB0]=0000         E
43CC:00000404  mov  cx,[bp+0A]                 ss:[0FB2]=209E         E
53CC:00000407  mov  dx,[bp+0C]                 ss:[0FB4]=0000         E
63CC:0000040A  mov  es,[bp+0E]                 ss:[0FB6]=0ABE         E
73CC:0000040D  mov  di,[bp+10]                 ss:[0FB8]=000C         E
83CC:00000410  int  33                                                E
9C7FF:00000010  inc  word [bx]                  ds:[0000]=062D         
10C7FF:00000012  callback 001F  (MouseBD)                               
11C7FF:00000016  retf 0008

Where is bx being incremented?

13CC:00000410  int  33                                                EAX:0000847B EBX:00000000 EC
2C7FF:00000010  inc  word [bx]                  ds:[0000]=062D         EAX:0000847B EBX:00000000 E

The C800-CFFF segment range is implemented as RAM for the emulated DOS private area. The internal mouse driver INT 33h handler is there and can be corrupted by errant programs. At C7FF:0010 an EB (short jump) appears to have been somehow changed to FF in your example.

Thanks!