Re: Maybe we should stop "Paging Beth Stone" already...


Richard Cooper wrote:

| > Unfortunately this PIT frequency+divider wont allow exact settings
| > for even time values. I found just 50mS(20Hz) to be the only exact.
| > Perhaps this were once the base to define the 1.193180 Mhz/65535,
| > seems not just defined to avoid 50 and 60 Hz interfierence as this
| > two beccome very close [ie: 5d37h 50.00125718 Hz].
|
| I think they just used the 3.579545 Mhz crystal that's used for color in
| televisions, probably because it was the cheapest one available, being in
| such wide use and all. Divide that by 3 and you get 1.193182. They were
| probably aiming for 1Mhz, and decided that was close enough.
|
| > If an INT or IRQ results in a PL-change it will swap ss:esp anyway
| > without swapping all contents of the TSS.
|
| Oh yeah... That'd be what those stack fields in the TSS are for...
|
| > As my all code run PL0, I may have not fully understood what I read so
| > far about IRQ ? ;)
|
| Well, I haven't even written code to do this stuff, so you probably know
| more about it than I do.



| > Non-hardware drivers ... OK.
| > For me non-hardware devices belong to software and don't need 'drivers'.

| So what do you think of a keyboard port driver, and then a seperate user
| space keyboard driver which deals with decoding scan codes and such?

[KEYbd]
My OS already decodes everything when a key is hit and put this info
into a global structure and into a buffer if configured that way.

KEY_struct: ;8 byte
00 dw internal flags, counter for pending bytes to complete
02 dw scan-code
04 db ASCII-code
from user selectable layout conversion table)
non ASCII-keys also produce a value here >7fh
and it holds Zero while the scan is busy/not completed
05 db Flags: Shift-status, make/break, CRSR-block
06 db Flags: LED-status, INS, prtscrn, sysreq, pause, cntl-break
07 db HEX/NUM value and the valid flags for ASCII, HEX-NUM and NUMblock.

I can have several boxes (I wont use the term 'windows') on the screen,
where one sees the keyboard like a German layout, the other an English one,
while a third may see a game console or I may even add the opportunity
for a user defined conversion table (but here I'd reserve a few keys).

Free definable key-masks can be linked to either OS-jobs or to a
user defined key-event-handler in addition.

What else would be needed ?



| Basically what I want in my OS is to be able to combine everything into a
| working system from user space.

OS post-development in user-space ? :)
Much better is an OS who already does what and how we want it.

| So if the actual hardware drivers aren't in user space,
| that's really not a big deal since the hardware drivers are
| just the ends of the chains.

I see, this is possible, but the hardware parts at least have to
run in PL0.

| So in my OS, you'd have a keyboard port, mouse port, and video card driver
| which just did the actual hardware interfacing, and nothing else.

Now here (in the hardware section) while in PL0 can be already done
a lot of useful things, saving the user from libraries and detours.

| Then in userspace I'd have a keyboard driver,...
| and a mouse driver, ..
| Then I'd have a program that I would call the multiplexer,
| which connects to the keyboard and mouse drivers,
| and the video card driver.

?? I don't need a multiplexer to display the mouse,
the IRQ12 (or IRQ3,4,10,11) does this on its own if enabled.
If task changes then just the mouse's image may be updated, and if there
is only one mouse (I can have up to three), then only one global structure
(x,y,dx,dy,r/m/l-button and some more) is needed.
So the active thread can read it anytime without a task switch.

| It then makes available a service to which other programs can connect to,
| just like they would connect to the real keyboard/mouse/video, and it
| does the multitasking switching between them,
| so when you type a key combination on the keyboard to switch to a
| different task, the multiplexer starts paying attention to a different
| task, and it either ignores or buffers the output of the other tasks.

| Then if, for example, you're making a dedicated system, you can leave out
| that multiplexer and connect the programs to the real keyboard/mouse/video
| drivers, so that task switching is no longer available.

I wouldn't direct connect the user to the hardware section, just making
the IRQ-result structs global accessible for all user threads may do it.



| What made me think of this is the complexities in getting something like
| PPP over TCP going, and how you basically have to write a program just to
| do it. In this OS, every program would do everything via IPC, so if you
| wanted PPP over TCP, then instead of telling the PPP program to connect to
| [serial][0][115200_8N1], you just tell it to connect to
| [network][tcp][216.49.81.19:4197], and it's quite happy to do so since
| it's the same IPC interface it would have seen anywhere else.

I'm not familiar with abstract layers, for me every piece of hardware
has to be treated as it needs to and all hardware drivers are connected
via (user shared if granted) structures (including buffer pointers)
to communicate with any software.

| ...[sound][pcm][44100_16_stereo]...
| --output mp3 [network][tcp][219.17.39.42:3294]" ...
| and [network][tcp][219.17.39.42:3294] works just like
| [filesystem][create][/home/idiot/sound.mp3].

| Similarly, [filesystem] is an IPC service implemented by a user-space
| process, which connects to other things like [fat32][ide0_1] and
| [ext2fs][ide0_2_1], mounting them into a single filesystem unix style. Of
| course, if you don't want a common filesystem like in unix, you can tell
| your programs to save to [fat32][ide0_1][create][\My Documents\file.txt]
| and that will work the same as anything else. If you don't like the long
| drive name, then when you load the fat32 driver, you can tell it to export
| it's [ide0_1] filesystem as simply [drive_c], in which case programs then
| save to [drive_c][create][\My Documents\file.txt] instead.

| Finally, that fat32 driver connects to [ide0_1] which is a PC hard disk
| partitioning driver, which connects to [ide0] which is the actual IDE
| driver that talks to the hardware. And that IDE driver also, of course,
| offers an IPC service called [ide1].

| Now of course there's all kinds of TSS switches all over that plan, but
| like I said, I'd rather have an 800Mhz PC with the features I want than a
| 1Ghz PC without them.

Yes, the above I'd assume to be 'user-system' stuff,
except I have no idea what this IPC actually does :)

My kernal routines know only how to read/write sectors and parts of it,
so the filesystem (also core routines) can be made flexible.
I once added a FAT-import/export module to my KESYS-FS, but it also
runs in kernel-mode.
I see it dangerous to let a user play with FileSystem-internals...

| > So you optionally allow I/O-access in user space. Good, but wouldn't this
| > somehow be against your strict protection demands ?

| There would be a permissions structure in place so that only programs with
| the proper permissions were allowed to get I/O access.

Ok, the 'super-admin'

| The driver would have to have I/O access regardless of wether it's a
| kernel process or a user-space process. I just don't want to give up
| protection that I don't have to give up, like isolated address spaces.
| So as long as drivers can have isolated address spaces and still function,
| then I want them to have them.

Perhaps this is why Intel implemented PL0,1,2 and PL3 ?


| > I also tend to have columns for
| > |address |opcode |source .... |comments
| > as this makes life easy for plain text storage/print and it allow
| > masking off unwanted fields without much software overhead.
|
| I don't usually find the column type comments very useful. People tend to
| write things like this:
|
| mov ecx, 12 ; put 12 in ecx
| mov edi, [dest] ; load [dest] into edi
| mov esi, [src] ; load [src] into esi
| rep movsb ; move 12 bytes

This may sometimes very helpful for beginners ... :)

| Now I can read assembly, so I don't need comments like that. So when I
| write comments, I assume that people can read assembly just fine, and
| instead try to help them out by documenting what the code does in
| general. Like this:
|
| # ==================================================
| section .text
[...]
|
| # ==================================================

|... You can just read the comments in that code and get an idea what
| it does in about 15 seconds.

Yes, just fine to read. Even I would check for performance ;)

| Now that's the best example of commenting in my code I could find. To be
| fair, here's the worst:
|
| # This is complicated as hell.
| # It's also spagetti code.
| # That tends to happen when you flowchart.
| # I'll include a picture of the flowchart.
| # I'll not include comments since it's easier to look at the chart.
|
| Now I have no idea what I did with that flow chart. Even so, it's got
| good function names and it makes use of if/else/endif macros, so it's not
| too hard to follow, it's just a bit confusing when you come across a
| section of code that looks like this:
|
| if al, ":", z
| call end_piece
| call new_piece
| call add_to_piece
| call end_piece
| call process_part
| jmp next_part
| endif
|
| And you wonder what the deal is with all of those function calls.

:)
My personal coding style would be even more worse to read for others:

cmp al,3a |jnz endif
call 00403314 |call 00403100 |call 0040....
....
endif: ;this hex-numbers 'are' talking names to me (only).

| I figured it out once it occured to me that the character in AL isn't part
| of any piece yet, so what it's doing is ending the last piece and then
| creating a piece that only contains the colon. So I guess even that
| wasn't too bad. But let me go pull a random piece of code out of Menuet:
|
| drawwindow_III:
|
| pusha
|
| mov edi,edx ; RECTANGLE
| mov eax,[edi+0]
| shl eax,16
| mov ax,[edi+0]
| add ax,[edi+8]
| mov ebx,[edi+4]
| shl ebx,16
| mov bx,[edi+4]
| add bx,[edi+12]
| mov esi,[edi+24]
| shr esi,1
| and esi,0x007f7f7f
| push esi
| call draw_rectangle
| mov ecx,3
| dw3l:
| add eax,1*65536-1
| add ebx,1*65536-1
| mov esi,[edi+24]
| call draw_rectangle
| dec ecx
| jnz dw3l
| pop esi
| add eax,1*65536-1
| add ebx,1*65536-1
| call draw_rectangle

| It almost might as well be a disassembler output. We've got two
| meaningful function names, one TLA-style label, and a bunch of unnamed
| constants and anonymous register variables, and we know it has something
| to do with a rectangle.

>From too many disassembling (graphic card BIOS and other HW specific),
I'm very familiar with uncommented ASM.

First I would strip off all the nonsense:
add eax,1*65536-1
would become:
dec eax
and then I'd look at 'draw_rectangle' if there isn't an easier
way to create a pseudo3D-shadowed-doubleline-rectangle, and the
weird 16 bit x,y-parameters would let me think about a change also.

| Now I'm sure I'd have a better idea what it did if I read over the entire
| source, but it's all written like that, so it would be a real headache.

Yes, the latter needs some clean syntax conversion first.

| One thing I have noticed that other people do and I don't, is that they'll
| sometimes put the main function at the bottom of the file, then the
| functions it calls above it, and the functions they call above them. So
| if you do read the entire file, you just read it from top to bottom, and
| every function or variable that's used you've already read. I tend to do
| the opposite, so to get the same effect you'd have to start reading from
| the bottom of my source code, which is a little more difficult.

May be just a matter of taste, I usually type my data-fields (in RosAsm)
near or even within the code where it belongs to. The compiler will take
it apart anyway. The order of functions is often just given by their age,
even I try to keep related things together.

[my debug view...]
| Now that's nice. I like how it has the [esi] and [edi] type fields and
| the disassembly there at the top.

I had to modify it lately to check for valid segments and memory ranges.
As my disassembler is just 20 KB 'large' I added it to the OS-core,
and it also helps to easy skip over DIV/0 instructions and other
fault-type exceptions if desired.

__
wolfgang


.