Archive for January, 2015

29
Jan
15

Creating my own Benchmark program

Looking at benchmarking programs last week got me thinking about creating my own testing software. I’m a Pascal programmer as far as DOS goes and I have read in many programming forums about how slow the Borland graphics interface is. I decided to test this theory out and find out just how slow or fast they are, and what effect the BGI driver and graphics mode has on the performance.

The Borland Graphics Interface is a library that Borland supplied with the Turbo C and Turbo Pascal products. It was used by many because it simplified drawing graphics and meant you didn’t need to write the code for drawing to the screen. This could save a lot of time for the individual programmer, and many shareware programmers used it in their simple games.

As I’ve said before, many have claimed that it is quite slow. So I have written a simple program called BGIbench to test the speed of any BGI driver. I test some of the more important graphics functions that will work on all the drivers, some like page flipping only work with specific drivers.

The drivers I’ve tested here are the standard Borland CGA and EGAVGA ones that came with Turbo Pascal 6 as well as VGA256 (a mode 13h driver), VESA (uses VESA compatible modes) and SVGA256M (another VESA driver) that I found when I started writing my platform game all that time ago.

BGIbench results for Dosbox @3000 cycles

BGIbench results for Dosbox @3000 cycles

Here are the results for testing performed under Dosbox. The result that matter the most for games is the sprites, notably the vga256 driver is the best in this category. All types of lines and circles are about the same between the drivers, although I have noted that drawing circles is pretty slow, slower than even Qbasic if I remember correctly.

Of interest is the filled boxes, which in theory should be about as fast as the sprites, but the EGA,VESA and SVGA256M drivers seem more capable at drawing filled boxes than blitting bitmaps. This doesn’t make sense, there must be something contributing to slow-down with bitmaps and these drivers. They are even slower than the pattern filled boxes!

BGIbench on a real machine pentium MMX 200Mhz

BGIbench on a real machine pentium MMX 200Mhz

On actual hardware things are much different. Notably the VESA driver is nearly as good as the VGA256 one at drawing sprites in the same resolution, and is in fact significantly faster at drawing filled boxes, which makes me think there is still some lost potential in that driver.

The SVGA256M driver has poor performance unfortunately where it counts, blitting sprites. In fact it’s almost as slow as the EGA driver, which is the worst performer. Again there must be significant lost potential as drawing filled boxes is significantly faster, but it suffers worse performance in most line drawing.

Circles and rendering text is again something that performs poorly across the board, so these types of primitives should be avoided if possible when writing BGI based software.

In summary the CGA and EGA drivers offer modes on older hardware that isn’t offered by the others, so they remain useful even though there are faster drivers. The VGA256 driver is the best for 320x200x256 sprite based graphics, but if you wanted to do vector/line drawing the VESA driver performs better in those areas. The VESA driver also offers higher resolution modes, although at a performance hit as it needs to switch memory banks for drawing. The SVGA256M driver is probably the least useful as others out-perform it in all areas and resolutions.

The question remains how fast is the BGI compared to writing a graphics driver yourself? This will be answered another day.

UPDATE: A Download of the results and the program can be found here.

19
Jan
15

Benchmark Software for DOS

Comparing the speed of computers is not a new thing, it has been done as long as there have been computers. It can be problematic picking a good benchmark, many output meaningless metrics, do not give consistent results, or simply fail by measuring the wrong things. Today I’m looking at a small collection of benchmarking utilities.

I am not equipped to capture from my DOS machine, so as a standard machine I used Dosbox with a setting of 3000 cycles. This isn’t ideal as it doesn’t mimic hardware exactly so it may cause some funny results. I’ve noted in particular that Dosbox’s video memory is faster than in real machines.

Topbench screen

Topbench screen

First up is a relatively new utility called TopBench. I’ve found this one handy for adjusting the emulation speed of Dosbox to approximate an actual machine. It benchmarks the system in real-time so any adjustments you make will be reflected on the screen straight away. The built-in database of machines gives you a good idea of roughly where you machine fits.

However the metrics provided aren’t really clear about what they are measuring. We get a measure of how long each type of test takes, but don’t get any indication of what each test does. So this is good for comparison, but isn’t going to tell you much about the various parts. Still I like this one a lot for tuning performance in Dosbox.

C&T MIPS

C&T MIPS

Chips and Technologies made a simple one that is supposed to measure the MIPS a system is capable of.  It would be good for comparing CPU speed and not much else, except that the MIPS rating doesn’t seem accurate for the speed. I thought Dosbox may have been the cause, but others have noted this as well on actual hardware.

Landmark Speed Test

Landmark Speed Test

Back in the day the Landmark Speed Test was frequently used to compare performance. It compares your system with an IBM AT and is measured in Mhz for that machine to achieve the same performance. It doesn’t tell you how fast the AT machine was, or what processor it was running. I guess you can still use this to compare between systems, but the metric is less useful.

It measures the speed of your graphic card in Characters per second which I thought was a bit odd. Mainly as very little performance limited software used text mode all that much, so I think the metric isn’t very useful. Also we don’t know if their test uses the BIOS routines or draws to the hardware directly, so this may not indicate anything about the hardware. Additionally this metric appears to be inaccurate.

Checkit CPU and FPU performance

Checkit CPU and FPU performance

Checkit isn’t just a benchmarking utility, it also provided technical information about the machine and offered some basic hard disk and floppy disk utilities. The benchmarks are better than some in that they provide the raw data in the form of Dhrystone and Whetstone loop counts.

Dhrystone and Whetstone were some basic benchmarking algorithms developed specifically for testing integer and floating-point instructions respectively. Both were synthetically designed for benchmarking machines, but will suffer inaccuracy due to compiler optimisations, and differences in the languages used to implement the benchmark. Despite the short commings these are still widely used benchmarks.

Checkit Character Through-put

Checkit Character Through-put

Notably Checkit also measures the graphics memory through-put using characters per second. Except they have separate measurements for rendering using the BIOS and directly handling the video buffer. You can see just how different the results are here. Whilst the results are a little more meaningful, it’s still measuring the text mode performance.

SpeedSys Results

SpeedSys Results

Lastly a commonly used tool amongst retro PC enthusiasts is SpeedSys. It is good for benchmarking faster DOS machines. I ran it on my Pentium MMX based MS-DOS 6.22 machine here, and you can see that it provides a lot of information about your hardware. The memory and hard disk graphs are perhaps the most interesting.

The memory speed graph shows the speed versus the data size (in KB). You can see on the graph several drops in speed, these roughly correspond to the L1 and L2 cache sizes. You’ll also notice how the both write graphs don’t seem to enjoy any speed boost from the cache. I can only assume this is because of the cache policy being write-through, but I can’t be certain.

The Speedsys test is probably the best one as it provides the most detail. The memory and hard disk tests are quite good as they give measurements that mean something outside of the benchmark. The only thing I would have liked is more detail about the graphics card, but there isn’t really any more room on screen.

Whichever benchmarking utility you use, remember to always only compare your results to those produced by the same program. Even where the same metric is used as in the case of Drhystone and Whetstone tests. Otherwise you’re really comparing apples and oranges.

11
Jan
15

Some Maintenance on a Canon A-200 20HD

Quite some time ago when I was back at my parents place I had a look at a Canon XT clone, the A-200 20HD. There were a few basic repairs needed, so when I recently saw my parents I spent some time on it.

Yuasa Battery

First thing I did was remove the Ni-Cad battery from the memory expansion board, to prevent any future problems with leaks. Leaky batteries are very hazardous, and can destroy whatever board they happen to leak upon. This often can damage a machine beyond repair. This battery had not leaked yet, but was not really holding a charge. It is a 3.6V  50mAh battery made by Yuasa from Japan, so it’s likely a quality cell, but still best to remove it. I wonder if given its small capacity I could use a super capacitor in its place.

The battery was the main reason I looked at the machine, but I remembered the MFM hard disk wasn’t spinning up. I had to test the machine anyway, to ensure it was working correctly after removing the battery. So I thought I’d try to get the drive spinning again. I tapped and banged it strategically a few times and that didn’t really help. So I rotated the stepper motor that drives the heads one step and it worked pretty much immediately. I wouldn’t normally do that given the risks, but I would have had to open the drive otherwise.

ADMAST Menu software

I rebooted the machine and MS-DOS 3.3 booted up of the hard disk without issue. Strangely it seemed to be only formatted as a 10MB disk, I had a look around the machine and found we had put a few games on it for testing. Here we see the menu screen installed on this machine called admast. Before MS-DOS 4.01 there was no shell or menu system included, so simple menu systems like this one filled the role.

This slideshow requires JavaScript.

The three games I had installed were Megapede, Nyet, and Cyrus Chess. All these games support using the MDA cards text mode for the simple graphics that they have. They also all run surprisingly well. Nyet runs pretty much the same as it does on faster machines. Megapede runs well, its speed is CPU dependent and this machine seems to be about ideal. Cyrus chess works about the same as a newer machine, minus the graphics, and it obviously takes longer to work out a good move.

I’m quite pleased to have gotten the machine working again as it would have to be the oldest machine anyone in the family owns. I’ll have to try some more software on it (if I can find any that is compatible) and see if I can get a hercules compatible graphics card. It would be cool if I could get an old version of simcity working on it.




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's Vintage Computing, Tech & Scale RC Blog

Random mutterings on retro computing, old technology, some new, plus radio controlled scale modelling.

ancientelectronics

retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way

lazygamereviews

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