-
September 24th, 2004, 07:15 PM
#11
I think so,
You would boot into a command line prompt.
You would have a command line interpreter (sort of runtime version of your CL).
You would have commands that you wanted
You would have any drivers needed (CD for example)
You would have any command utilities you needed (chkdsk, fdisk etc)
In other words, what you would have on a diagnostic/trouble shooting disk?
If you look at those links, you will see that most common boot disks are OS dependent. This is to keep them small and because they are for OS specific problems and tasks. On the other hand, the disks that come with hard drives (Caldera DOS for example) are not.
Cheers
-
September 24th, 2004, 07:23 PM
#12
Lol, I don't want to write some command line interpretenter that runs in dos or something.
The point is simply knowing how to write the most basic operating system.
My problem is simply not knowing how to get it to run make independantly.
I once found this proggie called 'Easy OS', it was simply a command interpretenter (not relying on any other os) written in assembly (obviously) and then it was written to floppy using some other program.
I feel like you are not understanding what I want to do...o_O.
The above sentences are produced by the propaganda and indoctrination of people manipulating my mind since 1987, hence, I cannot be held responsible for this post\'s content - me
www.elhalf.com
-
September 24th, 2004, 07:48 PM
#13
No, I am only using DOS as an example. It is part operating system and part command language, so is probably not a good example, but is the one most commonly associated with "boot disks"
Say you wrote your OS in assembly, you would need a runtime assembly command interpreter to get the commands to execute. In this case assembly is merely the language you chose to write your OS in.
Perhaps a better example would be the old floppy boot sector viruses? Boot from an infected floppy and the virus would run.
In your case all you want it to do is display a command prompt?
Something like that?
-
September 24th, 2004, 07:59 PM
#14
Yes, the virus example is good.
I firstly only want to display a simple string to make sure it actually works, then write a command interpretenter. But that's not the problem, I should technically be capable of writing a command interpretenter in assembly.
The above sentences are produced by the propaganda and indoctrination of people manipulating my mind since 1987, hence, I cannot be held responsible for this post\'s content - me
www.elhalf.com
-
September 24th, 2004, 08:50 PM
#15
You're a bit over my head here writing your own assembler, but from a working knowledge of 98 and dos I'll offer this - maybe it will help a bit.
When dos boots, it first looks for a file named 'command.com' - always. If it doesn't find it, it asks the user for it. I would suggest trying renaming your program 'command.com' on the floppy and see what good ol Dos spits back at you. Now, if you've written your own o/s, (unlike MS when they wrote win95/98/me and based it off of dos 6.0 and 6.2) this will (obviously) be different unless you've used Dos as a basis.
I wish you luck!
Even a broken watch is correct twice a day.
Which coder said that nobody could outcode Microsoft in their own OS? Write a bit and make a fortune!
-
September 25th, 2004, 12:43 PM
#16
That's what I did, rename it to command.com but it said it wasn't a command interpretenter.
You say
When dos boots, it first looks for a file named 'command.com' - always.
I know, but how does the computer know how to boot dos? (from a floppy that is).
Say you wrote your OS in assembly, you would need a runtime assembly command interpreter to get the commands to execute.
huh? The assembly is already assembled heh, to a binary file. /me is confused
The above sentences are produced by the propaganda and indoctrination of people manipulating my mind since 1987, hence, I cannot be held responsible for this post\'s content - me
www.elhalf.com
-
September 25th, 2004, 02:02 PM
#17
I know, but how does the computer know how to boot dos? (from a floppy that is).
Those particular instructions are burned into cmos - they read (in plain english)
You are a computer.
You have devices. Here are their locations and how to communicate with them but not interpret.
The instructions on how to interpret them are located somewhere on the device.
Boot from this device first, then try this secondary device in case your (l)user has them there.
Grab the instructions, no matter what they are, and load them into memory, and keep them there the entire time you're running.
Try to use the instructions to interpret the data on the drive. If they fail, let the user know what caused the failure and halt the system.
Hope this helps - missing command interpreter is a biggie. It's basically telling you that it can't find instructions for user commands contained within the file. To you it means that my suggestion didn't work and you might either A: try something else, or B: include command interpretations within your file.
Even a broken watch is correct twice a day.
Which coder said that nobody could outcode Microsoft in their own OS? Write a bit and make a fortune!
-
September 25th, 2004, 03:00 PM
#18
Those particular instructions are burned into cmos - they read (in plain english)
No, they aren't, the BIOS simply looks for a valid bootsector on the disk which is in the process of being booted. That bootsector contains the code needed to continue booting the operating system.
Anyway, that doesn't matter anymore as I have accomplished my purpose, I have written a bootsector and raw written it to a floppy.
Code:
[BITS 16]
[ORG 0]
jmp start
msg db 'Booting a shitty program$'
start:
mov ax,0x7c0
mov ds,ax
mov si, msg
lodsb
mov ah,0eh ; output character on screen function
mov bx,0007 ; bl value = attribute (back/foreground colour), not sure what bh does though...lol
int 10h ;BIOS interrupt
ret
times 510-($-$$) db 0 ;we need to fill so the binary image will be 512 bytes
;$ = start of instruction
;$$ = start of program
dw 0xAA55 ;fills last 2 bytes with 0xAA55 which makes this a valid bootsector
;(the BIOS checks whether it ends with 0xAA55)
How come it only displays a 'B' instead of the entire string I want to print?
The above sentences are produced by the propaganda and indoctrination of people manipulating my mind since 1987, hence, I cannot be held responsible for this post\'s content - me
www.elhalf.com
-
September 25th, 2004, 05:06 PM
#19
Obviously I was being stupid again, it requires looping which we can accomplish:
Code:
[BITS 16]
[ORG 0]
;16-bit real mode
jmp start
msg db 'Booting a shitty program',13,10,0
displaymsg:
lodsb ; load si string into something else
or al, al
jz return
mov ah,0eh ; output character on screen function
mov bx,0007h ; bl value = attribute (back/foreground colour), not sure what bh does though...lol
int 10h ; call BIOS
jmp displaymsg
return:
ret
start:
mov ax,0x7c0
mov ds,ax
mov si,msg ; display message
call displaymsg
times 510-($-$$) db 0 ;we need to fill so the binary image will be 512 bytes
;$ = start of instruction
;$$ = start of program
dw 0xAA55 ;fills last 2 bytes with 0xAA55 which makes this a valid bootsector
;(the BIOS checks whether it ends with 0xAA55)
/me wonders why the string is displayed 9 times????
The above sentences are produced by the propaganda and indoctrination of people manipulating my mind since 1987, hence, I cannot be held responsible for this post\'s content - me
www.elhalf.com
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
|