found a potentially usable basic spreadsheet program for the 600xl...but not written in Atari basic

[Geister]

Or possibly, you could buy this 64k memory upgrade and get a Microsoft Basic cartridge so that you would get compatible string handling.  Even so, there would be more compatibility issues to deal with.  Why not just use the 64K upgrade and pick on of the many good spreadsheets available for the Atari. 

 

https://www.tindie.com/search/?q=atari+600xl+external+memory

 

Unless you are just doing the conversion for a mental exercise.

[reifsnyderb]

An option is to use Altirra to get the program running on 64k then see what can be cut out to try to get it to run on 16k.

[newTIboyRob]

 

 

 

Just when I was ready to give up, you guys have given me food for thought. Thanks for all the comments, much appreciated. In this last batch of responses, let's zero in on the 3 I quoted, since they are very much related, and also kind of where I had been thinking myself before my last giving up altogether post:

 

1 hour ago, reifsnyderb said:

An option is to use Altirra to get the program running on 64k then see what can be cut out to try to get it to run on 16k.

 

For the above, I went to the Altirra site and saw all those links to download. I first tried to find anything on the page with 16 K mentioned, but it showed  Acid 800... so in short, I wouldn't know which of those other links to try to get Altirra.  In short, honestly if someone would do the courtesy loading the right one and then cutting and pasting Mr. Fish's program post, we could see just how close we get to the 16 K, that would be a big help. (Somehow I always seem just not to do that correctly.)

 

10 hours ago, TGB1718 said:

In ATARI Basic it's unfortunately more steps i.e.

C$=A$:C$(LEN(C$)+1)=B$

 

Also looking at the program with Atari Basic not having multi-dimension string arrays, you would probably need a

numeric array to index a large string, which would mean using even more memory.

 

I also noticed it's using a lot of strings that are not DIM'd, so you would have to find them all and dimension them

before use.

 

This list goes on, CALL - you would need to find what these do to find equivalent in Atari, there's so much more too.

 

I think you're right to give up, it would be a big task even for someone who knows Atari BASIC without

knowing Apple BASIC, not impossible, but a really big task

2 hours ago, TGB1718 said:

In it's current form it takes about 10K and that's without any DIM'd strings etc. which get allocated at runtime, just a quick glance

says there's about 2K or more for variable types and there's a lot of lines not tokenised because of the errors, so it will possibly

be using more than that once all the errors are ironed out.

 

All that before making changes to the code where differences between the 2 BASIC's have to be made and of course we lose

1792 bytes for the OS stuff, I know some of that could be used, maybe save about 512 bytes of base memory.

 

So even before running the program your up to getting on for 14K+ memory used

I had been playing with little bits and pieces of mini programs on the side for this main program, and learned that exact way he showed with the LEN command for the strings. When I got to lines further down where the MID$ command comes into play, that was where I saw future, even more complex problems. I have been thinking, all along in fact, exactly like TGB1718 has, (who I also know thinks a lot like me from other posts I've had) and about his comments. If you combine his 2 comments above, those were why I was hesitant to try this program in the first place (see my initial long program analysis post on this thread) and then continue typing the program, especially after finding that first page of 6 errors when I typed it in. As I say, some of these errors I know I could fix as I go, but these are the more easy and obvious ones, e.g. line 19 I figured out that CLEAR was just CLR.... But it's the strings and the DIM's that would cause us to get righhht to, and hopefully not, exceed the 16K limited memory threshold. This reminds me exactly of what happened in Jaws when Quint stupidly told Brody to max out the engine... toast!

 

So now let me throw another idea in the ring... related to TGB1781's above 2 comments...what if- but this would be after we learn just how close we are to that 16K threshold or the whole thing tanks- maybe, just maybe, perhaps we can "cut corners" so to speak within the program to save memory and thus push us down a couple of K for some headroom so the user can still work within the program?  Keep in mind that I don't think I myself would be using more than a page or 2's worth of it anyway, hence its allure, and not use tons of heavy formulas (which a person probably couldn't do anyway with this scaled down spreasheet version from jump), but you get my drift... maybe we could just shrink the program down and only put what is absolutely necessary to make it work, canning the bells and whistles within, yet still keeping the core program as much as we can. It's also quite possible, maybe even likely, that even cutting some of those would then render us something so basic as to be useless.

 

But, contingent upon what we learn from the Altirra expedition, I would reconsider typing the program all in, say a page or 2 a day, spreading it out say over this week and reporting back with the day's errors, posting those for the day's disappointments, or... even typing it all in, errors and all, with nothing yet viable, just so we'd have everything to see its interplay, and then going back and zeroing in on small sections of what needs to be fixed. I foresee quite a bit of those. 

 

Amazingly, I didn't think this post would get like 800 views, and I thought I was alone with this project, but apparently maybe I was wrong in my thinking that no one would really would actually like to be a part of this. I knew it was going to be a challenge, and boy, what a challenge!   I am willing to be the typist and pilot, but it would take many highly skilled co-pilots here, if we can get 'em in here, and just to refer back to TGB1718's 2 quoted posts above, which still keep echoing in my mind, it's going to take quite a bit of skill/trickery/manipulation to get us a working program due to the plethora of these we-gotta-work-around-them string sections.

 

So, in short, should I start typing again and we try to debug and rework this thing, or should we throw in the towel?  (Sorry but I still can't help to keep coming back to TGB1718's comments, because they mirror exactly my line of thinking here.)But I know that I, and at the least, reifsnyderb, are kind of curious about seeing if this program could work. I would start typing again only if you guys like any of my thoughts just now and/or think they would doable.

 

Tell me your thoughts.

 

 

 

 

 

Edited September 14, 2023 by newTIboyRob

[reifsnyderb]

I think it's an interesting project in a minimalist type mindset.

 

I would start by printing out the code that @MrFish supplied and just verify that it's exactly the same as in the magazine.  Then, I'd locate whatever sections needed converted to Atari BASIC and make some notes on how to convert them.  Also, I'd try to identify features that do not need to be added right away.  After reading through the code, some other thoughts may come to mind.  This is all before typing anything.

 

If there are some features that don't need added right away, I'd port everything but those features and get the program working in as simplistic format as possible.  This would make it easier to debug the program at this stage as well.

 

Once I got this version working, I'd check the memory.  Then I'd know if I can make this work in 16k or not.  If it's below 16k, I could start adding the most important of the other features one at a time.

 

At least that's my thought as to how to approach this problem.

 

I do hope you decide to continue as it would be interesting to have a simple spreadsheet program running in 16k.

[TGB1718]

I found this, I think you will find it useful to solve those PEEKS and POKES, I also think the statements such as :-

VTAB 2: HTAB 1: CALL  - 868

is analogous to POSITION(X,Y) where VTAB is the Y coord and HTAB is the X coord.

So you would change the above line to POSITION(1,2)

 

Other things like :- VTAB 2: CALL  - 868: INPUT "WIDTH = ";A$:A =  VAL (A$)

 

I think you might need a couple of variables to remember where the last X and Y positions were as it looks like

the above call retains the horizontal position which Atari BASIC doesn't.

 

I would create VTAB and HTAB as variables, then do VTAB=2:HTAB=1:POSITION(HTAB,VTAB)

Then the next time you use it like VTAB=2:POSITION(HTAB,VTAB)

as HTAB has not changed.

 

The input statement would have to be broken into 2 parts:-

PRINT "WIDTH = ";:INPUT A$

 

There are obviously lots more thing to do especially around the PEEK's and POKE's but the link below should help with that

 

Have a look at this:-

https://gswv.apple2.org.za/USA2WUG/FOUNDING.MEMBERS/HOME.PAGES/EDHEL/texts/pokes.html

[+Larry]

That is quite a useful list!

[TGB1718]

Just spotted another thing to look out for, according to the manual if you DIM an array

DIM A(10) you get 10 array items,

the first element is A(1) not A(0)

as it is in Atari BASIC (where you get 11 items in your array A(0) thro A(10))

You could still use the code ok though, you just never use the first array element.

 

I posted this as you might fall into this trap when debugging if you expect the first element to be A(0)

Edited September 15, 2023 by TGB1718

[pirx]

16 hours ago, newTIboyRob said:

Amazingly, I didn't think this post would get like 800 views, and I thought I was alone with this project, but apparently maybe I was wrong in my thinking that no one would really would actually like to be a part of this.

this effort does not have any sense and it is beautiful, basically, all we do does not have any sense and your journey seems to top us all :]

[TGB1718]

Maybe another useful link:- https://www.calormen.com/jsbasic/reference.html

 

I also spotted something with strings, the DIM A$(70,10) is different from the string A$ as in 

275 A$ =  MID$ (A$(Y,X),IV,1) 

 

It appears that A$ is a totally different string which also appears does not need to be DIM'd like a few other strings too,

can't seem to find what the default length of an un-dimensioned string is with this BASIC

[_The Doctor__]

the 'bonus' (0) array is often overlooked and can be used for some indexing or other info. many people waste that and it does use memory.

notice the ' ' as it's really not a bonus, it's just something many people never notice.

Edited September 15, 2023 by _The Doctor__

[newTIboyRob]

Thanks for all the comments. Wow, TGB1718, I appreciate all those handy links. Yes, the HTAB and VTAB I was familiar with from doing some programs in Applesoft. Those terms are just screen locators though basically, the equivalent of our POSITION in Atari basic.

 

What puzzles me though is how the arrays are used differently, especially the one you spotted in your comment below. I wasn't sure what to do with DIM A$(10,70). Many of us, myself included, are just used to the DIMensional statements having only a single subscript, with the A$ as the variable, and the subscript number after that usually, in practical terms, is how many letters we could have in a word/how much it is dimensioned to hold.  But then the DIM A$(70,10) makes this technically a "double subscripted variable", in that the variable A$ now has 2 subscripts, which are the 2 numbers separated by the comma. It's kind of hazy in mind after all these years, but I thought I remembered that how all this relates, again in practical terms, is that it translates to rows and columns.  Then I remembered this great Atari Basic book from 1979, and sure enough, chapter 8 on pages 220-226 is called Double Subscripts. So that is exactly what it means.

 

I kind of just glanced through that chapter and was trying to translate this stuff to plain damn English. So DIM A$(70,10) means that the variable A$ is being "assigned" or "dimensioned" the 2 values of 70,10. If this does mean 70 rows and 10 columns, herein lies the problem:  Atari basic, Graphic 0 has 24 rows and 40 columns. Thus, I wondered if it would be a simple change: to 40,24 so I tried it in the Atari online emulator.... Nope. So my next thought is that the error is one of syntax, as I couldn't find any examples of that kind of exact string double format, e.g. (40,24) thus far in Atari Basic.

 

So I thought they have to just be separated?  thus line 19 would change to DIM A$(40), B$(10) , CW(12), IV(50) .. obviously Atari would take this, and it did, but now that just puts us back to a single subscripted variable, not the rows and columns concept I am thinking this means.  or adding more arrays somehow  DIM A$(40), B$(24) C$(40),D$(24) or something like that

 

And then there are more complicated lines, like TGB1718's line 275 reference:  

 

6 hours ago, TGB1718 said:

Maybe another useful link:- https://www.calormen.com/jsbasic/reference.html

 

I also spotted something with strings, the DIM A$(70,10) is different from the string A$ as in 

275 A$ =  MID$ (A$(Y,X),IV,1) 

 

It appears that A$ is a totally different string which also appears does not need to be DIM'd like a few other strings too,

can't seem to find what the default length of an un-dimensioned string is with this BASIC

I just feel like I wouldn't be able to put it all together; sometimes I know what it means, but can't really apply it or adapt it, sometimes I don't know what it is all trying to "say", so maybe someone can just translate this line 275 to plain English for us: ..."In line 275, we are assigning A$ to be the middle location of itself at the location of whatever Y and X is at that moment and that at this and that... or what does this mean exactly???   ...

In short, I find this thing is super tricky translating from one "language" to another

[newTIboyRob]

So pirx... basically you are echoing Shakespeare from Macbeth there...[life] is a tale, told by an idiot, full of sound and fury, signifying nothing.     

[newTIboyRob]

I have been able to make progress in checking out other areas of this program by just practicing on the online emulator first. But still questions.

 

Another tricky thing is that when Applesoft uses the word INVERSE, the whole screen just changes to that inverse video mode (usually just for solid white line/s of text), and it looks like it wants to use it that way in the program.  In Atari basic, since I am 100% new to it, I only know of the inverse video key at the bottom right of the 600 xl, and/or if it needs to be used say in printing a word on the screen by: DIM MSG$ (X) , assign the actual MSG$="[now just press the inverse video key along with the words you're typing in here]" then PRINT MSG$ and the message shows/keeps that inverted video concept on the display while in Graphics 0. 

 

But what do you do if, in 9 times out of 10 in the program, (with the exception being line 1600 which references the subsequent print statement), it is not referencing a specific word, but rather a complete/entire inverse video concept more or less, in those 9 lines of 2050,2115,2120,2135,2175,2179,2182,2185,6190 ...and we still want to keep things in Graphics 0 here, a la Visicalc?
 

 

 

Edited September 15, 2023 by newTIboyRob

[+MrFish]

[This message was deleted. Nothing to see here.]

 

Attn: Moderators, please ↓

 

[newTIboyRob]

Mr. Fish, you mean the Delete key?

[invisible kid]

lol no, sometimes we "delete" posts that way. make moderator's lives a bit easier.

[newTIboyRob]

Oh I see, ok, didn't know that.

[TGB1718]

12 hours ago, newTIboyRob said:

If this does mean 70 rows and 10 columns,

What it means is 10 strings each 70 characters wide and you are correct, if you wanted to print one of those strings

to the screen, it would wrap when it reached the right margin.

[TGB1718]

It would appear that Apple II BASIC is very similar to MSBASIC, so for the fun of it I loaded MSBASIC and loaded

that listing (I know there's still a load of things that are Apple II and aren't going to work) but when run I obviously

got some errors but I commented those lines out I got this far:-

 

The next error was a CALL statement, so at that point I though no use going any further.

 

But what I have found is that Apple BASIC dynamically allocates memory for strings as they are used, just getting this

far in the program used about 14K of memory, once you start using those string arrays, it will eat a lot more, I'm running

this on a 130XE, DOS 2.5 and MSBASIC in memory (not a cart) and before loading the program I only had about 24K free.

 

 

[Fuji-Man]

14 hours ago, newTIboyRob said:

Another tricky thing is that when Applesoft uses the word INVERSE, the whole screen just changes to that inverse video mode (usually just for solid white line/s of text), and it looks like it wants to use it that way in the program.  In Atari basic, since I am 100% new to it, I only know of the inverse video key at the bottom right of the 600 xl, and/or if it needs to be used say in printing a word on the screen by: DIM MSG$ (X) , assign the actual MSG$="[now just press the inverse video key along with the words you're typing in here]" then PRINT MSG$ and the message shows/keeps that inverted video concept on the display while in Graphics 0. 

 

The FLASH, INVERSE only changes the text that is printed until NORMAL command is used. The strings at the beginning can be typed in as inverse characters as they are used for the row and column headings. You could add code to change a string to INVERSE is to add 128 to the ASC value of the character. FLASH although attainable, would require a machine language routine.

[Fuji-Man]

1 hour ago, TGB1718 said:

It would appear that Apple II BASIC is very similar to MSBASIC, so for the fun of it I loaded MSBASIC and loaded

that listing (I know there's still a load of things that are Apple II and aren't going to work) but when run I obviously

got some errors but I commented those lines out I got this far:-

 

The next error was a CALL statement, so at that point I though no use going any further.

1618 NORMAL : POKE 32,2: POKE 33,38: VTAB 5: CALL - 958: POKE 32,0: POKE 33,40

 

The POKES define the left and right columns (Atari BASIC used 82 and 83)

VTAB HTAB stuff could be POKED into 84 and 85 (in Microsoft BASIC) or PRINT #0, AT (VTAB#,HTAB#); or similiar. may have that backwards...

Call -958 Clears the bottom of the text screen (I'm guessing the bottom 3-4 lines)

Then then restores the left and right columns.

 

My best guess is there would need to be a subroutine that would clear parts of the screen using an X,Y,W, H to clear a line or box.

Edited September 16, 2023 by Fuji-Man

[Fuji-Man]

Makes me wonder, Applesoft BASIC for Atari, feasible or not?

Think of all the software that would be usable. Hmm.

Edited September 16, 2023 by Fuji-Man

[Fuji-Man]

3 hours ago, TGB1718 said:

What it means is 10 strings each 70 characters wide and you are correct, if you wanted to print one of those strings

to the screen, it would wrap when it reached the right margin.

The actual program shows 10 columns and 70 rows. And it scrolls as a spreadsheet. For BASIC it does well. The only strange thing is that the left and right arrow keys move the cursor up and down in a column, and to switch columns you have to press the space bar then the left and right arrow keys. The navigation keys need to be reworked...

[newTIboyRob]

What makes me wonder even more, Fuji-Man... is TGB1718's latest discovery: that he awesomely got to only about 1/3 of the entire program, only had a skeletal screen outline, and had only about 2 K remaining of the 600xl's remaining 16K threshold left.... all this even before the remaining strings holding any real "data" had yet to be explored in the remaining 2/3 of the program....   

 

Maybe the goose is cooked as we originally thought, TGB1718 et al. 😆

[newTIboyRob]

 ...but it's been nice to see how far you have been getting, in that VISIclone screen...