Breakthrough for the ao486 core announced - Cache

[Caldor]

Point taken.

As of dev tip right now, Norton 8 says overall performance (both CPU and disk) is at 486SX/33 levels, which feels about right to me having also tested (a whole bunch of) id software. If it doesn't improve any further at all, it's still a REMARKABLE effort and I'm getting serious waves of nostalgia from it. Unbelievable effort! Who'd have ever thought MiSTer representing so well at 90s PC gaming?

When you download the Cache31 or higher it comes with the bios files. The dev branch last I checked does not have the VESA bios file, only a VGA bios file. With Cache34, I am about to test that, but it might have an issue with the MiSTer file. If there is a problem with Cache34, it should using the MiSTer file from Cache33.

[ToothbrushThreepwood]

Point taken.

As of dev tip right now, Norton 8 says overall performance (both CPU and disk) is at 486SX/33 levels, which feels about right to me having also tested (a whole bunch of) id software. If it doesn't improve any further at all, it's still a REMARKABLE effort and I'm getting serious waves of nostalgia from it. Unbelievable effort! Who'd have ever thought MiSTer representing so well at 90s PC gaming?

Do you see much difference in in-game performance and Norton/benchmark scores with changing clock from 30 to 100?

[FPGAzumSpass]

You will often only see the difference if you do a reset after setting the clock speed and run the benchmark again.
If you switch at runtime, the time measurement is broken and results cannot be trusted.

[friendly.joe]

Hello and I wholeheartedly thank you for all the great efforts being made!

-----

From the cache 32 build, I noticed something seems to be another bug (or behavioral change in the core).

On Windows 95 RTM (w/o OSR), when you click "Display" applet in Control Panel,

Cache 31 and older: Works fine (it will display the display options)
Cache 32 and later: Does not work (it shows an error "An error occurred while Windows was working with the Control Panel file C:\WINDOWS\SYSTEM\DESK.CPL'."

If you could look into this issue, it will be greatly appreciated.
(I am suspecting this behavior is probably tied with the recent changes introduced in Cache 32 core)

Thank you.

[SavageX]

Just wanted to say how much I am in awe and admiration for the hard work done on the ao486 core. As far as I can tell, the original code base was partly autogenerated and isn't particularly easy to read - well, at least I find it hard to read, but then again my FPGA background is purely a hobbyist one.

I find it absolutely astonishing that you guys are not only able to identify the bottlenecks in the core (apparently the high-latency memory subsystem lead to pipeline stalls basically all the time) but also widen these bottlenecks (by basically a complete overhaul of the memory subsystem) without breaking things left and right.

One thing that stands out to me in the ao486 codebase is that it seems to favor long chains of conditionals over simple case statements. For instance, looking at the shifter code:

Code: Select all

assign e_shift_left_result =
        (e_shift_count == 5'd0)?  { cflag,  e_shift_left_input[63:32] } :
        (e_shift_count == 5'd1)?            e_shift_left_input[63:31] :
        (e_shift_count == 5'd2)?            e_shift_left_input[62:30] :
        (e_shift_count == 5'd3)?            e_shift_left_input[61:29] :
        (e_shift_count == 5'd4)?            e_shift_left_input[60:28] :
        (e_shift_count == 5'd5)?            e_shift_left_input[59:27] :
        (e_shift_count == 5'd6)?            e_shift_left_input[58:26] :
        (e_shift_count == 5'd7)?            e_shift_left_input[57:25] :
        (e_shift_count == 5'd8)?            e_shift_left_input[56:24] :
        (e_shift_count == 5'd9)?            e_shift_left_input[55:23] :
        (e_shift_count == 5'd10)?           e_shift_left_input[54:22] :
        (e_shift_count == 5'd11)?           e_shift_left_input[53:21] :
        (e_shift_count == 5'd12)?           e_shift_left_input[52:20] :
        (e_shift_count == 5'd13)?           e_shift_left_input[51:19] :
        (e_shift_count == 5'd14)?           e_shift_left_input[50:18] :
        (e_shift_count == 5'd15)?           e_shift_left_input[49:17] :
        (e_shift_count == 5'd16)?           e_shift_left_input[48:16] :
        (e_shift_count == 5'd17)?           e_shift_left_input[47:15] :
        (e_shift_count == 5'd18)?           e_shift_left_input[46:14] :
        (e_shift_count == 5'd19)?           e_shift_left_input[45:13] :
        (e_shift_count == 5'd20)?           e_shift_left_input[44:12] :
        (e_shift_count == 5'd21)?           e_shift_left_input[43:11] :
        (e_shift_count == 5'd22)?           e_shift_left_input[42:10] :
        (e_shift_count == 5'd23)?           e_shift_left_input[41:9] :
        (e_shift_count == 5'd24)?           e_shift_left_input[40:8] :
        (e_shift_count == 5'd25)?           e_shift_left_input[39:7] :
        (e_shift_count == 5'd26)?           e_shift_left_input[38:6] :
        (e_shift_count == 5'd27)?           e_shift_left_input[37:5] :
        (e_shift_count == 5'd28)?           e_shift_left_input[36:4] :
        (e_shift_count == 5'd29)?           e_shift_left_input[35:3] :
        (e_shift_count == 5'd30)?           e_shift_left_input[34:2] :
                                            e_shift_left_input[33:1];

Unless I miss something, I think a more straightforward way to accomplish the same would be

Code: Select all

    always @(*) begin
        case(e_shift_count)
            5'd0:   e_shift_left_result = { cflag,  e_shift_left_input[63:32] };
            5'd1:   e_shift_left_result = e_shift_left_input[63:31];
            5'd2:   e_shift_left_result = e_shift_left_input[62:30];
            5'd3:   e_shift_left_result = e_shift_left_input[61:29];
            5'd4:   e_shift_left_result = e_shift_left_input[60:28];
            5'd5:   e_shift_left_result = e_shift_left_input[59:27];
            5'd6:   e_shift_left_result = e_shift_left_input[58:26];
            5'd7:   e_shift_left_result = e_shift_left_input[57:25];
            5'd8:   e_shift_left_result = e_shift_left_input[56:24];
            5'd9:   e_shift_left_result = e_shift_left_input[55:23];
            5'd10:  e_shift_left_result = e_shift_left_input[54:22];
            5'd11:  e_shift_left_result = e_shift_left_input[53:21];
            5'd12:  e_shift_left_result = e_shift_left_input[52:20];
            5'd13:  e_shift_left_result = e_shift_left_input[51:19];
            5'd14:  e_shift_left_result = e_shift_left_input[50:18];
            5'd15:  e_shift_left_result = e_shift_left_input[49:17];
            5'd16:  e_shift_left_result = e_shift_left_input[48:16];
            5'd17:  e_shift_left_result = e_shift_left_input[47:15];
            5'd18:  e_shift_left_result = e_shift_left_input[46:14];
            5'd19:  e_shift_left_result = e_shift_left_input[45:13];
            5'd20:  e_shift_left_result = e_shift_left_input[44:12];
            5'd21:  e_shift_left_result = e_shift_left_input[43:11];
            5'd22:  e_shift_left_result = e_shift_left_input[42:10];
            5'd23:  e_shift_left_result = e_shift_left_input[41:9];
            5'd24:  e_shift_left_result = e_shift_left_input[40:8];
            5'd25:  e_shift_left_result = e_shift_left_input[39:7];
            5'd26:  e_shift_left_result = e_shift_left_input[38:6];
            5'd27:  e_shift_left_result = e_shift_left_input[37:5];
            5'd28:  e_shift_left_result = e_shift_left_input[36:4];
            5'd29:  e_shift_left_result = e_shift_left_input[35:3];
            5'd30:  e_shift_left_result = e_shift_left_input[34:2];
            5'd31:  e_shift_left_result = e_shift_left_input[33:1];
        endcase
    end

To compare these two constructs, I isolated them into their own modules (shifter_ternary and shifter_case - attached to this post) and ran them through the yosys open source synthesizer. Result for the original construct:

Code: Select all

=== shifter_ternary ===

   Number of wires:                385
   Number of wire bits:           2261
   Number of public wires:           4
   Number of public wire bits:     103
   Number of memories:               0
   Number of memory bits:            0
   Number of processes:              0
   Number of cells:                861
     cyclonev_lcell_comb           861

Result for the case-construct:

Code: Select all

=== shifter_case ===

   Number of wires:                194
   Number of wire bits:           1149
   Number of public wires:           4
   Number of public wire bits:     103
   Number of memories:               0
   Number of memory bits:            0
   Number of processes:              0
   Number of cells:                663
     cyclonev_lcell_comb           663

Is staring at the code and finding such points of possible optimization a way to generate useful contributions to your effort?

[NightShadowPT]

And it keeps on going... these improvements Have enabled the most amazing performance jump I’ve ever witnessed in any core. Just wow

EeU9nG4WkAIjGzC.png (72.74 KiB) Viewed 8555 times

[Caldor]

And it keeps on going... these improvements Have enabled the most amazing performance jump I’ve ever witnessed in any core. Just wow

Which core is this?

Oh, guess it must be cores

[Caldor]

Hello and I wholeheartedly thank you for all the great efforts being made!

-----

From the cache 32 build, I noticed something seems to be another bug (or behavioral change in the core).

On Windows 95 RTM (w/o OSR), when you click "Display" applet in Control Panel,

Cache 31 and older: Works fine (it will display the display options)
Cache 32 and later: Does not work (it shows an error "An error occurred while Windows was working with the Control Panel file C:\WINDOWS\SYSTEM\DESK.CPL'."

If you could look into this issue, it will be greatly appreciated.
(I am suspecting this behavior is probably tied with the recent changes introduced in Cache 32 core)

Thank you.

I have been testing Cache 34 running Windows 98 SE, and it seems to work for me. I have tried 640x480 with 16 colors and 800x600 with 16bit colors. The control panel and such works.

But I dont remember if I updated the MiSTer file or not.

[Caldor]

One thing that stands out to me in the ao486 codebase is that it seems to favor long chains of conditionals over simple case statements. For instance, looking at the shifter code:

......

Is staring at the code and finding such points of possible optimization a way to generate useful contributions to your effort?

I have not been coding the core myself, but from what I understand, and what I have read, a LOT of the AO486 code is auto-generated / converted from Bochs x86 code. The opensource x86 emulator.

So I am thinking there is pretty much without doubt such cases. I do not know if your code would be better, but there is just a lot of code to go over to fix this... also have no idea whether it really takes up more or loss logic space in the FPGA when its compiled and / or whether it would perform better.

I am planning on trying to make a setup myself that can compile and build the cores, so I can try it out.

[friendly.joe]

Hello and I wholeheartedly thank you for all the great efforts being made!

-----

From the cache 32 build, I noticed something seems to be another bug (or behavioral change in the core).

On Windows 95 RTM (w/o OSR), when you click "Display" applet in Control Panel,

Cache 31 and older: Works fine (it will display the display options)
Cache 32 and later: Does not work (it shows an error "An error occurred while Windows was working with the Control Panel file C:\WINDOWS\SYSTEM\DESK.CPL'."

If you could look into this issue, it will be greatly appreciated.
(I am suspecting this behavior is probably tied with the recent changes introduced in Cache 32 core)

Thank you.

I have been testing Cache 34 running Windows 98 SE, and it seems to work for me. I have tried 640x480 with 16 colors and 800x600 with 16bit colors. The control panel and such works.

But I dont remember if I updated the MiSTer file or not.

Thank you very much for your input; now I am trying again with WIndows 95 OSR 2.5 to see if it makes any difference.
It is interesting to know that cache 34 under Windows 98 SE is working for you.

I am also fairly astonished how much "impossibles" have been proven to be "possible".
I sincerely admire all the works being done by some talented devs.

[Glaurung]

Amazing work with thi core.Totally amzing.
What about Windows XP?
It's impossible for this core? Maybe in future builds?maybe the 128mb mem is not enought.
A lot of impossible things has bee done!!!
Win98 ia running pretty well right now with cache34

[friendly.joe]

Hello and I wholeheartedly thank you for all the great efforts being made!

-----

From the cache 32 build, I noticed something seems to be another bug (or behavioral change in the core).

On Windows 95 RTM (w/o OSR), when you click "Display" applet in Control Panel,

Cache 31 and older: Works fine (it will display the display options)
Cache 32 and later: Does not work (it shows an error "An error occurred while Windows was working with the Control Panel file C:\WINDOWS\SYSTEM\DESK.CPL'."

If you could look into this issue, it will be greatly appreciated.
(I am suspecting this behavior is probably tied with the recent changes introduced in Cache 32 core)

Thank you.

I have been testing Cache 34 running Windows 98 SE, and it seems to work for me. I have tried 640x480 with 16 colors and 800x600 with 16bit colors. The control panel and such works.

But I dont remember if I updated the MiSTer file or not.

Thank you very much for your input; now I am trying again with WIndows 95 OSR 2.5 to see if it makes any difference.
It is interesting to know that cache 34 under Windows 98 SE is working for you.

I am also fairly astonished how much "impossibles" have been proven to be "possible".
I sincerely admire all the works being done by some talented devs.

Confirmed: After reinstalled Windows 95 OSR 2.5 then performed the ET4000 driver, sound driver, then IE 4.0 install, Control Panel no longer complains for "Display" control panel module... Cache 34 Core is working correctly now. (256, 16 bit, and 24 bit colors work without issue)
So I suspect the original problem might come from the limitation which existed in the first version of WIndows 95.

For your information.

[abbub]

New version of cache 34 is working for me, though the uart issue is still there and I can't get networking to work.

Just to play around with the SVGA, I've installed and tested a few games from the early - mid 90s:

- F117 Stealth Fighter 2 works with no issues
- Masters of Orion works with no issues
- Descent 2 crashes with a DOS4GW issue (possibly a memory issue?)
- Beneath a Steel Sky locks up on loading
- Syndicate - works without issues.
- Pirates Gold - installation craps out after complaining about memory.

[IAmParadox]

Just wanted to say how much I am in awe and admiration for the hard work done on the ao486 core. As far as I can tell, the original code base was partly autogenerated and isn't particularly easy to read - well, at least I find it hard to read, but then again my FPGA background is purely a hobbyist one.

I find it absolutely astonishing that you guys are not only able to identify the bottlenecks in the core (apparently the high-latency memory subsystem lead to pipeline stalls basically all the time) but also widen these bottlenecks (by basically a complete overhaul of the memory subsystem) without breaking things left and right.

One thing that stands out to me in the ao486 codebase is that it seems to favor long chains of conditionals over simple case statements. For instance, looking at the shifter code:

Code: Select all

assign e_shift_left_result =
        (e_shift_count == 5'd0)?  { cflag,  e_shift_left_input[63:32] } :
        (e_shift_count == 5'd1)?            e_shift_left_input[63:31] :
        (e_shift_count == 5'd2)?            e_shift_left_input[62:30] :
        (e_shift_count == 5'd3)?            e_shift_left_input[61:29] :
        (e_shift_count == 5'd4)?            e_shift_left_input[60:28] :
        (e_shift_count == 5'd5)?            e_shift_left_input[59:27] :
        (e_shift_count == 5'd6)?            e_shift_left_input[58:26] :
        (e_shift_count == 5'd7)?            e_shift_left_input[57:25] :
        (e_shift_count == 5'd8)?            e_shift_left_input[56:24] :
        (e_shift_count == 5'd9)?            e_shift_left_input[55:23] :
        (e_shift_count == 5'd10)?           e_shift_left_input[54:22] :
        (e_shift_count == 5'd11)?           e_shift_left_input[53:21] :
        (e_shift_count == 5'd12)?           e_shift_left_input[52:20] :
        (e_shift_count == 5'd13)?           e_shift_left_input[51:19] :
        (e_shift_count == 5'd14)?           e_shift_left_input[50:18] :
        (e_shift_count == 5'd15)?           e_shift_left_input[49:17] :
        (e_shift_count == 5'd16)?           e_shift_left_input[48:16] :
        (e_shift_count == 5'd17)?           e_shift_left_input[47:15] :
        (e_shift_count == 5'd18)?           e_shift_left_input[46:14] :
        (e_shift_count == 5'd19)?           e_shift_left_input[45:13] :
        (e_shift_count == 5'd20)?           e_shift_left_input[44:12] :
        (e_shift_count == 5'd21)?           e_shift_left_input[43:11] :
        (e_shift_count == 5'd22)?           e_shift_left_input[42:10] :
        (e_shift_count == 5'd23)?           e_shift_left_input[41:9] :
        (e_shift_count == 5'd24)?           e_shift_left_input[40:8] :
        (e_shift_count == 5'd25)?           e_shift_left_input[39:7] :
        (e_shift_count == 5'd26)?           e_shift_left_input[38:6] :
        (e_shift_count == 5'd27)?           e_shift_left_input[37:5] :
        (e_shift_count == 5'd28)?           e_shift_left_input[36:4] :
        (e_shift_count == 5'd29)?           e_shift_left_input[35:3] :
        (e_shift_count == 5'd30)?           e_shift_left_input[34:2] :
                                            e_shift_left_input[33:1];

Unless I miss something, I think a more straightforward way to accomplish the same would be

Code: Select all

    always @(*) begin
        case(e_shift_count)
            5'd0:   e_shift_left_result = { cflag,  e_shift_left_input[63:32] };
            5'd1:   e_shift_left_result = e_shift_left_input[63:31];
            5'd2:   e_shift_left_result = e_shift_left_input[62:30];
            5'd3:   e_shift_left_result = e_shift_left_input[61:29];
            5'd4:   e_shift_left_result = e_shift_left_input[60:28];
            5'd5:   e_shift_left_result = e_shift_left_input[59:27];
            5'd6:   e_shift_left_result = e_shift_left_input[58:26];
            5'd7:   e_shift_left_result = e_shift_left_input[57:25];
            5'd8:   e_shift_left_result = e_shift_left_input[56:24];
            5'd9:   e_shift_left_result = e_shift_left_input[55:23];
            5'd10:  e_shift_left_result = e_shift_left_input[54:22];
            5'd11:  e_shift_left_result = e_shift_left_input[53:21];
            5'd12:  e_shift_left_result = e_shift_left_input[52:20];
            5'd13:  e_shift_left_result = e_shift_left_input[51:19];
            5'd14:  e_shift_left_result = e_shift_left_input[50:18];
            5'd15:  e_shift_left_result = e_shift_left_input[49:17];
            5'd16:  e_shift_left_result = e_shift_left_input[48:16];
            5'd17:  e_shift_left_result = e_shift_left_input[47:15];
            5'd18:  e_shift_left_result = e_shift_left_input[46:14];
            5'd19:  e_shift_left_result = e_shift_left_input[45:13];
            5'd20:  e_shift_left_result = e_shift_left_input[44:12];
            5'd21:  e_shift_left_result = e_shift_left_input[43:11];
            5'd22:  e_shift_left_result = e_shift_left_input[42:10];
            5'd23:  e_shift_left_result = e_shift_left_input[41:9];
            5'd24:  e_shift_left_result = e_shift_left_input[40:8];
            5'd25:  e_shift_left_result = e_shift_left_input[39:7];
            5'd26:  e_shift_left_result = e_shift_left_input[38:6];
            5'd27:  e_shift_left_result = e_shift_left_input[37:5];
            5'd28:  e_shift_left_result = e_shift_left_input[36:4];
            5'd29:  e_shift_left_result = e_shift_left_input[35:3];
            5'd30:  e_shift_left_result = e_shift_left_input[34:2];
            5'd31:  e_shift_left_result = e_shift_left_input[33:1];
        endcase
    end

To compare these two constructs, I isolated them into their own modules (shifter_ternary and shifter_case - attached to this post) and ran them through the yosys open source synthesizer. Result for the original construct:

Code: Select all

=== shifter_ternary ===

   Number of wires:                385
   Number of wire bits:           2261
   Number of public wires:           4
   Number of public wire bits:     103
   Number of memories:               0
   Number of memory bits:            0
   Number of processes:              0
   Number of cells:                861
     cyclonev_lcell_comb           861

Result for the case-construct:

Code: Select all

=== shifter_case ===

   Number of wires:                194
   Number of wire bits:           1149
   Number of public wires:           4
   Number of public wire bits:     103
   Number of memories:               0
   Number of memory bits:            0
   Number of processes:              0
   Number of cells:                663
     cyclonev_lcell_comb           663

Is staring at the code and finding such points of possible optimization a way to generate useful contributions to your effort?

For the most part, we are just normal users, you should go to github and post an issue/pull request there, if you want the devs to pay attention. Also, I agree with you, case statements are almost always better than a long list of conditionals.

[Caldor]

Sometimes a long list of conditionals might be to precalculate something and can be used to optimize... f.ex. some people precalculated some 3D calculations for... I think it was the SNES port of Doom. This way it would use disk / cartridge read speed, instead of CPU for these. Was some sinus cosinus stuff I Think. But... does not seem like that is what is going on here.

[softtest9]

Any idea how to "downscale" the picture in order to apply the scanlines filters to the 240p pictures ?

You would have to add some code to the filter you are using, to make the filter downscale the image before it begins upscaling. If you're using the MiSTer with a CRT TV, there are some hardware-based downscalers as well, like the Mimo Genius II: http://scanlines.hazard-city.de/

I haven't tried any of that though.

[FPGAzumSpass]

For instance, looking at the shifter code:

Thanks for searching for it and even running compare test!
Will look at it and if all is well, this will come to the repository.

I would have assumed this synthesizes to the same construct, but it seems not.

If you want to contribute more, it would be good to either create a github issue or new thread here.

Best would be of course, if you try it with the real core (biulding, testing) and file a pull request.

[SavageX]

@FPGAzumSpass

Cool, thanks for your kind response! I'll look into setting up a setup to compile and test core changes. Doing things over at GitHub certainly is the best way forward - my own projects reside over there anyways.


edit: Currently working on testing these shifter changes and prepare a GitHub pull request if things work out. No need to duplicate the effort on your side

[friendly.joe]

This community is amazing. Many Kudos for passionate Devs!

[jordi]

New version of cache 34 is working for me, though the uart issue is still there and I can't get networking to work.

Just to play around with the SVGA, I've installed and tested a few games from the early - mid 90s:

- F117 Stealth Fighter 2 works with no issues
- Masters of Orion works with no issues
- Descent 2 crashes with a DOS4GW issue (possibly a memory issue?)
- Beneath a Steel Sky locks up on loading
- Syndicate - works without issues.
- Pirates Gold - installation craps out after complaining about memory.

yep descent 1/2 crashes dos4gw.
Also worms crashes after some time running, not sure if in latest versions reproduce.

Anyway, it's a GREAT JOB!

[lroby74]

Amazing work with thi core.Totally amzing.
What about Windows XP?
It's impossible for this core? Maybe in future builds?maybe the 128mb mem is not enought.
A lot of impossible things has bee done!!!
Win98 ia running pretty well right now with cache34

Are 256MB ATM on core AO486

[rhester72]

yep descent 1/2 crashes dos4gw.

Same with Star Wars TIE Fighter Collector's CD-ROM.

[ZigZag]

Have you tried the replacement DOS32A extender? I remember using it years ago & found it considerably faster for some games.

[deepthaw]

Which rom should we be using to attempt SVGA?

[Chris23235]

yep descent 1/2 crashes dos4gw.

Same with Star Wars TIE Fighter Collector's CD-ROM.

TIE Fighter Collector's CD-ROM works for me, even in Hi-Res (the joystick is not recognised, but I didn't manage to get joystick support working in X-Wing or TIE Fighter in any version with any of the Cache versions).

[rhester72]

re: TIECD, mind sharing your CONFIG.SYS? I wonder if this is related to memory configuration somehow.

[Chris23235]

I use a config.sys with different menuitems, within the menuitem EM I use QEMM and here it works, but it also works without QEMM with the menuitem XM.

Code: Select all

[common]
DOS=HIGH,UMB
FILES=40
BUFFERS=40
LASTDRIVE=H
 
[menu]
menuitem=EMC, Expanded memory + Mouse + CD-ROM
menuitem=XMC, Extended memory + Mouse + CD-ROM
menuitem=CMC, Conventional Memory only + Mouse + CD-ROM
menuitem=EM, Expanded memory + Mouse
menuitem=XM, Extended memory + Mouse
menuitem=CM, Conventional memory only + Mouse
menuitem=E, Expanded memory
menuitem=X, Extended memory
menuitem=C, Conventional memory only
menudefault=EMC,10
 
[EMC]
DEVICE=C:\DOS\HIMEM.SYS /TESTMEM:OFF
DEVICE=C:\DOS\EMM386.EXE RAM
DEVICEHIGH=C:\DRIVERS\VIDECDD.SYS /D:OPTICAL
 
[XMC]
DEVICE=C:\DOS\HIMEM.SYS /TESTMEM:OFF
DEVICEHIGH=C:\DRIVERS\VIDECDD.SYS /D:OPTICAL
 
[CMC]
DEVICEHIGH=C:\DRIVERS\VIDECDD.SYS /D:OPTICAL
 
[EM]
device=c:\qemm\dosdata.sys
SET LOADHIDATA=C:\QEMM\LOADHI.RF
DEVICE=C:\QEMM\QEMM386.SYS RAM ARAM=B000-B7FF ARAM=D000-DFFF RF
device=c:\qemm\dos-up.sys @c:\qemm\dos-up.dat
DEVICE=C:\QEMM\LOADHI.SYS /RF C:\QEMM\QDPMI.SYS SWAPFILE=DPMI.SWP SWAPSIZE=1024
SHELL=C:\QEMM\LOADHI.COM /RF C:\COMMAND.COM C:\ /P
 
[XM]
DEVICE=C:\DOS\HIMEM.SYS /TESTMEM:OFF
 
[CM]
 
[E]
DEVICE=C:\DOS\HIMEM.SYS /TESTMEM:OFF
DEVICE=C:\DOS\EMM386.EXENOEMS X=A000-C7FF I=D000-EFFF
rem DEVICE=C:\DOS\EMM386.EXE RAM
 
[X]
DEVICE=C:\DOS\HIMEM.SYS /TESTMEM:OFF
 
[C]
 

[Caldor]

Which rom should we be using to attempt SVGA?

If you go to the first page in this thread, you will find a post by bbond007 where he has added releases of Cache29 to cache35, and the zip files include the required MiSTer file, and the bios files. (boot0.rom and boot1.rom).

[jordi]

tested duke 386 in new core at 640x480

ftp://retronn.de/dos/games/Duke3D/for386_1.4/

Well, this is impressive. It might be better using UNIVBE?

See this video a 640x480
https://youtu.be/ctPy_DqKR5E

[IAmParadox]

Windows drivers have been added to the repo, as well as the video BIOS we have been using, it is the same BIOS, so, if you are already using it, no need to replace it, and, if you aren't already using it, make sure to rename it to boot1.rom. (it's currently named boot1_et4k.rom)