WP 34S: Beware of new builds



#8

Just to be warned: The next few builds will most probably be badly broken because we are working on a proper implementation of END. The latest revision I can recommend is 1940.


#9

More than the next few I suspect. END is very invasive and requires a lot more changes before it will work suitably.

For those with a morbid fascination, there is a TODO-END file which contains things Marcus and I know we've got to do, address and fix. How often this file is updated remains to be seen :-) Also, ignore the one DONE item -- that is being reimplemented a different way.


- Pauli


#10

OK. I am currently at 1782 - got to catch up. Thanks for the updates!

#11

It might work now, at least partially. Testers are welcome.

In program mode, the complete memory is available but as soon as a program is running or single stepped, END serves as a boundary. The detection of labels 00 to 99 and A to D is confined to the program the program counter is currently in.

Try GTO.up and GTO.down to navigate between programs.

Edited: 30 Nov 2011, 10:25 a.m.

#12

I've made some updates to the latest release so that END should now be working (hopefully). END statements define boundaries for local label search. This includes the hot keys A to D. The program counter needs to be in the program that defines the hot keys to make them active.

GTO.. in program mode goes to the last statement in program memory and adds an END if it isn't already there. In run mode, GTO.. simply goes to step 000. As a short cut, you don't need to press h shift. XEQ. is treated the same as GTO.

GTO.down and GTO.up take you to the next or previous program respectively. This is intended for program mode but may work in run mode, too. I tested it in also library space. All libraries are updated to contain END statements where appropriate. I have not tested this thoroughly, though.


#13

Hi Marcus. We sat next to each other at the last HHC. In talking about GTO.. how do you handle memory when editing a program? Will GTO.. pack memory like the 41C? Just curious.

Gerry


#14

We don't have holes in program space. The 41 does some magic to improve performance in editing and running a program. We just tackle the same issues with brute (processor) force. Moving memory back and forth doesn't cause the same delays it would on a 41 Nut processor. So no packing necessary.

No need to remind me on your HHC presence. I'm still remembering almost every little bit of these few days. :-)


Possibly Related Threads…
Thread Author Replies Views Last Post
  [WP-34S] Unfortunate key damage with update to V3 :( svisvanatha 5 3,300 12-10-2013, 11:37 PM
Last Post: Les Bell
  WP-34S (Emulator Program Load/Save) Barry Mead 1 1,878 12-09-2013, 05:29 PM
Last Post: Marcus von Cube, Germany
  DIY HP 30b WP 34s serial flash/programming cable Richard Wahl 2 2,608 12-04-2013, 11:14 AM
Last Post: Barry Mead
  WP 34S/43 ?'s Richard Berler 3 2,130 11-10-2013, 02:27 AM
Last Post: Walter B
  My FrankenCulator (wp-34s) FORTIN Pascal 4 2,251 11-09-2013, 06:18 PM
Last Post: FORTIN Pascal
  WP 34S Owner's Handbook Walter B 5 2,756 11-09-2013, 05:34 PM
Last Post: Harald
  wp 34s overlay and programming. FORTIN Pascal 6 2,990 11-08-2013, 01:28 PM
Last Post: Nick_S
  m.dy in display of WP-34S Harold A Climer 3 2,004 11-05-2013, 11:28 AM
Last Post: Andrew Nikitin
  WP 34s : An old problem coming back Miguel Toro 2 1,804 11-05-2013, 03:00 AM
Last Post: Marcus von Cube, Germany
  [WP 34s] Pressure Conversion Factors Timothy Roche 8 3,271 11-04-2013, 07:17 PM
Last Post: Dave Shaffer (Arizona)

Forum Jump: