You are not logged in.


#21 2005-06-15 00:37:12

smiddy
Active member
Registered: 2005-02-15
Posts: 183
PM

Re: smiddyOS image for your pleasure...

@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...


Attachments:
Attachment Icon smiddyOS.IMZ, Size: 173,063 bytes, Downloads: 1,368

- [color=red]s[/color][color=blue]m[/color][color=red]i[/color][color=blue]d[/color][color=red]d[/color][color=blue]y[/color]

Offline

 

#22 2005-06-15 01:32:37

AxelDominatoR
Member
From: Reggio Calabria, Italy
Registered: 2005-03-07
Posts: 43
PM  Website

Re: smiddyOS image for your pleasure...

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


Attachments:
Attachment Icon smiddyostest.jpg, Size: 150,550 bytes, Downloads: 427

---
Axel DominatoR ^^^ HC

Offline

 

#23 2005-06-15 02:28:16

smiddy
Active member
Registered: 2005-02-15
Posts: 183
PM

Re: smiddyOS image for your pleasure...

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. wink 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?


- [color=red]s[/color][color=blue]m[/color][color=red]i[/color][color=blue]d[/color][color=red]d[/color][color=blue]y[/color]

Offline

 

#24 2005-06-15 11:51:09

DennisCGc
Member
From: Zoetermeer, The Netherlands
Registered: 2005-03-01
Posts: 49
PM  Website

Re: smiddyOS image for your pleasure...

Hi,

It hangs at GDT loaded...

(I even tested it with a new disk..)
Any things you're doing at that point ?

DennisCGc.

Offline

 

#25 2005-06-15 13:32:46

smiddy
Active member
Registered: 2005-02-15
Posts: 183
PM

Re: smiddyOS image for your pleasure...

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! cool


- [color=red]s[/color][color=blue]m[/color][color=red]i[/color][color=blue]d[/color][color=red]d[/color][color=blue]y[/color]

Offline

 

#26 2005-06-15 15:24:23

DennisCGc
Member
From: Zoetermeer, The Netherlands
Registered: 2005-03-01
Posts: 49
PM  Website

Re: smiddyOS image for your pleasure...

Hi,

Yup, it detected the CPU well  (showed 486 DX-2 wink )

You're welcome. (And I don't drink any beer tongue)

DennisCGc.

Offline

 

#27 2005-06-15 18:34:21

smiddy
Active member
Registered: 2005-02-15
Posts: 183
PM

Re: smiddyOS image for your pleasure...

Thanks!

I figured, but wanted to offer whatever you do drink...as a token of my appreciation. smile


- [color=red]s[/color][color=blue]m[/color][color=red]i[/color][color=blue]d[/color][color=red]d[/color][color=blue]y[/color]

Offline

 

#28 2005-06-15 18:59:09

DennisCGc
Member
From: Zoetermeer, The Netherlands
Registered: 2005-03-01
Posts: 49
PM  Website

Re: smiddyOS image for your pleasure...

Hehe smile

Well, let's see tongue Coca Cola (coke IIRC), neah, kidding. (I like Coca Cola though)
I was justing giving a test report... wink

DennisCGc.

Offline

 

#29 2005-06-16 03:18:09

smiddy
Active member
Registered: 2005-02-15
Posts: 183
PM

Re: smiddyOS image for your pleasure...

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:

ASM code:

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  eaxcr0      ;Switch to pmode
    inc  ax
    mov  cr0eax
    
;       sti
;       mov si,CR0Message
;       call PrintString16
;       cli
    
    mov  bx28h        ; flat_data ;Our only pmode selector
    mov  dsbx        ;Install 4Gb limits (warning)
    mov  esbx
    dec  ax            ;Switch back to real mode
    mov  cr0eax

;       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:

ASM code:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; 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...


- [color=red]s[/color][color=blue]m[/color][color=red]i[/color][color=blue]d[/color][color=red]d[/color][color=blue]y[/color]

Offline

 

#30 2005-06-16 14:20:41

tomtobias
Member
Registered: 2005-06-15
Posts: 16
PM

Re: smiddyOS image for your pleasure...

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

 

#31 2005-06-16 17:51:56

bubach
Administrator
From: Trollhättan, Sweden
Registered: 2005-02-15
Posts: 367
PM  Website

Re: smiddyOS image for your pleasure...

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

 

#32 2005-06-16 18:46:48

smiddy
Active member
Registered: 2005-02-15
Posts: 183
PM

Re: smiddyOS image for your pleasure...

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:

Code:

                                                                                                       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:

Code:

   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 18:49:23)


- [color=red]s[/color][color=blue]m[/color][color=red]i[/color][color=blue]d[/color][color=red]d[/color][color=blue]y[/color]

Offline

 

#33 2005-06-16 21:47:30

smiddy
Active member
Registered: 2005-02-15
Posts: 183
PM

Re: smiddyOS image for your pleasure...

Hi bubach,

Here is the scroll up routine:

ASM code:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; To scroll up one row
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
ScrollUp:

    push esi

    movzx eaxbyte [NumberOfRows]
    movzx ebxbyte [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.


Attachments:
Attachment Icon txtdrvr.asm, Size: 21,114 bytes, Downloads: 790

- [color=red]s[/color][color=blue]m[/color][color=red]i[/color][color=blue]d[/color][color=red]d[/color][color=blue]y[/color]

Offline

 

#34 2005-06-17 14:02:30

tomtobias
Member
Registered: 2005-06-15
Posts: 16
PM

Re: smiddyOS image for your pleasure...

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

 

#35 2005-06-17 16:21:07

AxelDominatoR
Member
From: Reggio Calabria, Italy
Registered: 2005-03-07
Posts: 43
PM  Website

Re: smiddyOS image for your pleasure...

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 wink

Axel


---
Axel DominatoR ^^^ HC

Offline

 

#36 2005-06-17 19:01:01

Dex4u
Active member
Registered: 2005-02-19
Posts: 132
PM

Re: smiddyOS image for your pleasure...

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

 

#37 2005-06-17 21:14:49

tomtobias
Member
Registered: 2005-06-15
Posts: 16
PM

Re: smiddyOS image for your pleasure...

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

 

#38 2005-06-17 21:24:30

smiddy
Active member
Registered: 2005-02-15
Posts: 183
PM

Re: smiddyOS image for your pleasure...

WOW! I am so excited by these posts. I only wish I had time right now to address everything. wink

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...


- [color=red]s[/color][color=blue]m[/color][color=red]i[/color][color=blue]d[/color][color=red]d[/color][color=blue]y[/color]

Offline

 

#39 2005-06-17 21:42:00

tomtobias
Member
Registered: 2005-06-15
Posts: 16
PM

Re: smiddyOS image for your pleasure...

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

 

#40 2005-06-17 22:18:42

AxelDominatoR
Member
From: Reggio Calabria, Italy
Registered: 2005-03-07
Posts: 43
PM  Website

Re: smiddyOS image for your pleasure...

@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 smile


Attachments:
Attachment Icon bochstrouble.jpg, Size: 126,527 bytes, Downloads: 375

---
Axel DominatoR ^^^ HC

Offline

 

 

Board footer

Powered by PunBB
BOS homepage © Copyright 2005 Christoffer Bubach
Strict XHTML and valid CSS.