How to download a program to slot 1?

Humanoido

How to download a program into program slot 1?
(using BS2px, Pbasic 2.5, Editor 2.2.6, winxp)

RDL2004

Link to Nuts and Volts article multi-bank programming:

http://www.parallax.com/dl/docs/cols/nv/vol3/col/nv87.pdf

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Rick

Humanoido

Thanks for the find. The NV document is helpful. After more days of searching, I found some limited info about the actual process of getting various programs into the banks. It was found under the topic of Advanced Compilation Techniques. Who would have known? However, when looking for specific working 'simple' examples, none were found. It would be nice to see a simple working example. I think one should exist for every code statement. The Parallax manual has accomplished this for most code statements, which is a remarkable accomplishment and well done, but something as important as this seemed to slip through.

I take it that very few people are exploiting the extra banks in their programming. For example, in reviewing code, there is usually just one program. However, to run more (complete) programs in other 2K banks, there would be a set of programs in a folder for loading into the Stamp via the editor. According to the Parallax web page, the 2K bank of the BS2 handles about 500 instructions. Maybe there are more BS2s sold than upgraded Stamps with 8x2K. But even so, wouldn't this be a common thing to see? i.e. code that uses the the other 2k banks... Again, it would be good to see some simple examples.

Unsoundcode

Hi humanoido , you may find some examples of what you are looking for at this link.

http://www.emesys.com/BS2SX.htm#Crossbank

Jeff T.

kelvin james

If you have the stamp editor loaded on your puter, there are some example multi-slot programs in the bs2p folder. If you open store0.bsp, you will see 3 programs open in the editor, the directive of the first line opens the programs listed. Store0 is the " main ", and store1 and store2 have been added to the 2 next slots. The program shows how to " run " the other slots, and how to move data between slots with the " store " command. The help section explains the commands clearly.

Humanoido

A really big thanks on this, to everyone! Rick, your info was great & led to search terms to find other valuable info and tips. Jeff, you really helped a lot with the technical link. It shows examples with numerous techniques. And Kelvin James, the Help File had exactly what I was looking for!

But the latter was really hidden - the help program does not work when accessed through my Basic Stamp Editor 2.2.6 so I went to Start, All Programs, Parallax Inc., Basic Stamp Editor v2.2.6, Help (PBASIC Syntax), and ran that as an individual application. It worked great, and came up with the sample code. Excellent!

All this started when my code came up with EEPROM Full Error. After trimming it, and removing most all Debug statements, I clicked the run button and .... it came up with the same error. The cursor was placed farther down in the program code, which is apparently where the memory ran out. Doing a "Properties" on the actual file shows it was 13.6K in size! - Far larger than the single 2K "program slot 0" that I was attempting to load it into. But then I did a properties on a program that loads fine, and it came back as 10.6K so apparently this is not a valid memory test. I'm not sure what is a valid test, as the Editor won't bring up the memory view. Maybe there is a formula, approximated from actual file size to tokenized size?

Bruce Bates

humanoido -

The size of the physical program as it resides on disk, and the size of the tokenized program are two completely different things. Just by way of a simple example, the comments will be shown in the size on disk, but comments never reach the tokenized program. A properly documented program will probably have more area (read: disk area) used for comments than there is for program code and variables!

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Humanoido

Thank you. Yes, that's true and a very good point, considering many remmed statements in the code that's not a part of what gets downloaded and tokenized. But it would take too much time to strip out these embedded comments in every program, every time program size was required. Mainly I'm thinking about programs that already give the EEPROM Full error. How do we know how much overload memory these programs have?

This could be helpful - Is there a chart showing the memory consumed by various program statements? I found a few rather general references but nothing complete. It would be useful to avoid statements that consume the largest amount of memory during programming.

Bruce Bates

humanoido -

The whole point is, don't use the Windows PROPERTIES facility to try to gauge the size of your program. There was NO suggestion to strip the comments out.

Selecting which statements to use in a program is about the LAST step I would take to remove program bloat. There are at least a half a dozen steps that would preceed that in my estimation.

The FIRST step I would take is to review where subroutines (GOSUB - RETURN) might be used in lieu of inline code. That probably consumes more unnecessary program space than almost any other cause, in most programs.

The SECOND step would be to remove any and all DEBUG statements replacing those that are deemed necessary with SEROUT statements. The list goes on from there.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Humanoido

Bruce Bates, thanks, I'm very interested in your list.
First, you are saying to add subroutines where the inline
code might be duplicated. Is this correct?

Secondly, you are saying there is a way to change Debug
Statements to Serout statements and save space. Is this correct?

How can Serout handle all the formatting that Debug is capable of?

Finally, is there a simple code example to change the following to Serout?

DEBUG CR, " The value is ",CR
DEBUGIN DEC x
DEBUG CLS, HOME, " Hello world",CR

What other things can you add to the list? In particular, my programs
consume a lot of space with FREQOUT x,y,z statements.

Bruce Bates

humanoido -

Remove duplicated code, and replace it with a GOSUB to a subroutine. In that subroutine have the program code which was duplicated many times in your program.

As far as SEROUT formatting is concerned, you may want to look at the end of the SEROUT command in either the PBASIC Stamp Manual, or the PBASIC Help File. Both have the formatting sub-parameters which are available for SEROUT.

You wanted to eliminate DEBUG from the following program code:

DEBUG CR, " The value is ",CR
DEBUGIN DEC x
DEBUG CLS, HOME, " Hello world",CR

SEROUT Outport, Baudmode, [noparse][[/noparse]13,"The value is ",13]
DEBUGIN DEC X or SERIN (with the appropriate parameters)
SEROUT Outport, Baudmode, [noparse][[/noparse]0,1, " Hello world",13]

I'll leave you to double check the ASCII control code values, as I don't have my table handy.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Humanoido

Changing a debug to a serout will save how much memory?

Bruce Bates

humanoido -

To answer your question exactly, I would have to write two quick programs, and check the size of the programs in the internal memory map (CTL + M), and jot down the sizes. I will leave the actual exercise to you.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Tracy Allen

There is no difference in size between the debug code and the serin/serout code. The tokenizer turns debugs into serouts that reference p16 at 9600 baud.

If you have a lot of DEBUG statements that output strings, like "The value is: ", it can save a huge amount of space if you code those strings as Data. Have a single subroutine to play them back:

valueIsStr  DATA "The value is: ",0
pointer=valueIsStr
GOSUB playString
STOP
playString:
  DO
    READ pointer,char
    IF char=0 THEN EXIT
    DEBUG char
    pointer=pointer+1
  LOOP
  RETURN

The reason that saves space is that each character in a DATA statement occupies 8 bits, whereas in the body of a DEBUG statement each character occupies 14 bits.

If you have a lot of FREQOUT sequences that play tunes, a similar compression can occur if you can store the tunes as DATA.

Since you are using a BS2px, that DATA can be stored in another bank, separate from your program, and the program can access it using the STORE, READ an WRITE commands.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Humanoido

Thanks Bruce Bates, incorporating subroutines to save on memory space will be helpful. However, I wrote the same end result programs using debug and serout, and was able to confirm memory use is identical in both programs.

Thanks Tracey Allen - for clarifying debug and serout memory usage as the same. Coding strings as data for Debug statements is a very interesting way to utilize memory very efficiently. The code sample is very helpful! Storing tunes as data will also be helpful in streamlining memory.

I know how to put a program in slot 0, and another in slot 1 which can be called by the program in slot 0. How to store, read and write some simple data in slot 1 and use it by the program in slot 0? Is this what you are referring to?

Tracy Allen

Yes, if you have the following DATA in slot 1:

' in slot 1
hi  DATA  "hello world",0
bye DATA "goodbye cruel world",0

Then in slot 0, you would use the STORE command to point to slot 1.

' in slot 0
hi CON 0  ' note that you have to enter the addresses in slot 1 as constants, or use fixed fields
bye CON 12  '
STORE 1  ' point to slot 1
pointer = hi  ' address in slot 1
GOSUB playString
STOP

There are other ways to do this. For example, the playString routine could be located in slot 0, and then the program in slot 0 can call across slots with an index to play the string at a certain index. Fixed field data can be referenced by a computed pointer.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com