johnc@rtmvax.UUCP (John Connin) (01/27/88)
Concerning: > From: Leisner.Henr@xerox.com (Marty) > Newsgroups: comp.os.minix > Subject: what I'm doing with protected mode Minix (very long) > Message-ID: <1022@louie.udel.EDU> > Date: 20 Jan 88 16:17:25 GMT I too have been working with Protected Mode Minix for about the same period of time as Martin Leisner and thus find it gratifying that there is at least one other person in this world who has thoughts and ideas in this area. I am new to usenet, so if I am not aware of previous articles, please excuse me. Since there may be other PM-Minix projects going on a well, it seems reasonable at this time to get the parties in contact with one another to facilitate sharing of substantive matters. Ergo, the purpose of this message and the REQUEST that others who are involved with Protected Mode Minix implementations articulate their activities on comp.os.minix -- who knows what might unfold. ------------------------------------------ Given the desire for Protected Mode operation, it is really interesting for me to see the degree of difference and yet similarities between Martin's work and mine. On the surface, the differences seem to derive from different objectives and implementation tools. My objectives were/are generally in no particular order: 1. Minimum changes to Real Mode Minix and where changes are required keep them to the lowest level possible. In other words, remain compatible with the main stream of Minix development (eg. source code). Status - remarkable successful. 2. The ability to "hot key" between MSDOS and Minix. That is MSDOS resides in the first 640k of memory and Minix resides above one mega-byte, with each sharing common physical resources. Status - working fine except disk access by Minix is causing interference subsequent MSDOS disk access (ie after hot key switch) and vice versa. I quess I need to learn how to save the disk controller context on each side of the fence -- Does anyone have any ideas?. 3. Position Minix as a screen oriented single-user multi-tasking operating system with Version 7 compatibility. Status - evolving, currently has 4 virtual terminals, and some ANSI support. Though my objectives included keeping Minix portable to the extent possible, the development tools I used are certainly not very portable. The method I use to create the loadable operating system are as follows: 1. Assemble/compile source with MicroSoft MASM and MSC under MSDOS to create objects in 86 OMF format. 2. Convert the 86 OMF objects to Intel 286 OMF format. 3. Bind the Intel 286 OMF modules into a loadable module using Intel's BLD286 utility. BLD286 automatically creates the various GDT, IDT and LDT's based upon a specification file and the OMF modules and produces a loadable file. 4. Using a loader evoked under MSDOS, load the file image, switch to the protected mode, perform final fixups, relocate the executable image to the target address, and jump into the initial context (ie. main() ). The target address can be specified on the command line. NB. The above applies to the operating system code only. Application code can be compiled in the normal manner (i.e the small model real mode code will run in the protected mode WITHOUT modification). For some reason this was a surprise to me. I have not attempted it, but I believe a tool can be constructed which would permit the construction of the operating system entirely with 86 tools. The idea being that the tool would (a) accept the 86 OMF objects and a build specification file as input producing a ASM file defining the Protected Mode tables, and (b) modify various records within the 86 OMF's in a manner that the code would employ the virtual addressing of the Protected Mode tables in lieu of real addresses. As envisioned, the modified objects would then be combined in the normal manner with a 86 linker. ---------------------------------------------- Observations, comments and questions re: Martin's article: 1. Two hole lists are not required. Simply initialize mm/alloc with total memory and then alloc, during mm initialization, the memory not available to Minix. 2. My implementation also treats all interrupts as tasks. This is clean and easy to do. However, high rate interrupts may best be handled in the normal fashion. 3. Once I got PM-Minix running properly, it has been rock solid in that no Protect Mode exceptions are being generated. 4. I am not sure I understood the discussion concerning a separate idle task. HARDWARE is a separate task invoked when there is noting else to due. 5. Handling non-zero initial IP is easy to implement. I had to implement this to accommodate MSC. Even with crtso as the first object, under MSC the initial IP will be 0x0010. The first 16 bytes of the executable image are zero for reasons I assume are related to NULL pointer protection. 6. Installable device drivers would indeed be desirable. 7. The hanging problem on boot-up sounds like the 286 task state register is not being properly initialized prior to the first task switch. 8. The purpose of creating regions was not clear to me. ---------------------------------------------- IN ANY EVENT, I would be appreciate hearing from all you out there, where every you are, on your thoughts, ideas and contributions which, perhaps, may lead someday to a "definitive" Protected Mode Minix implementation. John L. Connin UUCP: codas!alxfin!rtmvax!johnc