Subject: arrays

From: Owen Brand <[email-masked]>
Date: Mon, 1 Mar 2010 13:23:57 -0500

*I'm working on some data access subroutines for my new game.  I need to set
up a couple arrays to start with, and so far, I've gotten as far as the XB
manual takes me.  Here's the XB example for DIM*
**
DIM X$(30) reserves space in the computer's memory for 31 numbers for the
array called X$.

>100 DIM X$(30) DIM D(100),B(10,9) reserves space in the computer's memory
for 101 members of the array called D and 110 ( 11 times 10) members of the
array called B.

>100 DIM D(100),B(10,9)

So to keep it simple, we'll do a 1 dimensional array containing 4 members

  10 CALL CLEAR
90 OPTION BASE 1
100 DIM X$(4)
120 X$(1)="BERYL" :: X$(2)="REPTO" :: X$(3)="SKYLAR" :: X$(4)="MARKUS"
400 DISPLAY AT(3,1):X$(1); :: DISPLAY AT(4,1):X$(2); :: DISPLAY
AT(5,1):X$(3); :: DISPLAY AT(6,1):X$(4);

This should display the names of the characters on subsequent lines starting
at Line #3 and ending with Line #6, correct?
For the sake of keeping this simple, I put all the info together... The
strings will be converted first into DATA lines and will eventually be
loaded from diskette... I just want to make sure I'm on the right track
here.  =)  If they're in DATA statements, a FOR NEXT loop can be used to
shorten line 120 using READ.  Any other suggestions for optimization, or
anything like that?  Sorry again if this is elementary--- I've never had to
use arrays before.
*Owen*

---

From: mark wills <[email-masked]>
Date: Mon, 1 Mar 2010 10:34:05 -0800 (PST)

Yep, that'll work!

>
>From: Owen Brand <[email-masked]>
>To: [email-masked]
>Sent: Mon, 1 March, 2010 18:23:57
>Subject: [TI994A] arrays
>
> >
>
>
>
> >
> >
>
>
>
>
>
>
>  
>I'm working on some data access subroutines for my new game.  I need to set up a couple arrays to start with, and so far, I've gotten as far as the XB manual takes me.  Here's the XB example for DIM
> 
>DIM X$(30) reserves space in the computer's memory for 31 numbers for the array called X$. 
>
>>100 DIM X$(30) DIM D(100),B(10,9) reserves space in the computer's memory for 101 members of the array called D and 110 ( 11 times 10) members of the array called B.
>
>>100 DIM D(100),B(10,9)
>
> 
> 
>400 DISPLAY AT(3,1):X$(1); :: DISPLAY AT(4,1):X$(2); :: DISPLAY AT(5,1):X$(3); :: DISPLAY AT(6,1):X$(4);
> 
>This should display the names of the characters on subsequent lines starting at Line #3 and ending with Line #6, correct?
>For the sake of keeping this simple, I put all the info together... The strings will be converted first into DATA lines and will eventually be loaded from diskette... I just want to make sure I'm on the right track here.  =)  If they're in DATA statements, a FOR NEXT loop can be used to shorten line 120 using READ.  Any other suggestions for optimization, or anything like that?  Sorry again if this is elementary--- I've never had to use arrays before.
>Owen
>
>
>

---

From: "Jon Vogel" <[email-masked]>
Date: Mon, 1 Mar 2010 12:53:45 -0600

Here's where you're heading, Owen:

90 OPTION BASE 1
100 DIM X$(4)
120 for i = 1 to 4::read x$(i)::next i

400 for i = 1 to 4:: DISPLAY AT(i+2,1):X$(i)::next i
500 data "Beryl", "Repto", "Skylar", "Markus"

Eventually to be followed by:

90 OPTION BASE 1
100 DIM X$(4)
110 open #1: "DSK1.MYDATA", input
120 for i = 1 to 4::input #1, x$(i)::next i
130 close #1
400 for i = 1 to 4:: DISPLAY AT(i+2,1):X$(i)::next i

To create the data file, you'd do:

90 OPTION BASE 1
100 DIM X$(4)
120 for i = 1 to 4::read $(i)::next i
130 open #1: "DSK1.MYDATA", output
140 for i = 1 to 4::print #1, X$(i)::next i
150 close #1
400 for i = 1 to 4:: DISPLAY AT(i+2,1):X$(i)::next i
500 data "Beryl", "Repto", "Skylar", "Markus"

Hope this helps.

Regards,

JonV

  ----- Original Message ----- 
  From: Owen Brand 
  To: [email-masked] 
  Sent: Monday, March 01, 2010 12:23 PM
  Subject: [TI994A] arrays

   10 CALL CLEAR
  90 OPTION BASE 1
  100 DIM X$(4)

---

From: mark wills <[email-masked]>
Date: Mon, 1 Mar 2010 10:53:32 -0800 (PST)

to do it with DATA:

10 restore 70
20 dim x$(4)
30 for i=1 to 4
40 read x$(i)
50 next i
60 for i=1 to 4 :: display at(i,1):x$(i) :: next i
70 data beryl,repto,skylar,markus

>
>From: mark wills <[email-masked]>
>Sent: Mon, 1 March, 2010 18:34:05
>Subject: Re: [TI994A] arrays
>
> >
>
>
>
> >
>
>
>
>
>
>
>Yep, that'll work!
>
>
>>

---

From: Owen Brand <[email-masked]>
Date: Mon, 1 Mar 2010 14:36:28 -0500

Thanks Willsy... This will be the intermediate step between what I  
currently have and the DSK access Jon described.  I'm trying to do  
this progressively and step by step so that I am completely familiar  
with all the steps and know precisely how I'm loading the data info.   
The better I can understand the processes in the simple forms, the  
better equipped I will be for the whole big enchillada when I get to  
it. :)

Owen Brand
Opry99er.com

On Mar 1, 2010, at 1:53 PM, mark wills <[email-masked]>  
wrote:

> I'm working on some data access subroutines for my new game.  I need  
> to set up a couple arrays to start with, and so far, I've gotten as  
> far as the XB manual takes me.  Here's the XB example for DIM
>
> >100 DIM X$(30) DIM D(100),B(10,9) reserves space in the computer's  
> memory for 101 members of the array called D and 110 ( 11 times 10)  
> members of the array called B.
>
> >100 DIM D(100),B(10,9)
>
>
> This should display the names of the characters on subsequent lines  
> starting at Line #3 and ending with Line #6, correct?
> For the sake of keeping this simple, I put all the info together...  
> The strings will be converted first into DATA lines and will  
> eventually be loaded from diskette... I just want to make sure I'm  
> on the right track here.  =)  If they're in DATA statements, a FOR  
> NEXT loop can be used to shorten line 120 using READ.  Any other  
> suggestions for optimization, or anything like that?  Sorry again if  
> this is elementary--- I've never had to use arrays before.
> Owen
>
>
>
>
>

---

From: Owen Brand <[email-masked]>
Date: Mon, 1 Mar 2010 14:12:44 -0500

Yes that is most certainly useful, thank you!  I am trying to get all  
this stuff together-- I will be needing to use a few 2 dimensional  
arrays as well--- but Im not 100% sure where to go from here on that.   
I will certainly be coming to this group more as my needs arise on  
this game. It's certainly alot more involved than anything I've tried  
thus far.  Thanks again, Jon!!  :)

Owen Brand
Opry99er.com

---

From: "Matthew" <[email-masked]>
Date: Mon, 01 Mar 2010 20:00:53 -0000

Do it this way.  I like DATA statements and I hate them too.  The problem with them is that you can not change the data.

My problem with the other solution, i.e. loading the strings from DATA statements into arrays, is that you are now doubling your memory use.  The XB program has to store the DATA, and at run time you are proposing to copy that data again in to a string variable.

Mark's solution below keeps the string data in one place.

If you are loading from disk, then so be it, load into arrays.  But never load from DATA statements into arrays, that just wastes precious memory.

Matthew

--- In [email-masked], mark wills <markrobertwills@...> wrote:
> >From: mark wills <markrobertwills@...>
> >>From: Owen Brand <owenbrand@...>

---

From: mark wills <[email-masked]>
Date: Mon, 1 Mar 2010 12:26:23 -0800 (PST)

Good point.

I think is a little nervous about file IO in XB, and is over estimating it's complexity! In fact, as we all know, it's very simple and quite user friendly, not to mention a good deal more powerful than other contemporary systems.

Our Owen will be kicking himself soon when he get's into disk access :-)

Now, ASSEMBLY DISK IO... Yeah, I don't like that too much... A bit 'messy' for my taste...

----- Original Message ----
> From: Matthew <[email-masked]>
> Sent: Mon, 1 March, 2010 20:00:53
> Subject: [TI994A] Re: arrays
> 
> Do it this way.  I like DATA statements and I hate them too.  The problem with 
> them is that you can not change the data.
> 
> My problem with the other solution, i.e. loading the strings from DATA 
> statements into arrays, is that you are now doubling your memory use.  The XB 
> program has to store the DATA, and at run time you are proposing to copy that 
> data again in to a string variable.
> 
> If you are loading from disk, then so be it, load into arrays.  But never load 
> from DATA statements into arrays, that just wastes precious memory.
> 
> Matthew
> 
> --- In [email-masked], mark wills wrote:
> >
> > to do it with DATA:
> > 
> > 10 restore 70
> > 20 dim x$(4)
> > 30 for i=1 to 4
> > 40 read x$(i)
> > 50 next i
> > >From: mark wills 
> > >>I'm working on some data access subroutines for my new game.  I need to set 
> manual takes me.  Here's the XB example for DIM
> > >> 
> strings will be converted first into DATA lines and will eventually be loaded 
> from diskette... I just want to make sure I'm on the right track here.  =)  If 
> they're in DATA statements, a FOR NEXT loop can be used to shorten line 120 
> using READ.  Any other suggestions for optimization, or anything like that?  
> Sorry again if this is elementary--- I've never had to use arrays before.
> > >>Owen
> > >>
> > >>
> > >
> > >
> > >
> >
> 
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>

---

From: Owen Brand <[email-masked]>
Date: Mon, 1 Mar 2010 15:34:05 -0500

Heh....  Yea--- it just seems like quite a bit to grasp all at  
once....  Reading and writing data to and from disk, record lengths,  
fixed or not---update vs. Read--- it's like learning a new position in  
baseball.... Sure you know how to play baseball, but playing shortstop  
requires a different skillset than, say, catcher.  :)

Owen Brand
Opry99er.com

On Mar 1, 2010, at 3:26 PM, mark wills <[email-masked]>  
wrote:

> Good point.
>
> I think is a little nervous about file IO in XB, and is over  
> estimating it's complexity! In fact, as we all know, it's very  
> simple and quite user friendly, not to mention a good deal more  
> powerful than other contemporary systems.
>

---

From: "Jon Vogel" <[email-masked]>
Date: Mon, 1 Mar 2010 14:11:54 -0600

It's unfortunate that XB doesn't allow a more structured approach to data handling, like, say QuickBasic or C does.  Keeping track of things will be harder with XB because you will have to have a separate array for everything.  For example, to define a monster, with name, number of attacks, damage per attack and number of hit points, you need 4 separate arrays:

dim m_name$(num_of_monsters)
dim m_num_attacks(num_of_monsters)
dim m_damage_per_attack(num_of_monsters)
dim m_hit_points(num_of_monsters)

And, of course, because of the memory contraints for variable names, it will probably end up being a bunch of arrays with really cryptic names:

dim mname$(nom)
dim mna(nom)
dim mdpa(nom)
dim mhp(nom)

A more structured language would make tracking all this data easier.  Take the time to plan your game out on paper and figure out ahead of time exactly what data you will need and how to store it.  That will save you a lot of headaches later.

Regards,

JonV

  ----- Original Message ----- 
  From: Owen Brand 
  To: [email-masked] 
  Sent: Monday, March 01, 2010 1:12 PM
  Subject: Re: [TI994A] arrays

  Yes that is most certainly useful, thank you!  I am trying to get all this stuff together-- I will be needing to use a few 2 dimensional arrays as well--- but Im not 100% sure where to go from here on that.  I will certainly be coming to this group more as my needs arise on this game. It's certainly alot more involved than anything I've tried thus far.  Thanks again, Jon!!  :)

  Owen Brand
  Opry99er.com

---

From: mark wills <[email-masked]>
Date: Mon, 1 Mar 2010 12:47:17 -0800 (PST)

>it's like learning a new position in baseball.... Sure you know how to
play baseball, but playing shortstop requires a different skillset
than, say, catcher.  :)

Nope. Sorry. You've completely lost me there :-)

Shortstop? Catcher?

Nope... 

Er.... hello?

;-)

>To: "[email-masked]" <[email-masked]>
>Sent: Mon, 1 March, 2010 20:34:05
>Subject: Re: [TI994A] Re: arrays
>
> >
>
>
>
> >
>
>
>
>
>
>
>Heh....  Yea--- it just seems like quite a bit to grasp all at once....  Reading and writing data to and from disk, record lengths, fixed or not---update vs. Read--- it's like learning a new position in baseball.... Sure you know how to play baseball, but playing shortstop requires a different skillset than, say, catcher.  :)
>
>Owen Brand
>Opry99er.com
>
>On Mar 1, 2010, at 3:26 PM, mark wills <[email-masked]> wrote:
>
>
>>>
>>
>>
>>  >>
>>
>> 
>>>>      
>> 
>>Good point.
>>
>>>>> From: Matthew <matthew@mundomateo. com>
>>>>> To: TI994A@yahoogroups. com
>>>>> --- In TI994A@yahoogroups. com, mark wills wrote:
>>>>> >
>>>>> > to do it with DATA:
>>>>> > 
>>>>> > 10 restore 70
>>>>> > 20 dim x$(4)
>>>>> > 30 for i=1 to 4
>>>>> > 40 read x$(i)
>>>>> > 50 next i
>>>>> > 70 data beryl,repto, skylar,markus
>>>>> > 
>>>>> > 
>>>>> > 
>>>>> > 
>>>>> > >
>>>>> > >From: mark wills 
>>>>> > >To: TI994A@yahoogroups. com
>>>>> > >>To: TI994A@yahoogroups. com
>>>>> > >>>100 DIM X$(30) DIM D(100),B(10, 9) reserves space in the computer's memory 
>>>>> > >>>100 DIM D(100),B(10, 9)
>>>>> > >>400 DISPLAY AT(3,1):X$(1) ; :: DISPLAY AT(4,1):X$(2) ; :: DISPLAY 
>>>>> AT(5,1):X$(3) ; :: DISPLAY AT(6,1):X$(4) ;
>>>>> > >> 
>>>>> Sorry again if this is elementary-- - I've never had to use arrays before.
>>>>> > >>Owen
>>>>> > >>
>>>>> > >>
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> >
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ------------ --------- --------- ------
>>>>> 
>>>>> Yahoo! Groups Links
>>>>> 
>>>>> 
>>>>> 
>>
>
>
>

---

From: Owen Brand <[email-masked]>
Date: Mon, 1 Mar 2010 15:58:09 -0500

I've been doing that pretty extensively.  Check out my blog, Jon.. If  
you'd like to.  http://www.opry99er.com/the-legend-of-beryl-reichardt-crpg.php

I've also been working with Matthew and a few others over on Atariage,  
where I have several screenshots mocked up.  It's been a true teat of  
patience and tolerance not just jumping directly into code---a habit  
of mine... I've really been focused on developing every shred of the  
game before I start hammering down on it---coding-wise.  Here's the  
link to the Atariage forum that houses the conversation on the  
game.    http://www.atariage.com/forums/topic/157664-the-legend-of-beryl-reichardt/

Thanks for your suggestions and support my friend. :)

Owen Brand
Opry99er.com

On Mar 1, 2010, at 3:11 PM, "Jon Vogel" <[email-masked]> wrote:

> 
>
> It's unfortunate that XB doesn't allow a more structured approach to  
> data handling, like, say QuickBasic or C does.  Keeping track of  
> things will be harder with XB because you will have to have a  
> separate array for everything.  For example, to define a monster,  
> with name, number of attacks, damage per attack and number of hit  
> points, you need 4 separate arrays:
>
> And, of course, because of the memory contraints for variable names,  
> it will probably end up being a bunch of arrays with really cryptic  
> names:
>
> dim mname$(nom)
> dim mna(nom)
> dim mdpa(nom)
> dim mhp(nom)
>
> A more structured language would make tracking all this data  
> easier.  Take the time to plan your game out on paper and figure out  
> ahead of time exactly what data you will need and how to store it.   
> That will save you a lot of headaches later.
>
> Regards,
>
> JonV
>
> Yes that is most certainly useful, thank you!  I am trying to get  
> all this stuff together-- I will be needing to use a few 2  
> dimensional arrays as well--- but Im not 100% sure where to go from  
> here on that.  I will certainly be coming to this group more as my  
> needs arise on this game. It's certainly alot more involved than  
> anything I've tried thus far.  Thanks again, Jon!!  :)
>
> Owen Brand
> Opry99er.com
>
>

---

From: Owen Brand <[email-masked]>
Date: Mon, 1 Mar 2010 15:59:29 -0500

I meant "test", not teat...  But that's funnier

Owen Brand
Opry99er.com

On Mar 1, 2010, at 3:58 PM, Owen Brand <[email-masked]> wrote:

> I've been doing that pretty extensively.  Check out my blog, Jon..  
> If you'd like to.  http://www.opry99er.com/the-legend-of-beryl-reichardt-crpg.php
>
> I've also been working with Matthew and a few others over on  
> Atariage, where I have several screenshots mocked up.  It's been a  
> true teat of patience and tolerance not just jumping directly into  
> code---a habit of mine... I've really been focused on developing  
> every shred of the game before I start hammering down on it---coding- 
> wise.  Here's the link to the Atariage forum that houses the  
> conversation on the game.    http://www.atariage.com/forums/topic/157664-the-legend-of-beryl-reichardt/
>
>> It's unfortunate that XB doesn't allow a more structured approach  
>> to data handling, like, say QuickBasic or C does.  Keeping track of  
>> And, of course, because of the memory contraints for variable  
>> names, it will probably end up being a bunch of arrays with really  
>> cryptic names:
>>
>> dim mname$(nom)
>> dim mna(nom)
>> dim mdpa(nom)
>> dim mhp(nom)
>>
>> easier.  Take the time to plan your game out on paper and figure  
>> out ahead of time exactly what data you will need and how to store  
>> it.  That will save you a lot of headaches later.
>>
>> Regards,
>>
>> JonV
>>

---

From: Owen Brand <[email-masked]>
Date: Mon, 1 Mar 2010 15:52:52 -0500

It's like playing cricket... Try being a wicket and you'll see what I  
mean.  :)

Owen Brand
Opry99er.com

On Mar 1, 2010, at 3:47 PM, mark wills <[email-masked]>  
wrote:

> >it's like learning a new position in baseball.... Sure you know how  
> to play baseball, but playing shortstop requires a different  
> skillset than, say, catcher.  :)
>
> fixed or not---update vs. Read--- it's like learning a new position  
> in baseball.... Sure you know how to play baseball, but playing  
> shortstop requires a different skillset than, say, catcher.  :)
>
> Owen Brand
> Opry99er.com
>

---

From: mark wills <[email-masked]>
Date: Mon, 1 Mar 2010 12:58:59 -0800 (PST)

For a lot of things, VARIABLE length records are fine. It simply means that each record has a variable length:

OWEN
BRAND
TEXAS
INSTRUMENTS

The length of these records is 4 5 5 and 11

However, variable length records have a restriction: You can use them for RELATIVE access.

RELATIVE access is simply a posh word for random access. Consider this code:

10 A$(1)="OWEN"
20 A$(2)="MARK"
30 A$(3)="FRED"
40 A$(4)="JOHN"

We can select any 'record' from our array by simply stating the index:

PRINT A$(2)
MARK

Well, guess what... We can do EXACTLY the same thing with data on a disk. Only, you don't have to read the data into memory and store it in an array... This disk file *IS* the array!

Does it do this? Well, by using FIXED length records, when you specify a record number, the computer has to multiply the record number you give it, by the record length. So, using the example above, the record length is 4. So, if I want the 4th record, the computer does 4*4 and gets the answer 16. So it knows that record 4 begins at by byte 16 in the disk file, and continues for 4 bytes.

This is known in some programming parlances as a packed array. It is an array of data, but there is no character seperating the records (unlike a VARIABLE record, which uses CHR$(13) to seperate records). By having the length of every record the same, it is easy to calculate the location of the data on the disk.

This could be useful in your game: You could have a 'rooms' disk file, which describes the room data for every room (or location). Another file, called MAP could store record numbers for the locations in the rooms file. As you move around the map, you read the location from the map file, and that tells you which record to read in the rooms file, then you can load the room data and display it. That way, you can have many many rooms (because they are on disk).

Hope this makes sense ;-)

M

---

From: Owen Brand <[email-masked]>
Date: Mon, 1 Mar 2010 16:44:59 -0500

Excellent!!

I talk a little bit about this subject in my blog... The idea is to  
create a parsing method like such:

F130510

Break this up first

F1 30 5 10

This string represents a skeleton in the forest world who has a max HP  
of 30 and has the "firebreath" magic who (once killed) will drop 10  
gold.

F=forest world ID code
1=monster ID#
30=Max HP
5=magic ID#
10=gold dropped once killed

So what if a monster is only dropping 5 gold?
F130505

This way the identifiers for specific monsters and placements are  
"identifiable" and of a fixed length.  :).

This feeds right into what you're talking about Mark... I now have a  
better understanding of how to apply it to disk... Just need to create  
the parsing program to access the fixed records properly.

Owen Brand
Opry99er.com

On Mar 1, 2010, at 3:58 PM, mark wills <[email-masked]>  
wrote:

> For a lot of things, VARIABLE length records are fine. It simply  
> means that each record has a variable length:
>
> OWEN
> BRAND
> TEXAS
> INSTRUMENTS
>
> Well, guess what... We can do EXACTLY the same thing with data on a  
> disk. Only, you don't have to read the data into memory and store it  
> in an array... This disk file *IS* the array!
>
> Does it do this? Well, by using FIXED length records, when you  
> specify a record number, the computer has to multiply the record  
> number you give it, by the record length. So, using the example  
> above, the record length is 4. So, if I want the 4th record, the  
> computer does 4*4 and gets the answer 16. So it knows that record 4  
> begins at by byte 16 in the disk file, and continues for 4 bytes.
>
> This is known in some programming parlances as a packed array. It is  
> an array of data, but there is no character seperating the records  
> (unlike a VARIABLE record, which uses CHR$(13) to seperate records).  
> By having the length of every record the same, it is easy to  
> calculate the location of the data on the disk.
>
> This could be useful in your game: You could have a 'rooms' disk  
> file, which describes the room data for every room (or location).  
> Another file, called MAP could store record numbers for the  
> locations in the rooms file. As you move around the map, you read  
> the location from the map file, and that tells you which record to  
> read in the rooms file, then you can load the room data and display  
> it. That way, you can have many many rooms (because they are on disk).
>

---

From: fdos <[email-masked]>
Date: Mon, 01 Mar 2010 16:07:55 -0700

Owen,

Your data i/o requirements are ideal for X4th99 virtual memory.

In the mean time one of your AL participants could provide you with a 
couple of subprograms via CALL LINK() named "SAVE" & "LOAD" requiring a 
VDP address and byte count allowing a full screen and/or text/character 
graphic and/or Sprite definitions and/or Sprite attributes and/or color 
table to be saved/loaded to/from floppy/hard/ram disk.

Just create separate maintenance XB programs to create individual 
screens with colored text, graphics, sprites with motion attributes, 
etc., test, debug, stop all sprite motion and save.  Maybe you have to 
make multiple maintenance programs or because the screen remains the 
same and you only need to change the colors or just sprite motion 
changes or characters change or sprite definitions change.  You'll be 
surprised by how much faster SAVE & LOAD are as compared to record i/o.

You will probably need a master file of filenames, and then your program 
decides under what conditions a full screen (which one) gets loaded or 
just color changes and/or just sprite attributes, etc.  This means 
screen layout, character/sprite definitions, sprite attributes, 
text/character/sprite colors are never stored in CPU memory as they are 
directly loaded into VDP memory where they are actually used.

Your maintenance programs are never distributed, but think how easy it 
will be to update screens.

Bill S

Owen Brand wrote:
> of 30 and has the "firebreath" magic who (once killed) will drop 10 gold.
> 
> F=forest world ID code
> 1=monster ID#
> 30=Max HP
> 5=magic ID#
> better understanding of how to apply it to disk... Just need to create t 
> he parsing program to access the fixed records properly.
> 
> Owen Brand
> Opry99er.com <http://Opry99er.com>
> 
> On Mar 1, 2010, at 3:58 PM, mark wills <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>>  
>>
>> Does it do this? Well, by using FIXED length records, when you specify 
>> a record number, the computer has to multiply the record number you 
>> give it, by the record length. So, using the example above, the record 
>> length is 4. So, if I want the 4th record, the computer does 4*4 and 
>> gets the answer 16. So it knows that record 4 begins at by byte 16 in 
>> the disk file, and continues for 4 bytes.
>>
>> By having the length of every record the same, it is easy to calculate 
>> the location of the data on the disk.
>>
>> This could be useful in your game: You could have a 'rooms' disk file, 
>> which describes the room data for every room (or location). Another 
>> file, called MAP could store record numbers for the locations in the 
>> rooms file. As you move around the map, you read the location from the 
>> map file, and that tells you which record to read in the rooms file, 
>> then you can load the room data and display it. That way, you can have 
>> many many rooms (because they are on disk).
>>
>>     *From:* Owen Brand <[email-masked]>
>>     *To:* "[email-masked]" <[email-masked]>
>>     *Sent:* Mon, 1 March, 2010 20:34:05
>>     *Subject:* Re: [TI994A] Re: arrays
>>
>>
>>
>>     once....  Reading and writing data to and from disk, record
>>     lengths, fixed or not---update vs. Read--- it's like learning a
>>     new position in baseball.... Sure you know how to play baseball,
>>     but playing shortstop requires a different skillset than, say,
>>     catcher.  :)
>>
>>     Owen Brand
>>     <http://Opry99er.com>Opry99er.com <http://Opry99er.com>
>>
>>     On Mar 1, 2010, at 3:26 PM, mark wills
>>     <[email-masked] <mailto:[email-masked]>>
>>     wrote:
>>
>>>      
>>>
>>>     Good point.
>>>
>>>     > From: Matthew <matthew@mundomateo. com
>>>     <mailto:matthew%40mundomateo.com>>
>>>     > To: TI994A@yahoogroups. com <mailto:TI994A%40yahoogroups.com>
>>>     > --- In TI994A@yahoogroups. com
>>>     <mailto:TI994A%40yahoogroups.com>, mark wills wrote:
>>>     > >
>>>     > > to do it with DATA:
>>>     > >
>>>     > > 10 restore 70
>>>     > > 20 dim x$(4)
>>>     > > 30 for i=1 to 4
>>>     > > 40 read x$(i)
>>>     > > 50 next i
>>>     > > >To: TI994A@yahoogroups. com <mailto:TI994A%40yahoogroups.com>
>>>     > > >>To: TI994A@yahoogroups. com <mailto:TI994A%40yahoogroups.com>

---

From: Owen Brand <[email-masked]>
Date: Mon, 1 Mar 2010 19:07:22 -0500

Bill, thank you very much!  I may do an X4th99 conversion of this game later
on down the line, when it is finished and more readily available!  =)  I've
had some success--- got records to print into a new file and then got them
to input into another program.  =)  Here are the two programs::

 This prints these names to my file::

10 CALL CLEAR
90 OPTION BASE 1
100 DIM X$(4)
120 X$(1)="BERYL" :: X$(2)="REPTO" :: X$(3)="SKYLAR" :: X$(4)="MARKUS"
400 OPEN #1:"DSK1.NAMES",OUTPUT
410 FOR I=1 TO 4 :: PRINT #1:X$(I) :: NEXT I
420 CLOSE #1

This program inputs them to my screen and prints them =)

100 CALL CLEAR
110 OPTION BASE 1
120 DIM X$(4)
130 OPEN #1:"DSK1.NAMES",INPUT
140 FOR I=1 TO 4 :: INPUT #1:X$(I) :: NEXT I
150 CLOSE #1
160 FOR I=1 TO 4 :: DISPLAY AT(I+3,1):X$(I) :: NEXT I

Having so much fun now!!!

Willsy has agreed to take my graphics for screens and such and help convert
them to assembly already... CALL LOAD, CALL LINK implementation.  Sick minds
think alike.  =)  Thanks for your interest and input, Bill.  This is about
as much fun I've had with the TI since Lemonade Stand.  =)

Owen

On Mon, Mar 1, 2010 at 6:07 PM, fdos <[email-masked]> wrote:

> >>>     <mailto:matthew%40mundomateo.com <matthew%2540mundomateo.com>>>
> >>>     > To: TI994A@yahoogroups. com <mailto:TI994A%40yahoogroups.com<TI994A%2540yahoogroups.com>
> >
> >>>     <mailto:TI994A%40yahoogroups.com <TI994A%2540yahoogroups.com>>,
> mark wills wrote:
> >>>     > >
> >>>     > > to do it with DATA:
> >>>     > >
> >>>     > > 10 restore 70
> >>>     > > 20 dim x$(4)
> >>>     > > 30 for i=1 to 4
> >>>     > > 40 read x$(i)
> >>>     > > 50 next i
> >>>     > > >To: TI994A@yahoogroups. com <mailto:TI994A%40yahoogroups.com<TI994A%2540yahoogroups.com>
> >
> >>>     > > >>To: TI994A@yahoogroups. com <mailto:TI994A%40yahoogroups.com<TI994A%2540yahoogroups.com>
> >

---

From: fdos <[email-masked]>
Date: Mon, 01 Mar 2010 17:21:12 -0700

Owen,

You're very welcome.  Just don't over look the XB plan as it is very 
simple to implement, and sub-divides your tasks in a natural way with 
all the screen and graphics and sprites done by maintenance programs not 
included with the actual distributed program.  Only the binary data 
files created by the maintenance program(s) are included on the 
distribution disks.

Bill S

Owen Brand wrote:
>  
> 
> Bill, thank you very much!  I may do an X4th99 conversion of this game 
> later on down the line, when it is finished and more readily available!  
> =)  I've had some success--- got records to print into a new file and 
> then got them to input into another program.  =)  Here are the two 
> programs::
>  
> Willsy has agreed to take my graphics for screens and such and help 
> convert them to assembly already... CALL LOAD, CALL LINK 
> implementation.  Sick minds think alike.  =)  Thanks for your interest 
> and input, Bill.  This is about as much fun I've had with the TI since 
> Lemonade Stand.  =)
>  
> Owen
> 
> 
> 
>  
> On Mon, Mar 1, 2010 at 6:07 PM, fdos <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Owen,
> 
>      > On Mar 1, 2010, at 3:58 PM, mark wills
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >>
>      >>
>      >> However, variable length records have a restriction: You can use
>     them
>      >> for RELATIVE access.
>      >>
>      >> RELATIVE access is simply a posh word for random access.
>     Consider this
>      >> code:
>      >>
>      >> 10 A$(1)="OWEN"
>      >> 20 A$(2)="MARK"
>      >> 30 A$(3)="FRED"
>      >> 40 A$(4)="JOHN"
>      >>
>     specify
>     file,
>      >>     *From:* Owen Brand <[email-masked]
>     <mailto:[email-masked]>>
>      >>     *To:* "[email-masked]
>     <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>      >>     <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >>     wrote:
>      >>
>      >>>
>      >>>
>      >>>     Good point.
>      >>>
>      >>>     <mailto:matthew%40mundomateo.com
>     <mailto:matthew%2540mundomateo.com>>>
>     <mailto:TI994A%40yahoogroups.com <mailto:TI994A%2540yahoogroups.com>>
>      >>>     > Do it this way. I like DATA statements and I hate them
>     too. The
>      >>>     problem with
>      >>>     > If you are loading from disk, then so be it, load into
>     arrays.
>      >>>     But never load
>      >>>     <mailto:TI994A%40yahoogroups.com
>     <mailto:TI994A%2540yahoogroups.com>>, mark wills wrote:
>      >>>     > >
>      >>>     > > to do it with DATA:
>      >>>     > >
>      >>>     > > 10 restore 70
>      >>>     > > 20 dim x$(4)
>      >>>     > > 30 for i=1 to 4
>      >>>     > > 40 read x$(i)
>      >>>     > > 50 next i
>     <mailto:TI994A%40yahoogroups.com <mailto:TI994A%2540yahoogroups.com>>
>     <mailto:TI994A%40yahoogroups.com <mailto:TI994A%2540yahoogroups.com>>
>      >>>     > using READ. Any other suggestions for optimization, or
>     anything
>      >>>     like that?
>        (Yahoo! ID required)
>     <mailto:[email-masked]>
> 
> 
> 
>

---

From: Owen Brand <[email-masked]>
Date: Mon, 1 Mar 2010 19:25:50 -0500

Bill, I'm curious what exactly you mean by "maintenance programs."  
Perhaps I'm just not familiar with your terminology.  By this, are you  
referring to the examples I laid out in the previous message?

Owen Brand
Opry99er.com

---

From: Owen Brand <[email-masked]>
Date: Mon, 1 Mar 2010 19:31:49 -0500

And by "screens" and such in assembly, I am merely talking about  
graphics for battle sequences and such.  As this will be an RPG, there  
will be many screens to visit and such.... That's primarily what I was  
meaning by that.   :)

Owen Brand
Opry99er.com

---

From: Owen Brand <[email-masked]>
Date: Mon, 1 Mar 2010 19:33:01 -0500

I used "and such" about 300 times in that last email.  I need to read  
more books

Owen Brand
Opry99er.com

On Mar 1, 2010, at 7:31 PM, Owen Brand <[email-masked]> wrote:

> graphics for battle sequences and such.  As this will be an RPG,  
> there will be many screens to visit and such.... That's primarily  
> what I was meaning by that.   :)
>
> Owen Brand
> Opry99er.com
>

---

From: fdos <[email-masked]>
Date: Mon, 01 Mar 2010 18:55:38 -0700

Owen,

No.  I'm talking about stand-alone programs that create and maintain all 
aspects of full screens, text, graphics and sprites associated with one 
or more screens.  They (the screens) and any part thereof, and only the 
binary data files are used by the actual program that is distributed to 
users.  They have no need for these creation/maintenance programs.

Your program will CALL LINK("LOAD", FILENAME$, VDPADRESS, BYTECOUNT) 
these binary data files as the actual program requires them (a file of 
filenames will allow easy addition of more screens and other data). 
You, the programmer know when each of the screens are required by the 
program along with all the other described data.  Although screen 
affiliation could be provided in other data files to provide even more 
flexibility.  Right now I'm trying to keep this operation simple, but 
extremely flexibility.

Bill S

Owen Brand wrote:
> On Mar 1, 2010, at 7:21 PM, fdos <[email-masked] 
> <mailto:fdosbrs%40frontiernet.net>> wrote:
> 
>  > Owen,
>  >
> <mailto:fdosbrs%40frontiernet.net>
>  >> <mailto:[email-masked] <mailto:fdosbrs%40frontiernet.net>>> 
> wrote:
>  >>
>  >> Owen,
>  >>
>  >>> Opry99er.com <http://Opry99er.com <http://Opry99er.com>>
>  >>>
>  >> <[email-masked] <mailto:markrobertwills%40yahoo.co.uk> 
> <mailto:[email-masked] <mailto:markrobertwills%40yahoo.co.uk>>
> <mailto:markrobertwills%40yahoo.co.uk>
> <mailto:markrobertwills%40yahoo.co.uk>>>> wrote:
>  >>>
>  >>>>
>  >>>>
> <mailto:owenbrand%40opry99er.com>
>  >> <mailto:[email-masked] <mailto:owenbrand%40opry99er.com>>>
>  >>>> *To:* "[email-masked] <mailto:TI994A%40yahoogroups.com>
>  >> <mailto:[email-masked] <mailto:TI994A%40yahoogroups.com>>" 
> <[email-masked] <mailto:TI994A%40yahoogroups.com>
>  >> <mailto:[email-masked] <mailto:TI994A%40yahoogroups.com>>>
>  >>>> <http://Opry99er.com <http://Opry99er.com>>Opry99er.com 
> <http://Opry99er.com <http://Opry99er.com>>
>  >>>>
>  >>>> <[email-masked] <mailto:markrobertwills%40yahoo.co.uk>
> <mailto:markrobertwills%40yahoo.co.uk>>
> <mailto:markrobertwills%40yahoo.co.uk>
> <mailto:markrobertwills%40yahoo.co.uk>>>>
>  >>>> wrote:
>  >>>>
>  >>>>>
>  >>>>>
>  >>>>> Good point.
>  >>>>>
>  >> <mailto:[email-masked] 
> <mailto:TI994A-fullfeatured%40yahoogroups.com>>
>  >>
>  >>
>  >>
>  >>
>  >
>  >

---

From: Owen Brand <[email-masked]>
Date: Mon, 1 Mar 2010 21:07:45 -0500

Ahhh--- so you're referring to (basically) object code put out by  
source assembly.... That might not be  LITERALLY what you're saying,  
but a similar kind of thing--- wherein you do not have to include the  
source in with the disk, but the object is there for use.  ;). I did  
something similar with Honeycomb Rapture--- for the music.  And also  
with Lemonade Stand, but I included the source in with my diskette for  
the assbly subroutines.  BTW Bill, I need to get you a copy of  
Honeycomb to play--- do you have Lemonade Stand or not?

Owen Brand
Opry99er.com

---

From: fdos <[email-masked]>
Date: Mon, 01 Mar 2010 20:42:08 -0700

No Lemonade Stand as my grandkids can't decide who will be the boss. :-)

The biggie with the VDP binary load is absolutely no pass through CPU 
memory, no arrays, no data statements, no loops to load data; only a 
simple CALL LINK() for a full screen completely setup and ready for 
action, and thereafter just pieces (text, graphics, sprite motion or 
redef or color changes) as required by the action of moving to a new 
room or a zombie attack or whatever. :-)

Nothing but fun, fun, fun.

Bill S

Owen Brand wrote:
> On Mar 1, 2010, at 8:55 PM, fdos <[email-masked] 
>  >>>> <mailto:[email-masked] <mailto:fdosbrs%40frontiernet.net> 
> <mailto:fdosbrs
>  >>>> %40frontiernet.net>>>
>  >> wrote:
>  >>>>
>  >>>> Owen,
>  >>>>
>  >>>>> Opry99er.com <http://Opry99er.com <http://Opry99er.com> 
> <http://Opry99er.com <http://Opry99er.com>>>
>  >>>>>
> <mailto:markrobertwills%40yahoo.co.uk> <mailto:markrobertwills
>  >> %40yahoo.co.uk>>
>  >>>> <mailto:[email-masked] <mailto:owenbrand%40opry99er.com> 
> <mailto:owenbrand%40opry99er.com>>>
> <mailto:TI994A%40yahoogroups.com>
>  >>>> <mailto:[email-masked] <mailto:TI994A%40yahoogroups.com> 
> <mailto:TI994A%40yahoogroups.com>>"
> <mailto:TI994A%40yahoogroups.com>
>  >>>> <mailto:[email-masked] <mailto:TI994A%40yahoogroups.com> 
> <mailto:TI994A%40yahoogroups.com>>>
>  >>>>>> <http://Opry99er.com <http://Opry99er.com> <http://Opry99er.com 
> <http://Opry99er.com>>>Opry99er.com
>  >> <http://Opry99er.com <http://Opry99er.com> <http://Opry99er.com 
> <http://Opry99er.com>>>
>  >>>>>>
> <mailto:markrobertwills%40yahoo.co.uk> <mailto:markrobertwills
>  >>>>>> %40yahoo.co.uk>
> <mailto:TI994A-fullfeatured%40yahoogroups.com>