Newest Wp34s ROM and backwards compatibility



#40

I tried a few minutes ago to update my wp34s. I had read that it breaks binary compatibility, but I wasn't sure exactly what that meant so I wrote down my programs, just in case. I flashed the machine the usual way, but it wouldn't work. It would turn on but lock as soon as I tried to press a key (except EXIT or one of the shift keys). After a moment of panic I tried re-flashing it, and this time it worked (this was my first failed flashing ever... weird that it did turn on and drive the display etc - so the flash wasn't totally dead - but it couldn't perform any operations).
Anyway, now after the second flashing, it appears to work, but the programs I had entered no longer work. Looking at the listings I see some commands have changed. Is this what "breaks binary compatibility" means? I suppose so, but I thought I'd ask to be sure it wasn't another failed flashing! :)
Is there a list of what commands might have changed, and to what?

Cristian


#41

Please look at the release notes on the last page of the manual. The change causing the break was in ALL.

Walter


#42

Walter, I know that the "offending" command was ALL (and I thank you all for changing it, as it behaves now exactly as I wished). My question though, was if anyone could tell me what commands in my old programs would have changed due to this "broken compatibility". I noticed that many commands changed, including RTN, aVIEW, PSE and others. A list of affected commands would have made easier for me to scroll through my installed programs, and change back the wrong steps. And this information isn't in the release notes.

EDIT:
@ Pauli: I see you have replied while I was typing the above message... Thank you! :)

Thanks again,
Cristian

Edited: 12 June 2011, 3:41 a.m.


#43

Not that it will help but 57 commands from ALL and down in the commands with arguments table will have moved. The 92 commands from RTN down in the commands without argument table have changed. Also the last 60 commands in the commands that take one argument table have changed.

Look at the sources (commands.c) to find the full list.


- Pauli


#44

Quote:
Not that it will help but [...]
Look at the sources (commands.c) to find the full list.

- Pauli


Thanks Pauli, that did actually help! With that information I could build that list myself.

Cristian


#45

Great. I could have reduced the number of changed commands, but since some where changing it seemed sensible to rationalise some of the more recent additions.


- Pauli

#46

Hi Cristian,

I am looking at building an assembler/disassembler that might help in a situation like yours. I am amazed at how productive Paul, Walter and Marcus are ALL THE TIME (when do they get a chance to do their pay-for-the-bread-on-the-table work??) and I will certainly not be rolling this out in a day or two but I hope it may help.

To answer your specific question about the changes, I discovered today that if I capture the screen output of the console version I can gather the opcode table. I have done this for both SVN 1077 and 1089 (identical to 1095). Indeed, the changes mentioned above show up quite clearly if you diff the outputs.

$ wp34s.exe calc xrom > opcode_dump.txt

I may have more in the command line than I need (I can find little information on how to work the console version) but at least this barfs out what you are looking for.

(Interesting, I normally use Ubuntu and redirecting the console does not seem to work under wine. I reverted to a Windows box to get the output. I would love to make the console for a native linux shell but I can't seem to figure out how to get stuff working that way.)

I would post the tables here but they are 477K each!

Cheers...


#47

Hi Neil,

Quote:
I am amazed at how productive Paul, Walter and Marcus are ALL THE TIME (when do they get a chance to do their pay-for-the-bread-on-the-table work??) ...

First of all we benefit from being a intercontinental team. So you ask questions in the morning - we can answer them from Europe. You ask in the evening, we can answer them from Australia. Taking into account we have an opportunity in the morning and in the evening at least, this alone allows a reasonable service level already. Additionally, not everyone in our team has had an 8-to-5 job all the time since December 2008. Things they are a'changing and keep doing so.

Walter


#48

Quote:
Additionally, not everyone in our team has had an 8-to-5 job all the time since December 2008.

Ouch!! Well, I am all the more impressed. Some company is missing some very talented people!

Best regards...


#49

If any jobs are floating around, I'm always interested :-)

Apart from a couple of months, I've had a full time job since we started...


- Pauli

#50

To answer the responsiveness question first, I feel like I've been working a second full time job these past couple of months :-) It isn't quite that bad but it feels like it. I be needing a break soon.

The console mode has a few special commands buried that were helpful for me to debug with.

calc xrom produces a formatted listing of the XROM contents. This is what provides solve, integrate, sum, product, the two derivatives, TVM, the quadratic solver, etc.

calc a prints out the catalogues and a summary of the defined op-codes. The a can be anything except xrom. Currently the summary looks like:

total number of opcodes 25627
niladic commands 150
monadic commands 119 with 178 functions
dyadic commands 37 with 65 functions
triadic commands 5 with 5 functions
argument commands 126
multiword commands 10
special commands 43

calc a a prints out all the legal opcodes and this is what you discovered. Again the a's can be anything. The only op-codes that aren't listed in full are the multi-character alpha ones (which includes LBL, XEQ, GTO, SOLVE, integrate, ...) They only get a single entry in the big list.

calc wake does a warm start. Not all that useful really.

Since you are running Ubuntu, I'd strongly suggest grabbing the source from subversion and compiling it locally. There isn't anything special required to build the console version (ncurses is the only thing that comes to mind beyond the basic development tools). Ubuntu is one of the platforms I developed this on.

Finally, there is no point reverse engineering this stuff, it is open source. Use the sources to build a disassembler which will be quite straightforward, then do the assembler. xeq.h defines the opcodes, commands.c is the canonical place for the command names. keys.c has a weird character to real character mapping function (but not the reverse). prt.c converts op-codes to printable commands. xeq.c has code to step forward and backward instructions and to grab op-codes from memory (multi character alpha ones being double length but this is all handled automatically). console.c has the main routine and the xrom disassembler in it. Make this task easy for yourself :-)

It would even be possible to build the assembler/disassembler into the console version to keep everything self contained.

- Pauli

PS: I really really don't want to renumber op-codes again.

Edited: 12 June 2011, 8:07 p.m.


#51

Thanks, Paul.

I have been using SVN since my second download (not much of stretch from my CVS experience). However, my skills at "making" C programs are not in your league unfortunately. I tried a few attempts at building the console version but gave up. I am afraid that I need a bit more "block A goes into slot B" type instructions. :-) I also have an aversion to modifying the wonderful code base you guys have put together as well. Seems somewhat sacrilegious to me...

However, I have been trolling through the source looking at how you did various things as an instructive process. I must admit that I do get lost a fair bit.

Actually, as you say, disassembling is pretty simple. My Perl script achieved that in short order. I parsed the output table from the console version and it is a fairly simple lookup to exchange the op-code for the mnemonic in the flash images.

The assembler is a bit trickier. It is not too difficult if one uses the mnemonic format listed alongside the opcode in the console-generated table -- but that is a bit of a clumsy format. I had hoped to build an assembler that parsed a few different formats.

That you have 1) whipped off a disassembler in remarkably short order, and 2) are considering extending it to an assembler, pretty much renders my poor script somewhat less than useful. :-) I absolutely agree that building off the existing code base makes more sense. Mine required a big, bulky opcode translation table (477K!) and thus a 2-step process if the opcodes ever changed. Sigh...

PS: Any extended hints for my poor brain on how to compile the console version would be highly appreciated! Otherwise I am stuck reverting to a Windows box to do this step.

Best regards...


#52

Building the code should be as simple as:

    cd trunk
make

It is possible that things will be missing, you obviously need make and a tool chain installed as well as ncurses-dev. But that should be about it -- the code is almost completely self contained. I avoided standard library calls in favour of rolling my own (smaller & probably slower) versions. Speed generally isn't an issue for this platform, space is.

The code isn't as well structured as I'd have liked, it started out pretty good but we've been through a few iterations of space saving and feature adding.

I've no firm plans to build an assembler at this stage. Just maintaining the existing code base and fixing bugs is keeping me more than busy enough.

- Pauli


#53

OK, I was feeling pretty stupid about this. When I ran make on Ubuntu I got an error making keys.c -- it can't find curses.h. (Like the name of the header file, I know how it feels :-)

$ make
gcc -c -Wall -Werror -g -fno-common -fno-inline-functions -fno-defer-pop -fno-exceptions -O0 -DUSECURSES -DDEBUG -o Linux/obj/keys.o keys.c
In file included from keys.c:20:
lcd.h:58:20: error: curses.h: No such file or directory
make: *** [Linux/obj/keys.o] Error 1

A bit of Google searching showed me I had to install the ncurses libraries:

sudo apt-get install zlib1g-dev libncurses5-dev

Then make would finish and in the ./trunk/Linux/ directory there is now an executable called "calc". So now I finally understand what you meant by "calc xrom" and "calc opcodes" when talking about the console. I hadn't connected the "calc" phrase with the executable because I was expecting the executable to be similar to wp34s.exe. I had thought they were command line parameters to the other console. Ahah! The penny finally drops... :-)

I am on 1115 and now I see a new more attractive format for the opcode table. A big thanks from me!! (You can ignore my post -- probably a bit *below* this one -- about suppressing certain fields.)

I'll give this one a whirl and see what I can come up with.

Cheers...


#54

Quote:
A bit of Google searching showed me I had to install the ncurses libraries[/quote[


I mentioned this :-)
Although I got the package name a little bit wrong :-(


[quote]I am on 1115 and now I see a new more attractive format for the opcode table. A big thanks from me!!


Hope it is useful. There might be some errors in it still but they'll come out in due course.


- Pauli

#55

I just added a disassembler to the console version, I knew it would be straightforward :-)

calc ram to disassemble RAM contents.

calc prog0 to disassemble the backup flash program region.

calc prog1 to disassemble the first user flash program region.

calc prog2 to disassemble the second user flash program region.

calc prog3 to disassemble the third user flash program region.

calc xrom to disassemble the internal user code program.


Will be in the next build.

Which just leaves an assembler :-)


- Pauli


#56

Quote:
Which just leaves an assembler :-)

Quote:
I've no firm plans to build an assembler at this stage. Just maintaining the existing code base and fixing bugs is keeping me more than busy enough.

I can fully understand your position on the assembler. I think you guys have definitely been burning the midnight oil. Don't think that we all don't appreciate it!

Given that you are not looking to do the assembler any time soon, I think I may just "keep on keeping on" with my Perl project. Last night I flashed 1099 using the slick "ON+STO" trick and, as noted elsewhere, my existing programs don't work anymore (I get a cool "undefined OP-COdE" message when running the program and "???" when I list it via single step in program mode). I fully understand why this happened but my little ditty should help anyone else in this boat. One feature of the tool is that, since it reads and parses the legal opcode table when it does its thing, it will be able to translate between opcode "bumps" via a common mnemonic listing.

As an aside, I much prefer typing out programs using a full editor and keyboard rather than on the calculator keyboard so I have an additional motive for doing this.

I am now on 1104 but when I tried your changes with the disassembler, it didn't seem to matter what I added to the command line, I always got a full dump of the legal opcodes. When I asked the console application for its version, it reported "34s 2.0 621"(!?). In spite of what I try, I can't seem to dump a test disassembly of "calc xrom", "calc ram", "calc prog0", etc. Is it possible I am I just too early on the SVN and you haven't committed it yet? (Maybe I am a bit too keen to use it. :^)

BTW: When I parse the legal opcode table, either from before the great schism (1077), or after (1095), my disassembler reports 2 duplicates: "CLx" at both 0001 and 0140, and "+/-" at 0003 and 0235. I am not sure if this is intentional or not. Just noting it.

Cheers...


#57

Those duplicates are intentional.

- Pauli


#58

Quote:
Those duplicates are intentional.

That is fine. I am presuming that the calculator doesn't care which version of the opcode it sees then. Once the binary is converted to a mnemonic form, it loses connection to the original opcode. (Is there a reason you can share/recall as to why just these 2 are repeated?)

I have a first crack of the assembler/disassembler up and running. In disassembler mode it reads the flash image and converts it to a text form very similar to the right hand side of the legal opcode table. There are a very few differences (such as the conversion factors being embedded in the opcode table) that have to be dealt with as exceptions but generally it is pretty faithful.

In assembler mode it is capable of taking in multiple mnemonic sources and seamlessly stitching them together into a single binary image. It recalculates and injects the CRC16 so no MAGIC_MARKER's are required.

I am not exactly sure how to load a single flash (ie: wp34s-0.dat) into the emulator so I did a seocnd little stop-gap script to overlay it on top of the emulator 'wp34s.dat' file which loads automatically. This works for now but I will experiment more with the actual H/W when I have some time. I am sure it is easy to do.

(Most) Everything seems to have worked beautifully except my program for calculating Great Circle routes now converts from nmi->AU instead of nmi->km! My legal opcode table came from 1104 and I am now running on emulator 1109 so I am thinking something may have changed between them -- something to do with stones and kg perhaps? (I haven't rebuilt a table as yet since that means moving back over to Windows -- ugh!).

Currently the script is parsing the legal opcode table to generate that hash table so I either need an external file (ugly solution) or I embed the table in the Perl script (cleaner solution but HUGE). Typically, I have split the difference and have both modes in the script. That has the advantage of allowing older flash images to be translated to the new opcodes by giving it an optional older legal opcode table.

Since there is a lot of repetition in the table (ie: SL 01, SL 02, ... SL 09, etc), I am thinking I can compress it with a bit of cleverness to get the script to a much smaller state.

I have tested it with a few programs I have written and a transcription of a program Jake Schwartz wrote: "wp34S IEEE Floating-Point Conversions". I have concatenated these with the tool in various orders and all seems well (except for astronomical units, of course :-)

I am not sure if anyone would be interested in trying an alpha of this Perl script or not. If so let me know and I will get it to you. There are certainly still things I need to test that will undoubtedly break (I have never done much with the alpha stuff as yet, for example).

Below is a fragment of the Jake's Floating Point program as I transcribed it from his note (mistakes are mine! hard to copy from 3 JPG images). I have added a few comments to help me keep things straight. These are ignored by the assembler. Also, the line numbers are ignored so you can easily concatenate several sources together into a single image (see below).

# From Jake Schwartz 7-June-2011 (near: http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/forum.cgi?read=185649#185649)
#
# Hand entered from 3 JPG's(!?) and converted to the opcode style shown in the legal opcode
# dump from the console app so there may be a mistyping or two.
#
# Keep the leading asterisk in front of the LBL's since that is a an easy marker to see and
# is easy to "clean up" in the assembler.
#
001 *LBL B
002 BASE 16
003 2COMPL
004 WSIZE 32
005 SL 01
006 ENTER[^]
007 ENTER[^]
008 x=0?
009 GTO 02
010 MASKR 24
011 AND
012 XOR
013 RCL L
014 x[<->]y
015 MASKL 08
016 x=? Y
017 GTO 04
018 R[v]
019 x=0?
020 GTO 03

Here is the above source fragment being assembled and the resulting output image dumped as hex:

$ wp34s_asm.pl fp.wp34s -o fp.dat; hexdump fp.dat
0000000 c782 00ab bb65 e410 0154 d520 da01 0000
0000010 0000 0017 be02 e318 0317 0319 8b6c 0107
0000020 e208 aa65 be04 0109 0017 be03 0107 dd18
0000030 bb01 cd66 0003 0107 d608 000e 000c 0302
0000040 cb66 bb02 0158 020f 0303 0002 0006 0005
0000050 0005 ae65 be0b 0107 013a bb0b 0002 000d
0000060 000d 0302 ca65 ca66 013a bb03 dd18 0107
0000070 be01 bb04 0109 0001 ab65 be05 0006 0009
0000080 000a 0000 bb05 0107 cd66 0003 dc01 0107
0000090 ca66 be02 bb64 001a ca01 001a 0003 0154
00000a0 0000 0017 0000 0017 be0d 020e 0008 0007
00000b0 0107 0302 0204 001c be0a 0006 0302 bb0a
00000c0 0000 020f 010a 0107 010a 0303 cf01 0003
00000d0 010a 0003 bb0d d538 e410 cb66 cb65 aa65
00000e0 013a 000e 0012 0301 0107 cb00 001a ca00
00000f0 0205 0107 001a be63 0006 0301 bb06 8463
0000100 0109 d520 000d 0005 0301 e218 0317 ce66
0000110 b863 da01 8b63 0014 0014 af65 be07 0107
0000120 0109 0109 0001 010a 010a ca65 bb07 0109
0000130 0318 cd00 dd08 d709 cb66 013a bb09 0205
0000140 0008 0005 ae65 0107 0109 0005 dde5 0107
0000150 0109 0304 0005 be06 8303 8303 8303 8303
0000160 8303 8303 8303 8303 8303 8303 8303 8303
*
00003f0 8303 8303 8303 8303 0000 0000 0000 0000
0000400

To close the loop, a fragment of disassembly of this resultant flash-compatible image:

$ wp34s_asm.pl -dis fp.dat | head -20
001 LBL B
002 BASE 16
003 2COMPL
004 WSIZE 32
005 SL 01
006 ENTER[^]
007 ENTER[^]
008 x=0?
009 GTO 02
010 MASKR 24
011 AND
012 XOR
013 RCL L
014 x[<->]y
015 MASKL 08
016 x=? Y
017 GTO 04
018 R[v]
019 x=0?
020 GTO 03

To stitch multiple source together is simply a matter of giving it more than one source. I haven't tested the 506 opcode limit yet but it should correctly crap out if this is exceeded.

$ wp34s_asm.pl fp.wp34s gc.wp34s -o fp_gc.dat

I still have a few things I want to do (detect duplicate labels, maybe allow an alternate [more friendly] mnemonic format, etc.) but I hope someone might find this useful. [Warning until I can compress the opcode table, the script is *BIG* at 465K!]

If people are interested, and I can be coached on how to do it, maybe it can be uploaded to a public site in due course.

Cheers...


#59

Quote:
I am presuming that the calculator doesn't care which version of the opcode it sees then.

Actually it does -- they go to different pieces of code.


Quote:
Is there a reason you can share/recall as to why just these 2 are repeated?

For CLx one code is generated one entering the command line and the other when not. This catches backspace to edit the command line which isn't legal in a program. I forget the difference between the two CHS commands but I think it is something similar.


You are correct the conversions got an entry added early in the table which I'd forgotten about. Most of these will have changed too.


Quote:
I still have a few things I want to do (detect duplicate labels, ...)

Duplicate numeric labels are legal and useful -- XROM is full of them e.g. Duplicate alpha labels also have a use but it is more esoteric -- again XROM defines [delta]X which is meant to be overridden by a user version on occasion.


- Pauli

#60

Neil, your tool should definitely be part of wp34s. Get in contact with Pauli how this can be achieved. SF is our home and so should be yours. We might even create a step in the build process that ensures a valid command table is present.

The wp34s-n.dat file (n being a number from zero to 3, maybe more later) is automatically read in by the emulator on startup. Just create a program with an alpha label and use CAT to find and execute it. With PRCL n or P<-> n you can load this into RAM where it is modifiable.

How to get this into the real machine is described in the manual and in a small text file "flash.txt" in the doc directory. In short: Use SAM-BA and load the file to a location 0x11EC00 or above.

For ROM images I prefer 0xFFFF as the dummy opcode to fill the image because this reduces the number of bits flipped with flash programming.


#61

I'm confident we can modify the build process or add a utility to output the command table in a better format. As mentioned, there is a lot of repeated entries. I might add something to output the base op-codes only with a tag if they take an argument.

Does the assembler deal with multi-character labels properly? Only the first such op-code (& even then only two of the four bytes) is listed in the op-code dump.

One thing I would love to see is automatically converting branches into SKIP & BACK instructions where possible.


- Pauli


#62

Try "calc opcodes" in the latest console build :-)

Fields are tab separated.

The first field is the numeric op-code in hex.

The second field is the type of op-code. cmd is a standard command. mult is a multi-character alpha command (double length). arg is a command that takes an argument.

The third field is the op-code itself.

For argument commands there is a fourth field that can contain up to four pieces of information comma separated:

max=nnn nnn is the maximum value + 1 permitted as an argument. I.e. legal arguments are 0 through nnn-1 inclusive.

indirect is present if the command is permitted an indirect argument. If it is, the argument can of course be any register including the stack (0 - 111 inclusive).

stack is present if a stack register is allowed as an argument.

complex is present if the argument specifies a complex pair of registers. This basically restricts numeric registers to be 0 - 98 instead of 0 - 99 and it restricts lettered registers to be X, Z, A, C, L and J.


- Pauli


#63

This is great! The script has imploded from 477K to ~47k with this simple table change. So far I am having the script expand this new table -- on the fly -- back into something akin to the original format so I don't have to change many other sections of the code.

A couple of observations:

1) Is "stack" actually required? I can see no case where "stack" is indicated that "max=112" is not. Therefore I am presuming that any value of max=112 already includes the stack registers. I may have missed something...

2) Similarly, is "complex" required? In all cases, the prefix "[cmplx]" appears in the mnemonic for these as well.

3) I am not really sure how to deal with the very 1st "arg" line: "0x8200\targ\tiC\tmax=30,indirect". The indirect portion is easy, but how to encode the others (opcodes 8200 -- 821d, inclusive)? Is it your intention that these should be expanded to be "iC 'some-bunch-of-digits'" in a listing, and conversely, that "iC 'some-bunch-of-digits'" in an assembler source file be translated back to 80xx, where 0 <= xx <= 1d? If so, then this new format is missing some information and it will have to be entered through other means. As an alternative, maybe you could split out these 30 'direct' opcodes as "cmd" type and the others as "arg" types something like this:

0x8200  cmd  iC 0
0x8201 cmd iC 1
0x8202 cmd iC 5.01402
...
0x821d cmd iC iC 0.14773910
0x8280 arg iC max=0,indirect

Note that I have used spaces in the above section where you are using tab delimiters. I can't seem to represent tabs in this editor.

4) I am wondering why there is the inconsistency in the letter-named offsets. For the max=112 set, the letters are XYZTABCDLIJK (indicating opcode offsets of 100-112) and for the max=104 set they are ABDC (indicating opcode offsets of 100-103). Have you considered normalizing these to ABCDXYZTLIJK? Then there is a commonality between the two sets. No biggie but it means fewer exceptions. FAIK it may break huge swaths of other code in the calculator. If this doesn't make sense, obviously don't worry about it.

I am still coding but these are some of my thoughts thus far.

Best regards...

(BTW:
Vancouver lost 4-0! Ouch!!)


#64

1. Stack is the internal flag indicating that the stack can be used. I'd honor this rather than relying on 112. E.g. the complex operations that accept a stack argument could have their max reduced to 111 (& probably should do since 112 is completely meaningless for them and would walk memory if it was encountered).

2. Complex likewise, although I don't see a case for this (yet).

3. I can expand these to cmd status easily enough.

4. The funny numbering is the result of changes over time :-( I don't want to "fix" this now.


- Pauli


#65

1. Fine.

2. Likewise.

3. Actually, for consistency, can you make the base hex number for the "arg" component 0x8200 instead of 0x8280 like I originally suggested? This allows the indirect flag bit (0x80) to work transparently with these ones as well. I realize that this will "look funny" since both the first "cmd" element and the "arg" element will have the same hex value but it keeps things the same.

I suppose that, according to (1), the "arg" element should now have ",stack" as well?

(I have hand edited a copy to work on for now -- shown without the ",stack" until I hear back.)

0x8200	cmd	iC 0
...
0x821d cmd iC 0.14773910
0x8200 arg iC max=0,indirect

4. Don't blame you one little bit! :-) Just thought I'd ask.

#66

Quote:
I'm confident we can modify the build process or add a utility to output the command table in a better format. As mentioned, there is a lot of repeated entries. I might add something to output the base op-codes only with a tag if they take an argument.

If you are considering barfing out a table, can you removing (or containing) the extraneous information to the right of some of the mnemonic areas (eg: in the constants such as "# a\s+365.2425" and the conversions such as "kg[->]lb\s+/ 0.4535924")?

If you need to keep this data for some other process, could you put the right hand stuff into some kind of comment field (I'd suggest the C comment marker of "//" for now), then this table would be easier to parse without resorting to exceptions?

Best regards...


#67

Check out the new calc opcodes command. I think you'll find the output easy to parse.

- Pauli


#68

Yes indeed!! A few messages *above* you will see that I finally lifted my fog about getting the console built on Ubuntu and that helped understand what you have been saying to me for a fews days just suddenly fell into place. I am remarkably dense sometimes.

I have started to attack the new format but the Vancouver Canuks are about to take on the Boston Bruins in the 7th game of the Stanley Cup finals for the North American ice hockey trophy. I am afraid that Perl will just have to wait! :-)

Go Canuks Go!!

Cheers...

#69

Quote:
Does the assembler deal with multi-character labels properly? Only the first such op-code (& even then only two of the four bytes) is listed in the op-code dump.

Early days yet but I think it handles the 3-character ones (eg: LBL'FTH). The alpha texts are exception-handled to inject a second word with the 2nd and 3rd characters. I haven't tried alpha stuff so that might not work so great as yet. (Not sure I fully understand alpha mode at all :-) -- I am a pretty rank beginner with this level of calculator. I am afraid I am going to need Gene's "WP34S for Dummies" when it comes out!!)

Quote:
For ROM images I prefer 0xFFFF as the dummy opcode to fill the image because this reduces the number of bits flipped with flash programming.

As you can see from the alpha labels example below, a custom fill is a trivial change. I was just following what I observed in the existing images I have to work with -- which injects "ERR 03". (BTW: What is the purpose of the 4 trailing words of 0 at the end of each image?) A spec for the image would be lovely. :-)

$ cat multichar.wp34s
LBL'ABC
INT'12K
RTN

$ wp34s_asm.pl multichar.wp34s -o multichar.dat -f FFFF; hexdump multichar.dat
0000000 3fde 0006 1041 4342 1931 4b32 013a ffff
0000010 ffff ffff ffff ffff ffff ffff ffff ffff
*
00003f0 ffff ffff ffff ffff 0000 0000 0000 0000
0000400

$ wp34s_asm.pl -dis multichar.dat
001 LBL'ABC
003 INT'12K
005 RTN

Quote:
One thing I would love to see is automatically converting branches into SKIP & BACK instructions where possible.

This could be possible. Might require a 2-pass assembly where this is currently only a direct translation, single pass version (very dumb coding at the moment, I'm afraid).

Can you explain a bit more about duplicate labels and how the calculator handles these? I can't seem to understand how they can be "local" to a function. Makes my brain hurt.

That the emulator just reads in the wp34s-[0-3].dat file is so cool! That they are available to execute directly from flash via the CAT is brilliant! I never would have expected that. I probably didn't notice this since I tended to use the A-D labels more as opposed to the alpha ones. As was mentioned, the alpha ones in flash programs show up in CAT. (Goodbye my script to temporarily overlay the wps34.dat file!)

Cheers...


#70

Neil, go to the file data.h where the formats of all data structures in RAM and the flash regions are defined. The maximum number of program steps is 4 less then would fit in one K because we need this space for other purposes in RAM. The flash regions have the same structure as the start of RAM has. Thus, 8 bytes are wasted in each region. It is totally fine to fill this space with 0xff.


#71

Quote:
Thus, 8 bytes are wasted in each region. It is totally fine to fill this space with 0xff.

Would it be possible, when executing the "SAVE" command (or equivalent) that the calculator inject the SVN version number into some of these unused fields? This would certainly help with archiving flash images and could facilitate an automatic assembler feature to either correctly deal with the revision, or at least issue a warning of some possible impending dome due to opcode revision mismatch.

Cheers...


#72

Neil, this is not possible for image 0 because here, the complete RAM image is saved and I cannot modify single fields which have a different meaning on restore (this is the program return stack to be precise).

I don't think it's worth the hassle. Pauli has promised to leave the op-codes untouched.


#73

OK. It was just a thought. Would have been a nice archival tool. :-)

It was under the assumption that these last 4 words are actually DONT_CARE in the flash images (they always appear as 0000 0000 0000 0000 in flash images generated by SAVE -- IIRC).

Q: Does my DONT_CARE assumption still hold for 0 through 3 based on what you have said? Or is this DONT_CARE only valid for 1 through 3?

I think Marcus had mentioned that a flash-efficient FFFF was a possibility for these last 4 words, but I don't recall if he mentioned a limitation on which images ([0-3]) would allow this.

I'm always learning... :-)

Best regards...


#74

To make a long story short:

If you use PSTO and PRCL the trailing data isn't used at all. So FFFF is totally fine.

If you replace the program part of image 0 (the backup) in the calculator or emulator and restore the backup with LOAD (or ON+RCL on the hardware) you will have some inconsistency in the return stack. This is normally of no importance but may cause some irritation if you execute a RTN statement directly after the restore. I think this can be safely ignored but Pauli may explain it in more detail (the return stack is his.)


#75

The bottom two banks (register and PSTO 0) are special. They really contain the 2kb of RAM in the device and there is no free space. The other program banks have a small amount free. Which is the space for the user program return stack in bank 0.


- Pauli

#76

Quote:
Can you explain a bit more about duplicate labels and how the calculator handles these? I can't seem to understand how they can be "local" to a function. Makes my brain hurt.

Try page 12 of the manual for a description of the label searching.

In a nutshell, numeric labels (and hotkeys) are local to the program region. The search runs from the current location forward until the end of the segment and then from the start of the segment forward until the initial location is reached. For forward jumps it is generally fine to duplicate a labels. For backward jumps it isn't. A lot of HP-41 programs re-use the low numbered labels quite heavily because they are shorter. In the 34s, the XROM code uses this feature quite a bit to save on the number of labels defined.

Alpha labels are searched for in a specific order and only the first match is used. Thus, these can be duplicated but there is no point duplicating them within a program region (RAM or flash bank) as only the first will ever be used. This allows e.g. a user to override a library routine. The example I gave was the deltaX label in XROM which specifies the step size for the numeric differentiation code. The label in XROM returns a 0.1 value. You, as a user, can define a deltaX routine in RAM of one of the flash banks and this will be used in preference.


- Pauli

#77

Yes, some of the commands in your existing program changing their name is an indication of the command restructure.

The new ALL command takes a parameter which meant it went into a different table than the old command. This upset the command numbering so commands after its old location in that table will have moved up one position.

Since existing programs likely wouldn't work I took the opportunity to relocate a couple of other commands that had been put out of place.


I'm going to try very hard not to have to do this again.


Pauli

#78

Quote:
Is there a list of what commands might have changed, and to what?

No, I've not made such a list :-) Lots of commands will have moved. Most commands that take their arguments from the stack should be unchanged. Many of the rest will have changed.


Pauli


Possibly Related Threads...
Thread Author Replies Views Last Post
  9014B Sony Part Number Compatibility aj04062 0 127 11-08-2013, 05:59 AM
Last Post: aj04062
  Compatibility of new HP PRIME Cable Harold A Climer 8 374 10-13-2013, 01:14 PM
Last Post: Eric Smith
  HP10C series battery door compatibility? Bruce Larrabee 6 319 08-11-2013, 05:42 AM
Last Post: Bruce Larrabee
  HP85 Programmable ROM cardtridge 82929A-service ROM not working- inaki 2 226 04-25-2013, 08:08 AM
Last Post: inaki
  HP-17bII+ Solve Compatibility Issues Robert Prosperi 7 377 04-22-2013, 10:11 PM
Last Post: Gerson W. Barbosa
  [Clonix/NOV] NoV-64 backwards compatibility Doug (NYC) 0 145 01-20-2013, 11:21 AM
Last Post: Doug (NYC)
  Newest 41CL ROM Images Dan Grelinger 2 161 01-16-2013, 01:25 PM
Last Post: Monte Dalrymple
  shelf life time of a ROM, EEPROM, EPROM vs Mask Rom Guido (Canada) 6 360 01-11-2013, 04:09 PM
Last Post: Thomas Falk
  Big ROM - 41 System DEMO ROM Ángel Martin 5 352 10-16-2012, 05:28 AM
Last Post: Ángel Martin
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 157 10-04-2012, 04:59 PM
Last Post: Paul Dale

Forum Jump: