• Please review our updated Terms and Rules here

Transparent Mode

CP/M User

CP/M User

Veteran Member
Joined
May 2, 2003
Messages
2,986
Location
Back of Burke (Guday!), Australia
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" 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.
 
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).
 
"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.
 
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.
 
"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.
 
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.
 
"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.
 
CP/M User said:
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! ;-)
Click to expand...
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.
 
"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.
 
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.
 
"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.
 
CP/M User said:
which Emulator were the tests done on?
Click to expand...
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:

Code: 
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.

Code: 
             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
 
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:
Code: 
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
 
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.

Code: 
   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
 
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
 
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.
 
You must log in or register to reply here.
Back
Top