[MSX-C] Q&A official thread | MSX Resource Center (Page 13/68)

Paragon (1030)

10-09-2015, 09:02

Grauw wrote:

DarkSchneider wrote:

Think on a possible new multi-task OS.

Halt has no function in a multi-task OS, rather in the contrary it will waste precious CPU cycles doing absolutely nothing while it could be running some other task.

It has, multi-tasked = multiple threads. If your thread is using the CPU at full there is less for others. Take in mind that in a multi-task OS you run your program, and then the OS itself handles all the processes. So the halt doesn't stuck the whole OS.

Having a halt inside the while has only benefits, JIFFY can only change on an interrupt, so what is the problem of checking it only in that case?. If is not the interrupt you are waiting for (JIFFY hasn't changed), then return to the while and wait again for the next one.

Depending if you want a v-sync or dynamic-v-sync (not wait if dealyed from expectec), use better a while with OR operation as I exposed before, changing the first jiffy = 0 by jiffy_start = jiffy and use the substraction as condition. If you use only the jiffy reference just before the while, it will only sync at 60 fps, or what is the same, its only function is to wait for next VBLANK interrupt.

Par Grauw

Ascended (10821)

10-09-2015, 10:03

AxelStone wrote:

A question about JIFFY value. I suposse that it's a 16 bit value, so it's higher value is 65,535, maybe? If we don't reset JIFFY it's increased 60 times per second, 3600 times per minute. In about 18 minutes the counter will loop to 0, so the check while(JIFFY - lastJIFFY < 2) will never occur. Is that so?

Unless I’m mistaken, integers in C have the same overflow behaviour as assembly, so if you subtract a counter which goes from 0 to 255, e.g. lastJIFFY = 254 and JIFFY = 0, the result of JIFFY - lastJIFFY is 2. Same rules apply for 2’s complement (signed) integers.

DarkSchneider wrote:

It has, multi-tasked = multiple threads. If your thread is using the CPU at full there is less for others. Take in mind that in a multi-task OS you run your program, and then the OS itself handles all the processes. So the halt doesn't stuck the whole OS.

A halt will halt the CPU, so the CPU does nothing. If you want to do cooperative multitasking on a Z80, the process must yield back control to the system with a method call, not a halt. A halt will just waste cycles until the next interrupt (which presumably triggers a pre-emptive context switch). And you don’t need a special instruction for that, a simple while (true) loop will do it equally well.

DarkSchneider wrote:

Having a halt inside the while has only benefits, JIFFY can only change on an interrupt, so what is the problem of checking it only in that case?. If is not the interrupt you are waiting for (JIFFY hasn't changed), then return to the while and wait again for the next one.

Explain to me the benefits, because I don’t see any. The end result is the same. Using halt only complicates the way you achieve the goal, and the risk for synchronisation bugs is greater when you use halt as I’ve mentioned several times by now. So, why would you recommend people to use halt, in C no less (!), I can not comprehend.

Par DarkSchneider

Paragon (1030)

10-09-2015, 10:39

Grauw wrote:

DarkSchneider wrote:

It has, multi-tasked = multiple threads. If your thread is using the CPU at full there is less for others. Take in mind that in a multi-task OS you run your program, and then the OS itself handles all the processes. So the halt doesn't stuck the whole OS.

A halt will halt the CPU, so the CPU does nothing. If you want to do cooperative multitasking on a Z80, the process must yield back control to the system with a method call, not a halt. A halt will just waste cycles until the next interrupt (which presumably triggers a pre-emptive context switch). And you don’t need a special instruction for that, a simple while (true) loop will do it equally well.

The OS has its own handling. If a pure MS-DOS program makes a halt, when running on Windows environment it doesn't stuck the OS. And a pure MS-DOS program has no Windows calls. Remember that OS has its own mechanisms apart from the programs.

I see the benefit of using hardware features to get a more efficient result.
Think about enabling the turbo of CPU (there is no reason to do not), your game can slow down sometimes in the Z80, so with turbo you can remove those momentary slow downs. For those momentary slow downs, probably with only a Z80 a bit faster could be enough, why have the R800 (or Z80 with turbo) working at full all the time?, I see unnecessary.
Suppose now that a new MSX model, using one-chip solutions, is made. It has a CPU running at 50-100MHz. Why using it at full for an almost Z80 speed code?.
From a multi-task view, think you are not using only much CPU resources, also saturating the RAM bus.
Seen from another POV, has no disadvantage. Take only the CPU you need, and use the own CPU checks mechanisms. If you are waiting for an interrupt, wait for it, when it arrives, is the one you are waiting for?, no, then wait again, yes, then go ahead. In other environments we use what we have, like waits, locks, listeners, etc. So where is the problem of using what we have available?. Use only what you need.
Also, where the complication is to put a halt inside the while?, I don't understand, what can break?.

Par hit9918

Prophet (2932)

10-09-2015, 17:30

to get multitasking, you need to give away the cpu by calling an OS function.
the halt instruction is YOUR code continuing to use the cpu.
maybe the confusion is that halt() does look like calling an OS function.
but it doesn't, it is just a C wrapper around the halt instruction.

Par hit9918

Prophet (2932)

10-09-2015, 17:51

Quote:

The OS has its own handling. If a pure MS-DOS program makes a halt, when running on Windows environment it doesn't stuck the OS.

What happens is that the 386 got added transistors to make the HALT instruction do a trap to kernel.
This was needed because of the false use of the halt instruction
So, the instruction is still named "halt", but it does something else, it does a call to the OS.

Par AxelStone

Prophet (3199)

10-09-2015, 22:21

After a long discussion about use / not use of halt, here goes another question

Question: In the copy operations as cpyv2v I'm not sure to understand how logical operations works. We have the following table:

   Table 4.6  List of logical operations

-------------------------------------------------------------------------
| Logical name |					|L03 L02 L01 L00|
|--------------+----------------------------------------+---------------|
|	       |					|		|
|     IMP      | DC=SC					| 0   0   0   0 |
|	       |					|		|
|     AND      | DC=SCxDC				| 0   0   0   1 |
|	       |					|		|
|     OR       | DC=SC+DC				| 0   0   1   0 |
|	       |    __	     __ 			|		|
|     EOR      | DC=SCxDC+SCxDC 			| 0   0   1   1 |
|	       |    __					|		|
|     NOT      | DC=SC					| 0   1   0   0 |
|	       |					|		|
|     ----     |					| 0   1   0   1 |
|	       |					|		|
|     ----     |					| 0   1   1   0 |
|	       |					|		|
|     ----     |					| 0   1   1   1 |
|	       |					|		|
|--------------+----------------------------------------+---------------|
|	       |					|		|
|     TIMP     | if SC=0 then DC=DC else DC=SC		| 1   0   0   0 |
|	       |					|		|
|     TAND     | if SC=0 then DC=DC else DC=SCxDC	| 1   0   0   1 |
|	       |					|		|
|     TOR      | if SC=0 then DC=DC else DC=SC+DC	| 1   0   1   0 |
|	       |			    __	     __ |		|
|     TEOR     | if SC=0 then DC=DC else DC=SCxDC+SCxDC | 1   0   1   1 |
|	       |			    __		|		|
|     TNOT     | if SC=0 then DC=DC else DC=SC		| 1   1   0   0 |
|	       |					|		|
|     ----     |					| 1   1   0   1 |
|	       |					|		|
|     ----     |					| 1   1   1   0 |
|	       |					|		|
|     ----     |					| 1   1   1   1 |
|	       |					|		|
-------------------------------------------------------------------------

* SC  = Source colour code
* DC  = Destination colour code
* EOR = Exclusive OR

It's suppossed that operation 0 should not read alpha color, right? This is, I have a palette were the transparent color (Color 0 of the palette) is a colour used in background so I can draw background tiles with logical operation=0 (no alpha color). However the tiles that uses this color appears with alpha.

Why this happens? Thanks.

Par DarkSchneider

Paragon (1030)

11-09-2015, 09:40

Not http://www.read.seas.harvard.edu/~kohler/class/04f-aos/ref/i386/HLT.htm

They can't know the OOSS that will be released unless they ask a fortune teller ;) to do such things.

The OS really creates and environment and execute operations by its own behaviour, most simply bypass and others handles by its own mechanisms. i.e. Windows 64-bit has not 16-bit environment, it doesn't execute 16-bit programs.

A processor never can call to OS unless is specific for that OS, if not, what happens with the other OS?. It is in the other way, the OS translates programs to use the CPU resources in its own way.

About alpha in copy, how logop parameter is passed?, as 0 or as (TINY)0.

Par Grauw

Ascended (10821)

11-09-2015, 10:07

@DarkSchneider So why bring up halt in relation to multitasking? It has nothing to do with it, just wastes cycles until the time slice it got from the pre-emptive multitasking OS runs out and the timer interrupt occurs. It is no different from a loop: jp loop.

@AxelStone The T versions of the operators ignore color 0 while copying to permit transparent areas, the others copy every pixel. Typically you’d use IMP and TIMP, there isn’t much use for the others. If the copy is not fully opaque in your case, it seems you’re not setting the correct logical operation...

By the way, cpyv2v uses the slow LMMM VDP command, when you do not care about transparency and odd x coordinates, HMMM is much faster.

Par anonymous

incognito ergo sum (116)

11-09-2015, 11:01

AxelStone wrote:

After a long discussion about use / not use of halt, here goes another question

Question: In the copy operations as cpyv2v I'm not sure to understand how logical operations works. We have the following table:
[...]

It's suppossed that operation 0 should not read alpha color, right? This is, I have a palette were the transparent color (Color 0 of the palette) is a colour used in background so I can draw background tiles with logical operation=0 (no alpha color). However the tiles that uses this color appears with alpha.

Why this happens? Thanks.

What part is not working for you? I did a quick test (just used the function we wrote to read .GE5 files) and it's working fine for me:

Par anonymous

incognito ergo sum (116)

11-09-2015, 11:03

In the screenshot above, the pattern in the top of the screen is copied several times to the middle of the screen:

- The copies on the left are copied using logical operation 0 (IMP).
- The copies on the right are copied using logical operation 8 (TIMP).