Hi everyone.
Tried DosBox 0.73 on the Sammy 440 ep, but is too slow, even for ther humble old dos game Dangerous Dave. The sound is also crippled. Any thought?

Will the update 3 bring improvements on the 2D graphics speed too? Maybe the DosBox could benefits of such improvements. Will be possible to compile the version 0.74?

_________________
retired

@AmigaBlitter

do not touch dosbox with less than 1 GHz cpu, you can change frameskip also but it won't help

@AmigaBlitter

Did you tried DosBox 0.73b?
http://amigadev.free.fr/downloads/dosbox-0.73b.lha

Your SAM should reach 3000 CPU cycles - 386DX performance. Enough for most games from 1992/1993.

Edit: You can also disable doubled GFX output and run DosBox in plain 320x200 (window or screen) - it could be much faster.

Last edited by pavlor on 28-Jun-2011 at 02:21 PM.

Actually I didn't encounter any problems with DOSBox on my previous Sam440ep Flex @ 800 MHz though.

_________________

@AmigaBlitter

I compiled dosbox 0.74 after its release but haven't uploaded yet ... because it tried to optimize things but the dosbox code doesn't ease improvements.
Anyway, I will release dosbox 0.74 soon with all my patches applied and I hope it will be better.
I wanted to try a kind of hack on Sam440 but it will be later ... if that happens one day.

@corto


I'm looking forward to the next release.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@corto

Using WritePixelArray (if possible) will benefit of a higher transfer rate when copying the gfx content on the screen (on sam440 and sam460) via DMA with the next Update3 (assuming the real bottleneck is the gfx transfer rather then in the x86 emulation...)

_________________
Massimiliano Tretene, ACube Systems, Soft3

@m3x

Thanks ! I am trying to merge and clean all the patches and tests I made.
About the performance, the problem mainly comes from the x86 emulation. The problem about the graphic part is that the buffer is updated if needed (even if I'm not sure their graphic cache management has a lower overhead compared to a raw update) and then that enters the SDL part.

The SDL part is like other parts, very difficult to change.

Another in such a program is that I don't know clearly if changes improve things or not.

@AmigaBlitter

bochs is more compatible (check the screenshots) and it seems faster than Dosbox.

Also I don't think it's possible to boot from an ISO (or a CD) with Dosbox but you can with Bochs.

Last edited by elwood on 29-Jun-2011 at 10:15 AM.

_________________
Philippe 'Elwood' Ferrucci
Sam460 1.10 Ghz
AmigaOS 4 betatester
Amiga Translator Organisation

@all

Thank you all for the replies.

@elwood
Didn't know about bochs. I will try, thank you

@m3x
Update 3, update 3, please!!!!
Is the sam4x0 DSP optimized code used?

_________________
retired

@corto

Quote:

I compiled dosbox 0.74 after its release but haven't uploaded yet

Any news on this?

Have you noticed speed improvements?

thank you

_________________
retired

@elwood

There is a new version of bochs (2.4.6). Amiga version is old, tho.

_________________
retired

@elwood

Quote:

bochs is more compatible

For old DOS games?

Quote:

and it seems faster than Dosbox.

What level of performance you can reach on your AmigaOS 4 based computer? SAM440ep users reported more than 3000 CPU cycles with DOSBox - roughly 386DX performance.

Quote:

Also I don't think it's possible to boot from an ISO (or a CD) with Dosbox but you can with Bochs.

It is possible (if my memory serves well) - at least in the version for Windows.


My tests show that Bochs is not faster than DosBox (on Core 2 Q6600):
Doom benchmark
DosBox - 41 FPS (simple CPU core)
Bochs - less than 20 FPS

Dhrystone 2.1:
Both DosBox (simple CPU core) and Bochs score roughly 60 DMIPS (Pentium 60 performance)

Best results I get from QEMU - Pentium 200 performance (without accellerator).

@pavlor

I think that there is a lot of space for improvements. For example using the sam 440/460 24 dsp instructions. Even SDL should be compiled using the IBM optimized library for the sam's DSP. Update 3 could also give some improvements as gfxbench reports.

Last edited by AmigaBlitter on 06-Jul-2011 at 03:05 PM.

_________________
retired

I have very good news for DosBox users.

I managed to install Windows 95, S3 GFX card driver, SB16 sound driver and DirectX8.0a under DosBox 0.74 (for Windows). So DosBox can even run games for Windows95 - like Diablo I played some minutes ago!

Note that most Windows games need more than 30000 CPU cycles.

Installation is not that simple - DirectX refuses to install with simple CPU core (so I used full), S3 driver supplied with my Win95 doesn´t work with DosBox (I installed another driver) etc..

I must say compatibility of DosBox is impressive. Although Windows 95 is not officialy supported, I managed to run/play all games (or game demos) I tried in my Win95 setup inside DosBox:
Civilization 2
Diablo
Dungeon Keeper (Windows version, there is also DOS version that works good in plain DosBox)
Myth: The Fallen Lords
Seven Kingdoms
Sim Safari
Test Drive 4

However, these games are really resource demanding, only Civ2 runs OK even with less than 20000 CPU cycles.

@AmigaBlitter

Quote:

AmigaBlitter wrote: @pavlor I think that there is a lot of space for improvements. For example using the sam 440/460 24 dsp instructions. Even SDL should be compiled using the IBM optimized library for the sam's DSP. Update 3 could also give some improvements as gfxbench reports.

About DSP instructions, I compiled and ran dosbox on Sam440 compiled with -mcpu=440 but I didn't really see an improvement. I also tried with -Os, thinking that could give less pressure on the cache but I saw no visible changes.
About the IBM math lib, AFAIK some developers tried it in other projects and the improvement was not visible.
These proposals are nice but they doesn't match the problem here : what consumes time is the inner loop that decodes x86 instructions. I tried to reorganize the code there and to add a prefetch to avoid the instruction load penalty but again ... no visible changes

Quote:

Have you noticed speed improvements?

I think the main set of patches I already applied on dosbox 0.73 makes a difference. My other changes after profiling and trying many ideas don't show a visible benefit.

My problem is also that I don't really know how to measure performance in dosbox. I tried to measure time to reach a given point in a demo, with no frame skip and max cycles. But maybe the display frequency is used as a base in this case.

@pavlor

Could you give me the procedure to run the Doom benchmark please ?

@corto

Quote:

About DSP instructions, I compiled and ran dosbox on Sam440 compiled with -mcpu=440 but I didn't really see an improvement. I also tried with -Os, thinking that could give less pressure on the cache but I saw no visible changes. About the IBM math lib, AFAIK some developers tried it in other projects and the improvement was not visible. These proposals are nice but they doesn't match the problem here : what consumes time is the inner loop that decodes x86 instructions. I tried to reorganize the code there and to add a prefetch to avoid the instruction load penalty but again ... no visible changes

That's strange. However the 440 Dsp instructions are something like intel's mmx instructions. I don't think that dos games could benefits from DSP instructions. Maybe you should try use the IBM optimized memcopy routine.

DSP Mac processing:
https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/EA05F39C73A693A087256D6A00616D38/$file/440MacProcessing00.pdf

Optimized assembler:
https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/260D74A40E6DE3EE87256AE10055C790/$file/Optimized440.pdf

optimized memcopy routine:
https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/87AECE17F0BCB60C002573CA00652450/$file/440memcopy.pdf

_________________
retired

@AmigaBlitter

As I said in another thread while back, there is no need to use the IBM perflibs anymore, the same functionalities are include within newlib.

_________________
Massimiliano Tretene, ACube Systems, Soft3