I will need to test that. You will need a IDE BIOS that the PC BIOS can use to boot from HDD. XT IDE is one. I will add support for it in the config file and the GUI and do some testing.
This sound very good, but please let xtide as optional, so when we need a "pure" emulation we may turn it off.
Also, I was unable in loadin basics, even with the file setting directelly in config.cfg and the binary basicacc11.bin
Even worse, I have try with original Ibm xt bios (3 different version), but it doesn't boot.
p.s. I had to told you before....... Many thanks for this new emulator!!!!!
This sound very good, but please let xtide as optional, so when we need a "pure" emulation we may turn it off.
Yes I agree.
danrevella wrote:
Also, I was unable in loadin basics, even with the file setting directelly in config.cfg and the binary basicacc11.bin
Yes, BASIC loading is disabled in this release (I just forgot to enable it). I am re-enabling it back now. BASIC will work just fine.
danrevella wrote:
Even worse, I have try with original Ibm xt bios (3 different version), but it doesn't boot.
It did for me few days ago when I was trying. However it looks like it is hanging for a while because the XT BIOS is trying to hammer the FDC ports. Eventually it gives up and goes on to boot succesfully. It takes about 40 seconds or so. I will try it again though to make sure all is ok.
danrevella wrote:
p.s. I had to told you before....... Many thanks for this new emulator!!!!!
You are welcome!
I will shortly put up a new release with all those fixes that people mentioned here (and some others that I have done).
I have the 0xC000007C error as well when I try to use UniPCemu's 32-bit version with the 64-bit SDL2.dll and vice-versa(64-bit UniPCemu with 32-bit SDL2.dll), so it might be that the wrong dll is supplied?
Yes, I think this means the required dependency DLL is not found. In my case I was not statically linking against VS2015 runtime and your case it cannot find the matching SDL2.dll for the correct platform.
Version 0.3 is out, this time with MacOSX support as well. I created a new thread in "Release Annoucement" and we'll keep this thread for technical discussion.
I've been working hard on version 0.4 (and I will have a release soon). However here it is running (or trying to) on my Raspberry Pi 2 version 1.1. It seems I have some optimization work to do.
The ARM Cortex A7 at 900Mhz can only run the cycle based emulation of an IBM PC XT at mostly about 1Mhz 🙁
On a Raspberry Pi 3 I expect to run about half the speed of an 8088.
Still good enough to include in their repository with every other unusually slow emulator. DOSbox can't even refresh Doom's STARTUP text-mode screen at a tolerable framerate on that thing.
rpix86 alleges it can run a 486 at about 20Mhz which is a very good achievement for RPi which makes it totally useable. Good job by the author. However that is a normal emulator. I have to run cycle by cycle and emulate all components like that.
That gave me the idea to add a benchmark mode to CAPE and then try it on different platforms. I've also put in a good amount of optimizations and here is where it stands for the (unreleased) version 0.4.
The "Max Speed(Mhz)" is what speed is that particular machine capable of running my emulator. It does not matter (too much) what CPU (8088, 8086, 286, etc) because this is a cycle emulator. It simply measures how many cycles per second each platform can emulate. This is also for ALL components in the system, although the CPU, memory and CGA are the heaviest.
Compilers:
Windows 10: Visual Studio 2015
Linux: gcc 5.4.0
RPi: gcc 4.9.2
OSX: LLVM 7.0.0
I think the more powerful Corei7 4790 is help back by the (somewhat) lackluster Microsoft compiler that comes with VS 2015 whereas the OS X llvm is behaving much better.
