Author Archives: neozeed

The Commodore Amiga

Posted on by
3

I was enjoying that great site, stumbleupon when I came across a commented listing of the Amiga 1.2 ROM. Then it hat hit me, I’ve never really written about some of the great emulators for the Commodore Amiga.

Back when I was in highschool I wanted a Commodore Amiga, as at the time I was stuck with a Commodore 64. However the world was starting to accept the IBM PC swing of things. Windows 3.0 was out, suddenly the protected mode of the 80286 could be exploited for only a few hundred dollars, vs the thousands for a UNIX port, or what OS/2 cost. And of course the big appeal at the time was that you could build your own PC in a kit fashion (well it still is!). So I was toying with the idea of buying this 286 8Mhz board for $30 CDN when I saw this program that a kid had brought in… It needed VGA, but it could apparently emulate a Commodore Amiga!

You can still download it here.

Running it just simply threw up a picture of the Amiga’s insert a workbench diskette, and clicked the drive madly.. Passing it through a hex editor showed a copy of an Amiga ROM tacked on the end, but it didn’t actually emulate anything.

But I didn’t realize it at the time, and it cemented my decision to buy the 286.

Years later and the topic of m68k emulation came up, as there were simple cross assemblers and simulators, and I can remember in college searching to see if anyone had started an Amiga emulator… And there was one project!

UAE

Originally it stood for “Unusable Amiga Emulator” and well it was unusable. But then with enough people starting to flock to the project it suddenly could boot AmigaDOS. I used to use this on MS-DOS back in the day for ‘maximum’ speed. I was able to find one ancient version of this 0.65 that still has an MS-DOS exe. And it runs great under DOSBOX. You can find it here.

And for the heck of it, here is a screen shot with a 1.3 ROM.

UAE 0.65 under DOSBOX

UAE 0.65 under DOSBOX

Naturally transferring disks was a major pain in the butt… I luckily had a friend with a working Amiga and cross dos for AmigaDOS all configured so I could transfer some terminal emulator to my poor Amiga 500 I had picked up at a used hardware store in college. Then I used what I could of ramdisks, compression programs and whatnot to upload via some 50 foot nullmodem cable I had to transfer ADF’s of my workbench disks and an old favorite game of mine, Captain Blood. Even back at the time, Commodore was bankrupt their future was bleak. Getting spare parts then was becoming hard for my Amiga 500. And my 486SX-20 could almost run at an acceptable speed in emulation..

But time marches on.

UAE was then ported to Linux & X11, and the SVGA lib. I had some old RS232 terminal so I could keep on using my machine to ‘work’ and still play console vga stuff like doom for SVGAlib and of course UAE. Now with CPUs in the GHz++ speed range, emulation of a 8Mhz machine with 3 custom chips is more in software then raw cpu speed. The UAE project kind of died off, there hasn’t been any big updates in years, but the CPU core work lives on in all kinds of m68k derived work.

There is no doubt that there is still a few closeted Amiga users out there, but I suspect that we don’t kick up UAE all that much these days.. But it’s still cool to watch it in action.

And of course the demos! One of my favorites was the fairlight 242 demo. Which UAE with a Kickstart 1.3 ROM will run. Even the MS-DOS version!

fairlight 242 UAE for DOS on DOSBOX

fairlight 242 UAE for DOS on DOSBOX

I should add you can find more demos here, and a Win32 version of UAE here.

Qemu 0.12.3 win32 build available

Posted on by
7

Hot off the compiler….

http://vpsland.superglobalmegacorp.com/install/qemu-0.12.3.zip

I even remembered to strip the exe’s so it’s WAY smaller then the other versions….

Also for those *ONLY* interested in x86 emulation (ie regular PC) I’ve created a far smaller archive here, that only contains the pc emulator.

I figure the amount of people that run the non x86 stuff is few & far between.

Qemu 12.3 is out!

Posted on by
Reply

didn’t the time fly by?

Anyways scanning through the list I see that the SDL full screen/windowing has been fixed!

I’ll have to crank out some binaries later, but I had to write something here, otherwise I’d forget it.

Also on the topic of Qemu, I see this site qemu-buch.de has me listed as the latest win32 build site for Qemu on Win32…

Cool!

The oldest CP/M ‘simulator’ out there.

Posted on by
Reply

I was surprised to come across this little simulator simply called ‘com‘ tonight. This program started out as a 8080 instruction simulator for a mc68000 machine running CP/M, back in 1984, and was written by one Jim Cathey.

‘Com’ was then later written up, and published in Dr. Dobb’s Journal.

From there it’s evolved it’s assembly core to some other 68000 cpu families and platforms, then the MIPS and PowerPC. Then in 2006 the CPU core was re-written in C.

For a while it’s primary platform was a 68000 based Unix, and it still has a lot of unix’isims buried in the source. I’m sure it’d build in MinGW though.

But in the meantime I figured it was yet another reason to fire up the old gcc 1.37.1 for Xenix to give this thing a go.

The biggest, and dumbest thing I fought was without realizing there was both a ‘Makefile’, and a ‘makefile’, and gmake kept running the lowercase one, while I was editing the Makefile in vain… But with that out of the way, and a few includes to fix, it was VERY straight forward to build. Not to mention running Xenix on Virtual PC 2007 on my new intel core i7 cpu, it compiles the C version just about as quickly as I can hit the enter key.

Because it’s on Virtual PC the last few lines of the console are garbled.. Oh well, at least the floppy controller works (as long as you hard code /dev/fd0 to 2,60).

So, here is a picture:

Xenix 2.3.4 with ccom zork1

Xenix 2.3.4 with ccom zork1

And a disk image. All I’ve really done is tweaked a few things, and built this with gcc so it includes a binary for Xenix systems. Also the ‘com.tar.gz’ package did include quite a few sample programs… mandog.com is fun, along with zork 1,2 &3!

On a final note, I thought the Xenix thing was a good road to head down because in the 1990’s there was this BIG push for ibcs2 compatibility across all these Unix platforms on the i386 cpu. Well it’s been largely abandoned work, and the best I got was OpenBSD complaining that its always out of memory, and NetBSD kernel panics!.. Open Solaris has *NO* ibcs2 compatibility even left.

I suspect it doesn’t matter, esp now that you can run some real ibcs2 OS’s in a VM, who needs 3rd party emulation?

I guess I’m just too late to the party.

Frotz on Xenix

Posted on by
2

Well after having some fun with gcc, I wanted to try something a little more… “fun”. I’ve had good luck in the past with ‘dumb frotz‘ on the old BSD stuff (4.2/4.3 etc) but surprisingly I had no luck at all with gcc & xenix.

Well that was rather odd.

So in some crazed attempt I tried the regular version of Unix Frotz 2.32. Xenix was lacking the memmove procedure, but thanks to an old post here, I was able to get it running under Xenix.

Ok, fair warning it is SLOW. It’ runs the cpu into 1.0 levels… I don’t know why. My attempts at building gdb and using it from that old Soviet site hasn’t met with much luck.

Oh, and it was easier to massage some make files with gnumake.

But it does run!

If anyone want’s to give it a whirl it’s available here.

gzip for Xenix

Posted on by
2

sorry I didn’t realize that IIS was blocking the gzip download because of it haveing no extension…

I really need to redo that whole install.

Meanwhile you can download it here:

gzip-i386-xenix

Also I found on some old “Soviet Union” website (no really it’s a .su!) a binary version of GCC for Xenix… I’ll post more later as I get a chance to go through the thing….

For the adventurous it’s here:

ftp://ftp.kiae.su/pub/unix/os/xenix/gnu/  (now offline)

It’s kind of interesting to find such a thing, and if you see the dates, it’s from January 28th 1991… In the last days of the Soviet Union… Well lucky for us, someone in Russia is a packrat! I guess they were starting to switch out from homemade PDP-11’s into 386’s and they didn’t bother porting their ‘pirated’ versions of Unix v6…

Sometimes less is more.

Posted on by
6

 

The more they overthink the plumbing, the easier it is to stop up the drain.

-Star Trek III

Well as of late we’ve been fighting this aging SQL server at work. It was originally a NT 4.0 server with SQL 6.5 upgraded to 7.0 then 2000 with Windows 2000. It also had to do some work with Oracle, and the dba’s were using MSDTC to make sure their transactions were getting committed into Oracle. Oh and to keep it ‘fresh’ the Oracle client was version 7 as it originally was talking to an Oracle 7 DB.

Well as the years go by, that Oracle 7 DB became Oracle 9i (already obsolete!), and we suddenly hit a transaction wall.

And along the way we virtualized the server to go into our VMWare ESX 2.x cluster, and it’s been since migrated to VMWare ESX 3.5

The server was dropping tens of thousands of these XA???????????????????.trc files, into the \winnt\system32 directory.

Well naturally you’ll eventually hit this wall of how many 8.3 translations you can do before the system CRAWLS. And boy oh boy did we hit that wall. So at first my idea was to delete all of these trc files, and let it live, but that’s not such a ‘great’ idea… As this reeks of a fundamental problem.

So the ‘first’ step in all of this madness was to up the OS to Windows 2003 enterprise (it was 2000 Advanced server before) And see how things were doing. The OS upgrade went smoothly I had slipstreamed sp2 into the update, so I only had some 90+ updates needing to be done once the OS had been upgraded. And for ‘good’ measure I thought I’d take the server from 768MB of ram up to 2GB, and set VMWare to allow 4 cpu’s for the database server. The node it was running on wasn’t doing terribly much so what the hell right?

Wrong…

The server was now performing markibly SLOWER… And yes, still dropping TRC files like there was no tomorrow.

After a bunch of digging around, I found out that in 2003 you have to click a box in the component manager to allow XA (cross architecture) transactions! Well now it wasn’t dropping as many XA trc files, but after watching it for a while, when two went to run at the same time, the SQL server would crash with a hex code saying it was out of memory.

Out of memory? I’d just given it more!?

So I did the ‘logical’ thing and gave the system 5 GB of ram, and enabled the /3GB flag in boot.ini

Same crashes.

I moved SQL server up to using 2GB of ram (out of 5, sure why not?). Same error.

Well this sucked, so we tried to update the Oracle client from 7 to 9i. In the process I found I couldn’t un-install the 7 client, nor could the 9i thing just ‘upgrade’ it, 9i kind of installed in parallel. Which led us to our next major fault, after swapping out the new client, removing the Oracle product key from the registry, and re-linking the Oracle servers using a new registration string, now ALL of our transactions against the oracle servers were failing.

Thank goodness for google, as we were able to deduce that the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsfot\MSDTC\MTxOCI was populated with all the old Oracle 7 values….

OracleOciLib -> oci.dll
OracleSqlLib -> orasql9.dll
OracleTraceFilePath -> c:\oratrace
OracleXaLib -> oraclient9.dll

So changing it to reflect Oracle 9i and suddenly our transactions were running! Even two at a time!!

But there was no doubt about it the transactions were slower then hell. We had gone from 1 minute to 11 minutes on one, and 5 minutes to just under an HOUR.

I added MORE memory to only find the SQL server couldn’t see the network card. So I added another one, and it got even SLOWER.

So in a minute of panic, I reduced the ram back to 768MB, took the VM from 4 cpu’s to 2 cpu’s and forced SQL server to use a single processor.

And our timings are now fantastic! That 1 minute process can complete now in 12 seconds!!! The other process finishes in about a minute give or take, but it’s tremendously faster.

From what I can gather, since SQL is so IO bound the more ‘top’ hardware you give it, the harder it pushes the IO stalling itself… Naturally it’s different on a physical machine, but sometimes it’s interesting to see what happens.

And may this be a lesson, just because it can emulate multiple CPU’s doesn’t mean it’ll run parallel things ‘better’…

Xenix, K&R and f2c…

Posted on by
4

Well a friend of mine let me have access to a Xenix 386 machine with a C compiler! Which was great, The first thing I built was gzip, as I couldn’t imagine a machine without it…

then I spent the better part of 3 hours ‘fixing’ f2c/libf2c for some Zork fun. Well let me say that while it was fun and all, the C environment from Xenix is…. old. No stdlib.h.. Among other things. Also gzip and f2c had issues where some programs would use ‘local’ copies of procedures… Naturally whatever compiler (MS?) my friend had wouldn’t have any of that!

Not to mention the other slight stumbling block, was that this was a K&R Compiler… Ouch.

However I was able to bash together a version of f2c that ran!

However it left me fixing the prototypes for the output… Because by default f2c outputs in ANSI.

It’s no biggie for ‘hello’ or even the textcnv program for Dungeon, but there was no way I was going to do this for the 100’s of procedures in Dungeon…

But the upshot is that the simple answer was a man page away…

Use the -K flag, instead of the -C flag, and all will be well.

I didn’t bother trying to clean up the gettim.C thing, maybe some other day, but I can’t promise much.

But in the meantime, here it is, for the 2 or 3 people with some kind of legacy Xenix thing out there..

 

Dungeon-2.5.6 for Xenix.

This is an 80386 exe, so you 80286 users would be out of luck… I don’t know if I even can make 80286 stuff.. I think the next thing I’ll have to see how hard it is to build is that ACK as it says it supports Xenix… And free compilers are always ‘good’ things.

A quick follow up to building DLL’s

Posted on by
1

Another slight issue I’ve found with the SLiRP code, is that it expects to be able to call two functions (slirp_can_output and slirp_output). The snag here is that DLL’s expect to be SELF CONTAINED… So how can you have a DLL that needs to call functions from your program?

Void pointers!

So let’s make this more… involved.

dll.c

void (*bob)(int xy);

__declspec(dllexport) int hi(void)
{
(*bob)(12);
return 3;
}

__declspec(dllexport) void Register(void *p)
{
bob=p;
}

test.c

extern void Register(void *p);

void XX(int xy)
{
printf(“XX %d\n”,xy);
}

void main(void)
{
int j;
Register(XX);
j=hi();

printf(“%d\n”,j);
}

And let’s build it…

c:\temp\dll>cl /c /LD dll.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80×86
Copyright (C) Microsoft Corporation. All rights reserved.

dll.c

c:\temp\dll>link /DLL dll.obj
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.

Creating library dll.lib and object dll.exp

c:\temp\dll>cl test.c dll.lib
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80×86
Copyright (C) Microsoft Corporation. All rights reserved.

test.c
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test.exe
test.obj
dll.lib

c:\temp\dll>test
XX 12
3

So as we can see, the main procedure runs the ‘register’ procedure to tell the dll that the ‘bob’ procedure will infact be XX. Now when the dll invokes it’s ‘hi’ function it can call the XX function from the exe. Now if I were a better programer, I’d use the DLLMain code to make sure that all my virtual void functions cause some kind of ‘readable’ panic message when called so you don’t get the default reaper… Because naturally if you run the dll code without the register function it’ll crash in a not so great manner.

But I’ll leave that as an exercise to the reader.

I’ve made some good progress on the SIMH thing, Ive got the non networked versions & the libpcap stuff building with Visual C++ 2008… I was thinking about using that 2010 RC but that just seems wrong…. But for now all I’ll have to do is apply this logic to the slirp dll, and get building the VC version for linking, and the Mingw version for actual operation….

Build a DLL

Posted on by
Reply

Well this is leading up to a new release of my SIMH projects. The issue that I’ve had with the SLiRP code (usermode NAT) is that it only works when built with GCC, and ONLY when you have no optimizations. Naturally you will loose all optimizations with SIMH if you build the entire project like that. And of course you cannot use Visual C++ to build SIMH, because while it’s faster they use different object files.

So while thinking about what a bummer it is, and how to try to debug SLiRP with Visual Studio, today I had a ‘better’ idea. Well ‘better’ in that I can do this way quicker.

Instead I’ll build SLiRP as a DLL, and have Visual C++ call that!

Ok, now that sounds crazy, but the first thing I’d need is a simple ‘test’ case. First let’s build a dll in MinGW. It took a bit of googling but then I found this super simple example.

dll.c

__declspec(dllexport) int hi(void)
{
return 3;
}

Ok, it doesn’t do that much, but you get the idea. Now we have to compile this with MinGW.

gcc -c dll.c
gcc -shared -o test.dll dll.o

Ok, now this will first compile the C file into an object file, then the linker will set it up as a DLL. Notice that I’m not building the ‘.a’ export file for this DLL. Visual C++ wouldn’t like it anyways, so I don’t need it.

Next, using Visual C++ (I would *assume* just about every version can do this..) I re-build the DLL to create the export library. Yes I know this is weird, but it is the quickest way I know to do this.

cl /c /LD dll.c
link /DLL dll.obj

Cool, now we’ve built dll.c as a DLL under both MinGW & Visual C++. Now for a ‘test’ program to drive our ‘staticly linked’ dynamic link library.

test.c

void main(void)
{
int j=hi();
printf(“%d\n”,j);
}

Ok, now with that out of the way, let’s compile & link!

cl test.c dll.lib

Cool, now we’ll have a test.exe!

Let’s run it!

c:\msys\1.0\src\dlltest>cl test.c dll.lib
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80×86
Copyright (C) Microsoft Corporation. All rights reserved.

test.c
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test.exe
test.obj
dll.lib

c:\msys\1.0\src\dlltest>test
3

Wow that was exciting! Now for the people paying attention, you’ll remember that the test.exe was linked against dll.lib which was built with the Microsoft compiler, and is calling the Microsoft generated dll.dll. Yes you are correct. But always test with a known positive, before you throw in the negative I say…

c:\msys\1.0\src\dlltest>move test.dll dll.dll
Overwrite c:\msys\1.0\src\dlltest\dll.dll? (Yes/No/All): y
1 file(s) moved.

c:\msys\1.0\src\dlltest>test
3

Holy crap! It worked!!!!

That’s right, now I have built a very simple test program that’ll call a DLL function built with MinGW!

And that, is how you can get around a kooky problem where some programs build with one version of a compiler tweaked one way, and you want to use those bits in another program built another way.

Just ask any language refugee from the 1980’s how hard this was to do on the PC platform.. While VMS had a common library spec for all languages, not every platform (MS-DOS,UNIX) was as lucky. But with the rise of things like Windows with DLL’s, and of course NT thanks to the VMS crew it’s in modern systems today.

Let me tell you, linking Quick Basic to C was… not all that much fun. And Turbo C++ was right out!

Anyways I’ll leave you with this much, and at the worst case, much like making bootable CD’s, it’s a good note for me to find this stuff later when I need it.