80-Bus News

But be warned, MBASIC starts it’s workspace and stack from the top of the TPA. The stack and/or workspace could come crashing through the program if you’re not careful. So POKEing this into RAM in MBASIC is not a clever idea. Far sneakier is a method suggested by Carl Lloyd-Parker, and that makes use of the fact that although MBASIC knows where strings are in a program, it doesn’t pull then out into the workspace area until some additive or subtractive manuipulation is carried out on it. In other words, the string stays where it was originally written in the program unless you do something nasty to it. Carl’s method is to define a string of asterisks somewhere in the program, the string being as long as the machine code to be POKEd into it. Then calculate the position of the string using VARPTR, then POKE the code into the string as the example above. The address calculated from VARPTR is also the call address for the program. There are two examples of this, one by Carl in his IVC HIRES programs and another by me in the BASIC demo CLOCK program in the Gemini GM816 manual. The fun part of this method is if the string is placed as the first line of the program, then, when the program has been run, the string is full of lots of interesting junk, making the program unlistable (if you start the list at the first line).

Perhaps you’re wondering how I decimalize the HEX code from the programs as assembled into a form useable by dBASE or MBASIC, or whatever, at least without making too many mistakes. Simple I use BASIC to do it! First I assemble the program using M80 and L80 as usual, then I load it up under ZSID, DDT, GEM-DEBUG or some other debugger. I then clear out the memory around the location where the program is to reside and move the program to the working address. This gives me the program in memory at its correct place with some 00h’s before and after it. (Nice and identifiable that way.)

Next into MBASIC, work out the start and end addresses using the &H function in BASIC, note that this gives negative answers if not treated right. Take the instance above:

? 65536 + &Hc000
49152
Ok
? 65536 + &Hc011
49169
Ok

Now for the crafty bit, open a sequential file and write the code to it, I do this in the command mode like so:

OPEN "0",£1,"CODE": FOR A=49152 TO 49169: PRINT£1,PEEK(A);: NEXT: CLOSE

Surpise surpise, this gives me an ASCII file that I can bash into a text editor and edit to suit. My favourite address for machine code to be used in this way is c000h, as for some reason I can always remember 49152. When it comes to the end addresses of these programs, having calculated it I usually have a quick PEEK around the calculated address to see if I got right, hence the nulls either end of the program. The whole process takes about as long as it took to write up and being done by machine is not susceptible to human error.