Simple BASIC 'DATA Statement' Query.

ページ 1/3
| 2 | 3

Hi guys sorry to bother you all again. This will be easy for most off you i suspect. OK i have looked at a few data statements and maybe it was on another 8 bit system. I can't remember now. but a data statement can be binary. eg

DATA 0,0,1,0,0,1,0,0

There would be 8 data statements the 1 would color a 'pixel' in on the sprite map and a 0 would leave it transparent. I remember this being easy.

So what is this ? :-

1470 DATA 0,01,01,01,01,01,01,01,01,03,07,0F,0F,0F,0F,0F
1480 DATA 0,0,0,0,0,0,0,0,0,80,C0,E0,E0,E0,E0,E0,:REM EINDE EERSTE BLOK
1490 DATA 0F,0F,0F,0F,0F,0F,0F,0F,0F,0F,0F,0F,0F,0F,0F,0F,E0,E0,E0,E0,E0,E0,E0,E0,E0,E0,E0,E0,E0,E0,E0,E0:REM EIND
1500 DATA 1F,3F,7F,5E,5E,5E,5E,7F,7F,1F,1F,0F,01,03,07,0F,F0,F8,FC,F4,F4,F4,F4,FC,FC,F0,F0,E0,00,80,C0,E0
1510 DATA 81,5A,42,FF,24,18,18,

Line 1510 only has 7 and not 8 numbers like id suspect 1490 and 1500 are exceptionally long ???? and how does the computer assemble this type of data into individual sprites ? I would have expected an identification for the first sprite, like a sprite 1 starts here and ends there, sprite 2 now starts here and ends there and so on but its just one long list of data statements :/ how can the computer know where the data should be assigned ?

AHHH WAIT JUST ONE MINUTE. I THINK THE COIN JUST DROPPED. EACH VALUE IS ONE ENTIRE LINE OF BINARY SO ITS A GOOD WAY TO COMPRESS INFORMATION ? STILL NEED THE REST OF MY QUERYS ANSWERED THOUGH ! I love it when the coin drops We need a Lightbulb Emojy web devs !

ログイン/登録して投稿

Hi,

The MSX-BASIC SPRITE\$ definition actually requires that all sprites are defined as strings. (ie. SPRITE\$(0)=" P " to make a tiny ball.) The problem on string representation is how ever that not all needed characters can be written on keyboard or put to a BASIC listing and that is why some number based representation is typically used.

In book examples this is typically solved by using binary representation as it is quite intuitive for humans to read and understand. The problem is that it takes quite a lot of space and memory from the listing and for computer it is not any faster or better than some other "wrong" format. Here clearly hexadesimal representation has been used where each number/letter actually represents 4bits. (1 pair = 8bits) For human it is harder to read, but from computer point of view it is just as wrong as binary.

The DATA statements them self can contain any type of data. The parameters can be integers, strings or floats (ie. DATA 1,HELLO,3.14,"My name") it all depends of how READ is used to fetch the data. Please check the loop that does the conversion to string to understand the format. The inner loop is likely something like SP\$="" : FOR I=0 to 15 : READ D\$ : SP\$=SP\$+CHR\$(VAL("&H"+D\$)):NEXT I:SPRITE\$(0)=SP\$

Quote:

Line 1510 only has 7 and not 8 numbers like id suspect

You missed the last "," there is no value after that, so it returns empty string. On conversion plain "&H" then converts to 0. The DATA statements can be split as you wish as long as the parameter count matched the number of READs. (Ok, DATA can have extra parameters as well, but that would be useless)

I know it'd be bad practice, but do all these [graph]-images actually represent an ascii value, e.g. could you use these silly graphics (like the classic window frame, using [graph] [e], [r], [t], [d], [f], [g], [c], [v], [b]) to make a sprite strings?

Thanks for the explanation. Could you go into a little more detail in how the SPRITE\$ Definition READS the "CORRECT" DATA Statement ? How does it Know what data statement to read first and how many data statements will form a sprite. Is it simply that each data statement is an entire sprite ?

@wolf_ A quick test run in an emulator would say, "yes".

READ will simply get the next value from your lines of DATA. It's the programmer's responsibility to read the correct amount of DATA. Or you will get an Out of DATA error.

Hit-Biter wrote:

Thanks for the explanation. Could you go into a little more detail in how the SPRITE\$ Definition READS the "CORRECT" DATA Statement ? How does it Know what data statement to read first and how many data statements will form a sprite. Is it simply that each data statement is an entire sprite ?

DATA statements are read in the same order as they appear in the listing. When all values are returned from first DATA line, BASIC automatically continues from next found DATA statement. RESTORE can be used to alter the BASIC internal pointer if needed, but it accepts only line number as value. Practically DATA is useful only when you just need to read the values in linear order one after each other. If you need random access, it is better to put the values to array first.

The sprites are either 8-byte strings or 32-byte strings. If the string is shorter, rest of the sprite is automatically filled by 0-bytes. How you store the strings to DATA-statements (or if you use DATA-statements at all) is totally up to you... You can use as many as you like.

wolf_ wrote:

I know it'd be bad practice, but do all these [graph]-images actually represent an ascii value, e.g. could you use these silly graphics (like the classic window frame, using [graph] [e], [r], [t], [d], [f], [g], [c], [v], [b]) to make a sprite strings?

Well... Yes, in theory... How ever in practise you won't end up with useful sprite data because in strings these window frame characters are encoded to 2 bytes where first byte is 1 and second byte is a capital letter... For example: PRINT CHR\$(1)+"U" ' == GRAPH + G

Hey Guys I have another DATA Question . Sorry. I've still quite not got it yet ! OK so I'm now understanding that each Hex value represents an entire row of Binary or eight 1's and 0's and I've plotted some of the DATA Statements on 5x5 Graph Paper so i can see the sprite design. Now my question is this. When you have a long data statement like

DATA 0,01,01,01,01,01,01,01,01,03,07,0F,0F,0F,0F,0F

Does this draw a) 1 long sprite from left two right
b) 1 tall sprite from top to bottom
or c) 2 individual sprites whose position are arranged outwith the data statement

or some other explanation I'm missing ?

DATA is just data. Don't focus too much on the DATA statement.

What you're really after is [url=https://www.msx.org/wiki/SPRITE\$()]SPRITE\$()[/url]. There are two sprite modes, 8x8 and 16x16. They'll need 8 bytes or 32 bytes of data.

One byte of data is 8 pixels left to right. Bit 0 is the pixel on the right.

Small sprites require 8 bytes which will be top to bottom.
Large sprites require 32 bytes. First 16 will be left half top to bottom, next 16 will be right half top to bottom.

NYYRIKKI wrote:
wolf_ wrote:

I know it'd be bad practice, but do all these [graph]-images actually represent an ascii value, e.g. could you use these silly graphics (like the classic window frame, using [graph] [e], [r], [t], [d], [f], [g], [c], [v], [b]) to make a sprite strings?

Well... Yes, in theory... How ever in practise you won't end up with useful sprite data because in strings these window frame characters are encoded to 2 bytes where first byte is 1 and second byte is a capital letter... For example: PRINT CHR\$(1)+"U" ' == GRAPH + G

Sorry for hijacking, but I continue a bit more on this subject... In BASIC programs you can use a strings that have characters between 32 and 255 except for 127. If you want to make a program that you can only load and run (not write or LIST correctly) then you can bend the rules quite a bit more, but you still can't do everything with direct strings.

ページ 1/3
| 2 | 3