6/03/2006 at 17:20 pm - How install NXDOS on a dual booted PC with WINNT 5.0.
I will assume you start with your NTFS partition as the second one on the disk. Make sure the first is dos formatted with FAT16. (NXDOS will only work from first partition, currently) Then copy BOOT.BIN, NXBIO.SYS and command.com to the root of that drive. You may want to rename BOOT.BIN to NXDOS.BSS if you have other installed. Now you will want to edit BOOT.INI to add an entry for NXDOS as indicated in example below :
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect
c:\BOOTSECT.DOS="Freedos/WIN98 Second Editon (hack)"
c:\NXDOS.BSS="NX-DOS v8.0 (beta)"
c:\g.bin="NX-DOS v8.0 (beta) G.BIN"
In completely re-writing the DOS kernel added a infinate while loop snce the OS has no intention
of exiting when running a computer. This is not exactly a small project, so be patient.
4/20/2006 at 11:07 PM
Added some more routines to the built-in networking and graphics support. It currently has some problems with loading and running .com programs (program locks up if appears to be greater than 512 bytes?).
2/20/2006 at 12:26:02 AM
Finally got the 1.44MB 3 1/2" FAT 12 Boot code to function. It loads NXBIO.SYS into 0060:0000h of conventional RAM. Click on the souce code archive link above for access to these. and of course running "SYS A:" installs the OS onto a floppy diskette. Now I'll have to complete the kernel functions including the file I/O and figure out the FAT 16 support for fixed disk drives.
B.Y.O. DOS, 2/17/2006 at 9:35:26 AM (3/3/2005; 6/9/2005)
I will attempt to present to you the most common pitfalls and mistakes when writing an embedded real-time software system. Most of the problems caused from high-level project management methodologies to inadequate decisions on low-level technical issues of the implementations.
Okay, So lets get started... So you want to make an operating system for your PC or handheld computing device and you want the really cool features. Naturally you want it all yesterday, and tend to let the project slip into disuse. I can't promise you result by yesterday for your particular project but perhaps my experiences on hacking the x86 platform can hopefully point you in the right direction to reduce the number of tomorrows required.
A brief overview of operating system basics, and a discussion on selecting solutions for your hardware needs and take a look at my project solution for comparison. The OS that I built, and prefer very much like a simple program loader, that not spending all my time configuring, re-booting, re-installing, and re-configuring.
The first program you need to make is a zero start binary image of no more than 511 bytes in size. This special program known as an boot sector has a particular format when run on a PC. The BIOS expects to see the ROM ID at end of program (55AAh) and there is a boot parameter block at the top of the program (you jump pass this at offset 0), although you can probably get away with not adhering to the set standard it is best to have it in there for compatibility.
The job of this program is to load the first sectors of the data area from disk and into memory and then execute it. Once that is done, you have to setup the Operating System API interrupts and file management systems for use by applications. This accomplished in the kernel module, is the operating systems control program, like a conductor in a symphony that manages all the I/O and processes in a particular machine. This control program needs to function on its own with a minimum of external reliance of other software's calls (Linux kernel is an example of this). Actually, My code relies on BIOS functions as I have some latitude of freedom on different hardware.
The user interface design is totally up to you. However the simple approch is the tried and true method of enter commandline text and parse for command words much like command.asm uses.
You are going to to have to have a delivery method for your boot up and runtime files and is done using the system file transfer utility (SYS in MS-DOS). This program is basicly the installer for the operating system. Its job is to write the appropiate bootsector and copy the kernel and its support files to the target medium. sys.asm is my on-going attempt.
The operating system used for most (if not all) telecomm data systems needs to be a Real Time Operating System (RTOS). To properly implement standards, you need to be able to count on processing that is very deterministic. Things need to happen when they must happen, and cannot be delayed because some extraordinary event occurred.
It is true that some improved OS's that are not RT have included some prioritization that tends to overcome some concerns. But carefulness is heeded there are instances where you have less than 10ms to react and your system better be there to know it!
The current RTOSes that dominate the offerings are WindRivers' VxWorks & PSOS, OSE, Nucleus (Accelerated Technology) and DataLights ROM-DOS. These are off the shelf alternatives to rolling your own RTOS and you will get better payback than reinventing the wheel.
Recently, Linux OS as a communication application use with major interest in. Linux is not necessary a RTOS but there are some contenders that have allowed it to compete fairly with 2.6 kernel extensions.
An API, the venerable Application Programming Interface is absolutely required if you want to support 3rd party programs on your OS. A good starting point is to clone off the dos interrupts (20h-26h) so you can run dos programs. Next is a filing system, this is basically a table of indexed sectors for each file name. Into this design it must have recover capabilities built in (e.g. backup copy of the table) with the ability to undelete files and directories (e.g. byte/bit mark in file info block). Since Linux is the preferred choice for High Performance Computing, you should make the FS lookup and modify functions as fast as possible. This file system should support compression, encryption, fast access times, security, accounting and so on.
Networking via Ethernet NICs is essential in this day and age, so you must provide a means of interfacing with these (See the 8390 links on the left pane for more info). One idea I have is using the fossil driver INT14 to integrate serial and layered networking protocols.
An operating system must enhance system uptime and operate in an adaptive way in an environment that may have dynamic hardware configurations.
For the most part the GUI is not apart of the OS but just an interface to the OS that uses pictures to represent files on the system. But don't make the GUI the only choice as there are people who upgrade to more capable machines and GUI would like stay in a multitasking 32bit text mode.
The next important asspect that must be included in an OS is a system text file editor. Text file editors are prt text file viewer and editor as seen in my solution as implemented in SLATE.COM source code (slate.asm).
Embedded Systems Conference
A Breif History of DOS