NetBSD 1.0 i386

Posted on September 22, 2016 by neozeed

It had just hit me that I’d never actually installed NetBSD 1.0

So here we go! Â For whatever reason Qemu and NetBSD 1.0 see the floppy as a 1.2 MB, so I had to make 1.2 MB images. Â For anyone feeling like shuffling a whole lot of floppies here you go!

For everyone else, here is a pre-installed VMDK + Qemu all set to run (for Windows).

I’ve setup the networking, so you can telnet into the VM, and of course access outside, but remember with SLiRP, things like FTP & NFS aren’t going to work.

NetBSD 1.0 on Qemu

Almost transplanted NeXTSTEP

Posted on September 20, 2016 by neozeed

Disk command errors

I forgot just how crap pci ide controllers and disks can be.

I installed using Qemu 0.9 and having it drive the disk directly. Â Naturally, MS-DOS works fine.

Darwin 1.4.1 installs on Qemu 2.7!

Posted on September 20, 2016 by neozeed

Darwin 1.4.1 on Qemu

I tried the x86 version from Apple’s Darwin web site. Â For those who don’t know Darwin was (is?) an open source version of the OS X kernel and userland. Â This was on parity with the OS X 10.1 release. Â It was notoriously picky about hardware back in 2001, let alone anything today, and much to my amazement it installed fine on Qemu 2.7.

Source code to the packages should be about here. and the ISO is still on Apple’s site here.

Main Quasijarus site is down.

Posted on September 18, 2016 by neozeed

ifctfvax.harhan.org/QuasijarusÂ Archive.org kind of has a snapshot, but nothing for the files.

I put what I have onto sourceforge, since they have all my other unix stuff online…

update

Thanks to our readers the site has been saved!

qjsrc-se53pra0.tar.gzÂ is the source SCCS reconstruction

And here is theÂ 4.3BSD-Quasijarus0c release.

Visual C++ Toolkit 2003

Posted on September 17, 2016 by neozeed

For those 2-3 people still searching for this thing, it’s the old ‘free’ CLI C++ compiler from Visual Studio .NET 2003.

Although Visual C++ .NET 2003 SP1 gives you a later version of the compiler…

I’m not sure if you can service pack this toolkit.

You can download it from my site asÂ VCToolkitSetup.exe

For anyone who wants to run this under newer versions of Windows as I know I can’t install it on Windows 8 or 10, I installed it on my Windows XP x64 machine, and uploaded it here asÂ vc2003toolkit.7z

By the time this came out, Microsoft had started to admit that they had lost serious ground to GCC, as for years they had neglected the low end $99 market that they had dominated during their fights with Borland in the QuickC vs TurboC days. Â Once Borland had withdrawn from the market, Microsoft felt no need to compete and this left plenty of time forÂ GNU tools to take hold in the marketplace. Â This was a stopgap reaction as a prelude to the Visual Studio Express that would happen in 2005 onward.

Elsewhere I’ve been able to find an old Windows 2003 SP1 Platform SDK image, it should certainly let this compiler build far more interesting things. Â Although unless you really need 2003, you really ought to look at newer stuff. Â Unless you like really old stuff, then as a reminder the Win32s 1.1 SDK includes the version 8.00 compiler from 1993 as well. Â You can download it from here:Â win32s-1.1-build-88-msvc32sdev.7zÂ

Happy Mid-Autumn Festival!

Posted on September 15, 2016 by neozeed

Phases of the moon, compiled for 68020 & 68881

As always, fun time to drag out the phases of the moon!

Source code is available at the main siteÂ acme.com

Adding some SSL via Let’s Encrypt

Posted on September 13, 2016 by neozeed

Maybe this will work, maybe it won’t.

I know one thing right off is that the quake server status is ‘mixed content’ aka it’s retrieved over http.

The new version of Chrome is going to start alerting to non HTTPS sites, so it’s only a matter of time before everyone else starts to require it.. Sigh.

CP/M Exchange and the CP/M Player

Posted on September 13, 2016 by neozeed

Exchange & CP/M Player

While on the road, I stumbled onto a link that referred to this program called Exchange, which is a decapitated ‘port’ of CP/M that simply allows you to read and write CP/M disk images. Â While on the surface it may not seem much, but the fact it actually uses the 68000 kernel from CP/M seemed really interesting to me. Â With minor fighting I had it running on MinGW!

http://anachronda.homeunix.com:8000/~rivie/exchange/

And what fun would that be if we left it there? Oh sure you can get files in and out of standard 8″ images, but can you run them?

Over at the Takeda Toshiya’s page, not only does he make the MS-DOS player, and a whole host of other Japanese machine emulators, but he also has a CP/M player that works in the same style!

http://takeda-toshiya.my.coocan.jp/

So, combine the two, and now you too can trivially export and import files for emulators like SIMH, or just run files naively at the Win32/Win64 command line!

Porting DooM to the x68000

Posted on September 11, 2016 by neozeed

Getting started

DooM is without a doubt one of the most popular PC games of all time. Â And thanks to it being written in C is also an incredibly portable game. Â One platform that mysteriously was lacking DooM was the SHARP x68000.

After a bored day of playing with the source to Mariko’s GCC 1.42 / 1.30 that targets the x68000, I thought I would take a stab at trying to compile DooM. Â Since I’m using such an ancient version of GCC the first stumbling block is that DooM is FULL of C++ style comments, which older K&R & ansi based compilers of the late 1980’s simply cannot handle. Â So the first phase was to convert all the comments.

In order to convert the comments, I came across this great tool, uncrustify. Â The pain is that it doesn’t seem to take wildcards, but you can use make to have it do your work for you, or just a batch file…

uncrustify.exe --replace -c 1.cfg cl_main.h

you get the idea.

The key thing is the configuration file that tells uncrustify what to do. Â To convert C++ comments to C is quite simply:

cmt_cpp_to_c = true

And away we go. Â Having learned the ‘null’ lesson of Quake 2 the hard way, I started out with a working copy from Windows, via GCC 1.40 for Windows/RSXNT. Â I figured that by having a ‘known good’ build with the a very close compiler level would be a good start as I don’t want to fight too much with the compiler. Â After it was running with minimal changes, it was time to start the real fun.

Starting the actual port aka platform issues

The first error I hit was:

Error: Couldn’t realloc lumpinfo

For some reason the SHARP/Hudson LIBC has issues doing a realloc. Â I have no idea why. Â Over onÂ nfggamesÂ Neko68k had mentioned that he had a disk image with a working version of GCC, that uses different includes/libraries that was able to get further. Â I wasted some time by trying to bypass the Sharp LIBC malloc function by calling the HumanOS’s malloc directly which did get further but ran into issues when switching from usermode to supervisor mode to directly access the hardware. Â Once when he shared his disk image, I was able to see how his GCC setup worked, and more importantly linked, so I could alter the GCC cross compiler I was using, and get much further in terms of progress. Â I could then get from failing malloc to this:

startup errors

And from there after trying different assemblers, flags, and all kinds of other things we could finally get null DooM running on the x68000 via 68030 emulation on XM6 TypeG.

null DooM running on the x68000

DooM comes to life

From there, Neko68k was able to do something amazing, add in system support! Â Which to be honest would have taken me forever to do, I was more impressed that I was even able to get the null version running, but Neko68k blew me away with this:

There is no correct palette setup at this point, there is all kinds of issues but you can see the startup logo being painted!

Then with a lot of improvements, and an added keyboard driver it was starting to look like DooM!

And then Neko68k had a major breakthrough with the video, timer and keyboard, and we now have a playable port!

Issues while cross compiling

Around this time I had noticed that when I built a cross compiled version the video for me was garbled. Â After some investigating it turns out that m_swap was not being compiled correctly but rather the endian order was being reversed!

Â .dc.l $00000000,$40f00000

instead of:

.dc.l $40f00000,$00000000

I tried re-building, re-configuring my host setup, and I still had the same issue. Â I tried downloading GCC 1.42 and building an i386 SYSV to AT&T 3b1 cross compiler as it too is 68000 based, and I got the same issue. Â Maybe it’s a bug in GCC 1.x cross compilers? Â I don’t know, but since the procedure is small enough, it was easier to just have the native GCC produce an assembly version which I just assemble and link without issue.

Behold! DooM on the x68030!

Yes, there is no audio, but wow it’s playable! Â I do need to map the keyboard better in the emulator, but the key layout in the source is fine.