I would be very interested in trying it, I've seen some of your screen recordings and changelogs and it sounds very promising.

Unfortunately, my attempts so far have not been successful, as I'm slightly embarrassed to admit that I wasn't able to figure out how to load a floppy image. I've seen a post of yours about how the menu controls are modelled around the PSP, and I have the list of how they map to the keyboard if no joystick is present (I'm running build 2016-09-07 on Win7 x64 with no game controllers connected). Most of the keys seem to do something sensible, but none of them allowed me to choose image files for the floppy drives in the "Manage mounted drives" screen. All I can get it to do is shortly flickering to a black screen before immediately returning me to the drive options.

So, I guess my main criticism at this point would be that the UI is tough to figure out 😀

You first enter the Settings menu by pressing Select on the PSP or backspace on the PC(only when not mounting the inpit by pressing the middle mouse button, both mouse buttons or RALT-F10). It will not allow you to choose mounting a different hard disk when emulation is running(you can onpy change it during a emulator start, by resetting the emulator using the save&restart to settings menu option, or by clicking select/backspace or clicking the yellow boot text during emulator startup. (You can't swap hard disks on a real system while it's running after all).

You have to put the different files in seperate folders for the emulator to even find them:
- ROMs in the ROM directory.
- disk images in the disks directory.
- Soundfonts in the soundfonts directory.

Once placed there, it should be able to find them. The emulator returning to the first option in the menu is simply a sign of it not finding image files or soundfonts where it expects to find them, thus no list items to display(and returning to the calling menu). This behaviour was changed in recent builds.

Edit: I've updated the wiki(emulator manual) accordingly. (at https://bitbucket.org/superfury/unipcemu/wiki/ )

superfury wrote:

Once placed there, it should be able to find them. The emulator returning to the first option in the menu is simply a sign of it not finding image files or soundfonts where it expects to find them, thus no list items to display(and returning to the calling menu). This behaviour was changed in recent builds.

Oh, I see! Thanks for the clarification. I will give the emulator another go as soon as I have a moment.

I wanted to try its supposedly cycle-accurate CPU emulation, but found the user interface for setting it up to be such a nightmare that I have given up trying.

Choosing normal, intuitive PC keys for control, instead of mapping meaningless PSP keys to even more meaningless PC keys, would be a start. For example: The proper key to switch between pages of options is always "Page Up" and "Page Down", not "Q" and "W". The proper way to select an option is ENTER, not Num Pad 2. The proper key for leaving a sub-menu would be ESC or Backspace, not Num Pad 6. And so on.

After renaming 5000026.u18 to BIOSROM.U18 and 5000027.u19 to BIOSROM.U19 and putting both in a ROM subdirectory, emu.log no longer complains about a missing U18 file, but I still only get a black screen, albeit with 100% CPU usage (in one core). Switching to internal BIOS produces almost the same result, except that Windows 7 64bit now complains that the application is not responding. Given that I got every other emulator in the world running, my current review is that the emulator is unusable for me in its current form.

I've implemented ESC/NUM6=Cancel and ENTER/NUM2 to choose/confirm in the Settings menu. Also, the internal BIOS should show itself now(the VGA no longer being in a HLT state), without hanging waiting for the VGA to reach Vertical Retrace.

Switching between tabs can be done using Q/W, but also using left/right keys(Q/W is taken from the way VisualBoyAdvance was set up(as far as I can remember), mapping to PSP LTrigger/RTrigger shoulder buttons).

These improvements and fixes are in the latest build I just released.

Also about the BIOS ROM not working, have you checked the emulated CPU Speed? Is it running slowly(<100%)? That might be the case on a <4.0GHz CPU(Tested on Intel i7 and 2.0 Ghz dual core CPU).

The latest version I've released yesterday(and the x64 version today) contains fixed that improve the internal BIOS(making it not crash anymore) and optimize the emulator a bit.

Can you check if the emulator is running at all? You can show the emulation speed by using Backspace(PSP Select) to open the setting menu, navigate to the Advanced menu(using left/right), Choose CPU Settings, click on/choose "Show CPU Speed" to set it to enabled. Then exit the menu, saving the changes (Escape to back out into the Advanced menu, use left/right to get to the Main menu, Click/choose Save Changes & Resume emulation(or Save Changes & Reboot when hardware settings have been changed). It should show a CPU speed: X% in the top-left corner of the window. What does that say? If it's 0% the CPU isn't running some some reason, otherwise it's always 1-100%.

I have switched to the 64bit version.

At least I now get a recognizable screen image.

The cursor blinks for five seconds (CPU speed around 75%), then it's back to "program is not responding". Trying to use the XT 1986 BIOS only gets me a blinking cursor and nothing else, not even the BIOS' memory test, but at least the emulator does not crash.

I know that there are still problems using the internal video BIOS, which I haven't figured out yet(even though it's input and output registers is according to the interrupt 10h documentation found everywhere, testing with Turbo XT BIOS v3.0). Could you try again with a VGAROM.BIN ROM file in the ROM subdirectory?

I had it in the directory, but named it OPTROM.1. Changing it to VGABIOS.BIN completes the memory test with the original XT 1986 BIOS. After the emulators first shows "A" and then "B" in green, the original XT BIOS now prints error number 601, which is listed as "General diskette or adapter failure". The keyboard does not seem to be responsive; at least F1 to "resume" does not proceed to Cassette BASIC, which it normally would.

Turbo XT BIOS says "System Error 02".

VGABIOS.BIN won't get used. It has to be called VGAROM.BIN in order for the emulator to use it(instead of falling back to the internal video BIOS, which doesn't work yet). The possible options are:
VGAROM.BIN for VGA
CGAROM.BIN for CGA
MDAROM.BIN for MDA
ET3000.BIN for ET3000
ET4000.BIN for ET4000

Any others are ignored, with the internal video BIOS being used instead. OPTROM.*.BIN start mounting AFTER the internal video BIOS. So at address D0000+. It's a custom-build Dosbox-based 64K ROM for UniPCemu use only. When the above ROM list item is used, it's mounted at C0000+, with the first OPTROM starting at the first 32K after it.

Edit: Looking up the error code:

1 Error Codes
2-----------
3The BIOS may give a "System Error" code at bootup. This error code is a
4combination of the following codes:
5
601h - Bad system BIOS checksum
702h - Bad RAM in main system memory
804h - Bad RAM in video card
910h - Bad RAM in vector area (this also in main system memory)
1020h - Bad expansion ROM checksum
11
12Note that the codes are in hexadecimal. The "System Error" code given by the
13BIOS is a sum of the above codes. For example, if the code 26 is given, the
14individual errors are 02h, 04h, and 20h.

So now there's a RAM problem? Have you tried the 32-bit version as well?

I meant VGAROM.BIN, just wrote it incorrectly. What is CGAROM.BIN supposed to be? The character ROM? Because the CGA does not have its own BIOS.

Same results with the 32-bit version of the emulator.

Well, that's strange. I'm using the Turbo XT BIOS(BIOSROM.BIN), XT-IDE BIOS(OPTROM.1.BIN) and VGA ROM(VGAROM.BIN) and it works. The ROMs have to be placed in the ROM subdirectory. Is that the case with your ROMs too? Another thing you could try is a full emulator settings reset(deleting the SETTINGS.DAT file). Then start it up and reconfigure.

The 1987 version of the Turbo XT BIOS does proceed to attempting to boot from diskette, after which the message "Disk Boot Failure" appears, even with a DOS 3.3 system disk mounted. Before, I used the 2008 Turbo XT BIOS version, which produced error 02, and the original IBM XT BIOS 1986 version, which produced error number 601. Deleting SETTINGS.DAT changes nothing.

The ROMs have to be placed in the ROM subdirectory. Is that the case with your ROMs too?

If they were not in the ROM subdirectory, I could not be getting any BIOS-specific error messages, could I?

Does the latest Generic Super PC/Turbo XT BIOS work? It's version 3.0(came out last december).

http://www.phatcode.net/downloads.php?id=101

Mount the .bin file as BIOSROM.XT.BIN

That newer BIOS did away with the Error 02 problem, and now puts me on par with all the other BIOSes and proceeds until "Disk Boot Failure" is displayed.

What kind of floppy disk do you have mounted? The BIOS only supports up to 720K and up to 360K low-density disks(everything from 1.44MB and up isn't supported).

MS-DOS 3.3 originally booted ok (360K floppy), newer might not work.

You might also go the easy way: create an empty hard disk image, use an bootable 360K MS-DOS 3.3 floppy and dummy(XT-IDE) ROM, Flash it from the floppy over the XT or AT ROM using UniPcemu(or simply use Dosbox to create a XT-IDE ROM with manual configuration) to use the ATA IDE HDD interface at the default IDE ports, save it back to the file, use the file as HDD ROM. Only the primary controller is used(Secondary contains CD-ROM ATAPI devices, which XT-IDE can't handle). The base ports are 1F0 and control port 3F6.

The full details of the HDD controller ports is at: http://wiki.osdev.org/PCI_IDE_Controller#Dete … _IDE_Controller

The PCI autdetect way is also supported, but for some reason xtidecfg only sees the Secondary(CD-ROM) controller in UniPCemu. Once configured and flashed to the ROM(See the UniPCemu wiki), it should find the harddisk correctly both on XT and AT.

The AT floppy disk is mostly accurate, only disk read/write timings are still unimplemented. That makes it give the 601 floppy errors.

Last time I checked, Turbo XT BIOS ran fine booting from 360K MS-DOS 3.3 and reading(not writing!) 1.44MB+ HD floppies.

It's a simple 360K floppy disk image of PC-DOS 3.3 which works on every other PC emulator in the world. 😜

The original IBM BIOS returns error 601 if the seek to track 34 failed, according to its source code. This check is performed before the actual boot process starts. That might indicate the actual source of the problem.

Hmmm. That booted last time I checked. I'll see if it still works...

Edit: It now indeed even seems to fail to boot my MS-DOS 3.3 boot disk, which worked up until I started messing with the floppy disk timings(seek/recalibrate accuracy).

Edit: Hmmm... Using the Turbo XT BIOS to boot my XT-IDE(xtidecfg) boot disk seems to abort before actually doing anything(timeout?) on 80286 emulation:

100:00:24:08.04476: FLOPPY: Write DOR=08
200:00:24:08.04884: FLOPPY: Reset requested by DOR!
300:00:24:08.04894: FLOPPY: Write DOR=0C
400:00:24:08.04900: FLOPPY: Activation requested by DOR!
500:00:24:08.04982: FLOPPY: MSR changed: 80
600:00:24:08.04986: FLOPPY: Read MSR=80
700:00:24:08.05000: FLOPPY: Command byte sent: 08
800:00:24:08.05006: FLOPPY: executing command: 08
900:00:24:08.05012: FLOPPY: Reset Sense Interrupt, pending drive 0/4...
1000:00:24:08.05020: FLOPPY: Sense interrupt: ST0=C0, Currentcylinder=00
1100:00:24:08.05040: FLOPPY: MSR changed: d0
1200:00:24:08.05042: FLOPPY: Read MSR=D0
1300:00:24:08.05054: FLOPPY: Reading result byte 1/2=C0
1400:00:24:08.05072: FLOPPY: Read MSR=D0
1500:00:24:08.05092: FLOPPY: Read MSR=D0
1600:00:24:08.05104: FLOPPY: Reading result byte 2/2=00
1700:00:24:08.05122: FLOPPY: MSR changed: 80
1800:00:24:08.05124: FLOPPY: Read MSR=80
1900:00:24:08.05156: FLOPPY: Read MSR=80
2000:00:24:08.05168: FLOPPY: Command byte sent: 03
2100:00:24:08.05174: FLOPPY: Reset for all drives has been finished!
2200:00:24:08.05192: FLOPPY: MSR changed: 90
2300:00:24:08.05196: FLOPPY: Read MSR=90
2400:00:24:08.05206: FLOPPY: Parameter sent: CF(#1/2)
2500:00:24:08.05224: FLOPPY: Read MSR=90
2600:00:24:08.05236: FLOPPY: Parameter sent: 02(#2/2)
2700:00:24:08.05240: FLOPPY: executing command: 03
2800:00:25:50.05094: FLOPPY: Write DOR=0C

So, Sense Interrupt(floppy disk initialization required), then a specify(a.k.a. Fix drive data) command with it's parameters, then aborts for some unknown reason? Anyone can see what's going on? Jepael? Reenigne?

Why isn't MSR going back from 90 to 80 after "Specify" (command 03) has been completed? In the terminology of the log, there should be an "MSR changed: 80" occurring after "executing command: 03".