Motherboard: Asus A7PRO

I’ve got a smallish collection of motherboards, so I thought I would start a series of short posts with photos and a short commentary on each board. So without any further ado, here is the first board.

This one was made by ASUS roughly around 2000. It is a earlier socket A with a VIA Apollo chipset. This came with the hardware donation I received a while ago and was fitted in the large chassis. There is a Duron 800Mhz processor installed, along with some SDRAM. This board could take a fast for the time Athlon processor.

I found the manual for this board here on the ASUS website, in it I found everything needed to set up the board. It supports the technologies you’d expect for the time, but also one I hadn’t heard of. VCM or Virtual Channel Memory was an open standard developed by NEC. It was supposed to increase the memory bandwidth. It’s quite complicated from what I read on Wikipedia, so I won’t go into details, but it clearly wasn’t popular.

This board has a few other unusual features such as an AGP Pro 4x slot and a VRM that usually only made it to more expensive boards. Yet it also has some features that cheaper boards had such as the utterly silly AMR slot and lack of ISA slots.

I’d say this board was probably a middle-of-the-range board, clearly it is better than the cheapest, but not as flash as the most expensive. Usually this is the sensible option, and that seems to be the case here. The choice of processor installed is a little bit of a mystery, as I expected to see something faster here.

From the perspective of a technician, this is a really nice board. It’s easy to set up because all the switches, headers and jumpers have a reference silk-screened on the board. You don’t really need the manual. It has plenty of features and supports faster hardware from the time period. The VRM module may have been a good feature, it could be replaced if it failed. Of course that is assuming you could easily get a replacement. The only downside is lack of legacy ISA support, so it wouldn’t suite upgrading when ISA slots were required.

Thus concludes the first of the Motherboard series, please let me know what you think.


Shaw’s Nightmare for DOS

Shaw's NightmareToday’s game is some-what unusual, it is a DOS game that was released relatively recently, at the end of 2013. It was mostly developed by one guy, Michael Muniko, which is quite impressive really given the scale of the game. It is an obviously Doom inspired FPS built using the Build engine. Unlike many others, who would produce a total conversion mod for something like Duke Nukem 3d, the developer has instead built their own DOS executable from source. This was certainly an ambitious project right from the get go.

I played today using Dosbox, and there are a few things you’ll need if you want to play. Firstly, whilst the game only requires 8Mb of RAM, it doesn’t recognise it correctly under Dosbox. To get around this you need to set the amount of memory to 24Mb or higher, I have mine set to 32Mb. I have no idea if this is true of an actual machine as I haven’t tried it on one yet. You also need to set a reasonably high cycle count, I tested the game at 60,000 cycles.

Lets start with the graphics. The game uses VGA graphics, which is no surprise as that is what most build engine games support. The art style of this game is what confuses me the most. It looks like it was drawn in 5 minutes per sprite with MS Paint to put it bluntly, but it kinda has a weird childish charm as well. I could imagine having drawn something like it when playing with paint as a kid. I’m not really sure what to make of it, either he was a bit lazy, or deliberately chose this style for artistic reasons which would be clever. After all the game is set with-in Shaw’s dream world.

Unfortunately some of the sprites will cause problems. Their size will sometimes cause them to clip into walls, which fortunately doesn’t happen often. The biggest problem is with the corpses being just as large, blocking your view, and looking not much different to the live creatures. Doom sometimes suffered a little from this when you encountered any number of certain enemies, but you could usually see over them to some degree, and they were obviously dead.

The sound design, like the graphics, is either lazy or very clever. The music sounds like random mashings on a keyboard, as if he threw a random number generator at the music. I can’t say it’s bad, it doesn’t hurt your ears, it’s just somewhat surreal. Sound effects for Shaw himself are much better, albeit a bit quiet, they sound like they are the straight recorded voice of an actor/friend. The creatures however sound somewhat deranged, for some reason he used cats yowling for many of the effects and other strange noises. Weapon noises are fairly run of the mill, but are too quiet to make much impact.

Game play wise, Shaw’s Nightmare is very much like Doom. The weapons, whilst sounding and looking a bit different are largely the same as the weapons in Doom. The creatures encountered in the first episode are much like the basic enemies found in shareware Doom. Although they are much more brain dead than even the zombies.

The level design is different, however I’m not sure how to describe it. They are elaborate in a way, but also simple in their design, not a bad thing by any stretch. There is some variety, some levels are more open and set outside, whilst others are closed and set in corridors and maze-like structures. Because the same simple textures are used repeatedly you may get lost, but I didn’t experience as much of this as I thought I would.

The controls are probably the part of the game which annoyed me the most. I used the keyboard as that’s what I would normally use for a vintage FPS such as Doom or Duke Nukem 3d.  I found it to be kind of like walking in treacle in the sense that it takes a while before you accelerate to normal speed, in turning as well as walking. Then when you release the key it takes much longer than you’d expect stop. This makes it really hard to aim and move with much precision. I would have had much more fun if this was set up more like Doom or other FPS games.

sn_028I don’t really know how to summarise Shaw’s Nightmare. It’s certainly feels surreal and strange, much like the dream world it is set in. But on the other hand the graphics and sound clearly could be much better. Neither are obstacles to it being fun, the controls are pretty much the main reason I found it frustrating sometimes. Should you play this? If you’re curious about an obscure FPS made by an individual, then yes. If you want to play something polished like Doom, then you should probably play that instead.

Update: The author has provided a link in the comments to a new version that controls better. It’s still not perfect but makes the game much more fun and easier to control.

This slideshow requires JavaScript.


Under-volting my CPU

It’s not often I tinker with modern hardware, but I decided recently to try and reduce the temperature and power consumption of my main PC. It is the most modern PC I own, yet is still probably about 7 years old. I have a AMD Phenom II 955 x4 @ ~3.2 Ghz which normally will reach over 50 degrees C when running a single thread at full load in warmish weather. Not really great sounding, but it usually idles around 44 degrees C.

People who are familiar with overclocking will know that as you increase the clock rate of a chip you frequently need to increase the voltage as well to maintain stability. This can also work in the reverse, a lower speed can utilise a lower voltage and be stable. I didn’t particularly want to make my machine slower, but I did want it to run cooler, so I went about lowering the voltage.

It’s a fairly simple process, lower the voltage by one setting in the BIOS, test with Prime95 using the maximum heat FFT, see if it fails after a while (best to test overnight) and repeat if the machine is still stable. The goal is to find the minimum voltage that the machine will be stable at.

My processor is so far stable at ~1.18v which is about 0.15 under voltage. Doesn’t sound like much, but it has had a profound effect on the temperature the machine runs at under load. Under the same conditions (one core fully loaded) the temperature dropped by 4-5 degrees, and had a larger decrease for full load. Idle temperatures remained about the same.

I’m still running Windows XP on the machine, which whilst old still suites me. I’m thinking about what to upgrade to, favouring Debian linux or FreeBSD. I’ll have to find out whether these support Cool-n-quiet for my processor, and how well that works. By default Windows XP doesn’t use it, so this is something I decided to rectify.

Enabling Cool-n-quiet wasn’t particularly hard fortunately as long as you’ve installed the processor driver from AMD. Turn it on in the BIOS and then set the power management plan to portable/laptop or minimal, the default desktop setting disables it again. Using a program like CPU-Z you can see the clock speed and voltage going up and down. Interestingly Cool-n-quiet maintains the under-volting I configured as the maximum voltage.

My only real issue with Cool-n-quiet is an interesting one. I play older games and use software that is sometimes single threaded, the windows XP scheduler will move the single process from one CPU to another to balance the load. This has an interesting effect with Cool-n-quiet. Basically it reduces the clock rate of each core (independently it seems) based on how much usage each core has. Because the scheduler is moving the single thread around, each individual core is not as busy and is then under-clocked by the Cool-n-quiet system. I haven’t yet measured the impact this has on a single thread, but from what I’ve observed it does appear to lose performance.

Ultimately this leads to the single thread not getting the maximum performance even if it uses an entire core worth of processor. Fortunately you can set the affinity in the task scheduler which stops the thread being migrated around, this means cool-n-quiet does it’s job better by being able to slow down the other cores until they are needed and the single thread gets the maximum performance from the single core.

Unfortunately this is a bit of a pain in the butt to do each time. So I’m not sure if I’ll continue to use the Cool-n-quiet technology. It does work exceptionally well in the sense that my processor is another 4 degrees cooler with a single core fully loaded. I will have to make some performance measurements and decide if it’s worth it.


Jazz Jackrabbit for DOS

Todays game, Jazz Jackrabbit was made by Epic Megagames back in 1994. It is an action platformer with a quirky story based on the old fable of the Tortoise and the Hare. Your character, Jazz Jackrabbit, has to save the princess Eva Earlong from the bad guy, Devan Shell. Today is my first time playing Jazz, as my DOS machine back in the day was simply not powerful enough, that and I was never exposed to it. It can be exceptionally hard finding a registered copy of this game, so today I’m playing the shareware version.

The first thing I noticed was how amazingly good the artwork for this game is. The graphics are like they came straight out of a comic book. Animations are similarily also very good. In-game sprites are large and detailed with plenty of frames of animation to go wih them.

The game supports exclusively VGA graphics, which by 1994 was the norm. However I played under Dosbox and found that it would have required quite a beefy machine for the time in order to play. The minimum specifications in the documentation say about a 386@ 33Mhz, but when I set up the equivalent in Dosbox I found frequent slowdowns. You probably really need a 486 @ 33Mhz but ideally 50Mhz. In 1994 machines like this were around, but still expensive, and many wouldn’t upgrade for a while.

Jazz also suffers from an unfortunate bug if you run it on a machine that is too fast. Basically upon starting the game you will get a Runtime Error 200 when using a fast CPU (>~200Mhz). This comes from a bug in the CRT unit found in Borland Pascal. Basically when calibrating a timing loop a counter overflows and causes problems. Fortunately Dosbox makes it easy to avoid, and there is a patch online, search for borland CRT patch.

Jazz supports Sound Blaster cards mostly for sound, but there is also support for the GUS, Pro Audio Spectrum and Sound Blaster clone boards. The music sounds like MOD music and is exceptionally good. Digitised sound effects are used and are also quite effective. Jazz has a distinctive voice and will even ask the player what they are doing if he is idle for a short while. I think the sound design works quite well, the music and sound effects fit the art style well, they’d work well in a saturday morning cartoon.

Gamplay wise Jazz borrows elements from many platformers, but the most obvious is that he is fast like Sonic. However Jazz defends himself mostly with his big gun, the LFG-9000. His speed can be problematic, as I found I kept running into enemies before I had time to react. This is partly because the sprites are large you can’t see all that far ahead. I found this less of a problem once I started to learn the levels a bit and had some more practise with the controls.

The levels are split into pairs for each planet that you visit. The planets each have a different theme, the first level seems to be simpler, and the second is the more complicated and difficult of each pair. The themes for the planets are quite different from each other, each with their own enemies and artwork. Although I did think the first two planets reminded me of the early levels of Sonic the Hedgehog, this is mostly in appearance and some features like the tubes in level 3 and 4.

Of course since I only played the shareware episode I can’t comment on the other episodes, so they may be different as far as level design goes.

Interestingly my 4 year old daughter also had a go at playing, she seemed to like the colourful graphics and the cute little “bunny”. Unfortunately the game was a little bit too hard for her, mostly as she hasn’t learned how to use more than one control at a time.

I tried a few different difficulty levels and didn’t notice much change. It seems the lower difficulty levels just give you more hit points, which did mean I lasted longer before dying, but some difficult parts still killed me.

I have mixed impressions of Jazz Jackrabbit, at first I found some elements of the game difficult to deal with, such as Jazz’s imense speed and jumping controls. However as I played the game more it grew on me, I was usually able to avoid running into enemies mainly because I knew where they were. I still find some aspects of jumping a bit annoying, but it’s certainly quite fun anyway. The Guardian at the end of the first episode was a little bit of a let-down, it was too easy to beat, otherwise there is plenty of challenge.

This slideshow requires JavaScript.


Creating a Benchmark: part 3

Last time I started the process of comparing the BGI to a hand coded VGA library. I coded up a fairly lazy completely Pascal library. Today I’ve re-coded some parts of that code using x86 assembly with Pascals in-line assembler.

At work in the IDE

At work in the IDE

The first thing I wanted to tackle was the speed of the sprite blitting and filled boxes as they didn’t seem to live up to their potential. I decided to replace the Pascal move (copy memory) and fillchar (fill memory) functions as they are heavily used in the Pascal only version.

Luckily there are some neat instructions which make copying and filling memory faster even on old processors like the 8086 and 80286. These are MOVS and STOS, both string instructions which actually owe their existence to the Z80 and i8080 where they first appeared. Using them with the REP prefix makes them even better as it helps eliminate some looping code.

MOVS is for copying a block of memory, you load the ES:DI registers with the destination pointer and DS:SI with the source pointer and CX with the loop count. Then execute…

shr cx,1
rep movsw
jcxz @next
loop @again
jnc @done

This code will copy any count of bytes one word (16 bits) at a time, copying a single byte at the end if you specified an odd count. I’ve used JCXZ and LOOP to continue the data copying as some older processors have a bug where the REP MOVSW can end early if an interrupt occurs at the wrong time. I know this isn’t strictly necessary, but it’s a safety measure.

STOS works in much the same way, just it doesn’t source the data from a memory pointer, it uses the accumulator register instead.

With these new memory copy and fill routines done I tested the program to see if I had any improvement in performance. To my surprise there was none, the built-in functions for copying and filling memory must be about as good as what I wrote, but why is the blitting and box filling still slower than they should be?

It turned out that the loops in the filledBox and putImage functions were the culprit. The pascal code looked like this for putImages main loop…

for i:= 0 to sizey do
         copymem(bseg,4+(i*sizex),cardseg,((y+i)*320)+x, sizex);

It didn’t look problematic until I considered the instructions required for calculating the offset into the image data and screen buffer. Multiplication is an unfortunately slow operation, and with some nifty assembly code I rewrote both the putImage and filledBox procedures mostly in assembly, avoiding multiplications in the main part of the loop altogether.

It took me about 2-3 days to get through all the work re-writing two of the drawing functions in assembly, when it took about 1 to write the basic VGA graphics to begin with, but boy did it pay off. After re-writing most of putImage and filledBox in assembly I increased their performance by over 3 times for putImage and almost 2 times for filledBox. Both are also now significantly faster than the BGI implementation, being about twice as fast.

So the BGI is slow compared to raw x86 assembly after all, but it took significant effort to get that performance gain. For the myriad of one-man shareware programmers I still understand why they just went with the BGI, it was easy to use and good enough for what they were doing.

Making a VGA library with straight pascal was fairly easy to do, but had some disadvantages over BGI and wasn’t really quicker. I had to go to assembly before there was any significant performance gain. Coding assembly is daunting to many programmers, and for me is much more time consuming than writing in a higher level language. It will be quite some time before I really finish re-coding the library in assembly.

Next time I’ll have to tackle the line drawing functions, which are using some floating point numbers to accurately draw the lines. I’m planning on converting them to using fixed point numbers to improve speed on machines without an FPU, like my old 386sx. I’m also hoping assembly will help speed things up there to.


Hardware pickups

Recently I’ve been able to pick up some interesting hardware and I thought I’d share some photos of it with you. It was also an opportunity to try out some better lighting in the hope of getting better pictures.

387sx 33MhzThis unfortunately wasn’t the greatest photo due to the reflectivity of the packaging.

First up is a pair of 80387sx co-processors from the mid 80’s. Very few people actually bought and installed these chips as floating point arithmetic was mostly only used in scientific applications or Computer Aided Design. Consequently chips like these can be quite rare, and this pair clock in a 33Mhz making them some of the faster 387’s.

Intel weren’t the only company making co-processors for the 386, these included Cyrix, Chips and Technologies,  IIT, ULSI and Weitek. Most of these were faster than the Intel part, but had some compatibility issues, and some were of completely different designs.

Interestingly the NPU’s as they were known could be clocked asynchronously from the CPU. They also could operate whilst the CPU was busy doing something else, which gave machines with these some very crude parallel capabilities.

Here we have a Sun Microsystems mainboard from a Sparcstation IPX. The machine came in a neat lunchbox form-factor that was actually impressively small. This particular board has a Weitek Sparc processor that ran about 40Mhz. These chips had an FPU on-die, so they would have been similar to the 486 in performance. The LSI chip and some of it’s supporting chips are likely the 1Mb of system cache which was quite large for the time. The Sun GX chip is a graphics controller which contained some basic drawing acceleration. These features made the IPX quite an impressive little workstation. Most of the chips and the board itself appear to be manufactured in 1993.

It’s a shame I don’t have the rest of the machine, I’d like to be able to run this little beast. I’m not even sure I can get RAM for it, or if what I have is compatible. I’ll have to keep an eye out for the chassis and other parts.

Mechanical Keyboard

Mechanical Keyboard

This might look like an ordinary keyboard, but it is a proper mechanical switch keyboard that came with the next piece of hardware (a PC clone). Despite its very plain looks it feels fantastic to type on and has that distinctive mechanical sound. It has a larger DIN plug which actually suites many machines up to and included many Pentium based machines. It is a bit grubby but in otherwise good condition.


Lastly we have an interesting PC clone. This one was made by a company called Microbyte, which turns out that they were an Australian company based in Adelaide who made PC clones such as this one. It is clear that they designed and built their own boards and wrote their own PC compatible BIOS. Quite an achievement for what must have been a small engineering company. I found very little information about them online unfortunately.

My machine is a PC230sx, which has a 386sx@20Mhz with a Trident VGA card. It has SIPP memory fitted for both the main memory and video memory. They installed an unusually large amount for the VGA, having a full 1Mb of video memory. The system RAM is 2Mb in total.

When I bought this machine I didn’t think it had a hard disk, but it turns out that it has a Seagate ST3144A which is 130Mb. Probably an impressive and expensive drive in it’s day. This drive still works, I just had to configure the CMOS with the drives details which are handily written all over the machine.

You may notice the socket for a WD33c93 chip, this was a SCSI controller chip. This would have to be one of the few older machines that have the capability of on-board SCSI. I’m not sure why the chip is missing here, but these machines were apparently commonly fitted with SCSI drives instead. Looking in the BIOS seems to indicate that they were supported for booting. I may have to find one of these chips and see if I can get SCSI to work.

Between the VGA chip and VLSI chips lays an extremely long header where the expansion riser card would normally be inserted. This machine doesn’t have the riser card, so I can’t plug in a sound card or anything else which is a bit of a shame. I’m surprised the machine works without it as I’ve seen many other machines which don’t work correctly or at all when it is missing.

This board has some stickers that look like they were written by a service technician, they are attached to a part of the board under the floppy drive where there is a blank area containing no visible traces or chips. The first sticker reports an invalid opcode at a particular memory address which could indicate a problem with RAM or software.

Fortunately after testing the machine I’ve found the only problem so far is the malfunctioning COM1, the rest of the machine appears to be functional, and the IDE hard drive boots DOS ok. I have noticed that the Floppy drive light stays on, something which sometimes indicated incorrect installation of the cable. In this case the cable is correct, and the drive even reads disks, so there is likely a jumper setting on the drive that needs correcting.

I benchmarked this machine with Topbench to see how it compares to others. It was marginally faster than a 286@16Mhz with a 287 co-processor. I think there may be a few factors that contribute to this. Firstly I think the RAM must be a similar speed to that in the 286, thus slowing down the memory and opcode tests. It does perform better in the 3d games test which I found interesting as that has some floating point arithmetic. Luckily this is perfect for testing my homebrew platform game.

Finally I’m pleased with how the extra lighting has improved the pictures, but my technique still needs work. Perhaps another source of lighting is called for, or perhaps finally a step up to a better camera.


Creating a Benchmark: part2

A couple of weeks ago I created a basic benchmarking program for measuring the speed of the Borland Graphics Interface and its drivers. I’m primarily interested in how they compare not only to each other, but also to a hand-coded implementation. So this week I created a VGA graphics unit by hand and made a benchmark program around it.

I chose coding for VGA 320x200x256 as it is the easiest mode to code for and matches more of the BGI drivers. You simply initiate the graphics mode 13h (h for hex) with the video BIOS, this sets up a linear buffer for drawing at the memory location A000h:0000h. Each pixel is a single byte, so drawing a pixel doesn’t require bit masking unless you want it to. Drawing a pixel simply involves changing the byte at the offset following this simple formula. (y*320) + x.

Given this information it was no problem at all to code up a basic graphics unit. I didn’t use much in the way of assembly code to implement the unit, partly out of laziness, instead opting to implement it using Pascal code mostly. I haven’t implemented all the graphical functions in the BGI, simply because there are way too many.

Here are the results when tested under Dosbox with 3000 cycles. I used pretty much the same code to perform the measurement to ensure as much consistency as possible. It’s quite interesting to see that implementing your own graphics unit doesn’t really provide that much extra performance for most functions, and in this case blitting sprites is actually slower using my code! I suspect this is because I used a built-in Pascal function for copying memory that may not be super fast. I did note it is still faster than both the VESA and SVGA256M driver in the same mode.

So is it worth implementing your own graphics driver instead of using the BGI. The answer is a sorta, maybe. I haven’t optimised my graphics code in this case, so it surely could be a bit faster, but I did manage to use less memory for storing the sprites, and my code was much smaller in terms of size. However the Graph unit and VGA256 actually seem to have some decent performance comparatively, so if you need compatibility with other cards that are more difficult to code for, or simply don’t have time to code a graphics unit of your own, then the graph/BGI implementation isn’t too bad.

Code and DOS binary are available here.

Blogs I Follow

Enter your email address to follow this blog and receive notifications of new posts by email.

Mister G Kids

A daily comic about real stuff little kids say in school. By Matt Gajdoš

Random Battles: my life long level grind

completing every RPG, ever.

Gough's Tech Zone

Reversing the mindless enslavement of humans by technology.

Retrocosm - Vintage & Retro Computing Blog

Random mutterings on retro computing, old technology, some new, plus any other stuff that interests me


retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way


MS-DOS game reviews, retro ramblings and more...


Get every new post delivered to your Inbox.