WP-34S: Safely copy a graphics register's contents

[Dave Britten]

I have a single-register graphic (6x6) I need to copy to another register. What's the safest way to do that regardless of current modes, or at least assuming standard DECM (H.d key)? Can I just do RCL 01 STO 00, or do I risk truncating the value? I know the graphics are stored as raw binary integer values. Or is there a single-step register-copy instruction I'm overlooking?

[walter b]

Dave,

just STO and RCL as you please.

Background: There are no data types in your WP 34S. You decide how it shall interpret the bytes stored: they may be read out as integers or reals or character codes though they will stay the same all the time.

d:-)

[Dave Britten]

(06-11-2014 08:54 PM)walter b Wrote:  Dave,

just STO and RCL as you please.

Background: There are no data types in your WP 34S. You decide how it shall interpret the bytes stored: they may be read out as integers or reals or character codes though they will stay the same all the time.

d:-)

Excellent, thanks Walter. Wasn't sure if recalling to the stack would change the value, or simply display it in the current format.

[walter b]

(06-11-2014 09:22 PM)Dave Britten Wrote:  Wasn't sure if recalling to the stack would change the value, or simply display it in the current format.

You're welcome, Dave. If you want to know more about it, please check App. B of the manual.

d:-)

[Paul Dale]

(06-11-2014 08:54 PM)walter b Wrote:  just STO and RCL as you please.

This is not reliable in DECM. Real numbers are normalised on store, this could change the graphic.

I think it will work in integer mode as the code currently stands but I wouldn't rely on it -- a mask and truncate to the current word size is a perfectly acceptable thing for the calculator to do on either STO or RCL.

Using one of the register swap commands twice will work too:

Code:

x<>
y<>
z<>
t<>

This won't preserve the source but is more likely to run into the future.

The most reliable way will be to use the block register copy command (R-COPY). That is what it is there for. Thus, something like:

Code:

# 001
SDR 002
# 001
SDR 005
+
R-COPY

- Pauli

[walter b]

Ooops, our baby's still carries some surprises. But, as my signature tells ...

[walter b]

Pauli, Dave was talking about just a single register graphic 'block'. Still critical? It's obvious I don't do graphics ...

d:-)

[Dave Britten]

Ah, R-COPY should be the secret ingredient I need. Currently the program happens to be running in BASE 10 64-bit word size when it does the STO/RCL, so it appears to work fine, but I'll change it to the safer method. Looks like I just need to call 1.01 R-COPY to do the job.

[Paul Dale]

(06-11-2014 09:56 PM)walter b Wrote:  Still critical? It's obvious I don't do graphics ...

Yes. The register can change on STO and RCL. The value contained within (as a real) won't but the bits could. The decimal64 and decimal128 formats don't have unique representations of numbers, so the code normalises them.


- Pauli

[Paul Dale]

(06-11-2014 10:01 PM)Dave Britten Wrote:  Ah, R-COPY should be the secret ingredient I need. Currently the program happens to be running in BASE 10 64-bit word size when it does the STO/RCL, so it appears to work fine, but I'll change it to the safer method. Looks like I just need to call 1.01 R-COPY to do the job.

You should be safe in 64 bit integer mode. Masking off the unused bits here won't change anything. The sign mode shouldn't matter but unsigned would be safest.

The base is display only so that won't impact the contents.

1.01 R-COPY can be written as # 101 SDR 002 R-COPY. This will save a couple of steps and be faster.


- Pauli

[Dave Britten]

(06-11-2014 10:11 PM)Paul Dale Wrote:  

(06-11-2014 10:01 PM)Dave Britten Wrote:  Ah, R-COPY should be the secret ingredient I need. Currently the program happens to be running in BASE 10 64-bit word size when it does the STO/RCL, so it appears to work fine, but I'll change it to the safer method. Looks like I just need to call 1.01 R-COPY to do the job.

You should be safe in 64 bit integer mode. Masking off the unused bits here won't change anything. The sign mode shouldn't matter but unsigned would be safest.

The base is display only so that won't impact the contents.

1.01 R-COPY can be written as # 101 SDR 002 R-COPY. This will save a couple of steps and be faster.


- Pauli

Okay, good to know about using unsigned mode. That makes more sense for this program anyway.

I think I'm going to stick with STO/RCL and make sure I'm running 64-bit unsigned. I realized have a need to compare the two register values to see if there's a change, and I'll need to get them onto the stack unmangled anyway in order to do that, so might as well just STO after I'm done comparing.

Thanks for the input guys.

[Paul Dale]

(06-11-2014 10:17 PM)Dave Britten Wrote:  Okay, good to know about using unsigned mode. That makes more sense for this program anyway.

It won't matter with the current code base. Integer mode doesn't change registers on STO/RCL.

Quote:I think I'm going to stick with STO/RCL and make sure I'm running 64-bit unsigned. I realized have a need to compare the two register values to see if there's a change, and I'll need to get them onto the stack unmangled anyway in order to do that, so might as well just STO after I'm done comparing.

I should have implemented a R-CMP? to compare blocks of registers


- Pauli

[Mark Hardman]

(06-11-2014 09:49 PM)walter b Wrote:  Ooops, our baby's still carries some surprises. But, as my signature tells ...

For those of us without a copy of the Bauer-Danker Lexicon and the skills to translate Plato's dialogues:

"For this is an experience which is characteristic of a philosopher, this wondering: this is where philosophy begins and nowhere else."

[Dave Britten]

Now this is weird. If I run the program in unsigned mode, it actually corrupts itself. A couple of steps near the end of program memory change in a consistent manner, breaking the program. If I run it in 2's-complement mode, this doesn't occur. Let me transcribe and upload a copy of the code so you guys can see it. It's not too long...

[Dave Britten]

Here's an Excel spreadsheet with the program (let me know if it turned out okay - I converted it from Numbers). It's a simple 6x6 cellular automata, specifically Conway's Life. The three steps highlighted in red are changed to other instructions if I run the program in unsigned mode. Very strange.

EDIT: Firmware version 3.2 3472, by the way.


  Blank.xlsx (Size: 457.97 KB / Downloads: 18)

[Marcus von Cube]

(06-11-2014 11:01 PM)Dave Britten Wrote:  Here's an Excel spreadsheet with the program (let me know if it turned out okay - I converted it from Numbers). It's a simple 6x6 cellular automata, specifically Conway's Life. The three steps highlighted in red are changed to other instructions if I run the program in unsigned mode. Very strange.

EDIT: Firmware version 3.2 3472, by the way.

That shouldn't ever happen!
Can you send a RAM image to the emulator and post the image file?

[Dave Britten]

(06-12-2014 01:15 PM)Marcus von Cube Wrote:  

(06-11-2014 11:01 PM)Dave Britten Wrote:  Here's an Excel spreadsheet with the program (let me know if it turned out okay - I converted it from Numbers). It's a simple 6x6 cellular automata, specifically Conway's Life. The three steps highlighted in red are changed to other instructions if I run the program in unsigned mode. Very strange.

EDIT: Firmware version 3.2 3472, by the way.

That shouldn't ever happen!
Can you send a RAM image to the emulator and post the image file?

I will try, but I won't be home for at least a week or two, and that's where my transfer equipment is. It does it consistently even after I RESET and pull the program back with PRCL. I'm too chicken to try running it directly from flash RAM and risk corrupting what I've got stored in there.

[Marcus von Cube]

(06-12-2014 01:25 PM)Dave Britten Wrote:  

(06-12-2014 01:15 PM)Marcus von Cube Wrote:  That shouldn't ever happen!
Can you send a RAM image to the emulator and post the image file?

I will try, but I won't be home for at least a week or two, and that's where my transfer equipment is. It does it consistently even after I RESET and pull the program back with PRCL. I'm too chicken to try running it directly from flash RAM and risk corrupting what I've got stored in there.

Don't worry, flash is pretty well protected! I'm interested in your RAM image anyway because I assume there is some kind of RAM corruption (internal stack overflow or the like) which bothers me.

[Dave Britten]

Alright, I'm back home with access to the necessary cables. If you can describe the process of backing up the RAM (or link to an appropriate instruction document), I'll see what I can do.

[Marcus von Cube]

You need to link your calculator to the emulator. The classic Windows emulator has an ini file (wp34s.ini) in its working directory which names the COM port e. g. COM1: on a single line. The Qt emulators have a menu option for this.

Now go to P.FCN, RECV on the emulator and P.FCN, SENDA on the calculator. The latter sends the contents of RAM to the former. You should see a success message on both screens.

Is your calculator equipped with the crystal and is it active? If yes skip this paragraph, if not enter a percentage in the X register of the calculator (only there!) to adjust the transmission speed before you call the SENDA command. Start with 90 and go up slowly until the transfer works. (This is the number you should note on the back of your calculator because you will need it for each transfer; only whole numbers are supported.)

After a successful transfer both calculators (device and emulator) should have the same status and programs. Quit the emulator and post the wp34s.dat file here. The file is in the emulator's working directory (classic emulator) or in your personal settings folder for the Qt emulators. If you do not want to overwrite the emulator's RAM image, just make a copy of this file before the transfer.