Well as far as I know it's simply a matter of target. I noticed some Win95 game lagging rendering a lot using VirtualPC(Disney Classics Video Games 2's Cold Shadow ripped from my game CD), but it ran fine in Dosbox with Win95 without any problems as far as I can remember.
My app is simply made with the PSP in mind. That's the reason I made it (Original and default input method when starting the emulator is mapped to PSP buttons(actual PSP buttons&joystick on a real PSP), based on Danzeff's keyboard and custom mappings(Set using the BIOS's Input submenu in the Advanced menu) for easy gameplay/usage without messing with text files or PC to configure.
- Fixed 808X divide by zero return address.
- Fixed MUL and IMUL instruction flags.
- Optimized various parts of the emulator. It can now go really fast.
- Implemented all PIT modes according to various manuals.
- PC speaker PWM is now implemented.
- CPU cycles specified are equivalent of Dosbox cycles setting. Setting it to default will select 8086/8088(~4.77MHz) with 4 cycles/instruction (exact cycle counts still need to be implemented).
- PIT now ticks at ~1.19MHz(Exactly 4 times as slow as a 8086/8088@~4.77MHz).
- Fixed bug with minimized windows not having it's resolution updated.
- Now keyboard and mouse are only handled when the window has focus (mouse focus and/or keyboard focus).
- All timed hardware are now tied to the CPU clock time for accuracy(Mouse, Adlib, ATA and DMA. Adlib, VGA and MIDI rendering are still independent).
- HLT/HALT state is now implemented as a 1 cycle delay.
- Greatly improved CPU speed due to various optimizations to the emulator.
- Multiple IRQ0 firing without CPU acnowledge is now supported. A triggering IRQ0(PIT0 going from low to high) will fire the IRQ and process the next PIT0 output after the next instruction.
- Various parts of the emulator have been optimized to make it run faster.
It's known that the emulator hangs or crashes when you try to run another program besides it. This has something to do with executing multiple instructions and hardware processing before checking for updated input and waiting for synchronization (using minimal delays to yield). Currently it works without problems (without other software opened) on my Intel i7-4790K@4.0GHz processor with 8GB RAM.
The PC speaker PWM emulation has so far been tested with Links(working), Supaplex(working) and 8088 MPH(working, but playing too fast due to inaccurate CPU timing until accurate 8086 CPU clock timings are added instead of 4 cycles/instruction).
Just because PCem exists and it is a very good product does not mean that all emulator work should stop. Just because it does not do something on top of PCem does not mean it does not have a goal. The point is, it is fun to write an emulator and a challenge, and Superfury's is pretty cool (and complete for a 8086 class computer) so grats to him for writing it. You also get to learn a lot. Sometimes the goal of a project is just to have fun. After all isn't this why we are all on this website? I write an emulator too and the last question I want to answer is "how is yours better than PCem?" It is not PCem, you cannot compare them.
leileilol wrote:
You know, there's been the same sort of "whats the point of dosbox we have virtualbox"
Just ignore those alreadyinventedhere people and carry on 😀
But that question has a clear answer. Just like there's an answer to "Why PCem when Qemu exists" and so forth.
The reason I put "...say..." in my question was to indicate that PCem was just an example. I wanted to know what is he aiming to do, is he aiming to make it different to what's already here (again, PCem was the example, any emulator could have gone there)? If so, how is it different? If not, just doing it for fun?
I didn't ask to judge or discourage (and I apologise if it came across that way). All I've seen here is a list of changelog, I couldn't find an initial post describing the aim of the project, even if that aim is just as an academic/leisure exercise. I figured that the formal release/changelog format meant there was some compatibility/functionality target.
It was a question that came purely from curiosity. Certainly not meant as "There is no point to this."
And he answered that question too:
"It was originally intended for usage on the PSP(actually still is) as a better usable alternative for Dosbox."
- Added BIOS option to the CPU menu to display CPU synchronization percentage (emulated time vs real time, 100%=Realtime, <100% is slower than realtime, >100% is faster than realtime).
- Fixed the bug mentioned previously that caused the emulator to hang (input updating locked semaphore always, but never unlocked it since it's only unlocked within the if-clause that follows it).
- Fixed various PIT timing errors according to OSDev (channel 2 gate and reload checks during mode 3/7 rendering).
- Added BIOS menu option to the Sound menu to record audio. It will be stored in the captures directory under recording_<increasing number>.wav.
- Closing empty .WAV files without content (0 samples long) will now properly clean up and delete the file.
I've also started working on getting the PSP version working, but it's still too slow to use (about 10 seconds or more response time) and won't run the CPU(if it's even running at all? The CPU speed indicator gives 0% CPU speed with 8086 timing(~4.77MHz with 4 cycles/instruction)). Timers (VGA etc.) are unknown if they're actually updating.
- Moved BIOS Advanced menu options to subcategories they're related to. The CPU menu is now ordered according to subcategories (CPU settings, Basic execution information and Debugger information). Mouse settings are now placed under the Input submenu. The Advanced submenus are now named in the same way.
- Added support for clickable characters to the text surfaces.
- Added support to the BIOS to be able to click on menu items and yellow BIOS text when (re-)starting emulation. Clicking on an item will now open that item or menu. Clicking on the yellow BIOS text will open the BIOS menu. This will make it better usable with systems using a mouse.
Edit: Hocus Pocus shareware version 1.0 finally seems to run (without any device drivers loaded) on the 80186! 😁
But that question has a clear answer. Just like there's an answer to "Why PCem when Qemu exists" and so forth.
I think this is similar to all the linux distributions.
Since none of them are a 'full' solution, people keep coming up with new linux distros that do something particular that others can't or aren't good at.
In an ideal world, I think we'd only need one PC emulator, and one virtual machine.
The PC emulator for accurate emulation of vintage hardware, and the virtual machine to do 'modern' virtualization with high performance.
I guess we've seen that with C64 and Amiga emulators... Over time, Vice and UAE became pretty much feature-complete, and the other emulation projects died out over time.
I hope we will see an emulator for PC one day, that is as accurate as Vice and UAE are. x86EMU looks to be well on track.
It won't recognize me specifying the -mwindows suggestion (not any other thing like -Wl,--subsystem,windows ). It tells me that Windows isn't a valid subsystem:
1... 2.o ../projects_build/x86emu/emu/debugger/debug_files.o ../projects_build/x86emu/ 3emu/io/directorylist.o ../projects_build/x86emu/emu/main.o ../projects_build/x86 4emu/basicio/fopen64.o -L/mingw/lib -lmingw32 -lSDLmain -lSDL -lSDL_gfx --enable- 5core-inline -static-libgcc -static-libstdc++ -mwindows -o ../projects_build/x86e 6mu/x86EMU.exe 7c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: invalid su 8bsystem type Windows 9collect2.exe: error: ld returned 1 exit status 10make: *** [../projects_build/x86emu/x86EMU.exe] Error 1
I can't get rid of the console window? Any suggestions? It compiles without problems (x86EMU + SDL + SDL_gfx) otherwise.
I've installed up to SDL according to http://www.dosbox.com/wiki/BuildingDOSBox , then SDL_gfx according to it's SDL_net tutorial, then compiling my emulator using Make win build.
Some other example I found, that uses -mWindows, compiles without errors? So it's a problem in my makefile(see last post on bitbucket Makefile.win) or the problem is caused by the SDL libraries? Is there a problem with my parameter ordering? It currently only uses gcc, does it need something extra/different? Ld comes to mind, but I can't get it to work. Anyone? When I try to link with gcc, then link using Ld it tells me it's output(-o) from gcc, is corrupt or truncated? Anyone knows how to make this work?
Btw, excuting Ld -V gives me only some i386pe platform? Compiling using that platform gives an corrupt executable.
Creating a working exe using this makefile (some simple test project taken from the internet) creates a correct executable:
Anyone notices anything that makes it fail? I think it has something to do with the includes linked libraries (-lSDL etc.)? Anyone knows any of those libraries messing up the linker stage when linking with -mwindows?
Working example:
1-s -lcomctl32 -Wl,--subsystem,windows
My makefile has (when working):
1-s -lmingw32 -lSDLmain -lSDL -lSDL_gfx
Is the problem simply in the -lcomctl32? When I try to add "-Wl,--subsystem,windows" to my makefile libraries (-l mentioned above), the debugger crashes instead of compiling? Since everything else is practically the same (except paths and Win32App.exe vs $(TARGET)), it's probably a problem in my libraries or the order they're given in?
I seperated the Makefile.win, Makefile.psp and Makefile into three new, project independent files:
Makefile.psp: PSP makefile
Makefile.win: Windows makefile
Makefile.multiplatform: Converts the Makefile that includes this into a project makefile supporting: make psp/win build/clean/rebuild.
The Makefile that includes Makefile.multiplatform needs to supply:
BUILD_NAME: The name of the executable(Windows) or EBOOT title(PSP).
OBJS: The object filenames to be build, with current directory as root (so test.c test/test.c will become test.o test/test.o).
Simply call one of the following instructions to compile:
1.1. make psp build
1.2. make psp clean
2. make psp rebuild
Replace psp with win for Windows compilation.
For some reason, when I try to compile a different project (using a simple test.c including includes/types.h and other includes, using OBJS = test.o test2.o and BUILD_NAME=test, it compiles without any errors (even producing a valid Windows non-console executable).
When I try to compile my own emulator using this it errors our with the error previously mentioned. ld -V tells me only platform i386pe is supported. Yet in the test project it compiles with platform windows and with x86EMU it tells me there isn't any windows subsystem.
Anyone knows if there's any header messing up things here? (include <header....> headers? My own headers doesn't generate any compiler flags as far as I know and can see? Are there any system headers that mess up the -mwindows workings?)
- It's now the same as the other version (the Visual C++ versions) in that it doesn't have a console window anymore, thanks to Visual Studio Community 2015's editbin 😀 .
- Fixed BIOS boot text background color to it's old color.
- Made the adlib fully cycle-accurate (up to it's samplerate).
- Fixed PC speaker timing not being reset with the emulator being reset.
- Fixed Adlib and MPU security (potential overflow) issues.
- Fixed code to be able to compile without errors on the PSP (pspsdk), WinGW(windows without dependencies, for all windows versions) and Visual C++(windows, only with Visual C++ 2015 runtime).
- Made the debugger and MMU report more information about invalid memory when an memory error occurs during debugging. It now differentiates between non-existant memory, unpaged/protected memory and unknown cases.
- The adlib now supports PCM output correctly by stopping the clock of an running sample wave when the frequency is set to 0 Hz without giving INF sound output (divide by zero).
- Added double buffering to the adlib and PC speaker emulation for better performance.
- Changed the Sound Source emulation to use the new double buffering support instead of it's original double buffering (essentially letting the FIFO buffer support handle double buffering passthrough more efficiently by transferring the whole FIFO to the render FIFO with one lock instead of a lock for every sample).
- Fixed the emulator constantly opening the BIOS menu when it's discarded on first boot. It will now not automatically open the BIOS after the first boot(when BIOS.DAT doesn't exist, which contains all the emulator settings).
- Improved speeds with this new build. Setting the cycles to 30000 will make MIPS 1.10 overflow and report it as a 30.23x IBM/AT 8MHz CPU (and make the Compaq 386 and/or MIPS count overflow like crazy, with the IBM/XT column empty). Although it isn't running realtime at such a high speed (although it is to the software running in it, since everything is synchronized, including the PIT and CPU. The CPU itself, in turn, is synchronized to realtime using the set cycle count (and eventually rampaging instructions on high cycle counts, since it's executing at 1 cycle/instruction, Dosbox-style. Only on Default mode (8086 clock frequency) it will use 4 cycles/instruction until full cycle calculations are implemented.)).
Adlib PCM support has been verified running with Bill & Ted's excellent adventure.
Anyone knows why edlib tracker (last release I could fine some time ago) looks like it has corrupted characters? I see small characters with big characters below. Is it overwriting the default VGA font and updating the VGA character height incorrectly? Or isn't it being updated by the VGA?
Anyone knows why edlib tracker (last release I could fine some time ago) looks like it has corrupted characters? I see small characters with big characters below. Is it overwriting the default VGA font and updating the VGA character height incorrectly? Or isn't it being updated by the VGA?
I think it's a bit like ScreamTracker, where it does some pseudo-graphics (like a smooth-tracking mouse cursor) by changing the VGA font in RAM.
- Implemented VGA Extended memory bit(unverified).
- Made the VGA cycle accurate.
- Implemented Adlib CSM mode(unverified).
- Improved VGA emulation with Sequencer Reset and EGA/VGA Vertical Retrace Interrupt(IRQ2).
- Fixed various uninitialized variables.
- Added full parallel port emulation(Turbo XT BIOS and software now properly detect it).
- Fixed keyboard input timing(keyboard now works at correct speed again).
- Changed Parallel and Serial ports to only use the ports that are connected(Atm LPT1=Sound Source and COM1 can be Mouse(when set to serial mouse)). The rest of the ports are unassigned, so not emulated until they're assigned(probably adding a convox speech thing adapter emulation on LPT2 later).
GPU might crash on changing rendering modes, even though it should be protected from doing so. Still working on getting the leak fixed.
Edit: Quick little fix for logging the updated screen resolution(used when debugging it):
- The UART and Parallel port is now fully emulated and detectable.
- Implemented Sound Source (now with Convox Speech Thing support!) accurate timing.
- Fixed PC speaker output.
- VGA limit has been increased to 10000 lines (from 1000 lines).
- The VGA was releasing the lock on the GPU(The display generator), which it wasn't supposed to do(only when starting and ending rendering blocks). This has been fixed. Now display mode changes no longer crash the emulator.
- Fixed all rendering modes. They should now work again without crashing anything.
- Fixed CPU speed percentage. It will now reset the speed counting each time the CPU is interrupted (By the BIOS menu).
- Fixed SDL support module(x86emu's module that converts calls into sdl function calls with extensions for the emulator, e.g. resizing with dirty status, line copy with memory protection(using the emulator's memory module) and other SDL-related graphics routines) using preallocated memory. It was updating the wrong variable when allocating a display surface, causing the renderer to deallocate the GPU's display memory(and other pixel data buffers as well). That would stop the VGA from rendering(as there's no place to render to, since the memory is freed after resizing(all other modes resizing the VGA display)/before taking a direct plot frame(when using the fullscreen mode combined with either the forced mode or automatic mode within PSP resolution range(<=480x272 VGA resolution)), essentially freezing VGA rendering when that happens.
This program should only have the requirement of the msvcrt.dll(Visual C++ 6.0 Runtime), which is shipped by default with Windows 2000 and higher. Older versions (95/98/ME) will still need to install the runtime redistributable. No other runtimes(that only run on newer versions of Windows, Like Visual Studio 2015's requirement of Windows XP to run and up?) are needed (SDL and SDL_gfx are compiled with the default settings, according to the Building Dosbox wiki page(SDL_gfx based on Building Dosbox's SDL_net tutorial)). The only thing left to do might be to get rid of the msvcrt requirement, if it's even possible without breaking the application/SDL/SDL_gfx?
- Fixed parallel IRQ 7,6 and 5 handling. Now the floppy disk controller works correctly again.
- Fixed parallel port IRQ handling and Sound Source emulation.
(currently the covox speech thing still logs it's samples because it doesn't work yet)
- Optimized FIFO buffer transfers for rendering.
- Disabled VGA screen lines limit for maximum performance.
- Moved the GPU rendering to the main thread.
- Fixed unnecessary screen updates from the framerate layer updating.
- Improved GPU rendering speed.
- Improved text layer rendering speed.
- Fixed bugs in the text layers.
- Changed the adlib double buffering threshold to 2048 samples.
- Improved PIT double buffering.
- Full Sound source and Covox buffer rendering.
- The VGA now tries to run realtime to the CPU emulation.
- The VGA now won't do anything when not needed to render (like the sequencer reset register telling it to stop).
- Moved FIFO buffer threshold shift outside the lock to improve rendering response.
- Increased timer to a slower rate(1ms, as it's mostly unused atm. There are only a few timers left that actually use the functionality (with low response required).
