My latest build:

- Implemented missing Covox mono support, based on Dosbox's. This now renders correctly too.
- Increased adlib and PC speaker treshold for better sound.

Hi, over the last day or so I've been trying to get x86EMU working, for the reason that you're the only person I've seen who is actively trying to make it run the 8088MPH demo correctly.

However, no matter what I do, after it boots, I just get a black screen with "Cap", "NCS", and "MCAS" on the bottom right corner. I've tried almost every BIOS option, several system and VGA BIOS images, and multiple boot media (FreeDOS floppy, DOS6.22 floppy, your own bootable HDD image).

Is there anything special you have to do to make it boot?

Well, you could check the settings of the emulator(advanced menu). Also, check if anything is logged in the logs subdirectory. There might be something going wrong mapping the ROMs. Do you have a BIOS ROM in either ROM/BIOSROM.BIN or ROM/BIOSROM.u18&ROM/BIOSROM.u19(both required if used). The VGA ROM, if used, must be mounted as ROM/VGAROM.BIN. Any other Option ROMs are ROM/OPTROM.xx(replace XX with index 1 and higher).

The VGA ROM is optional: if not used the emulator will emulate it using an adapted version of Dosbox-X's Video Interrupt.

You can use the framerate and CPU Speed settings to verify if the VGA and CPU are doing anything(or hanging VGA or CPU with 0FPS or 0% speed. If both are running, you can check if the CPU is executing valid instructions by enabling the debugger and stepping through the code. If you encounter an Unimplemented 80186/8086 opcode, your application/BIOS can't be used on the emulated processor. 80286+ instructions aren't implemented yet, nor is task switching or protected mode interrupts. An application or BIOS using those will lock up(because of infinite #UD exceptions remaining unfixed, thus throwing exceptions, returning and executing again unfixed) or skip those actions(in the case of protected(and V86) mode interrupts and task switches).

I use the following ROM setup:
BIOSROM.BIN: Turbo XT BIOS v2.5
VGAROM.BIN: IBM VGA ROM from PCEM or VGA ROM from fake86
OPTROM.1: XTIDE BIOS.
The filenames are filenames (case sensitive on *nix systems) as full filenames(with .bin and .1 extension respectively) in the ROM subdirectory of x86EMU.

Of course the XTIDE BIOS will need to be configured using it's support tools and ROM(The XT one). Just load the ROM from the floppy, autodetect settings, make sure to only use one IDE channel(Second will contain CD-ROM with primary being tbe harddisks. The CD-ROMs will move to the primary channel without harddisks). Since XT-IDE can't handle CD-ROM drives, it's recommended to disable the ATA channel until proper 286+ emulation is added to run the drivers. Also take care with MS-DOS 6 CD-ROM drivers: these will contain 286+ instructions that hang the CPU because of the unimplemented opcodes.

Also beware with BIOSes that use non-IBM VGA registers(see FreeVGA documentation for supported registers. I've added a VGA NMI option for software that expects NMI when accessing CGA I/O ports not supported by the VGA). These might not work with the pure IBM VGA.

You could try setting the video mode to Forced Fullscreen(in their respective settings) to make the emulator use the direct pixel rendering mode. If the screen becomes 480x272(PSP resolution minimum), the VGA might not be rendering anything. You can verify by performing a screen capture using the CAPTURE key (Keyboard input mode(not direct input mode), third tab, left bottom section, top option). I will implement some easier screen capture by clicking the CAP text in the next release.
If no screen capture is made when the CAP text deactivates, the VGA is rendering empty frames. If the CAP text keeps being active indefinitely, the VGA isn't rendering at all(Sequencer is being reset permanently or RAM is nonexistant). Finally, since the VGA is clocked to the CPU, if the CPU doesn't run instructions(or is halting), then so does the VGA stop running(shared clock, like all hardware but the MIDI rendering).

Also, make sure you aren't running the x86EMU from where the floppy wasn't working(due to IRQ5/6/7 errors). These versions can't use floppies when using the floppy IRQ.

My latest x86EMU build:

- Improved PC speaker, Adlib and Sound Source latency.
- Implemented screen capture clickable CAP text.
- Changed the CPU speed to at least report 1% when not running at exactly 0% to show the CPU is actually running(0% speed running CPU doesn't exist: The CPU always does something, so report so if it's doing anything. Only if it isn't running at all, report 0%).
- Protected screen captures from overflowing buffers (bigger than the emulated screen buffer).
- Fixed screen updates without rendered buffer (it now correctly uses a black background, so that in all cases the display and text is cleared when it needs to be instead of staying unchanged(with old data being shown below new data)).
- Fixed BIOS Sound Source percentage not being shown in the BIOS Sound menu since the nee clickable menu items.

My latest x86EMU build:

- Fixed the debugger output. It now won't disturb framerate rendering anymore.

My latest x86EMU release:

- Fixed floppy disk size reporting at port 3F0 (4 floppy disk sizes, 2-bits each).
- Implemented BIOS option for generating empty floppy disk images (unformatted), essentially the floppy disk version of the static disk creation(with predefined standard floppy disk sizes).

Copying files to floppy disks still fails for some reason (I'm using the Generic Super PC/Turbo XT BIOS v2.5 combined with the latest XT-IDE hard disk bios for the XT). Maybe the XT-IDE does something wrong? The files copied to the floppies get corrupted (essentially the tail of the file when displayed using any text editor/MS-DOS type command(gives corrupted data/beeps also before/during display)). Anyone can see what's going wrong here? I haven't changed the floppy disk controller in a long time, so the HDD emulation might be doing something wrong here? Or is some recently added hardware interfering? (I/O overlapping with the FDD registers(except HDD&Floppy shared port(the port with the single bit on bit 7, disk change if I recall correctly))

Some little bugfixes:

- Floppy: Implemented full disk change emulation (although unused so far).
- IDE controller: Fixed BARs according to osdev (control registers of BAR1 and BAR3 starting at BAR1+2 and BAR3+2 instead of BAR1 and BAR3 when they're set to values larger than 1).
- IDE controller: Changed drive address register reads to discard bit 7 (used by the Floppy Disk Controller's disk change bit).

I do seem to notice that for some reason, when the hard disk controller is enabled(and XT-IDE bios disabled or enabled), the floppy disk controller screws up writing sectors and formatting (write operations). Reading still works without problems though (tested with MS-DOS 3.3 by echoing text into a text document (using "echo testfdfsdetc>test.txt" and "echo testdefghijklm>>test.txt" repeatively) until ~11KB and then reading it back using the type command. When the file is read nothing strange happens, but when it's copied, the copy has corrupt data when read back using the type command).

When disabling the IDE controller(and BIOS) everything copies and reads without problems, but when it's enabled (calling initATA, both with and without XT-IDE BIOS), files copied carry corrupt data?

IDE hardware emulation: https://bitbucket.org/superfury/x86emu/src/98 … ide.c?at=master

Floppy hardware emulation: https://bitbucket.org/superfury/x86emu/src/98 … ppy.c?at=master

Anyone can see the problem in the source code? The result of the in/out functions is OR'ed together during reads when the function returns 1. When no functions return 1, 0xFF is read. When any function returns 1, the built OR'ed value is used as the result.

The XT-IDE BIOS is set to use the default base ports (1F0 and 376(although 370 in the setup menu it programs the controller for 376)). The default settings (with the BAR0-4 being 0) are the same.

Anyone knows what the problem is here? Are the hardware conflicting for some reason(I/O conflict)?

Edit: I've found a little bug in handling the hardware using 8-bit and 32-bit port reads (using the INB/IND command) processing OUTB channels (instead of INB channels) and INW reads (instead of IND reads). In this case reads from 8-bit ports might be using the 8-bit output port ports amount instead of 8-bit input port ports. So if the amount of OUT channels registered doesn't match the amount of IN channels, either reads from 8-bit ports could read less or more than needed. I'll test the fix when I got time. (It would explain why I look through all recently added I/O emulation and can't find anything wrong with any of the hardware)

My latest x86EMU build:

- Fixed various I/O port bugs.
- Improved floppy emulation with data rate failing and register updating.
- Implemented full floppy disk formatting (FAT12) at floppy creation.
- Fixed BIOS menu showing floating point MB floppy disk sizes.
- Implemented direct input handling during BIOS menu input mode. Now direct input using the keyboard in the BIOS text input is possible.
- The Floppy disk images generated using the BIOS menu now also create a basic MS-DOS FAT12 file system on the disk.

My latest x86EMU build:

- Added support for XT(80(1)86/88 vs AT(286+) floppy disk controller's limited (unhandled) registers.
- Changed all floppy disk logging to only log while debugging.
- Added proper reset functionality to the floppy (only raising the IRQ when re-activating the controller from reset mode).
- Fixed floppy pending Interrupt Status calls after reset. This is now properly 4(with AT) or 1(with XT, for the Turbo XT BIOS only handles one call instead of the official 4 calls for every drive).
- Added logging of invalid floppy disk commands.
- Implemented correct error conditions (setting bit 6 of ST0 instead of bit 7(invalid opcode)) for normal valid instructions with invalid input/output.
- Disabled floppy minimum rate for now. Now the rate is ignored again, just like Bochs ignores it(as far as I can see it isn't used in it's floppy module).
- Floppy disks now work properly again with all formats.
- Formatting of floppy disk images created using the Generate Floppy Image in the disks menu is now properly applied (verified using Winimage). The only things that might be different between it and a real format is the FAT sector count (set to 9 for all formats), the FAT12 root entries count (224 always), media descriptor (estimated for unknown formats, based on it's lowest equivalent) and boot loader (It simply executes the Cassette BIOS/no bootable disk handler(interrupt 18h)).

My latest x86EMU build:

- Implemented full FAT boot sector creation when creating floppy disk images.
- Implemented Double Density and GAP length errors during floppy disk access (80286+ only, currently disabled with 80(1)86/88).
- Fixed floppy creation boot sector bootstrap giving a message it's not bootable and press a key to reboot(verified using some emulators too, like Virtualbox, Dosbox, PCEm and PCE emulator in IBM PC and IBM PC XT mode w/ actual BIOS ROM).
- Check for Turbo XT BIOS to make the floppy disk controller replicate bugs in the BIOS (1 Sense Interrupt instead of 4 when performing a controller reset).
- Reimplemented protected mode paging support (still unused, as protected mode itself isn't done yet, thus CR0 isn't writable by the CPU yet(instruction not yet emulated, not any other 32-bit instructions, except for CPUID(still blocked CPU options)).)
- Now all BIOS menu options working with the keyboard should work without problems.
- Added Floppy Tape Drive register.
- Improved Floppy DMA (globally set instead of looked at each point).
- Added Floppy DOR read according to Bochs (according to another manual on the uPD765 it doesn't exist to read?)
- Fixed Direct Input mode when using the BIOS menus.
- Fixed Gaming mode default shift status (it was setting all Ctrl, Alt and Shift values ON instead of OFF by setting -1 instead of 0).
- Disabled Floppy logging for this release (still working on getting it working fully).
- Re-implemented the low pass filter in the sound module to protect against direct current generated during slow/buggy hardware emulation output(like the PC speaker on slow systems not giving enough samples fast enough, resulting in DC). Although this creates a decrease in sound quality compared to earlier versions.

My latest x86EMU build:

- Added drive-specific NDM bit to DMA checks.
- Fixed Floppy IRQ lowering (shouldn't be done).
- Disabled Floppy read write protected updating: This shouldn't be done (only on writes)?
- Added Floppy abnormal termination to the log.
- Added TC errors to the log.
- Added Floppy result phase byte data to the log.
- Implemented Gaming mode mouse buttons.
- Fixed inputs in the bios using keyboard/mouse combinations.
- Increased BIOS version because of the new Mouse Button support in Gaming mode.
- Fixed hanging buttons during BIOS input.
- Fixed various bugs in the input module.
- Fixed BIOS keep quitting the gaming mode when returning into it.

My latest x86EMU build:

- Improved keyboard handling to properly support timed input in correct order(properly supporting special(ctrl/alt/shift) key combinations at the same moment of processing(like Gaming mode).
- Converted keyboard to process input in linear time (first Ctrl, Alt and Shift is pressed/released now, then other keys in a predetermined order during non-Direct Input modes).
- Fixed input with all methods.
- Fixed BIOS menu key selection options (having reordered the BIOS input fields to match the output better and with better order).
- Now the down button won't enter gaming mode and press the button mapped to DOWN anymore. It will now enter gaming mode when down is released (as it already did with leaving gaming mode, but with select(which isn't mappable for this reason, as it's coming from gaming mode, thus being unusable for giving input). Also this is to prevent going into the BIOS accidently, while leaving gaming mode).

Since the Gaming mode is working fully now, it's ready to be used with the PSP version of it (input wise). Although it still needs some work to get fully running (CPU doesn't seem to start, is way too slow or is hanging when trying in an emulator and real PSP).

The source code currently supports Windows, Linux and PSP Makefile configurations. Windows works, thus version on Linux will still need to be checked, PSP is already mentioned.

Will this get a libretro core? 😀

I don't know if this "libretro core" actually is a complete CPU core (my emulator already has one, which it uses for CPU emulation?) or simply an interface to use with emulators?

Anyway, a little bugfix of BIOS settings file size and loading of Soundfonts (incorrect struct sizes due to packed bugs in MinGW).

My latest build:

This should fix BIOS settings compatibility(not being cleared when used because the format in the file is wrongly aligned) with other systems that are not affected by the bug (Linux and PSP), as wel as fix the problem of reading Soundfonts incorrectly.

I mean as a core for Retroarch

Since you're developing it for the PSP in mind, it would be driven with a gamepad like anything else on that platform right? It does have DOSBox but that's a bit difficult to use 😀

Actually it currently uses the PSP gamepad/PC joystick #0(when having at least as many buttons as the PSP has) for PSP-style input, keyboard on the PC for either PSP-style mapped input (during all non-Direct Input modes) and mouse/keyboard normal input during Direct Input mode.

When no joystick is connected and not in Direct Input mode, the keyboard is mapped to PSP buttons/joystick. When a joystick is connected, it's used instead of the keyboard (joystick #0 and PSP input are using the same SDL input interface handler, with the requirement of minimal buttons (14 I believe)).

PSP Key - Keyboard Key
L trigger - Q
R trigger - W
Home - Ctrl
Start - Enter
Select - Backspace
DPad - Arrows
Analog stick - I,J,K,L
Square, Triangle, Circle, Cross - Numpad 4, Numpad 8, Numpad 6, Numpad 2

And then I've simply added middle mouse buttons(with both mouse buttons alternative) for enabling/disabling support for the added Windows/Linux(or simply said devices using a mouse) Direct Input mode. The PSP simply does not use a mouse, so it's effectively not used(although it's still emulated, but never triggered, since there's no mouse input).

So it's essentially a combination of literal mappings (mostly), combined with VisualBoyAdvance-style mappings for L/R/Select/Start input (with Ctrl as Home added).

My latest build:

- Optimized rendering to work faster.
- Optimized VGA rendering a bit.
- Changed the 80(1)86/88 CPUs to use 8 cycles per instruction instead of the 4 cycles per instruction used on the other CPUs until actual cycle accuracy is implemented.
- Decreased EMS memory to 2MB instead of the old 4MB according to the board's specifications (effectively the upper 2MB is supported, but unused by the driver of the Lo-tech EMS 2MB EMS board (it is supported by addressing pages 128-255, but only assigned 2MB memory by the emulator to be more efficient, as such a driver doesn't exist)). This decreases memory usage.
- Decreased MMU memory to 1MB on systems having more than 1MB memory free when emulating a 16-bit CPU (80(1)86/88 CPU), as they cannot address more than 1MB anyway, thus decreasing memory usage as well.
- Implemented both high pass (1Hz, currently disabled) and low pass (22kHz, enabled) to the sound module. This won't prevent it from blowing up your speakers (as the high pass filter is still buggy, giving wrong output, it's disabled) with Direct Current (DC), but does increase sound quality until this bug is fixed (currently asking around on the forum about the bug).
- Optimized MIDI rendering and added MIDI Low pass and Pitch modulation using the Soundfont 2.0 Modulation Envelope (ME).

I'm curious about running x86emu on my main PC running Linux. Are you using any Win32 specific stuff? SDL sound should be completely portable, so I'm not concerned with that, but what about on the rasterizer or anywhere else?

All system specific stuff is in the header file concerning the system (types_win.h, types_linux.h, types_psp.h). All other defines and functions are either in the normal code itself (and in it's respective header file) or defined in it's system specific header (like the mkdir being mapped to differently called functions in the previous mentioned files, as well as pointer sizes, when converted to numbers).

So it's essentially build for three systems currently: Windows, PSP and Linux(and all other systems like it, as long as they're defined correctly using SDL's #defines.).

Although I would like to know if there are any warnings/errors during compilation on Linux. I don't know if it's GCC compiler compiles 100% the same as the MinGW compiler I'm using (throwing warnings/errors mine doesn't throw), as the MinGW compiler might be a bit outdated(I believe it's a lot older than the current GCC compiler toolchain).

I'll try to find the time to give it a spin, then. Thanks!