Re: [fpc-pascal] VirtualTreeview Mac (Carbon)
Lazarus/LCL has added most of the needed functions, but it's not released yet. I am using the daily snapshot anyway. Are they in there? And if so, what is to do? Remove the dependencies on lclextensions from your port? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] VirtualTreeview Mac (Carbon)
CA Gorski escreveu: Lazarus/LCL has added most of the needed functions, but it's not released yet. I am using the daily snapshot anyway. Are they in there? Yes And if so, what is to do? Remove the dependencies on lclextensions from your port? Yes Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] power?
Am Sonntag, 30. Mai 2010 20:38 schrieb spir ☣: > On Sun, 30 May 2010 18:28:47 +0200 > > Reimar Grabowski wrote: > > On Sun, 30 May 2010 15:03:03 +0200 > > > > spir ☣ wrote: > > > PS: is there a round(fractional_size) function? that's the reason > > > why i needed power. > > > > http://community.freepascal.org:1/docs-html/rtl/system/round > > > > R. > > Sorry, maybe was not clear enough, I meant with a fractional_size > argument. see unit math .. "function RoundTo" (IIRC) regards Burkhard ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] PChar & AnsiString
Hello, The documentation in the ref manual about PChar may have i bit more details: http://www.freepascal.org/docs-html/ref/refsu13.html#x36-390003.2.7 Do the following statements hold true? * This type is mainly intended to interface with C code (or for low-level needs?). Else AnsiString should be prefered (even for low-level, since AnsiString is also referenced via pointer?). * Like C strings, and unlike AnsiString-s (even if the latter also are "pointed"), PChar strings cannot hold NULL characters (#0). I just checked this point. Also: * How is length computed (traversal?)? Can AnsiStrings be safely used as dynamic byte arrays? For instance to benefit of ref counting and copy_on_write (if any benefit). Or is it recommended to use Array of Byte? What is the actual benefit of copy-on-write? I ask because of the following reasoning: * If a string is just used at several places, for example in output or into bigger strings, then there is no reason reason to copy it into a new variable. * If a programmer explicitely assigns an existing string to a new variable, the intent is precisely copy-semantics, to make them independent for further changes. If there is no change, there is also no reason for such an assignment. As a consequence, s2:=s1 will nearly always be followed by modification of either string, which will result on copy anyway, according to copy-on-write semantics. So, the initial gain at assignment time is soon lost. While the cost I imagine in terms of type complexity remains (every builtin modification method must ensure copying; no user-defined modification method should be possible without using builtin ones -- else copy-on-write is lost and consequences undefined). What happens if a programmer indirectly modifies an AnsiString (via a pointer) which ref count is > 1: Var s1,s2 : AnsiString; pc: PChar; begin s1 := 'abcde' ; s2 := s1; pc := PChar(s1); pc[2] := 'X'; writeln(pc,' ',s1,' ',s2); // abXde abXde abXde end. There must be an error in my reasoning, else language designers would not bother with such complication. What do you think? Denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PChar & AnsiString
2010/6/1 spir ☣ : > * Like C strings, and unlike AnsiString-s (even if the latter also are > "pointed") Sure if you cast an AnsiString to a PChar it will only go until the first #0. You can't magically add capabilities to the PChar type. > * How is length computed (traversal?)? It isn't computed, it is stored as part of the string in memory. 4 bytes, so a string can go up to 2GB in size. -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PChar & AnsiString
On Tue, 1 Jun 2010, spir ☣ wrote: Hello, The documentation in the ref manual about PChar may have i bit more details: http://www.freepascal.org/docs-html/ref/refsu13.html#x36-390003.2.7 Do the following statements hold true? * This type is mainly intended to interface with C code (or for low-level needs?). Else AnsiString should be prefered (even for low-level, since AnsiString is also referenced via pointer?). PChar is for C code. * Like C strings, and unlike AnsiString-s (even if the latter also are "pointed"), PChar strings cannot hold NULL characters (#0). I just checked this point. Correct. Also: * How is length computed (traversal?)? Strlen traverses till the first null. Can AnsiStrings be safely used as dynamic byte arrays? For instance to benefit of ref counting and copy_on_write (if any benefit). Or is it recommended to use Array of Byte? You can use them. What is the actual benefit of copy-on-write? I ask because of the following reasoning: Copy on write is needed to preserve the Pascal nature of strings while keeping the benefits of reference counted strings. After A:='some string'; // Ref count is 1 B:=A; // Ref count is 2 B[1]:='S'; // Copy, and ref count of B is 1. the A[1]='s' should still hold true. * If a string is just used at several places, for example in output or into bigger strings, then there is no reason reason to copy it into a new variable. * If a programmer explicitely assigns an existing string to a new variable, the intent is precisely copy-semantics, to make them independent for further changes. If there is no change, there is also no reason for such an assignment. This is not correct. Many strings are simply referenced several times. As a consequence, s2:=s1 will nearly always be followed by modification of either string, which will result on copy anyway, according to copy-on-write semantics. So, the initial gain at assignment time is soon lost. While the cost I imagine in terms of type complexity remains (every builtin modification method must ensure copying; no user-defined modification method should be possible without using builtin ones -- else copy-on-write is lost and consequences undefined). What happens if a programmer indirectly modifies an AnsiString (via a pointer) which ref count is > 1: Var s1,s2 : AnsiString; pc: PChar; begin s1 := 'abcde' ; s2 := s1; pc := PChar(s1); pc[2] := 'X'; writeln(pc,' ',s1,' ',s2); // abXde abXde abXde end. There must be an error in my reasoning, else language designers would not bother with such complication. What do you think? If the programmer does this, it is his own fault; A pchar typecast should be considered read-only and valid only for the duration of the expression. It states as much in the docs. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] VirtualTreeview Mac (Carbon)
And if so, what is to do? Remove the dependencies on lclextensions from your port? Yes Ok, I will try... Meantime I tried to compile lclextensions against gtk2 but the compiler still uses includes from include/carbon sub-folder. Why? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PChar & AnsiString
On Tue, 1 Jun 2010 13:05:16 +0200 (CEST) Michael Van Canneyt wrote: [...] Thank you for all answers (all is now clear for me :-). > > * If a programmer explicitely assigns an existing string to a new variable, > > the intent is precisely copy-semantics, to make them independent for > > further changes. If there is no change, there is also no reason for such an > > assignment. > > This is not correct. Many strings are simply referenced several times. May I ask in which typical cases? (I can easily find examples of strings _used_ several times, eg concatenated into larger strings and/or output, but this does not make new references.) Can only think at the special case of loop variables: for i:=0 to persons.count do begin name := persons[i].name; -- do something with name w/o changing it -- end; I find this question (from a larger point of view than strings only) very interesting. Some newer languages, such as Clojure, introduce reference semantics while basically preserving basic value immutability: a different approach. (I do not mean one is better than the other; instead try to understand why either is prefered by some language designers.) Denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PChar & AnsiString
On 01 Jun 2010, at 14:28, spir ☣ wrote: On Tue, 1 Jun 2010 13:05:16 +0200 (CEST) Michael Van Canneyt wrote: This is not correct. Many strings are simply referenced several times. May I ask in which typical cases? The most common one is probably assigning a function result to a variable or field. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PChar & AnsiString
On 01/06/2010 11:23, spir ☣ wrote: What is the actual benefit of copy-on-write? I ask because of the following reasoning: * If a string is just used at several places, for example in output or into bigger strings, then there is no reason reason to copy it into a new variable. * If a programmer explicitely assigns an existing string to a new variable, the intent is precisely copy-semantics, to make them independent for further changes. If there is no change, there is also no reason for such an assignment. As a consequence, s2:=s1 will nearly always be followed by modification of either string, which will result on copy anyway, according to copy-on-write semantics. So, the initial gain at assignment time is soon lost. While the cost I imagine in terms of type complexity remains (every builtin modification method must ensure copying; no user-defined modification method should be possible without using builtin ones -- else copy-on-write is lost and consequences undefined). No, an assignment, or increase in ref count is not necessarily followed by a change: Procedure Foo(a:String); begin ... end; Procedure Bar; var s: string; begin s:= SomeString; Foo(s); end; Now a copy of s has to be given to Foo, because Foo *may* changes the string. But Foo may also *not* change the string => so leave it till later. Example 2: Procedure Bar; var a, b: string; begin a:= SomeString; b:=a; if SomeCondition then b:=b+"..."; if SomeOtherCondition then b:=b+"???"; end; So b may never be changed at all. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PChar & AnsiString
On Tue, 01 Jun 2010 15:00:47 +0100 Martin wrote: > On 01/06/2010 11:23, spir ☣ wrote: > > What is the actual benefit of copy-on-write? I ask because of the following > > reasoning: > > * If a string is just used at several places, for example in output or into > > bigger strings, then there is no reason reason to copy it into a new > > variable. > > * If a programmer explicitely assigns an existing string to a new variable, > > the intent is precisely copy-semantics, to make them independent for > > further changes. If there is no change, there is also no reason for such an > > assignment. [...] > No, an assignment, or increase in ref count is not necessarily followed > by a change: > > Procedure Foo(a:String); > begin ... end; > > Procedure Bar; > var s: string; > begin >s:= SomeString; >Foo(s); > end; > > Now a copy of s has to be given to Foo, because Foo *may* changes the > string. But Foo may also *not* change the string => so leave it till later. For me, parameter passing is just an implicit assignment "param:=s" (with the variant of var params). The same applies to return values when assigned back in calling code (*). I would have thus expected s the pointer to be passed. Just checked it is not the case. More secure, esp since legacy shortstrings do not behave that way. This example rather backs my pov, I guess, since here copy-on-write does not apply. But it certainly could, since its application should prevent bad surprises, no? (unexpected change of original variable) > Example 2: > > Procedure Bar; > var a, b: string; > begin >a:= SomeString; >b:=a; >if SomeCondition then > b:=b+"..."; >if SomeOtherCondition then > b:=b+"???"; > end; > > So b may never be changed at all. Sure, I did not mean this cannot happen. I rather spoke of the programmer's intent. My hypothesis is that it does not make sense to copy a string into another var if none will change. Your example is perfect :-) There are cases were this cannot be avoided. Still, is this worth the complication of copy-on-write. I also favor a super-simple and explicit coding style, which produces some more assignments, intermediate and not necessary, than clever coding with complex expressions. From this point of view, copy-on-write is an interesting scheme, in that it avoids useless copies (except for references), thus allowing such a coding style with minor penalty (ref copy only). But if the compiler is smart enough, such intermediate vars can probably be eliminated, no? Denis (*) And to some more constructs in other languages, like foreach (*the* feature I miss in freepascal): foreach name in names do ... end; vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PChar & AnsiString
On Tue, 1 Jun 2010 14:36:36 +0200 Jonas Maebe wrote: > > On 01 Jun 2010, at 14:28, spir ☣ wrote: > > > On Tue, 1 Jun 2010 13:05:16 +0200 (CEST) > > Michael Van Canneyt wrote: > > > >> This is not correct. Many strings are simply referenced several > >> times. > > > > May I ask in which typical cases? > > The most common one is probably assigning a function result to a > variable or field. Is there increment of ref count (I think it does +1-1)? If no, passing the ref cannot have any side-effect, so the copy_on_write scheme does not apply -- or rather does not make any change if applied. This is plain reference copy. The issue is rather for parameter passing, since here the original var survives the call (see Martin's post). Denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PChar & AnsiString
On 01/06/2010 16:13, spir ☣ wrote: On Tue, 01 Jun 2010 15:00:47 +0100 Martin wrote: On 01/06/2010 11:23, spir ☣ wrote: What is the actual benefit of copy-on-write? I ask because of the following reasoning: * If a string is just used at several places, for example in output or into bigger strings, then there is no reason reason to copy it into a new variable. * If a programmer explicitely assigns an existing string to a new variable, the intent is precisely copy-semantics, to make them independent for further changes. If there is no change, there is also no reason for such an assignment. [...] No, an assignment, or increase in ref count is not necessarily followed by a change: Procedure Foo(a:String); begin ... end; Procedure Bar; var s: string; begin s:= SomeString; Foo(s); end; Now a copy of s has to be given to Foo, because Foo *may* changes the string. But Foo may also *not* change the string => so leave it till later. For me, parameter passing is just an implicit assignment "param:=s" (with the variant of var params). The same applies to return values when assigned back in calling code (*). I would have thus expected s the pointer to be passed. Just checked it is not the case. More secure, esp since legacy shortstrings do not behave that way. This example rather backs my pov, I guess, since here copy-on-write does not apply. But it certainly could, since its application should prevent bad surprises, no? (unexpected change of original variable) I don't know all the internals of FPC, but yes to my understanding, your quote: "parameter passing is just an implicit assignment" is absolutely true. So why do you then say "copy on write" would not apply? The assignment creates a 2nd reference, and a copy only happens if inside Foo a change is made to the string. => So according to your own words, copy-on-write is exactly what happens. Shortstrings have nothing to do with it, they are not reference counted. They are a completely different data type. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Between bug?
Bee Jay : [TDateTime] > What if an app need a precise and correct result, say a rocket launcher? > :D Is there other alternative solution? Yes. Use a time type based on a fixed point representation. This eliminates drift and accuracy issues cause by a floating point representation. http://stop-me.svn.sourceforge.net/viewvc/stop-me/trunk/src/calendar.pas may serve as an idea. ;) (Still, the windows implementation, relying on MillisecondsBetween itself, still may not provide accurate clock times, so be careful.) Vinzent. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] timing again
"spir ☣" : > Thank you. Using dos.getTime (including its last arg), the following > returns integer time in 10^-2s units: [...] > > This is the needed base for my uses. (A unit of 1s is too gross for > timing, this leads to endless runs; more precision than 10^-2s is > unneeded.) Actually, the resolution is only about 55ms (or, to be precise, the underlying clock ticks with a frequency of 1193182 / 65536 Hz). Vinzent. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PChar & AnsiString
On Tue, 01 Jun 2010 16:30:22 +0100 Martin wrote: > I don't know all the internals of FPC, but yes to my understanding, your > quote: >"parameter passing is just an implicit assignment" > is absolutely true. > > So why do you then say "copy on write" would not apply? > The assignment creates a 2nd reference, and a copy only happens if > inside Foo a change is made to the string. You're right, I reasoned wrongly. Deins vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] VirtualTreeview Mac (Carbon)
CA Gorski escreveu: And if so, what is to do? Remove the dependencies on lclextensions from your port? Yes Ok, I will try... Meantime I tried to compile lclextensions against gtk2 What messages do you get when compile lclextensions for carbon? I ask that so i can add the missing function headers Value="lib/$(TargetCPU)-$(TargetOS)-$(LCLWidgetType)"/> but the compiler still uses includes from include/carbon sub-folder. What message do you get? The config seems OK I think is a good idea to move to http://lists.lazarus.freepascal.org/mailman/listinfo or private mail Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] timing again
On Tue, 01 Jun 2010 19:58:54 +0200 "Vinzent Höfler" wrote: > "spir ☣" : > > > Thank you. Using dos.getTime (including its last arg), the following > > returns integer time in 10^-2s units: > [...] > > > > This is the needed base for my uses. (A unit of 1s is too gross for > > timing, this leads to endless runs; more precision than 10^-2s is > > unneeded.) > > Actually, the resolution is only about 55ms (or, to be precise, the > underlying clock ticks with a frequency of 1193182 / 65536 Hz). > > > Vinzent. > Thank you for this precision. Where does getTime actually get its time? And where do these numbers come from; I mean why chose this time unit instead of plain 1/10 or 1/100 or 1/1000s? (1193182 does not look familiar to my eyes ;-) Do you have an idea on how to get one of those time units (ms would be perfect, since more precision can be rounded, while the contrary is a hard task!) Denis __ vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PChar & AnsiString
> > >> This is not correct. Many strings are simply referenced several > > >> times. > > > > > > May I ask in which typical cases? In an earlier version of our database (before we had things properly typed) many things were stored as strings. Thus a common ansistring may have had a reference count in the hundreds or even thousands. Most of the time, if I changed one of them, I would not want to change them all! But it saved a lot of memory to not be redundantly storing the same string. > > The most common one is probably assigning a function result to a > > variable or field. > > Is there increment of ref count (I think it does +1-1)? If no, passing the ref > cannot have any side-effect, so the copy_on_write scheme does not apply -- or > rather does not make any change if applied. This is plain reference copy. > The issue is rather for parameter passing, since here the original var > survives the call (see Martin's post). I believe it depends on the circumstance. It's been a while since I tested this, but IIRC, when a variable is passed-by-value the ref count is incremented, whereas if it is passed-by-reference the ref count is not incremented... as one should hope. In the case of the latter, this means that if the ref count is one, then copy-on-write is not needed, as there is only the one instance of the string-- so that can save some processor time. Back when I was dealing with enormous ansistrings that were frequently being changed, I spent considerable time researching this so as to figure out how to avoid unnecessary copy-on-writes. What I found is that the compiler's treatment of them is quite intuitive: there were no unpleasant surprises. I ended up changing a number of functions which took a value parameter and returned a result to instead take a reference parameter and change that. Have fun... ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] timing again
Thank you for this precision. Where does getTime actually get its time? And where do these numbers come from; I mean why chose this time unit instead of plain 1/10 or 1/100 or 1/1000s? (1193182 does not look familiar to my eyes ;-) Do you have an idea on how to get one of those time units (ms would be perfect, since more precision can be rounded, while the contrary is a hard task!) Denis The standard clock for the system timer runs at 1,193,182 Hz, derived for the original IBM PC as the 4.77 MHz processor clock divided by 4. -- Regards, Paul Breneman www.dbReplication.com - VCL database replication components www.TurboControl.com - Hardware and software development services - Educational programming project for environment monitoring - Information on using FreePascal for embedded systems - Support information for the TurboPower open source libraries ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] timing again
> On Tue, 01 Jun 2010 19:58:54 +0200 > "Vinzent Höfler" wrote: > > > "spir ☣" : > > > > > Thank you. Using dos.getTime (including its last arg), the following > > > returns integer time in 10^-2s units: > > [...] > > > > > > This is the needed base for my uses. (A unit of 1s is too gross for > > > timing, this leads to endless runs; more precision than 10^-2s is > > > unneeded.) > > > > Actually, the resolution is only about 55ms (or, to be precise, the > > underlying clock ticks with a frequency of 1193182 / 65536 Hz). > > Thank you for this precision. Where does getTime actually get its time? Technically it should use a DOS function. Of course, on non-DOS systems it will be mapped to something different with a probably higher resolution, yet the old DOS time is all accuracy you can assume here. > And where do these numbers come from; I mean why chose this time unit > instead of plain 1/10 or 1/100 or 1/1000s? (1193182 does not look > familiar to my eyes ;-) Well, historically it's the frequency driving the programmable interval timer (an 8254). I don't know the exact reason, but it's probably 1/11 of the frequency of a 13.125 MHz quartz (at least that's what it looks like, CMIIW). Whatever the exact choices of base frequency and divider, that's where the 1.193 MHz value comes from. The second part is due to the fact that the timer values are loaded with the value providing the largest divider value (and thus the least possible interrupt load). This value is actually a zero (16-bit), but having the effect of a divider of 65536), so that the abovementioned and quite strange interrupt frequency comes up. > Do you have an idea on how to get one of those time units (ms would be > perfect, since more precision can be rounded, while the contrary is a > hard task!) Actually, I would simply use "SysUtils.Now" as base clock and appropriate rounding. I used that in the past and it provides fairly accurate values while maintaining system portability. The DOS unit is provided for TP compatibility only and I wouldn't advise using it for new code. Theoretically this clock has a millisecond resolution. IIRC, in practice, the tick behind this clock is about 15 ms under Win32, but under most Unices you'll get the full millisecond resolution. If you want to get better than that, you need to get system specific, I'm afraid. But as you stated, you don't need more accuracy, so system dependent functions providing a higher resolution simply won't be necessary in your case. Vinzent. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] timing again
> The standard clock for the system timer runs at 1,193,182 Hz, derived > for the original IBM PC as the 4.77 MHz processor clock divided by 4. Digging a bit deeper clarifies it: http://sos.enix.org/lxr/source/hwcore/i8254.c?v=6.5 |* Ahhh PC systems are nice toys: this maximum "strange" frequency |* equals that of the NTSC clock (14.31818 MHz) divided by 12. In |* turn, the famous 4.77 MHz cpu clock frequency of the first IBM PC |* is this same NTSC frequency divided by 3. Why the NTSC frequency as |* a base "standard" ? Because the 14.31818 MHz quartz were cheap at |* that time, and because it allows to simply drive altogether the |* cpu, the "time of day" timer, and the video signal generators. So, the base frequency actually was a 14.318 Mhz quartz, not a 13.125 as I assumed in my previous post. But that's enough history lessons for a day. ;) Vinzent. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] timing again
> If you want to get better than that, you need to get system specific, I'm > afraid. That's not true. As Graeme already mentioned there is EpikTimer which is a cross-plattform, high-resolution timer (which btw works very well for realtime tasks). R. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
