▼
Posts: 896
Threads: 183
Joined: Jul 2005
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?
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
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)
▼
Posts: 243
Threads: 122
Joined: Jan 2006
Luiz, would you have lex files in the format 9114B?
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
What OS are you using on your PC?
▼
Posts: 243
Threads: 122
Joined: Jan 2006
Windows 98Se
Do I format using 256 or 1024 bytes?
Thank's
Edited: 4 Nov 2005, 5:40 p.m.
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
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.
▼
Posts: 887
Threads: 9
Joined: Jul 2007
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.
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
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.
Posts: 1,830
Threads: 113
Joined: Aug 2005
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.
Posts: 4,027
Threads: 172
Joined: Aug 2005
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)
Posts: 1,841
Threads: 54
Joined: Jul 2005
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
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
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)
Posts: 896
Threads: 183
Joined: Jul 2005
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 :)
Posts: 1,792
Threads: 62
Joined: Jan 2005
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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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...
▼
Posts: 117
Threads: 6
Joined: Mar 2006
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.
▼
Posts: 896
Threads: 183
Joined: Jul 2005
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...
|