Dec 092017
 
An improved version of FST's TALK, includes full Modula-2 source.
File TALK3.ZIP from The Programmer’s Corner in
Category Modula II Source Code
An improved version of FST’s TALK, includes full Modula-2 source.
File Name File Size Zip Size Zip Type
PCZ.ARC 50446 48985 deflated
PROTOCOL 3173 1360 deflated
READ.ME 2865 1412 deflated
TALK3.EXE 58624 16523 deflated
TALK3.MOD 22720 5297 deflated
XMODEM2.DEF 1236 564 deflated
XMODEM2.MOD 12079 2669 deflated

Download File TALK3.ZIP Here

Contents of the READ.ME file


TALK3.ARC
---------

Chuck Somerville
Eastman Kodak
Dayton, OH 45420
(513) 259-3561


Here's a quick and dirty cut at enhancing TALK further. This version can
handle ZModem file transfers by Loader.Execute-ing a PD ZModem program.
Since I had to learn about about Loader.Execute anyway, I added a selection
to "shell" out to DOS to browse files, do directories (or for that matter,
run other file transfer programs).I started from TALK2 instead of TALK so
the CRC stuff would be in there. (I'm enclosing the XMODEM2.MOD, and
XMODEM2.DEF I made so as to preserve the original XMODEM.)

Since one probably doesn't want the multitasking, interrupt-driven IO, and
hooked interrupts left in place when one "shells" out to something, I took
a shot at a brute-force save and restore scheme for the interrupt vectors
hooked by multi-tasking TALK routines (MODULEs SaveVectors and SetVectors).

I thought digging into the Kernel, RS232, etc. code for how to "undo" all
the stuff they set up and then "redo" it after a shell to something was
beginning to look like a lot of work. At least I reset the interrupt
vectors to the relatively harmless state they would be in if the main
program did nothing at all but Loader.Execute something.

It seems to me Loader.Execute leaves that issue not properly covered. You
might consider a similar save of vectors in System's startup code, and in
Loader.Execute do a save & restore in addition to the heap management stuff.

Anyhow, The Zmodem file transfer is handled by executing PCZ.COM, a public
domain file transfer program (included in PCZ.ARC). Its documentation file
should stay with TALK3 if this makes it to the BBS for sharing with others
due to its licensing statement.

I set it up to look for a PCZ environment variable in order to find the
[drive:]pathname of the directory where PCZ.EXE resides. TALK3 then appends
a "\" (if necessary) and then appends "PCZ.EXE" to make the full
Loader.Execute "name of program to run" parameter.

I would like to hear your views on suspending/undoing the interrupt-hooked,
multi-tasked TALK environment in order to shell out to something giving it
a semi-normal environment to run in, and then re-establishing the TALK
environment upon return. My scheme seems somewhat brute-force to me, and
I've probably left one or more bases uncovered.

-- regards,
-- Chuck


FILES DESCRIPTIONS
----------- ----------------------------------------------------------

PCZ.ARC PCZ.EXE (and .DOC) - the PD file xfer program.

TALK3.MOD M2 source.

TALK3.EXE Executable.

XMODEM2.MOD Just a copy of XMODEM.MOD from the TALK2 package (name
change only, to keep XMODEM.MOD separate).

XMODEM2.DEF DEF file for above.

PROTOCOL A brief description of several protocols.



 December 9, 2017  Add comments

Leave a Reply