Page 16 of 22
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 6:44 am
by Caldor
rhester72 wrote: ↑Sun Aug 02, 2020 6:26 am
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.
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 6:47 am
by ToothbrushThreepwood
rhester72 wrote: ↑Sun Aug 02, 2020 6:26 am
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?
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 6:57 am
by 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.
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 8:06 am
by 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.
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 10:06 am
by 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?
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 12:12 pm
by 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 10426 times
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 12:13 pm
by Caldor
NightShadowPT wrote: ↑Sun Aug 02, 2020 12:12 pm
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
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 1:56 pm
by Caldor
friendly.joe wrote: ↑Sun Aug 02, 2020 8:06 am
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.
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 1:59 pm
by Caldor
SavageX wrote: ↑Sun Aug 02, 2020 10:06 amOne 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.
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 2:56 pm
by friendly.joe
Caldor wrote: ↑Sun Aug 02, 2020 1:56 pm
friendly.joe wrote: ↑Sun Aug 02, 2020 8:06 am
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.
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 3:05 pm
by 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
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 4:20 pm
by friendly.joe
friendly.joe wrote: ↑Sun Aug 02, 2020 2:56 pm
Caldor wrote: ↑Sun Aug 02, 2020 1:56 pm
friendly.joe wrote: ↑Sun Aug 02, 2020 8:06 am
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.
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 5:00 pm
by 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.
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 5:16 pm
by IAmParadox
SavageX wrote: ↑Sun Aug 02, 2020 10:06 am
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.
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 5:53 pm
by 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.
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 6:12 pm
by softtest9
mahen wrote: ↑Wed Jul 29, 2020 8:43 am
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.
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 7:05 pm
by FPGAzumSpass
SavageX wrote: ↑Sun Aug 02, 2020 10:06 am
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.
Re: Breakthrough for the ao486 core announced - Cache
Posted: Sun Aug 02, 2020 7:24 pm
by 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
Re: Breakthrough for the ao486 core announced - Cache
Posted: Mon Aug 03, 2020 5:44 am
by friendly.joe
This community is amazing. Many Kudos for passionate Devs!
Re: Breakthrough for the ao486 core announced - Cache
Posted: Mon Aug 03, 2020 9:59 am
by jordi
abbub wrote: ↑Sun Aug 02, 2020 5:00 pm
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!
Re: Breakthrough for the ao486 core announced - Cache
Posted: Mon Aug 03, 2020 12:09 pm
by lroby74
Glaurung wrote: ↑Sun Aug 02, 2020 3:05 pm
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
Re: Breakthrough for the ao486 core announced - Cache
Posted: Mon Aug 03, 2020 1:26 pm
by rhester72
jordi wrote: ↑Mon Aug 03, 2020 9:59 am
yep descent 1/2 crashes dos4gw.
Same with Star Wars TIE Fighter Collector's CD-ROM.
Re: Breakthrough for the ao486 core announced - Cache
Posted: Mon Aug 03, 2020 4:05 pm
by ZigZag
Have you tried the replacement DOS32A extender? I remember using it years ago & found it considerably faster for some games.
Re: Breakthrough for the ao486 core announced - Cache
Posted: Mon Aug 03, 2020 5:29 pm
by deepthaw
Which rom should we be using to attempt SVGA?
Re: Breakthrough for the ao486 core announced - Cache
Posted: Mon Aug 03, 2020 5:54 pm
by Chris23235
rhester72 wrote: ↑Mon Aug 03, 2020 1:26 pm
jordi wrote: ↑Mon Aug 03, 2020 9:59 am
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).
Re: Breakthrough for the ao486 core announced - Cache
Posted: Mon Aug 03, 2020 6:21 pm
by rhester72
re: TIECD, mind sharing your CONFIG.SYS? I wonder if this is related to memory configuration somehow.
Re: Breakthrough for the ao486 core announced - Cache
Posted: Mon Aug 03, 2020 8:21 pm
by 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]
Re: Breakthrough for the ao486 core announced - Cache
Posted: Mon Aug 03, 2020 11:14 pm
by Caldor
deepthaw wrote: ↑Mon Aug 03, 2020 5:29 pm
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).
Re: Breakthrough for the ao486 core announced - Cache
Posted: Tue Aug 04, 2020 11:56 am
by 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
Re: Breakthrough for the ao486 core announced - Cache
Posted: Wed Aug 05, 2020 10:33 am
by 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)