Aprom 100212: now stable, with fasm and 3D

[Artlav]

Hi again, continuing from http://forum.osdev.org/viewtopic.php?f=2&t=20761

I've been developing an OS project for quite some time now, and hope to get some feedback again.
You can get the images here:
http://orbides.1gb.ru/aprom_100205.zip
(latest: http://orbides.1gb.ru/aprom_100212.zip , info in post 15)
Containing a floppy and bootable CD images.

In this version, i decided to test the "usability"&etc on a non-trivial application, specifically one, that should render a 3D teapot with some lights and effects, and a few working buttons.
What it should look like is on the screenshot.
It should start into GUI automatically after GRUB, buttons (color rectangles) should toggle various modes, and it should either work entirely or not work at all, anything in between is bad.

It should work, albeit slowly, in qemu, but i'm more interested if it works on any real machine out there, so that kind of feedback is welcome.

Screenshot:

[midir]

Artlav, I tested your OS on all the virtual and real machines I had to hand.

First in Virtual PC 2004, about half a second after the teapot appeared it bluescreened -- not your OS, but my real, host, Windows 2003 OS. I have no idea how you managed that but we can blame it on Microsoft.

Next, Bochs: It got as far as setting the screen resolution to 800x600, but it was black. Nothing else appeared. The last message printed to the Bochs console was "all run".

VMware server: I got this message: http://img218.imageshack.us/img218/2204/vmware.png

Sun VirtualBox: Success! It worked (slowly), but with a couple of graphics glitches: The right-most column of the grey bar across the top was black (not filled in), and along the bottom of the screen, up as far as the bottom of the saucer, was black.

Real machine; Toshiba laptop w/ Intel Centrino 2.13 GHz: Worked almost perfectly. Here's a picture (on a CRT so I could get a less blurry picture): http://img22.imageshack.us/img22/1073/pict0028co.jpg
It worked except for the black bar at the bottom of the screen and the blue one above. When the cursor should have appeared in the black bar area, it appeared intead in the blue bar, offset about a centimetre to the right. The frame rate was good, about 15 fps.

Real machine; AMD Sempron @ 1.75 GHz, ASUS A7S8X-MX motherboard: Got this message: http://img195.imageshack.us/img195/6384/pict0031k.jpg

I was going to test another, very old machine but my floppy drive seems to have packed up (?) (again?) so I couldn't load it.

Couple of general comments though: I thought the bracketed letters (L) (W) (T) were things I could press with the keyboard. If they were meant to be, they didn't work. Would have been nice to be able to control the teapot motion too, even if it was just a demo, but it didn't seem to be possible.

[Cjreek]

Hi,

I tested your demo with qemu and it worked fine. Quite slow, but it worked. Didn't try it with a real machine.

[Artlav]

Update: http://orbides.1gb.ru/aprom_100206.zip
-Fixed keyboard
-Translated labels
-Added some more apps to autostart (buttons left of app name in top-left corner)
-3D demo speed could change
-Teapot can be rotated with mouse motion and right button
-Might not start on the first try

VMware server: I got this message: http://img218.imageshack.us/img218/2204/vmware.png
Real machine; AMD Sempron @ 1.75 GHz, ASUS A7S8X-MX motherboard: Got this message: http://img195.imageshack.us/img195/6384/pict0031k.jpg

It's a prompt to select video mode, since default was not found.
In the second case, have you tried typing in one of the mode numbers?

Couple of general comments though: I thought the bracketed letters (L) (W) (T) were things I could press with the keyboard. If they were meant to be, they didn't work. Would have been nice to be able to control the teapot motion too, even if it was just a demo, but it didn't seem to be possible.

Keyboard fixed, rotation with mouse ability added.
Also, thanks for testing.

[midir]

It's a prompt to select video mode, since default was not found.

Oh! I thought it was just an error or status message. Sorry!

-Might not start on the first try

Yeah, it starts correctly less than half of the time. You see the cursor and taskbar but the background is black and it's all frozen.

I tried again in VMware (the one with no mode numbers listed). I tried typing some stuff but it just printed this and then stopped:
vbe_cur_mod.winsize=00000000
vbe_cur_mod.segmentA=00000000
vbe_cur_mod.granularity=00000000
vbe_cur_mod.bank_size=00000000

Sun VirtualBox: Doesn't start most of the time. Teapot still working and controllable when it does start but clicking to *any* of the other tabs makes it freeze.

Laptop: When it does start it works. Teapot is working and controllable (still some screen corruption). TestWhatever page: clickable thing works; "Red Green Blue" in corressponding colours, brown diagonal line just below that, and grey box with white outline over on the right. Sine wave: OK, some screen corruption around bottom and right. Xcommander freezes on some directory changes.

Desktop machine: Had the same problem with only working half the time. Highest video mode it would work in was 640x350 but the frame rate was very good and smooth. No screen corruption at all. Teapot, sine wave, test pages, all working ok. XCommander freezes on some directory changes.

[Artlav]

Update: http://orbides.1gb.ru/aprom_100207.zip
-Fixed filesystem for good
-Improved stability
-minimal autostart
-both gui and console modes included
-More items in test program

The main point here is stability. It should be stable now, no more starting every odd time, no more crashes on directory reads.
I removed all the stuff from gui autorun and left only XC there, from which you can run any other program (select with arrow keys, enter, if not obvious).

On boot it will prompt to go either in console or gui mode.
Console mode is somewhat boring, but should work nicely. You should be able to get from console to gui by using "/bin/run/1/gui & /bin/run/1/xcmd" command.
In gui mode you can switch tasks by caps lock or by mouse clicks on task bar.

-test: There should be all kinds of windows and gui elements, expected to work as self-described.
-sprite: Draws a mandelbrot set where mouse is
-sinw: Sine wave graph
-drheap: Memory usage info
-zgl_demo: 3D teapot
-xcmd: file manager
Running gui or init from XC is a sure suicide.

As before, tests on real machines are welcome.

Yeah, it starts correctly less than half of the time. You see the cursor and taskbar but the background is black and it's all frozen.
...
Xcommander freezes on some directory changes.

Fixed and fixed, i hope.

[midir]

Hi again Artlav.

The intermittant starting is properly fixed, but something you enabled has broken things differently. On my laptop GRUB prints the module loading messages, then it gets as far as changing the VGA font, but the green "Mounting root" never appears, and it just sits spinning the CPU.

On my desktop it gets as far as "Mounting root" but just sits there, with the floppy drive light stuck on (even though it was booted from the floppy image in the bootable CD).

I tried it again in VirtualBox, and it seemed to all work perfectly as described. I tested all the GUI stuff, dragging windows, the fire simulation, and so on ("typable text" not finished I assume -- has a caret but can't be edited or selected). I tested the other programs (sprite, sinw, drheap, zgl_demo, xmcd) too, and the only issue there is that the sprite stuff does not undraw itself -- it leaves old copies of the sprite behind.

I wasn't sure what all the console commands were supposed to do so I wasn't sure if they all worked. "mt" just prints an infinite number of A's and B's and X's and dashes, but the rest seemed to be sane.

Some other things you're probably aware of, but anyway:
-- Keyboard handling is weak. Layout at fixed at US (at least in the version you sent me). I have a UK keyboard -- I'd be happy to test the key map if you programmed in a command to change to a UK layout. Caps/Num lock don't have any effect. No ctrl-keys & accented letters.

-- Console's handling of some input is unhelpful: prints out tab, Esc, F-keys as little graphics; Page Up prints an 'I'. Up arrow to recall the previous command line does work, but although it adds it to the text already on the command line instead of replacing, you can only backspace through the newest added characters. Try it to see what I mean.

-- Console should have an error for invalid commands!

-- GUI needs Z-order & keyboard focus handling (I'm sure you know this perfectly well -- it just needs to be over-stated because it's important if you want a good GUI!)

-- The file system on the floppy image seems to be corrupt. If you open it in WinImage the directory structure and the dates/times on the files are missing. I don't think that's why it's not starting on my PCs because I looked at the older floppy image versions and they're the same. GRUB doesn't seem to mind.

I don't mean to nitpick -- just trying to be a thorough tester!

[Artlav]

Update: http://orbides.1gb.ru/aprom_100208.zip
-Removed buggy floppy driver
-Fixed most of console input
-Cleaned and re-organized the shell
-Tab auto-completion
-Some gui cleanup, fixed input here and there
-Few more demos

...but something you enabled has broken things differently...
...just sits there, with the floppy drive light stuck on...

That's the floppy driver - it's very sluggish on real machines, and takes minutes to read a few sectors.
Turned it off.

"typable text" not finished I assume

Should be now, except for copy&paste.

"mt" just prints an infinite number of A's and B's

Mutex test. Was working since long ago.

Keyboard handling is weak. Layout at fixed at US (at least in the version you sent me). I have a UK keyboard -- I'd be happy to test the key map if you programmed in a command to change to a UK layout. Caps/Num lock don't have any effect. No ctrl-keys & accented letters.

Um, you lost me here. I thought UK layout was the same qwerty? Can't quite google the difference.
Caps lock is an aux switch, num lock well forgotten until now.
"accented" letters?

The file system on the floppy image seems to be corrupt. If you open it in WinImage the directory structure and the dates/times on the files are missing. I don't think that's why it's not starting on my PCs because I looked at the older floppy image versions and they're the same. GRUB doesn't seem to mind.

Interesting. The image is generated from a directory by my program, which does not care about putting dates&times in. The result works anywhere i tried it, winimage is the first that failed.

I don't mean to nitpick -- just trying to be a thorough tester!

You won't hear me complaining!

[AndrewAPrice]

Nice screenshots.

However in VirtualBox GUI mode is VERY slow (I was moving the cursor around and counted 9 seconds between frames). That made it basically unusable - even after I lined up the cursor over the labels I binaries I clicked as much as I can and nothing happened.

[Artlav]

However in VirtualBox GUI mode is VERY slow (I was moving the cursor around and counted 9 seconds between frames). That made it basically unusable - even after I lined up the cursor over the labels I binaries I clicked as much as I can and nothing happened.

Hm, it does crawl in VirtualBox.
Weird, even in Bochs the full emulator it runs at a few FPS.
Clicking on files in xcmd would do nothing, only keyboard is supported there.

[midir]

However in VirtualBox GUI mode is VERY slow (I was moving the cursor around and counted 9 seconds between frames).

It's a few fps for me, though slower in the teapot test. Of course, it's much faster and smoother running natively.

Update: http://orbides.1gb.ru/aprom_100208.zip
-Removed buggy floppy driver
-Fixed most of console input
-Cleaned and re-organized the shell
-Tab auto-completion
-Some gui cleanup, fixed input here and there
-Few more demos

It now boots and works on both my real machines, including the new gears demo. Congrats!

A few hardware-independent comments though:
-- you should separate the drawing of the cursor from the drawing of the rest of the screen, so the GUI is still responsive even when the rest of the screen is slow to draw
-- if you drag a window to the left-most pixel of the screen, it gets drawn all scattered horizontally (try it to see what I mean)
-- there are occasional hangs in GUI mode, that are more frequent if you try running lots of programs together. They don't seem to happen always the same way. One thing that goes odd consistently: try running "test", then exit it, then run another program, like "sinw", and it will get confused and make space on the taskbar but not provide the button to click.

Um, you lost me here. I thought UK layout was the same qwerty? Can't quite google the difference.

The symbols are slightly different. Compare
UK: http://www.saitek.com/images/300dpi/PK2 ... _black.jpg
US: http://closedstacks.files.wordpress.com ... yboard.jpg
On the UK layout @ and " reversed. The # and ~ are moved to their own additional key, which takes the same scancode (0x2b) as the \| key on US keyboards, while the actual UK \| key has a completely different scancode (0x56). Then the backticks key (to the left of 1) has ¬ and ¦ symbols on its Shift and AltGr/Ctrl+Alt states, and a pound sign (£) is on the 3's Shift state. Then there are some extra symbols on the AltGr/Ctrl+Alt states: a euro sign (€) on the 4, and acute accents on the vowels, so Ctrl+Alt+E = é (and Ctrl+Alt+Shift+E = É) and so on.
See: http://en.wikipedia.org/wiki/British_an ... _keyboards

EDIT: The relationship between the | (vertical bar/pipe) and ¦ (broken vertical bar) symbols is a bit odd. In Windows, you get the | by pressing Shift+\ and the ¦ with AltGr+`, but I've seen some UK keyboards (like the one in the picture above) that label them the opposite way.

[Artlav]

Update: http://orbides.1gb.ru/aprom_100210.zip
-Added bin to running from shell (# hello = # /bin/hello)
-GUI mouse disconnected from drawing loop
-GUI windows z-ordering
-Better keyboard handling
-Keymaps, switch with Win or Properties keys
-Alt Gr a little implemented
-Fixed windows and edges
-Text editor sample

In the test page there is a text editor. It should be good enough to edit a text file with relative comfort. No save button, since floppy driver is still sour.

With the stability hopefully there, what i wonder is - what to make of it all?
Any ideas/suggestions on which way to develop this "OS" further?
There is still some space on the floppy, but it's likely run out soon, so ATAPI drivers at least. All kinds of drivers and libs in the plans, for sure.
But, what about the big picture?

-- you should separate the drawing of the cursor from the drawing of the rest of the screen, so the GUI is still responsive even when the rest of the screen is slow to draw
-- if you drag a window to the left-most pixel of the screen, it gets drawn all scattered horizontally (try it to see what I mean)
-- there are occasional hangs in GUI mode, that are more frequent if you try running lots of programs together. They don't seem to happen always the same way. One thing that goes odd consistently: try running "test", then exit it, then run another program, like "sinw", and it will get confused and make space on the taskbar but not provide the button to click.

Fixed, fixed and maybe fixed.

The symbols are slightly different. Compare

Ok, that was informative enough. I've wired the layout switch to buttons between alt and ctrl (win and properties?), and did my best to make the UK layout.
Alt Gr is used, but the use is limited - there are no pound/euro signs or accented letters in the current font.
But other buttons should work as expected.

[midir]

-Added bin to running from shell (# hello = # /bin/hello)
-GUI mouse disconnected from drawing loop
-GUI windows z-ordering
-Better keyboard handling
-Keymaps, switch with Win or Properties keys
-Alt Gr a little implemented
-Fixed windows and edges
-Text editor sample

You code quickly!

Okay, there's a hardware-dependent problem with how the cursor gets drawn. It happens in VirtualBox but also on real hardware moreso. It's the same problem as the bar at the bottom of the screen that doesn't draw right, but now it affects the cursor at intermittant vertical positions all over the screen. It might draw in the wrong place, or in two places. If you move it to the bar at the bottom of the screen it doesn't get undrawn.

In the test page there is a text editor.

I've wired the layout switch to buttons between alt and ctrl (win and properties?), and did my best to make the UK layout.

Both features working fine! The text editor doesn't like tab characters yet though.

Fixed, fixed and maybe fixed.

Much better. I had about three dozen graphical programs running without problems, though if you start just 3 or 4 very quickly, it sometimes still hangs or goes odd. I hadn't noticed before, but the window glitch also happens if you move it to the top pixel of the screen -- probably exactly the same bug.

By the way, I forgot to mention before, my test machines your OS runs on both have USB mice. I don't know whether it's doing that via PS/2 emulation or true USB, but it's working nonetheless.

With the stability hopefully there, what i wonder is - what to make of it all?
Any ideas/suggestions on which way to develop this "OS" further?

Um, good question. I've never got nearly far enough in my own OS dabblings to be able to ask this question, never mind answer it. Well, if you're a science fiction fan, one thing that encouraged me to try OS dev was seeing the operating systems they use on computers on Stargate... mainly on Stargate Atlantis. They're definitely not Windows, and not Linux, and not anything else I've seen. Presumably it's some special OS developed by the US government. There are quite a lot of screenshots of it throughout the series, though stupidly, hardly any findable via Google Images. E.g., http://images2.wikia.nocookie.net/starg ... mputer.jpg and http://www.nelsonguirado.com/media/blog ... eeware.gif. One of the Atlantis characters was playing solitaire on one of their tablet computers once . There's also LCARS. So, I had some vague idea of making an OS that could be used on a starship, though perhaps I should have designed the starship itself first.

[ru2aqare]

Well, if you're a science fiction fan, one thing that encouraged me to try OS dev was seeing the operating systems they use on computers on Stargate... mainly on Stargate Atlantis. They're definitely not Windows, and not Linux, and not anything else I've seen. Presumably it's some special OS developed by the US government.

Not to spoil your fun, but its most likely some Flash animation running in fullscreen... Who would go the lengths to develop an OS when you can get by with an animation? Especially if the producers want cost-efficiency and rapid development. Sorry.

[Brynet-Inc]

I find it surprising you believe they developed an OS for use on television, often it's a non-interactive timed video loop or occasionally a custom program running full screen (..akin to a video game).

Some TV shows have used non-Windows operating systems, BeOS was shown on a workstation in Dollhouse.. although it was actually a fullscreen screenshot.

http://www.osnews.com/story/21254/BeOS_ ... _Dollhouse