ASCII() statement equivalent in basic stamp?

CuriousOne

Hello.

Other basic syntaxes have ASCII() statement, which returns apropriate ASCII char of statement supplied.

For example:

A=ASCII(33) equals to A="!"

How should I do this in BS2 ?

Need to create custom data type and do lookup each time?

Mike Green

There is no ASCII() function or equivalent because there is no string data type in PBasic. All values (including characters) are 16-bit integers. Sure, you can have variables that take up less storage ...You can have individual bits, 4-bit nibbles, 8-bit bytes, and 16-bit words, but those are the storage units. In expressions, everything is a 16-bit integer. That includes characters which are treated as their integer value (like "!" is 33). You can write character strings in certain specific statements, but they're treated as arrays of byte values for the purpose of that specific statement if they're more than a single character and you can't assign one array to another or compare two arrays.

So, there's no ASCII() function because you can write a single character like "!" and it will be treated as a number like 33 or $21.

CuriousOne

so, code like:

FOR A=32 TO 255
NAME$=NAME$+ASCII(A)
NEXT A

is impossible with basic stamp?

Then how to handle user input? say user inputs his name on keypad ?

Mike Green

That's correct. You can't do that the way you've written it on a Basic Stamp.

There are some examples of such things in some of the Nuts & Volts Columns. Essentially, you declare a byte array long enough for the user name and write the code to input characters one at a time and store them as characters in the byte array, usually marked at the end with a zero byte. You run into difficulties with potentially long user names because of the limited variable storage on the BS2 (only 26 bytes total).

For long strings, you have two options ... You can use part of the program EEPROM to store the characters using the READ and WRITE statements. You're limited somewhat there because of the potential for the EEPROM to wear out with repeated writing. In practice with keypad / keyboard inputs, this doesn't happen since it takes a very long time to enter in over 100K keystrokes (the usual wear limit for an EEPROM location). Alternatively, you can use a different Stamp model that has additional RAM storage. The BS2p/pe/px models are best for this. This extra RAM is not directly usable for variables ... you use GET and PUT statements to access it.

Chris Savage

In all fairness, what you're asking is technically done without the ASCII conversion. If you print a 32 to the screen, a space is printed. So if you create an array with those code and then display the array it will already contain the alphanumeric text you've encoded. Note though in your example you've gone past 127, so results will vary depending on the device (such as the Parallax Serial Terminal or an LCD) you send these bytes to.

CuriousOne

It was just an example, and quite often we do need string variables as well as ASCII () STR$() and other string variable related statements. Why it was not implemented in basic stamp?

Mike Green

Why no string variables in the Stamps? Probably because of the very limited memory available for variable storage (26 bytes for the BS2, even less for the BS1). Remember that each string character requires a byte of storage.

CuriousOne

Variable storage you mean RAM, built-in EEPROM or ?

I have a Synth keyboard, Yamaha PSR E-413, made in 2011. Quite sophisticated, with many many MIPS DSP and CPU. And with whopping 436kb(!) of user usable EEPROM, which is being accessed via emulated serial port via USB at 9600bps! Situation looks very similar to BS

Speaking seriously, are there even a small chances that string variables ever to be added?

Mike Green

Seriously, I would not wait for string variables to be added to the Basic Stamps. The microcontrollers used simply do not have enough memory to make it practical. The BS2, for example, has 26 bytes of RAM and 2K of EEPROM. The BS2px has additional RAM areas (not directly accessible for variable use) and 16 x 2K EEPROM "slots" which effectively hold fairly independent programs with shared variables ... there's no real subroutine calling between these "slots", so it's not like you can split up a program into 2K pieces and have them call each other.

The Propeller, on the other hand, has 32KB of memory that is shared between variables and compiled code. In addition to Spin, which has limited built-in support for string variables and lots of library routines to add additional functions, the Propeller can use C which has standard C libraries for strings. In both Spin and C, strings are implemented as byte arrays with zero-byte delimited strings.

The Propeller II, which is still under development, has much more memory (128K split into mostly RAM and a little bit of ROM) and speed and will also support Spin and C.

CuriousOne

But it won't have basic support , right?

Mike Green

Well, there's sort of Basic support. There's a quite slow, but functional integer Basic (FemtoBasic), but it doesn't really have string support. OldBitCollector has been expanding it, adding new features, and it has a very limited form of string support. There's PropBasic which compiles into Spin and has some very limited string support. You can run a Z80 emulator on the Prop-1 and run several different Basic interpreters and compilers with very reasonable performance and full string support. There have also been some experiments with Basic interpreters written in C compiled for a Prop-1 using external SRAM or flash memory with caching of external code pages. It's a bit slow, but probably could be sped up with time and work.

CuriousOne

Thanks!

Running Z80 emulator means that I can upload a ZX Spectrum rom and...

Mike Green

I don't know about the ZX Spectrum. You'll have to ask around and do some searching. The posted code is for running CP/M with a PS/2 keyboard, TV (video) text display, and files on an SD card for emulating floppies and/or small hard disk.