On Saturday 15 April 2006 14:03, Tony Duell wrote:
On 4/15/06,
Lyle Bickley <lbickley at bickleywest.com> wrote:
4. I'm a *NIX buff and haven't written
DOS code for years, but I wrote
GTTY as a DOS program because I know there are a lot of collectors
that use "imagedisk", "Teledisk", "PUTR", etc. which
only operate
on DOS - and many folks who don't have *NIX systems. I've
successfully tested GTTY on DOS 6.22, Windows 98 SE in a DOS window,
and Windows XT [Home Edition] in a DOS window.
Hey felllow *nix buff! :-)
Would a *nix (specifically Linux) port be in your vision in the near
future?
I've had the same question in reverse whenever I've released a program
(e.g. the HP calculator LIF Untilies for Linux). People want an MS-DOS or
Windows version. My reply is always the same. I've published the source
code. If you want a version for another machine or OS, then write it
yourself :-). I've written it for Linux becasue that's what I use.
I believe the sourve for GTTY has been released too. It should therefore
be possible to port it.
The source is released. I'll be pleased if someone wants to take the "C"
source and port it to a *NIX system! However, I suggest they hold off for a
bit (see below).
I'm interested in knowing what was done with the
reader-run loop from the
PDP8? The DEC specification (deduced from the scheamtics, etc) is that
when the PDP8 (or PDP11) wants to read a character from the paper tape,
it passes a current through this look. This energises the reader run
relay, the TTY reads a character and starts to serialise it. When the
Start bit is received by the PDP8, the loop is opened again. The
reader/TTY sends no more characeters until there's a current in the
reader run loop again.
Many UARTs seem to buffer at least one extra chracter and may well have
problems with this. There's also a hardware problem in that AFAIK the DEC
card never tried to provide an RS232 equivalent to this signal, and most,
if not all, commercial currnet loop converters ignore it.
The COM port is buffered by using a fairly large buffer with interrupt
control, etc. That's done in the COM library code. [The source for the
library is available with the commercial release of the Dave's Compiler
($25). Dave's compiler and library is designed for use in embedded systems -
so it tends to handle things "close to the metal" well.]
I will have to look at the source to GTTY to see if
this was simply
ignored (I hope not, a heck of a lot of stuff would break...) or what.
I designed into the GTTY (with a few bits still on paper) the use of CTS as a
a means of synch. with the Reader FF. I want to test it with different TTY
modules - including the board "patches" necessary for making this work in an
RS-232/EIA environment. Be a bit patient, and I hope to get it done in the
not too distant future...
Remember the current release of GTTY is a 0.x release. The "CTS" version will
start with 1.0 ;-)
Cheers,
Lyle
--
Lyle Bickley
Bickley Consulting West Inc.
Mountain View, CA
http://bickleywest.com
"Black holes are where God is dividing by zero"