I accidentally upgraded vpsland to Debian 8

So yeah, dealing with Apache 2.4 vs 2.2 was… fun.  The security Order stuff is obsolete so that was fun editing all the virtual hosts.

The key parts being:

In this example, all requests are denied.

2.2 configuration:

Order deny,allow
Deny from all

2.4 configuration:

Require all denied

In this example, all requests are allowed.

2.2 configuration:

Order allow,deny
Allow from all

2.4 configuration:

Require all granted

In the following example, all hosts in the example.org domain are allowed access; all other hosts are denied access.

Boy was that fun!

Not to mention the joys of updating perl, and the cvsweb breaking, and I’m sure far more to break.  Oh well, at least it’ll be up to date.  That’s what I get for mixing ‘stable’ with ‘old stable’, when the local mirror out in the UK I was using moved up to 8.

Making MacMiNT self hosting

Compiled in 2015!

Compiled in 2015!

One thing that always bothered me about MacMiNT is that I never could compile JET or MacMint itself.  It requires the headers from MPW 3.2, or better known as the Macintosh Programmer’s Workshop, along with a single library again from MPW 3.2

MPW 3.3 won’t work, which is the only version I’ve had when I bought an extraordinarily heavy FORTRAN compiler for the MAC, Language Systems FORTRAN.  I tried to get dungeon to work with that, but no dice.

But thanks to macgui, they have links to the 3.2 headers & libraries!

It took me a little longer than I’d like to figure out how to build the cross libraries, as I kept running the script from the script directory, not from /mint as I should have (is there any documentation?!).  But I finally built the libmac16.olb and libmac.olb needed for MiNT programs to call the MacOS toolbox!

So now I’m able to compile Hoshi’s 1999 JET and MacMiNT!

For anyone interested, I’ve built a disk image here, that includes everything all ready to go.  It runs great on my latest build of Cockatrice, although I haven’t made any Win32 builds just yet….  I suspect it’ll run on emaculation’s build of Basilisk II it really should only need a 68000 with 8MB of RAM or so.  The disk image is 8MB, and uncompressed onto a hard disk takes up 35MB of space.

I’ve also made a small (100MB) mirror of the umich MiNT & MacMiNT install archives I could find right here.

Also, it runs dungeon,and with a lot of finagling, it’ll even run f2c dungeon! (needs a 68030 or higher).

For those who insist on running this on SheepShaver / Or PowerPC based machines, I’ve found that System 7 and an OldWorld ROM run it best.  System 8.0 and System 8.1 can run it (assuming they were installed as a PowerPC install), but System 8.5 and higher are not very cooperative when it comes to MacMiNT.

MacMiNT on SheepShaver MacOS 8.1

MacMiNT on SheepShaver MacOS 8.1

I suspect it must be the re-write of the nanokernel that PowerPC MacOS is based on.

GSOC bringing MacOS 9 to Qemu

It's some progress!

It’s some progress!

I know it may not look like much right now, but Cormac O’Brien is working on bringing MacOS 9 support to Qemu!  This is really great news as Sheepshaver has painted itself in a corner with it’s CPU code that requires memory access to 0x00000000 which more and more operating systems deny.

So you can download the snap and follow the instructions here. And you too can watch it fail.

Screen Shot 2015-07-20 at 9.57.16 AM

Starting to boot

During the boot you’ll see a message from MacOS on the CLI that it is unable to find a NVRAM partition.  During this time you will either see a bunch of CUDA and IRQ messages, and there is a good chance from here it’ll progress to loading the New World ROM.  If it gets stuck you’ll see tonnes of the following messages:

CUDA: read: reg=0xd val=00
CUDA: read: reg=0x0 val=30
CUDA: read: reg=0xd val=00
CUDA: read: reg=0x0 val=30

From here the screen should turn grey, and again it may or may not go to a happy mac, or again get stuck on the CUDA read 30/00 thing above.

New World ROM loaded

New World ROM loaded

Once it goes New World happy mac, it’ll load MacOS then bomb over one of the extensions.

I tried some OpenBSD for the heck of it, the good news is the kernel loads and starts the boot, but it has some issues with either memory or mapping the PCI bus.

Screen Shot 2015-07-19 at 6.03.43 PM

OpenBSD 5.7

Screen Shot 2015-07-19 at 6.08.31 PM

OpenBSD 3.3

Screen Shot 2015-07-19 at 6.16.02 PM

OpenBSD 4.0

And for the heck of it, Debian 5.0.0

Debian 5.0.0 installer

Debian 5.0.0 installer

I didn’t bother installing but nice to see the installer CD runs fine.

So yeah, sourceforge is still down

sourceforge down

Kind of annoying when I wanted to expand something with mingw, and all their download mirrors are… sourceforge.  And since I finally got around to putting Cockatrice on git but where did I put it? sourceforge.

Seems everyone has a good outage from time to time.  What to do?  Trust more of the cloud?

On Saturday 11AM BST the pages and downloads are back online!

Project pages and downloads back online!

Project pages and downloads back online!

Wolfenstein 3D for DOS/4GW update

If you remember a while back, I had found the ‘missing link’ of Wolfenstein to Wolfenstein SDL, Wolf4GW.  Well Tobias has cleaned it up somewhat, and now it compiles on the latest builds of OpenWatcom 2.0c!

The first thing you’ll notice if you try to compile it, is that now it’s a single source file, that includes all the other modules.  And it compiles FAST, for me 1 second fast.

From the changes:

  • Compiles with OpenWatcom v2.
  • Keys (for Run, Shot…) are shown.
  • Hang with optimization is fixed.
  • Missing Spear of Destiny SignonScreen added.
  • Inter-procedural optimization (unity build).
  • External assembler routines re-implemented in C.
  • Better interrupt enablement /disablement.
  • Dead Code removed or #ifdefined.

So, if you want to Wolf3d, or SPOD, I’d check out Tobias’s Wolf4GW if you have a 32bit capable machine.  The maps load instantly, and it just feels all around much more smoother than the old 8086 code.

re-vamping source code cvs depot

I think it is kind of funny in a way I had set up unix.superglobalmegacorp.com years ago, but moved hosts a few times, and it broke all the CGI functionality.  But all the static pages still worked, so when googling around for internal stuff related to Quake, I would actually find my old site in the top five.

#5 for Sys_FileOpenWrite

#5 for Sys_FileOpenWrite

So, I thought I’d take some time, and get it working again.  I use two programs CVSweb, and src2html.

CVSweb let’s you easily explore multiple revisions, do comparisons between the versions, and just look all around great. I keep a copy of the following:

  • Net/2 This also includes Net/2 derived OS’s 386BSD 0.0 and 0.1, and NetBSD 0.8/0.9
  • DOOM Includes, Heritic, and Hexen
  • truecrypt, the popular disk encryption tool
  • Synchronet the BBS software for MS-DOS, OS/2, Win32 and Linux/BSD
  • Quake, the popular game from iD.
  • QuakeWorld, the multiplayer version of Quake
  • Quake II, the successor to Quake.

I also like how the src2html program parses out the code so you can search for symbols in the code.  However src2html works with static versions of the code, not CVS, so I selected various programs to be available, some from above, and:

So it may not be worth much to most users, but when looking to see how various code works, it’s really useful.  Of course none of this compares to Visual Studio’s search database, but google has to learn from somewhere.

I should also point out that upgrading perl as part of a move from Debian 7 to Debian 8 broke CVS web.  Thankfully the NetBSD folk had a simple 2 line fix!

— cvsweb.orig 2013-12-24 09:58:09.333520125 -0500
+++ cvsweb 2013-12-24 09:58:50.222171067 -0500
@@ -1194,7 +1194,7 @@

General options


EOF
– for my $v qw(hidecvsroot hidenonreadable) {
+ for my $v (qw(hidecvsroot hidenonreadable)) {
printf(qq{\n},
$v, $input{$v} || 0);
}
@@ -2953,7 +2953,7 @@
print ”
\n”;

print ‘‘;
– if (defined @mytz) {
+ if (@mytz) {
my ($est) = $mytz[(localtime($date{$_}))[8]];
print scalar localtime($date{$_}), ” $est
(“;
} else {

So it’s working again.

Porting Quake II to MS-DOS pt4

Bringing it all home for release day.

Bringing it all home for release day.

Since the last update we got some help in a few fields that have really fleshed out this ‘experimental’ port into a full fledged port.  First RayerR helped us with the fun of getting us onto the latest deployment of DJGPP, 2.05 (rc1).  It’s always nice to be in the latest available release.  Next in a passing comment, Ruslan Starodubov had mentioned that he had gotten a much older build of our QDOS to support the Intel HDA sound chipset via the  MPXPlay sound library.  I wrote to the author of MPXPlay, Pádár Attila asking for us to distribute his source in our project, and he granted permission.

So at this point things were looking good.  The only ‘feature’ that modern OS’s really held over us was the ability to dynamically load and unload game modules on the fly.  I had tried to use DLM, but it stripped the DPMI functionality out of the MS-DOS Extender making the port really useless.  I tried to build the newer DXE3 support but had no luck.  I suspect now my native tool chain was interfering with the build process. But Maraakate managed to get it to not only build, but to run!

Adding in DX3 support was relatively painless.  I first looked at DJGPP’s FAQ and downloaded the example code.  In the example code there was small helper functions to make unions and check the symbols.  If they didn’t exist a printf was spit out to alert you about it.  To resolve the issue you simply just add DXE_EXPORT to the other list of missing exports.

Compiling the game code was easy, again referring to the example I saw that basically they compiled it the same, but at link time you use DX3GEN and -U flag to ignore unresolved symbols.

The biggest head scratcher was the Sys_GetGameAPI failing to find GetGameAPI from the DX3.  After some piddling around I noticed that it listed GetGameAPI as _GetGameAPI inside the DX3 itself.  I added the underscore and it worked!

Other things that were relatively to easy to import was R1Q2’s HTTP downloading code.  Compiling CURL was kind of tricky because of the linking order, but thankfully neozeed figured it out quickly.

All of Yamagi’s Quake 2 updated game DLLs were all diff’d by hand using BeyondCompare to make sure I didn’t clash using some newer functions that weren’t available in DJGPP.  I also merged their Zaero code with their baseq2 code by comparing Zaeros code to the Quake 2 SDK, marking every thing that was changed.  The result is a really stable Zaero game code.  If you haven’t played Zaero check it out.  I think it’s a lot better than Rogue, but Xatrix is probably my favourite (even over stock Q2).

Other cool things I’m glad to get into the code was the GameSpy Browser.  It took me quite a bit of work to get it where it is, but it’s really nice to just be able to ping to a master server (a custom GameSpy emulator I wrote specifically for Q2DOS.  Source is not finalized yet, but will be available soon for those curious), pick a server and go!  All in DOS!

So here we are at the end of the journey.  Or at least safe enough for a 1.0 release.

To recap, we have:

* VGA
* SVGA (LFB modes only)
* Mouse
* Keyboard
* SoundBlaster and Gravis UltraSound Family
* CD-ROM music
* OGG music
* Networking (You need a packet driver)
* Loading/unloading game DLLs in DX3 format.
* Intel HDA support -hda
* Mouse wheel support with -mwheel

And I should add, that it works GREAT on my MSI Z87 motherboard.

You can download Quake II for MS-DOS on bitbucket.  And as always the source is available here.

Don’t forget you can always make bootable USB stick with DOS, or CD-ROMs.