Announcement

**Lance Edmonds** · 14 Aug 2000, 01:22 AM

To be honest I have no idea... I'm an "applications programmer" by trade, so I rarely ever have to deal with super-accurate or hardware dependent timing.

This whole topic is likely to be well researched by many of the "game programmers" sites that abound on the Internet, and I would suggest that that would be a good place to start looking for information.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Paul Dixon** · 14 Aug 2000, 02:43 AM

Randal,
<< I tried to use the PB WAIT cmd with port &H40, but using mtimer to measure results did not work well.>>

Just a few thoughts, but doesn't MTIMER use the same timer chip that you are WAITing for and doesn't
port &h40 only become valid for 1 or 2 reads following the write to the control word? WAIT will do repeated
reads of this timer waiting for it to match the set conditions, probably getting the low timer byte on one
read and the high byte on the next but of which timer? MTIMER may have selected another one of the chip's
timers. Which byte (high or low) will the WAIT instruction terminate on? (it's the first one which matches
which may not be the one you want!) The timer is probably running in the wrong mode so may increment twice
as fast as you think it is (it is often run in mode 3 instead of mode 2). Don't use WAIT on such a chip.

<<Will it work for machine independant delays?>>

It can't because MTIMER tells you how long a delay was, it doesn't cause a delay itself. I'm sure
there's a program called MDELAY somewhere in this website that will give you an accurate, predetermined
delay, if you can't find it I can post it here.

Paul.

**Randal Milota** · 14 Aug 2000, 07:41 PM

Paul,

The PB manual says the WAIT statement: waits until a specific bit combination
is present on a specified port. Using mtimer to MEASURE the wait should not interfere
with the timer counting down to a specific state, which the WAIT is looking for.

However, you have brought up many of the questions I had in mind when I posted The WAIT thread. i.e. which timer?, which byte?, what resolution?,etc..

My hope is that someone from POWERBASIC, maybe even Bob Zale, would let us all know
more about this (potentially) very useful command.

From the PB Manual, it looks to be for somewhat long term indeterminate events.
As I mentioned,I have seen it used to write to the screen during the vert. retrace,
to avoid flicker, but this is only about a 70hz usage.

I searched this site for mdelay, then an altavista search on the web. The hits were for CD players, linux kernels,
and csound software synthesizer stuff. (Quite interesting to me, in a past life I built an analog synth (during hi school, in the 70's))
There was no source to be found, and it seemed to be for millisecond delays. One thread led to udelay, which i thought might
be microseconds, but again, no source. So, please do post the code you mentioned. Thank you.

P.S. Am I the only one who finds it hard to know when to put a CR when posting to this forum? Any suggestions?

------------------

[This message has been edited by Randal Milota (edited August 14, 2000).]

**Lance Edmonds** · 14 Aug 2000, 10:07 PM

You should not need to use CR's except at the end of paragraphs... the only time the text does not wrap to the window exception is if wide [ CODE ] [ /CODE ] UUB codes are used in a post within the same thread - the UUB software will set the wrap width to approximately match the widest message body.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Paul Dixon** · 15 Aug 2000, 03:07 AM

Randal,
The wait statement IS well documented...but there's not much to say about it because it doesn't do a lot!

I'll post mdelay in the source code forum but I'm sure it's already on this site somewhere.

<<P.S. Am I the only one who finds it hard to know when to put a CR when posting to this forum? Any suggestions? >>

No. The forum formatting is terrible. I've just realised what's happening. The entire thread is formatted into a single table which will usually adjust its width to the width of the screen and each message will then wrap within its own cell of the table if you leave out the <CR>s. But, if someone posts a preformatted block of text (I assume this is what the "[ code ] " tag mentioned elsewhere is for) then the font size is set to size 3 (large) and the automatic wrap is ignored for the duration of the prefomatted text.

This causes the column in the table to be given a huge width in order to fit the pre-formatted text and all other posts in the thread then wrap into the HUGE cell that results because the table will adjust to keep all cells in the column the same width. In effect, these other messages don't wrap at all.

So, in the 1st page of the "8243(4) timer interrupts" thread, the first message was OK although it included unnecessary line breaks. The second message forced a large, fixed pitch font and preformatted text to give a HUGE cell width which then set the column width for all other messages in the thread to be equally huge. All other messages were then formatted to fit the "current" table column width which requires us all to do the horizontal scrolling to read all messages.

The soloution is probably to give any message with preformatted text its own table to live in. That way all other messages will adjust to match the screen, and only those which need the formatting to be preserved will need horizontal scrolling. No doubt the soloution will also increase the size of the download of each thread by even more, they're already too big (aproximately twice as big as the contributions by members). PB could also reduce the size of the pre-formatted font from 3.

Paul.

------------------

**Randal Milota** · 15 Aug 2000, 04:47 AM

Paul,

I hope they're listening, seems like some good ideas,esp. removing the size 3 font.
More for you on the 8254 thread.

Randal

------------------

**Tom Hanlin** · 15 Aug 2000, 08:18 AM

WAIT presumably uses the assembly language instruction by the same name, so granularity and speed are completely CPU-based.

I'll see if it's practical to tweak the forum table handling. Thanks for the idea.

If the font size looks large to you, you're probably using Internet Explorer. If we reduce the size one iota, it turns into "fine print" under Netscape. So, there's not much we can do about that, as far as I know.

------------------
Tom Hanlin
PowerBASIC Staff

**Paul Dixon** · 15 Aug 2000, 09:50 AM

Tom,
I just tried my suggestion for formatting these messages and it appears to work. At the end of each row of the table if you insert the following:

</TD></TR></TBODY></TABLE>
<TABLE border=0 cellPadding=4 cellSpacing=1 width="95%">
<TBODY>

..just before the <TR> tag for the next message. This closes the previous table and begins a new one with the same parameters. Then only the messages which are forced to be wide by preformatted text will appear wide and all of the others will wrap to fit the screen size.

It may need a little tweaking, the left hand column (containing the poster's name) is set to a different width in WIDE and wrapped messages. Otherwise it appears to work in both Netscape and IE.

While on the subject of formatting web pages..
You do realise that the PB web pages are HUGE for the content they contain? I just noticed that the HTML is sent as 80 character lines with 6 spaces at the front. These spaces are all filtered out by the browser so why send them? They add 8% to the size of the message. Removing them would cut storage and download time by 8%. Not a lot, but it's a start!

<<WAIT presumably uses the assembly language instruction by the same name>>

I hope not! The assembly instruction waits for a co-processor to finish it's job. The BASIC instruction waits for a certain combination of bits to be present on an I/O port. I haven't checked but I suspect WAIT 1,2,3 will compile into half a dozen lines of assembler. Granularity and speed will depend on both the CPU speed and the port being accessed. In this case the port is the timer chip which is on the very slow ISA bus and will take 1-1.5us to return a value when read. A fast PCI port may return its value in <100ns. A fast CPU will add another 100ns(?) to these times.

Paul.

**Tom Hanlin** · 15 Aug 2000, 11:25 AM

'k, thanks.

We didn't design the forum software, of course. The size of the HTML code is the least of the UBB quirks that need working on, but I'll look into it when I get the chance. Thanks for the info.

You're right about WAIT, dunno what I was thinking of. Z80 code? <sigh>...

------------------
Tom Hanlin
PowerBASIC Staff

**Randal Milota** · 15 Aug 2000, 03:57 PM

Paul,

<I suspect that wait 1,2,3 will compile to half a dozen ASM lines>

How would you check this? In PB35, the single line program WAIT 1,2,3
compiles to 13k, and a hex editor shows nothing obvious (to me, anyway)

------------------

**Paul Dixon** · 16 Aug 2000, 03:07 AM

Randal,
Your code compiles to 13k because the 13k includes the PowerBASIC code to interface your code to DOS.

<<How would you check this?>>

Place a label at the start of the code statement you wish to check out:

Within the code, print out the code segment and code offset of that label in HEX format.

Open a new DOS shell (it's in the FILE menu of the PB IDE).

Type DEBUG to start the DOS debugger

Type u 1234:5678 where 1234 is the code segment given above and 5678 is the code offset given above.

Look at the screen to see the actual code produced by the PB compiler.

Type q to quit the debugger

Type EXIT to exit the new DOS shell and return to the IDE.

Doing the above with WAIT 1,2,3 produces the following output from the debugger:

Code:

REM this is the code I used in PB3.5
?hex$(codeseg(xxx))
?hex$(codeptr(xxx))
end

xxx:
wait 1,2,3  :rem This is the instruction I want to check out
!nop

Running the above program produced the following output:

Code:

7511
13a

I then opened a new DOS shell and typed as below to get the information:

Code:

C:\PD\BASIC>debug
-u 7511:13a
7511:013A B80100        MOV     AX,0001      <-- this is the 1
7511:013D 8BD0          MOV     DX,AX
7511:013F B80200        MOV     AX,0002      <-- this is the 2
7511:0142 8BC8          MOV     CX,AX
7511:0144 B80300        MOV     AX,0003      <-- this is the 3
7511:0147 8BD8          MOV     BX,AX
7511:0149 EC            IN      AL,DX        <-- this gets the data from the port pointed to by DX i.e.port 1
7511:014A 30D8          XOR     AL,BL        <-- this XORs it with 3
7511:014C 20C8          AND     AL,CL        <-- this ANDs it with 2
7511:014E 74F9          JZ      0149         <-- this loop back to the IN AL,DX if the conditions were not set
7511:0150 90            NOP                  <-- this is the next instruction in my program after WAIT
7511:0151 FF1ECC06      CALL    FAR [06CC]
7511:0155 FF1EB803      CALL    FAR [03B8]
7511:0159 0000          ADD     [BX+SI],AL
-

You can see that WAIT 1,2,3 compiles to 10 machine instructions. I'm not sure why the BX,CX and DX aren't loaded directly instead of beig loaded via AX as this would save 3 instructions.

Paul.

**Randal Milota** · 17 Aug 2000, 11:19 PM

Paul,

This I understand. Thank you

Randal

------------------

Announcement

Wait Statement Usage in PB35

Wait Statement Usage in PB35

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment