Transparent Mode

[CP/M User]

Just curious to know if other machines have this.

On the Amstrad it's a Control Code sequence,
which can be activated with a BASIC statement
like this:

PRINT CHR$(22)+CHR$(1); which activates this.

To deactivate it it's:

PRINT CHR$(22)+CHR$(0);

In particular, I was just wonderning if other Z80s
can do this, but any other machine which supports
this would be great.

Cheers,
CP/M User.

[carlsson]

What is the difference between transparent and printing in the same colour as the background?

[CP/M User]

"carlsson" wrote:

> What is the difference between transparent
> and printing in the same colour as the
> background?

The idea of this transparent mode, is you can
write in other text characters.

For example say I have a character at row 1
column 1 with a letter Q in it. Normally, if I
were to write another letter in there the Q
would disappear. However, if I wrote a
statement like this:

LOCATE 1,1:PRINT CHR$(22)+CHR$(1);"Z"

The Q would remain & Z will just fill in the
cells (in the 8x8 grid) which weren't used by
the Q.

Writing characters which is the same colour
as the background would just result in
invisible characters, even though it seems
pointless this can be quite a clever little
programming trick on an Amstrad, cause
you can just issue a background colour
change & the characters would appear
out of the blue (which looks better than
if you were to see the stuff written out).

Cheers,
CP/M User.

[carlsson]

Aha. I wonder if not the OVER attribute on the ZX Spectrum Basic does exactly this. It probably requires a bitmapped text display, where all the text automatically is plotted onto screen rather than fetched character by character from a ROM (or RAM).

[CP/M User]

"carlsson" wrote:

> Aha. I wonder if not the OVER attribute
> on the ZX Spectrum Basic does exactly
> this. It probably requires a bitmapped
> text display, where all the text
> automatically is plotted onto screen
> rather than fetched character by
> character from a ROM (or RAM).

Well it might do. The Amstrad's do have
some sort of connection with them, so
perhaps it might.

On a Spectrum it maybe worthwhile trying
this:

PRINT AT 1,1;"Q" [ENTER]
PRINT AT 1,1;chr$(22)+chr$(1);"Z" [ENTER]
PRINT chr$(22)+chr$(0); [ENTER]

Cheers,
CP/M User.

[carlsson]

Close. :) CHR$(22) is the control code for AT, while CHR$(21) is the control code for OVER.

Edit: After testing on the emulator, this actually works:

PRINT AT 1,1;"Q"; AT 1,1; CHR$(21)+CHR$(1);"Z"

or in an easier way PRINT AT 1,1;"Q"; AT 1,1; OVER 1;"Z"

The OVER attribute will supposedly be turned off when a PRINT statement has ended. After trying WinAPE, it seems the Amstrad works in the same way. The major difference is that the ZX seems to XOR overlapping pixels while the Amstrad only uses OR.

[CP/M User]

"carlsson" wrote:

> Close. :) CHR$(22) is the control code for AT, while
> CHR$(21) is the control code for OVER.

"Edit: After testing on the emulator, this actually works:"

> PRINT AT 1,1;"Q"; AT 1,1; CHR$(21)+CHR$(1);"Z"

> or in an easier way
> PRINT AT 1,1;"Q"; AT 1,1; OVER 1;"Z"

> The OVER attribute will supposedly be turned off when
> a PRINT statement has ended. After trying WinAPE, it
> seems the Amstrad works in the same way. The major
> difference is that the ZX seems to XOR overlapping
> pixels while the Amstrad only uses OR.

Well the idea is the same. The Amstrad doesn't have an
instruction to write over text, which is why we need to
use the Control Characters to enable this feature.

Character 21 on the Amstrad actually turns the text
screen off & is enabled with Control character 6.

Cheers,
CP/M User.

[carlsson]

I believe the Spectrum Basic is quite unique by having commands like INK, PAPER, BORDER, FLASH and OVER which also can be used within a PRINT statement. Normally they would be standalone only or a control code for PRINT usage.

Admittingly, I don't have so much experience with the other Basics, so I can't speak for Apple, Atari, Texas Instruments, Radio Shack, Oric, MSX etc.

[CP/M User]

"carlsson" wrote:

> I believe the Spectrum Basic is quite
> unique by having commands like INK,
> PAPER, BORDER, FLASH and OVER
> which also can be used within a PRINT
> statement. Normally they would be
> standalone only or a control code for
> PRINT usage.

Not as unique as you think. The CPC has
commands like INK, PAPER, BORDER. No
FLASH though, FLASH would be like issuing
an INK ink_number, colour1, colour2 (hence
flashing).

The Amstrad CPC can also access these
commands by using control codes in PRINT
statements, but for type-ins, it's not good
for people typing in stuff like that! ;-)

> Admittingly, I don't have so much
> experience with the other Basics, so I
> can't speak for Apple, Atari, Texas
> Instruments, Radio Shack, Oric, MSX
> etc.

I've played around with the BASIC on
an Oric emulator, not bad, but I haven't
used it in a while! :-(

Cheers,
CP/M User.

[carlsson]

The CPC has commands like INK, PAPER, BORDER.
The Amstrad CPC can also access these commands by using control codes in PRINT statements, but for type-ins, it's not good for people typing in stuff like that! ;-)
Exactly. You can do this:

10 INK 5:PRINT "HELLO" or
10 PRINT CHR$(whatever);CHR$(5);"HELLO" but not
10 PRINT INK 5;"HELLO"

The Oric Basic is supposedly a halfway illegal exact copy of Microsoft Basic, as it was licensed for the Microtan 65 but later reused without a license for the Oric computers. It is dog slow too, which was partly explained to me in a newsgroup by the number of times per second the computer is scanning the keyboard etc, and that it is done in a crude way.

[CP/M User]

"carlsson" wrote:

>> The CPC has commands like INK, PAPER, BORDER.
>> The Amstrad CPC can also access these commands
>> by using control codes in PRINT statements, but for
>> type-ins, it's not good for people typing in stuff like
>> that! ;-)

> Exactly. You can do this:

> 10 INK 5:PRINT "HELLO" or
> 10 PRINT CHR$(whatever);CHR$(5);"HELLO" but not
> 10 PRINT INK 5;"HELLO"

Well, the first one is still Invalid. It looks at though
INK on the Spectrum is the same as PEN on the CPC.
PEN 5 would give you the colour of whatever 5 is.

The second line would be something like this on an
CPC:

print chr$(15);chr$(colour);"HELLO" - colour can be
anothing from 1 to 15. Of course this is based on the
PEN command for the CPC.

The third is definitely out.

INK on an CPC is used to assign a colour to a colour
number. There is 27 colours you can choose from &
upto only 16 are allowed (depending on which screen
mode you're in), so in low res it's 16, mediam res 4
& high res 2. But you can still use 27 colours for any
of those screen modes. So if you wanted Bright White
text & you're in PEN 1 a INK 1,26 would give you
bright white text. For a black background (usually 0
is the default) it's INK 0,0: But of course like PEN
which changes the colour of the text, PAPER is used
to change the background value.

> The Oric Basic is supposedly a halfway illegal exact
> copy of Microsoft Basic, as it was licensed for the
> Microtan 65 but later reused without a license for
> the Oric computers. It is dog slow too, which was
> partly explained to me in a newsgroup by the
> number of times per second the computer is
> scanning the keyboard etc, and that it is done in
> a crude way.

I wouldn't agree with that, I've typed in some game
which was a basically a version of Missile Command
from the Atari. I thought it was quite good. But to be
honest, I haven't really tested this BASIC to see
what the strengths & weaknesses are.

Cheers,
CP/M User.

[carlsson]

Using an emulator and hand timing, which indeed is a poor way to determine real speed, I ran the suite of eight simple benchmarks issued by Byte in 1977. It did really poor results compared to the previously known benchmarked machines of the era. Someone ran the same benchmarks on the real computer with exact timing and got similar results.

In average, maybe one doesn't notice if the Basic is slower and internally works in a more complex way than another, but when running 1000 iterations of the same code, the differences between implentations, clock speeds and processor architectures show quite well.

[CP/M User]

"carlsson" wrote:

> Using an emulator and hand timing, which
> indeed is a poor way to determine real
> speed, I ran the suite of eight simple
> benchmarks issued by Byte in 1977. It did
> really poor results compared to the
> previously known benchmarked machines
> of the era. Someone ran the same
> benchmarks on the real computer with
> exact timing and got similar results.

> In average, maybe one doesn't notice if
> the Basic is slower and internally works in
> a more complex way than another, but
> when running 1000 iterations of the same
> code, the differences between
> implentations, clock speeds and processor
> architectures show quite well.

Well you've got me there Carlsson, which
Emulator were the tests done on?

Cheers,
CP/M User.

[Terry Yager]

I ran the suite of eight simple benchmarks issued by Byte in 1977.

Are these benchmarks portable? What language? Feel like sharing a copy? (I don't have any old Byte magazines to copy from).

--T

[carlsson]

which Emulator were the tests done on?
Euphoric 0.99-something.

It seems the benchmarks did not come from BYTE, but Kilobaud and later Personal Computer World, who included the 8th trigonometric test. The benchmarks are written in Basic. Add or replace lines as specified, or start from scratch when (new) is written:


BENCHMARK 1 (new)
-----------------
100 REM TEST 1
110 PRINT "START"
120 FOR K=1 TO 1000
130 NEXT K
500 PRINT "STOP"
550 END

BENCHMARK 2
-----------
120 K=0
130 K=K+1
190 IF K<1000 THEN GOTO 130

BENCHMARK 3
-----------
140 A=K/K*K+K-K

BENCHMARK 4
-----------
140 A=K/2*3+4-5

BENCHMARK 5
-----------
150 GOSUB 600
600 RETURN

BENCHMARK 6
-----------
125 DIM M(5)
155 FOR L=1 TO 5
160 NEXT L

BENCHMARK 7
-----------
157 M(L)=A

BENCHMARK 8 (new)
-----------------
100 REM TEST 8
110 PRINT "START"
120 K=0
130 K=K+1
140 A=K^2
150 B=LOG(K)
160 C=SIN(K)
170 IF K<1000 THEN GOTO 130
180 PRINT "STOP"
190 END


These were the benchmark results, counted in number of seconds to execute. The average value may be doubtful, but was originally included in the published tests.


BM1 BM2 BM3 BM4 BM5 BM6 BM7 BM8 Avg
--------------------------------------------------
BBC (B ?) 0.6 3.2 8.1 8.8 9.9 14.3 21.9 48 14.3
IBM PC 1.5 5.2 12.1 12.6 13.6 23.5 37.4 35 17.6
Acorn Atom 0.5 5.1 9.5 10.8 13.9 19.1 31.1 92 22.8
VIC-20 1.4 8.3 15.5 17.1 18.3 27.2 42.7 99 28.7
Apple II 1.3 8.5 16.0 17.8 19.1 28.6 44.8 107 30.4
Dragon 32 1.6 10.2 19.7 21.6 23.3 34.3 50.0 129 36.2
Oric Atmos 1.6 15.2 25.4 27.4 33.0 45.6 68.5 136 44.1
SVI-328 1.6 5.4 17.9 19.6 20.6 30.7 42.2 236 46.7
ZX81 (fast) 4.5 6.9 16.4 15.8 18.6 49.7 68.5 229 51.2
Microtan65 1.9 12.8 24.7 27.8 29.6 43.2 68.9 243 56.5
ZX Spectrum 4.8 8.7 21.1 20.4 24.0 55.3 80.7 253 58.5
Oric-1 1.8 17.1 29.0 31.4 38.0 51.8 77.8 230 59.6
Atari 600XL 2.2 7.2 19.1 22.8 25.8 37.6 58.3 412 73.1
TI-99/4A 2.9 8.8 22.8 24.5 26.1 61.6 84.4 382 76.6

[Terry Yager]

Thanx, Anders. I got a few machines I'll try them out on.

--T

[Terry Yager]

Ok, so I just tried a slightly modified version of BenchMark #1 on several old portables and thought I'd post the results. I don't have a stopwatch, so I used the RealTimeClock in each machine to track the execution time (rounded to the whole second, none of them track fractions). The program goes:

10 PRINT "START ";TIME$
20 FOR I=1 TO 1000
30 NEXT I
40 PRINT "STOP ";TIME$
50 END


The results:

Epson HX-20 (dual Hitachi 6301s clocked @ 614KHz, running MicroSoft BASIC): 3 seconds.
Tandy 102 (Intel 8085 @ 3Mhz, MicroSoft BASIC): 3seconds.
Cambridge Computers Z-88 (Zylog Z80 @ 3.5MHz, BBC BASIC): 1 second.
Hewlett-Packard 75C (Proprietaty processor, clock unknown, proprietary BASIC) 3 seconds.

BTW, the two slowest machines in the table above were both Sinclair machines. Looks like Sir Clive finally got it right with the Z-88, which was the fastest in my test.
I'll try other benchmarks later. I have another BASIC benchmark I'll post later on.

Edit: Just for laffs, I ran the same program on my ThinkPad (P-II, 266MHz running BBCBASIX in a DOS window under WIN 98SE). Results? Less than one second. Guess I need a longer, slower program to measure the Pentium II. BBCBASIX may be downloaded here:

http://www.bbcbasic.com/

--T

[Terry Yager]

Here's a program that computes all the prime numbers (in reverse order) from 32767 to X, with X being user supplied. (29000 is a good seed number to use). It also uses the RTC, so it'll have to be modified if your machine doesn't have one.


10 PRINT "Stop Calculations at what value less than 32767?"
20 INPUT V
30 P = 32767 DIV 100
40 IF V>32767 OR V<0 THEN PRINT "INVALID": GOTO 10
50 PRINT "Primes < 32767 & > ";V
60 A$ = TIME$
70 FOR I = 32767 TO V STEP -2
80 FOR J = 3 TO 191 STEP 2
90 IF (I MOD J) = 0 THEN GOTO 140
95 NEXT J
100 IF (I<P*100) THEN PRINT : P=P-1
110 PRINT I;" ";
140 NEXT I
150 B$ = TIME$
160 PRINT A$
170 PRINT B$


This prog uses the display, so it may be a more accurate test of real-world situations than just testing raw computin' power. (It'll run extra slow on my old LCD-based portables).

--T

[Terry Yager]

The above program (prime numbers) ran in 5 min. 15 sec. on my Z-88, and in just 5 sec. on my Pentium II laptop, using 29000 as a seed number. (We've come a long way in the past 20-or-so years, haven't we?)

Edit: Eliminating the display (REM-out line 110) shaved the time down to 1 sec. on the ThinkPad and 4min. 23 sec. on the Z-88.

--T

[carlsson]

In the case of Z88, I think the answer is BBC Basic, which is known to be really quick and elegant on both 6502 and Z80 implementations. There is a Sinclair Spectrum implementation of BBC Basic too, I think, but I don't know if it is freely distributable and how common it is.

I can try the prime numbers on some computers/emulators when I get home. The most interesting part with the Kilobaud benchmarks is to see how time differs between each benchmark, and which factors slow down more than others. In almost all cases except Sinclair Basic, using numeric constants is slower than using variables.

[Terry Yager]

In the case of Z88, I think the answer is BBC Basic, which is known to be really quick and elegant on both 6502 and Z80 implementations. There is a Sinclair Spectrum implementation of BBC Basic too, I think, but I don't know if it is freely distributable and how common it is.

Yeah, I thought that might be the case, too. The Sinclair & Amstrad (CP/M) versions of BBC are available at the link I posted above, as well as a plain-vanilla CP/M version.

I can try the prime numbers on some computers/emulators when I get home. The most interesting part with the Kilobaud benchmarks is to see how time differs between each benchmark, and which factors slow down more than others. In almost all cases except Sinclair Basic, using numeric constants is slower than using variables.

That makes sense, since a variable has to be re-calculated each time it is used, but a constant is always "known" to the program. (I wonder if numeric variables take longer than strings, since string variables only have to be stored and read when needed?)

--T

[carlsson]

In almost all cases except Sinclair Basic, using numeric constants is slower than using variables.
That makes sense, since a variable has to be re-calculated each time it is used, but a constant is always "known" to the program. (I wonder if numeric variables take longer than strings, since string variables only have to be stored and read when needed?)
Err? I can't speak for all Basic interpretations, but in Commodore Basic, which is a Microsoft derivate:
a decimal (A) or integer (A%) variable allocates 7 bytes of space and appears to be evaluated in the internal format when it is allocated
a string (A$) variable allocates 7 bytes of space, but points into the program itself
whenever a string is changed or concatenated, it is "evaluated" into a local copy and grows in size (see below)
a numeric constant doesn't allocate space anywhere and thus has to be evaluated everytime it appears
an array up to 10 elements is automatically dimensioned when one element is accessed if the array isn't already dimensioned
manually dimensioning smaller arrays will save space
an array of integer variables (9 bytes + 2 per element) takes less space than an array of decimal variables (12 bytes + 5 per element)
This line will thus only take 7 bytes after running:
10 A$="A VERY LONG STRING INDEED"

while adding this line, the program instead will take 52 bytes extra:
15 A$=A$+" BUT NOT THE LONGEST POSSIBLE"

By the way, your prime number program calculating primes between 29000 and 32767 took 7 minutes and 38 seconds to execute on the VIC-20 (using the VICE emulator in warp mode). I made the following significant changes to the listing:

30 P%=32767/100 : REM P% will hold the integer value
60 TI$="000000" : REM resetting the timer
90 IF INT(I/J)*J=I THEN 140 : REM instead of I MOD J = 0

Taking away the output just reduced the execution speed by six seconds.

[carlsson]

Using decimal variable P instead of P% unexpectadly increased execution time by one second (7m33s), which probably is an error in measurement.

As FOR J% is not allowed, I tried to unroll the loops into IF statements: 13m13s (integer) or 12m31s (decimal) variables, which also could be realized by my previously posted benchmarks.

[Terry Yager]

Err? I can't speak for all Basic interpretations, but in Commodore Basic, which is a Microsoft derivate:
a decimal (A) or integer (A%) variable allocates 7 bytes of space and appears to be evaluated in the internal format when it is allocated
Of course a variable must be evaluated when it is first defined, but does this mean that it is not evaluated again unless it has been changed, or is it re-evaluated every time it is encountered (to determine if it has changed)?

a string (A$) variable allocates 7 bytes of space, but points into the program itself
Is this because the string is stored within the program itself, and therefore does not need to allocate any extra (external) storage space elsewhere in memory? If this is the case, what is the purpose of BASIC reserving some space (at the top of RAM usually) for string storage, or doesn't Commodore BASIC reserve any string space?

whenever a string is changed or concatenated, it is "evaluated" into a local copy and grows in size (see below)

Right (I think)... The string only needs to be re-evaluated if it has been changed. (Like the numeric variable above?)

a numeric constant doesn't allocate space anywhere and thus has to be evaluated everytime it appears
The constant does not need to be stored because it is always known to the program, since it never changes, so why does it need to be evaluated whenever it is encountered?

an array up to 10 elements is automatically dimensioned when one element is accessed if the array isn't already dimensioned

...?

manually dimensioning smaller arrays will save space
...??

an array of integer variables (9 bytes + 2 per element) takes less space than an array of decimal variables (12 bytes + 5 per element)

...???
Don't mind me, I've never understood arrays. (I'm (obviously?) not a programmer, and although assembly language makes some kinda sense to me (dealing with the hardware at it's own level), I've never been able to grok BASIC at all

This line will thus only take 7 bytes after running:
10 A$="A VERY LONG STRING INDEED"

while adding this line, the program instead will take 52 bytes extra:
15 A$=A$+" BUT NOT THE LONGEST POSSIBLE"

Why is this? How is it that the second half of the string adds so many bytes of storage?

By the way, your prime number program calculating primes between 29000 and 32767 took 7 minutes and 38 seconds to execute on the VIC-20 (using the VICE emulator in warp mode). I made the following significant changes to the listing:

It isn't my program (I wish)...it's a PD thing I copied from a (e-)book.

30 P%=32767/100 : REM P% will hold the integer value
60 TI$="000000" : REM resetting the timer
90 IF INT(I/J)*J=I THEN 140 : REM instead of I MOD J = 0

I'll try changing those values and run the benchmark again to see how much difference it makes.

Taking away the output just reduced the execution speed by six seconds.
But you're using a CRT, right? That wouldn't take as much of a hit as a (notoriously s-l-o-w) LCD display, would it?

--T

[carlsson]

Of course a variable must be evaluated when it is first defined, but does this mean that it is not evaluated again unless it has been changed, or is it re-evaluated every time it is encountered (to determine if it has changed)?
Yes, AFAIK, once evaluated it is stored in internal MFLPT (floating-point) form. If changed, it is of course re-evaluated.
a string (A$) variable allocates 7 bytes of space, but points into the program itself
Is this because the string is stored within the program itself, and therefore does not need to allocate any extra (external) storage space elsewhere in memory? If this is the case, what is the purpose of BASIC reserving some space (at the top of RAM usually) for string storage, or doesn't Commodore BASIC reserve any string space?
It reserves space, but as long as the string is identical to the listed one, there is no need to copy the value into work memory. As I wrote, when the string is changed, it is first copied and will thus take more memory.
The constant does not need to be stored because it is always known to the program, since it never changes, so why does it need to be evaluated whenever it is encountered?
Because it is stored like text "12632", not a hexadecimal or MFLPT value. The interpreter only tokenizes keywords when the program is inputted, not evaluating constants. Other dialects may do both.
an array up to 10 elements is automatically dimensioned when one element is accessed if the array isn't already dimensioned
manually dimensioning smaller arrays will save space
an array of integer variables (9 bytes + 2 per element) takes less space than an array of decimal variables (12 bytes + 5 per element)
...?
...??
...???
I just wanted to give an answer why integer variables exist, as they are more limited and slower (stored in integer rather than MFLPT format, so it has to be converted everytime it is used) than decimal variables.

This line will thus only take 7 bytes after running:
10 A$="A VERY LONG STRING INDEED"

while adding this line, the program instead will take 52 bytes extra:
15 A$=A$+" BUT NOT THE LONGEST POSSIBLE"

Why is this? How is it that the second half of the string adds so many bytes of storage?
Because in the first case, a string variable is set up but pointing to the string inside the program. In the second case, the variable is modified and thus its value has to be copied and modified in workspace. :)

Taking away the output just reduced the execution speed by six seconds.
But you're using a CRT, right? That wouldn't take as much of a hit as a (notoriously s-l-o-w) LCD display, would it?
Right. I think it depends on how the PRINT and screen output is performed. On a Spectrum, Amstrad or all the other systems which seem to plot the text on a high resolution screen, I'm afraid it could make quite a lot of difference despite running on a CRT, but a character-based display where the video chip only has to fetch 8x8 pixels of character data from ROM, it may not make much of a difference. We'll wait for CP/M User to try the prime numbers with and without display.

[CP/M User]

"carlsson" wrote:

> Right. I think it depends on how the PRINT
> and screen output is performed. On a
> Spectrum, Amstrad or all the other systems
> which seem to plot the text on a high
> resolution screen, I'm afraid it could make
> quite a lot of difference despite running on
> a CRT, but a character-based display where
> the video chip only has to fetch 8x8 pixels
> of character data from ROM, it may not
> make much of a difference. We'll wait for
> CP/M User to try the prime numbers with
> and without display.

Oh we're onto Prime Number programs in
this thread now! ;-)

I had to do some modifications with your little
program so it worked on my Amstrad.

Here they are:

30 P = 32767/100
No such thing called DIV in Locomotive BASIC

60 A = time/300

Not sure about this one. Time/300 is the value
used to determine what 1 sec is. A needed to
be a value & not some string or character
variable.

150 B = time/300

The same as 60.

160 & 170 Changed String variables to Integer
variables (I hope! :-)

Now the times I had:

3 min 55 secs with display & 3 min 41 secs
without display. Doesn't make any real
difference, but then if I'm doing something
wrong with the time statement, then it should
take less time.

So unless you've just called time$ as another
string, then maybe that's the problem & I
should call it something else (like T$ for
example). Time is actually a function on my
Amstrad! :-)

Cheers,
CP/M User.

[carlsson]

Oh we're onto Prime Number programs in this thread now! ;-)
Yep, "transparent" prime numbers if you decide not to print them.

3 min 55 secs with display & 3 min 41 secs without display.
Hmm.. that looks speedy, but maybe the Locomotive Basic is speedy on the Amstrad? You could time it by hand to make sure you were not fooled.

[CP/M User]

"carlsson" wrote:

>> 3 min 55 secs with display & 3 min 41
>> secs without display.

> Hmm.. that looks speedy, but maybe the
> Locomotive Basic is speedy on the
> Amstrad? You could time it by hand to
> make sure you were not fooled.

I used a stop watch for this & so there's
no way that would be incorrect, unless
I've misinterpreted this program for
Locomotive BASIC. The Amstrad runs
at 4Mhz (about the same as a Spectrum),
but it's BASIC seems more advanced. I
know it's quicker than Turbo Pascal in
some regards, so it's not bad! :-) If
anything my timing might be a couple of
seconds out, meaning it could be 3
minutes & 51 seconds.

Cheers,
CP/M User.