knudsen@ihwpt.ATT.COM (mike knudsen) (04/27/87)
With the new Level 2's emphasis on merging modules
together into files, it's worthwhile to visit
an old bug of RUNB (Basic09). Some guys on Delphi
finally figured out what had been going on for years
even under Level 1 (I had just quit using PACK).
Problem is this: You PACK several Basic09 procedures
into one file (or MERGE them together later, maybe
adding some machine-code routines like INKEY or GFX2
or your own).
With this file in your /CMDS, say named ZORCH,
you should be able to type just "ZORCH" and OS9 will
pull in RUNB to execute it. Well, not quite.
You'll get the "unknown procedure" error.
Reason: OS9 (or Shell) loads the first module
in the file and immediately starts to execute it,
forgetting about the rest of the file. That is,
once RUNB is loaded, OS9 looks for the rest of the
procedures in /CMDS and your pwd, but ignores the
rest of your merged file! So unless all the other procedures
are also saved separately under their own names,
you get Unknown Procedure. (And if they are, you just
blew 8K for every one of the little buggers in Level 2).
To fix, just LOAD ZORCH before typing ZORCH.
This puts all modules in memory, nicely packed for
Level 2 also. Yes, you can mix packed B9 and 6809 code
modules (neat, eh?). I found the fix while trying to run
a friend's PACKed graphics demo; the Delphi hackers found
the explanation while trying to make the "for 128K only"
part of the B9 manual (YAWN) work.
--
Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T)
Delphi: RAGTIMER CIS: <memory failure, too many digits>
" ~E(x):[is_lunch(x) && cost(x)==0] "ingoldsby@calgary.UUCP (04/28/87)
In article <1639@ihwpt.ATT.COM>, knudsen@ihwpt.ATT.COM (mike knudsen) writes: > Problem is this: You PACK several Basic09 procedures > into one file (or MERGE them together later, maybe > adding some machine-code routines like INKEY or GFX2 > or your own). > With this file in your /CMDS, say named ZORCH, > you should be able to type just "ZORCH" and OS9 will > pull in RUNB to execute it. Well, not quite. > You'll get the "unknown procedure" error. > Reason: OS9 (or Shell) loads the first module > in the file and immediately starts to execute it, > forgetting about the rest of the file. That is, > once RUNB is loaded, OS9 looks for the rest of the > procedures in /CMDS and your pwd, but ignores the > rest of your merged file! I haven't yet played with Basic09 on Level II, but the key to overcoming this is the order in which the modules are specified to the PACK command. I don't have the documentation with me, but it seems to me that one can either specify the first module to be executed is the last in the file (meaning that all others are loaded first) or that (here my memory gets foggy) the trick is to make certain that the first module to be executed is the last module edited (ie. the one with the * beside it when you do a dir), then pack *. I know it can be made to work automatically since my text formatter (tformat) works just fine this way, even under level II (it was `compiled' under Level I). If anyone wants the details I will look them up for you. Does anyone know if there is some trick to making the bit banger serial port read data. It is really weird. I'm using the same cable as I used for level I, but it can't read. What is really weird is that if I say copy /T1 /TERM then typing at a terminal causes the character typed to be echoed back to the terminal (implying that the computer received and understood the character) but never does anything appear on the screen. I also tried sending it to /w and /w7 but that didn't help. Can anyone help me? Terry Ingoldsby ihnp4!alberta!calgary!ingoldsby
pete@wlbr.UUCP (04/29/87)
Sorry for the message repeat.. I felt the bulk of it needed to be seen.. In article <1639@ihwpt.ATT.COM> knudsen@ihwpt.ATT.COM (mike knudsen) writes: >With the new Level 2's emphasis on merging modules >together into files, it's worthwhile to visit >an old bug of RUNB (Basic09). Some guys on Delphi >finally figured out what had been going on for years >even under Level 1 (I had just quit using PACK). > >Problem is this: You PACK several Basic09 procedures >into one file (or MERGE them together later, maybe >adding some machine-code routines like INKEY or GFX2 >or your own). > With this file in your /CMDS, say named ZORCH, >you should be able to type just "ZORCH" and OS9 will >pull in RUNB to execute it. Well, not quite. >You'll get the "unknown procedure" error. > Reason: OS9 (or Shell) loads the first module >in the file and immediately starts to execute it, >forgetting about the rest of the file. That is, >once RUNB is loaded, OS9 looks for the rest of the >procedures in /CMDS and your pwd, but ignores the >rest of your merged file! So unless all the other procedures >are also saved separately under their own names, >you get Unknown Procedure. (And if they are, you just >blew 8K for every one of the little buggers in Level 2). > To fix, just LOAD ZORCH before typing ZORCH. >This puts all modules in memory, nicely packed for >Level 2 also. Yes, you can mix packed B9 and 6809 code >modules (neat, eh?). I found the fix while trying to run >a friend's PACKed graphics demo; the Delphi hackers found >the explanation while trying to make the "for 128K only" >part of the B9 manual (YAWN) work. >-- Hmmmm - I wonder which BASIC09 you're running (grin). Actually, I have *several* B09 programs ('Editor' - a disk/sector editor comes to mind) that have MANY B09 and M/L modules all merged together, and they run just dandy. There *is* a bug that pertains to loading & running of B09 packed files, but I'll get to that in a second.. The most likely reason for the UNKNOWN PROCEDURE error is one of three things: a) The file was improperly packed (i.e., not done with 'PACK*') b) The sequence of the modules may have been wrong at 'PACK' time. c) There was a M/L module in the B09 workspace at 'PACK' time (this is a flaky 'maybe'). d) RUNB's (or BASIC09's) data area was too small to hold the whole file, so the I-Code may not be fully loaded (i.e. it got truncated). Fix for a) is to reload source and repack it using the PACK* option. Fix for b) is to make SURE that the last module you EDIT is the module you intend to be the module that will run at program start. That is, if you have MAIN_PROGRAM, SUBS1, and SUBS2, make sure that the edit pointer (a "*" by the module name) is pointing at MAIN_PROGRAM when you 'PACK*'. The edit pointer is displayed when in the B09 command mode and either 'DIR' or [enter] is typed. Fix for c) is to KILL any machine language modules that may have been loaded during testing before 'PACK*' is issued. Fix for d) is discussed below. =========== The BUG =========== The real bug with packed B09 programs is this: When you invoke a program that is packed BASIC09 I-Code, the shell first searches the module directory to see if it is resident. If not, it then searches the current execution directory (usually /DD/CMDS) for a FILE by that name. If the file turns out to be an I-Code module, RUNB is forked with this FILE as a parameter. Here's the RUB: When the Shell invokes RUNB, it looks at the >>RUNB<< module header to determine how much DATA MEMORY is required. Under the older versions, that was #4k.. under RS OS9/LII it has been patched to #8K. So, in your example above, the effective command is *REALLY*: RUNB ZORCH #8k The program ZORCH then gets loaded into RUNB's DATA AREA (which is 8K). If ZORCH won't FIT in 8K, the remaining part of the file never gets loaded! Even if it DOES get the PROGRAM loaded, there may well not be enough space left for it to RUN. The best fix would be to have the Shell analyze the size of the DATA AREA required by the packed I-Code by walking through the packed file and adding up the requirements in ALL - not just the first - module headers. Then it could fork RUNB with the computed memory requirement. Another fix might be to hack RUNB so that *it* looks at the module headers and requests an appropriate amount of memory on the 'fly'. A good workaround for this is to invoke RUNB yourself with the appropriate memory requirements: RUNB /DD/CMDS/Zorch #16k It has been a long time since I have coded in BASIC09, so this may be somewhat tainted by my lack of exposure. I program primarily in ASM and C. -- Pete Lyall Usenet: {trwrb, scgvaxd, ihnp4, voder, vortex}!wlbr!pete Compuserve: 76703,4230 (OS9 SIG Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud) Phone: (818)-706-5693 (work 9-5 PST) EATON Corp, IMSD, 31717 La Tienda Dr., Westlake Village, Ca. 91359 ----------------------------------------------------------------------