It is a character that contains no data bits. Kinda like an empty peanut butter jar.

Null is empty or nothing or not stored or switched, depending on what circumstance your are describing.

The characters that print as nothing are undisplayable characters under the system you are using. But you can sometimes load the ansi.sys driver and change the setup of your system to display better.

Writing is by print#1,chr$(123).

First major implementation of ASCII was with the teletype system where the null character was a tape feed with no holes.

Ed Fair
Any advice I give is my best judgement based on my interpretation of the facts you supply. Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.

thanks a lot. I found a way to run the prog. at chr$(128-255)..I mean ;

  1000000-11111111 the seventh bit will be always set to 1....

But i will use just 7 bits instead of 8.

     1 xxxxxxxx

Firstbas, a QBasic clone, allows you to view all 255 characters! Check it out! Run something like:

CLS
FOR A = 0 TO 255 STEP 1
PRINT CHR$(A);" ";A
SLEEP 1
NEXT A

That will show you all of the cool characters to use in misc. programs.

Doug

Or you could go to http://www.asciitable.com/

- Martin

0 is used with extended keys.  a very good idea of extended keys is the arrow keys.  

chr$(0) + chr$(72)
chr$(0) + chr$(75)
chr$(0) + chr$(80)
chr$(0) + chr$(77)

i don't know much about extended keys though.  all i know is that they return the 0 plus their value.  

so say you made a program like this
do
do
i$ = inkey$
loop until len(i$)

print i$
loop

if you pressed a normal key, say a, it would return this:

a

say you pressed an arrow key.  it would return something like this:

 M

notice it returned a space and the letter m.  that's something like right.  i never could get the values and the keys straight...

There are easier ways to use the arrow keys, every single key on the keyboard has its own code, and you can read this code by using INP(96) to tell exactly what key has been pressed.  
I don't have the axact codes with me right now by I believe that the arrow keys are: 72 - down, 74 - left, 76 - right, and 80 - up.

I'll double check and follow up.

Thanks a lot for your informations..

my code was to ;

In screen 7 we have 320*200 with 16 colors means ;
320*200*4 bits, right ?

And mapping it ;
dim map(320,200)

It spends too much memory but ;
An ascii code is 8 bits long
so it can carry 2 pixel colors 4 - 4
for example;

pixels with colors 12,8
=1100,1000
=&hc8
=200
chr$(200)
get it now ?

320/2=160

dim map$(200,2)

for t=1 to 200
map$(t,1)=space$(160)
map$(t,2)=space$(160)
next


320*200*4/8=32000 ascii codes

so we used just a dim with (200,2) instead of (320,200)

when we save it as a file we can see the real difference..

but like what i said i'm gonna use 7 bits and the the 7nth bit will be set to 1 always......

1000 0000

or ;

a variable can be trough 0 to 65536 means 16 bits;

16 bit=4 pixels

so dim map(200,80)

the converter routinne is so simple..........

if u want me send it i will absoulitely send it;

but i need some help with inp and out
meet u on a different thread

Hi,
Going back to your original question.
chr$(0) is not the same as "".
"" does not contain anything.  There isn't any space in "".

chr$(0) contains zeros like so  00000000
chr$(1) would contain a one     00000001

Pappy
You learn something new everyday.

Thank you Pappy :)

That was very helpful. I have only used the CHR$(0) to use arrows keys as well. but I didn't use CHR$(77) and such. I just put the capital letter in quotes.

CHR$(0) + "M"

~PlystirE~

To basicguru, if you run your program to print the characters you better check for 7,10,12,13 and a few others
that will cause unwanted results. like clearing the screen with chr$(12).

fancom: seems like you're trying to doublebuffer.  check out zippy's tut on double buffering, then ninkazu's tutorial on double buffering.  

why not use screen 13?  much better.  same size screen, but 256 colours, aka 8 bit.  so 8 bits = 1 byte, 1 byte = 1 pixel, 1 integer = 2 bytes (very convient) so 1 integer = 2 pixels.  

so therefore if you were double buffering the whole screen, 320*200, 64000 pixels in area.  but it's too big.  so we're going to have to store two pixels in one integer, so it will be cut in half, 32000.  if you want it in get/put format, you'll need two extra integers, one for the width in bits (so width * 8) and the height in pixels.  so it seems like you need 32002, but you only need 32001, since counting in qbasic starts at 0.  (0,1,2,3...)  the very first variable will be 320*8, or 2560.  the second will contain the height of the screen, 200 pixels.  so therefore...

dim buffer(32001)
buffer(0) = 320*8
buffer(1) = 200
or...
get(0,0)-(319,199), buffer

so now you're set.  however, now you need to be able to draw pixels on the buffer.  with plasma357's setvideoseg, you could use qb's primary routines (pset, line, etc. etc. ) but if you don't want to use them, then you'll have to use poke.  once again this only works in screen 13.

first of all, you have to set the default segment to the buffer, as poke "pokes" information to whereever the def seg is pointing too.  however, if you use
def seg = buffer(0)
then it will set the default segment to 2560.  in order to find the address the buffer is at, you must use varseg.  it returns the segment of whatever variable you put in it.
def seg = varseg(buffer(0))
but now how do we put a pixel on the buffer?  well, first you need to know the x and the y.  now, poke works like this:
poke offset, byte
this creates problems.  how do we get the x and y variables in there?  well, you should be able to tell that this is one dimensional.  since the screen is 320 pixels wide, then we should have enough information to find the offset, or x and y coordinates on the buffer.
poke 320& * y + x + varptr(buffer(2), colour
now, we times the y with 320 because since we're working with one dimension, timesing the y with 320 will bring the offset to the right row.  adding x will move it forward to the right column.  you must add varptr(buffer(2) to skip over the two variables holding the size of the buffer.  for example, say x is 32 an y is 1.  first you times the y with 320.  this will move the the coordinates to the right row.  then you add x, which moves teh coordinates to teh right column.  oh, the reason why it's 320& instead of just 320 is because the buffer will overflow if you don't.  


sub putpixel (x, y, colour, buffer()

def seg = varseg(buffer(0))

offset& = 320& * y + x + varptr(buffer(2))
poke offset&, colour

end sub

maybe later i'll explain it better.

Little tip, you seem to contradict yourself, I liked the way that you explained the bits-pixils:  "8 bits = 1 byte, 1 byte = 1 pixel, 1 integer = 2 bytes".  
But then you used floating points variables in your example.

buffer() should be buffer%()

Also, I'm not sure if your POKEing system is fool-proof; I am pretty sure that your offset& can not be greater than 65535, but the RAM sould be sequencial, so you could figure out the offset& the way you did above, but add this code

IF offset& > 65535 THEN DEF SEG = VARSEG(buffer%(0))+1
a = offset& MOD 65535
POKE a, colour

You might be a redneck if... you think a megabyte is a good day of fishing.

I am aware of that, qbasicking, but thanks.  I just assume that the program will be .exe'd, as exe integers go from 0 to 65535.

i also assume that people use defint a-z at the beginning of their programs.  As you very well know, that means all nondefined variables are integers.  but you're right, i'll take note of that.  thanks.

btw qbasicking, you may very well be right.  i just wrote that off the top of my head.  As i recall, 16 offsets will equal a segment.  knowing that, you can set the segment to this:

def seg = varseg(buffer%(0)  + int(offset& / 16)
poke offset& mod 16

this will fix any overflowing bug.  i don't use this often, because exeing the program will fix this bug, and it works slower than what i had before.  

a very good resource would be zippy's buffering tut.  it's how i learned buffering.  and relgfx is a VERY good read.  very well organized, shows you what pure qb can truly do.

thank u a lot barok and qbking..........I identified that a *.bmp loader can do what i was triing to  do...

a *.bmp file huh


i thought that using integers would be better for using ram..and dims..but a *.bmp file already works like that.

what a silly.......