Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!mit-eddie!killer!elg
From: elg@killer.DALLAS.TX.US (Eric Green)
Newsgroups: comp.sys.cbm
Subject: Re: Zmodem on commodores?
Message-ID: <7022@killer.DALLAS.TX.US>
Date: 3 Feb 89 06:12:41 GMT
References: <6482@emcard.UUCP>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 55

in article <6482@emcard.UUCP>, mat@emcard.UUCP (W Mat Waites) says:
> What ever happened to the joker who posted a couple of months ago about
> building a real UART board?

My brother designed and built a real UART board. However, it has the
slight problem of being incompatible with most terminal programs,
since the drivers are in RAM and not ROM. This is easily solved by
modifying the ROMs, but I haven't moved his code into "ROM" yet (I
have a "soft Kernal ROM" setup that I use for such prototyping
purposes).

I'm thinking about sending some of this stuff to The Transactor. Maybe
you'll eventually see some of it there, at least in its current
(non-commercial-quality but usable) state.

> Surely the NMI routines run fast enough to allow response to a uart, i.e.
> 1 interrupt per character.

Nope. We got big-time serial-bus lockup when we tried. Turning the
RS232 NMI's off when accessing disk solved that problem. It's easy
enough to see why, when you see the Kernal ROM:

(ARGH! I can't find my annotated Kernal at the moment... anyhow...)

Do byte-level handshaking.
OK, got handshake, wait for individual bits:
lp: Wait for bus to settle
    shift clock bit into carry, if not clock goto lp:
    shift bit into byte, exit loop if got full byte.
    Wait for clock to fall again, e.g. another loop like above
    jmp lp:   

T(v) is on the order of 20us. Looking at the C-64's serial bus output
routines (which presumably are duplicated inside the 1541), there's
only 20 instructions or so executed per each time thru the loop that's
shifting these bits out... it's shifting the bits out as fast as it
can, except for a 4-NOP delay and waiting for the bus to settle.
There's little chance of responding to a NMI in this sort of time
frame. Heck, it takes most of that just to save/restore the registers!

> Another kludgey possibility (and aren't kludges the tradition in c64
> telecomm?) would be to allocate a large chunk of memory to hold
> incoming blocks. That would allow you to cut zmodem loose for 20k bytes

This would work fairly well, actually. It would give you the
advantages of Ymodem (the big block size), without the disadvantage
(having to re-send that whole big block upon error). If you have a
fast drive, it might actually be worthwhile. With a 1541, regular
Xmodem is just as fast, unless you're using PC Pursuit (which is going
away). 

--
|    // Eric Lee Green              P.O. Box 92191, Lafayette, LA 70509     |
|   //  ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg     (318)989-9849     |
| \X/              >> In Hell you need 4Mb to Multitask <<                  |