The Third 512-byte OS Contest!
- Troy Martin
- Member
- Posts: 1686
- Joined: Fri Apr 18, 2008 4:40 pm
- Location: Langley, Vancouver, BC, Canada
- Contact:
Re: The Third 512-byte OS Contest!
ndisasm -b16 boot.bin | more
- Troy Martin
- Member
- Posts: 1686
- Joined: Fri Apr 18, 2008 4:40 pm
- Location: Langley, Vancouver, BC, Canada
- Contact:
Re: The Third 512-byte OS Contest!
Disassembles boot.bin as if it were 16-bit code and pumps it to more, paging it one screen at a time. You should be able to figure that out.
Re: The Third 512-byte OS Contest!
Is this for NASM or ? (I am used to the FASM win32 assembler)
My hero, is Mel.
- Troy Martin
- Member
- Posts: 1686
- Joined: Fri Apr 18, 2008 4:40 pm
- Location: Langley, Vancouver, BC, Canada
- Contact:
Re: The Third 512-byte OS Contest!
NASM, but the rules are generally the same for any disassembler.
Re: The Third 512-byte OS Contest!
Not much of a compo, if you do not announce the winner.
- Troy Martin
- Member
- Posts: 1686
- Joined: Fri Apr 18, 2008 4:40 pm
- Location: Langley, Vancouver, BC, Canada
- Contact:
Re: The Third 512-byte OS Contest!
Ego much?
Congratz, Dex, here are your twenty invisible tokens!
Congratz, Dex, here are your twenty invisible tokens!
Re: The Third 512-byte OS Contest!
Do these count as tokens?
* * * * * * * * * * * * * * * * * * * *
any way congrats Dex.
* * * * * * * * * * * * * * * * * * * *
any way congrats Dex.
My hero, is Mel.
Re: The Third 512-byte OS Contest!
Thanks, i am supprized to win as that PC speaker demo looked good, it must be all the free code i post
Re: The Third 512-byte OS Contest!
Well, the speaker demo didn't have its source included, So there was no posible way for me to learn from it... And the fact is, you made the worlds smallest GUI.
My hero, is Mel.
- Masterkiller
- Member
- Posts: 153
- Joined: Sat May 05, 2007 6:20 pm
Re: The Third 512-byte OS Contest!
Actually I dissassebled it and I noticed a call to INT 0x1A (I have never looked this interrupt number before). I found that the BIOS supports timers there (commonly based on the PIT) and I used it in my OS boot menu The speaker demo has 1 vote from me.Coddy wrote:Well, the speaker demo didn't have its source included, So there was no posible way for me to learn from it...
Lol, I have never expect even one vote to my program if I follow the rule to not vote for myself... And I have two votes, I am progressing in the os development (happy)
ALCA OS: Project temporarity suspended!
Current state: real-mode kernel-FS reader...
Current state: real-mode kernel-FS reader...
Re: The Third 512-byte OS Contest!
well, when I disassembled it I got a total of 33 lines of ??? so I am guessing that meens it does not know
My hero, is Mel.
Re: The Third 512-byte OS Contest!
Congratulations, Dex! Impressive demo you had there, and I guess the best "OS" won. (But to be honest, I thought I had a pretty good chance at first. Did I actually forget to include the source!? )
I was away last week for 5 days sailing around the Gulf Islands in British Columbia (Canada) as part of a school-sponsored trip, so when I got back the voting had JUST finished and so t'was too late to right the wrongs and possibly win me a compo. But on the other hand, I guess the rickroll would've been too obvious if you read through the source beforehand.
Here you guys go:
There's actually no real compression involved, though the way I stored the song is I guess... creative? The first four bits of a note would represent the actual tone (an index to a bunch of frequencies) AS WELL as the 16-bit VGA color - 2 of the note AND the position it occupied on the screen (efficient, no?). The last four bits was used in a tick-checking loop to give the note the appropriate length. A 0 would indicate text to print, followed by a number which would help indicate the memory offset to start printing on, and then followed by the text (terminated by another 0). Two 0s would denote the end of the song, causing the entire song to loop again.
I was away last week for 5 days sailing around the Gulf Islands in British Columbia (Canada) as part of a school-sponsored trip, so when I got back the voting had JUST finished and so t'was too late to right the wrongs and possibly win me a compo. But on the other hand, I guess the rickroll would've been too obvious if you read through the source beforehand.
Here you guys go:
There's actually no real compression involved, though the way I stored the song is I guess... creative? The first four bits of a note would represent the actual tone (an index to a bunch of frequencies) AS WELL as the 16-bit VGA color - 2 of the note AND the position it occupied on the screen (efficient, no?). The last four bits was used in a tick-checking loop to give the note the appropriate length. A 0 would indicate text to print, followed by a number which would help indicate the memory offset to start printing on, and then followed by the text (terminated by another 0). Two 0s would denote the end of the song, causing the entire song to loop again.
"Sufficiently advanced stupidity is indistinguishable from malice."