Double post, please delete me.

Unreal, UT99, Diablo II, NFS5 and Undying are pretty stable and fast now. So the next release will also contain a Glide3 dll. Also I fixed some issues with the second TMU and the texture palettes. But as I stated I want to improve overall compatibility further, so it will take a bit for the next release. Quake III is another story though, it is completely broken. But I don't see a point to fix that, since it isn't a Glide game and the visual experience is always worse, due to the 256x256 pixel texture limit. Maybe someone can convince me?

myne wrote on Yesterday, 14:41:

ElTentakel this might be of some interest to you. https://github.com/nand2mario/zSST linked in the post I linked a few pages ag […]
Show full quote

ElTentakel this might be of some interest to you.
https://github.com/nand2mario/zSST linked in the post I linked a few pages ago.

Well, I ran it through verilator.
https://verilator.org/
After more than a few fails, I got source with the following command:

Copy code to clipboard

1..\verilator -Wno-WIDTHEXPAND -Wno-WIDTHtrunc -cc .\sst1_pkg.sv .\generated\sst1_regs_pkg.sv .\generated\sst1_tmu_tables_pkg.sv .\frontend\sst1_addr_decode.sv .\frontend\sst1_float_to_fixed.sv .\frontend\sst1_pci_fifo.sv .\frontend\sst1_regfile.sv .\frontend\sst1_frontend.sv .\tmu\sst1_texture_layout.sv .\tmu\sst1_tmu_front_staged.sv .\tmu\sst1_texture_cache_ram.sv .\tmu\sst1_texture_cache.sv .\tmu\sst1_texture_address.sv .\tmu\sst1_texel_decode.sv .\tmu\sst1_texture_combine.sv .\tmu\sst1_tmu.sv .\fbi\sst1_pixel_pipeline.sv .\fbi\sst1_fb_write_combine.sv .\fbi\sst1_fb_read_cache.sv .\fbi\sst1_fbi.sv .\video\sst1_video_control.sv .\sst1_perf_counters.sv .\sst1_core.sv .\sst1_device.sv

-Wno-WIDTHEXPAND -Wno-WIDTHtrunc ignore word size changes. -cc outputs to c++

I will have a look at it. I also have ordered a VGA->HDMI converter to be able to compare the visual outcome with one of my voodoo2.

Kahenraz wrote on Yesterday, 17:06:

Am I reading this right? It implements native multi-core support in pure DOS, as long as the system is real-mode?

Yes, sound insane, but one gets used to it 😁. The hardest part is to get the memory management working, so you can safely access the memory of other cores without corruption due to cache or paging. Especially in Ring 3 things get very tricky. In Windows a temporary Ring 0 Call gate is used inside the separate VXD driver. Maybe it is possible to adapt that temporary call gate to DOS. This would massively improve compatibility with SBEMU and would fix that MTRRs are not working in that scenario. I really want that for Redguard, since this is the most challenging DOS game I know performance wise.

ElTentakel wrote on Today, 14:25:

How much RAM do you have? I can not get VDPMI+Glidulator running on my Hasswell machine with 32GB of RAM.

I have 8GB, did you used the latest version from last crazii sbemu thread? I don't use other XMM and VDPMI provides then cca 380MB of XMS. I used default vdpmi.cfg