Latest version: 0.04
You are not logged in.
@DennisCGc,
Yeah, laziness tends to get into the way quite frequently too.
BTW, here's a new one for you to try. It should <cross your fingers> pickup your processor. Please let me know the actual identification it displays.
Also, I added some DEBUG printing to see where the OS dies on your system. Let me know what the last message that is displayed...
Offline
It seems to work but I have a little graphic trouble...
Screenshot attached. ( it's related to your font? )
The OS seems to work, however ( the clock goes on... )
Axel
Offline
Hi Axel,
That is an interesting shot. I had reported a similar type instance to Bochs about the Windows version. If you notice the characters on the right side of the screen, they are the begining of the next line. However, the difference between your screenshot and the one I had is that it looks like only the top 8-lines of a 16-line character are being shown. This is not normal...obviously. 
I suspect this may be related to Bochs it self. If you want to test this theory, you could boot DOS within Bochs and the run Chris Giese's 90x60 code: http://my.execpc.com/~geezer/software/90x60.asm to determine if what I'm saying passes the test.
Thanks for testing the OS...
BTW, did you get to test it on a real system?
Offline
DennisCGc wrote:
It hangs at GDT loaded...
(I even tested it with a new disk..)
Any things you're doing at that point ?
I don't have access to my code here at work, but essentially it seems that the CR0 fiddling is the issue; or the loading of that particular selector. I couldn't break it up too much because everytime I print in real-unreal mode, I'm using INT 10h, which interrupts need to be off while fiddling with CRO and establishing the new segments. It doesn't appear that it makes it to the STI instruction, so perhaps my selector (i'll have to post the code when I get home) isn't working correctly with your system.
Out of curiosity, I assume since you didn't mention it, that it identified your CPU ok this time. Is that a safe assumption?
Thanks man...a hefty pint (or shot) of your favorite beverage for you! 
Offline
Thanks!
I figured, but wanted to offer whatever you do drink...as a token of my appreciation. 
Offline
DennisCGc wrote:
It hangs at GDT loaded...
(I even tested it with a new disk..)
Any things you're doing at that point ?
I am tired tonight so I'm heading to bed early. Here is the culprit code for your look-see:
UnrealModeMessage db 'Entering UnReal Mode...',13,10,0 TheCS dw 0 ; DEBUG Messages CLIMessage db 'Interrupts are off...',13,10,0 GDTMessage db 'GDT Loaded...',13,10,0 CR0Message db 'CR0 updated...',13,10,0 STIMessage db 'Interrupts are back on...',13,10,0 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; UnrealMode - Puts the processor into unreal mode to traverse the RAM ;; with ProbeMemory. If not needed it updates the screen with ;; the right information. ;; ;; This is only used currently for testing probing. Will begin ;; protected mode after probing fully tested. ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; UnrealMode: mov si,UnrealModeMessage call PrintString16 .DoProbing: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; New One - Mostly from Chris Geise ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; cli ;Don't allow interrupts during this ; mov si,CLIMessage ; call PrintString16 push ds ;Save real mode selectors push es lgdt [GDTR] ;Load the GDT sti mov si,GDTMessage call PrintString16 cli mov eax, cr0 ;Switch to pmode inc ax mov cr0, eax ; sti ; mov si,CR0Message ; call PrintString16 ; cli mov bx, 28h ; flat_data ;Our only pmode selector mov ds, bx ;Install 4Gb limits (warning) mov es, bx dec ax ;Switch back to real mode mov cr0, eax ; sti ; mov si,CR0Message ; call PrintString16 ; cli pop es ;Restore real mode selectors pop ds sti ;Notice, I never needed to change the CS while in pmode. mov si,STIMessage call PrintString16 mov byte [ProtectedMode],1 jmp .GetOut .LeaveHere: .GetOut: ret
GDT:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; Global Descriptot Table: ;; -- Need to read 80386 Programmer's Rerference for information ;; ;; Discovered today that DEX4u has a much cleaner look and is understandable. I ;; will convert over to that and use the 16-bit information from that GDT. ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; GDTR: dw GDTEnd - BIG_GDT - 1 dd BIG_GDT BIG_GDT: ;------------------------------------------- ; #0 segment descriptor ; dummy ; Intel(c)(r) specifications ;------------------------------------------- db 0,0,0,0 ; the first selector is dummy db 0,0,0,0 ; and unused even by the microP ;------------------------------------------------------------------------ ; so loading a segment register with a "zero" selector ; will show that you dont use that segment ; it is ok with the exception of the CS and SS segment registers ; witch will generate a protection fault if loaded with zero selector ; other "zero" segment registers will GPF only if used ;------------------------------------------------------------------------ ;=========================== ; SELECTOR #1 segment descriptor ; index=0x08H ; SYSTEM_CODE ;============================ ; code ; only read is ok, no write ; nonconforming ; ring 0 ; base=0 ; limit=4Giga ;--------------------------------------------------------------- ; THIS IS/WAS my first "real working" segment descriptor ; I am so proud of it ... hehe ; because i thought i will never make it by hand. ; really ... i should use some structures for GDT and IDT :P ;---------------------------------------------------------------- GDT_CODE_SELECTOR: ; Need to fix this for the real offset from the start dw 0FFFFh ; limit00 to limit15=0xFFFFF=4GigaByte dw 00000h ; base00 to base15=0x0000 ; db 00h ; base16 to base23=0x00 db 09Ah ; 0x9=1001=P/DPL/S ; 0xA=1010=Type=code/nonconforming/read ;------------------------------------------------------------ ; P=1=Present ; DPL=00=Maximum privilege level ...req? or applied? ; S=1=Code or Data Segment (ie not a system segment) ; ; Type=1010=b11:b10:b09:b08 ; b11=1=Code ; b10=0=nonconforming ; b09=1=Read from code segment is acceptable ; please note that writeing to a code segment in never ; acceptable from Intel's point of view... ; b08=0=Accessed is zero...until actually loaded/used? ;------------------------------------------------------------- db 0CFh ; limit16 to limit19=0xF ; 0xC=1100=G:D/B:0:AVL ;-------------------------------------------------------------- ; G=1=Granularity=4Kbyte increments to the limit ; D/B=1=32 bits segment ; AVL=0=this bit is available for use by system software... ; they are generouse 1bit for free...wow! :) ;-------------------------------------------------------------- db 00h ; base24 to base31=0x00 ;========================================================================== ;=========================== ; SELECTOR #2 segment descriptor ; index=0x10H ; SYSTEM_DATA1 ;=========================== ; data ; read / write are ok ; ring 0 ; base=0 ; limit=4Giga ;--------------------------------------------------------------------- GDT_DATA1_SELECTOR: dw 0FFFFh ; 4Gb - (0x100000*0x1000 = 4Gb) dw 00000h ; base address=0 dw 09200h ; data read/write dw 000CFh ; granularity=4096, 386 (+5th nibble of limit) ;=========================== ; #3 segment descriptor ; index=0x18H ; SYSTEM_DATA2 ;============================ ; read / write ; base=0 ; limit=4Giga ;=========================== GDT_DATA2_SELECTOR: dw 0FFFFh ; 4Gb - (0x100000*0x1000 = 4Gb) dw 00000h ; base address=0 dw 09200h ; data read/write dw 000CFh ; granularity=4096, 386 (+5th nibble of limit) ;=========================== ; #4 segment descriptor ; index=0x20H ; SYSTEM_DATA3 ;============================ ; read / write ; base=0 ; limit=4Giga ;=========================== GDT_DATA3_SELECTOR: dw 0FFFFh ; 4Gb - (0x100000*0x1000 = 4Gb) dw 00000h ; base address=0 dw 09200h ; data read/write dw 000CFh ; granularity=4096, 386 (+5th nibble of limit) GDT_DATA4_SELECTOR: dw 0FFFFh ; Base - Limit: 0 - 0FFFFF * 4KB dw 0 dw 9200h ; Type: 16-bit dw 8Fh ; ;-------------------------------- ; fill the rest with zero ;------------------------------- ;TIMES 256 db 0 GDTEnd:
Parts of this GDT are from SolarOS, however I am going to have to clean it up some more for the readability I prefer. As well as RTFM (Read The Frigging Manual). Forum at'cha tomorrow...
Offline
smiddy wrote:
...
BTW, the OS should display everything it is doing on the screen.
...
FIRST RATE JOB! Very clear. Excellent description of what is going on....
At least on my computer, your well written program picked up even which chip was on my sound card! THOROUGHNESS is admirable.
My system has one test computer with DVD, floppy and IDE hard drive plus ethernet, usb, etc, connected along with three other computers to a single monitor/keyboard/mouse via KVM switch. Sorry to say that upon reaching the conclusion of this very nice boot, umm, the keyboard was inoperable, so, I had to turn off the power to the Smiddy computer in order to return function to the keyboard to switch back to one of my other computers, but, that is just a small problem with the end of the boot, i.e. abrupt termination, rather than smooth exit.
Looks good so far, keep up the fine effort, I will study the sources if they are available.....regards, tom
Offline
I have the same problem as on your wifes laptop. It starts the new row one char to early. Looks really wierd...
Can I have a look on your print/scrolling/whatever code..?
Offline
bubach wrote:
I have the same problem as on your wifes laptop. It starts the new row one char to early. Looks really wierd...
Can I have a look on your print/scrolling/whatever code..?
When you do a capture it pastes correctly in say Notepad, yes?
This is a problem with Bochs, I think looking at Axel's screen shot it may be the version. Von Ruppert fixed the problem for the Windows version. It would do like this:
s middyOS Version such and such A 20: Enabled... ...
On MrsSmiddy1 (real boot) the text goes off the edge of the screen, however the first character is correct on each line. The characters to the right are in, I guess never-never land, they don't wrap to the next line. this to me means that the memory is written to corectly, there is an issue with the VGA 90 x 60 setup. It is a WXGA card (the specific one I can't recall; at work).
Anyway, I'll paste my routine for view when I get home this evening. BTW, in real mode I am using INT 10h. In PMode, I am using a modified version of your code for the text driver.
@tomtobias:
Thanks for the complement. I haven't done a graceful retreat yet for protected mode. There are routines in place it something fails in real mode to force either a reboot (boot loaded) or return to DOS (DOS loaded). In protected mode I am instead of:
jmp $
I am calling a routine to get the current time from the CMOS.
@All,
Apparently, embarrassingly, I forgot to put in place a mechanism to fall back in case PCI32 isn't installed. The routine gets run even though it isn't there. This is troublesome because I had put in place a way of over writting the code for a far call. I have no idea what the address is that it is trying to call, and for that matter why it finishes looking at all the devices within the list, when booted under Bochs without i440FX enabled. I will fix this fairly quickly though.
Last edited by smiddy (2005-06-16 16:49:23)
Offline
Hi bubach,
Here is the scroll up routine:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; To scroll up one row ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ScrollUp: push esi movzx eax, byte [NumberOfRows] movzx ebx, byte [NumberOfColumns] mul ebx dec eax add eax,eax ; Maximum text memory location add ebx,ebx ; Start of Row 2 mov edi,ebx add edi,dword [TextMemoryLocation] ; Starting location in memory add eax,dword [TextMemoryLocation] ; Ending Memory Location .Looper: mov esi,edi sub esi,ebx mov dl,byte [es:edi] mov [es:esi],dl ; Copy line to previous line inc edi ; Increment EDI cmp edi,eax ; If EDI is at the end jg .ClearLine ; then clear the end line jmp .Looper ; else keep going .ClearLine: sub edi,ebx ; Reset EDI to begining of last line inc edi .SecondLooper: mov [es:edi],byte 20h ; Place a space there inc edi inc edi cmp edi,eax ; If EDI is at the end jg .Finished ; then clear the end line jmp .SecondLooper ; else keep going .Finished: pop esi RET
I am uploading the file too for your review. I tried to keep a decent record on this file, but somethings have lapsed. Please be critical of my code, or use it as you will. I will eventually come up with some sort of (C) Copyright Statement. And other agreements for liabilities protection when I do post the entire OS code.
Offline
Thanks Smiddy, I enjoyed reviewing your code. In it you mention (rather thorough documentation, in my opinion, and reasonably complete) that a portion of the code is coming from BOS. That's perfectly satisfactory, however, it would be good, in such a situation, to acknowledge the specific lines which were borrowed, so that proper attribution can be made.
A couple of comments. Your OS, on boot up, gives very precise information, (very desirable feature, in my opinion), in other words, it would appear that you are quite comfortable accessing individual motherboard components. If so, (and I hope that is the case), may I ask, sincerely, WHY are you fooling around with BIOS in this routine? BIOS, so far as I know, and maybe things have changed during the past quarter century, is a REAL MODE set of routines. It is not appropriate, to the best of my knowledge, to be using it for a PROTECTED MODE OS, operating at ring zero for all user applications, unless you envision the user DEPARTING from protected mode, to access the hardware, i.e. switching back and forth, constantly. Have you considered the possibility of creating your own 32 bit protected mode routines to replace the 16 bit real mode BIOS calls? I think it is EASIER to use someone else's BIOS, but wouldn't it be more creative, to say nothing of FASTER, to STAY in Protected Mode, and call the graphics routines, adjusting the cursor position, clearing the screen, and so on, FROM PROTECTED MODE, without using BIOS? Remember, please, that in that era, 25 years ago, when BIOS was evolving, THERE WAS NO PROTECTED MODE, and MEMORY WAS VERY PRECIOUS. Today, one could have ALL 32 bit values (no bit shifting, for a simpler, and faster access, squandering memory, but gaining both readability and speed of execution.
Secondly: (and this is even more trivial:) You wrote:
.Backspace:
mov al,20h ; Put space at last screen location
dec edi ; Backup edi
dec edi ; to last screen location
mov [es:edi],word ax
....... etc
When I see dec edi, twice, I wonder, why not simply subtract once, instead of decrementing twice?
For my own education, why is it necessary to indicate the fact that ax represents the low order 16 bits of eax? Does the assembler require specification of the width of ax?
What would happen if you simply wrote mov [es:edi],ax ?
I would profit from reading the rest of your code, if it is available for my perusal.
regards, tom
Offline
tomtobias wrote:
If so, (and I hope that is the case), may I ask, sincerely, WHY are you fooling around with BIOS in this routine?
You would instead squeeze all known motherboard drivers into the kernel and cycle between each one until you find the right motherboard?
@smiddy:
Sorry as of today I couldn't find the time to test the Bochs + DOS + 90x60 test.
I'll try later this night and I'll give you detailed results ( I'm using Bochs 2.2 so if it gives the same error I could argue that's a Bochs problem ). I'm interested in having customizable text mode in my OS, too... so I'll try to test it hard
Axel
Offline
tomtobias wrote:
mov al,20h ; Put space at last screen location
dec edi ; Backup edi
dec edi ; to last screen location
mov [es:edi],word ax
When I see dec edi, twice, I wonder, why not simply subtract once, instead of decrementing twice?
If i remember my size optimizing, 2 "dec", is smaller than 1 "sub".
Offline
Dex4u wrote:
....
If i remember my size optimizing, 2 "dec", is smaller than 1 "sub".
Well, this is my own personal BIAS, opinion, not fact, just point of view:
I don't care if it is 1000 times slower, or takes up 1000 times more memory: LET IT BE READABLE. That is FAR MORE IMPORTANT (to me) than any mythical savings in either time or space.
Repetition is done for other reasons too, NONE OF THEM GOOD.
As I wrote, just my opinion.....
tom toBIAS
Offline
WOW! I am so excited by these posts. I only wish I had time right now to address everything.
I have to take my 2 year old out to ride his bicycle. I will be back later to address everything you'all have asked. In my own vernacular, this is good poop! <- Changed poop to your favorite excrement explitive...
Offline
AxelDominatoR wrote:
You would instead squeeze all known motherboard drivers into the kernel and cycle between each one until you find the right motherboard?
Well, thanks Axel, good question. Let me try to give a suitable answer. Let's see, now, to begin, one should estimate the number of motherboards in this GIGANTIC data base:
let's say 50 manufacturers, ok, let's keep it simple: 100 different manufacturers.
Let's further suggest EACH manufacturerer has produced 10 new boards per year for the last 10 years, i.e. the approximate lifespan of the cpu supported by the os. So what does that give us, about, 10,000 different motherboards.
Wow, a data base with 10,000 entries, how long would it take to find motherboard X in that group? I guess less than 1 millisecond, even if we follow the sequential path you imply, instead of a more rapid search algorithm. If each search required a comparison to a memory location, increment the address, next, until end: what is that, about 100 nanoseconds per item? So, then what: 1,000,000 nanoseconds, is about 1 milliseconds? Even if the code required TEN TIMES as many instructions to complete the cycle of load, compare, increment, next, the whole task would require a maximum of 10 milliseconds. And if I have erred by a factor of ten on the quantity of different unique motherboards, it still requires not more than 100 milliseconds to search the entire group. An eyeblink requires 60 milliseconds, by comparison....
So, I am not intimidated by that chore. I am intimidated by the chore of reading sloppy, poorly documented code. That is tough. And I am surely confused about the need to employ BIOS routines operable only from real mode to permit protected mode programs to access hardware.
regards, tom
Offline
@tomtobias:
Sorry, I mean no offense... but I think that having a database only to obtain informations it's a bit "overkill".
And, personally, I don't think that using BIOS routines will make a code unreadable. ( It's always good old assembly, syntax doesn't change a bit )
@smiddy:
test done...
Putting it in a DOS floppy and running it, the 90x60 test trashes happily the screen the same way as your OS do. ( see attached screenshot )
Now... knowing that this happens to other "real" PC as well it may be a coding problem on that 90x60 code.
I'll do some tries & researches to see if I can find the problem, but I cannot guarantee how much time I can spend on it right now.
I hope that good news will follow
Offline
)
