Monthly Archives: February 2020

emulator-sun-2

Posted on by
22

Since I was playing with the 68000 based GCC ’87 I know it was going to be more geared to SUN workstations, certainly of the early 80’s vintage as they would be the most ‘affordable/cheap/donated’ to FSF (Or so I’d imagine).

Naturally the go to emulator is TME, however this time while searching around for the install scripts and stuff I found lisper‘s (heeltoe.com) emulator-sun-2, a greatly cut down and SUN-2 focused emulator that emphasizes ease of use.

Wait, what? SUN-2, and ease of use? Why yes, not only that, as it uses SDL 1.2 it also means it’s much easier to compile. After an hour of messing around with it, I had it running on Windows. After a few minutes I had it running on my ARM based Acer NovaGO.

At it’s core is the m68k 68010 emulation from Karl Stenerud‘s Musashi core which is a great choice for the SUN-2 as it’s a 68010 based machine. Some fun notes from web.cuzuco.com/~cuzuco/sun2/ include:

  • CPU is a Motorola 68010 running at 10MHz
  • Maximum physical memory is 4 Megabytes
  • Maximum virtual memory is 16 Megabytes
  • All I/O is via a Multibus (an Intel design)
  • Main disk is a SMD, the largest size is 380Mbyte
  • Has a SCSI adapter, but the disk is slow and small (42Mbyte)
  • Sun was just finishing NFS
  • alludes to future AT&T UNIX System VI and VII
  • Display supported dual heads and a resolution of 1152×900
  • List price as tested: $44,900
  • Sun was still private, had 400 employees and sold 1500 units

You can read about the debut of the SUN-2 in the UNIX/WORLD Magazine, VOlume 1, Number 5 dated October 1984 in archive.org. It starts on page 86.

I started to integrate sigurbjornl’s patches for networking but I think I need to work through SunOS 2.0’s weird VAX 4.2BSD arp issues (anyone have the source code to SunOS 2.0?!). I’ll probably update it with UDP or some fixed ARP thing to remove that or just let the SUN-2 talk to a VAX with 4.2BSD so they can be weird, together.

I’m also pretty sure my old Cockatrice III sort of debugged SLiRP thing broke the packed structs to let it work properly when compiled with Microsoft C, so I’ll have to break down and either try to fix that, or update and borrow the vastly updated SLiRP from SIMH.

For Windows users who want to play along the bundle is on the terribly named page “Ancient UNIX/BSD emulation on Windows” as SUN2.zip.

GCC from ’87 on the 68000

Posted on by
9

Years ago I found the ‘first’ released version of GCC, and had built it for the VAX. And things were… fun.

While digging around on bitsavers for new and interesting things, I saw some newer stuff from MIT, and stumbled into the GNU directory and rediscovered the early GNU software depot.

And I re-built the early GCC to target the 68000 which I’d imagine primarily was for the SUN target.

simple program

Using a simple program I can run it through the pre-processor, and the compiler to get the following assembly:

assembly from ’87 GCC

Then it’s a matter of running it through the cross assembler, uuencoding it, and sending it to the target.

I used the cross assembler from the AtariST cross ‘project’, to get an object file. I fired up MachTen, pasted my object file to the VM, and uudecoded the object.

And yeah, much to my surprise the object file linked fine, and I got my native EXE.

It’s not much of a cross toolkit, and honestly it’s kind of useless… but I thought it was maybe worth a bare paragraph to show the other available target available for the 1987 release of GCC.

Also on the MIT archive is TRIX, the MIT Unix work alike that almost became the GNU Kernel, until Mach stole their hearts, and basically lead them on a wild goosechase.

I haven’t bothered uploading binaries or patches or anything yet, I don’t know if people are interesting in such a fringe thing……

The Jingsha x79 redeemed itself

Posted on by
5

Back on Christmas Eve I struggled to get this board to do much of anything. When it did boot it’d bluescreen Windows with a useless ‘ IRQL NOT LESS OR EQUAL ‘ error. I took it that the board was crap, and just shelved it.

Today however I’m working on another project and I need to emulate a ‘datacentre’ deployment so I’m stuck looking for machines with RAM, and of course cores. They can be slow I don’t care, but I need to run a TONNE of VM’s. I need egress, ingress, routers, policing, domains, email, servers, various databases, some container infrastructure to provision some other apps and all kinds of crap. I’d planned on maxxing this board out to 256GB or more, but it wasn’t playing nice. And now that it’s like the end of the world out here, getting more RAM from China really isn’t going to happen.

So this time I tried something different.

I have this Dell r710 server with a bunch of memory but it’s CPU’s are frankly lacking. I took the 32GB I had reserved for the Jingsha and swapped out 64GB from the Dell to put into here. I also picked up some massive GAMEMAX GM-1650 power supply which I figured would be more than enough for the dual processor board. The PSU clearly was built for a miner, and I had to use some really lame Y cable for the CPU power. I wasn’t sure what would happen if any of it even worked. My expectations were pretty low, and the first few times the board didn’t appear to do anything at all.

Then suddenly it beeped!

Booting Windows 10 from USB

I shoved in a Windows install USB, and it actually booted this time!

I bought some more of those ALSEYE 120mm cpu radiators as they couple with socket 2011 just fine.

Probably the weakest Quadro ever. But it’s low powered compared to anything modern

Although finding an E-ATX case that isn’t some ‘bling surprise’ is kind of difficult. It’s annoying all these ‘glass window’ cases, and other nonsense. What was wrong with IBM AT BEIGE?!

The lack of a boot diagnostic LED display really hurts this board. Clearly there was something about the memory I had it doesn’t like. It ran fine in the Huananzhi dual x79 board, and it runs fine in the Dell r710.

So yeah. Now I have 3 machines with 64GB of ram, and one with 96. It’d be easier to order but here we are.

So 6 weeks later the Jingsha finally did something useful.

One thing to mention as well is that like others have mentioned while running Linux it’s not uncommon to freeze, reboot and other fun things. Meanwhile Windows is fine. What is going on here?!

I enabled NUMA thinking if something was going wrong maybe it’d be isolated to a single NUMA node, and not take down the entire machine. I’m not convinced I was right, HOWEVER I did capture this error message!

Feb 19 07:31:27 rancher kernel: [    5.820094] mce: [Hardware Error]: CPU 1: Machine Check: 0 Bank 7: cc00008000010093

Feb 19 07:31:27 rancher kernel: [    5.821328] mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 7: cc00008000010093

Feb 19 07:31:27 rancher kernel: [    6.812122] mce: [Hardware Error]: CPU 1: Machine Check: 0 Bank 7: cc0069c000010093

Well that’s not good. So what is more interesting, is that I entered the BIOS after hammering F2/DEL like a typical end user and found this in the memory settings:

Memory is being configured as 1333Mhz, incorrectly

As you can see the current memory speed is 1333 MHz.

However as you can see, I’m using hynix 8gb 2rx4 pc3-10600r-9-11-e2 memory sticks, which means they should be clocked down to 1066 MHz. It’s probably a bit premature to write this, but I’m 30 minutes up, which is a record running Linux on the Jingsha.

It feels like RAM is the new Lupus. it’s never Lupus, but it’s always Lupus.

Cross compiling SDL 1.2.15 for ARM Win32

Posted on by
Reply

I was getting this fun error:

C:\proj\ss\SDL-1.2.15\VisualC\SDL>link /dll -out:sdl.dll *.obj winmm.lib dxguid.lib gdi32.lib user32.lib advapi32.lib dxguid.lib uuid.lib dxguid.lib Version.res
Microsoft (R) Incremental Linker Version 14.24.28315.0
Copyright (C) Microsoft Corporation. All rights reserved.

Creating library sdl.lib and object sdl.exp
SDL_dx5events.obj : error LNK2001: unresolved external symbol GUID_SysMouse
SDL_dx5events.obj : error LNK2001: unresolved external symbol GUID_SysKeyboard
SDL_dx5events.obj : error LNK2019: unresolved external symbol IID_IDirectInputDevice2A referenced in function DX5_DInputInit
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_XAxis
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_YAxis
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_ZAxis
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_RxAxis
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_RyAxis
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_RzAxis
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_Slider
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_Key
SDL_dx5video.obj : error LNK2001: unresolved external symbol GUID_POV
sdl.dll : fatal error LNK1120: 12 unresolved externals

Which was NOT easy to track down. Thankfully while amputating and chasing the origin of GUID_Key, I ran across this: cboard.cprogramming.com

I have read various texts that state you must
Code:?

1#define INITGUID

And yes, you do!

In the file SDL-1.2.15\src\video\windx5\directx.h I just added it to the top, and now it’ll build the hacky DLL!

Maybe it’s something for Visual C++ version 19? I don’t know.

Anyway the advantage is now I have full audio for DosBOX!

Luckily updating binaries wasn’t too hard.