Hextool All the way from Norway comes this version of a standard utility, but with some very useful extra features. Bob Brown explains... I've seen many Hex to Dec and vice versa conversions but so far no math in Hex. As I'm beginning to work in machine code, I Decided I needed something like that, so I made up this prog. I've found that it has already come in very handy for me, especially in attempting to read published machine code listings. It helps me to understand what is happening to be able to go back and forth between Hex numbers and Dec numbers easily. I use common Hex to Dec, Dec to Hex algorithms and built on them. I started out with five separate progs, then Decided to make them into one listing. The listing is very compart- mentalised, and will easily lend itself to being broken back down into the five original separate progs. It is all menu controlled. (I like that expression, "menu controlled"... aren't almost all of us... a nice salad, a slab of roast beef, mashed potatoes... enough of that for a man on a diet!) The prog is also Aborted from the menu and one is given a second chance before the final Abort. I've put in an option to hard copy the menu, but I don't think it would be used much, as one always can return to menu after each operation. But, if one finds he needs to save memory, a hard copy of menu can be made. Then change menu control number 1 thru 5 to letter variables and use only the letters in menu display. The following changes will also save memory space. Change line 8820 to "M returns menu" and delete lines 8830 thru 8870: change line 9630 to read "M returns menu" and delete lines 9640/50: delete all REMs. Delete the complete SAVE/VERIFY routine and enter manually when needed. Those changes should save a bit of memory space, but at present, I like it the way it is. Chummy I've made the prog very friendly, I believe. If the cues are followed it will work fine. But I must caution, the cues must be followed. I used the results of M$ both as a control for the menu and as a flag for the various operations in the conversion sections. As mentioned earlier, there is an automatic SAVE-VERIFY- RUN routine. Once it is loaded with 'Hextool' it will RUN itself. In Line 9110, type in "12 spaces, Extended Mode, Caps Shift 4, MENU, Extended Mode, Caps Shift 0" (not the commas). In line 9930 go to Extended/Caps 2 just before "don't" and Extended/Caps 0 just after "forget". In the math mode, the ADD and SUB routines will probably be used the most, especially in jump routines. In such a listing as: 7E9A 18A3 JR -5Dh one would first find Dec equiv. of -A3, equal to -93 (M-2 mode), then the Hex equiv. of 93, equal to 5Dh and prefix a -. Of course an assembler program would probably do all that automatically, but I personally like to know exactly what is happening so eventually I'll have a solid under- standing of the intricacies of a process. I'm glad I worked with it for a while, as a wee bug insidiously crept into the works between the lines and was merrily laying its eggs. But the problem wasn't what I had originally believed it to be. I had merged the hextool with a hexload prog which contained a "DIM a$(2)" line. When I tried to load a number into line 9350, which has the variable string a$, the last two digits of the number were truncated. It appears that I had set up a "conflict of interest" between the two programs. One must watch when merging one prog with another to be certain that there are no conflicts between assigned variables. I've never seen that detail listed in anything I've read, so I thought I'd mention it. In hindsight it is obvious, but if one doesn't think of it beforehand, some weird results can emerge. I like the "PRINT #1" routine to put cues into the edit lines, and have used these in the prog. I get more fun out of trying to program than playing games, so this type of thing suits me. I hope the prog will be of use to a lot of novice programmers such as myself. That's all, happy programming!