Confirmed, this does not solve the FDD issue, however `LOWDMA` from `UMBPCI` does quite nicely

gnif wrote on 2025-09-25, 05:48:

I have been trying on and off for the last few years to get this device to function when the packet driver is loaded in the UMB […]
Show full quote

I have been trying on and off for the last few years to get this device to function when the packet driver is loaded in the UMB when using URAM+UMB.

The problem is well documented that when UMB is used, it breaks DMA Bus Mastering which results in devices like this NIC from failing to function (The packet driver loads, but it wont transmit or receive any data).

Well today I finally solved it!

See: https://bitsavers.org/components/sis/SiS_85C4 … -497_199507.pdf
Page 122 in the PDF, or 120 as numbered.
Specifically register 0x44-0x45 - Shadow Configure
Bit 10 - PCI, ISA Master Access Shadow RAM Area Enable

Thanks for sharing that hint. I highlighted the important information that this post only applies if you use shadow RAM as UMB, and not if you use EMM386 to provide UMBs.To me, it sounds like it would be nice if URAM would automatically set that bit if you use it on an SIS 496 chipset. On the other hand, it seems the author of URAM deems this out of scope, by just explaining that DMA into URAM-provided UMBs does not work.

gnif wrote on 2025-09-25, 06:13:

Confirmed, this does not solve the FDD issue, however `LOWDMA` from `UMBPCI` does quite nicely

That's surprising for me, but thanks for testing and reporting. The data sheet of the SiS 496 contains the following snippet

SiS 496 datasheet wrote:

PCI master, ISA master and DMA is not permitted to access 0C0000h-0FFFFFh unless the bit
10 of register 44-45h is enabled. Once enabled, the read enable, write protect settings in the
bits[8:9] of register 44-45h still control the read/write attribute of that area.

While it explicitly only mentions that DMA does not work by default, it very much sounds like that bit is supposed to not only make PCI masters and ISA masters work, but it should also make ISA DMA work as well, so floppy access would be fiexd as well.

gnif wrote on 2025-09-25, 05:48:

There is also a nice performance boost (+10fps in doom timedemo for me) to be had by enabling caching of the shadow ram regions […]
Show full quote

There is also a nice performance boost (+10fps in doom timedemo for me) to be had by enabling caching of the shadow ram regions (some experimentation here is still needed, this might cause undesirable behaviour):

Copy code to clipboard

1mcsis496 w46h 8=1 9=1 10=1 11=1 12=1 13=1 14=1 15=1 16=1

I think that doesn't do what you expect it to do. According to the data sheet, the shadow ram cacheable bits are in the byte at 46h, located in the bits 0 to 7. Because x86 is a little-endian architecture, these bits keep located at 0 to 7 if you perform a word access. The bits 8 to 15 (as a word does not have bit 16 if you start counting at 0) are in fact the bits of register 47h, so instead of enabling cache on the UMB (which might indeed be a good idea if the BIOS didn't already do so with "Shadow Cacheable: Enabled"), this command actually sets all the bits in register 47h. Possibly bit 1 is the important bit: "CPU Memory Access to A0000h ~ AFFFFh forward to", which is "PCI only" if you set it, but "PCI+ISA" if it is cleared. If you BIOS doesn't set this bit if a PCI graphics card is detected (or if DOOM uses the 128K VGA memory map, and the B0000h ~ BFFFFh bit is not set because the BIOS wants to support PCI VGA + ISA MDA), this will explain a big speed-up on video memory access.

I don't expect that "shadow RAM cacheable" should make a difference that big, especially compared to running Doom without UMBs at all, because in either case, Doom is running fully in cached memory. On the other hand, if Doom uses the UMBs provided by URAM.SYS, it may slow down significantly if some core code or data of Doom happens to be located in uncacheable UMBs.

mkarcher wrote on 2025-09-25, 06:32:

gnif wrote on 2025-09-25, 05:48:

There is also a nice performance boost (+10fps in doom timedemo for me) to be had by enabling caching of the shadow ram regions […]
Show full quote

There is also a nice performance boost (+10fps in doom timedemo for me) to be had by enabling caching of the shadow ram regions (some experimentation here is still needed, this might cause undesirable behaviour):

Copy code to clipboard

1mcsis496 w46h 8=1 9=1 10=1 11=1 12=1 13=1 14=1 15=1 16=1

I think that doesn't do what you expect it to do. According to the data sheet, the shadow ram cacheable bits are in the byte at 46h, located in the bits 0 to 7. Because x86 is a little-endian architecture, these bits keep located at 0 to 7 if you perform a word access. The bits 8 to 15 (as a word does not have bit 16 if you start counting at 0) are in fact the bits of register 47h, so instead of enabling cache on the UMB (which might indeed be a good idea if the BIOS didn't already do so with "Shadow Cacheable: Enabled"), this command actually sets all the bits in register 47h. Possibly bit 1 is the important bit: "CPU Memory Access to A0000h ~ AFFFFh forward to", which is "PCI only" if you set it, but "PCI+ISA" if it is cleared. If you BIOS doesn't set this bit if a PCI graphics card is detected (or if DOOM uses the 128K VGA memory map, and the B0000h ~ BFFFFh bit is not set because the BIOS wants to support PCI VGA + ISA MDA), this will explain a big speed-up on video memory access.

I don't expect that "shadow RAM cacheable" should make a difference that big, especially compared to running Doom without UMBs at all, because in either case, Doom is running fully in cached memory. On the other hand, if Doom uses the UMBs provided by URAM.SYS, it may slow down significantly if some core code or data of Doom happens to be located in uncacheable UMBs.

Aha, that makes more sense, I was a bit confused there 😀
I dumped the default value for 0x47 which for mine only has bit 1 and 2 on. I will do some testing to see what exactly improved the perf, my guess would be bit 4

I am using a ET6000 (PCI) device, enabling BIT1 improves the performance here, the bios clearly should have been setting this.