The nice thing is that it separates the data and the code a bit.

OMG... 2-dimensional arrays...

*TILT*

Wow!

[Edit] @manuel: Brings me to another question I didn't really dare to ask.

How do you know how much you have to "CLEAR"? (without overlapping the RAM used to store things)

With CLEAR you actually reserve RAM space to store those things. So overwriting is not possible in practice. You could get the occasional 'Out of memory' error when you've CLEAR'ed too little memory. Basically it's like this: count all variables you use, add to that all string lengths of the different string variables and that should give you a lower bound on the number of bytes you need to CLEAR.

I do agree that with two dimensional array the code is very much cleaner....
BUT
Is it equally faster ?

@manuel
I think that the code that accesses to two dimensional arrays is slower than multiple monodimensional arrays.

@demonseed
I vote for read/data/restore, but before moving to two dimensional arrays would do a bit of experiments on the speed differences.

Have there ever been MSX Basic programs that were made/designed in a sophisticated way? Like a procedural flow, data/visualization/implementation separated and another bunch o' design patterns? I got the impression that all those listings from the old magazines were a ridiculous pile o' spagetti-code that clearly wasn't intended to work on after 2 months of not watching it anymore.., nor did they have any intelligent solutions like simple compression schemes (e.g. RLE). Remember all those MCM game listings which had their map set up in strings? Oodles o' lines with: gaaaaaabigaaaaaaaaaaaagbbaafa afffaaaaagaaagbbaddaaaaade gabiiiiiiabaaaaaaaaabdeddaaaaaa just to define a screen etc.

@ D-Tail: A-ha! Thanks again!

@ ARTRAG: As of now, my "test results" point out that it is indeed slower!

@ wolf_

Quote:

Oodles o' lines with: gaaaaaabigaaaaaaaaaaaagbbaafa afffaaaaagaaagbbaddaaaaade gabiiiiiiabaaaaaaaaabdeddaaaaaa just to define a screen etc.

Yeah, like anyone knew better those days... Except for the really really brilliant people... *LOL*

Hey, we also got some schematics how to make a "jogging game" on MSX 1 with an actual guide to build your own mat to run/jump on which you could plug into your MSX joystick port!
Do you remember? Way ahead of its time! (still got the actual "MCM" featuring it I think...)

(let alone the "special home-made" gas/break pedals for, e.g. F-1 Spirit... Merely fire button detection)

Wait 'till the MRC Mega Challenge is due, and I'll hope to prove how powerful MSX (X) BASIC can be!

(As far as "No Name" from KAI Magazine hasn't done that already... Where there hell can I buy that game nowadays? )

I suppose that the BASIC interpreter uses the IX/IY registers for indexing integer arrays so the offset parameter can be easily used. That would explain the slower performance here. On the other hand, I'm very much in favor of using [albeit single-dimensional] arrays. E.g. usually my code looks like this:

10 COLOR 15,0,0: SCREEN 5: SET PAGE 0,1 BLOAD "GFX.GE5",S: COLOR = RESTORE
    ' And some more initialization crap
20 DEF INT P,V,E: DIM P(15), V(23) ' I declare the default NBASIC variable array P() w/ it's default length, 15.
    ' My own vars are stored in V(). Here I use 24 own vars.
30 CALL TURBO ON(P(), V()) ' Will do some additional speed-ups for my declared integer arrays
40 DIM F$(3) ' NBASIC String allocation, my own strings are in F$(2), F$(3).
    ' NBASIC treats F$(0) and F$(1) as special-purpose strings
50 P(0)=1: E=USR(0) ' Will call NBASIC function 0 w/ P(0)=1. 
    ' Fastest alternative 'cause E is a declared integer as well
60 ' Some random code here, e.g. start of a game engine loop
...
10010 F$(2) = INKEY$: IF F$(2) = "" GOTO 60 ' No keypress? Rerun loop
10020 ' some more conditions
...
10090 IF F$(2) = CHR$(27) GOTO 65500
10100 GOTO 60 ' Rerun loop again
10110 ' misc. routines start here
...
50000 ' And maybe some data lines here
...
65499 ' Ending routine
65500 CALL TURBO OFF
65510 COLOR 15,0,0: SCREEN 0: END

I'm not sure this code is 100% flawless, I kind of mocked it up at this instant. Normally I don't work in the BASIC interpreter, but use Compass as editor [neat program!] to edit source files which I compile using NPR. Then I go to BASIC, load/save the program again (so it loads faster the next time) and I test/run. And yes, I'm a bit embarrassed to tell that I use Compass solely for editing BASIC files

NPR? what is it?

ARTRAG: NPR is a BASIC pre-interpreter, which allows you to use line labels instead of line numbers (e.g. ON STRIG GOTO ~SPACE, ~JOY1BUT1, ~JOY1BUT2, ~JOY2BUT1, ~JOY2BUT2) and variable names [well, I misuse macros for that ] instead of BASIC variables. E.g.: @DEFINE TRUE -1: @DEFINE FALSE 0 and then IF @MYVAR <> @FALSE GOTO ~DO_SOMETHING. You jack the ASCII source code [can also be a SAVE,A'ed BASIC program!] through NPR and it spits out an ASCII file without spaces, remarks, and proper line numbering. Extremely useful tool for the advanced BASIC programmer.

Check out MCCW 93 for more info