RDROYA01@ULKYVX.BITNET.UUCP (07/05/86)
Hi folks,
I've got another monster to announce. I have been able to create a command
buffer in uEmacs similar to the one created by the <ESC>$ command on
VAX-GNU-EMACS. It captures all text output by built-in ccp commands in a
popup window. I overcame the initial problem with the brk() function
returning a "no-mem" error by swapping the usp and ssp while inside the
replacement for conout. Now I don't get allocation errors in the background
window, but programs bomb out with an exception three (address boundary).
This does not crash the editor, so my trap handler must be working. What I
figure is that the programs I am loading are loaded in S mode and run in S
mode, but somewhere they should be shifted to U mode.
As I said in an earlier message, the normal switch to background command
now works without errors. Simply capturing the output text should cause
problems and could be a great help in programming by allowing you to edit
in one window and compile, link and read the errors in another. But the
address error means this will not work properly. BTW if it were not for
the way the C functions check on available memory, there would be no
problem at all with running a program in a window. It's just that brk
checks to see whether a requested mem region is above the current value of
(sp) and if so returns -1. Of course this is necessary to insure proper
memory organization, but it sure causes problems for this application.
When I run the programs in background and capture the output to the
[Command] buffer without playing with the value of the ssp (a7), the
programs run fine, even ddt, but after the initial allocated space is used,
the editor functions cannot insert any more characters in the buffer.
Neither the host program (uEmacs) nor the called program crashes, but the
screen output from the called program is lost.
On my system, without the modifications I have made, when a normal program
warm boots, the S mode is set because it exits through trap #2 which calls
trap #3 with d0=1. The bios warm boot reinitializes some peripherals and
then jmps to _ccp. The processor is still in S mode. But by the time a
program has loaded, the processor is in U mode. Where and how does this
switch in mode take place, and where should I place it in my routine?
A rough outline of the routine:
[Inside uEmail]
CCP command
Popup command window on screen.
Switch to it.
Call ccp (via trap #1).
[From here on we're in supervisor mode]
Intercept bios calls.
d0=1 (bios warm boot (the last function called by the bdos wboot
routine))
call bios wboot
reinit peripherals, log_vector, etc.
branch to ccp
restore default ssp (value of ssp when trap #1
was issued)
d0=3 (bios conin)
trap #0 (where real bios vector lives while in background)
d1=CTRL-C
cleanup background operations
replace trap #3 vector
restore ssp and usp
reset disk system
return to original environment
else
rte (returns char to bdos in d1)
d0=4 (bios conout)
insert output char in [Command] buffer window and update the
window, buffer, and line
else (some other bios call)
trap #0 (any other bios request goes through normally)
Does anyone have any suggestions on how to remedy this problem?
Thanks,
rdroya01@ulkyvx.bitnet