RE: userport: C64, Plus4, others?

Lol... well I tried.



Think about the similarities/differences between "car driver" and "bus
driver" where both words have two meanings. I wonder if I made it worse
with the word "bus".



*From:* owner-cbm-hackers@musoftware.de [mailto:
owner-cbm-hackers@musoftware.de] *On Behalf Of *Imre Széll
*Sent:* Friday, March 09, 2012 1:42 PM
*To:* cbm-hackers@musoftware.de
*Subject:* 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