RCONN@SIMTEL20.ARPA (Rick Conn) (04/25/86)
Paul, Re your message ... "... I noticed that each file starts with LXI H,SYSENV ;pointer to sys env CALL ???INIT ;init for program and I assume that it is the address after the LXI instruction that the install program fills in. If this is the case then why not replace that code with LHLD zero_page_pointer_to_SYSENV CALL ???INIT this would mean that the tools cou6d be run WITHOUT (re)installing! It seems to me that this would be a big plus for people that have many systems, or that load systems of different memory sizes. A side feature would be that you could load more than one ENV table for debugging or what ever and just have to change ONE pointer to use the other one." -- Your suggestion would be nice, but there is a problem in that there is no "free" space on page zero which would provide two bytes (or even one byte for a page address) that can be guaranteed to be free in all CP/M implementations ... note that the "standard" external path location is a variable since some implementations use this area for BIOS constants; take heart, tho, for in ZCPR 3.3 (the new version which will go into beta test soon), there are many radical differencences, one being that the tools do NOT require installation (the address of the ENV is passed in HL from the ZCPR 3.3). "Also I was wondering why there was a POINTER -in- the ENV_table that points to the WHEEL_byte instead of the actual WHEEL_byte itself? This would save one byte in the ENV and free up the zero_page entry for something else (maybe the pointer to sys_env), and it would also save programs from having to index to get to the wheel_pointer then index to wheel from the pointer. I thought that maybe this was because many programs have the wheel address "hard-wired-in" but can't think of any that use wheel that don't allow you to change the address... This change would also mean that this would no longer be necessary for Z-systems, while everyone else could still patch as always." -- Two years ago, when I completed ZCPR 3, I was concerned with having TWO wheel bytes on a RAS (Remote Access System) - one wheel byte which was implemented by some other user software, and one for the ZCPR3. With the evolution of ZCPR 3.3 into an os/comm system, of which I have total control, this concern is gone, and ZCPR 3.3 now has a Wheel BIT in the ENV as well as a variety of access control bits "I sure think the idea of non-installed tools is a great hack! So what did I miss, you're far too great a programmer to have passed this up with out some good reason." -- non-installed tools are now common under ZCPR 3.3, as well as built-in CM; you should try to come to my talks (like the one I just gave at Trenton, which was packed) - lots of details are coming out there and in planned articles as well as Z-News; ZCPR 3.3 forms the basis for ZCPRB3 (Banked ZCPR3) and ZCPRM3 (Multitasking ZCPR3), so the non-installed tools are here to stay, as well as the new CM system and communications system attributes of the Z System Rick -------