Peter's site blog

Strange DOSBOX (with latest version 0.74-3) behaviour with a sample benchmark program 
Monday, February 8, 2021, 11:58 AM
Posted by Administrator
To have some new examples for x86 assembler programming, I've created also one sample with a small benchmark program, which should work with old PCs like the IBM PC/XT.
This program, created with an assembler source for MASM 5.10, will measure basically for a defined period of time (5 seconds, or in 1/18.2 sec ticks exactly 91 ticks) how fast one char is displayed with the help INT 10h function 09h (a BIOS function, not DOS related). I was trying to implement it via INT 10h function 0Eh (tty type output), but this was not working because function 0Eh is working only in graphics mode.
I didn't liked to implement it by writing directly into video RAM (beginning at 0B800:0h for CGA, EGA and VGA), because I wanted to avoid screen snow with a CGA.

I tested it with several virtual, emulated PCs (from IBM PC/XT up to a PC with a Pentiumn 233 MMX), and also with some real, existing PCs I had.

Usually, DOSBOX, especially if the cycle value is increased or unlimited, but also even with the default settings, is really fast and things will work really good.

With my sample bench program, this ends up in a surprise !
DOSBOX wasn't the fastest choice. It started very fast, but after a moment, was slowing down drastically with the video output. I didn't try to analyze the reason (by reviewing the DOSBOX source), but it was interesting.

PCem with the emulated Pentium MMX 233 was way faster (~ 982 loops for DOSBOX, ~ 1700 for the emulated PCem v17 PC). I guess I need an explanation why this happens, but I fear emulated PCs (using PCem) with a real BIOS are much better in terms of (text) video output, because there is no caching or memory limit while executing the emulation.

Added later: It depends of the "cycle" value, if the value is above ~4000 (or even "max"), you will get the mentioned effect, if it's the default value of 3000, the effect is almost invisible. But still a strange effect.

See 'related link' for a download possibility of the benchmarking program (with source code). See also my >youtube video<.

I would really, really appreciate some result values from REAL machines. Many thanks for any value in advance. You can use the comment function (at least for about 60 days after posting this) and/or the contact function here.
add comment ( 1 view )   |  permalink   |  related link   |   ( 3.1 / 86 )
Ghost HDD imaging history ... Wikipedia ignores versions below 3 
Monday, December 28, 2020, 05:59 PM
Posted by Administrator
Most of you know "Norton Ghost", even more often known as "Symantec Ghost".
But it wasn't published by Symantec first. Binary Research started to sell Version 1.0 (1.1) in 1996, followed by Version 2.0 (2.07) and Version 3.0 (3.1) - latest minor version in brackets.
The first 2 versions runs even with an IBM XT and without extended memory.
Starting with Version 3 it uses XMS and needed a 286 CPU, Version 4.0 uses Pharlab Extender, but is still running at least with a 286. Starting with Version 5.0, it's running with an 386 and higher. So, if you want to create a hard disk drive image for an IBM AT clone, you can go on with Ghost 4.0a, and the best, it can still be read by later Ghost versions (e.g. with Ghost Explorer). So that could be a way to virtualize your HDD content (and running it with VMWare, VirtualBox or PCem).
For the first 3 versions valid: It can also run with OS/2.

I have made some screenshots, the first 4 versions are running in text mode, starting with Ghost 5, it is a graphics screen with VGA resolution.

This is version 2.07:


Version 3.1a:


Version 4.0a:


Well known, starting with Version 5, all later versions having the same look alike:


Ghost Version 1.1 did not support FAT32,
starting with Version 2.0 it had support for FAT32. Both run with conventional RAM only, too.
Since Ghost 3.0, partitions can be imaged as well as a whole drive, but XMS is needed.
Ghost 4.0 images can be read from later Ghost versions.
Ghost Version 5 breaked the 8GB (BIOS) barrier.

Btw. Wikipedia does not list up earlier versions than 3. My blog entry does this ;-)

1 comment ( 7 views )   |  permalink   |  related link   |   ( 3 / 168 )
Remarkable site and blog: The 'Computer History Museum' 
Monday, December 21, 2020, 12:49 PM
Posted by Administrator
I just want to point out that there is a site and blog you must visit:
The 'Computer History Museum'.

The blog is still actualized regularly, and points out many historical facts beside of other more ore less computer related facts but also opinions.

The site itself does NOT only shows vintage computer technology, but covers also infos about 'remarkable' people, and beside this, it has a very interesting corner named "Internet History Program Archiv". It's NOT an archive like, it's moderated and selected.
It lists up also recent and upcoming computer history related events in the U.S..

I like the concept in general also, because you will still find interesting entries even after your 10th visit, very good. It's like a kind of mirror of the "old times", like a time travel.

add comment ( 6 views )   |  permalink   |  related link   |   ( 3 / 332 )
Two interesting pages about the Olivetti M20 - one of the few computer which have a Z8000 and can run CP/M-8000 
Wednesday, December 16, 2020, 12:25 AM
Posted by Administrator
Full with additional links and infos, more than just a vintage computer museum entry:

To get an impression from what I'm talking - here's an image from an M20 machine,
running CP/M-8000 (click on the picture to zoom):

The machine was selled in 1982 with PCOS (that's an operating system with cryptic commands, even more cryptic than CP/M was)...

There was an additonal 8086 card available to run MS-DOS, but that's another story.
The cpu was - to document it more accurately - a Zilog 8001, the cpu family is named 'Z8000'.

Still one of the most "rich" web pages about the Olivetti M20 can be found at

2 comments ( 213 views )   |  permalink   |  related link   |   ( 3.1 / 8910 )
Off topic: Microsoft Safety Scanner ... not really recommendable. See why. 
Tuesday, November 17, 2020, 02:00 PM
Posted by Administrator
Many of you may know that there is an offline malware scanner from Microsoft existing, it's a portable app, so you don't need to install it (just extract it from an archive and start it) - the Microsoft Safety Scanner ... also known as MSERT.
I tested this tool a few times, but I found some points really annoying, beside the fact it also helped to find some WM97 Downloader variants not found by Symantec Endpoint Protection for example.

It is very slow, despite of the choice you're taking at the beginning of the scan process. It can take hours to be finished.

Also, it does not only find malware, but also network tools, and other useful tools e.g. found at Nirsoft's page. You can't choose what type of files you want to scan.

It cannot handle less established archive formats. It scans even ISO images, report findings, but let the ISO as is (this can be also an advantage, though).

At the end, it does not ask what to do with the findings. They/it will be moved into quarantine. There is no possibility to make a decision for each file, nor how to deal in general with findings.

You can't restore files from the quarantine (files are encrypted). So may be you need a backup before scanning with MSERT.

I would recommend (for unencrypted drives) to use ESET SysRescue Live instead for scanning "offline" for malware.
add comment ( 7 views )   |  permalink   |  related link   |   ( 3 / 485 )

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Next> Last>>