On Apr 1, 6:32 pm, PC Pete wrote:
>
> I've got L80 and M80, and all the usual editors (WS, etc), but while I
> can compile and link the asm sources for the system-independent code, I
> just can't get the linker to link the CPVGEN.HEX code in properly.


Normally, a .hex file is not something that needs to be linked. It is
a hex representation of an executable (.com, whatever) file.


> I tried to use the bootstrap routines, but because it's running
> TurboDOS, there is no SAVE.COM equivalent, so while I can use DDT to
> load and merge the hex sources (from the /a subdir on the kermit
> server), I can't run or save the merged file.


See ftp://kermit.columbia.edu/kermit/c/td*

Subject: Re: Help with CPVGEN sources for TurboDOS system?
From: PC Pete

In article @r9g2000prd.googlegroups.com>, you say...
> Normally, a .hex file is not something that needs to be linked. It is
> a hex representation of an executable (.com, whatever) file.

Yeah, and that's where I'm stuck - I can load the hex files using ddt,
and even run them once, but there's a problem with the load addresses,
and the run'd image prints up the kermit prompt and fails with hex data
being "seen" as the commands. But that's closer than I've ever got
yet... Here's what I see when I merge the compiled cpsker with the
downloaded cpvgen:

0E}ddt cpsker.hex
DDT VERS 2.2
NEXT PC
70AD 0127
-icpvgen.hex
-r
NEXT PC
73C8 0000
-g100
Kermit-80 v4.11 configured for Generic CP/M-80 with Generic (Dumb) CRT
Terminal

For help, type ? at any point in a command
Kermit-80 0E:>0240D0A535061636B3A2024E0
?Unrecognized command
Kermit-80 0E:>:0000000000
?Unrecognized command
Kermit-80 0E:>
Kermit-80 0E:>30240D0A5374617274696E6
?Unrecognized command
?Not confirmed
?Not confirmed
?Not confirmed
....etc....
?Not confirmed
?Not confirmed
?Not confirmed
0E}
>
>
> See ftp://kermit.columbia.edu/kermit/c/td*
>
>
Thanks for the reference, I'm about to reverse-hex the hex data and try
it out... I'll try and update here shortly.

I do appreciate you taking the time to forward the td reference, I
couldn't find it in the sites I was looking on. Probably I didn't look
long or hard enough!

Cheers,
PCP

On 2008-04-02, PC Pete wrote:
: G'day all,
:
: I'm trying desperately to rescue a terminally ill TurboDOS system. It
: has no working floppy controller, and the hard drive is spinning down
: for the last time! TurboDOS is an "extension" of CP/M 2.2 - it has most
: of the same BDOS calls, but also an extra set of T-calls for better I/O
: and so on. Most "standard" CP/M 2.2 applications (like KERMIT, XMODEM,
: etc) work perfectly, if inefficiently without modification.
: ....
:
: I'm running out of options, and after 2 days spent trolling mail and
: news archives, I know the CPVGEN source used to be available, and I know
: that at least one person successfully compiled and ran Kermit 3.x on a
: TurboDOS system - so it's been done, but I can't for the life of me find
: any other reference to the asm sources.
:
There is no CKVGEN.ASM. I apologize for the inadequate or misleading
documentation, but I believe the thing to do is to edit CPXTYP.ASM
and change the definition for one and only one of the system types
(in this case "gener") from FALSE to TRUE. Or if TurboDOS is more like
CP/M 3 than CP/M 2.2, do this for "cpm3" rather than "gener".

And as Marc Sapiro noted (and I forgot until just now) there is also a
binary for TurboDOS, available in both straight hex (not Intel hex)
format and UUencoded. The hex is about 52K, so it should be "just" a
question of getting it into your box in one piece somehow and
dehexifying it.

- Frank

Frank da Cruz wrote:
> There is no CKVGEN.ASM. I apologize for the inadequate or misleading
> documentation, but I believe the thing to do is to edit CPXTYP.ASM
> and change the definition for one and only one of the system types
> (in this case "gener") from FALSE to TRUE. Or if TurboDOS is more like
> CP/M 3 than CP/M 2.2, do this for "cpm3" rather than "gener".
>
Thanks, Frank, that makes a bit more sense to me. I did a lot of
assembly programming (like you, too long ago and too far away to want to
remember how old that makes me! ), and I never ever linked in hex
sources with any rel or mac files. That's what was driving me nuts - the
doco actually states the system-independent source must be compiled,
then linked (merged using DDT) with the system-dependent hex file, and
instructions for how to build the system-dependent files aren't
mentioned anywhere I've looked - it all seems to be "pre-built", which
seems a bit strange, unless there's proprietary code or licence issues.

> And as Marc Sapiro noted (and I forgot until just now) there is also a
> binary for TurboDOS, available in both straight hex (not Intel hex)
> format and UUencoded. The hex is about 52K, so it should be "just" a
> question of getting it into your box in one piece somehow and
> dehexifying it.
>
> - Frank

I've downloaded the ASCII hex, de-hexed the TD binary (I still had the
Turbo Pascal source I wrote in 1989 for that exact problem on the target
system, which was a really nice break), and run it - and it starts up,
then before a prompt appears, it crashes out. Actually, it resets the
CPU completely, which is what happens on this system when the transient
BDOS portion is overwritten. I've even tried running it in Bank 0, but
the ccp can't load it, I've got less than 26k free in bank 0.

I suspect (and my memory is a bit hazy) that it's because I'm running it
on a SLAVE processor, not the same processor configured as a standalone
CPU system (it's the Pulsar Z80B I'm doing this all on, with a Pulsar
80186 master CPU, running TurboDOS 1.4). That's going to be a problem,
because I don't have a working floppy drive - I have plenty of CP/M 2.2
and standalone TurboDOS boot floppies that I know are configured for
this system, but there's no way of getting access to them, even if I
could remember which of the 16 jumpers and 8 switches and replacement
PALs I need to turn the slave into a standalone/master...

If nothing else, it's been a blast finding all this again, and I'm
flabbergasted at how helpful the few remaining folks have been. I really
hope I can return the favour.

Back to configuring... and crossing fingers.

Actually, I think there is "some stuff" missing from the archive.
(understatement!)

In aavsys.txt, it does specify ASM source for TurboDOS (by Mark Eichin),
but in the ftp site, there's only the hex binary and uue and ann files.

.... Ok, I'm looking through the files I downloaded from the kermit/a
directory, and I'm looking at the cpxxxx.asm files.

From what I can see, I need to compile :
CPXVDU.ASM
CPXTYP
CPXSYS
CPXSY2
CPXSWT
CPXLNK
CPXCOM
CPXAPP
... are there any others I need to be aware of?

Or, to save you wasting your valuable time, is there a "master" file
(like cpsker) that lists all the other files and/or equates I need to
compile and link to get the system-dependent part of a generic kermit 4
system implementation working?

I'm really sorry to ask all of this of you guys, but so far I've spent
around 35 hours and looked at 115 sites (102 of them now dead) and750+
pages of news archives, bbs lists, resource archives, uunet archives,
and more...

I'm just a bit lost at the moment, if I can find a touchstone for what I
need and where I can get it, then I can stop bugging people with better
things to do than answer questions for 20 year-old code. Even better, I
can then document it and put it somewhere so no-one else has to go
through this. The resources available are amazing, it's just finding the
appropriate ones! And I've got so MUCH stuff on the dying system, that I
know I can give something back if I can get some transfer happening, but
I'm just spinning my wheels here.

Frank da Cruz wrote:
My apologies, all, I did not read all the way through the user guide.

I now know (hopefully) which asm files to be compiled.

I'm having some fun trying to identify the overlay address, as it's
defined as $-lnkflg, but then the lnkflg address needs to contain
lnksiz... I'll do some .printx and recompile so I have a clearer idea!

I've at least documented the changes that needed to be made, I hope
these will be useful when I've confirmed all the mods.

Again, sorry for not R-ing TFM.
-PCPete

OK, I'm sorting most of the problems out now. Kinda.

I can now almost compile the cpxxxx sources, but my M80 keeps throwing
macro overflow errors.

It looks like my version doesn't like an included file including another
file more than 2 levels deep, and that's exactly what's happening.

I'll do some more playing to see if I can avoid the included chaining by
making the cpxtyp.mac a bit less flexible to start with - then I can
fart around with getting a new version of these tools.

PC Pete wrote:
> OK, I'm sorting most of the problems out now. Kinda.
>
> I can now almost compile the cpxxxx sources, but my M80 keeps throwing
> macro overflow errors.
>
> It looks like my version doesn't like an included file including another
> file more than 2 levels deep, and that's exactly what's happening.
>
> I'll do some more playing to see if I can avoid the included chaining by
> making the cpxtyp.mac a bit less flexible to start with - then I can
> fart around with getting a new version of these tools.
>
>
Nope, wrong again. I do get a macro (or memory, the M80 manual and doc
file are extraordinarily unhelpful, that's one bad side I forgot about
M/L80) overflow at line 458 in CPXVDU.ASM,and line 1360 in CPXSYS2.ASM,
and it is happening within an "open" IF directive (these are included
from line 679 in CPXTYP.ASM), but I'm not sure why that particular
equate is not getting flagged for pass 2 - especially this is failing on
the first pass of the assembler!

I've included the full output here, if anyone could have a look and see
if the problem rings any bells, I'd very much appreciate the hand. I
just can't remember all the pitfalls.

Back to the grind. I'm sure it's going to be blindingly, stupendously
obvious...

0E}m80 cpxtyp=cpxtyp.mac
* sysfam set TRUE *
* CPXCOM.MAC *
* CPXSWT.MAC *
* Assembling Generic KERMIT-80 *
* CPXSYS.MAC *
* CPXSY2.MAC *
* CPXVDU.MAC *
* generic CRT selected *
M C ovlend equ $ ; End of overlay
* sysfam set TRUE *
* CPXCOM.MAC *
* CPXSWT.MAC *
* Assembling Generic KERMIT-80 *
* CPXSYS.MAC *
* CPXSY2.MAC *
M 733E C ovlend EQU $
* CPXVDU.MAC *
* generic CRT selected *
M 73C0 C ovlend equ $ ; End of overlay

3 Fatal error(s)

0E}

PC Pete wrote:

> 0E}m80 cpxtyp=cpxtyp.mac
> * sysfam set TRUE *
> * CPXCOM.MAC *
> * CPXSWT.MAC *
> * Assembling Generic KERMIT-80 *
> * CPXSYS.MAC *
> * CPXSY2.MAC *
> * CPXVDU.MAC *
> * generic CRT selected *
> M C ovlend equ $ ; End of overlay
> * sysfam set TRUE *
> * CPXCOM.MAC *
> * CPXSWT.MAC *
> * Assembling Generic KERMIT-80 *
> * CPXSYS.MAC *
> * CPXSY2.MAC *
> M 733E C ovlend EQU $
> * CPXVDU.MAC *
> * generic CRT selected *
> M 73C0 C ovlend equ $ ; End of overlay
>
> 3 Fatal error(s)
>
> 0E}

There does seem to be a logic error in the includes, and I seem to have
"fixed" the problem and the code now compiles fine, but I still can't
run it or save it as a COM image on the TurboDOS system. To run it at
all, I have to load the compiled hex images in DDT, then G, which craps
out with the same wierd error messages.

I've also compiled this on a stock CP/M 2.2 system, and I get the same
errors (multiple ovlends), and the code compiles to the same "size" -
i.e. the end of the independent code is way past 7000. However, that all
seemed to work on that system, whereas the same isn't true on the
TurboDOS system.

I've traced through the initialisation code in CPSMIT.MAC, but
unfortunately my debug is absolutely awful - I can't download or capture
the PRN file generated by M80 when compiling the cpsker code, because
the terminal emulator won't wrap, so my PRN file display has no
comments, while the "clean" source obviously has no addresses I can
match - so when I get lost, I have to get the PC from DDT, look it up in
the truncated PRN, then match that (remember, no line numbers in this
version of M80) to the "raw" asm source to get my bearings.

I'm trying a few alternatives to that nightmare, but the terminal
emulator won't capture plain ASCII, it will only download using
x/y/zmodem/kermit... which completes the circle of life. And if I use a
dedicated windows build of a serial file transfer, it doesn't work
because I still don't have x/y/z/k on the target system. Enough already.
Sorry.

The logic problem I see is that with the 'gener' and 'crt' equates set
to true, both CPXSY2.ASM and CPXVDU.ASM are included (in that order),
but ovlend is defined in both files and both lines are parsed. It looks
as though the logic to avoid duplicate definitions worked using LASM,
but obviously not many people would have been interested in testing the
L80 logic as well. I mean, what kind of loser would want to do THAT?
....oh, right, that would be mel80...

If it's OK with everyone, I'll see if I can sort the logic out, and post
my changes for comment. Maybe then that might find a home on the archive
site?

I realise this is 17 years too late, but it would be a shame if someone
else had to bite the same bullet.

I've also documented the changes that needed to be made to both the file
formats (M80 and L80 on both my two CPM systems (TurboDOS and MyZ80
emulator) freak out at the unix-style source) and the names (MAC instead
of ASM), and all the equates that needed to be changed/set.

I'm sorry to waste so much bandwidth on such a little issue.

Thanks to all for your wonderful ideas, it's nice to have someone more
experienced offer help, especially when you're as rusty as I am!

That was kind of like getting castrated with two bricks. Hopefully it's
getting closer now...

On 2008-04-04, PC Pete wrote:
: ...
: Thanks to all for your wonderful ideas, it's nice to have someone more
: experienced offer help, especially when you're as rusty as I am!
:
I'm more rusty. The last time I actually worked with this code was over
20 years ago and I'm sure it goes without saying that I don't have any
machines here where I could do it again. I don't understand why the "native
TurboDOS" version doesn't work, but then I've never even seen TurboDOS.
Unfortunately I don't see any other grizzed CP/M Kermit veterans popping
up with advice.

The version we have up on our FTP server is 4.11, which was done by Mike
Freeman, but I haven't heard from him in years. But perhaps this version
exceeds some bounds that were not exceeded by earlier versions. There's an
older version -- I'm not sure exactly which one -- here:

ftp://kermit.columbia.edu/kermit/old/misc/cpm

I also noticed this directory, which I had forgotten about:

ftp://kermit.columbia.edu/kermit/old/misc/cpmtools

It contains source for LASM and MLOAD.

But maybe there's a simpler approach. The object of the game is to get
your files OFF TurboDOS and into the PC, right? Getting things INTO TurboDOS
is evidently problematic.

And both TurboDOS and the PC support RTS/CTS flow control, right? So for any
text file on TurboDOS, shouldn't you be able to TYPE it to the serial port?
And have the PC terminal emulator capture it to a file? It's not elegant, but
you only have to do it "just this once". If it's really RTS/CTS flow control,
you should be able to do this at any speed that TurboDOS supports and you have
a true null modem cable:

http://www.columbia.edu/kermit/cable.html

If you have Kermit 95 on the Windows box, the commands would be LOG SESSION
(to start logging) and CLOSE SESSION (to stop).

If you have to send binary files, you'd have to ASCIIize them first, of
course.

With some programming on each end, you could even automate the process.
The TurboDOS program would loop through all the files, sending first some
kind of distinctive text header containing the filename, like:

>>> BEGIN filename-goes-here <<<

then the file contents, then (not strictly necessary) a footer:

>>> END <<<

A Kermit script could be written that waits for a header:

INPUT 9999 <<<

parses it (I'll supply details if you're interested), and then opens
a session log using the filename from the header:

LOG SESSION filename-goes-here

and waits for the footer:

INPUT 9999 >>> END <<<
IF FAILURE (fill in what to do if this fails)
CLOSE SESSION

All this in a loop. If you wanted to get fancy, you could also have an
end-of-session footer to terminate the loop. Or other embellishments like
transmitting the file date.

With a short cable and the high speed of the Windows box and hardware flow
control driven by the receiver, you should have pretty much error-free
transfers.

Sorry to not respond to all your posts promptly but as I might have mentioned,
Columbia U no longer supports netnews so I have to find the time to go
elsewhere to read news.

- Frank

Frank da Cruz wrote:
> On 2008-04-04, PC Pete wrote:
> : ...
> : Thanks to all for your wonderful ideas, it's nice to have someone more
> : experienced offer help, especially when you're as rusty as I am!
> :
> I'm more rusty. The last time I actually worked with this code was over
> 20 years ago and I'm sure it goes without saying that I don't have any
> machines here where I could do it again. I don't understand why the "native
> TurboDOS" version doesn't work, but then I've never even seen TurboDOS.
> Unfortunately I don't see any other grizzed CP/M Kermit veterans popping
> up with advice.
>
It's not that surprising, Frank, I'm more surprised that this newsgroup
is still alive and kicking at all! Mind you, it's a bit like going into
a wonderful old hotel that's been bypassed by new highways - the
furniture and fittings are still there, one or two "grizzled" staff
greet the infrequent guests, but we watch the old billboards fade while
dust quietly gathers in the corners...

> I also noticed this directory, which I had forgotten about:
>
> ftp://kermit.columbia.edu/kermit/old/misc/cpmtools
>
> It contains source for LASM and MLOAD.
>
That's a good find - I didn't dig too deeply, I was too fixated on
finding other mirrors with different source sets. I'll try that out (I
think LASM/MLOAD might deal with the merging problems better than DDT.

> But maybe there's a simpler approach. The object of the game is to get
> your files OFF TurboDOS and into the PC, right? Getting things INTO TurboDOS
> is evidently problematic.
>
Yep, this is (for now) a one-way only problem. I have to get the oil OFF
the sinking tanker.

> And both TurboDOS and the PC support RTS/CTS flow control, right? So for any
> text file on TurboDOS, shouldn't you be able to TYPE it to the serial port?
> And have the PC terminal emulator capture it to a file? It's not elegant, but
> you only have to do it "just this once". If it's really RTS/CTS flow control,
> you should be able to do this at any speed that TurboDOS supports and you have
> a true null modem cable:
>
> http://www.columbia.edu/kermit/cable.html
>
You read my mind. The problem for me is that on a 64-bit OS, none of the
terminal emulators work properly (the only one that offers some help in
the form of waiting for simple characters and so on is a real 16-bit
Windows 95 emulator with no buffer capture).

> If you have Kermit 95 on the Windows box, the commands would be LOG SESSION
> (to start logging) and CLOSE SESSION (to stop).
>
At the moment, the only kermit I have working is the one that's rolled
into the terminal emulator, and that's not programmable - it just sends
or receives kermit "packets" - if it doesn't receive kermit protocol
information, it treats the data as bad.

> If you have to send binary files, you'd have to ASCIIize them first, of
> course.
>
> With some programming on each end, you could even automate the process.
> The TurboDOS program would loop through all the files, sending first some
> kind of distinctive text header containing the filename, like:
>
> >>> BEGIN filename-goes-here <<<
>
> then the file contents, then (not strictly necessary) a footer:
>
> >>> END <<<
>
> A Kermit script could be written that waits for a header:
>
> INPUT 9999 <<<
>
> parses it (I'll supply details if you're interested), and then opens
> a session log using the filename from the header:
>
> LOG SESSION filename-goes-here
>
> and waits for the footer:
>
> INPUT 9999 >>> END <<<
> IF FAILURE (fill in what to do if this fails)
> CLOSE SESSION
>
> All this in a loop. If you wanted to get fancy, you could also have an
> end-of-session footer to terminate the loop. Or other embellishments like
> transmitting the file date.
>
> With a short cable and the high speed of the Windows box and hardware flow
> control driven by the receiver, you should have pretty much error-free
> transfers.
>
I've already written ascii-fiers and de-ascii-fiers that work, I was
just hoping to avoid having to loop through the 7,000-odd files on 40
user areas on 5 drive volumes, many of which are now corrupt or
unreadable. But I've already spent more time trying to find out why
Kermit doesn't compile than I would have spent doing a
findfirst/findnext looped transfer of files in a simple protocol as
you've suggested.

> Sorry to not respond to all your posts promptly but as I might have mentioned,
> Columbia U no longer supports netnews so I have to find the time to go
> elsewhere to read news.
>
> - Frank

Don't apologise, it's me who should apologise for spewing updates and
data here without fully understanding the intricacies of the kermit
compile requirements, and 15+ years since I last M80'd in anger.

I appreciate every word you've been able to suggest. I'll spend a couple
more hours to see if I can get any debugging done (after compiling and
linking with masm/mload) and using my newly-captured CPSKER.PRN, and if
not, I'll bite the bullet and 'do the washing by hand'.

I've also finally got my WinXP-32 virtual machine running, that will
give me true access to the comm ports on the PC in a 32-bit environment,
which will open up some other transfer options with different serial
tools (I hope)! I've also dusted off and fired up my PC-XT with a whole
bunch of serial comms software (Telix Procomm, MS-DOS kermit, etc) on
it. Unfortunately the serial hardware access in the MS-DOS virtual
machines isn't as robust as in the XP virtual machine. So there are a
few bridges yet to burn...

Thanks again for all the ideas and suggestions, I really appreciate the
help. I really really really want to be able to give something back. But
don't hold your breath...

Kind regards
PC Pete



--
--
"I want to die peacefully in my sleep, like my grandpa, not screaming
and crying, like the passengers in his car." -Unremembered source from
the (19)90's.

Frank da Cruz wrote:
> On 2008-04-04, PC Pete wrote:
> : ...
> : Thanks to all for your wonderful ideas, it's nice to have someone more
> : experienced offer help, especially when you're as rusty as I am!
> :
> I'm more rusty. The last time I actually worked with this code was over
> 20 years ago and I'm sure it goes without saying that I don't have any
> machines here where I could do it again. I don't understand why the "native
> TurboDOS" version doesn't work, but then I've never even seen TurboDOS.
> Unfortunately I don't see any other grizzed CP/M Kermit veterans popping
> up with advice.
>
It's not that surprising, Frank, I'm more surprised that this newsgroup
is still alive and kicking at all! Mind you, it's a bit like going into
a wonderful old hotel that's been bypassed by new highways - the
furniture and fittings are still there, one or two "grizzled" staff
greet the infrequent guests, but we watch the old billboards fade while
dust quietly gathers in the corners...

> I also noticed this directory, which I had forgotten about:
>
> ftp://kermit.columbia.edu/kermit/old/misc/cpmtools
>
> It contains source for LASM and MLOAD.
>
That's a good find - I didn't dig too deeply, I was too fixated on
finding other mirrors with different source sets. I'll try that out (I
think LASM/MLOAD might deal with the merging problems better than DDT.

> But maybe there's a simpler approach. The object of the game is to get
> your files OFF TurboDOS and into the PC, right? Getting things INTO TurboDOS
> is evidently problematic.
>
Yep, this is (for now) a one-way only problem. I have to get the oil OFF
the sinking tanker.

> And both TurboDOS and the PC support RTS/CTS flow control, right? So for any
> text file on TurboDOS, shouldn't you be able to TYPE it to the serial port?
> And have the PC terminal emulator capture it to a file? It's not elegant, but
> you only have to do it "just this once". If it's really RTS/CTS flow control,
> you should be able to do this at any speed that TurboDOS supports and you have
> a true null modem cable:
>
> http://www.columbia.edu/kermit/cable.html
>
You read my mind. The problem for me is that on a 64-bit OS, none of the
terminal emulators work properly (the only one that offers some help in
the form of waiting for simple characters and so on is a real 16-bit
Windows 95 emulator with no buffer capture).

> If you have Kermit 95 on the Windows box, the commands would be LOG SESSION
> (to start logging) and CLOSE SESSION (to stop).
>
At the moment, the only kermit I have working is the one that's rolled
into the terminal emulator, and that's not programmable - it just sends
or receives kermit "packets" - if it doesn't receive kermit protocol
information, it treats the data as bad.

> If you have to send binary files, you'd have to ASCIIize them first, of
> course.
>
> With some programming on each end, you could even automate the process.
> The TurboDOS program would loop through all the files, sending first some
> kind of distinctive text header containing the filename, like:
>
> >>> BEGIN filename-goes-here <<<
>
> then the file contents, then (not strictly necessary) a footer:
>
> >>> END <<<
>
> A Kermit script could be written that waits for a header:
>
> INPUT 9999 <<<
>
> parses it (I'll supply details if you're interested), and then opens
> a session log using the filename from the header:
>
> LOG SESSION filename-goes-here
>
> and waits for the footer:
>
> INPUT 9999 >>> END <<<
> IF FAILURE (fill in what to do if this fails)
> CLOSE SESSION
>
> All this in a loop. If you wanted to get fancy, you could also have an
> end-of-session footer to terminate the loop. Or other embellishments like
> transmitting the file date.
>
> With a short cable and the high speed of the Windows box and hardware flow
> control driven by the receiver, you should have pretty much error-free
> transfers.
>
I've already written ascii-fiers and de-ascii-fiers that work, I was
just hoping to avoid having to loop through the 7,000-odd files on 40
user areas on 5 drive volumes, many of which are now corrupt or
unreadable. But I've already spent more time trying to find out why
Kermit doesn't compile than I would have spent doing a
findfirst/findnext looped transfer of files in a simple protocol as
you've suggested.

> Sorry to not respond to all your posts promptly but as I might have mentioned,
> Columbia U no longer supports netnews so I have to find the time to go
> elsewhere to read news.
>
> - Frank

Don't apologise, it's me who should apologise for spewing updates and
data here without fully understanding the intricacies of the kermit
compile requirements, and 15+ years since I last M80'd in anger.

I appreciate every word you've been able to suggest. I'll spend a couple
more hours to see if I can get any debugging done (after compiling and
linking with masm/mload) and using my newly-captured CPSKER.PRN, and if
not, I'll bite the bullet and 'do the washing by hand'.

I've also finally got my WinXP-32 virtual machine running, that will
give me true access to the comm ports on the PC in a 32-bit environment,
which will open up some other transfer options with different serial
tools (I hope)! I've also dusted off and fired up my PC-XT with a whole
bunch of serial comms software (Telix Procomm, MS-DOS kermit, etc) on
it. Unfortunately the serial hardware access in the MS-DOS virtual
machines isn't as robust as in the XP virtual machine. So there are a
few bridges yet to burn...

Thanks again for all the ideas and suggestions, I really appreciate the
help. I really really really want to be able to give something back. But
don't hold your breath...

Kind regards
PC Pete



--
--
"I want to die peacefully in my sleep, like my grandpa, not screaming
and crying, like the passengers in his car." -Unremembered source from
the (19)90's.

Frank da Cruz wrote:
> The version we have up on our FTP server is 4.11, which was done by Mike
> Freeman, but I haven't heard from him in years. But perhaps this version
> exceeds some bounds that were not exceeded by earlier versions. There's an
> older version -- I'm not sure exactly which one -- here:
>
> ftp://kermit.columbia.edu/kermit/old/misc/cpm
>
> I also noticed this directory, which I had forgotten about:
>
> ftp://kermit.columbia.edu/kermit/old/misc/cpmtools
>
> It contains source for LASM and MLOAD.

Actually Frank, those files are inaccessible via anonymous ftp. I can cd
to the directory, but I can't download any of the files using either a
dos ftp client nor a web-based (html) ftp client.

I'll have a look for those files on different archives and see what I
can get.

On Apr 6, 5:04 pm, PC Pete wrote:
> Frank da Cruz wrote:
> > The version we have up on our FTP server is 4.11, which was done by Mike
> > Freeman, but I haven't heard from him in years. But perhaps this version
> > exceeds some bounds that were not exceeded by earlier versions. There's an
> > older version -- I'm not sure exactly which one -- here:
>
> > ftp://kermit.columbia.edu/kermit/old/misc/cpm
>
> > I also noticed this directory, which I had forgotten about:
>
> > ftp://kermit.columbia.edu/kermit/old/misc/cpmtools
>
> > It contains source for LASM and MLOAD.
>
> Actually Frank, those files are inaccessible via anonymous ftp. I can cd
> to the directory, but I can't download any of the files using either a
> dos ftp client nor a web-based (html) ftp client.
>
> I'll have a look for those files on different archives and see what I
> can get.


The files in those directories are not world readable. I'm sure Frank
will fix it as soon as he sees your post.

I wish I could be more help, but every time I think about this, I have
to stop and clean my keyboard because of all the rust particles that
fall out of my head. I haven't been in those dusty corners in a very
long time.

--
(for email use this address please - you can figure it out)

Mark Sapiro mark at msapiro net Any clod can have the facts;
San Francisco Bay Area, California having opinions is an art. -
C. McCabe, The Fearless Spectator

Mark Sapiro wrote:
> The files in those directories are not world readable. I'm sure Frank
> will fix it as soon as he sees your post.

That would explain a lot! I've actually just slurped the \c\ group of
files just so I can search and view them faster than the WWW or ftp
clients can. I hope nobody minds. Heck, I've got enough storage to spare
to archive the entire site I think, but that might not be a good idea...

> I wish I could be more help, but every time I think about this, I have
> to stop and clean my keyboard because of all the rust particles that
> fall out of my head. I haven't been in those dusty corners in a very
> long time.
Don't apologise, I'm rusty as well. I'm still figuring out the bloody
parameter strings for TurboDOS, let alone the M80/L80 progs...

I've actually tried building the TP4KER source from Terje Mathiesen's
source, but it depends on some object files that my TP5/6/7 system
doesn't have. Definitely a blast from the past, remembering how to build
and compile to disk!

And don't get me started with debugging - that was my life back then and
I can't believe how much we've come to rely on integrated debuggers -
Allah forfend, I was putting printf() and Writeln() and .printx
statements all through the source files I've found. There's definitely a
lot to be said for modern debuggers. Still, it's all good fun.

If I can't compile the MASM/LASM source, I'll definitely sit down in
front of my emulated local CP/M window and do what I should have done in
the beginning - rolled my own clunky serial transfer code. Sometimes
shortcuts definitely AIN'T.

Thanks all for your help, I'll keep looking and trying I guess.
-PCP

On 2008-04-07, PC Pete wrote:
: Frank da Cruz wrote:
:> The version we have up on our FTP server is 4.11, which was done by Mike
:> Freeman, but I haven't heard from him in years. But perhaps this version
:> exceeds some bounds that were not exceeded by earlier versions. There's an
:> older version -- I'm not sure exactly which one -- here:
:>
:> ftp://kermit.columbia.edu/kermit/old/misc/cpm
:>
:> I also noticed this directory, which I had forgotten about:
:>
:> ftp://kermit.columbia.edu/kermit/old/misc/cpmtools
:>
:> It contains source for LASM and MLOAD.
:
: Actually Frank, those files are inaccessible via anonymous ftp. I can cd
: to the directory, but I can't download any of the files using either a
: dos ftp client nor a web-based (html) ftp client.
:
: I'll have a look for those files on different archives and see what I
: can get.
:
The files are accessible by FTP if you don't have a firewall on your end
blocking access.

You can also get files from the Kermit archive with HTTP by following the
link at the bottom of the Kermit Project home page.

- Frank

On 2008-04-07, Mark Sapiro wrote:
:> > ftp://kermit.columbia.edu/kermit/old/misc/cpmtools
:>
: The files in those directories are not world readable. I'm sure Frank
: will fix it as soon as he sees your post.
:
Oops, sorry again for the delay, and for the mistake. Contrary to sentiments
recently aired here, Kermit is very much alive and there is a great deal of
FTP activity, and I get a truckload of complaints about "FTP doesn't work"
every day, and until now it's been because of firewalls. The permissions
are fixed now.

- Frank

Frank da Cruz wrote:
> The files are accessible by FTP if you don't have a firewall on your end
> blocking access.
>
> You can also get files from the Kermit archive with HTTP by following the
> link at the bottom of the Kermit Project home page.
>
> - Frank

Thanks Frank, I've been able to download the hex and asm sources.

I'm so sorry to take so long to respond, I've been sidetracked by a DOS
build problem on another ye olde system, and I haven't even thought
"CP/M" for weeks...

When I get back into code build mode, I'll try and update here to let
anyone else interested know... Watch this space.

Thanks again for your involvement. It's good to know Kermit is still
very much a live project!
Kind regards,
PCPete

PC Pete wrote:

> Thanks again for your involvement. It's good to know Kermit is still
> very much a live project!

I like kermit. It is a pity about the restrictive licencing that makes
the source code effectively read-only, unless patches are used.

The project would probably be a lot more active, if it was under an open
source licence that permits free modification of the source code and
distribution of modified versions.

There is a gkermit package which is distributed under GPL, but this does
not contain connection establishment facilities. If gkermit supported
connection establishment, it would be great.

Mark.

--
Mark Hobley,
393 Quinton Road West,
Quinton, BIRMINGHAM.
B32 1QE.