Jump to content
IGNORED

PRINT - Different ways


Recommended Posts

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 by Alkadian
Found the solution
Link to comment
Share on other sites

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.

  • Thanks 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...