Hypnospace Outlaw

Hypnos desktop

It’s an interesting twist on the typical point & click adventure game. How so? Well simply put it’s all based on web technology! With a big emphasis on that late 90’s vibe! Complete with ‘desktop pets’ animated GIFs, blinking text, and embedded MIDI (and even more sophisticated music).

While it’s obviously not real, the entire ‘web’ is stored locally (even in it’s own lore), it’s still fun to dig around in.

You play as an “Enforcer” basically it’s like back to the AOL days of walled gardens being patrolled by unpaid volunteers. Look for banned content and flag it appropriately. As the game progresses things go off the rails, near riots, helicopter crashes, amputations, culminating in a Y2K crash that kills people.

I totally missed out on this being a crowdfunded thing, and found out from Steam recommendations of all things.

Even for the aesthetic alone, I think it’s worth it. Some of the game play is too much wrapped up into it’s own lore, so paying attention is kind of important.

Added UDP to Qemu0.90

Yes, I know it’s kinda pointless as it’s horribly out of date, but I’m still having fun. Anyways now it’ll integrate with dynamips!

So yeah, in this example, instead of the usual “-net user” and the built in SLiRP stack, this uses UDP to talk to a stand-alone SLiRP stack. This will let you plug your Qemu into virtual Ethernet switches/hubs and interfaces of virtual routers. Even mixing and matching connections to different emulators that use UDP to exchange packets.

In this case I have a VMDK loaded with a NE2K-PCI driver, and QuakeWorld for MS-DOS. I also made the MPU401 external although it’s hanging on a secondary flag…

qemu.exe -L pc-bios -m 64 -soundhw sb16,adlib -mpu401 xx -net nic,model=ne2k_pci -net socket,udp=,remote= -hda qworld.vmdk

This has the Qemu instance listen on UDP port 4000, and connect to the same physical host on port 4001.

The recipical for the SLiRP stack from my bashed Dynamips is:

slirp_rdr.exe 4001 4000

Which in this case listens on port 4001, and connects back on port 4000.

Hopefully it makes some sense to someone.

Download it, if you want!

Download Qemu090b

Degrading qemu performance in DooM Part II

ticks for demo (fewer is better)

VersionASM FixedDiv/FixedMulC

So after the last round, I went ahead and dug out my crap version, where I had just recently found a nice abs() fix for a FixedDiv issue that the old iD code suffers from, and re-built a version of DooM that both used the assembly fixed division, and another with the C version. To compile I used my old GCC to build with the flags:

-m486 -msoft-float -ffast-math -O2 -fforce-addr -fomit-frame-pointer

So here we go using the versions of Qemu that I can build quickly with GCC 3.4.5 MinGW, along with the last two pre-built Win64 builds.

It’s kind of interesting just how close the performance is between the two versions.

Naturally the real test is to run it on actual hardware, and to try a few versions of Watcom C.

Maybe the real takeaway is that Qemu runs GCC built code better…?

Adding DOSBox’s MPU401 to Qemu 0.90

I thought this may be something cool, if not kind of pointless. Anyways the MPU401 UART can be run like a traditional serial port with an IRQ, in intelligent mode, or just as a ‘dumb’ device you can just bit bang to talk to MIDI devices. So while playing with DOSBox I thought it’d be fun to take it’s emulation and plug it into Qemu.

And this is the end result.

It’s far from perfect, when it works it does tend to work well, although it fails to work with things like Return to Zork, but it does work with DMX’s sound code in DooM and the MPU401 driver for Windows 3.1

While doing this I was originally struggling with mapping the IO ports. Qemu has some functions to map in the memory model to assign a function that will trap read/write space. In this case base is 0x330 the base of the MPU401 device.

register_ioport_write(base, 8, 1, mpu401_ioport_write, s);     register_ioport_read(base, 8, 1, mpu401_ioport_read, s);

I was thinking that the port 0x331 needed to be mapped in the same way, but it turns out after looking through more of the source, it’s actually a word aligned access. So in that case you can use a switch to see which port is actually being accessed.

static uint32_t mpu401_ioport_read(void *opaque, uint32_t addr) {
     case 0:
      return(MPU401_ReadData(addr,0)); break;
     case 1:
      return(MPU401_ReadStatus(addr,0)); break;
      return(0xff); break;

Pretty simple, right?

And from there it’s a matter of mapping the DOSBox MPU code, along with the Windows interface code. Since I’m not using intelligent or IRQ mode, I just amputated the code where applicable.

If anyone wants to look at what I did to merge into anything else (and probably do a better job!) it’s on sourceforge as mpu401.c.

Otherwise the binary is available on sourceforge:

Download Qemu090b

Proot, defeating security by ignoring it in user-space

From the proot project site :

PRoot is a user-space implementation of chroot, mount –bind, and binfmt_misc.

Android among other Linux systems creates a very restricted user mode where the end user is denied the root user privileges. This is annoying as to ‘root’ a phone can be incredibly complicated l, and beyond a normal user that wants to use their phone for more than some kind of cat video social machine (don’t tell me the incredible popularity of cat videos isn’t toxoplasmosis!).

Many new phone SOC’s are supporting external HDMI, and USB host capabilities allowing you to dock your phone and use it with a keyboard and mouse.

Well thanks to the app, aptly named UserLand, running a light weight Linux distro is just a few screen presses away!

What is cool is that by emulating a scant few system calls it makes the deployment quick and seemingly trivial. And a lot more lightweight compared to docker, User Mode Linux, or Qemu (in full system emulation). But it can invoke qemu to run foreign architecture binaries to give Intel users an Arm UserLand.

Yes, via VNC you can run X11! And yes on my phone it shows all 8 Cores.

Although I’ve been using qemu, UML and other strategies to sidestep restrictive environments, proot proves itself as an exciting new tool!

End of an era, Linux to Deprecate a.out support

From the post on kernel.org:

Linux supports ELF binaries for ~25 years now. a.out coredumping has bitrotten quite significantly and would need some fixing to get it into shape again but considering how even the toolchains cannot create a.out executables in its default configuration, let’s deprecate a.out support and remove it a couple of releases later, instead.

I can’t say I’m all that surprised, maintaining backwards compatibility has not really been a Linux thing, as most people are incapable of doing any troubleshooting in the myriad of hundreds to thousands of independent packages, and instead find it far easier to switch to a different distro entirely.

At the same time, the vast majority of Linux packages are available in source code, so re-building things as ELF most likely has happened in the last 25 years.

During the great ELF migration, it was a gigantic PITA having basically 2 copies of all the libraries as things were converted over, and a.out stuff quickly evaporated. For me, the beauty of a.out was for later kernels to be able to mount and run older stuff. But as we are in the era of both ‘cheap’ user mode kernels along with virtualization will the old executable format truly be missed?

Linux has survived the removal of native support for the 80386, and even the detection logic for the NexGen processors (yes they were real, and yes they did ship), so no doubt this further amputation won’t matter to the vast majority.

I have to wonder how long until the i386 32bit target is removed? Distros like Debian have long since removed support for 80486/80586 classed processors to bring the minimum up to requiring SSE-2 based instructions, and I can’t imagine anyone who is running a 32bit OS for their main OS in this day and era.

diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig
index f518b47..494eeb5 100644
--- a/arch/x86/um/Kconfig
+++ b/arch/x86/um/Kconfig
@@ -16,7 +16,6 @@ config 64BIT
 config X86_32
   def_bool !64BIT
-  select HAVE_AOUT

Farewell a.out

Update: from further along in the changelog

And Alan Cox points out that the a.out binary loader _could_ be done in user space if somebody wants to, but we might keep just the loader in the kernel if somebody really wants it, since the loader isn’t that big and has no really odd special cases like the core dumping does.

VC6 Ultimate updates

I’ve been trading emails with various people from the project after I had made my post, and helping them integrate more of Visual Studio 2003 into the project and working through a few issues to bring far better compatibility to VS 2003.

And the best part is being able to build projects in parallel!

10.2 seconds in parallel!

I haven’t ordered new processors, so the 2.1Ghz parts are… lacking. However being able to use all available cores makes building DOSBox pretty fast.

Restricting the build to a single process takes 1:13 while the full parallel build on this machine takes a mere 10 seconds!

So absolutely check out VC6Ultimate!

Visual Studio .net Enterprise Architect

I uh, also saw this on archive.org, which may help people looking for this stuff from the future as old tools get harder and harder to find. Especially bigger editions like the Enterprise Architect version.

Degrading qemu performance in DooM

Quick table… its late.

I’m using MS-DOS 5 & this benchmark suite loaded into a VMDK, and ran a few tests to check performance numbers.

version2 3d bench3 chris bencha doom ticksc quake demo

I snagged 3.1.50 from https://qemu.weilnetz.de/w64/

better performance than v2, sure, but for interactive stuff.. not so much.

So what is really going on here? Why is 0.90 so much faster when it comes to doom, and how is it possible that it’s the slowest in raw CPU performance. And fastest at IO? It appears that the crux of the issue is simply how it handles its IO, heavily favoring device performance VS CPU.

I’ll have to follow up with more builds and reading release notes to see what changed between releases. And what was it exactly that broke between gcc 3 and 4, and why the rip had to be.

I still like 0.90, if anything for it’s ability to run NeXTSTEP and NetWare.