Help with CPVGEN sources for TurboDOS system? - Protocols

This is a discussion on Help with CPVGEN sources for TurboDOS system? - Protocols ; 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 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: Help with CPVGEN sources for TurboDOS system?

  1. Help with CPVGEN sources for TurboDOS system?

    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'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.

    By "properly", I mean it links in, but running the final COM file
    results in an immediate exit to the prompt with no messages or any other
    activity that I can see.

    Luckily, I also have Turbo Pascal 3.01, so I've been able to write a
    simple download/parse routine to get the source and hex files on to the
    system, so I might be able to build something myself - but that's going
    to take time that the system just doesn't have left.

    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.

    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.

    I've spent two or three hours disassembling the DDT'd hex file for
    CPVGEN, but of course that doesn't work properly once the instruction
    stream gets out of sync with the disassembled addresses.

    Any ideas, comments, or suggestions would be most welcome.

    Kind regards,
    PCPete
    PCPete at audiography dot com dot au

  2. Re: Help with CPVGEN sources for TurboDOS system?

    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*


  3. Re: Help with CPVGEN sources for TurboDOS system?

    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

  4. Re: Help with CPVGEN sources for TurboDOS system?

    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

  5. Re: Help with CPVGEN sources for TurboDOS system?

    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.

  6. Re: Help with CPVGEN sources for TurboDOS system?

    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.

  7. Re: Help with CPVGEN sources for TurboDOS system?

    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

  8. Re: Help with CPVGEN sources for TurboDOS system?

    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.



  9. Re: Help with CPVGEN sources for TurboDOS system?

    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}

  10. Re: Help with CPVGEN sources : Problem found

    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...

  11. Re: Help with CPVGEN sources : Problem found

    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

  12. Re: Help with CPVGEN sources : Problem found

    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.

  13. Re: Help with CPVGEN sources : Problem found

    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.

  14. Re: Help with CPVGEN sources : Problem found

    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.

  15. Re: Help with CPVGEN sources : Problem found

    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

  16. Re: Help with CPVGEN sources : Problem found

    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

  17. Re: Help with CPVGEN sources : Problem found

    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

  18. Re: Help with CPVGEN sources : Problem found

    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

  19. Re: Help with CPVGEN sources : Problem found

    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

  20. The life of Kermit

    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.

+ Reply to Thread
Page 1 of 2 1 2 LastLast