Data Storage on SX - strange characters in data
Mrdavidjenkins
Posts: 49
Good Morning,· I am having trouble with a little storage algorithim I have written for the SX.· I have a 32 byte long data stored in the SX first 32 bytes.· This data is a mix of words and bytes.·· What I want to do is take the data from locations 100 to 868, move it to 132 to 868 and·discard the last 32 bytes.··I will write this data into storage into the "6th" 2K program storage of the sx.·
Problem is - I get data moved up and then the new 32 bytes put in, but the data looks really goofy - I get special characters in some cases.· Some of the data is recognizable, some not.·
I'd guess that the problem is hex related, but I am not sure.· It might be using a combination of words and bytes, but I would think that copying bytes·from·one location to another would not be a·problem.· Attached is·an example file.·
Why am I getting incorrect looking data in this program? Thanks
Problem is - I get data moved up and then the new 32 bytes put in, but the data looks really goofy - I get special characters in some cases.· Some of the data is recognizable, some not.·
I'd guess that the problem is hex related, but I am not sure.· It might be using a combination of words and bytes, but I would think that copying bytes·from·one location to another would not be a·problem.· Attached is·an example file.·
Why am I getting incorrect looking data in this program? Thanks
Comments
·· From looking at your code I gather 2 things.· First it seems like you're running this program from one in another slot.· I'm not clear on whether the operation of the other program has any affect on this one, but let's assume it doesn't.· Second, you're possibly making things more complicated than they need to be.
·· You said you need to copy data from locations 100 to 868 up to 132 to 868, discarding the last 32 bytes.· One counter (FOR...NEXT loop) could easily do this.· The question is, what are the source and destination banks?· I got the impression you were moving the data from one bank to another, but your code doesn't support that, only within the current bank.
·· If you could elaborate on exactly where the data needs to go I'm sure I could write something up to demonstrate how this could be done.· In fact, I will attempt to show you one possible way below...Give me a few minutes to add the code.
If the data needs to be moved from one bank to another, that just requires adding the STORE command before the READ and again before the WRITE to specify source and destination banks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
Post Edited (Chris Savage (Parallax)) : 8/19/2005 2:34:02 AM GMT
BTW, you are correct, I am using two slots. I am using the first 32 bytes of scram to update the existing data to keep a set of the last 24 hours of a operation. The first bank loads the data into scram, then calls the second slot and the second slot takes the data from scram, appends it to the running stack of 24 records, and delete the oldest data.
·· You are referring to the SPRAM (ScratchPad RAM), but I didn't account for that in that piece of code.· The code I listed was solely for moving the data up 32 bytes, truncating the last 32 bytes of the source, in effect.· If you then need to copy the SPRAM to that 32 bytes at the beginning we skipped over, then you could use code like below.
·· This code makes two assumptions...First, that you intended to move 32 bytes from 100-868 to 133-868, since that's the only way you'll have 32 bytes of space that won't over-write the data you just moved.· Second, by looking at your original code, it appears you are using ScratchPad RAM starting at location 1 instead of location 0.· Perhaps if I knew exactly how much data was in the original block, and how it was organized, I could see a better way.· 768 divides down into 24 blocks of 32 bytes, but the way you were moving data it would be partially over-written, from what I can tell.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
I was thinking of but Chris posted before I got to writing anything. Anyways I just looked back over Chris's code and noticed that there was a slight logic error in it. The code that was posted will repeatedly store the first 32 bytes thought the entire space that it writes two, because it writing to memory addresses and then reading them after they have stored the new data, thus causing a continual loop. To get the code working properly just switch the '132' and '868' around, the new code should look like this.
(Also one other thing that I noticed, both in both sets of code is that they seem to be moving an extra byte. If I read your description correctly, you are storing records of data that are 32 bytes long, so if the first record starts at location 132, then the last byte of record 23 should be 867, not 868. Not that this really affected the data, just thought I would point it out.)
JLBShecky
·· You are correct.· I guess last night I was still stuck on the concept of moving the data from one bank to another, and eventually I took out the STORE commands and didn't think about the consequences of that!· · Thanks for catching that.· I noticed I was also off by 1 in my calculation for the number of bytes to move.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com