HP Forum Archive 15

[ Return to Index | Top of Index ]

Self-modifying programs for HP-41 Message #1 Posted by Geir Isene on 4 Nov 2005, 1:49 p.m. One of my first real programs on a calculator was a self-modifying program for the TI-59. Even its ancestor, the SR-52 had this capability of self-programming. I now need the same feature on my HP-41. I am looking at creating a small Petri Net (see http://en.wikipedia.org/wiki/Petri_nets) engine for the 41. Due to speed constraints on the 41 and because I would like to conduct Monte Carlo runs of the Petri Nets, I need the calculator to be able to devise a program from certain user inputs and then run the program a number of times in succession, then give the statistical outputs. Any suggestions?

Re: Self-modifying programs for HP-41 Message #2 Posted by Vieira, L.C. (Brazil) on 4 Nov 2005, 3:40 p.m., in response to message #1 by Geir Isene Hi, Geir; not a solution for your case, I guess, but the AECROM (a custom ROM) has a program generator that builds programs from expressions writen in the ALPHA register. The program asks for the names of the variables that must match the names in the user expression ('formula'), so it creates the PROMPT's, and the resulting value is also labeled accordingly. Hope this gives you some guidance. Cheers. Luiz (Brazil)

Off Topic Message #3 Posted by Gileno on 4 Nov 2005, 4:51 p.m., in response to message #2 by Vieira, L.C. (Brazil) Luiz, would you have lex files in the format 9114B?

Re: Off Topic Message #4 Posted by Howard Owen on 4 Nov 2005, 4:57 p.m., in response to message #3 by Gileno What OS are you using on your PC?

Re: Off Topic Message #5 Posted by gileno on 4 Nov 2005, 5:39 p.m., in response to message #4 by Howard Owen Windows 98Se Do I format using 256 or 1024 bytes? Thank's Edited: 4 Nov 2005, 5:40 p.m.

Re: Off Topic Message #6 Posted by Howard Owen on 4 Nov 2005, 11:27 p.m., in response to message #5 by gileno The 9114B writes 256 byte sectors. PC hardware is capable of doing the same. It works under DOS and Linux on my ancient Compaq, and under Linux on a less ancient low end Dell server. But some combinations of floppy controller/system software seem to have trouble with the format. I do know that your chances of success are increased if you format the disk on the 9114 before trying to write to it from DOS. Also, covering the quad density hole is critical. The PC will try to read and write at that density if you don't, and that will fail to produce disks readable on the 9114 every time.

Re: Off Topic Message #7 Posted by Garth Wilson on 5 Nov 2005, 1:58 a.m., in response to message #6 by Howard Owen In my not-so-recent experience, what was written by the high-density drives was not readable by the only-double-density drives. It makes sense, if you think about the narrower head of the high-density drive recording over just the middle of any given track played by the double-density drive, leaving old data at the edges of the track, data which would conflict with the new material. Maybe it would work if you started with a disc that either had never been recorded on or had been erased with a bulk eraser. Someone who knows more about disc drives' insides might have some comments or corrections to offer, but this was my experience at my last place of work when the high-density floppies were just coming in and we had both densities for awhile in the late 1980's.

Re: Off Topic Message #8 Posted by Howard Owen on 5 Nov 2005, 2:57 a.m., in response to message #7 by Garth Wilson Except it actually works for me. Not only can I write a DS/DD image on a DS/HD drive, and onto either DS/HD or DS/DD media, I can write SS/DD media as well. It works on one of my systems and not another, as I mentioned, so it may be that differences in the width of the data written are in play. But it could as easily be that the non-working drive has been cursed by the floppy fairy, as far as I can tell. That is, I have no idea why it works in one case and not in another. All I can do is report my results.

Re: Off Topic Message #9 Posted by Howard Owen on 4 Nov 2005, 5:15 p.m., in response to message #3 by Gileno If you have Windows or DOS, do the following: Format a disk in your 9114B. If you are using standard PC DS/HD floppy disks, tape over the density select hole. (The one opposite the write protect tab.) before moving the disk over to your PC. Download LIFutil from the museum ftp server. Use it to write DOS files to your 9114B-formatted floppy disc. Done! This works on one of my PCs (an old Compaq Pentium) and not on another (a Thinkpad A22P) so your mileage may vary. If it doesn't work on your machine, try a friend's.

Re: Off Topic Message #10 Posted by Vieira, L.C. (Brazil) on 4 Nov 2005, 6:13 p.m., in response to message #3 by Gileno Hi, Gileno; are you well? I have an 9114B, one HP71B with IL module, one HP75D and the HPIL for the HP41, but I mainly use the 9114B to store data and programs (in native language) for each of them. I have not worked with LEX files yet, sorry. I'd like to help. As I see, others have already followed you up. Success! Luiz (Brasil)

Re: Self-modifying programs for HP-41 Message #11 Posted by Raymond Del Tondo on 4 Nov 2005, 7:04 p.m., in response to message #1 by Geir Isene Hi, for easy and powerful input/output features, use the CCD ROM. For easy and powerful user program memory manipulation, also use the CCD ROM. As Luiz noted, the AECROM has the unique feature of a program generator, so maybe that could help, too. However, if there's a way to avoid self-modifying programs, I'd go that way. There are always ways to use parameters as 'modifiers', without hacking the code itself. Wouldn't that be a challenge to write your program that way? In the early HP-48 days, there were some French self-modifying programs, which caused nothing but trouble to the system integrity, likely to make the system unstable. OMHO;-) Raymond

Synthetic programming (was: Self-modifying programs for HP-41) Message #12 Posted by Vieira, L.C. (Brazil) on 4 Nov 2005, 10:47 p.m., in response to message #11 by Raymond Del Tondo Hey Raymond, guys; I remember quite well that, by using synthetic manipulations, the size of the HP41 could be changed without altering memory contents, i.e., lowest numbered registers with NNN contents would have its contents considered as program instructions after reducing SIZE accordingly. I remember reading Wickes` Synthetic Programming on the HP41 where he mentioned something like `Imagine programs creating programs.` Although tricky and mind boggler, this can be done. I myself tried a few. It works, no doubts about, but I think that the necessary manipulations may not be worth doing. Cheers. Luiz (Brazil)

Re: Self-modifying programs for HP-41 Message #13 Posted by Geir Isene on 5 Nov 2005, 5:48 a.m., in response to message #11 by Raymond Del Tondo Quote: There are always ways to use parameters as 'modifiers', without hacking the code itself. Wouldn't that be a challenge to write your program that way? I know, this is the way I would usually program in Ruby or Forth. But for the 41, the speed would make this undoable. I will get the CCD (with the PPC and David's assembler) module from Don soon, and I will look into how I can make a program generator for the 41. The result will be posted, but don't hold your breath :)

Self-modifying programs [a bit OT] Message #14 Posted by Karl Schneider on 6 Nov 2005, 6:04 p.m., in response to message #1 by Geir Isene The concept of self-modifying code arose in the 1980's, when I was a programmer on mainframes running Fortran software. We considered the idea frightening, from a standpoint of maintainability... -- KS

Re: Self-modifying programs [a bit more OT] Message #15 Posted by Marcus von Cube, Germany on 7 Nov 2005, 2:56 a.m., in response to message #14 by Karl Schneider Guess were I saw a self modifying piece of Software the first time? I found it in the BASIC ROM of my Tandy TRS-80 clone from Taiwan. The code implements two I/O commands (INP/OUTP). The Z80 processor has indirect I/O addressing but the BASIC was written for the 8080 which lacks such an operation. So the solution was to write the code sequence to RAM, modify the address byte and call the modified code. Did I mention who authored the code? It was Microsoft in its early days. It was possibly written by Bill Gates and/or Paul Allen in person...

Re: Self-modifying programs [a bit more OT] Message #16 Posted by Frank Wales on 8 Nov 2005, 11:29 a.m., in response to message #15 by Marcus von Cube, Germany Unless I misunderstand the original problem, I don't consider it to be a self-modifying program, but rather a program generator, which is a significantly less hazardous programming technique. (With a self-modifying program, the program alters its own code as it is running, and you end up with a different program from the one you started with. There are actually very few legitimate reasons to do this.) It sounds, instead, as if what is wanted here is a program that can write another program, based on some user input, and then run that generated program repeatedly under controlled conditions. Without knowing more about why this approach is considered the only reasonable one for performance reasons, my approach to the problem as stated would be to write the Petri net engine first, which would also force me to design the corresponding graph data representation in registers. Then I'd re-write the core of the engine in machine code, while leaving the user interface in user code (which, of course, requires you to have some additional hardware for executing your own machine code, which you might not have). (But really, if performance was going to be that poor, I'd seriously consider switching platforms, if only to a 41 emulator on a PDA or something.) Quote: So the solution was to write the code sequence to RAM, modify the address byte and call the modified code. This is pretty similar to a technique I (and probably many others) use to implement graceful degradation of Javascript-dependent functionality in web pages. The version of the page that works without Javascript is sent to the browser, but includes a call to a Javascript function that alters appropriate nodes in the web page's in-memory representation to change it into the corresponding Javascript-enhanced version. If Javascript is not available in the browser for any reason, the function call gets ignored and the user sees the non-JS version; if Javascript is available, the user only sees the Javascript-enhanced version. (This also allows more fine-grained feature switching, based on things like platform, screen size, rendering engine and other fiddling details. In general, though, trying to be too smart about this leads to madness at both ends of the network.) The only real differences with the MS BASIC technique are that the RAM I'm using is in the memory space of the browser on another computer, possibly on another continent, and the instruction sets I'm toggling between are vastly more elaborate and flakey than the old Intel/Zilog operations.

Re: Self-modifying programs [a bit more OT] Message #17 Posted by Geir Isene on 9 Nov 2005, 8:28 p.m., in response to message #16 by Frank Wales You are indeed correct. I am not looking to create a _self_modifying_ program for this task, but rather a program generator from user input. Exploring av viable self modifying program may be a future challenge...

[ Return to Index | Top of Index ]

Go back to the main exhibit hall