PRINT - Different ways

[Alkadian]

Hi,

 

I am reading back Oscar's book, and with reference to Chapter 4, Paragraph 4.2 and the code below:

 

CLS

MODE 0,2,0,0,0

WAIT

 

DEFINE 0,1,my_bitmap

 

PRINT AT 0 COLOR 1

FOR C = 1 TO 20

PRINT "\256"

NEXT C

 

loop:

GOTO loop

 

my_bitmap:

 

BITMAP "11111111"

BITMAP "00000000"

BITMAP "11111111"

BITMAP "00000000"

BITMAP "11111111"

BITMAP "00000000"

BITMAP "00000000"

BITMAP "00000000"

 

gives the same result if I replace the section in red above with :

 

 

FOR C = 0 TO 19

PRINT AT C COLOR 1, "\256"

NEXT C

 

which is equivalent to

 

FOR C= 0 TO 19

#BACKTAB(C)=$0801

WAIT

NEXT C

 

What I don't follow with the original way is that how the compiler knows that every iteration we move from card 0 to card 1 to card 2 etc. if the position 0 is fixed?

 

Thanks!

 

EDIt: Of course! I have figured it out! That is equivalent to write PRINT "\256" 20 times! Oh dear, time to do a break then

 

 

Edited September 25, 2023 by Alkadian
Found the solution

[+DZ-Jay]

30 minutes ago, Alkadian said:

Hi,

 

I am reading back Oscar's book, and with reference to Chapter 4, Paragraph 4.2 and the code below:

 

CLS

MODE 0,2,0,0,0

WAIT

 

DEFINE 0,1,my_bitmap

 

PRINT AT 0 COLOR 1

FOR C = 1 TO 20

PRINT "\256"

NEXT C

 

loop:

GOTO loop

 

my_bitmap:

 

BITMAP "11111111"

BITMAP "00000000"

BITMAP "11111111"

BITMAP "00000000"

BITMAP "11111111"

BITMAP "00000000"

BITMAP "00000000"

BITMAP "00000000"

 

gives the same result if I replace the section in red above with :

 

 

FOR C = 0 TO 19

PRINT AT C COLOR 1, "\256"

NEXT C

 

which is equivalent to

 

FOR C= 0 TO 19

#BACKTAB(C)=$0801

WAIT

NEXT C

 

What I don't follow with the original way is that how the compiler knows that every iteration we move from card 0 to card 1 to card 2 etc. if the position 0 is fixed?

 

Thanks!

 

EDIt: Of course! I have figured it out! That is equivalent to write PRINT "\256" 20 times! Oh dear, time to do a break then

 

 

 

You figured it out already, but for the benefit of others, and for additional context, here is what is happening.

 

Like in many The "PRINT" statement keeps track of an internal "cursor" where the next character will be placed.  It also keeps track of the last color attribute used, so it shouldn't be necessary to repeat it on every subsequent "PRINT" statement if it remains the same.  The default starting color is black, and cursor starting position is at the origin of the screen (column=0, row=0).  The cursor is advance for every character printed in each subsequent "PRINT" statement.

 

The "PRINT AT" variation, on the other hand, resets the cursor to a specific position.

 

So, how does that apply to the code in question (as shown below)?

PRINT AT 0 COLOR 1
FOR C = 1 TO 20
  PRINT "\256"
NEXT C

 

Notice that the first line sets the cursor position and the printing color, but prints absolutely nothing.  Because no characters were printed, the cursor is not advanced and remains at position 0.  After that, the loop prints the first picture from GRAM (pictures in GROM are from 0 to 255), and repeats 20 times.

 

The color set on the first line is reused until a new "PRINT AT x COLOR y" statement is encountered.

 

I hope that this makes it even more clear.

 

      -dZ.

[Alkadian]

@DZ-Jay, many thanks for your further clarifications. Very clear indeed.

 

I guess from a clock cycles point of view, the code provided in the book is better as it takes less instructions.

[artrag]

Not necessarily. Compare the asm files generated by the compier if you're curious about which solution is faster. 

[Alkadian]

1 minute ago, artrag said:

Not necessarily. Compare the asm files generated by the compier if you're curious about which solution is faster. 

Thanks. Very good point! 

[+DZ-Jay]

56 minutes ago, Alkadian said:

@DZ-Jay, many thanks for your further clarifications. Very clear indeed.

 

I guess from a clock cycles point of view, the code provided in the book is better as it takes less instructions.

No worries.

 

I would not expect it to be more efficient, it is certainly less keystrokes type.

 

44 minutes ago, artrag said:

Not necessarily. Compare the asm files generated by the compier if you're curious about which solution is faster. 

 

I have not looked, but I suspect that the compiler generates the same code for both — unless the constant “PRINT AT” induces it to reset the cursor and and update it over and over, which is certainly more work.

 

In any case, I suspect that in anything else than the most trivial programs, the cycle count of a PRINT statement would be the least candidate for a bottleneck.

 

   dZ.

[carlsson]

Also note that unlike other vintage BASIC dialects on home computers, a PRINT here doesn't do a carriage return. Essentially it moves the cursor like an older BASIC would do if you add a semicolon after the data to be printed. Perhaps nobody expects it to work like that anyway.