How did you come up with this 0x6001 number? Seems like an unlikely address for a PCI memory region, considering it overlaps with conventional RAM.

PCI stuff usually gets mapped into the adapter area or after 2GB. Using 'unreal mode' might be an easier way to access high addresses, rather than having to go through a DOS extender.

bit 0 defines if the BAR is for mapped memory (value = 0) or a mapped I/O port (value = 1). So what you seem to have there is an IO port range at 0x6000. Try accessing it using IN/OUT.

jmarsh wrote on 2024-08-31, 13:15:

bit 0 defines if the BAR is for mapped memory (value = 0) or a mapped I/O port (value = 1). So what you seem to have there is an IO port range at 0x6000. Try accessing it using IN/OUT.

Oh indeed, that was the case!

I was able to access the data in the I/O port with inport() and outport().

However, now I'm met with a next issue. It seems that the PCI device in question (which is a Diamond Multimedia Rendition Verite V2200 card) either decodes 8-bit and 16-bit port writes incorrectly.

I find that

1outport(0x60C2, inport(0x60C2));

"works" in the sense that it doesn't do anything (as one might expect from a well-defined hardware implementation of registers), but

1outportb(0x60C2, inportb(0x60C2));

causes the high byte at 0x60C3 to be cleared.

Well, no big deal, I can just not do byte reads and writes.

But then I realize that 16-bit aligned reads and writes exhibit from the same problem. That is, if I do

1outport(0x60C2, inport(0x60C2));

it actually clears the I/O data at 0x60C0 and 0x60C1. And if I do

1outport(0x60C0, inport(0x60C0));

it seems to behave like it clears the I/O register data at 0x60C2 and 0x60C3. I infer that I need to do a single atomic 32-bit port write. Any chance there might be a way to hack that kind of thing into Borland C++ 3.0? I recall there were some asm prefix hacks to do 32-bit addressing or similar, or maybe some inline asm data bytes mechanism?

I'm not familiar with that compiler so I can't say. All I know is that adding an operand prefix (byte 0x66) to the IN/OUT opcode will make it perform 32-bit access (using EAX instead of just AX) if the current code segment size is 16 bits.

Thanks jmarsh, you're so awesomely helpful, as always!

I wrote up a gist code example to do 32-bit I/O port accesses from Borland Turbo C++: https://gist.github.com/juj/84f6c680939d1da7686db890b69954a0

Even though I ended up not needing to do it, to answer my original question of "how to write to memory-mapped address space from DOS", I believe the scenario would be two-fold:

1) if the memory-mapped address space resides below the 1MB region, then one should be able to in Borland Turbo C++ just MK_FP(segment, offset) the 32-bit linear address given from PCI configuration register space and access it directly.
2) if the memory-mapped address space is above the 1MB region, then using protected mode compiler makes life easier. In DJGPP, I believe that this page https://www.delorie.com/djgpp/v2faq/faq18_7.html shows how to map the physical PCI memory BAR to the calling processes address space. Glad I didn't need to go down that route. Today at least.. maybe I'll run into this issue another day.

Nice. If you did need above-1MB memory access, I think a DOS extender really is the way to go, otherwise (unreal mode?), you'd produce a program that doesn't run under EMM386.
Any late DOS SVGA game that supported linear framebuffer would have to deal with this.

Over Thanksgiving weekend I dusted off Borland's Turbo C++ and took a stab at writing a program that can poke around Voodoo2's RAM chips. Inspired by the Witchery project but running on DOS directly. I managed to get up to the point where I can see how many Voodoo2 cards are installed and to get the BAR0 addresses for each ( checking with the output of MOJO to see that they match) . Where I am currently stuck is getting any attempt to actually write to this address to return anything other than `FFFFFFFF`.

Anyone who understands this better than I do have any ideas what I can try next?

https://gist.github.com/jasonsperske/35606048 … bc258f27e391957

I dug deeper and found a few obviously wrong things, my FBI_INIT* address were all off (fixed from values) found in the voodoo2 spec PDF. I also found some code in the Base-Metal video (https://www.youtube.com/live/LDT6KlfOG2k?si=1 … 1dpzDPdk&t=3748) that shows a method of Blanking the Voodoo by writing the FBI_INIT0, 1 and 2 with some bitwise operators. I incorporated these changes into https://github.com/jasonsperske/witcheroo but I still feel like I am missing some obvious thing that is preventing my writes and reads to the Frame Buffer.

You may find some useful code in mkarcher's dostools: https://github.com/karcherm/dostools

sndtst wrote on 2024-12-03, 07:41:

... but I still feel like I am missing some obvious thing that is preventing my writes and reads to the Frame Buffer.

Looks like you are confusing I/O space and memory space.
You figured out how to make 32 bit accesses for I/O space (outportl and inportl), but for linear frame buffer you need 32 bit access to memory space.

I like the idea of using DOS for poking video cards, using Linux for such simple task looks like overcomplication.
I'm trying to figure out how to make similar thing right now, and it looks like links to djgpp/dpmi stuff above point to the right direction.

I wrote some protected mode C code a few years ago to write to the linear framebuffer on the NEC PC-98 series of computers, whilst the hardware is different to IBM PC compatibles, the code is more or less identical.

Have a look here: https://www.target-earth.net/wiki/doku.php?id … r_to_dos_memory

It's targetting GCC/DJGPP/DPMI, so should be pretty much drag and drop for DOS/IBM PC - just changing a few defines for framebuffer location. You *can* then poke pixels directly in the VGA framebuffer, but it's probably best to doublebuffer between system ram and vram and pageflip when needed.

Of course you're going to have to find the linear framebuffer address first... and I guess that's a VGA-chip specific lookup; whereas on the PC-9821 it always lives in one of two locations (15-16MB, or up at 4095MB),

My video card, GeForce 3 Ti 500, has a straps register, located in MMIO space.
Card allows to override it, and this is what video BIOS is doing during card initialization.
I was able to read modified value of this register with AIDA64, but I wanted to know its original value.
To do this, register should be reset by writing zero to it and be read afterwards.

By combining code from @sndtst, @megatron-uk and official DJGPP documentation, I was able to write this simple program:

1#include <pc.h>
2#include <dpmi.h>
3#include <stdio.h>
4#include <stdint.h>
5#include <sys/farptr.h>
6
7int selector;
8
9uint8_t bus;
10uint8_t dev;
11uint8_t func = 0x00;
12
13uint32_t pci_config_read32(uint8_t offset)
14{
15  uint32_t address = 0x80000000 | bus << 16 | dev << 11 | func << 8 | offset;
16  outportl(0x0cf8, address);
17  return inportl(0x0cfc);
18}
19
20void pci_config_write32(uint8_t offset, uint32_t value)
21{
22  uint32_t address = 0x80000000 | bus << 16 | dev << 11 | func << 8 | offset;
23  outportl(0x0cf8, address);
24  outportl(0x0cfc, value);
25}
26
27bool find_video_card(uint32_t pci_id)
28{
29  for (bus = 0; bus < 255; bus++)
30    for (dev = 0; dev < 32; dev++)
31      if (pci_config_read32(0x00) == pci_id)
32        return true;
33  return false;
34}
35
36void initialize_mapping(uint32_t base, uint32_t size)
37{
38  __dpmi_meminfo mi;
39  mi.address = base;
40  mi.size = size;
41  __dpmi_physical_address_mapping(&mi);
42
43  selector = __dpmi_allocate_ldt_descriptors(1);
44  __dpmi_set_segment_base_address(selector, mi.address);
45  __dpmi_set_segment_limit(selector, mi.size - 1);
46}
47
48uint32_t register_read32(uint32_t address)
49{
50  return _farpeekl(selector, address);
51}
52
53void register_write32(uint32_t address, uint32_t value)
54{
55  return _farpokel(selector, address, value);
56}
57
58int main()
59{
60  printf("Searching for video card... ");

61  if (find_video_card(0x020210de))
62    printf("Found at %02d:%02d.%d\n", bus, dev, func);
63  else
64  {
65    printf("Not found, exiting\n");
66    return -1;
67  }
68
69  uint32_t bar0 = pci_config_read32(0x10);
70  uint32_t bar0_base = bar0 & 0xfffffff0;
71  pci_config_write32(0x10, 0xffffffff);
72  uint32_t bar0_size = ~(pci_config_read32(0x10) & 0xfffffff0) + 1;
73  pci_config_write32(0x10, bar0);
74
75  printf("BAR0 base: 0x%08x, size:0x%08x\n", bar0_base, bar0_size);
76
77  initialize_mapping(bar0_base, bar0_size);
78
79  printf("Card id: 0x%08x\n", register_read32(0x00000000));
80  printf("Overridden straps: 0x%08x\n", register_read32(0x00101000));
81  register_write32(0x00101000, 0x00000000);
82  printf("Original straps: 0x%08x\n", register_read32(0x00101000));
83  
84  return 0;
85}

Running it with real hardware revealed that BIOS didn't actually changed this register except for enabling override bit. I wonder why it was needed.

1Searching for video card... Found at 01:00.0
2BAR0 base: 0xd4000000, size:0x01000000
3Card id: 0x020200a5
4Overridden straps: 0xfff86c6b
5Original straps: 0x7ff86c6b