Graphic modes

Página 5/20
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10

Por Prodatron

Paragon (1797)

Imagen del Prodatron

31-10-2005, 01:21

But what happens, if the GUI library is drawing something for a process, and suddenly the process is beeing interrupted (because of the multitasking) and another process receives the CPU time and also wants to draw something? Then it calles the GUI library, too, but the library is already in a "froozen" state because of the other process. Or do semaphores protect the library from "double calls"? Or do you add the instruction for the library to a buffer? (but that would sound nearly like the message system)
Btw, the overhead generated by messages is very low compared to the time, which is needed, if something is plotted to the screen, so it has no effect in SymbOS (on CPC).
The GUI is not a part of the kernel. The kernel is only responsible for multitasking/process handling, memory management/ram banking and the process messages, nothing else. The GUI is a service of the desktop manager process (one of many processes), which application may use, if they want. Other applications may use nothing, and other ones may use the text shell:
http://www.symbos.de/files/symshell1.gif
(this text shell can run in full screen mode or in the desktop - then it uses the desktop manager again, but the application inside the shell doesn't know about that, it just knows about STDIN and STDOUT).

Cheers,
Prodatron

Por flyguille

Prophet (3028)

Imagen del flyguille

31-10-2005, 01:30

But what happens, if the GUI library is drawing something for a process, and suddenly the process is beeing interrupted (because of the multitasking) and another process receives the CPU time and also wants to draw something? Then it calles the GUI library, too, but the library is already in a "froozen" state because of the other process. Or do semaphores protect the library from "double calls"? Or do you add the instruction for the library to a buffer? (but that would sound nearly like the message system)
Btw, the overhead generated by messages is very low compared to the time, which is needed, if something is plotted to the screen, so it has no effect in SymbOS (on CPC).
The GUI is not a part of the kernel. The kernel is only responsible for multitasking/process handling, memory management/ram banking and the process messages, nothing else. The GUI is a service of the desktop manager process (one of many processes), which application may use, if they want. Other applications may use nothing, and other ones may use the text shell:
http://www.symbos.de/files/symshell1.gif
(this text shell can run in full screen mode or in the desktop - then it uses the desktop manager again, but the application inside the shell doesn't know about that, it just knows about STDIN and STDOUT).

Cheers,
Prodatron

what happens? nothing... it works.

why?... because the libraries by its nature are multisession.... why? because they don't share data segments & any of the three stacks between threads...

if the library needs a common data for to organize tasks it is a internal work of them.-

Por Prodatron

Paragon (1797)

Imagen del Prodatron

31-10-2005, 01:47

Ok, that sounds good.

I just wonder how such cases are managed:
- Process #1 draws a sprite inside window #1, that has focus. During the drawing process it will be interrupted.
- Process #2 gets the CPU time and puts window #2 to focus. This window will overlap window#1 partially.
- Process #1 can continue, but a part of the sprite is now overlaped by window #2. Does the interrupted sprite drawing routine now knows, that suddenly an other object is overlaping it?

If yes, I am not sure, if all the overhead to handle this would be less than the SymbOS message overhead. In SymbOS every resource (desktop, disk drive etc.) is managed by only one process, so there are no problems with competing tasks, as the responsible task is working all request one after the other, which makes everything quite easy.

Cheers,
Prodatron

Por flyguille

Prophet (3028)

Imagen del flyguille

31-10-2005, 01:56

speed executing itself isn't a problem...
The Lag between the event generated (a click or a key press) and the appl. reacting is a problem.

if it depends of a message passed from a thread to other.... that means that can be some times a cycle of delay... needed to that the thread of the GUI is executed and the thread of the appl is executed then.

I not knows about symbian but in MNBIOS one cycle is 1 seg... being executed high priority threads first then the appls threads careless of the modality of being executed. (rythmic mode or continous mode or freetime mode)... but that is another agent.

in MSX the only one interrupt by sure is 50hz... and the best way to handle user events is on the interrupt... with the procedures hunged on it, (keyb mouse etc.), the best and direct way it from that place to fill a event's buffer of the target object.

and then let to the appl. to check for events just reading a property.

Por flyguille

Prophet (3028)

Imagen del flyguille

31-10-2005, 02:10

Ok, that sounds good.

I just wonder how such cases are managed:
- Process #1 draws a sprite inside window #1, that has focus. During the drawing process it will be interrupted.
- Process #2 gets the CPU time and puts window #2 to focus. This window will overlap window#1 partially.
- Process #1 can continue, but a part of the sprite is now overlaped by window #2. Does the interrupted sprite drawing routine now knows, that suddenly an other object is overlaping it?

If yes, I am not sure, if all the overhead to handle this would be less than the SymbOS message overhead. In SymbOS every resource (desktop, disk drive etc.) is managed by only one process, so there are no problems with competing tasks, as the responsible task is working all request one after the other, which makes everything quite easy.

Cheers,
Prodatron

first, the MSX VDP doesn't helps about multitasks... it is the worst chip for that task....

why?.. it isn't just LDI.... LDIR to copy RAM to VRAM

any attempt to interrupt a vdp routine with another task that also accesses to the VDP will fuck the first vdp routine. that is for sure

for that exists DI / EI instructions on Z80.

but anyway that doesn't closes all the problem... because the VDP has internal cursors registers that can save a lot of Z80 time... like addressing one time and sending several bytes placing one after the other automatically.... that kind of work simply fuck up the multitasks....

so, in MNBIOS is a task of the kernel to make sure that you doesn't override the vdp work. How settling rules!.

first, in MSX sprites are entities handled by the VDP and you don't needs to draw it by hand.

now if you speak about drawing a picture box... well that is other thing....

rules:

all desktop appls. can't handled vdp itself, the same for libs. there is a LARGE set of vdp routines on kernel for that... for all likes.

Second, only appls with fullscreen properties that has the focus can do a use of vdp by itself including handling the interrupt.... but are forbidden to avoid that the interrupt executes the kernel interrupt handler.

about the problem of overlapping windows, there is a masking windows system. that is enabled only in those cases, because it overheads a lot and slowdown a lot the drawing... so, only drawing on a windows that is partially overlapped it is enabled.... if itsn't it saves a lot of tests.

Por Sonic_aka_T

Enlighted (4130)

Imagen del Sonic_aka_T

31-10-2005, 02:34

Hey Prodatron, great to have you on these forums! I took a look at SymbOS, and it looks very impressive. I saw you had a lot of stuff working already, and most routines appear to be fairly flexible, great to see! Well, to quicky answer a couple of questions you asked. If something is not entirely clear, feel free to ask. I'll start with just a rough outline though, so you get the main idea...

About the video mode:
Mode 5 seems to be perfect for porting SymbOS in it's current state. Also the VRAM is not larger than 32K, which means, that I have 32K vram, 16K screen driver (ok, it's shorter) and 16K application data within the 64K address space.
Mode 6 is very interesting because of the high amount of colours, but it will be a little bit harder to implement.
What is absolutely cool are the blitter features, as I could use them directly in the screen driver (it is already designed for supporting such features!).
Well, I don't know a whole lot about the CPC (other than that it has a motorola CPU Tongue) but from what little I understood, it doesn't really have a VDP or VRAM. This will probably be one of the bigger differences with the MSX system. The MSX2 has a dedicated VDP, with dedicated memory. This has a few advantages (more free RAM and parallel processing) and disadvantages (speed, in this case). The speed problem is not too big though, since the speed which SymbOS currently has should certainly be possible. Commands can also be a nice extra, if you're executing a fairly 'big' command, the Z80 can go do something useful (usually this is calculating the next command) while it's executing. It also means you don't have to worry about address space. You'll have the full 64kB at your disposal. The downside is in your case, that you would have to rewrite many of your routines. The MSX2 VDP uses X,Y coordinates for commands, addresses are not often used.

Since the MSX2 has 128kB VRAM, you could use the surplus VRAM to store graphics. Probably you would want to use this area for a copy of the desktop picture, and perhaps a few icons. You could also store the main system font here, so you could easily print text by copying characters using a logical move. You could draw windows by using FILL commands and LINEs. This is all reasonably fast, and is probably easies than doing all this in RAM using the Z80. It is however not as fast. Completely restoring the desktop picture using a copy command for instance, would take about 6,5 interrupts at 50Hz, more than a 10th of a second. This means that in practice some planning is required when drawing to the screen, updating only those parts of the screen that actually need updating. All in all tho, with a little planning, it should be possible to everything the CPC version does.

Now I need to know exactly about the banking possibilities in the MSX? How can I switch ram pages and from where to where can I switch them? Is it possible to replace any 16K page in the 64K address space with any 16K page of the whole memory or are there any restrictions?

Banking works like a charm on MSX. You out the bank number you want to activate, to the corresponding page. How's that for ease of use? Tongue There are no limitations, other than that the range from $C000-$FFFF usually contains the stack, and always contains the slot select register. There's really no need to change this page though, since it's more trouble than it's worth, and there's still 3 pages to go mad with. Anyhow, to select a RAM bank at address-range $8000, you would simply do an OUT ($FE),A or similar. Changing slots is a bit more of a hassle, but there are ready-made routines for that, as far as I know.

Also what's about the interrupts? As far as I know MNBIOS is using a 50Hz interrupt, which is too slow in my opinion (current SymbOS on CPC does the task switching at 150Hz.

I think I already read it in this thread, but idd, sadly the MSX system usually only has the VDP interrupt to rely on. The VDP does an RST $38 when an interrupt is generated, usually this would be 60 times per second. If you wanted to double this, you could perhaps set a line interrupt somewhere in the middle of the screen, that would double it to 120Hz. I guess you could repeat that trick for multiples of 60Hz (or 50Hz).

Por flyguille

Prophet (3028)

Imagen del flyguille

31-10-2005, 02:50

about VDP

vdp problems...

vdp has two or three cursors regs....

you can set those... but not to READ those....

rule to set... in desktop mode (when is several appls using the vdp... AVOID to use the cursors regs), that means to set the vram addr in every access.... there isn't a shortcut that is SLOW idd.

about sharing the CO-VDP there is the WAIT signal so, there isn't a problem... but that put appls to wait or to do something else if they are well programmed (but is more complicated for the average programmer).

about using SPRITES in desktop appls... well, only one way i can thinks is to use a sprite agent that handles which sprites numbers are assigned to each appl... that mean to handle sprites likes being objects... and as there is a limit of 32 sprites... well just cry.... and care that there isn't more than 8 sprites in horizontal line because they dissapears from the screen. That is the reason that mnbios doesn't support a sprite agent like object by default... all the sprite functions on kernel are available for full screen appls.

about which bitmap is ok ... screen 5 is great... it is fast for redrawing because it uses 32KB VRAM... on other way screen 7 or 8 uses 64KB per page and you will see how slow it is just when scrolls a text window... check in MNBIOS's demo that i thinks is somewhere in the MRC for download...

check using the "screen" command to swhich between the different

SCREEN -m0 == MSXBASIC screen 5 (256x212x16)
SCREEN -m1 == MSXBASIC screen 6 (512x212x4)
SCREEN -m2 == MSXBASIC screen 7 (512x212x16)
SCREEN -m3 == MSXBASIC screen 8 (256x212x256)

Por Trebmint

Champion (294)

Imagen del Trebmint

31-10-2005, 09:51

The CPC is a z80 based system! which is why porting would be possible. It has no dedicated VRAM, and all processing of the screen is done via the main CPU, which is a memory mapped layout. If the VDP can effectively get on with a task while the CPU is doing something from the CPC point of view that is impossible, so it would be a major benefit.

Sprites, are in my opinion of limited or no use to an OS (Except perhaps as a mouse pointer). Yes in a Direct screen games mode they would be, but that isn't even in CPC symbos yet. How such a games mode could work as cross platform I'm not sure it could Sad

Whether this port happens is upto Prodatron as the coder, but from my point of view I will start to build the modes 5,6 and 7 into the IDE editor as I'm hopeful we will someday soon find the best OS on the CPC as a MSX program

Rob

Por Sonic_aka_T

Enlighted (4130)

Imagen del Sonic_aka_T

31-10-2005, 13:24

The CPC is a z80 based system! which is why porting would be possible. Hehe, I was trying to lighten the mood a little after all that, uhm, heavy reading material... Tongue

It has no dedicated VRAM, and all processing of the screen is done via the main CPU, which is a memory mapped layout. If the VDP can effectively get on with a task while the CPU is doing something from the CPC point of view that is impossible, so it would be a major benefit.Idd, it should be rather helpful to have a command engine for a windowing OS.

Sprites, are in my opinion of limited or no use to an OS (Except perhaps as a mouse pointer). Yes in a Direct screen games mode they would be, but that isn't even in CPC symbos yet. How such a games mode could work as cross platform I'm not sure it could SadWell, that's a choice Prodatron would have to make. Sprites can be great for stuff like mousepointers and perhaps some other things, but if you were to disable them altogether, your commands would be executed roughly 25-30% faster. Certainly something to keep in mind.

Whether this port happens is upto Prodatron as the coder, but from my point of view I will start to build the modes 5,6 and 7 into the IDE editor as I'm hopeful we will someday soon find the best OS on the CPC as a MSX programWell, I sure hope so. It looks like a great OS, and it would really be nice if it were to be ported to MSX. Try to convince Prodatron a little, will ya? Wink Tongue I'm looking forward to the next build of your editor then, let us know when you release it...

Por flyguille

Prophet (3028)

Imagen del flyguille

31-10-2005, 15:36

Well, I am happy that someelse is working in an OS. for msx. It is a hard and long task.

Well i will comments some problems to fix about GUI.

The use of the COPROCESSOR-VDP for drawing lines and filled box and to scrolls some textbox is the faster way on MSX. The alternative is dumping VRAM using the CPU time... the difference is a lot slower (very unconfortable). The big problem, is that this CO-VDP commands doesn't support a window mask, That means three ways:

1. Easy way, to do all dumping pixel per pixel using CPU. Before to set a pixel to check if it is in a uncover area. (that means 4 checks per window on the screen, for that you needs a caché table pre-formatted where is recorded all the coordinates of the upper-left and down-right corners) (pre-formatted because normally the windows properties only has upper-cornet coordinate and its size and on other hand those data is normally in other memory's pages (the ones that owns the object instances) ) so for save time the GUI needs a local table very fast to read and with both corner's coordinates of all object that reserve a space in the screen (excluding from that, objects that anyway are sticked on windows like buttons) ). So 4 checks per windows before to set ONE pixel.... Sad In a scroll of a average window's size that means 1.5 up to 3 seconds just for scroll text.

2. Hard way. To analize the uncover area of the window (its size and frame) and to divide the task of filling or scrolling between small squares to see if you can do those using CO-VDP's commands, by example one partial overlap needs 2 or 3 CO-VDP's command normaly, if there is other window also overlapping... maybe you need 3, 4 or 5... The problem is not to execute the covdp commands doing part of the task, the real problem is to make a smart and clever engine.

3. The screen's prebuffer on RAM method.... this is the faster way drawing on overlapped windows but also it is a waste of RAM, RAM that maybe isn't available unless you set too high the minimun RAM spec... Ofcourse this method of predraw all in RAM and then to refresh the screen in one task (or a part of the screen) doesn't save you of doing a smart engine like in the "way #2", because the alternative of the "way #1" is still too slow. The only one advantage is that this way allows to do a lot of things or to use a lot of tricks about drawing on RAM... using by example all the power of LDIR LDI, being possible to copy/past and to do effects in this way easily, than working directly with VRAM.

To pre-buffer you needs in the worst of the cases 64KB of RAM in a system where a lot of ppl has only 128KB of RAM (but never mind), most fanatic users has 256KB or more, and UZIX or MNBIOS are already setted to that quantity but by others reasons.

I thinks the best way to chose is to do a pre-buffer, but not for the screen, to do a pre-buffer per object, is the BEST WAY and the one that I will to adopt in MNBIOS's GUI. But also I will support objects without prebuffer because large objects will eats a lot of RAM in the appls's data pages, so to support also a descriptive way of drawing object also is good.

I hope that all this thinks from my side helps you with your system. Because the mine is very delayed but not dead.

Página 5/20
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10