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

[newTIboyRob]

I posted a couple of other related threads on this topic but I'll just return here with this new post because I remember now this was the original section.

 

After tons of searching, I actually found a type in spreadsheet program in basic, (5 total pages but only about 2.5 of actual typing.) That was amazing in itself. But the catch is that I can see it was written in Applesoft basic, thus it would need to be modified in spots for Atari Basic. Another biggie is that I also don't know if it would work with the 410 since this program was meant for Apple disk drives. But I thought that maybe there is a way to modify this program to get it to run in Atari basic by fiddling with it, modifying it to get it to work with tape somehow, if that is possible. The program does look like it could be modified to work with other basics, so it got me wondering:

 

1) Is there an online translator program for lines of basic code, whereby you could enter basic lines of a program and it would translate what changes you'd have to make in order to get it to run on another, different brand of computer's basic?  In essence, a basic program translator.  If no, seems hard to believe with all the things out there!  That would be an ultra handy thing though.  I remember BITD magazines like Family Computing used to print the changes needed to run the different programs on different computers, but again, the program I found was written in Applesoft, with 0 translation to other computers, and it appears it would get tricky for me in certain areas trying to get it to run on the 600 XL. 

 

2) If no to the above, does anyone recall ever seeing maybe a chart with showing how each command differs in each type of basic?  e.g. for the clear screen command, the chart shows:

Atari = PRINT CHR$(25)    Apple= HOME     IBM & Compatibles= CLS.   I couldn't find that, but maybe someone remembers?  Though it would be easy to bring over certain words like these, for string variables it could get quite dicey for me.

 

 I'm curious about the 2 above before I would continue trying to write my own program.

 

[newTIboyRob]

I could also post the program in case anyone does care to take a look.

[reifsnyderb]

It shouldn't be hard to port the program....

[+Stephen]

37 minutes ago, reifsnyderb said:

It shouldn't be hard to port the program....

Until you realize the (silly) limitation of 16kB and cassette only I/O device.

[reifsnyderb]

16 minutes ago, Stephen said:

Until you realize the (silly) limitation of 16kB and cassette only I/O device.

Then maybe you'll only have a 3x3 grid of 9 cells?  😀

Edited September 12, 2023 by reifsnyderb

[+slx]

3 hours ago, reifsnyderb said:

Then maybe you'll only have a 3x3 grid of 9 cells?  😀

2 screens of text would be around 2K. A little more than 3x3 cells should be workable.

 

@newTIboyRob, you might want to post the program so it's easier to see where it uses Apple-specific stuff.

 

It might be easer to pull this off if you don't do input "in place" like we are accustomed to in Excel, etc., but just select a "cell", copy its contents to an input area and edit it there. The original Atari VisiCalc works that way as well. The only method VisiCalc uses to separate cells with numbers horizontally is to switch to exponent display if they would exceed cell width-1, so the leftmost character remains a space. (Not for text, so you can run contiguous text along several cells.) You can check it out on an emulator.

 

I think it's a nice programming exercise and if you don't care too much about speed it should be doable in BASIC with some PEEKs and POKEs to change the display list. There's no ceiling on the amount of ML trickery you can add to speed it up and beautify it, but let's look the Apple BASIC code for starters.

 

However you proceed, good luck and have fun along the way!

 

P.S.: To invert ordinary Gr. 0 Atari text, you just need to set the high bit of the character. (That does not work in text modes 1 and 2 where it changes the color.)

 

 

[+slx]

6 hours ago, newTIboyRob said:

1) Is there an online translator program for lines of basic code, whereby you could enter basic lines of a program and it would translate what changes you'd have to make in order to get it to run on another, different brand of computer's basic?  In essence, a basic program translator.  If no, seems hard to believe with all the things out there!  That would be an ultra handy thing though.  I remember BITD magazines like Family Computing used to print the changes needed to run the different programs on different computers, but again, the program I found was written in Applesoft, with 0 translation to other computers, and it appears it would get tricky for me in certain areas trying to get it to run on the 600 XL. 

 

I never came across such a thing but you might find some hints in Appendices to later editions of the David Ahl books and in magazine articles. Many magazines are archived online. I don't know about Apple BASIC but the main difference between Atari BASIC and most other BASICs is the (sub)string handling, as the Atari uses an A$(x,y) notation with x being the first and y the last character you "slice" out of a string rather than the BEGIN$, MID$ and END$ of MS-BASIC. Another difference is the absence of string arrays (which you can mimic by converting the second dimension to an offset). One of the neat tricks of Atari BASIC programming is the rather fast manipulation of strings. With some PEEKs and POKEs you can use a string as screen memory and manipulate it a lot faster than using the normal routines to write to the screen.

 

 

 

 

[+Larry]

Will the Atari Microsoft Basic cartridge run in 16K?  Never cared much for AMSB, but it should make conversion easier.  Of course, he'd still have to come up with a cartridge or multi-cart.  As others have said, a 16K cassette system is so extremely limited!

[Rledo]

18 hours ago, newTIboyRob said:

I posted a couple of other related threads on this topic but I'll just return here with this new post because I remember now this was the original section.

 

After tons of searching, I actually found a type in spreadsheet program in basic, (5 total pages but only about 2.5 of actual typing.) That was amazing in itself. But the catch is that I can see it was written in Applesoft basic, thus it would need to be modified in spots for Atari Basic. Another biggie is that I also don't know if it would work with the 410 since this program was meant for Apple disk drives. But I thought that maybe there is a way to modify this program to get it to run in Atari basic by fiddling with it, modifying it to get it to work with tape somehow, if that is possible. The program does look like it could be modified to work with other basics, so it got me wondering:

 

1) Is there an online translator program for lines of basic code, whereby you could enter basic lines of a program and it would translate what changes you'd have to make in order to get it to run on another, different brand of computer's basic?  In essence, a basic program translator.  If no, seems hard to believe with all the things out there!  That would be an ultra handy thing though.  I remember BITD magazines like Family Computing used to print the changes needed to run the different programs on different computers, but again, the program I found was written in Applesoft, with 0 translation to other computers, and it appears it would get tricky for me in certain areas trying to get it to run on the 600 XL. 

 

2) If no to the above, does anyone recall ever seeing maybe a chart with showing how each command differs in each type of basic?  e.g. for the clear screen command, the chart shows:

Atari = PRINT CHR$(25)    Apple= HOME     IBM & Compatibles= CLS.   I couldn't find that, but maybe someone remembers?  Though it would be easy to bring over certain words like these, for string variables it could get quite dicey for me.

 

 I'm curious about the 2 above before I would continue trying to write my own program.

 

Note much, but this'll get you started: PRINT CHR$(125) is clear screen in text modes and clears text window in graphic modes

 

[+slx]

4 hours ago, Larry said:

Will the Atari Microsoft Basic cartridge run in 16K?  Never cared much for AMSB, but it should make conversion easier.  Of course, he'd still have to come up with a cartridge or multi-cart.  As others have said, a 16K cassette system is so extremely limited!

In emulation MS BASIC II will leave a few hundred bytes more free memory than Atari BASIC on a 16K 600XL but probably lose at least some of that advantage due to less tokenization. It might have a speed advantage and use of integers might help as well for the user interface part. Boolean function could be used for the cursor. But the OP would still need to get it, so plain Atari BASIC is more likely the weapon of choice. 

 

That severe limitation can be experienced as a challenge. 

[newTIboyRob]

 Before I continue on with the program/s, I thought I'd better check on my 410 as it has been 3 years since I tried. Boy am I glad I did.

 

Just now, I typed a 3 line program and it seemed to CSAVE ok.  But I noticed 3 things, so tell me if they are all related. I think they must be interwoven here considering the error message I got, any maybe someone can explain/expound here:

 

-both the rewind and advance functions don't work, though it seemed to record fine

-the LOAD ERROR -138 (=device time out) appears, where I've never seen any errors prior, ever

 

So is this device timeout thing occurring because the drive motors or the like need to be at a certain speed for the Atari to register it?  I was wondering if, since both rewind and advance ain't churnin' that maybe it wasn't recording at the proper speed and/or alignment, that kind of thing.

 

Someone please clarify?

Edited September 12, 2023 by newTIboyRob

[+mytek]

14 minutes ago, newTIboyRob said:

Before I continue on with the program/s, I thought I'd better check on my 410 as it has been 3 years since I tried. Boy am I glad I did.

 

-both the rewind and advance functions don't work, though it seemed to record fine

-the LOAD ERROR -138 (=device time out) appears, where I've never seen any errors prior, ever

 

Uggg I'm sorry to hear that your 410 is apparently having issues. I know you are likely trying to re-experience the Atari as it was in the 80's, but you might want to consider a modern SIO2PC-USB, SDrive-Max, or FujiNet instead. I absolutely learned to hate my 410 back in the day 😖

[newTIboyRob]

Yes, thank you. I was just trying to make use of what I had. I am going to go post those issues on another thread now before I even go any further with this program! 😆

[reifsnyderb]

21 minutes ago, newTIboyRob said:

 Before I continue on with the program/s, I thought I'd better check on my 410 as it has been 3 years since I tried. Boy am I glad I did.

 

Just now, I typed a 3 line program and it seemed to CSAVE ok.  But I noticed 3 things, so tell me if they are all related. I think they must be interwoven here considering the error message I got, any maybe someone can explain/expound here:

 

-both the rewind and advance functions don't work, though it seemed to record fine

-the LOAD ERROR -138 (=device time out) appears, where I've never seen any errors prior, ever

 

So is this device timeout thing occurring because the drive motors or the like need to be at a certain speed for the Atari to register it?  I was wondering if, since both rewind and advance ain't churnin' that maybe it wasn't recording at the proper speed and/or alignment, that kind of thing.

 

Someone please clarify?

Hello,

 

The first thing I'd do is to take it apart and carefully oil the mechanism with a fine oil.  Also, check the belts.  If they are bad, replace them.

 

With that Atari 600XL, I'd take @mytek's advice and get something like an SDrive Max and memory upgrade so that I have at least 64k of memory.

[newTIboyRob]

I am considering that route as the last alternative, as I have been trying to use what I have here first. Thank you though for the suggestion.

[Geister]

The memory upgrade on the 600XL requires two 4464 chips and a couple of wires run to here and there on the board.  I just did it on GP when I was fixing my 600XL and it was just as well because the original 4416's were smoked along with the CPU, and the Pokey chip.  I blame an ingot power supply that the previous owner had tossed in the trash.  It's a cheap as chips upgrade.  For a non-invasive upgrade, there's a 600XL selling locally for $95 with an external 64K upgrade board that plugs into the parallel port.  I could possibly inquire about it for you.

[reifsnyderb]

10 minutes ago, Geister said:

The memory upgrade on the 600XL requires two 4464 chips and a couple of wires run to here and there on the board.  I just did it on GP when I was fixing my 600XL and it was just as well because the original 4416's were smoked along with the CPU, and the Pokey chip.  I blame an ingot power supply that the previous owner had tossed in the trash.  It's a cheap as chips upgrade.  For a non-invasive upgrade, there's a 600XL selling locally for $95 with an external 64K upgrade board that plugs into the parallel port.  I could possibly inquire about it for you.

I've got a 64k and a 320k PBI board that I sell on ebay and Tindie.  Both will work with a 600XL and upgrade it in seconds.

[newTIboyRob]

I appreciate that. Should I eventually have to upgrade, I would choose the non-invasive route, but by that time, that one you just mentioned is likely to be long gone... kind thought though.

[+David_P]

You could look at some of the SD solutions, and try LiteDos - which would give you a bit more RAM to play with even if you don't upgrade beyond 16K.

 

http://www.mr-atari.com/Mr.Atari/LiteDOS/

[newTIboyRob]

This is a rather long post. Perhaps get a beverage of choice before reading      

 

So the program I found looks like a cool little thing that appears quite adaptable and can be useful, even to a limited degree, on the "game machine" only 600xl.  While the program technically is a 5 pager with a 6th page addendum, due to all the ads, it's actually only about 2.5 pages of actual typing , which isn't so bad, relatively speaking.   Since I am the original poster here, I took the liberty of first taking a look at program, then sifting through it, line by line, to identify any potential snags. There are definitely those present.

 

Overview questions/first impressions:

• Will it fit within 16 K with use with even a few pages of data (which would be all I would need/use) and also be able to save to tape?   My guess would be yes, yours?   But if the consensus here is no, then I won't even start typing and the project is: game over.
• Since the Atari, and I think many of us can agree, in general, handles string functions quite unorthodoxly compared to other basics, that very fact alone may cause heading for the hills.  But... maybe we can beat this here.
• Page layout/setup... this has been my weak area. I'm wondering if we can just stay in text mode Graphics 0 though commands like NORMAL FLASH and INVERSE are used.  I remember, member SLX mentioned that to invert ordinary Gr. 0 Atari text, you just need to set the high bit of the character. I watched a You Tube video on mixing modes, if we have to, but I foresee this being an issue here. SLX, this is where your expertise will come into play perhaps, or you can find a way around any page layout/setup issues within the program....

 

Considering the amount of code in it though, overall it doesn't seem too bad to port to Atari Basic. I'd even go so far as to say that at least 85% percent of it, or even more, is written in universal basic, thank goodness. Ok, enough build up.  So I attempted to address the snags and their fixes. Some were easy, some are going to be more of a challenge. The 11 italicized underlines are my questions with the bringing this into Atari Basic.

HTAB AND VTAB occur ocassionally, but those are easy conversions ... So in Atari basic, I will just change those to  POSITION x,y   whenever they occur       ✓
NORMAL, INVERSE and FLASH occur ocassionally...     (see last bullet above)          Depending on mode, what are Atari BASIC's equivalent commands?

 

continuing....

 

Page 1... non remarkable

 

Page 2...CALL -868 in line 240 is Applsoft's' way of clearing the cursor line from cursor to end of line, thus:  Can a a PEEK and/or POKE combination can be substituted here for where this appears in the program, or  is there another way ?  I wasn't quite sure which exactly, nor how to implement it here.

 

Page 3...       
            Line 1618 is a biggie. Question 3:  I essentially wasn't sure if PEEKS and POKES are universal, (I thought they were different on all systems? so wasn't totally sure.)  But from research, I learned that in Applesoft Basic:

 

           POKE 32, 2...  sets left margin of text window, here at #2...  but would this same exact command apply to the program, or need changing depending on our chosen screen set up?
           POKE 33,38... sets width of text window. (Same question as last above)  
           CALL -958...    clears the bottom of the text screen                so, the Atari equivalent here?
           POKE 32,0: POKE 33,40   (setting left margin and text window width, respectively, at those locations... but...same question as above)

 

Page 4... line 2310 POKE -16368,0      In Applesoft, IF PEEK(-16384)>127 then a key has been pressed (POKE -16368,0 resets this)  So, can we just leave this as is, or must it be changed?

 

 

Clearing those hurdles would be super enough, but...

 

 

Page 5... is where the real fireworks begin here, in the DISK I/O section, specifically within lines 5120-5675. This is where the tape concept, if it could, comes into play, and is another area I'm finding confusing.

 

What I know: we want to use tape here, not disk

 

What I know: In Applesoft, PRINT CHR(4);" XXXX ";STRING$ ...  CHR$() is a function that retrieves the keyboard character assigned to the numerical value in parenthesis. In the original program, it emits a Control-D character to signal DOS. Thus, the "CHR$(4);" is the equivalent of keying in CTRL+D which instructs the computer that the next PRINTed string should be executed as a DOS command rather than PRINTed to the screen.
                   
What I don't know:  If, again, since this section presumes we are using disk, not tape, how will these need to be changed when using tape?)

 

What I know:  both Applesoft and Atari basic both use OPEN, READ and CLOSE commands relating to data

 

What I dont know: if Atari basic uses the WRITE or UNLOCK commands at all, or its equivalent, (because I don't see either one listed in the ATARI Basic Reference Manual.)  But if those refer to the disk-related concept, how  does it change with tape?

 

What I know: CATALOG is just a disk directory command. If not using disk, Can we scrap this entire line #5510

Later on in the program is a PRINT CHR$(4);"PR#0"    PR stands for Peripheral "print" or "output to slot# typically with a "DOS string CHR$(4)" followed by the OS command.  Basically here means to shut off communication.  , But again, it is a disk/DOS related command, and how to change it for tape usage?

 

I realize there is a lot here.  I spent quite some time going back and forth, but if you guys can throw some hats in the ring, I would appreciate it.  It would be super satisfying to see if this program can actually work!

NOTE the changes on the addendum page.

 

I thought at the very least someone else can use this and play with it if to suit their liking/taste, or even type it in verbatim in Applesoft should they not want to dust off the Visicalc.

 

Edited September 13, 2023 by newTIboyRob

[+slx]

2 hours ago, newTIboyRob said:

Overview questions/first impressions:

• Will it fit within 16 K with use with even a few pages of data (which would be all I would need/use) and also be able to save to tape?   My guess would be yes, yours?   But if the consensus here is no, then I won't even start typing and the project is: game over.

I think it should though you might have to reduce the number of cells.
 

Every line of BASIC uses up at least five bytes of overhead plus 1 byte per command and variable used in the line plus 6 bytes per number.

E.g.

10 A=1

This uses

2 bytes for the line number,

2 bytes for internal housekeeping,

1 byte for the implied „LET“,

1 for variable A,

1 for the assignment statement (=)

6 for the number 1 in floating point representation (ATARI BASIC does not use integers)

1 for End of Line

Every extra statement in a line has two bytes of overhead.

 

If you try to write minimum size code it can help to define often used numbers (like 1) as variables as those are stored as a single byte.

 

Every variable needs some space as well, if memory becomes very tight you might want to use short variable names.

 

The easiest way to find out if it fits would probably be to OCR it and enter it in an Emulator via Copy/Paste. Even if lines with non-Atari statements don‘t parse you‘ll get a good estimate of remaining free RAM.

 

 

 

2 hours ago, newTIboyRob said:

• Since the Atari, and I think many of us can agree, in general, handles string functions quite unorthodoxly compared to other basics, that very fact alone may cause heading for the hills.  But... maybe we can beat this here.

A detailed description on how to substitute string arrays is found here.

 

 

2 hours ago, newTIboyRob said:

• Page layout/setup... this has been my weak area. I'm wondering if we can just stay in text mode Graphics 0 though commands like NORMAL FLASH and INVERSE are used.  I remember, member SLX mentioned that to invert ordinary Gr. 0 Atari text, you just need to set the high bit of the character. I watched a You Tube video on mixing modes, if we have to, but I foresee this being an issue here. SLX, this is where your expertise will come into play perhaps, or you can find a way around any page layout/setup issues within the program....

You can use Gr. 0. If you absolutely need flashing, it can be done via a vertical blank interrupt (VBI) machine language routine. Look up address 755 here.

 

 

2 hours ago, newTIboyRob said:

 

Page 2...CALL -868 in line 240 is Applsoft's' way of clearing the cursor line from cursor to end of line, thus:  Can a a PEEK and/or POKE combination can be substituted here for where this appears in the program, or  is there another way ?  I wasn't quite sure which exactly, nor how to implement it here.

 

Afaik there is no equivalent Atari command. With some trickery you could define a string at the address of screen memory and use string manipulation to perform that. Another possibility would be a machine language subroutine.

 

(When using screen memory you have to be aware that the codes used to generate characters on screen differ from the ATASCII codes used to represent them in BASIC, there are tables that show how they correspond.)

 

 

2 hours ago, newTIboyRob said:

 

Page 3...       
            Line 1618 is a biggie. Question 3:  I essentially wasn't sure if PEEKS and POKES are universal, (I thought they were different on all systems? so wasn't totally sure.)  But from research, I learned that in Applesoft Basic:

No, they are not. 

 

 

2 hours ago, newTIboyRob said:

 

           POKE 32, 2...  sets left margin of text window, here at #2...  but would this same exact command apply to the program, or need changing depending on our chosen screen set up?

 

Check the memory map linked above at locations 82 and 83.

 

2 hours ago, newTIboyRob said:

 

POKE 33,38... sets width of text window. (Same question as last above)  
           CALL -958...    clears the bottom of the text screen                so, the Atari equivalent here?

 

Not sure, don‘t think there is an equivalent, but check the memory map.

 

2 hours ago, newTIboyRob said:

Page 4... line 2310 POKE -16368,0      In Applesoft, IF PEEK(-16384)>127 then a key has been pressed (POKE -16368,0 resets this)  So, can we just leave this as is, or must it be changed?

 

 

PEEK 764,X will give you the last key pressed (again in a non-ATASCII coding) but if your program can just wait for the next keypress you can OPEN the keyboard and GET a keypress from there. 
 

2 hours ago, newTIboyRob said:

 

Page 5... is where the real fireworks begin here, in the DISK I/O section, specifically within lines 5120-5675. This is where the tape concept, if it could, comes into play, and is another area I'm finding confusing.

 

What I know: we want to use tape here, not disk

 

What I know: In Applesoft, PRINT CHR(4);" XXXX ";STRING$ ...  CHR$() is a function that retrieves the keyboard character assigned to the numerical value in parenthesis. In the original program, it emits a Control-D character to signal DOS. Thus, the "CHR$(4);" is the equivalent of keying in CTRL+D which instructs the computer that the next PRINTed string should be executed as a DOS command rather than PRINTed to the screen.
                   
What I don't know:  If, again, since this section presumes we are using disk, not tape, how will these need to be changed when using tape?)

 

What I know:  both Applesoft and Atari basic both use OPEN, READ and CLOSE commands relating to data

 

What I dont know: if Atari basic uses the WRITE or UNLOCK commands at all, or its equivalent, (because I don't see either one listed in the ATARI Basic Reference Manual.)  But if those refer to the disk-related concept, how  does it change with tape?

 

What I know: CATALOG is just a disk directory command. If not using disk, Can we scrap this entire line #5510

Later on in the program is a PRINT CHR$(4);"PR#0"    PR stands for Peripheral "print" or "output to slot# typically with a "DOS string CHR$(4)" followed by the OS command.  Basically here means to shut off communication.  , But again, it is a disk/DOS related command, and how to change it for tape usage?

 

 

There is no way to catalog tape storage. The only way to locate specific recordings is via tape counter. To save something to cassette you’d have to write to the “C:“ device. This might require some PEEKs and POKEs to set up I/O and a short machine language subroutine to get it going. Details should be available in the I/O section of De Re Atari. As I was lucky enough to never have a floppy drive in my youth and the ones I have now gathering dust I am not familiar with the practical aspects of floppy storage, but it sure can be done.

 

As mentioned above, „De Re Atari“ has a very good description of various programming concepts. „Mapping the Atari“ contains valuable information about various memory locations including sample programs and the modern Altirra Hardware Reference Manual is probably the most detailed description of the hardware, although it does not look as inviting as the other two. 

I can‘t recommend a „best“ book for Atari BASIC but get one to find out about its peculiarities. Almost all Atari literature has been scanned and is available online. 

 

If you have not found them, the atarimagazines.com, atariarchives.org and Atarimania websites contain a treasure trove of information on Atari programming. The Compute! Books are compilations of magazine articles with various neat tricks.

 

 

[newTIboyRob]

slx... thank you so much for taking the time to dissect things and answer line by line like that. I really like and appreciate how you did that for me!

[newTIboyRob]

Ok, I will try any online OCR and try to get it into the Atari Emulator. That is Step 1 I suppose, just to make sure it fits within the 16k

Edited September 13, 2023 by newTIboyRob

[newTIboyRob]

I must be I'm doing something wrong here when I tried to do this, slx... I found an OCR, got it in there to convert to a file, but then I got only like 1 page of gibberish without any program. Not to mention, it wasn't letting me cut and paste what was converted into the online Atari Emulator I've been using anyway even if it was fully there. 

 

Since I haven't had any luck with trying.. could someone else try the process slx suggested to see about how much K this program actually would be using?  Hopefully it's not over 16k! (I won't proceed further until we know.)

[TGB1718]

1 hour ago, slx said:

Page 3...       
            Line 1618 is a biggie. Question 3:  I essentially wasn't sure if PEEKS and POKES are universal, (I thought they were different on all systems? so wasn't totally sure.)  But from research, I learned that in Applesoft Basic:

I would advise getting Mapping the Atari, you will nee it