VOGONS


Getting UniPCemu up and running

Topic actions

First post, by superfury

User metadata
Rank l33t
Rank
l33t

Just created this thread to help people getting UniPCemu up and running. Reply with any questions you may have.

The very basics:
- Most settings can be easily adjusted through the settings menu(all when the yellow startup text displays itself(clickable). After it disappears, the used BIOS is loaded, hard disks mounted and hardware settings are locked down(much in the same way you can't switch out hard disks or hardware in ISA/PCI slots while the system is up and running).
- The locked down settings in the settings menu can viewed in the settings menu, but choosing them isn't allowed(due to said locking down of the setting), returning to the originating menu's top item as the focused item(having a > in front of it with the active font/border color on the text).

There are a few settings which can only be changed by manually opening the settings file(mostly TCP server settings). Other connection settings can be changed normally as documented by the Hayes modem's commands. They should also be able to work with software supporting Hayes modem commands to set it up(e.g. Telemate or the like to run AT&Sx=n to set the phonebook and quick dial number x(0-9 range only) to value n). All phone dialing numbers support 3 kinds of dialing:
- 12-digit IP address( :[port] can be added). This is a normal x.x.x.x IP address to use.
- Normal hostname(with optional :[port]).
- Single digit for dialing the phone book.

The phone book dialing option can be used both as ATDn, ATDTn, ATDPn and ATDSn. Provided it's a single digit.

The BIOS settings can be programmed by following the following steps:
1. Setup the floppy disk and hard disk as required, using the steps described in the UniPCemu manual(wiki).
2. Either boot the Compaq Deskpro 386 system after normally formatting the hard disk and installing MS-DOS on it, or use a floppy disk image.
3. Use the Compaq Deskpro 386 diagnostic/setup disks to configure the BIOS, or use a plain MS-DOS boot floppy with gsetup on it(you can grab one, then use e.g. WinImage to put gsetup on the disk) to configure the BIOS in a more simple way. By default, disks with more than 40 tracks won't work with booting from the Compaq BIOS(it only recognises 40 tracks, requiring being setup for 720K drives to recognise 80 track drives properly).

One normal(non-server) settings can only be modified by manually opening the settings.ini file(all others can be modified using the settings menu):
- listenport: The port the server listens on for it's serial modem and dial-up server.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 1 of 75, by EmanuelePulciDoria

User metadata
Rank Newbie
Rank
Newbie

Thank you for this new post, I hope it will get the emulator up and running.
Starting from point 1 I imagine you are referring to the following link: https://bitbucket.org/superfury/unipcemu/src/master/ where I can see a README file with the instructions. You suggest to pull all the repository in a folder named UniPCemu. I have created one with all the files coming from your downloadable file UniPCemu_win64server.zip. I imagine I need to add all the others found in https://bitbucket.org/superfury/unipcemu/src/master/ (probably not the Android related ones) to the same folder. Is that correct? But how do I download them?

Reply 2 of 75, by superfury

User metadata
Rank l33t
Rank
l33t

With point 1(the manual/wiki) I actually meant the wiki part of the repository: https://bitbucket.org/superfury/unipcemu/wiki
It contains a simple manual I've written when using the normal compiled version.
The Readme.MD is only for compiling it from source(pulling the required repositories from git, then compiling it yourself(which is required on Linux)).

UniPCemu_win64server.zip already contains the required files themselves for the emulator to run with bare basics. You'll just need to add the ROMs for the emulated system in the ROM folder etc. to make it run fully.
The ROMs you'll have to obtain yourself, but for the XT machine, the Generic Super PC/Turbo XT BIOS 3.0 can be used(https://www.phatcode.net/downloads.php?id=101).

The AT/Compaq BIOS ROMs you'll need to obtain yourself. Can't post the links to them, but I know PCjs has some(search for the rev J.6 BIOS ROM for the Compaq Deskpro 386 on said site). Although it's in javascript format and needs to be converted back to a plain binary format(You can use http://tomeko.net/online_tools/hex_to_file.php?lang=en). The ROMs themselves can be found on Jeff Parson's PCjs git repository, it's the 1988-01-28 ROMs you'll need.

Edit: OK. Managed to get the IMD disk image support working in two modes: fast mode and slow mode. The downside of fast mode is that it uses more memory(more than the PSP can handle with it's less than 1MB free memory(shared with stuff like display buffer shrinking and file opening). The other mode (slow mode) is the one now enforced on new PSP builds, which has way more disk overhead(in the form of fseek and fread operations) but doesn't require buffering the entire disk image into memory(with large images, it could be 2-3MB, which can't be done properly on the PSP builds with less than 1MB free memory(which is guaranteed by the emulator's initialization process)).

The density setting(MFM vs FM and speed setting in the CCR register(250K/300K/500K/1M modes)) isn't emulated at any other location than the formatting process currently(which writes it to the track information block of the formatted track). The read and write routines of the IMD disk format themselves return the values, but the FDC controller currently doesn't actually check for them and error out when they don't match up with what the disk track says it uses.
This is currently mainly done to keep easy compatibility with BIOS and MS-DOS code which doesn't actually set the MFM bit of the command and the speed mode depending on what disk is inserted(it's a static, unchanging value for both settings). Otherwise, booting various media might fail. Perhaps I'll add said feature in the future(as an option in the settings for the architecture).

Edit: OK. Just checked using the TESTFDC tool. The disk image parsing seems to be working properly in slow mode! 😁

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 3 of 75, by EmanuelePulciDoria

User metadata
Rank Newbie
Rank
Newbie

Sorry, just been busy in some other side project here. But I am still interested in this new emulator you developed.
Ok, it looks like we are kind of building a machine with all the bits from scratch here. It could take me a while to understand how to set this up maybe because I do not have the correct knowledge about it.
I think this project could have much more visibility if a video on how to set it up and running would be created and made it public on your homepage. It will probably take 10 minutes for someone like me to do it with a video or few weeks of hard work without it. This will allow you to have more user and as a consequence more feedback to develop it faster.
Just let me know, otherwise I will try to get it to work through this post.

Reply 4 of 75, by superfury

User metadata
Rank l33t
Rank
l33t
EmanuelePulciDoria wrote on 2020-04-29, 14:04:
Sorry, just been busy in some other side project here. But I am still interested in this new emulator you developed. Ok, it loo […]
Show full quote

Sorry, just been busy in some other side project here. But I am still interested in this new emulator you developed.
Ok, it looks like we are kind of building a machine with all the bits from scratch here. It could take me a while to understand how to set this up maybe because I do not have the correct knowledge about it.
I think this project could have much more visibility if a video on how to set it up and running would be created and made it public on your homepage. It will probably take 10 minutes for someone like me to do it with a video or few weeks of hard work without it. This will allow you to have more user and as a consequence more feedback to develop it faster.
Just let me know, otherwise I will try to get it to work through this post.

I've added a simple getting started page to the manual, with some basic steps on how to get the emulator up and running ( https://bitbucket.org/superfury/unipcemu/wiki … tting%20started ).
Everything after that(besides the configuration and ROMs being ready for use) is pretty much system-specific. So that's the normal steps of installing and booting your OS.

Of course CD-ROM booting isn't directly supported by the BIOSes used, but can be circumvented using the Plop BIOS ROM, with some manual settings in the Plop ROM and it's ROM creation process not using any flashing(just creating the ROM file and name it appropriately(in my case, it's the second ROM, the first being the XT-IDE Universal BIOS ROM). In that way, the XT-IDE BIOS loads first, after which when pressing F8 it loads the Plop BIOS for booting CD-ROM discs.
Edit: Just noticed that the recording app I used(XBox Gaming Bar) didn't record most of the actions I made, only recording a single app... So I have to remake the whole thing once again.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 5 of 75, by superfury

User metadata
Rank l33t
Rank
l33t

Managed to create a video with all the steps in it with some other software(after a few tries (3 or 4) getting the first software to work, failing after about every 10 minutes 😖 ). That was mainly because the original recording software(XBox software) failed the first try after I uploaded it on Youtube(which only recorded the Windows explorer app instead of the other apps used), while the other app quit after each 10 minutes of recording, having to restart the whole process time and time again.
Eventually managed to find my old software I used to record the older videos on Youtube again(ezvid), which I then used to record the whole thing. And then there was the slight issue with the uploading process of said app itself, which was failing on Google's side(saying that the app wasn't approved by Google's guidelines or something like that and that it needs to be approved first), so I then grabbed the already saved video file from the project's folder and uploaded it manually on Youtube. Although it's got no sound as a result(It didn't record any sound either).

Of course normal tutorials usually don't need that software, as I can simply do it within the app itself without closing it in the meanwhile, which is pretty much impossible during this kind of tutorial(since it requires reloading settings and other files and showing things outside the app, which the XBox recording software cannot do).

A link to it can be found in the UniPCemu manual's getting started guide( https://bitbucket.org/superfury/unipcemu/wiki … tting%20started ) and on the itch.io's external links. Simply click on the More information button on itch.io for the link, which can also be found on the manual's getting started guide itself!

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 6 of 75, by mr.cat

User metadata
Rank Member
Rank
Member

Hi superfury, what's the status of the x64 ports? Are they supposed to work?

I got the native 64-bit Linux binary compiled with a "make linux build SDL2", it runs and configuration menus can be used etc.
But when the actual POST is attempted, it just hangs with a black screen (I think I saw it emit a green letter A eventually).

However, if I build a 32-bit Linux binary instead and use it with the exact same settings, that one does work:
It shows me the BIOS banners, counts memory etc.

Tested with Tseng ET4000 and XT BIOS (from XTulator).
To produce a 32-bit binary, I added the flag -m32 to OPTIMIZATIONFLAGS and LDFLAGS in commonemuframework/Makefile.linux.
The --version flag says the version is "UniPCemu build 20201216_0835-336-gda7082be"

Reply 7 of 75, by superfury

User metadata
Rank l33t
Rank
l33t

To build for linux x64 it uses the same command to build it as the 32-bit build, but with the extra x64 parameter added to it.

So: "make linux build SDL2 x64" or "make linux build SDL2 SDL2_net x64".

Also, before building, the configure script will need to be run on linux. That's just running"./configure" in my case (Ubuntu 18.04 LTS).

Also, if you're running the latest-ish commits, you can use an environment variable on Linux(UNIPCEMU) to specify the directory the UniPCemu files reside in. It will otherwise fall back to organisation name "Superfury", application name "UniPCemu". Finally, if none of those are valid or usable, it will fall back to "~/UniPCemu". You can, however, specify UNIPCEMU to be "." . In that case it will use whatever folder you're currently in as the folder containing the files to use (SETTINGS.INI etc.).

The configure script isn't committed into the repository (for obvious system-specific reasons), so you'll need to run ./autogen.sh to create it.

Edit: Just ran on Ubuntu 20.04 inside my Virtualbox VM and it ran without issues (other than the SDL2 bug in terminating the app infinitely waiting on the audio thread to finish or something like that, which seems a SDL2 bug in this case).

Last edited by superfury on 2021-03-24, 16:46. Edited 1 time in total.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 8 of 75, by mr.cat

User metadata
Rank Member
Rank
Member

Thanks, I think I tried it with x64 already at some point but it wasn't recognized as an option. But I'll check that.
EDIT: Just tried it and it's as I remembered...but this x64 keyword isn't really needed because gcc spurts out a 64-bit binary by default (since I'm on a 64-bit host).

make: *** No rule to make target 'x64'. Stop.

These other points I also know from docs, but perhaps it's good to bring them up here as well.
I'm indeed using the UNIPCEMU env variable. If it is not used, it seems the conf files will end up ~/.local/share/Superfury/UniPCemu/ as you said.
Which might not be so obvious (I only found that out by doing some strace'ing...)

However, this same problem seems to be present in the Windows binaries too. I don't have Windows, but I tested running them in Wine and encountered the same black screen symptoms for the 64-bit one.
The 32-bit Windows binary did work in Wine (slowly), but it was very picky about the settings.
(e.g. debug couldn't be enabled - maybe dependent on which BIOSROM.BIN is used).
XT and CGA (or MDA) seemed like the best combo.

Last edited by mr.cat on 2021-03-24, 22:40. Edited 2 times in total.

Reply 9 of 75, by superfury

User metadata
Rank l33t
Rank
l33t

Even in the 64-bit Windows binaries you say? Weird? I'm doing pretty much all development on my Windows 10 64-bit machine using the 64-bit build of UniPCemu (Visual Studio) and it always runs without issues?

Is the screen displaying the CPU percentage in the top left when it's enabled in the settings ( showcpuspeed=1 in SETTINGS.INI )? Is the border of said percentage orange( = CPU not running) or green(CPU running properly and responsive)?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 10 of 75, by mr.cat

User metadata
Rank Member
Rank
Member

OK, that's good to hear. So the Linux 64-bit variant should also work, at least in theory 😁
There might well be a Wine related problem also (as it wasn't exactly perfect with the 32-bit binary).
Btw my Wine setup was very plain: Installed via apt, no mods or frontends of any kind, fresh WINEPREFIX and no winetricks.

The CPU speed indicator did show, but I wasn't paying attention to any coloring. I'll check that out and report back.
(I assume by a "border" you mean the outline of the letters)

EDIT: OK it looks like there is a green outlining in there, but it's a bit hard to see.
To my eyes it seemed like grey, until I opened the screenshot in gimp and got the actual pixel value 😁

Attachments

Last edited by mr.cat on 2021-03-24, 22:37. Edited 3 times in total.

Reply 11 of 75, by superfury

User metadata
Rank l33t
Rank
l33t
mr.cat wrote on 2021-03-24, 17:05:
OK, that's good to hear. So the Linux 64-bit variety should also work, at least in theory :D There might well be a Wine related […]
Show full quote

OK, that's good to hear. So the Linux 64-bit variety should also work, at least in theory 😁
There might well be a Wine related problem also (as it wasn't exactly perfect even with the 32-bit binary, after all).
Btw my Wine setup was very plain: Installed via apt, no mods or frontends of any kind, fresh WINEPREFIX etc.

The CPU load indicator did show, but I wasn't paying attention to any coloring. I'll check that out and report back.
(I assume by a "border" you mean the outline of the letters)

Indeed the outline of the seperate letters. If it's a reddish (I believe it was set to orange border color) color, it means that the thread that does the counting of CPU percentage (should be together with it being 0%) actually determined that the main thread(which handles CPU and hardware) is somehow idling. If it's a green outlined 0%, that means it's actually running, but so slow it's below 1% (so it's somewhere between 0-1% and being rounded down to 0%).

Edit: Also, as a little side note: I've modified the handling of the linux makefile to actually take the gcc as setup by the ./configure command, as well as the other things it set up in the Makefile file to actually start using those. Previously, it would simply overwrite them with the values I've used. But it should actually append it's own settings to those (making them add to the settings that are supplied by the configured settings).

So if you've added a -m32 with the ./configure command, that would actually be ignored by the linux building script (overwriting it with it's own CFLAGS/LDFLAGS/CC etc. values).
Edit: Fixed the issue with the CFLAGS and LDFLAGS in the latest bugfix to be handled properly (was causing recursive handling, which Make didn't like).

Edit: Also, you're right with the x64 parameter not having any effect. It only has effect when used with the Windows and MinGW versions. All others simply rely on the autoconf inputs to determine their output files (as they're only built in one way, depending on the build system).

Also, if you've built for x86 and need to switch to x64 on Linux etc., you'll need to perform a proper full recompile(clean and build) to make sure all files are the proper architecture. Instead of "clean build" you can also use "rebuild" which has the same effect. That's mainly because the windows builds are seperated by x86 and x64, while the linux/android/PSP builds don't have such a seperation (only one architecture used is assumed).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 12 of 75, by mr.cat

User metadata
Rank Member
Rank
Member

Yes that's good advice. Actually I've been bitten by partial rebuilding before, so I've taken the habit to clean up the whole thing and build from scratch if it's feasible.
Sometimes it's useful to also check the binaries with the "file" command to see what you're dealing with.

What's the significance of the green letter A on top of the screen (this is not visible in the screenshot, comes later)? Is it a disc error indicator or something?

Last edited by mr.cat on 2021-03-24, 22:35. Edited 2 times in total.

Reply 13 of 75, by superfury

User metadata
Rank l33t
Rank
l33t

Just tried a true 64-bit build using the configure inputs:

./configure --host=x86_64-linux-gnu
make linux rebuild SDL2 x64
sudo make linux install SDL2 x64

Then just ran UniPCemu. It ran without issues (other than the termination issue when quitting the emulator, which looks like a SDL2 library issue with it's sound rendering thread).

The letters A B C D E F are actually the disk status indicators. A and B light up (always green) when the OS enables said drive motor and is perhaps accessing the disk(just like a real floppy drive), C and D are the hard disks(green for reading, orange/reddish when writing), E and F are green during reads from the CD-ROM drives. There's also a simple red R that shows itself when it's recording audio.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 14 of 75, by mr.cat

User metadata
Rank Member
Rank
Member

I've seen that termination issue before, but it was with SDL1
You can run "ldd ./UniPCemu" to check which libraries it tries to use.
I have both SDL1 and SDL2. Of course, the SDL2 keyword *should* ensure it's using SDL2...

Reply 15 of 75, by superfury

User metadata
Rank l33t
Rank
l33t
mr.cat wrote on 2021-03-24, 17:47:

I've seen that termination issue before, but it was with SDL1
You can run "ldd ./UniPCemu" to check which libraries it tries to use.
I have both SDL1 and SDL2. Of course, the SDL2 keyword *should* ensure it's using SDL2...

It prints the following:

	linux-vdso.so.1 (0x00007ffdc56c6000)
libSDL2-2.0.so.0 => /usr/local/lib/libSDL2-2.0.so.0 (0x00007f092eabe000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f092e95b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f092e769000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f092e763000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f092e740000)
/lib64/ld-linux-x86-64.so.2 (0x00007f09303fe000)

Any idea what's going wrong during termination?
Edit: During the hang, the backtrace is as follows:

Thread 1 "dbgUniPCemu" received signal SIGTSTP, Stopped (user).
__pthread_clockjoin_ex (threadid=140736912967424,
thread_return=thread_return@entry=0x0, clockid=clockid@entry=0,
abstime=abstime@entry=0x0, block=block@entry=true)
at pthread_join_common.c:145
145 pthread_join_common.c: No such file or directory.
(gdb) backtrace
#0 __pthread_clockjoin_ex (threadid=140736912967424,
thread_return=thread_return@entry=0x0, clockid=clockid@entry=0,
abstime=abstime@entry=0x0, block=block@entry=true)
at pthread_join_common.c:145
#1 0x00007ffff7a829f3 in __pthread_join (threadid=<optimized out>,
thread_return=thread_return@entry=0x0) at pthread_join.c:24
#2 0x00007ffff7f4e17b in SDL_SYS_WaitThread (
thread=thread@entry=0x5555574f9640)
at /home/superfury/SDL/src/thread/pthread/SDL_systhread.c:301
#3 0x00007ffff7e9b146 in SDL_WaitThread_REAL (thread=0x5555574f9640,
status=status@entry=0x0) at /home/superfury/SDL/src/thread/SDL_thread.c:433
#4 0x00007ffff7e20e30 in close_audio_device (device=0x5555574e6120)
at /home/superfury/SDL/src/audio/SDL_audio.c:1128
#5 SDL_CloseAudioDevice_REAL (devid=<optimized out>)
at /home/superfury/SDL/src/audio/SDL_audio.c:1583
#6 0x000055555557129f in doneAudio ()
at ../commonemuframework/emu/io/sound.c:1446
#7 0x0000555555571d4c in main (argc=1, argv=0x7fffffffde88)
at ../commonemuframework/emu/main.c:934

Printing the SDL_Thread object:

  state = {value = 0}, errbuf = {error = 0, str = '\000' <repeats 127 times>}, 
name = 0x5555574f9720 "SDLAudioC2", stacksize = 0,
userfunc = 0x7ffff7e1ce60 <SDL_CaptureAudio>, userdata = 0x5555574e6120,
data = 0x0, endfunc = 0x0}
Last edited by superfury on 2021-03-24, 20:05. Edited 1 time in total.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 16 of 75, by mr.cat

User metadata
Rank Member
Rank
Member

OK, so it's using SDL2 (as expected).
I don't know what that hang is about (the switch from SDL1 to SDL2 fixed it for me - also could've been something else entirely).

EDIT: I tried using valgrind (to get some nice kcachegrind process diagrams out) but closing the window kills the whole shebang without a trace. Maybe there's a better way to do that.
EDIT2: Well that was simple. Just use Ctrl-C in valgrind's terminal window (instead of closing the app window...).

Last edited by mr.cat on 2021-03-26, 17:38. Edited 2 times in total.

Reply 17 of 75, by superfury

User metadata
Rank l33t
Rank
l33t

Said SDLAudioC2 thread's backtrace says the following:

#0  0x00007ffff7bb6bf6 in __ppoll (fds=0x5555574e2a80, nfds=3, 
timeout=<optimized out>, sigmask=0x0)
at ../sysdeps/unix/sysv/linux/ppoll.c:44
#1 0x00007fffeee298c1 in pa_mainloop_poll ()
from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#2 0x00007fffeee29ec3 in pa_mainloop_iterate ()
from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#3 0x00007ffff7f1eea0 in PULSEAUDIO_CaptureFromDevice (this=0x5555574e6120,
buffer=0x5555574f8e30, buflen=1024)
at /home/superfury/SDL/src/audio/pulseaudio/SDL_pulseaudio.c:405
#4 0x00007ffff7e1d000 in SDL_CaptureAudio (
devicep=devicep@entry=0x5555574e6120)
at /home/superfury/SDL/src/audio/SDL_audio.c:848
#5 0x00007ffff7e9ad1f in SDL_RunThread (thread=0x5555574f9640)
at /home/superfury/SDL/src/thread/SDL_thread.c:275
#6 0x00007ffff7f4de69 in RunThread (data=<optimized out>)
at /home/superfury/SDL/src/thread/pthread/SDL_systhread.c:78
#7 0x00007ffff7a81609 in start_thread (arg=<optimized out>)
at pthread_create.c:477
#8 0x00007ffff7bc3293 in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Looking further reveals the following:

gdb) info threads
Id Target Id Frame
1 Thread 0x7ffff7a77280 (LWP 4194) "dbgUniPCemu" __pthread_clockjoin_ex (
threadid=140736912967424, thread_return=thread_return@entry=0x0,
clockid=clockid@entry=0, abstime=abstime@entry=0x0, block=block@entry=true)
at pthread_join_common.c:145
* 2 Thread 0x7fffde97f700 (LWP 4201) "PulseHotplug" 0x00007ffff7bb6bf6 in __ppoll (fds=0x555556d0bbc0, nfds=3, timeout=<optimized out>, sigmask=0x0)
at ../sysdeps/unix/sysv/linux/ppoll.c:44
3 Thread 0x7fffde345700 (LWP 4202) "SDLAudioP1" 0x00007ffff7bb6bf6 in __ppoll (fds=0x5555574d7140, nfds=3, timeout=<optimized out>, sigmask=0x0)
at ../sysdeps/unix/sysv/linux/ppoll.c:44
4 Thread 0x7fffddb44700 (LWP 4203) "SDLAudioC2" 0x00007ffff7bb6bf6 in __ppoll (fds=0x5555574e2a80, nfds=3, timeout=<optimized out>, sigmask=0x0)
at ../sysdeps/unix/sysv/linux/ppoll.c:44
(gdb) thread 4
[Switching to thread 4 (Thread 0x7fffddb44700 (LWP 4203))]
#0 0x00007ffff7bb6bf6 in __ppoll (fds=0x5555574e2a80, nfds=3,
timeout=<optimized out>, sigmask=0x0)
at ../sysdeps/unix/sysv/linux/ppoll.c:44
44 in ../sysdeps/unix/sysv/linux/ppoll.c
(gdb) backtrace
#0 0x00007ffff7bb6bf6 in __ppoll (fds=0x5555574e2a80, nfds=3,
timeout=<optimized out>, sigmask=0x0)
at ../sysdeps/unix/sysv/linux/ppoll.c:44
#1 0x00007fffeee298c1 in pa_mainloop_poll ()
from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#2 0x00007fffeee29ec3 in pa_mainloop_iterate ()
from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#3 0x00007ffff7f1eea0 in PULSEAUDIO_CaptureFromDevice (this=0x5555574e6120,
buffer=0x5555574f8e30, buflen=1024)
at /home/superfury/SDL/src/audio/pulseaudio/SDL_pulseaudio.c:405
#4 0x00007ffff7e1d000 in SDL_CaptureAudio (
devicep=devicep@entry=0x5555574e6120)
at /home/superfury/SDL/src/audio/SDL_audio.c:848
#5 0x00007ffff7e9ad1f in SDL_RunThread (thread=0x5555574f9640)
at /home/superfury/SDL/src/thread/SDL_thread.c:275
#6 0x00007ffff7f4de69 in RunThread (data=<optimized out>)
at /home/superfury/SDL/src/thread/pthread/SDL_systhread.c:78
#7 0x00007ffff7a81609 in start_thread (arg=<optimized out>)
at pthread_create.c:477
#8 0x00007ffff7bc3293 in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) frame 5
#5 0x00007ffff7e9ad1f in SDL_RunThread (thread=0x5555574f9640)
at /home/superfury/SDL/src/thread/SDL_thread.c:275
275 *statusloc = userfunc(userdata);
(gdb) frame 4
#4 0x00007ffff7e1d000 in SDL_CaptureAudio (
devicep=devicep@entry=0x5555574e6120)
at /home/superfury/SDL/src/audio/SDL_audio.c:848
848 const int rc = current_audio.impl.CaptureFromDevice(device, ptr, still_need);
(gdb) frame 3
#3 0x00007ffff7f1eea0 in PULSEAUDIO_CaptureFromDevice (this=0x5555574e6120,
buffer=0x5555574f8e30, buflen=1024)
at /home/superfury/SDL/src/audio/pulseaudio/SDL_pulseaudio.c:405
405 PULSEAUDIO_pa_mainloop_iterate(h->mainloop, 1, NULL) < 0) {
(gdb) frame 4
#4 0x00007ffff7e1d000 in SDL_CaptureAudio (
devicep=devicep@entry=0x5555574e6120)
at /home/superfury/SDL/src/audio/SDL_audio.c:848
848 const int rc = current_audio.impl.CaptureFromDevice(device, ptr, still_need);

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 18 of 75, by superfury

User metadata
Rank l33t
Rank
l33t

Currently thinking about a new release. Lot of new features and fixes so far:
- Implemented MMU-induced waitstates to delay giving inputs to the CPU core instead of just delaying the CPU core itself after a read/write.
- Improved settings value capping.
- Implemented the ET4000/W32 extensions to the ET4000AX emulation.
- Improved existing RAMDAC emulation to work properly and be properly detected.
- Added emulation of the Dosbox UMC UM70C178 RAMDAC.
- Added emulation of the AT&T 20C490 RAMDAC.
- Added emulation of the SC15025 RAMDAC, adding support for true-color modes.
- Improved the video subsystem enable registers to affect the (S)VGA as a whole instead of remapping to the memory enable bit.
- Improved Tseng KEY emulation.
- Improved Tseng VRAM size detection and applying.
- Improved Tseng video card detection.
- Fixed Tseng clocking divider.
- Improved ET3000 1M linear memory map bank size to be a proper 256K.
- Improved the Tseng definition of the extended memory bit in the Sequencer Memory Mode register.
- Improved 8-bit vs linear memory modes.
- Improved generic video card initialization for EGA and up.
- Improved (S)VGA data latches to be more cross-platform.
- Improved (S)VGA clock rates and dot clock rates to not be multiplied anymore.
- Improved EGA horizontal total to be +2 instead of +5 clocks.
- Improved VRAM address handling and non-existing VRAM detection.
- Implemented modem break signal emulation.
- Improved SLIP server handling of packets and filtering.
- Improved APIC and IO APIC emulation.
- Implemented a simple memory viewer (16x16 grid) into the debugger.
- Improved 8086 REP and REPNZ prefixes with MUL/IMUL and IDIV instructions undocumented behaviour.
- Improved protected mode structure fetching to be properly done with bus locks.
- Linux-based builds now can use an environment variable (UNIPCEMU) to use for the path of the program's files (an absolute path. The current working directory "." is also allowed).
- Added a setting for setting different luminance modes when in greyscale mode (Averaged and Luminance modes).
- Added a setting for the different DAC modes on the Tseng chips.
- Added a setting to switch between the different ET4000 chips (ET4000AX vs ET4000/W32) (applied when the ET4000 is selected in the VGA chip setting).
- Added various nullmodem configurations to the modem emulation, with a setting to switch between them. These are: simple nullmodem cable, nullmodem cable with line signalling, nulmodem cable with line singalling and outgoing connect using phonebook entry #0.
- Said nullmodem cable can also be connected and disconnected from the settings menu.
- Fixed x86 RCR shift amount masking.

The main issues that currently prevent it are the ET4000/W32 bugs remaining and the Windows issues with the serial modem giving wrong dialing commands.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io

Reply 19 of 75, by mr.cat

User metadata
Rank Member
Rank
Member

Sounds good 😁
My "64-bit black screen problem" can be considered solved. I just tried building UniPCemu on a different host and it works there just fine.
So I'll have to do some comparison to see what that was about. Could be hw related (Intel vs. AMD etc.), but we'll see.
I'll report back here, if I manage to find out the root cause.

Btw new Tseng card coming up 😁
EXCELGRAPH - ISA Video Display Controller (ET4000/W32i)

Maybe ALEKS has some hints about test software for you?