What does your OS look like? (Screen Shots..)
Re: What does your OS look like? (Screen Shots..)
Huh, thanks for reminding me that I could just attach the screenshots.
Got scroll/sliderbars working (there aren't embedded scrollbars in this OS so they're pretty much the same control), and yes those mouse settings actually take effect. Also some preliminar terminal program (for the sake of it), although you can't do anything right now anyway (got some early keyboard code in, gotta see if it works).
Got scroll/sliderbars working (there aren't embedded scrollbars in this OS so they're pretty much the same control), and yes those mouse settings actually take effect. Also some preliminar terminal program (for the sake of it), although you can't do anything right now anyway (got some early keyboard code in, gotta see if it works).
-
- Member
- Posts: 273
- Joined: Sun Oct 09, 2016 4:38 am
- Libera.chat IRC: NunoLava1998
Re: What does your OS look like? (Screen Shots..)
Beacuse i am still in the beginner stages and programmed my 7-line keyboard driver perfectly...
Developing TRIODIUM OS. Or call it Dixium if you want. It doesn't matter.
https://github.com/NunoLava1998/DixiumOS
https://github.com/NunoLava1998/DixiumOS
Re: What does your OS look like? (Screen Shots..)
Nice one, Sik!
Re: What does your OS look like? (Screen Shots..)
I'm pretty sure 99% of the users on this site have seen that exact screen. I know I have.NunoLava1998 wrote:Beacuse i am still in the beginner stages and programmed my 7-line keyboard driver perfectly...
That's essentially what happens when you pass a null to your Print method. That's the 16-bit real mode Interrupt Vector Table, and by default, it's located at address zero.
EDIT: Actually, it's not by default... it's actually hard coded, apparently.
Last edited by SpyderTL on Fri Dec 09, 2016 12:48 pm, edited 1 time in total.
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Re: What does your OS look like? (Screen Shots..)
Agreed.Lukand wrote:Nice one, Sik!
How much of those graphics resources did you create by hand? Is any of that provided by the system ROM?
Just curious.
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Re: What does your OS look like? (Screen Shots..)
There's no such thing as "system ROM", the console boots straight off cartridge. (OK, later models have TMSS, but it doesn't provide any functionality and it isn't everywhere anyway) So yeah, absolutely everything you see had to be provided by myself.
- jojo
- Member
- Posts: 138
- Joined: Mon Apr 18, 2016 9:50 am
- Libera.chat IRC: jojo
- Location: New York New York
Re: What does your OS look like? (Screen Shots..)
Sik, do you have a link to a good reference on particularly the Genesis/Master Drive graphics subsystem? I'm very curious about how it operates, and I might just go ahead and start screwing with MD development here.
Also: With the strange generally sprite-and-tile-centric graphics systems late 80s/early 90s consoles generally had, I'm curious what the general outline for your draw loop is like. Are you using sprites for most of the GUI elements or are you just doing the old-fashioned 'dump everything in the framebuffer' technique? (Now that I think of it, that second thing probably isn't even an option)
Also: With the strange generally sprite-and-tile-centric graphics systems late 80s/early 90s consoles generally had, I'm curious what the general outline for your draw loop is like. Are you using sprites for most of the GUI elements or are you just doing the old-fashioned 'dump everything in the framebuffer' technique? (Now that I think of it, that second thing probably isn't even an option)
Re: What does your OS look like? (Screen Shots..)
Eh, look up GenesisSoftwareManual.pdf. Yeah it has some errors, but a lot of the homebrew documentation has just as many errors too. Probably the biggest downside from that PDF is that for whatever reason they never explained how the joypad works o_O (thankfully that isn't hard to find)jojo wrote:Sik, do you have a link to a good reference on particularly the Genesis/Master Drive graphics subsystem? I'm very curious about how it operates, and I might just go ahead and start screwing with MD development here.
Quick summary though (far from complete):
- 64KB of video memory (holds tiles and most tables)
- 8×8 tiles (32 bytes each)
- 4 palettes of 15 colors each
- 2 scrolling tilemaps
- Up to 80 sprites (from 8×8 to 32×32)
Actually using the tilemaps for most of the GUI elements (although this means widgets are tile-aligned for the most part). The cursor is a sprite, as well as the marker thingy in scrollbars (and there will be a bunch of other stuff too). Some programs may need to add their own sprites too later.jojo wrote:Also: With the strange generally sprite-and-tile-centric graphics systems late 80s/early 90s consoles generally had, I'm curious what the general outline for your draw loop is like. Are you using sprites for most of the GUI elements or are you just doing the old-fashioned 'dump everything in the framebuffer' technique?
Nah, there's enough room for a fullscreen framebuffer (320 × 224 × ½B = 35KB, a bit over half the video memory), the problem is that it's horribly slow to do things that way =P (that it wouldn't be linear isn't helping, you must use tiles for this) See just about every 3D game on the system. Sega CD games (primarily Core's) have it easier since they can render using the add-on's own scaler, but they still won't reach full speed because there isn't enough bandwidth to transfer the full screen in one frame.jojo wrote:(Now that I think of it, that second thing probably isn't even an option)
- BrightLight
- Member
- Posts: 901
- Joined: Sat Dec 27, 2014 9:11 am
- Location: Maadi, Cairo, Egypt
- Contact:
Re: What does your OS look like? (Screen Shots..)
xOS can now load programs from disk.
hello.exe and draw.exe are two different programs, each in its own binary.
hello.exe and draw.exe are two different programs, each in its own binary.
You know your OS is advanced when you stop using the Intel programming guide as a reference.
Re: What does your OS look like? (Screen Shots..)
My OS is a pure sh*t compared to your one!
Developing U365.
Source:
only testing: http://gitlab.com/bps-projs/U365/tree/testing
OSDev newbies can copy any code from my repositories, just leave a notice that this code was written by U365 development team, not by you.
Source:
only testing: http://gitlab.com/bps-projs/U365/tree/testing
OSDev newbies can copy any code from my repositories, just leave a notice that this code was written by U365 development team, not by you.
- BrightLight
- Member
- Posts: 901
- Joined: Sat Dec 27, 2014 9:11 am
- Location: Maadi, Cairo, Egypt
- Contact:
Re: What does your OS look like? (Screen Shots..)
You can't say that just because my OS is good looking to the eye; most of the things under the hood are just satisfactory and not actually good.catnikita255 wrote:My OS is a pure sh*t compared to your one!
You know your OS is advanced when you stop using the Intel programming guide as a reference.
Re: What does your OS look like? (Screen Shots..)
I didn't said about visual look, I know that it's definitely can't be used to measure OS advancemend (bad, really bad sentence!). You can at least run programs and you don't have that terrible memory corruption bug that freaks me out everytime and stops me for making lots of things.
Developing U365.
Source:
only testing: http://gitlab.com/bps-projs/U365/tree/testing
OSDev newbies can copy any code from my repositories, just leave a notice that this code was written by U365 development team, not by you.
Source:
only testing: http://gitlab.com/bps-projs/U365/tree/testing
OSDev newbies can copy any code from my repositories, just leave a notice that this code was written by U365 development team, not by you.
Re: What does your OS look like? (Screen Shots..)
Python 3.6, with support for dynamic loading for C modules, is now a relatively stable addition to my OS. I've not yet fully integrated it into my automated toolchain installation, but it builds with very little patching.
(Note that the `math` and `json` modules load C dependencies. It's more obvious with some debugging enabled.)
Most of the standard library works, but there are some missing features like sockets.
My plan for Python is to write wrappers for my windowing libraries and write a UI toolkit and general applications in it. Despite its deficiencies in speed, Python has always been one of my favorite languages.
(Note that the `math` and `json` modules load C dependencies. It's more obvious with some debugging enabled.)
Most of the standard library works, but there are some missing features like sockets.
My plan for Python is to write wrappers for my windowing libraries and write a UI toolkit and general applications in it. Despite its deficiencies in speed, Python has always been one of my favorite languages.
Re: What does your OS look like? (Screen Shots..)
Klange, you are a master.
Developing U365.
Source:
only testing: http://gitlab.com/bps-projs/U365/tree/testing
OSDev newbies can copy any code from my repositories, just leave a notice that this code was written by U365 development team, not by you.
Source:
only testing: http://gitlab.com/bps-projs/U365/tree/testing
OSDev newbies can copy any code from my repositories, just leave a notice that this code was written by U365 development team, not by you.
Re: What does your OS look like? (Screen Shots..)
Basic OS Update 1.7.2:
+VGA driver
+Switched to 90x60 text mode
+Massive mega TTY update, everything has been rewritten from scratch, all new functions, everything is 100% new and more functional
+Blinking text mode cursor
+Text mode mouse (not speaking about the cursor) (early stages)
+Event logger, (currently RAM only, not hard drive integration, but that will be added as soon as possible)
+Console arguments, working echo implementation (high resolution mode only, at the moment)
+Started working on some driver abstractions
+Bug-fixes, all the things I forgot to mention
What do you guys think? Is is any good?
+VGA driver
+Switched to 90x60 text mode
+Massive mega TTY update, everything has been rewritten from scratch, all new functions, everything is 100% new and more functional
+Blinking text mode cursor
+Text mode mouse (not speaking about the cursor) (early stages)
+Event logger, (currently RAM only, not hard drive integration, but that will be added as soon as possible)
+Console arguments, working echo implementation (high resolution mode only, at the moment)
+Started working on some driver abstractions
+Bug-fixes, all the things I forgot to mention
What do you guys think? Is is any good?
- Attachments
-
- BasicOSUpdateTUI.png (6.77 KiB) Viewed 4031 times
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader