Sunday, December 16, 2007
Emulating IBM OS/2 Warp 4.0
This system is tested using Bochs, and having some difficulties. Cannot click to run program. I don't know why. I will try again using VMware later.
Sunday, December 9, 2007
IBM PC-DOS 1.00
Hello Guys,
My first post on emulating the DOS, would be using IBM Personal Computer DOS version 1.00 which was released by IBM in the year 1981.
The history says that,
Enough the history, I was able to secure a copy through ***** from ***** and after doing MD5 checksum, the result is: 73c919cecadf002a7124b7e8bfe3b5ba which has the same result as Daniel B. Sedory (http://thestarman.pcministry.com/DOS/ibm100/Exam.htm)
Let have a look from some screen capture, I made through BOCHS.
If someone would like to make a comment, I would be most welcome.
Regards,
Adhall W. Idrewoods
My first post on emulating the DOS, would be using IBM Personal Computer DOS version 1.00 which was released by IBM in the year 1981.
...
The history says that,
IBM® Personal Computer™ DOS 1.00 was a result of the vision and efforts of many different people; including various employees of both IBM® and Microsoft®. Some would say that DOS owes a great deal more to the creator of CP/M (Gary Kildall) than either IBM® or Microsoft® would ever admit to. If you want an honest assessment, I suggest you find a group of disinterested assembly programmers to compare the code from CP/M and DOS rather than relying on Net rummors! Most would say the majority of the initial work had been accomplished by Tim Paterson, who created much of the system code while employed at Seattle Computer Products where he wrote QDOS (Quick and Dirty Operating System). Bill Gates and Marc McDonald, however, actually invented the File Allocation Table (FAT) file system for Microsoft's standalone BASIC in 1977 which Paterson later used to store and work with files under QDOS.
Apart from the DOS system code, Paterson also produced two system utilities that found their way onto IBM's diskette, the most notable being DEBUG. After Microsoft® acquired the rights to sell what was then called 86-DOS, Paterson joined that company in order to help complete their 'secret project' for IBM® (i.e., Personal Computer™ DOS 1.00). At least one other Microsoft employee, Robert O'Rear (whose name is embedded in the Boot Sector), spent a great deal of time on this project as well. There were a number of IBM employees who worked on hardware interface code, wrote applications software for the operating system and spent time testing each change made along the way (some of their names are embedded in various BASIC and system programs on the diskette).
Of the 40 files on this diskette, 38 of them can be listed using the operating system's DIR command; they all had the same date: 08-04-81. However, the two Hidden System files have different dates: The earliest file on the disk, IBMBIO.COM, was dated July 23, 1981, and latest one, IBMDOS.COM, had a date of August 13, 1981.
This information was taken from Daniel B. Sedory (Thank you!), if you need more information please read at:
http://thestarman.pcministry.com/DOS/ibm100/
Enough the history, I was able to secure a copy through ***** from ***** and after doing MD5 checksum, the result is: 73c919cecadf002a7124b7e8bfe3b5ba which has the same result as Daniel B. Sedory (http://thestarman.pcministry.com/DOS/ibm100/Exam.htm)
Let have a look from some screen capture, I made through BOCHS.
Click on each image to enlarge!
If someone would like to make a comment, I would be most welcome.
Regards,
Adhall W. Idrewoods
Sunday, December 2, 2007
Settings Mac OS X Dual-boot Using Windows XP Bootstrap
I installed OS X on a separate hard drive. I used the bootloader built into Windows.
The copy the chain0 file from
to
Then add
To my Windows bootloader (file boot.ini). It works flawlessly. When I turn the computer on, I get a menu for
I can choose either, and once I select and press enter, it automatically boots into the desired OS. No other settings required.
Hope this helped those who had problem into booting to Mac OS X or finding a software that can dual-boot Windows and Mac OS X. Why get 3rd party, when Windows already have the functionality.
To get more information about chain0, please visit Wiki page on the subject. Also available for download the chain0 file itself.
http://wiki.osx86project.org/wiki/index.php/Chain0
Regards,
A. Idrewoods
The copy the chain0 file from
/usr/standalone/i386/chain0
to
C:\chain0
Then add
C:\chain0="Mac OS X"
To my Windows bootloader (file boot.ini). It works flawlessly. When I turn the computer on, I get a menu for
Windows XP
Mac OS X
I can choose either, and once I select and press enter, it automatically boots into the desired OS. No other settings required.
Hope this helped those who had problem into booting to Mac OS X or finding a software that can dual-boot Windows and Mac OS X. Why get 3rd party, when Windows already have the functionality.
To get more information about chain0, please visit Wiki page on the subject. Also available for download the chain0 file itself.
http://wiki.osx86project.org/wiki/index.php/Chain0
Regards,
A. Idrewoods
Running Mac OS X on Intel Pentium IV
Mac OS X
Windows XP
These are expectable screen shot of Mac OS X and Windows XP. (these are not mine, just to show what we can expect to see).
I have tested running Mac OS X on Intel Pentium IV on a partition. This is my experience.
I have formatted and executed Norton PartionMagic 8.05 to partition my hard disk. I have just added a new hard disk, 320GB, making the total space I have 600GB. One partition at 50GB.
Previously, I installed Windows Vista. Though it has good interface, nice to use, but it didn't come to my expectation of easeness to XP likeness. So, I decided to install Windows XP. Having so much problem due to jumper and BIOS settings, I grab Mac OS X and installed onto second partition of first hard disk.
Things went smoothly and the interface was great!
Later, when I tried to install Windows XP and worked, i tried to boot to Mac OS, but I don't know how.
Only a week later, when I decided to search though Google, with this keyword "dual boot windows xp mac os x", I found a website giving instruction, damn easy instruction and using file CHAIN01 and change (by adding single line) in boot.ini that allows me to select Mac OS X boot partition.
So, now I can use both Windows XP and Mac OS X.
Unlike the so many myths online, I am running Mac OS X natively without making any patches. But, still I am having little problems, image file (JPEG, PNG) cannot be viewed using default program and I cannot even play DiVx files. Bad though, because I don't know where to find those program. I am not fluent in Mac OS X.
So, if anyone need helps to install or booting Windows XP and Mac OS X, please post a comment, or contact me and I shall write a simple tutorial here.
Will update "screen capture" (using Nikon camera).
Until then and best wishes.
Adhall W. Idrewoods
System Emulator - Qemu
QEMU is a fast processor emulator, written by Fabrice Bellard, which allows full virtualization of a PC system within another one. It is free software. In particular, the QEMU virtual CPU core library is released under the GNU Lesser General Public License (GNU LGPL). Many hardware device emulation sources are released under the BSD license. When running on Windows, the proprietary FMOD library is usually used, which disqualifies it for a single, unified, Open Source software license. QEMU is a hypervisor and is similar to projects such as Bochs, VMware Workstation and PearPC, but has several features these lack, including increased speed on x86 (through an optional accelerator), and support for multiple architectures in-progress. By using dynamic translation it achieves a reasonable speed while being easy to port on new host CPUs.
Qemu Launcher is a Gtk+ front-end for the QEMU, written by Erik Meitner and Linas Žvirblis. Qemu Launcher provides a graphical front-end to all basic, and many advanced QEMU computer emulator options. It allows you to create, save, and run multiple virtual machine configurations, create and convert disk images. Qemu Launcher utilizes the full system emulation mode of QEMU that allows you to run unmodified operating system on virtual hardware. Qemu Launcher also supports launching virtual machines from the command line, by specifying the configuration name. Note that you still need a graphical environment to do this, unless the virtual machine is set to start in non-graphics mode.
I like this program because it has Windows interface, and it can run VMware images. I tried to run Mac OS, but failed. But I am still using this program, interchangably with Bochs.
Rating: 3.8/5.0
QEMU on Windows
http://www.h7.dion.ne.jp/~qemu-win/
QEMU running on Debian Linux. Windows XP is running inside the virtual machine, which in turn is running Internet Explorer 6 displaying the Wikipedia front page.
Qemu Launcher is a Gtk+ front-end for the QEMU, written by Erik Meitner and Linas Žvirblis. Qemu Launcher provides a graphical front-end to all basic, and many advanced QEMU computer emulator options. It allows you to create, save, and run multiple virtual machine configurations, create and convert disk images. Qemu Launcher utilizes the full system emulation mode of QEMU that allows you to run unmodified operating system on virtual hardware. Qemu Launcher also supports launching virtual machines from the command line, by specifying the configuration name. Note that you still need a graphical environment to do this, unless the virtual machine is set to start in non-graphics mode.
I like this program because it has Windows interface, and it can run VMware images. I tried to run Mac OS, but failed. But I am still using this program, interchangably with Bochs.
Rating: 3.8/5.0
QEMU on Windows
http://www.h7.dion.ne.jp/~qemu-win/
QEMU running on Debian Linux. Windows XP is running inside the virtual machine, which in turn is running Internet Explorer 6 displaying the Wikipedia front page.
Thursday, November 29, 2007
Emulator 1 - Bochs
Bochs is a portable x86 and AMD64 PCs emulator mostly written in C++ and distributed as free software under GNU Lesser General Public License. It supports emulation of the processor(s) (including protected mode), memory, disks, display, ethernet, BIOS and common hardware peripherals of PCs.
Many guest operating systems can be run using the emulator including DOS, several versions of Windows, BSDs, Linux, AmigaOS and MorphOS. Bochs can run on many host operating systems, including Windows, Linux, Mac OS X.
Bochs is mostly used for operating system development (when an emulated operating system crashes, it does not crash the host operating system, so the emulated OS can be debugged) and to run other guest operating systems inside already running host operating systems. Some people use it to run older software – such as computer games – which will not run on their non-compatible computers.
Bochs can emulate the hardware needed by the guest operating system, including hard drives, CD drives, and floppy drives. Disk and ISO images can be "inserted" while the system is being run. However, the system performance is very slow due to the fact that it is only emulated. It doesn't provide any CPU virtualization features. However, it is useful for capturing screen shots in researching old DOS software. Bochs is widely used for hobbyist OS developing, as it saves the need for constant system restarts (to test code) Bochs is preferred by OS developers because it has error reporting and dump files that other emulators lack.
I am using this software as it is light but little hard to use for those who don't really know how to "scripting", since this program run from DOS without special Windows interface.
Rating: 4.2/5
Tested system: PC-DOS 1.10, MS-DOS 2.xx until 6.22, Windows 1.01 until Windows 3.11 (but for Windows 1.01, 1.02, 1.03 appear in black-n-white, instead of colours).
Click on the picture to enlarge, screen captured on Windows 95 guest system.
Many guest operating systems can be run using the emulator including DOS, several versions of Windows, BSDs, Linux, AmigaOS and MorphOS. Bochs can run on many host operating systems, including Windows, Linux, Mac OS X.
Bochs is mostly used for operating system development (when an emulated operating system crashes, it does not crash the host operating system, so the emulated OS can be debugged) and to run other guest operating systems inside already running host operating systems. Some people use it to run older software – such as computer games – which will not run on their non-compatible computers.
Bochs can emulate the hardware needed by the guest operating system, including hard drives, CD drives, and floppy drives. Disk and ISO images can be "inserted" while the system is being run. However, the system performance is very slow due to the fact that it is only emulated. It doesn't provide any CPU virtualization features. However, it is useful for capturing screen shots in researching old DOS software. Bochs is widely used for hobbyist OS developing, as it saves the need for constant system restarts (to test code) Bochs is preferred by OS developers because it has error reporting and dump files that other emulators lack.
I am using this software as it is light but little hard to use for those who don't really know how to "scripting", since this program run from DOS without special Windows interface.
Rating: 4.2/5
Tested system: PC-DOS 1.10, MS-DOS 2.xx until 6.22, Windows 1.01 until Windows 3.11 (but for Windows 1.01, 1.02, 1.03 appear in black-n-white, instead of colours).
Click on the picture to enlarge, screen captured on Windows 95 guest system.
Understanding System Emulator
An emulator is also known as virtual machine, since it simulate and running the system on a virtual peripherals.
An emulator duplicates (provides an emulation of) the functions of one system using a different system, so that the second system behaves like (and appears to be) the first system. This focus on exact reproduction of external behavior is in contrast to simulation, which can concern an abstract model of the system being simulated, often considering internal state.
Most emulators just emulate a hardware architecture — if operating system firmware or software is required for the desired software, it must be provided as well (and may itself be emulated). Both the OS and the software will then be interpreted by the emulator, rather than being run by native hardware. Apart from this interpreter for the emulated machine's language, some other hardware (such as input or output devices) must be provided in virtual form as well; for example, if writing to a specific memory location should influence the screen, then this would need to be emulated.
While emulation could, if taken to the extreme, go down to the atomic level, basing its output on a simulation of the actual circuitry from a virtual power source, this would be a highly unusual solution. Emulators typically stop at a simulation of the documented hardware specifications and digital logic. Sufficient emulation of some hardware platforms requires extreme accuracy, down to the level of individual clock cycles, undocumented features, unpredictable analog elements, and implementation bugs. This is particularly the case with classic home computers such as the Commodore 64, whose software often depends on highly sophisticated low-level programming tricks invented by game programmers and the demoscene.
In contrast, some other platforms have had very little use of direct hardware addressing. In these cases, a simple compatibility layer may suffice. This translates system calls for the emulated system into system calls for the host system.
Developers of software for embedded systems or video game consoles often design their software on especially accurate emulators called simulators before trying it on the real hardware. This is so that software can be produced and tested before the final hardware exists in large quantities, so that it can be tested without taking the time to copy the program to be debugged at a low level without introducing the side effects of a debugger. In many cases, the simulator is actually produced by the company providing the hardware, which theoretically increases its accuracy.
CPU Simulator
The CPU simulator is often the most complicated part of an emulator. Many emulators are written using "pre-packaged" CPU simulators, in order to concentrate on good and efficient emulation of a specific machine.
The simplest form of a CPU simulator is an interpreter, which follows the execution flow of the emulated program code and, for every machine code instruction encountered, executes operations on the host processor that are semantically equivalent to the original instructions.
This is made possible by assigning a variable to each register and flag of the simulated CPU. The logic of the simulated CPU can then more or less be directly translated into software algorithms, creating a software re-implementation that basically mirrors the original hardware implementation.
The following example illustrates how CPU simulation can be accomplished by an interpreter. In this case, interrupts are checked-for before every instruction executed, though this behavior is rare in real emulators for performance reasons.
Summary
Therefore, if you really interested into running old software, you would certainly need to choose a correct simulator for your PC.
The choice of virtual machine/emulator maybe (to which I have already used),
VMware
Microsoft Virtual PC
Bochs
Qemu
There maybe other simulator but I will not be stressing on those. I will give example based on these simulator.
I will post information on these programs, therefore wait for my future post.
Adhall W. Idrewoods
VG
An emulator duplicates (provides an emulation of) the functions of one system using a different system, so that the second system behaves like (and appears to be) the first system. This focus on exact reproduction of external behavior is in contrast to simulation, which can concern an abstract model of the system being simulated, often considering internal state.
Most emulators just emulate a hardware architecture — if operating system firmware or software is required for the desired software, it must be provided as well (and may itself be emulated). Both the OS and the software will then be interpreted by the emulator, rather than being run by native hardware. Apart from this interpreter for the emulated machine's language, some other hardware (such as input or output devices) must be provided in virtual form as well; for example, if writing to a specific memory location should influence the screen, then this would need to be emulated.
While emulation could, if taken to the extreme, go down to the atomic level, basing its output on a simulation of the actual circuitry from a virtual power source, this would be a highly unusual solution. Emulators typically stop at a simulation of the documented hardware specifications and digital logic. Sufficient emulation of some hardware platforms requires extreme accuracy, down to the level of individual clock cycles, undocumented features, unpredictable analog elements, and implementation bugs. This is particularly the case with classic home computers such as the Commodore 64, whose software often depends on highly sophisticated low-level programming tricks invented by game programmers and the demoscene.
In contrast, some other platforms have had very little use of direct hardware addressing. In these cases, a simple compatibility layer may suffice. This translates system calls for the emulated system into system calls for the host system.
Developers of software for embedded systems or video game consoles often design their software on especially accurate emulators called simulators before trying it on the real hardware. This is so that software can be produced and tested before the final hardware exists in large quantities, so that it can be tested without taking the time to copy the program to be debugged at a low level without introducing the side effects of a debugger. In many cases, the simulator is actually produced by the company providing the hardware, which theoretically increases its accuracy.
CPU Simulator
The CPU simulator is often the most complicated part of an emulator. Many emulators are written using "pre-packaged" CPU simulators, in order to concentrate on good and efficient emulation of a specific machine.
The simplest form of a CPU simulator is an interpreter, which follows the execution flow of the emulated program code and, for every machine code instruction encountered, executes operations on the host processor that are semantically equivalent to the original instructions.
This is made possible by assigning a variable to each register and flag of the simulated CPU. The logic of the simulated CPU can then more or less be directly translated into software algorithms, creating a software re-implementation that basically mirrors the original hardware implementation.
The following example illustrates how CPU simulation can be accomplished by an interpreter. In this case, interrupts are checked-for before every instruction executed, though this behavior is rare in real emulators for performance reasons.
Summary
Therefore, if you really interested into running old software, you would certainly need to choose a correct simulator for your PC.
The choice of virtual machine/emulator maybe (to which I have already used),
VMware
Microsoft Virtual PC
Bochs
Qemu
There maybe other simulator but I will not be stressing on those. I will give example based on these simulator.
I will post information on these programs, therefore wait for my future post.
Adhall W. Idrewoods
VG
Subscribe to:
Posts (Atom)