Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!ittatc!dcdwest!sdcsvax!ucbvax!psuvaxg.BITNET.berkeley!przemek
From: przemek@psuvaxg.BITNET.berkeley
Newsgroups: mod.computers.68k
Subject: (none)
Message-ID: <8606282121.AA04052@ucbopal.Berkeley.Edu>
Date: Sat, 28-Jun-86 15:39:31 EDT
Article-I.D.: ucbopal.8606282121.AA04052
Posted: Sat Jun 28 15:39:31 1986
Date-Received: Sun, 29-Jun-86 04:14:33 EDT
Sender: mwm@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 51
Approved: info-68k@ucbvax.berkeley.edu

Following is the article I want to submit to 'mod.computers.68k':
                                        przemek@psuvaxg.bitnet

  All computers in sight do have some or the other form of the command
history mechanism and the command line editing.  All, that is, except
for the stride 420 I use under CP/M-68k; this sad observation made me
think of implementing such mechanism.  The difficulties of this project
seemed to be twofold -- first one must write the code itself; and then
one must incorporate it into CPM so that it will become the part of the
operating system.

  The decision to actually try this thing resulted from the problems
with the warmboot execution encountered in Robert Royar's implementation
of the 'exec' under the CPM.  By looking at the disassembled system I
realised that the warmboot service routine is called via jsr and not a
trap from within the line input routine, and therefore it cannot be
intercepted via the fake trap #2 handler.  My goal was therefore to
write new routine servicing BDOS call #10 -- properly reacting to the ^C
and providing some sort of the editing and history of the system command
lines.

  Now the first part (writing) proved to be relatively easier; a simple
algorithm and uninspired implementation have been done and tested in the
program, requesting lines of input (thus simulating the buffered line
input of the operating system); the second part was much harder.  At
first I thought that I would be able to link my routine to the
relocatable image of the system; then, since my routine has to have
unique name with respect to the original (the image is just a collection
of object modules and I cannot replace old one with my own), I would
have to fix manually the reference to the service routine in the __bdos
dispatcher and boot the new system.  This didn't work; the resulting
system gives very strange boot error (illegal function reference....)
and I don't know what issues this message -- whether it is the boot code
or some bootstrap code within CPM.  The only thing that changed from the
boot process point of view is the system size, n'est ce pas?

  Now the other approach is to set up the trap #2 intercept, test for
the function 10 and dispatch to my routine if yes; I had some problems
with that possibly caused by the stack overflow, since the handler is
entered in S state and SSP is used.  If anybody has some experience with
that I would appreciate hearing from this person.  Maybe switching to U
state could help -- I didn't try.  The way I do it right now is ghastly
-- I run the program relocated to the high memory, protect it with
'permanent' set TPA call, and overwrite the original reference in the
system image with reference to my routine installed permanently by
changed top of TPA.

  I look forward to hear from you; and keep you informed about my progress
as it occurs.
                        przemek@psuvaxg.bitnet
                        psuvax1!gondor!przemek