Stamp Virtual Memory!

Archiver

Hello,

I'm fairly new to stamps (got mine a few weeks ago) but i've decided
to contribute to the stamp community with this little creation for
the Basic Stamp 2E, 2SX, and 2P24/40 units. This code utilizes the
scratch pad memory in the previously mentioned stamps to store
variable data. For variables that need to be quickly accessed, the
program leaves 18 bytes of RAM free. When all possible "data slots"
are filled, it will leave 5 bytes of the scratch pad free (58-62) It
uses 389 bytes of the program slot EEPROM, but can be reduced in size
by removing some of the parts you may not need (such as bit and
nibble storage, and the "over the limits" hanling). It will store up
to 16 of each variable, though it can be modified to just about any
specifications as long as it doesn't exceed the limits of the scratch
pad. You could even perform mathematical operations with 31
different word variables, as long as you have the EEPROM space to do
so!

I haven't really tested it because I can't find my serial cable :-(
I know for sure that the syntax is correct however. If some people
with the BS2E, SX, or P could test this out for me, I would greatly
appreciate it! You can send me e-mail feedback with the address
found inside the file.

Thanks a lot!
Kyle

(here's the file)
http://groups.yahoo.com/group/basicstamps/files/svm13.bsx

Archiver

Hi Kyle,

Welcome to the club. Nice program but I have a few questions.
Why the separate areas for bits,nibbles etc. For example, if you were to
define the bit variables as aliases within a byte variable, you could
store/retrieve
the bits using a single command, speeding things up a little.

Your slot concept, as defined by currentl, is this related to the program
slots,
or program banks as some people say, or is it a way to define multiple
variable sets within a program?

Some months ago we had a discussion about program calling using a bs2sx/e/p
That involved a stack mechanism. At some point there was also the
save/retrieve
mechanism for local and global variables. In a way it provided the same
result:
More named variables, it didn't split up the variables in datatypes though.
You should be able to find that thread in the archives searching for
'program calling'.
Maybe you could combine both methods to our mutual benefit.

Greetings peter

---

Oorspronkelijk bericht

---

Van: pyromaneyakk@h... [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=ORcGUkKN-TKbS7uBQiWYN2D3a-vndOSsX_Ew7kJrHqnb10Vq7o-Yrol_KtdO4vGiVbjUyZSrNkrLc17Nfsg]pyromaneyakk@h...[/url
Verzonden: woensdag 11 juli 2001 08:59
Aan: basicstamps@yahoogroups.com
Onderwerp: [noparse][[/noparse]basicstamps] Stamp Virtual Memory!

Hello,

I'm fairly new to stamps (got mine a few weeks ago) but i've decided
to contribute to the stamp community with this little creation for
the Basic Stamp 2E, 2SX, and 2P24/40 units. This code utilizes the
scratch pad memory in the previously mentioned stamps to store
variable data. For variables that need to be quickly accessed, the
program leaves 18 bytes of RAM free. When all possible "data slots"
are filled, it will leave 5 bytes of the scratch pad free (58-62) It
uses 389 bytes of the program slot EEPROM, but can be reduced in size
by removing some of the parts you may not need (such as bit and
nibble storage, and the "over the limits" hanling). It will store up
to 16 of each variable, though it can be modified to just about any
specifications as long as it doesn't exceed the limits of the scratch
pad. You could even perform mathematical operations with 31
different word variables, as long as you have the EEPROM space to do
so!

I haven't really tested it because I can't find my serial cable :-(
I know for sure that the syntax is correct however. If some people
with the BS2E, SX, or P could test this out for me, I would greatly
appreciate it! You can send me e-mail feedback with the address
found inside the file.

Thanks a lot!
Kyle

(here's the file)
http://groups.yahoo.com/group/basicstamps/files/svm13.bsx


To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.


Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Archiver

The reason I used the separate save/load systems for bits and nibbles
was simply to demonstrate a way to store the bits and nibbles within
the scratch pad's byte-only memory. The code was designed to be
modified to one's needs. It has all the necessary functions to store
all four types of data. Both RAM and EEPRom can be saved by cutting
out what's not needed, however it is there in case anyone needs it.


The idea is that is for when you need a lot of different variables.
Instead of having all of the variables named in the RAM and possibly
not having enough, you would share all data between one single
variable, eliminating the lack of RAM. Though more EEPRom space and
processing time is required, if you eliminate the bit and nibble
portions of my code, you can have up to 81 bytes of "RAM" (18 bytes
real, 62 bytes "virtual" scratch pad).



--- In basicstamps@y..., "Peter Verkaik" <peterverkaik@b...> wrote:
> Hi Kyle,
>
> Welcome to the club. Nice program but I have a few questions.
> Why the separate areas for bits,nibbles etc. For example, if you
were to
> define the bit variables as aliases within a byte variable, you
could
> store/retrieve
> the bits using a single command, speeding things up a little.
>
> Your slot concept, as defined by currentl, is this related to the
program
> slots,
> or program banks as some people say, or is it a way to define
multiple
> variable sets within a program?
>
> Some months ago we had a discussion about program calling using a
bs2sx/e/p
> That involved a stack mechanism. At some point there was also the
> save/retrieve
> mechanism for local and global variables. In a way it provided the
same
> result:
> More named variables, it didn't split up the variables in datatypes
though.
> You should be able to find that thread in the archives searching for
> 'program calling'.
> Maybe you could combine both methods to our mutual benefit.
>
> Greetings peter
>
>
>

---

Oorspronkelijk bericht

---

> Van: pyromaneyakk@h... [noparse][[/noparse]mailto[noparse]:p[/noparse]yromaneyakk@h...]
> Verzonden: woensdag 11 juli 2001 08:59
> Aan: basicstamps@y...
> Onderwerp: [noparse][[/noparse]basicstamps] Stamp Virtual Memory!
>
> Hello,
>
> I'm fairly new to stamps (got mine a few weeks ago) but i've decided
> to contribute to the stamp community with this little creation for
> the Basic Stamp 2E, 2SX, and 2P24/40 units. This code utilizes the
> scratch pad memory in the previously mentioned stamps to store
> variable data. For variables that need to be quickly accessed, the
> program leaves 18 bytes of RAM free. When all possible "data slots"
> are filled, it will leave 5 bytes of the scratch pad free (58-62)
It
> uses 389 bytes of the program slot EEPROM, but can be reduced in
size
> by removing some of the parts you may not need (such as bit and
> nibble storage, and the "over the limits" hanling). It will store
up
> to 16 of each variable, though it can be modified to just about any
> specifications as long as it doesn't exceed the limits of the
scratch
> pad. You could even perform mathematical operations with 31
> different word variables, as long as you have the EEPROM space to do
> so!
>
> I haven't really tested it because I can't find my serial cable :-(
> I know for sure that the syntax is correct however. If some people
> with the BS2E, SX, or P could test this out for me, I would greatly
> appreciate it! You can send me e-mail feedback with the address
> found inside the file.
>
> Thanks a lot!
> Kyle
>
> (here's the file)
> http://groups.yahoo.com/group/basicstamps/files/svm13.bsx
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@y...
> from the same email address that you subscribed. Text in the
Subject and
> Body of the message will be ignored.
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

Archiver

Hi Kyle,

I took the liberty to show you what I meant.
I redefined your variables as aliases and adapted
your routines subsequently. The program still does
the same, it now just occupies 266 bytes.
If you look closer to your bit/nibble/byte save and load routines
you see that they are basically the same, That's why I asked about the
separate
areas for bits, nibbles and bytes. Why not just bytes and use aliases to
define nibbles and bits when required?

Greetings peter


'SVM -- Stamp Virtual Memory -- version 1.3
'by Kyle "PYROManeyakk" Kronyak
'E-mail -- PYROManeyakk@h...
'{$STAMP BS2SX}
'
'
'
'
'This code is designed to greatly relieve the memory limitations
'set by the 32 bits of RAM allocated in the Basic Stamp modules.
'It works by storing the majority of used variables in the Stamp's
'"Scratch pad" memory. The limitations described below are set in
'the original written code, but can easily be modified:
'
'ALLOWED VARIABLES: Bits: 16 Nibbles: 16 Bytes: 16 Word: 16
'STORED IN AT ONCE: Bits: 8 Nibbles: 2 Bytes: 1 Word: 1
'
'RAM USAGE: 6 Bytes
'ROM USAGE: 266 Bytes
'
'
'The number of bytes can be extended by
'
'Below are the steps to load and save data:
'
'
'1.Set the slot you want by changing the value of currentl (0-15 are valid
by default)
'2.Set the type of data you want by changing the value of datatype (0-3 are
valid)
'3.Load the data by using -- gosub loaddata
' Data will be in vwordl, vbytel, vnib1 or 2, or vbit1-8 depending on type
'4.Perform necessary operations with loaded data using variable
'5.Place modified data in the variable it came from (vwordl, vbytel,
vnib1/2, vbit1-8)
'6.Save data by using -- gosub savedata
'7.Repeat as necesary


'word-related variables
vwordL var word 'word where data is loaded to/saved from

'byte-related variables
vbyteL var byte 'byte where data is loaded to/saved from

'nibble-related variables
vnib var byte
vnib1 var vnib.highnib 'first nibble loaded to/saved from
vnib2 var vnib.lownib 'second nibble loaded to/saved from

'bit-related variables
vbit var byte
vbit1 var vbit.bit0 'bits 1-8 loaded to/saved from
vbit2 var vbit.bit1
vbit3 var vbit.bit2
vbit4 var vbit.bit3
vbit5 var vbit.bit4
vbit6 var vbit.bit5
vbit7 var vbit.bit6
vbit8 var vbit.bit7

'storage-related variables
currentl var nib 'determines "save slot" number 0-15
datatype var nib 'determines bit, byte, word, or nib


loaddata:
if datatype > 3 then ukdatatype
if currentl > 15 then datoohigh 'because a max of 16 of each
variable are allowed,
'16 would be the 17th unit and
must be nullified
branch datatype,[noparse][[/noparse]bitload,nibload,byteload,wordload]

bitload:
if currentl > 1 then datoohigh 'because 2 clusters are allowed,
2 would be the 3rd unit and must be nullified
get 56+currentl, vbit
return

nibload:
if currentl > 7 then datoohigh 'because 8 pairs are allowed, 8
would be the 9th number and must be nullified
get 48+currentl,vnib
return

byteload:
get currentl,vbytel
return

wordload:
get currentl*3+16,vwordl.highbyte 'loads first data into RAM
get currentl*3+17,vwordl.lowbyte 'loads second data into RAM
return

datoohigh:
debug cr, "DATA ADDRESS TOO HIGH, PROGRAM TERMINATED!"
end

ukdatatype:
debug cr, "INVALID DATA TYPE!"
end

savedata:
if datatype > 3 then ukdatatype
if currentl > 15 then datoohigh 'because a max of 16 of each
variable are allowed,
'16 would be the 17th unit and
must be nullified

branch datatype,[noparse][[/noparse]bitsave,nibsave,bytesave,wordsave]

bitsave:
if currentl > 1 then datoohigh
put 61+currentl,vbit
return

nibsave:
if currentl > 7 then datoohigh
put 48+currentl, vnib
return

bytesave:
put currentl,vbytel
return

wordsave: 'calculates address locations,
put currentl*3+16,vwordl.highbyte
put currentl*3+17,vwordl.lowbyte
return

---

Oorspronkelijk bericht

---

Van: pyromaneyakk@h... [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=KMwEF6ueGLykovS-ooePqmb4clMA1dTtVhtoXOjcM5_LcLsLMbzryKdAlGv4OdresvetQxU0lkMJP7kuN-W7]pyromaneyakk@h...[/url
Verzonden: woensdag 11 juli 2001 13:59
Aan: basicstamps@yahoogroups.com
Onderwerp: [noparse][[/noparse]basicstamps] Re: Stamp Virtual Memory!

The reason I used the separate save/load systems for bits and nibbles
was simply to demonstrate a way to store the bits and nibbles within
the scratch pad's byte-only memory. The code was designed to be
modified to one's needs. It has all the necessary functions to store
all four types of data. Both RAM and EEPRom can be saved by cutting
out what's not needed, however it is there in case anyone needs it.


The idea is that is for when you need a lot of different variables.
Instead of having all of the variables named in the RAM and possibly
not having enough, you would share all data between one single
variable, eliminating the lack of RAM. Though more EEPRom space and
processing time is required, if you eliminate the bit and nibble
portions of my code, you can have up to 81 bytes of "RAM" (18 bytes
real, 62 bytes "virtual" scratch pad).