RE: userport: C64, Plus4, others?

Thanks for you effort, Bil but I think Google Translate has a lot to
improve. ;-) for example it translates "driver" as "car driver".
Nevertheless the whole translation made me a good laugh.
But the whole text is understable especially if you read the English
version too.
2012.03.09. 17:31, "Bil Herd" <bherd@mercury-cg.com> ezt írta:

> Igen, "Z" impedancia http://en.wikipedia.org/wiki/Electrical_impedance
> van, így több az "elektronikus nyelv", majd angolul. "Hi Z" lenne voltak
> mind a járművezetők alacsony és a magas vezetők ki vannak kapcsolva.
>
> Tervezése során számítógépeket, a szükséges időt menni "Hi-Z" volt néha
> probléma. "Hi-Z" nagyon gyorsan megtörténhet, a legjobb esetben, nem
> lehetett számolni, hogy a hosszabb ideig tartó öntartó adatok. Egyes
> eszközök késéssel 100ns, hogy "kuss", vagy menjen "Hi-Z"
>
> Ennek oka, hogy ha az eszköz NMOS elég nagy ahhoz, hogy vezessen egy busz,
> majd a kapu a NMOS tranzisztor kell, hogy legyen nagy. Egy nagy kapu
> terület azt jelenti, sok a kapacitás és az idő, hogy "Hi-Z" diktálta, hogy
> milyen gyors a töltés vérzett le a kapacitást a kapu. Ez volt gyorsabb
> váltani alacsony és magas-alacsony, mint az idő, hogy kapcsolja ki NMOS
> tranzisztorok a busz sokkal nagyobb volt.
>
> Bil Herd
>
> *** I had to re-write this many times using google translate in both
> directions to test.  Please let me know if I have translation okay.
>
> Yes, "Z" is impedance http://en.wikipedia.org/wiki/Electrical_impedance so
> more of "electronic language" then English.  "Hi Z" would be were both the
> low drivers and the high drivers are turned off.
>
> When designing computers,  the time it takes to go "Hi-Z" was sometimes a
> problem.  "Hi-Z" could happen really fast best case, you couldn't count on
> it lasting longer for  latching of data.  Some devices have a delay of
> 100ns to "shut up" or go "Hi-Z"
>
> The reason is that if the NMOS device is big enough to drive a bus, then
> the gate of the NMOS transistor has to be big.  A big gate area  means
> lots of capacitance and the time to "Hi-Z" was dictated by how quick the
> charge bled off of the capacitance of the gate.  It was actually quicker
> to switch from Low to High to Low  compared to the time to  turn  off NMOS
> transistors for the bus was much greater.
>
>
> -----Original Message-----
> From: owner-cbm-hackers@musoftware.de
> [mailto:owner-cbm-hackers@musoftware.de] On Behalf Of Gábor Lénárt
> Sent: Thursday, March 08, 2012 4:34 AM
> To: cbm-hackers@musoftware.de
> Subject: Re: userport: C64, Plus4, others?
>
> On Wed, Mar 07, 2012 at 11:20:48AM -0600, Jim Brain wrote:
> > On 3/7/2012 3:10 AM, Gábor Lénárt wrote:
> > >Hi Jim,
> > >
> > >On 6526, afaik: "PC will go low for one cycle following a read or
> > >write of PORT B".  So I guess, falling edge of PC can tell (or the
> > >low level ...) the uC that CPU put new value on CIA2 PORT B (if it's
> > >a writing session) or read a byte from (if it's a reading session).
> > >If uC is fast enough (I am really not sure about this, fixme ...) an
> > >interrupt can be generated on the uC triggered by PC, and that
> interrupt handler would store/load the next value.
> > That would work for writing data from the 64 and reading it on the uC
> > (Tie PC to INT on AVR).
> >
> > Note, though that the 6526 PORTB is a IO port, not a data bus.  As
> > such, it has no HiZ state.
>
> What HiZ is? I guess it's high impedance, am I right? As being Hungarian I
> am not sure about the English notion of things sometimes, sorry about it.
>
> >
> > An example:
> >
> > We set the DDRB on 6526 to output data, and the uC has it's port set
> > to INPUT.  All is well.  We output data on PORTB, PC goes low,
> > triggering a uC INT, and the uC reads the data.
> >
> > All is well.
> >
> > Then, though, the uC needs to send data back to the 64.  If it just
> > outputs data to PORTB, the two outputs (remember, DDRB is set to
> > output on all pins) will fight one another, potentially damaging the
> > 6526 (or a buffer that you put in the middle).
>
> Yes, but my idea that always the C64 is the one who must start a transfer
> regardless of the data direction (read/write). uC won't respond by its
> own, but C64 requires both of the read/write signaling with another line
> (maybe
> PA2 on userport or something like that). So the C64 sets the direction up
> on CIA, and uC is signaled about the data direction by the C64 so it will
> know as well about the transfer direction. AFAIK even DTV has the PA line,
> however I am a bit confused about DTV, as I've read it has not got fully
> functional 8 bit I/O just for input, but it's possible that it was about
> the Hummer game only and not the DTV (v2 or v3) actually, I must still
> investigate about this.
>
> However that's still true that there can be times for a short period (or
> program bug?) when eg both of uC and C64 thinks they do output, and there
> can be some problem then what you described. I am really not an expert
> about digital circuits yet (that's also why I want to start a project like
> this to learn some new things), I don't know who to make this safe and not
> to burn something ...
>
> > THere are a number of potential solutions.  I think the simplest is to
> > dedicate two ports on the uC for data.  PORTI (input) and PORTO
>
> Maybe, however I would like to use an uC which has the minimal number of
> pins as possible (using more ports on uC means more pins), I mean using a
> DIP version is OK, but I think I have got no skills and tools to solder
> chips which are not DIP.  Also making a board as a "DIY" style would be
> quite hard then (for me at least).  I have some experience to build more
> basic boards/soldering using discrete stuffs and DIP ICs.
>
> Btw, for starting point I'd like to wire some kind of SD socket, with dual
> purpose: uC would "boot" its "firmware" from it (there are boot loaders
> for AVR like this afaik) and also it can be used to read/write data
> sent/read by
> C64 too (yes, I know, SD2IEC and like are "better" because they are
> "ready"
> and compatible with a stock machine too - since it uses std IEC bus, but
> also because of this, it can't be as fast, and also note that having the
> SD storage is only a part of the project, and not even the primary goal).
> It's a bit like however as IDE64; it's also not compatible at hw level (it
> does not using IEC) the compatibility is provided with KERNAL modification
> (on DTV it's really easy, no need for additional hardware).
>
> So I would need an uC which can interface with the C64 (and DTV later) and
> which is also connected to an SD card for example. Besides this, my goal
> is some kind of ethernet connectivity, I am not sure about this: uCs which
> has it "built in" usually have just two many pins for an average hobby
> use. I am thinking on using I2C or SPI bus with external ethernet chip
> designed for this, it's still can be quite fast, at least as far as I can
> remember, the transfer rate can be even 3-4 mbit/sec still on these serial
> buses. Also other stuffs may be connected later on I2C/SPI, it remembered
> me a bit for C2N-power btw :) Just I would like a solution which also
> works with DTV, and using parallel data transfer from the view point of
> the computer.
>
> > (output).  tie PORTB to IPORT and PORTB to the '245 and PORTO to the
> > other side of the '245.  You can use PC as WRITE, which will trigger a
> > read of PORTI.  Using a signal on the 64 for READ will allow the
> > 245 to engage, dumping PORTO data to the PORTB pins.  Of course, the
> > 64 needs to:
> >
> > SET DDRB to input
> > BRING READ low
> > READ PORTB
> > BRING READ high
> >
> > That's not too bad.  You can do this without the '245 (watch for low
> > INT on READ, when found, set DDRO to output, put data on port, wait
> > for READ to go hi, and then set DDRO to input).  However, this places
> > more timing demand on the uC.
>
> Hmm. As I've written above, uC won't answer on its own, just if C64 asks
> for some answer. However still I need some kind of solution for preventing
> demage when both of C64 and uC is configured (for any reason including a
> software bug etc) as output. Normally it won't happen, but still. I am
> really not experienced here though ...
>
>
> > >So it seems pin PC can be used for handshaking quite well (both for
> > >reading and writing).
> > I guess I must have missed something, but I would not assume the uC
> > *knows* when it is safe to place data on PORTB, for the double output
> > concern listed above.
>
> The key what I told that always the C64 tell it wants data to send or
> receive (eg using that PA2 pin on user port). So the uC should know the
> data direction. But still, as I've stated, some kind of protection would
> be needed anyway.
>
> Sorry if I missed something because of my "not so perfect" English, it can
> happen ...
>
>
>       Message was sent through the cbm-hackers mailing list
>
>       Message was sent through the cbm-hackers mailing list
>


       Message was sent through the cbm-hackers mailing list