Category Archives: 80386

I’m not dead

Posted on by
3

It’s just been really busy with this move, unpacking and the usual losing things, finding things and breaking things.

In the middle of it all, I found something online, that I want to at least do some proper article thing about… As it’s been really exciting, and goes back to the first month I started this blog.

Outside of NeXTSTEP, the other i386 commercial version of Mach 2.5 surfaced, the Mt Xinu version!

Even better, a few years ago, I had stumbled onto the source code for 2.5 buried on the 4th disc of the CSRG set, and with a LOT of luck and persistence I can confirm that the sources are complete enough to build.

loading vmunix.sys
rearranging symbols
text	data	bss	dec	hex
389088	45564	101364	536016	82dd0
ln vmunix.sys vmunix; ln vmunix vmunix.I386x.STD+WS-afs-nfs

However, as luck always has it, start.s in the i386 code does something weird at the 3GB mark causing a triple fault on any kind of modern emulation/virtualization setup.

    / Fix up the 1st, 3 giga and last entries in the page directory
    mov     $EXT(kpde), %ebx
    and     $MASK, %ebx

    mov     $EXT(kpte), %eax
    and     $0xffff000, %eax
    or      $0x1, %eax

    mov     %eax, (%ebx)
    mov     %eax, 3072(%ebx)        / 3 giga -- C0000000

    mov     $EXT(kpde), %edx
    and     $MASK, %edx

Not all that sure why, but at least on Bochs, I can see the triple fault. 

00036527018d[CPU0  ] page walk for address 0x0000000000101122
00036527018d[CPU0  ] page walk for address 0x00000000e0000011
00036527018d[CPU0  ] PDE: entry not present
00036527018d[CPU0  ] page fault for address 00000000e0000011 @ 0000000000101124
00036527018d[CPU0  ] exception(0x0e): error_code=0002
00036527018d[CPU0  ] interrupt(): vector = 0e, TYPE = 3, EXT = 1
00036527018d[CPU0  ] page walk for address 0x00000000c0161370
00036527018d[CPU0  ] PDE: entry not present
00036527018d[CPU0  ] page fault for address 00000000c0161370 @ 0000000000101122
00036527018d[CPU0  ] exception(0x0e): error_code=0000
00036527018d[CPU0  ] exception(0x08): error_code=0000
00036527018d[CPU0  ] interrupt(): vector = 08, TYPE = 3, EXT = 1
00036527018d[CPU0  ] page walk for address 0x00000000c0161340
00036527018d[CPU0  ] PDE: entry not present
00036527018d[CPU0  ] page fault for address 00000000c0161340 @ 0000000000101122
00036527018d[CPU0  ] exception(0x0e): error_code=0000
00036527018i[CPU0  ] CPU is in protected mode (active)
00036527018i[CPU0  ] CS.mode = 32 bit
00036527018i[CPU0  ] SS.mode = 32 bit
00036527018i[CPU0  ] EFER   = 0x00000000
00036527018i[CPU0  ] | EAX=e0000011  EBX=0015f000  ECX=00161dc1  EDX=0015f000
00036527018i[CPU0  ] | ESP=0000efbc  EBP=0000efbc  ESI=00193fb8  EDI=00009d84
00036527018i[CPU0  ] | IOPL=0 id vip vif ac vm RF nt of df if tf SF zf af PF cf
00036527018i[CPU0  ] | SEG sltr(index|ti|rpl)     base    limit G D
00036527018i[CPU0  ] |  CS:0028( 0005| 0|  0) 00000000 ffffffff 1 1
00036527018i[CPU0  ] |  DS:0020( 0004| 0|  0) 00000000 ffffffff 1 1
00036527018i[CPU0  ] |  SS:0010( 0002| 0|  0) 00001000 0000ffff 0 1
00036527018i[CPU0  ] |  ES:0020( 0004| 0|  0) 00000000 ffffffff 1 1
00036527018i[CPU0  ] |  FS:0000( 0005| 0|  0) 00000000 0000ffff 0 0
00036527018i[CPU0  ] |  GS:0000( 0005| 0|  0) 00000000 0000ffff 0 0
00036527018i[CPU0  ] | EIP=00101122 (00101122)
00036527018i[CPU0  ] | CR0=0xe0000011 CR2=0xc0161340
00036527018i[CPU0  ] | CR3=0x00000000 CR4=0x00000000
00036527018i[CPU0  ] 0x0000000000101122>> add byte ptr ds:[eax], al : 0000
00036527018d[SIM   ] searching for component 'cpu' in list 'bochs'
00036527018d[SIM   ] searching for component 'reset_on_triple_fault' in list 'cpu'
00036527018e[CPU0  ] exception(): 3rd (14) exception with no resolution, shutdown status is 00h, resetting

Mach 3.0 doesn’t do this, so I’ll have to dig far deeper into start.s which is kind of really beyond me.

Building a boot disk … is involved. 😐

rm -rf /usr/src/mach25-i386/obj
mkdir /usr/src/mach25-i386/obj
cd /usr/src/mach25-i386/standi386at/boot
make fdboot
/home/user/mkfs /dev/rfloppy 2880 18 2 4096 512 32 1
dd if=/usr/src/mach25-i386/obj/standi386at/boot/boot.fd of=/dev/rfd0d
/home/user/fsck -y /dev/rfloppy
cd /usr/src/mach25-i386/
make
mount /dev/floppy /mnt
cp /usr/src/mach25-i386/obj/STD+WS-afs-nfs/vmunix /mnt
sync
umount /mnt
/home/user/fsck -y /dev/rfloppy

So, I’m not all that dead. For anyone super impatient, you can download my VMDK here, which runs on Qemu & VMware, it includes a serial terminal on COM1 so you can use a real terminal, and if you are like me, uuencode/uudecode files in & out of the system. As always read the 404 page for the current username/password.

PCem v15 released!

Posted on by
5

The new dynamic recompiler appears to be much more faster, although if you want maximum performance, make sure to set your video card to the fastest possible performance.

I was doing my typical DooM thing, and the performance was abysmal. But I did have an 8bit VGA card selected, so what would I really expect? Interestingly enough in ‘low resolution’ mode it performed quite well, but setting it to the artificial ‘fastest PCI/VLB’ speed it was performing just great.

PCem v15 released. Changes from v14 :

  • New machines added – Zenith Data SupersPort, Bull Micral 45, Tulip AT Compact, Amstrad PPC512/640, Packard Bell PB410A, ASUS P/I-P55TVP4, ASUS P/I-P55T2P4, Epox P55-VA, FIC VA-503+
  • New graphics cards added – Image Manager 1024, Sigma Designs Color 400, Trigem Korean VGA
  • Added emulation of AMD K6 family and IDT Winchip 2
  • New CPU recompiler. This provides several optimisations, and the new design allows for greater portability and more scope for optimisation in the future
  • Experimental ARM and ARM64 host support
  • Read-only cassette emulation for IBM PC and PCjr
  • Numerous bug fixes

Thanks to dns2kv2, Greatpsycho, Greg V, John Elliott, Koutakun, leilei, Martin_Riarte, rene, Tale and Tux for contributions towards this release.

As always PCem can be downloaded here:

Cross compiling to the Atari ST

Posted on by
14

This was a lot harder than it should have been. And not because of gcc or surprisingly ancient binutils.

I didn’t have much to go on, as ancient threads like this, or this end up unanswered or without any good conclusion. I guess it’s not surprising that all the attention is to MiNT & MINIX rather than the native platform. But I was not deterred.

The reason why this was so freaking hard was how so much of key parts of gcc for the ST have been purged and what remains being scattered to the winds. Amazingly the hardest thing to source is the include files. There is a GCC 1.30 file on all the usual GNU mirrors but to save a few kb it has no headers, instead it wants you to reuse the ones from the 1.25 binary distribution. Which is gone. There survives a pl95 binary and source package, but again no includes. Instead I got lucky with all three for pl98. Which has a lot of GCC2 hooks so I cheated on getting the 1.30 hello world by using the 2.5.8 pre-processor.

It’s kind of annoying how all these seemingly tiny files get purged to save a few kb. Just as I can’t for the life of me find the old original GNU libc.

Speaking of files, ZOO has to be the worst compressor ever. Not only is it just overall worse than ZIP, but there are 2 incompatible compression methods, like the introduction of LZD, which any of the good versions of UNZOO can’t deal with. And sure there is zoo210.tar.Z but despite being able to build it on multiple platforms it never does anything useful. All these ancient fileformats sure don’t help anything. And sure there is a MS-DOS version that the MS-DOS Player can run, but get ready for 8.3 filename renaming.

The one good thing that came out of this experience is that since I am building form i386 to 68000 I found that this setup uses the G++ linker which has endian swapping. So maybe I can complete the chain for Mint and MachTen.

I even got the 1987 Infocom interpreter running. Although I don’t know what the deal is, it seems the larger the GCC based program is the higher chance it’ll just crash on exit or force the next program to crash. Building anything native under emulation was an impossibility.

In the same effort, I’ve had the same luck with sozobon. It took way too long to find a working dlibs. I don’t know why people couldn’t either package them together or at least in the same directory. It took far longer just to find the libs… But it was still fun to get that one running as well.

It’s a far more manual process to compile as I have to invoke each stage manually, but at least I’m finally able to get things going.

One of the bigger issues is that I would always find libraries in this olb file format, that the linker from Sozobon wouldn’t recognize. And almost every attempt of trying to build the G++ linker would also fail on. It wasn’t until I was able to get the pl98 include files that I could finally get a linker to actually recognize this … seemingly different for no apparent reason format to actually link. After then I managed to finally find a build of this dlibs that would actually link with Sozobon, which naturally didn’t use olb at all.

So yeah that was an adventure.

I haven’t cleaned it up at all, and really wouldn’t expect anyone else to care, but all my mashed together work (source & binaries!) is here: MinGW-AtariTOS.7z

UPDATE

I started browsing more cd.textfiles.com and amazingly found a ‘home made CD-ROM set’ of Atari software, and buried in the gigabytes of stuff was 4 of the 5 disks of the original GCC-1.23! Namely the source & includes to the first GCC library. I didn’t think this article was going to get any traction, let alone downloads. So many people downloaded the above download.

Anyways I started to put together a better package on sourceforge since it’ll do the multiple GIT’s and nicer downloads.

Download crossAtariST

The default download set is for GCC-1.30, with the headers & lib, along with source. It’s crazy small which just goes for how this old stuff is, and how impact full for losing a few kb.

Also the shell that you use apparently makes a BIG difference. The shell that I was using EmuCON doesn’t show any output from the GCC 1.x libs. However other shells most certainly do. I’ll have to do another update regarding shells/emulation.

68000 and i386 C Compiler Version III on Windows

Posted on by
Reply

While looking around for simple compilers to see how easy it is to modify their assembly output syntax, I ran across this tiny file, cc68iii3.zip which bills itself as:

This compiler consists of various modules that build up a
front end — these modules are common to all versions of
this compiler — consisting of parser, analyzer and optimizer,
of modules that are specific for the target processor,
namely *68k.c (for the 68000) and *386.c (for the i386),
and of assembly language output modules that are further
dependent on the (syntax of the) target assembler.

Well isn’t that interesting! So instead of doing something 68000 based, I setup the i386-gas compiler, and tried it with MinGW. And amazingly a hello world program worked!

C:\temp\ccc\cc\infocom> type hello.c
void main(){printf("Hello World!\n");}
C:\temp\ccc\cc\infocom> ..\c386gas hello.c hello.s

C:\temp\ccc\cc\infocom> gcc hello.s -o hello

C:\temp\ccc\cc\infocom> hello
Hello World!

C:\temp\ccc\cc\infocom> type hello.s
        .file   "C386GENERATED"
        .version        "C386 V 1.0"
        .optim
c386_compiled.:
        .text
L1:
        .byte 72,101,108,108,111,32,87,111,114,108,100,33
        .byte 10,0
        .align 2
_main:
pushl %ebp
movl %esp,%ebp
pushl $L1
call _printf
popl %ecx
leave
ret
.globl _main
.globl _printf

C:\temp\ccc\cc\infocom>

Well that was unexpected, but great! So I thought I’d modify the simple Infocom interpreter to build with this. I came up with this as a block for gnumake to read in a Makefile

%.o:    %.c
        $(CC) $(CFLAGS) -E $<  -o $*.i
        c386gas $*.i $*.s
        as $*.s -o $@
        rm -f $*.i $*.s

The key substitute is $* which is the 'root' of the file being passed in. Although it's lame doing it this way but it works in a nice automatic enough fashion.

The compiler must be K&R only as it doesn't like standard includes, so I built file.c/io.c/term.c using GCC but all the rest were able to be built just fine. And even better it works!

Infocom '87

Although I'd never recommend using something like this in a place that matters. If anything GCC 1.x is probably a better choice, but it's still kind of neat.

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

Posted on by
5

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 select ARCH_WANT_IPC_PARSE_VERSION select MODULES_USE_ELF_REL select CLONE_BACKWARDS

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.

Virtual Xenix & the internet pt 2

Posted on by
22

So retrohun is doing their blog thing on github of all things, and the latest entry, is of course Xenix tales. As mentioned in comments on this blog & other places they found another driver for Xenix TCP/IP!

Going back years ago, the tiny NIC driver support for the elderly Microsoft/SCO Xenix 386 v2 included 3COMA/B/C and SLIP. However it’s been recently unearthed that D-Link had drivers for their DE-100 & DE-200 models, and as it happens the DE-200 is a NE-2000 compatible card!

That means that Qemu can install/run Xenix, and it can get onto the internet* (there is a catch, there is always a catch).

You can download the driver either from github or my password protected mirror. Simply untar the floppy under Xenix (tar -xvf /dev/fd0) and do the install via ‘mkdev dlnk’

Setting up the driver is… tedious. Much like the system itself. I found Qemu 0.90 works great, and is crazy fast (in part to GCC 3) even though Qemu 0.9’s floppy emulation isn’t good enough to install or read disks. With all the updates to Qemu 3.1 use that, it’ll read the disks, and allow for networking.

To give some idea of speed I ran the age old Dhrystone test, compiled by GCC 1.37.1 and scored the following:

Dhrystone(1.1) time for 5000000 passes = 8
This machine benchmarks at 625000 dhrystones/second

When compared to the SGI Indy’s 133Mhz R4600SC score of 194,000 @ 50000 loops that makes my Xeon W3565 322 times faster, under Qemu 0.90! And that’s under Windows!

Setting up the commandline/launching is pretty much this:

qemu.exe -L pc-bios -m 16 -net nic,model=ne2k_isa -net user -redir tcp:42323::23 -hda ..\xenix.vmdk
added SLIRP
adding a [GenuineIntelC] family 5 model 4 stepping 3 CPU
added 16 megabytes of RAM
trying to load video rom pc-bios/vgabios-cirrus.bin
added parallel port 0x378 7
added NE2000(isa) 0x320 10
pci_piix3_ide_init PIIX3 IDE
ide_init2 [0] s->cylinders 203 s->heads 16 s->sectors 63
ide_init2 [1] s->cylinders 0 s->heads 0 s->sectors 0
ide_init2 [0] s->cylinders 2 s->heads 16 s->sectors 63
ide_init2 [1] s->cylinders 0 s->heads 0 s->sectors 0
added PS/2 keyboard
added PS/2 mouse
added Floppy Controller 0x3f0 irq 6 dma 2
Bus 0, device 0, function 0:
Host bridge: PCI device 8086:1237
Bus 0, device 1, function 0:
ISA bridge: PCI device 8086:7000
Bus 0, device 1, function 1:
IDE controller: PCI device 8086:7010
BAR4: I/O at 0xffffffff [0x000e].
Bus 0, device 1, function 3:
Class 0680: PCI device 8086:7113
IRQ 0.
Bus 0, device 2, function 0:
VGA controller: PCI device 1013:00b8
BAR0: 32 bit memory at 0xffffffff [0x01fffffe].
BAR1: 32 bit memory at 0xffffffff [0x00000ffe].

In the file /etc/tcp the default installation does a terrible job of setting up the NIC. I changed the ifconfig line to this:

ifconfig dlink0 10.0.2.15 -trailers broadcast 10.0.2.255 netmask 255.255.255.0

Which at least brings it up a bit better. I added in a gratuitous ping also in the startup script to build the arp for the gateway.

ping 10.0.2.2 32 1

Which brings us to the next point, the routing command is broken after loading the D-Link driver. I tried all the available TCP/IP drivers for Xenix (1.1.3.f 1.2.0e).

# route add default 10.0.2.2 1
add net default: gateway 10.0.2.2 flags 0x3: No such device or address

So no dice there. And yes, for SLIP/no interfaces the route command works as expected, just not with the DLINK driver.

However local connections from the host machine do work, so yes, you can telnet into the VM!

Welcome to 1990!

This makes using Xenix far more usable say for managing files, control/compiling etc.

For you die hard IRC fans, all is not lost, you can simply run a local proxy (See: Teaching an old IRC dog some new tricks) on your host machine, and point the irc client to 10.0.2.2

IRCII on Xenix/Qemu

So there you go, all 20 Xenix fans out there! Not only a way to get back online, but to do it in SPEED!

Thanks to Mark for pointing out that there has been tremendous progress with version 3.1 of Qemu, and it’s TCG user speed is up to the 0.90 levels of speed (at least with dhrystone/Xenix), and it just takes a little (lot) of massaging to get up and running with Xenix with the right flags:

qemu-system-i386.exe -net none -L . -m 16 -hda xenix.vmdk -device ne2k_isa,mac=00:2e:3c:92:11:01,netdev=lan,irq=10,iobase=0x320 -netdev user,id=lan,hostfwd=tcp::42323-:23

This is based off my old post, Running Netware 3.12 on Qemu / KVM 2.8.0 although with a few more flags to assert the user mode tcp redirect.

I’m using Stefan Weil’s build of the x64 native i386 Qemu.

win86emu: the greatest thing for Windows RT that Microsoft should have made.

Posted on by
8

While I’m writing this, I’m listening to Neuromancer via WinAmp & the ancient Speex plugin I had updated about 8 years ago.

x86 node running on Windows RT

I took my Surface, and downgraded it to the North American 8.0 version without updates, added my MS ID, and from there ran the jailbreak and win86emu (sometimes called x86node) and from there I was able to run some simple Win32 exe’s.

Even though I had done a simple cut down QuakeWorld port with the GDI only display, using win86emu it’ll run the 80386 build as well.  while I haven’t thrown much at it, I’m just amazed that so far things are working.

When you think that between the jail-break to unlock the ability to run programs combined with a CPU translator, and Win32 to Win32 thunk / translation program, why on earth did this thing ship without it?  It’s amazing that between trying to launch a platform with no inertial for applications after Android &  Apple were selling millions of hardware units, and billions of software units, and cutting the past applications.  It’s just crazy.

And then Microsoft did their normal thing when something goes wrong, which is basically end it, and destroy all evidence it existed.  There is no Windows 10 upgrade for the Surface, even though Windows 10 IOT has been hacked to run from a USB stick on the Surface, but it’s insanely slow.

I figured since this is kind of hard to find I’ll just mirror it on Source Forge… along with the source.

WineVDM 0.5.0 released!

Posted on by
11

This version has MANY issues fixed, and is capable of running more and more Win16 software on Win64 based OS’s.

Printing on paper!

One of the more exciting things is that as long as I do a print setup first, I can actually print on a new printer from MS Word 2.0c!

You can download it from the releases page here:

https://github.com/otya128/winevdm/releases/tag/v0.5.0

Unloading some BSD/OS CD’s

Posted on by
4

I was kindly sent these a while ago from an avid reader, and I tried to get them to boot up into anything useful and didn’t get anywhere.  I’m sure emulators of today are probably up to task, be it Bochs/PCem/86Box or even Qemu.

So they are now up on archive where I also found version 4 up there so I may as well flesh out the collection.

Enjoy!

Windows/386 v2.0(3)

Posted on by
16

Unknown disk on Ebay…

I stumbled onto these three disks, seemingly out of place in history.  Windows/386 version 2.0 is a strange one in that it shipped to OEM’s in late 1987, making it & Xenix part of the initial 386 wave of Operating Systems/Environments and beating out not only the OS/2 launch in 1988, but taking advantage of the 80386’s v86 mode, something that OS/2 wouldn’t be able to do in a shipping product until 1992. 

This version itself appears to be a retail version of Windows/386 lacking any clear OEM identification that was so prevalent for the era.  Indeed setting it up it offers a few interesting platforms:

Getting this to run was a little bit of a challenge as much as I prefer Qemu, these older 2.0x versions of Windows/386 have a BIOS/disk incompatibility with the hypervisor resulting in errors reading the hard disk.  Although PCem/86Box have no such issues.  I think it’ll run off floppy/CD-ROM/Network without any issue though.

Windows/386 v2.03

Once installed it reveals itself to be version 2.03 of all things.  While I was hoping for some kind of retail version of 2.00/2.01 this appears as close as it may get as it has more in common with the PCjs version of 2.01 (which you can try live on his site!)

The PCjs version of 2.03 has 138 setup files (not counting the PIFs), compared to the eBay’s 141, while the PCjs 2.01 has 59 files.

That said, well it’s Windows/386 mostly from 1987 with slightly updated EGA/CGA VMM drivers from early 1988 that just didn’t quite make the cut.  To me what is confusing, is that it identifies as 2.03 while it’s closer to 2.01 in file count and functionality, unlike 2.03 it really ought to have been a 2.02, if there even was such a thing.

Windows/386 2.03 in CGA

Otherwise it’s really not all that interesting short of the timestamp.  It’ll run on CGA/EGA *IF* you have the proper adapter in place, although VGA is compatible, the environment will detect that it’s not actually the proper card and refuse to run.  I tried to put in the 2.01 CGA/EGA drivers, but that resulted in an OS version mismatch (I didn’t check if 2.01 was locked to the Compaq OEM of MS-DOS)

No mixing drivers!

I installed the infamous pair Word & Excel.  Despite Word 1.1a demanding at least Windows 2.11, it appears to run okay.  Excel 2.1d loaded without complaining.  There isn’t very much convential memory for either, but they both can use expanded memory, which the hypervisor can create and share out without any emm386 or any equivalent driver.  I can only imagine the incompatibles of trying to balance these drivers at the time, and how much the coming DPMI specification was needed.

Memory trouble in Windows 2.x

 And as the old saying goes the three top problems in Windows version 2 is memory, memory and memory.  Trying to run anything graphical will exhaust convential ram, forcing you to single task anything graphical which kind of defeats the whole point of Windows.  You go from this:

BattleTech CGA in a Window

To this:

Windows is out of memory!

Oh well it’s 1987, and users were kind of used to being disappointed as such.  It’s really no wonder why Windows 3.0 became the smash it it was.

And of course you can't talk about Windows/386 without this gem. (Video in MPEG-1/Audio MPEG-2 care of JSMpeg).